[00:08] <calc> wgrant: that was fast :)
[00:10] <wgrant> calc: That's one of the fastest rollouts I've seen them do. Pleasantly surprising.
[00:15] <calc> wgrant: yea :) short outages are fine with me :)
[00:15] <calc> i'm just scared of those 8hr+ outages ;-)
[00:16] <wgrant> I remember back when they used to take it down for >2 hours every Tuesday night. That was annoying.
[00:18] <calc> yea
[00:25] <beuno> 12 minutes total downtime
[00:25] <beuno> we're getting better!
[00:29] <wgrant> beuno: But I guess you can't be so quick during normal rollouts :(
[00:30] <beuno> wgrant, probably not, but quick-er
[00:31] <beuno> and just wait until read-only launchpad lands...
[00:31] <wgrant> That has been coming for a long time... but it does seem to have a hard target now...
[00:31] <beuno> well, you know, good things come to those who wait...
[00:31] <beuno> if you don't, onlt bad things (>)
[00:36] <bryce> I has haircut
[00:37]  * wgrant blames developers' haircuts for RC being buggy.
[00:39] <persia> wgrant, You think it's better to fix bugs than cut hair?
[00:39] <wgrant> persia: You obviously haven't seen my hair.
[00:40] <persia> No :)
[00:40] <persia> Although, personally, every five or six months, my hair starts getting in the way of my doing useful things like seeing or typing, and I find a haircut assists in bug closure.
[00:41] <bryce> persia: indeed
[00:41] <wgrant> There are workarounds for that which don't involve cutting it, fortunately.
[00:42] <bryce> timing haircuts to coincide with lp downtimes == priceless
[00:42] <persia> bryce, Admit it: it was luck.
[00:42] <bryce> yeah pretty much
[00:43] <persia> wgrant, Depends on your hair.  Mine tends to break.
[00:44] <ogra> pfft heairs
[00:44] <ogra> *hairs
[00:44] <wgrant> Mine has survived quite well for a number of years.
[00:45] <ogra> mine too ... but i find beards more significantly showing that state of my workload :)
[00:45] <ogra> *the
[00:55] <ion_> pitti: Heh, there’s already a bug report about it. I’ll see whether i’ll get around to creating a patch for the issue.
[01:14]  * StevenK appears
[01:16] <persia> StevenK, There's no kernel, and been no word for ~8 hours.  Apparently it was evening in Europe.
[01:16] <persia> Oh, and Good morning :)
[01:28] <StevenK> Hmm
[01:47] <munckfish> cjwatson: you there?
[01:48] <cjwatson> munckfish: if you don't mind a zombie
[01:48] <munckfish> well I am one myself :)
[01:48] <munckfish> :S
[01:49] <munckfish> cjwatson: could we add a "recovery" option to the kboot-installer package?
[01:49] <munckfish> I needed that today
[01:49] <cjwatson> not now, maybe for jaunty
[01:49] <munckfish> ok
[01:49] <cjwatson> can't add features 12 days before release :)
[01:49] <munckfish> yeah true, it's a feature
[01:49] <munckfish> sorry
[01:49] <cjwatson> so you mean like a rescue CD type thing?
[01:50] <munckfish> umm like we have in grub
[01:50] <cjwatson> "rewrite my kboot.cnf"
[01:50] <munckfish> two items for each kernel
[01:50] <cjwatson> oh, you mean a separate boot menu entry
[01:50] <munckfish> second one boots kernel with "single" as it's arg
[01:50] <cjwatson> yeah, sure, that would make sense for jaunty
[01:51] <munckfish> which boots into that recovery menu which allows you to get root shell or fix X etc
[01:51] <munckfish> cool
[01:51] <munckfish> Oh I nearly cried today
[01:51] <munckfish> I never expected to see such bad bad problems so late
[01:51] <cjwatson> can't you edit the menu in kboot to some degree?
[01:51] <cjwatson> or boot manually or something
[01:51] <munckfish> especially as Intrepid  was running so nice just last week :(
[01:51] <munckfish> cjwatson: oh yeah I can edit it
[01:52] <cjwatson> I agree the framebuffer thing is bad, you'll have to delve into initramfs to figure that one out
[01:52] <munckfish> It just occurred to me it'd be useful for "users"
[01:52] <cjwatson> hopefully my kboot-installer change will fix the label thing, I'm pretty confident
[01:52] <cjwatson> it's definitely a correct fix
[01:52] <munckfish> ah cool
[01:52] <munckfish> roughly what did you change? Or where can I see the patch?
[01:53] <cjwatson> munckfish: http://paste.ubuntu.com/59077/
[01:53] <munckfish> cjwatson: do you ever sleep?
[01:53] <cjwatson> was a global change across partman, we just missed kboot-installer :-(
[01:54] <cjwatson> munckfish: not nearly so much as I'd like
[01:54] <munckfish> aha that defo looks like the thing
[01:54] <munckfish> you in BST/GMT?
[01:54] <cjwatson> BST, yes
[01:55] <munckfish> me too
[01:55] <cjwatson> ... and I have to be up in reasonable time tomorrow so I think that has to be a wrap :)
[01:55] <munckfish> yeah I need to quite now too
[01:55] <munckfish> thx for your help so late
[01:55] <cjwatson> no problem
[01:55] <munckfish> c ya!
[02:05] <wgrant> Oh ffs.
[02:05] <wgrant> Is there somebody around with an amd64 xserver with a Synaptics touchpad?
[02:05] <wgrant> Something continues to be borked in the X stack.
[02:06] <bryce> wgrant: sadly my amd64 box is a desktop
[02:06] <wgrant> bryce: Are you able to run xinput list-props on one of your real mice?
[02:07] <wgrant> Somebody is complaining that my new syndaemon version doesn't work properly, but xinput is segfaulting, so I think we can blame it elsewhere...
[02:07] <wgrant> Oh.
[02:07] <slangasek> wgrant: amd64 w/ synaptics here, yes
[02:07] <wgrant> I can reproduce it with an i386 server... but only on the synaptics device.
[02:07] <wgrant> What the....
[02:07] <wgrant> The other devices work fine.
[02:08] <wgrant> So amd64 clients don't like synaptics properties for some reason.
[02:08] <wgrant> Regardless of server arch.
[02:08] <wgrant> amd64 needs to die. Or X.
[02:09] <bryce> slangasek: btw, fix for targeted bug 275285 is tested and uploaded
[02:10] <wgrant> So XGetDeviceProperty now works fine.
[02:10] <bryce> slangasek: wait a sec
[02:10] <wgrant> But XListDeviceProperties segfaults for -synaptics. How stupid.
[02:12] <bryce> slangasek: ok 275285 ready for approval
[02:12] <RAOF> wgrant: Uuuh, yeah!  What the hell happened there?  xinput list-props "Syn..." _worked_ for one blessed day, and now segfaults?
[02:13] <slangasek> bryce: well, hasn't reached the queue yet :)
[02:13] <wgrant> RAOF: I'm stepping through upgrades to work out what broke it.
[02:14]  * RAOF 's internet is currently capped at a princely 64kbit/sec, so is not the ideal candidate for that. :(
[02:14]  * bryce turns attention to 261977
[02:15] <wgrant> RAOF: I've only been capped once this year, but back two years ago when we were on the 1GB plan we were frequently capped to 28.8kbps for half a month...
[02:15] <LimCore> hi devels \o/
[02:15] <RAOF> wgrant: I forgot how utterly dependent on a fast connection Intrepid testing is.
[02:15] <wgrant> RAOF: Yes...
[02:16] <wgrant> Though it's not so bad now we're frozen.
[02:16] <RAOF> At the current rate, it'll be _tomorrow_ before I finish downloading yesterday's updates.
[02:16]  * RAOF thanks OOo and Java for that.
[02:16] <wgrant> Why won't X just stay unbroken?
[02:16] <LimCore> so, I would like to fix the braindeadness in logout funcionality ( https://bugs.launchpad.net/ubuntu/+bug/285141 ) but there are rumors of APIC changes... So, what is now the proper way to have script power.sh executed when ever someone presses power button (the one on PC, not on keyboard)
[02:16] <bryce> wgrant: what fun would that be??
[02:17] <bryce> LimCore: the acpi stuff is sort of in a state of flux
[02:18] <bryce> LimCore: acpi-support is still used for some things, but other stuff is moving towards hal, and pm-utils
[02:18] <wgrant> bryce: True...
[02:18] <wgrant> But I think this might be a clientside change.
[02:18] <wgrant> Hmm.
[02:18] <LimCore> bryce: but I hope, that no matter what system uses, in the end system WILL provide a way to execute user script on common ACPI event like power-off button, right?!
[02:18] <wgrant> Er, serverside.
[02:19] <bryce> LimCore: I haven't had a chance to go through pm-utils and learn the new world order for acpi, so sorry I don't know
[02:19] <LimCore> there should be some  powerdown.d/ directory or something.  And there my patch would go, to fix above bug (to do, so that pressing power button repeataly will turn off pc)
[02:20] <LimCore> *turn off the system
[02:20] <bryce> LimCore: I'd encourage you to review the pm-utils source
[02:20] <LimCore> bryce: I dont have now time for that, unfortunatelly, yet I like to fix the problem.  If I do it using current acpi-support, then can I ask someone to port it to the new way, pack it, and include in 8.10?  current way of logout is realllly brain dead
[02:21] <persia> Looks loosely like they belong under /etc/pm/ somewhere, although one wants to check the implementation before blindly stuffing something there.
[02:21] <Hobbsee> LimCore: is that release critical?
[02:21] <Hobbsee> if not, it won't get done.
[02:21] <LimCore> Hobbsee: yes
[02:22] <LimCore> bad design of logout funcionality leads to fs corruption.  seems horrible to me
[02:22] <Hobbsee> LimCore: provide patches then.
[02:22] <LimCore> I almost lost my fs today, thanks to that
[02:22] <LimCore> Hobbsee: thats what I want to do, and therefore my question.
[02:23] <bryce> LimCore: for intrepid, if you can make it work in acpi-support, porting it to pm-utils should not be necessary
[02:24] <LimCore> bryce: cool, thanks
[02:24] <LimCore> can I implement this in C++?
[02:25] <LimCore> or in C or even bash, this utility must go to base system imho
[02:25] <bryce> LimCore: bash would probably be the only thing likely to get accepted
[02:25] <LimCore> ok
[02:25] <persia> Well, actually, POSIX shell would be preferred to bash, generally.
[02:25] <LimCore> like, /bin/sh ?
[02:25] <bryce> right
[02:26] <persia> /bin/sh means different things for different people, but yes :)  Test with dash.
[02:26] <bryce> acpi-support is currently a mix of bash and sh.  I did convert some simpler stuff to sh
[02:27] <james_w> um, have you tried on an up-to-date Intrepid Ubuntu (GNOME)?
[02:27] <persia> james_w, tried which?
[02:27] <james_w> doesn't pressing the power button show a menu to shutdown, with a 60 second timeout that shuts down the machine?
[02:27]  * Hobbsee notes kde used to support that, too.
[02:27] <Hobbsee> (as in, automatic shutdown when power button is pressed)
[02:28] <persia> james_w, Does for me.
[02:28] <RAOF> james_w: Actually, it shows a logout dialog, not a shutdown dialog (at least here).
[02:28] <persia> RAOF, how updated are you?
[02:28] <james_w> RAOF: are you up to date, it was changed this week.
[02:29] <RAOF> A day or two late.
[02:29] <LimCore> james_w: 60 s is too much.  Plus, the goal is pressing button will also shutdown machine that is partially hanging (i.e. 100% cpu usage)
[02:29] <persia> Might be it.  I got the logout yesterday.
[02:29] <james_w> LimCore: well, that's quit a bit more work.
[02:29] <LimCore> also, it will not work when not in X
[02:29] <LimCore> my idea is simple: system (scripts) react to pressing the power button.  first 1,2,3 times nothing (but WM can react)
[02:30] <LimCore> 4 - shutdown   5 - more aggressive shutdown  etc
[02:30] <LimCore> another use case is to get machine almost hanging by fork bomb
[02:30]  * jdong mumbles Alt-sysrq-REISUB under his breath
[02:30] <Hobbsee> LimCore: if it's partially hanging, or fully hanging, will it really result in the filesystem getting finished properly anyway?
[02:30]  * jdong agrees with Hobbsee 
[02:30]  * LimCore jdong points to his use cases in which lights are out and/or keyboard doesnt work. but yes, this is the goal, only by power button instead
[02:30] <james_w> you want to run a script when the system is being fork-bombed?
[02:30] <persia> In the case of a hang, it doesn't help at all, as it won't trigger acpi-support|pm-utils
[02:31] <jdong> there's no guarantee that the flurry of shutdown scripts will execute correctly if it's fork-bombed
[02:31] <LimCore> ok, perhaps this is not solution for forkbomb use case.   it is for no-keyboard  and no-screen cases
[02:31] <jdong> why is 60s too long?
[02:31] <LimCore> user perhaps wants it off in 10s
[02:32] <LimCore> a) ups will die in 30 s
[02:32]  * persia notes that it would be nice if the 60s didn't count down in 10s increments.
[02:32] <jdong> will the user die if the computer turns off in 60s?
[02:32] <LimCore> b) thunderstorm
[02:32] <LimCore> c) fire
[02:32] <LimCore> etc
[02:32] <jdong> ok those are ridiculously far-fetched usecases.
[02:32] <LimCore> jdong: no, but FS will
[02:32] <Hobbsee> jdong: if you were out drinking, and didn't notice that there was a thunderstorm.
[02:32] <persia> LimCore, It's going to take a while to sync the disks and shut down anyway.
[02:32] <Hobbsee> jdong: until the first boom
[02:32] <Hobbsee> persia: well, that's what I would have thought.
[02:32] <LimCore> persia: that is why waiting 60 is too long.  sync takes 1-3 sec usually
[02:32] <ion_> d) nuclear holocaust
[02:33] <LimCore> jdong: thunderstorm  and   ups die in 30 s  are my own use cases
[02:33] <Hobbsee> ion_: i'm sure that c & d mean that you don't care about the laptop, in that case.
[02:33] <persia> LimCore, How long does it take your machine after you select shutdown from the menu?  Takes me 20-30 seconds.
[02:33] <Hobbsee> or other computer.
[02:33] <jdong> so for that we should make the shutdown button work with less confirmation?
[02:33] <LimCore> persia: correct, this is why 6th press will just  sync and remount ro
[02:33] <jdong> frankly I already think Intrepid has gone off the nazi end for lacking confirmation
[02:33] <jdong> i.e. the logout/restart/shutdown buttons all have no confirmation prompt
[02:33] <Hobbsee> jdong: as long as they *never* become like my work system...
[02:34] <persia> Hobbsee, What's that like?
[02:34] <Hobbsee> jdong: "shutdown".  "OK!  bang!" "oh, shit, another 3+ min wait for it to boot again"
[02:34] <LimCore> jdong: first 3 presses do nothing.  its not like users will press them by accident
[02:34] <Hobbsee> persia: ^
[02:34] <jdong> sync and remount-ro is not any less likely to corrupt your data!
[02:34] <jdong> particularly if it involves some SIGKILLS first
[02:34] <persia> Oh.  I had a configuration like that once.  Very annoying.
[02:34] <bryce> LimCore: hmm, given this is sounding feature-ish, you may find it challenging to get such a thing accepted by the intrepid release team
[02:35] <LimCore> jdong: sync + remount-ro  is not less likelly to corrupt file system, then pulling out the plug?
[02:35] <Hobbsee> bryce: yeah, i can outright decline it now, if you like :)
[02:35] <jdong> and we don't need morse code sequences for the power button... I'd be very much against that idea from a UI perspective.
[02:35] <Hobbsee> but i figured i should at least listen to it first.
[02:35] <bryce> Hobbsee: *nods*
[02:35] <jdong> LimCore: it is not any less likely to corrupt the data, no.
[02:35] <Hobbsee> jdong: ++.  Little kids and computers.  argh.
[02:35] <Hobbsee> arent' filesystems good enough nowadays to handle this stuff, particularly when the machine is locked, anyway?
[02:36] <LimCore> jdong: ok, then unmount, or whatever is needed
[02:36] <jdong> LimCore:  are you listening? interrupting all disk activity via SOFTWARE is no safer than doing the same in HARDWARE.
[02:36] <LimCore> Hobbsee: if you are so sure, you can try right away, especially try with XFS fs
[02:36] <jdong> LimCore: XFS doesn't even remount-ro when you tell it to
[02:36] <jdong> LimCore: nor does it completely sync.
[02:36] <Hobbsee> LimCore: right, well, last I checked, we don't use xfs by default...
[02:37] <jdong> if you are worried about powerdown corruption you shouldn't be anywhere *NEAR* XFS.
[02:37] <jdong> hell XFS makes assumptions about disks that aren't even true except on expensive corporate storage devices.
[02:37] <LimCore> jdong: well, then unmount
[02:37] <jdong> LimCore: how do you propose doing that? :)
[02:38] <LimCore> this is a related problem, it should be more userfriendly to unmount DVD in use etc, is that fixed
[02:38] <Hobbsee> why don't you test it?
[02:38] <LimCore> afair latest gnome finally shows a list why it cant unmount
[02:38] <Hobbsee> actually, last ichecked with a dvd in use, pressing the eject button worked fine.  Maybe tha'ts not user friendly enough for you, i'mnot sure.
[02:38] <LimCore> it could use a button to kill thoes applications.  but that is not critical
[02:39] <jdong> lol no, we shouldn't give users a magical button to kill processes.
[02:39] <jdong> you do that and I will personally write an exploit for it.
[02:39] <Hobbsee> jdong: there already is one, anyway.
[02:39] <Hobbsee> jdong: well, at least, for GUI bits.  in the panel.
[02:39] <Hobbsee> (not on by default, fortunately)
[02:39] <LimCore> why not?
[02:39] <ion_> hobbsee: It should only eject after you hit the eject button five times. :-P
[02:40] <Hobbsee> jdong: it's how i save firefox's state :P
[02:40] <jdong> *sigh* where is desktop Linux going these days...
[02:40] <jdong> LimCore: because it can be used to kill processes maliciously?
[02:40] <Hobbsee> jdong: just be greatful that the ones who tend to make the decisions upstream aren't currently here and talking...
[02:40] <LimCore> ion_: no no, sudo something something ;   ps aux ;  kill -9 etc etc,  is much more user friendly. For humanbeings.
[02:40] <Hobbsee> LimCore: you shouldn't *have* to be force killing anything *at all*.
[02:41] <jdong> you shouldn't be using kill -9 if you care about corruption either.
[02:41] <jdong> I still don't see *ANY* sense in fscking killall -9'ing userland to "unmount the filesystem safely"
[02:41] <jdong> isn't there something counterproductive about doing this? anyone?
[02:41] <Hobbsee> if the program's freezing, it's a bug.  fix the program, instead of making it easier to killthings.
[02:41] <LimCore> jdong: corruption of filesystem -vs- corruption of data in file written by given program because I terminated that
[02:41] <Hobbsee> jdong: sure, but i don't thinkhe'slistening...
[02:41] <jdong> LimCore: your filesystem should not be corrupting when you uncleanly shut down
[02:41] <LimCore> well, Im reading all you say
[02:42] <jdong> LimCore: take that up with your hardware and filesystem vendor.
[02:42] <jdong> namely for XFS this is a hardware problem
[02:42] <jdong> your hardware was obviously not designed to run XFS
[02:43] <LimCore> jdong: I had such corruptions on ext3 as well, but I did not test recently. Still Im quite sure randomly pluging out power cable in middle of writes to ext3 will corrupt more then just the files that where being written to
[02:43]  * jdong thinks hard about why we don't configure to use XFS by default...
[02:43] <jdong> LimCore: it won't corrupt the filesystem but any in-transit data is at risk for being stale or incompletely written.
[02:44] <jdong> and that's *GASP* the same symptoms of killall -9.
[02:44] <LimCore> so you are saying that killing -9 one program is not better then randomly pulling out the plug from pc?
[02:44] <Hobbsee> guys, we have a release soon.  This being discussed now is *not* a release critical bug, and it would be great if these discussions could be held elsewhere.
[02:44]  * jdong agrees with Hobbsee 
[02:45] <jdong> LimCore: depending on what program, absolutely not.
[02:45] <james_w> it would be great if the participants would go and fix RC bugs instead of discussing it :-)
[02:45]  * bryce +1
[02:45] <LimCore> data corruption sounds like RC problem, doesnt it?  With the confirmation box, no need to kill -9 anything
[02:46] <Hobbsee> james_w: that too.
[02:47] <LimCore> so, is it not?
[02:48] <bryce> LimCore: RC bugs are ones targeted | milestoned in launchpad
[02:49] <LimCore> do we want to make some users have to hard reboot their boxes, or do we want to take 2 hours to fix it?
[02:49] <james_w> 2 hours?
[02:49] <elkbuntu> LimCore, i'm not a developer, and not even i can take what you're saying here seriously.
[02:50] <LimCore> elkbuntu: do you have some reasoning for that?
[02:50] <Hobbsee> LimCore: provide the patch, and get it uploaded.  It will then be reviewed.  It may be declined for intrepid, which means you can get it into jaunty.
[02:50] <elkbuntu> LimCore, yes. you're refusing to listen to other people's reasoning.
[02:50] <jdong> yes. what you are saying does not make much sense, you have not provided any valid solutions, and now you are continuing to disobey the requests to keep this channel on topic.
[02:51] <Hobbsee> LimCore: unless you do this, no it will not be considered, and the discussions will not continue here.
[02:51] <LimCore> elkbuntu: I responded to all arguments so far.  Ok, which channel is on topic for this then?
[02:52] <elkbuntu> LimCore, responding does not mean you listened properly.
[02:55] <slangasek> apachelogger: how does it happen that a patch that's been in kde4libs for a year was responsible for bugs just filed?
[02:55] <slangasek> (in the past two months, that is)
[02:56]  * Hobbsee eyes that kdebase-workspace upload
[02:57] <slangasek> Hobbsee: yes, I skipped over that one in the queue
[02:57] <apachelogger> slangasek: the one about kmenuedit wasn't visible in KDE 4.0, because there was no visible way to start the editor at all
[02:58] <apachelogger> I am not sure why he broken icons one isn't older though, TBH bug reports for KDE 4 are really rare still
[02:58] <apachelogger> s/he/the
[02:58] <Hobbsee> slangasek: i don't think it's right, either.
[02:59] <apachelogger> Hobbsee: what's it changing?
[02:59] <Hobbsee> apachelogger: well, it's bumping an unsatisfiable recommends to an unsatisfiable suggests, to start with.
[03:00] <NCommander> StevenK, hola
[03:00] <apachelogger> Hobbsee: python-plasma-examples is available here
[03:00] <Hobbsee> apachelogger: in what repository?
[03:01] <apachelogger> Origin: Ubuntu
[03:01] <Hobbsee> apachelogger: (apt-get policy  python-plasma-examples)
[03:01] <apachelogger>         500 http://archive.ubuntu.com intrepid/main Packages
[03:02] <Hobbsee> apachelogger: hmmmm, i'll try updating again, but my apt-cache isn't finding it.
[03:03] <apachelogger> Hobbsee: kdebase-workspace is actually the source package for python-plasma-examples
[03:04] <Hobbsee> apachelogger: ah.  wonder why it refused to find it previously.  p.u.c doesn't know about it either yet
[03:05] <apachelogger> https://edge.launchpad.net/ubuntu/intrepid/i386/python-plasma-examples/4:4.1.2-0ubuntu10
[03:05] <apachelogger> Hobbsee: puc is not the fastest ;-)
[03:06] <apachelogger> very weird either way though
[03:07] <Hobbsee> apachelogger: ahh.  so itis new.
[03:08] <apachelogger> pretty much
[03:09] <Hobbsee> slangasek: if we're not building cds yet, then i presume that one's safe.
[03:14] <slangasek> Hobbsee: kdebase-workspace?  If you think it's appropriate, feel free to push it through
[03:14] <Hobbsee> slangasek: OK
[03:15] <Hobbsee> slangasek: i'm just not sure of cd building status.
[03:16] <slangasek> CDs on Monday
[03:16] <Hobbsee> right.
[03:28] <Hobbsee> mdke: was ubuntu-docs going to get updated before release?
[03:28] <nixternal> he is probably sleeping
[03:30] <Hobbsee> nixternal: that's a point.  it's been updated in the bzr branch, but never got uploaded.
[03:30] <nixternal> actually, the final upload of ubuntu-docs will be for translations only
[03:31] <nixternal> and that typically happens like, damn right now
[03:31] <Hobbsee> nixternal: https://bugs.edge.launchpad.net/ubuntu/intrepid/+source/ubuntu-docs/+bug/272772 too, preferably.  it's RC.
[03:31] <nixternal> ya, I just saw that
[03:32] <nixternal> ubuntu-docs shouldn't depend/recommend/suggest firefox as they aren't built to HTML, they stick in DocBook/XML format for ubuntu-docs
[03:32] <nixternal> unless something has changed
[03:32] <Hobbsee> nixternal: ubuntu-serverguide does
[03:32] <nixternal> ahhh
[03:32] <nixternal> does it dep on www-browser?
[03:33] <nixternal> www-browser | x-www-browser or whatever it is
[03:33] <nixternal> haven't looked in a while to be honest
[03:33]  * nixternal looks
[03:33] <Hobbsee> nixternal: not on my sysetm.
[03:33] <nixternal> looking now
[03:33] <Hobbsee> Suggests: firefox
[03:34] <nixternal> hrmm, that is nuts
[03:34] <nixternal> should just recommend either www-browser | x-www-browser, not a specific browser
[03:34] <Hobbsee> oh,score, Keybuk's tracking down this iwl3945 bug for us!
[03:34] <nixternal> what is the bug?
[03:34] <Hobbsee> nixternal: well, yes.
[03:34] <Hobbsee> nixternal: the one above?
[03:34] <Hobbsee> or the iwl?
[03:35] <nixternal> 0c:00.0 Network controller: Intel Corporation PRO/Wireless 3945ABG [Golan] Network Connection (rev
[03:35] <nixternal> mine has worked great actually, but then again I don't use it all that much
[03:35] <Hobbsee> nixternal: boot hang bug - https://bugs.edge.launchpad.net/ubuntu/intrepid/+source/linux/+bug/263059
[03:38] <nixternal> Hobbsee: yes, mdke fixed ubuntu-docs in bzr by suggesting www-browser ....
[03:38] <Hobbsee> nixternal: right, yes, I see that in the bug, but it's not in the archive yet :)
[03:38] <nixternal> Hobbsee: looks like he is currently importing translations
[03:38] <Hobbsee> nixternal: oh, so that's related.  right.
[03:39] <nixternal> not related, but he will probably prepare the package shortly and get it uploaded
[03:39] <Hobbsee> ah, cool.
[03:39] <nixternal> he has been highlighted enough, he will update us in the next 12 or so hours I am sure :)
[03:59]  * calc back, and got his hair chopped off
[04:08] <calc> slangasek: thanks wrt 223476
[04:08] <calc> slangasek: i'm pretty sure i brought that bug up before but it was several months ago
[04:09] <calc> slangasek: and we were already too low on space at the time
[04:09]  * Hobbsee kills more bugs off the intrepid list.
[04:10] <nixternal> kill kill kill
[04:13]  * calc is getting rid of his bugmail queue
[04:13]  * nixternal is trying
[04:23] <calc> gar, new vmware installs into /usr without asking you
[04:23] <calc> it should at least into /opt if not /usr/local
[04:26] <lifeless> the FHS is for other people
[04:27] <Hobbsee> sbeattie: were you planning to provide a patch for https://bugs.edge.launchpad.net/ubuntu/+source/djvulibre/+bug/277301?
[04:31] <calc> lifeless: until 6.5 it asked where you wanted to install it
[04:33] <calc> well it is a lot simpler install, but too simple i think since it installs into an illegal (for 3rd party) location :\
[04:38] <Hobbsee> calc: 223476 should probably be fix committed / fix released - i accepted the u-m upload to add -math to the seeds.
[04:39]  * NCommander is finally free from classwork!
[04:41] <Hobbsee> NCommander: yay!  so, fix some bugs!
[04:41] <calc> Hobbsee: cool :)
[04:41] <NCommander> Hobbsee, working on fixing lpia's kernel ;-)
[04:41] <Hobbsee> NCommander: that's good too :)
[04:42] <calc> Hobbsee: done, i added it to hardy as well on the bug report to have it examined when i get a chance
[04:43] <lifeless> calc: I was being droll
[04:43] <Hobbsee> calc: \o/
[04:45] <calc> lifeless: i know, i just wanted to rant about it since it is really annoying :\
[04:45]  * lifeless hands calc a blog
[04:46] <calc> heh :)
[04:46] <lifeless> (it is ontopic here, just saying, a good rant deserves an audience)
[04:47] <calc> yea
[04:47] <calc> i haven't had a blog in several years, i probably should set one up again
[04:48] <NCommander> calc, join the planet
[04:51] <StevenK> NCommander: Hey hey
[04:51] <NCommander> StevenK, so amitk broke the lpia build ;-)
[04:51] <NCommander> (he forgot to bump the abi folder name)
[04:51] <StevenK> Argh
[04:51] <NCommander> Yeah
[04:51] <NCommander> I'm getting closer to nailing this
[04:52] <NCommander> Almost everything is getting built now, but I'm debating if I should move the binary-indep rules to binary-arch
[04:52] <NCommander> (since the lpia kernel strictly speaking has no arch all packages)
[04:52] <StevenK> Right
[04:52] <StevenK> Personally, do whatever makes the diff smaller
[04:52] <StevenK> amitk might feel differently
[04:53] <NCommander> Well, that would technically make the diff get larger, but having binary-indep called from binary-arch shouts hack
[04:53] <StevenK> "Duh"
[04:54] <calc> launchpad should host blogs :)
[04:54] <calc> it does everything else already, heh
[04:54] <Hobbsee> calc: erk.
[04:54] <StevenK> Yes, "Erk"
[04:56] <NCommander> calc, SourceForge has that feature even
[04:58]  * calc wonders why up arrow in vmware 6.5 causes printscreen
[05:02] <NCommander> StevenK, WOOO< success!
[05:02] <StevenK> Woot
[05:02] <NCommander> dpkg-deb: building package `linux-headers-2.6.27-4-lpiacompat' in `../linux-headers-2.6.27-4-lpiacompat_2.6.27-4.8_lpia.deb'.
[05:02] <[reed]> calc: 8.10 remapped all my keybindings on my thinkpad
[05:02] <NCommander> Need to go through and make sure everything actually worked sanely
[05:02] <[reed]> I wasn't happy at all
[05:02] <[reed]> considering they are all wrong
[05:03] <[reed]> and like three different random buttons now printscreen instead
[05:03] <NCommander> StevenK, I can upload this to a PPA, and then smoke test lpia-lrm/lpia-meta
[05:06] <NCommander> StevenK, second woo moment, it appears at first glance the linux-lpia-headers packages are also properly working
[05:06] <NCommander> dh_installchangelogs: I have no package to build
[05:06] <StevenK> NCommander: To be honest, don't bother with a PPA
[05:06] <NCommander> That however I'm still figuring out
[05:06] <StevenK> NCommander: I just want it in the archive
[05:07] <NCommander> Find someone who can commit to the git tree :-)
[05:09] <StevenK> NCommander: It's more to be in the archive than the git tree at this point, given where we are in the release
[05:09] <StevenK> more important
[05:10] <NCommander> StevenK, well, right now, I'm ripping the rules a new one
[05:10] <NCommander> THe actual debs are not being built because the debhelper magic is screwed up
[05:10] <NCommander> So give me some time to finish twisting the rules into submission (everything is getting built which is a good thing)
[05:12] <NCommander> and since I just need to rerun the install phase over and over, its not that time consuming
[05:13] <NCommander> ^- StevenK
[05:13] <StevenK> Fair enough
[05:14] <NCommander> It will probably take me an hour or so to get this properly locked down (an install run takes about 10 minutes), and then I would like to do a full build run if you can tolerate it ;-)
[05:19] <StevenK> I'd like to upload before I have to leave at 4:45pm local
[05:22] <NCommander> StevenK, how long is that?
[05:22] <StevenK> NCommander: An hour and change away
[05:22] <wgrant> 1.5 hours.
[05:27] <NCommander> StevenK, its building packages, I'll post the list once it finishs so we can make sure all the necesities are there
[05:52] <NCommander> -rw-r--r-- 1 root root 556K 2008-10-18 00:41 linux-headers-2.6.27-4-lpia_2.6.27-4.8_lpia.deb
[05:52] <NCommander> getting closer
[05:54] <StevenK> We knew that one built
[05:54] <StevenK> linux-lpia-headers-2.6.27-4 is the question mark
[05:57] <NCommander> StevenK, the files weren't getting loaded into it
[05:57] <NCommander> (I just fixed that)
[05:58] <NCommander> (the important thing is dpkg -c actually listed stuff :_-))
[05:58] <NCommander> *:-)
[05:59] <NCommander> -rw-r--r-- 1 root root 5.6M 2008-10-18 00:58 linux-lpia-headers-2.6.27-4_2.6.27-4.8_lpia.deb
[05:59] <NCommander> \o/!
[06:00]  * NCommander needs to clean and make sure allt he files still end up in the right places however
[06:02] <NCommander> StevenK, all the packages aside from the -debug ones seem to get built, but I need to do a full build run to make sure all the files are properly ending up int he right place
[06:03]  * NCommander however saves the debian/build directory so the kernels themselves do not need to be recompiled
[06:59] <StevenK> NCommander: Still building?
[06:59] <NCommander> StevenK, well, I had to restart it because of a bug
[07:00]  * NCommander got the build script stuck in an endless loop <g>
[07:00] <StevenK> Woot
[07:00] <StevenK> NCommander: I'll be leaving in a few, can you mail me the debdiff?
[07:00] <slangasek> calc: well, it was never nominated for intrepid until now... :)
[07:00] <NCommander> However, I did get a proper linux-headers and linux-lpia-headers package it seems
[07:00] <slangasek> calc: anyway, we'll see if it fits :)
[07:21] <Mez> anyone here know lots of linker voodoo ?
[07:22]  * Mez needs some help with a question from his Debian NM thing, and I REALLY don't know the answer (and can't find much, and man gives a horrible explanation)
[07:27] <NCommander> Mez, depends on what sorta voodoo
[07:27] <Mez> NCommander: an explanation of ld's -Bsymbolic?
[07:27] <NCommander> That's usually a bonus question
[07:27] <NCommander> Are you sure you have to answer it?
[07:34] <slangasek> Mez: the explanation in ld(1) is complete, as far as it goes; what part is confusing?
[07:35] <slangasek> it's true that this is a bonus question; it's certainly not the question I would ask about library linkage if I'd written those templates :P
[07:37] <Mez> slangasek: It's evil... though - ld confused me a little as I wasn't reading the right bit of the man page explanation
[07:37] <Mez> slangasek: "Bonus" Question ?
[07:38] <slangasek> Mez: being able to answer the question correctly has no real bearing on your NM application
[07:39] <Mez> slangasek: o_O ok... *confused* wasn't aware of that, but have managed to find a better explanation now
[07:40] <NCommander> slangasek, the T&S bonus questions though are useful, the AM_MAINTAINER_MODE is handy for someone who hasn't heard of it before
[07:40] <slangasek> I happen to find the current written test approach to NM distasteful in general, and fundamentally, the lack of a support structure for a more skills-oriented NM process was a big reason why I failed at being an AM
[07:41] <lifeless> NM is broken
[07:41] <slangasek> news at 11
[07:41] <wgrant> I'm not sure that NM is more broken than our process.
[07:41] <Mez> slangasek: Indeed, a more skills oriented approach would be nice (like in Ubuntu) ... but... *shrugs*
[07:41] <lifeless> wgrant: its way more broken
[07:41] <NCommander> slangasek, I personally learned a lot during NM
[07:42] <Mez> NCommander: so have I ;)
[07:42] <lifeless> NCommander: thats to your credits, not the NM process' credit
[07:42] <NCommander> slangasek, so its not completely useless, and for the one or two questions I did get stuck on, my AM was extremely helpful
[07:42] <Mez> NCommander: yeah, my AM has been extremely helpful too ;)
[07:42] <Mez> if a little pedantic ;)
[07:43] <NCommander> Well, I feel the P&P test is extremely useful for those unexposed to licensing issues, but for T&S, I think I would perfer something more hands on
[07:43] <slangasek> NCommander: that's fine; but it ought to be "here's some stuff you should digest, ask me if you don't understand something, now here's a handful of random questions about it, ok now let's see what you're actually *doing*"
[07:44] <slangasek> wgrant: NM doesn't do a good job of selecting for the things it should
[07:44] <Mez> slangasek: don't they actually check your packages etc though?
[07:44] <NCommander> slangasek, well, my biggest concern with NM is two fold, is that the length of the process is insane, and for people who are porters (or do things beside packaging as a main task), its completely lopsided
[07:45] <slangasek> wgrant: too much of it is a test of one's tolerance for paperwork and sitting alone in a cold waiting room waiting to be called in for your interview
[07:45] <NCommander> It's meant for people who package pretty much exclusively. Even my AM admitted its not well suited to people who are pretty much porting vs. packaging
[07:45] <wgrant> slangasek: Right, and it's particularly fun when your AM vanishes.
[07:46] <Mez> wgrant: haha, I'm lucky and havent had that happen yet, though it's part of the reason I wouldn't become an AM at the moment. I have a tendency for doing that ;)
[07:46] <slangasek> Mez: yes, but the package checks are pretty weak; they amount to "can the AM find bugs in your package?" when it should be "can the NM find bugs in this package and fix them?"
[07:46] <wgrant> Mez: white is your AM, isn't he?
[07:47] <Mez> slangasek: I thought that part of the process was going and fixing RC bugs/other bugs
[07:47] <NCommander> slangasek & wgrant: that just happened to me
[07:47] <Mez> (and I've been told to do QA uploads too)
[07:47] <Mez> wgrant: yes... you stalking me ? :P
[07:47]  * NCommander is considering applying for DM status so I can help with pkg-xfce without constantly stalking for uploads
[07:47] <wgrant> Mez: Heh. Maybe.
[07:47] <slangasek> Mez: "find one RC bug and fix it" is, IMHO, an insufficiently high bar for DDship on a point that counts
[07:47] <slangasek> we have high bars in the wrong places
[07:48] <NCommander> slangasek, well, looking at debian-qa, there are very few people who are seemingly working on RC issues if the package maintainer hasn't tackled it already
[07:48] <Mez> slangasek: I've been told at least 2 and a couple of important or higher
[07:48] <slangasek> NCommander: why are you expecting to see evidence of this on debian-qa...?
[07:49] <NCommander> Most of the work on solving RC bugs is split up between #debian-qa and #debian-devel on IRC
[07:49] <NCommander> ^seems to me
[07:50] <slangasek> debian-qa has always focused on unmaintained packages; that's the last place I would expect to see folks holding a Bsp
[07:50] <slangasek> SP
[07:52] <NCommander> well, the bug count is going down slowly. It was over 200 a few days ago as lenny gets closer and closer to release
[07:56] <Mez> slangasek: so where are the high bars that shouldn't be there, and where should the high bars be?
[07:58] <slangasek> Mez: the long written test for T&S shouldn't be there; it should be reduced to a random scattering of questions per applicant.  And there should be higher bars for demonstrating functional knowledge and involvement, including being able to fix an artificially broken package, and demonstrate a record of healthy contribution to Debian (which definitely does /not/ mean having a pet package in the archive).
[07:58] <Mez> slangasek: multiple pet packages ? :P
[07:58] <slangasek> heh
[07:59] <slangasek> a pet desktop environment
[07:59] <Mez> slangasek: what about evil non-free stuff taken over from someone else, but that people seem to want to use for some unknown reason?
[07:59] <slangasek> sure, that's ok... if I were the AM, I would quiz someone extra hard about the DFSG if that was their only package, though :)
[08:00] <Mez> slangasek: I probably don't pass on your score then ;)
[08:00] <Mez> http://qa.debian.org/developer.php?login=mez@ubuntu.com
 looks fine to me. :)
[08:02] <slangasek> you have three pet packages, *plus* non-free packages, so. :-)
[08:05] <Mez> slangasek: I wouldnt exactly call symfony a "pet" package atm ;)
[08:05] <Mez> It's annoying the heck outta me... and upstream need a good slap ;)
[08:05] <slangasek> there are people who keep chihuahuas as pets
[08:06] <Mez> slangasek: ;)
[08:07] <Mez> good analogy.
[08:07]  * Mez is going to have to get the word "chihuahua" in the changelog now somehow
[08:29] <NCommander> Mez, O_o;
[08:38] <bryce> slangasek: fix for 283921 uploaded and ready for review.  I've promoted it to be an RC bug because its inhibiting input-hotplug configuration from working.
[08:38] <bryce> slangasek: it's just a one line fix, but took wgrant an appreciable amount of the day to debug it.
[08:40] <bryce> slangasek: he's also identified all the packages that depend on that header and will be putting in builds for each.  I've reviewed all this and it looks correct.
[08:40] <NCommander> cjwatson, are there lpia CDs?
[08:41] <bryce> NCommander: not afaik
[08:41] <NCommander> How can it be installed?
[08:41] <wgrant> Of course upstream had to fix it just a couple of hours after I had the first part uploaded...
[08:41]  * NCommander has a friend who has an atom board, and has great interest in lpia
[08:41] <bryce> NCommander: when I've done it, I've gotten a USB iso image, put it on a USB stick, and booted from that
[08:41] <slangasek> bryce, wgrant: accepted; how many packages are we looking at for needing rebuilds?
[08:41] <NCommander> bryce, where can I find that?
[08:42] <bryce> slangasek: 7, listed on 283921
[08:42] <wgrant> Isn't x11proto-input one of the 7?
[08:42]  * wgrant counts.
[08:42] <slangasek> bryce: bleurgh
[08:42] <bryce> ok 6
[08:43] <bryce> slangasek: huh, I hadn't heard ack pronounced that way before
[08:43] <wgrant> Heh.
[08:43] <slangasek> will these all get uploaded over the weekend, so as to not block CD builds come Monday?
[08:43] <bryce> yes
[08:43] <slangasek> ok
[08:43] <wgrant> They're trivial rebuilds, so I don't see why not.
[08:43] <slangasek> just making it clear :)
[08:44] <wgrant> They only depend on x11proto-input-dev being published.
[08:44] <wgrant> Sure.
[08:44] <bryce> only fair :-)
[08:44] <NCommander> bryce, bah, my friend will be disappointed by the lack of lpia installability
[08:45] <bryce> NCommander: well, really you should talk to the UME guys directly.  There's a ubuntu-mobile mailing list that's the best place to ask
[08:45] <slangasek> NCommander: he could install i386 instead and pretend lpia doesn't exist?
[08:45] <bryce> I've not done an install in some time, so my knowledge is dated.
[08:46] <wgrant> lpia has some nasty MID-specific patches... it should probably be avoided.
[08:46] <NCommander> slangasek, he could, but lpia is compiled for atom ... ah
[08:46] <maco> wgrant: any chance bug 278418 was intentional?  i personally find the similarity of the icons confusing, but crimsun says it might have been on purpose
[08:46] <persia> NCommander, There is an lpia alternate CD, and a MID live environment.
[08:46] <NCommander> persia, where's the later
[08:46] <persia> wgrant, It should work fine for Kubuntu.
[08:46] <wgrant> maco: They're very different styles, so I doubt it...
[08:46] <persia> NCommander, http://cdimage.ubuntu.com/ubuntu-mid/intrepid/current/
[08:47] <maco> ugh, he says i have bad quoting because "no idea if it was on purpose" is totally not the same thing as "might have been on purpose" though i dont understand the difference...
[08:47] <wgrant> Heh.
[08:47] <wgrant> One just implies a slightly different magnitude of suggestion, I guess.
[08:48] <maco> my interpretation was "*shrug*"
[08:49] <NCommander> persia, I think I got the LPIA kernel fixed
[08:50] <persia> NCommander, Cool.  It builds cleanly now?
[08:50] <NCommander> persia, and it generates proper header packages
[08:50] <NCommander> ;-)
[08:50] <persia> Is it still -4 ?
[08:50] <NCommander> Yup
[08:50] <NCommander> (-4.8 now)
[08:50] <NCommander> BUt yeah
[08:50] <persia> Excellent.
[08:50] <NCommander> No ABI changes
[08:50] <persia> Anyone feel like uploading a kernel?
[08:51] <NCommander> I did give the rules file a lobotomy
[08:51] <persia> It probably needed it.
[08:51] <NCommander> I actually wanted to make more changes
[08:51] <NCommander> (its a rather nasty hack at the moment)
[08:51] <NCommander> But that can wait for jaunty
[08:51] <persia> How nasty?  Will it break on SRU?
[08:51] <NCommander> It sorta fails the builds in a sane way test now, binary-indep is called from binary-arch
[08:52] <NCommander> since lpia kernels aren't built at all on x86 to generate the meta packages
[08:52] <persia> See, the details are unpleasant, offensive, and likely wrong ...
[08:52] <persia> Will it break on SRU?
[08:52] <NCommander> Oh
[08:52] <NCommander> No
[08:52] <persia> OK.  Then it needs uploading :)
[08:53]  * NCommander couldn't see how a rules change could break SRUs ...)
[08:53] <persia> Well, it's possible to create a rules file that works until it's been used to compile the package on the buildds.
[08:53] <NCommander> I tested an earlier version of this package in my PPA
[08:53] <persia> Such a file would then break if the package was included in the archive, and it was rerun.
[08:54] <NCommander> (that one had a few bugs which have been since exercised)
[08:54] <NCommander> it built without issues
[08:54] <persia> Next step is testing on HW?
[08:54] <NCommander> you mean an actual lpia machine?
[08:54] <NCommander> Yeah
[08:54] <persia> That, or use the lpia-compat flavour if you don't have an i686 available.
[08:54] <NCommander> I have an i686
[08:55] <NCommander> So you want make to make sure the kernel boots
[08:55] <NCommander> It would be lovely if I could install the packages, but I'm arch amd64, not arch i386 :-/
[08:55] <persia> Well, that's a bonus :)
[08:55] <persia> Should work in kvm if you can do that.
[08:56] <NCommander> Well, I'm waiting for a final build run to finish
[08:56] <NCommander> With debug packages, docs, and sources generated
[08:56] <NCommander> (I fixed everything with the rules evil ;-))
[08:56] <persia> This one is expected to finish?
[08:56] <NCommander> I've already built it before
[08:56] <NCommander> But without the debug kernel
[08:57] <NCommander> I also just need to make sure files are ending up in the right places (since we've never built headers out of the lpia)
[08:57] <NCommander> persia, do you have a kernel.u.c account?
[08:57] <NCommander> (I have git patches)
[08:57] <persia> No.  Just send them to amitk.
[08:57] <NCommander> works for me ;-)
[08:58] <NCommander> persia, its a LARGE debdiff because a folder has to be renamed
[08:58] <persia> Just a folder under debian/ right?
[08:58] <NCommander> yeah
[08:58] <NCommander> the abi folder needed a version bump
[08:58] <persia> OK.  No worries.  That part is the part that kernel developers don't like to change.
[08:58] <NCommander> There are no source changes
[08:59] <NCommander> and the ABI check confirms nothing changed
[08:59] <NCommander> the lpia-lrm and meta packages *should* just compile out of the box once this available
[08:59] <wgrant> Won't they need build-dep changes for the new header name?
[08:59] <maco> ABI check? is there documentation somewhere i can read about that? i didnt know there was some automated way to find out if the kernel ABI was changing
[09:00] <persia> maco, There's a script in the kernel source packages.
[09:00] <wgrant> maco: It is perhaps the hardest part of building a custom kernel. It's nasty.
[09:00] <NCommander> wgrant, no, there is a provides linux-headers, so it should in theory just do the right thing if I follow StevenK right
[09:00] <NCommander> If not, then I can kick off the packages
[09:00] <NCommander> Ok, all the udebs built
[09:00] <persia> wgrant, They got those in the last upload, which then promptly FTBFS because they weren't built.
[09:00] <NCommander> persia, you must be happy this got fixed ;-)
[09:01] <NCommander> persia, what was the last linux-lpia package to be uploaded? (packages.u.c is giving me issues)
[09:01] <maco> persia, wgrant thanks
[09:01] <persia> NCommander, p.u.c is not a reliable way to check anyway.
[09:01] <NCommander> an earlier version of my patch landed in git (it wasn't finished testing when it got committed, and the repo was tagged)
[09:02] <NCommander> I'm not sure if that package was uploaded or not
[09:02] <persia> NCommander, https://launchpad.net/ubuntu/+source/linux-lpia
[09:03] <NCommander> persia, ok, that makes life easier, I'll have amitk simply pop off the patch in git, and pop mine in place, which will get everything synced up :-)
[09:05] <NCommander> Err http://us.archive.ubuntu.com intrepid/main linux-lpia 2.6.27-4.7 (dsc)
[09:05] <NCommander>   Could not open file linux-lpia_2.6.27-4.7.dsc - open (13 Permission denied) [IP: 91.189.88.31 80]
[09:05] <NCommander> Uhhhhhhhhh
[09:05] <NCommander> WTF
[09:05] <NCommander> oh wait
[09:12] <amitk> NCommander: you got something for me?
[09:12] <NCommander> amitk, I got the build fixed
[09:12] <amitk> splendid
[09:12]  * NCommander is waiting for one last build run to finish
[09:12] <NCommander> its builiding linux-lpia-source ;-)
[09:12] <NCommander> It just finished linux-lpia-doc :-)
[09:18] <NCommander> amitk, here, I got the patch, its still building (my HDD is thrashing ATM so ... :-/)
[09:21] <NCommander> persia, http://paste.ubuntu.com/59191/ - kernel patch, I can have a debdiff in a few minutes
[09:22] <persia> amitk, ^^
[09:22] <NCommander> ;-)
[09:22] <NCommander> My laptop sucks
[09:22] <NCommander> I dunno why its taking forever to build the source package
[09:22] <NCommander> and to whoever uploaded the package
[09:22] <NCommander> PLEASE, upload a .orig.tar.gz
[09:22] <NCommander> s/uploaded/uploads
[09:23] <amitk> persia: NCommander: reworking this into git and recreating a diff.gz now. Give me 20mins
[09:23] <NCommander> amitk, give me upload credit this time :-) *shot!*
[09:24] <NCommander> amitk, so I take it your the lpia kernel guy?
[09:29] <lool> moving from linux-lpia-headers to linux-headers hmm
[09:30] <NCommander> lool, its consistant with linux-ports
[09:30]  * lool refuses to ponder on the usefulness of having a separate source if we don't have separate headers
[09:31] <lool> Whatever fixes the installability :)
[09:33] <NCommander> lool, we do
[09:33] <NCommander> lool, 2.6.27-4.8-lpia(compat)
[09:33] <persia> lool, binary package name has no relation to contents.
[09:33] <amitk> NCommander: I did give you credit in git. Do you want to do the deb diff?
[09:34] <NCommander> amitk, I was referring to upload credit ;-)
[09:34] <NCommander> Yeah
[09:34] <NCommander> I was doing that now
[09:34] <amitk> NCommander: go ahead
[09:34] <NCommander> I was just making sure the headers came out in the right place
[09:34] <NCommander> http://pastebin.ca/1230022 - there we go!
[09:36] <amitk> persia: ^
[09:36] <amitk> looks ok to me
[09:37] <persia> lool, ^^
[09:53] <amitk_> NCommander: how are we doing? upgrade killed my network...
[09:53] <NCommander> amitk, got a debdiff
[09:54] <NCommander> amitk_, someone needs to test the resulting kernel to make sure it works, and as an added bonus, the header packages are all installable and usable
[09:54] <amitk_> NCommander: your patch doesn't apply cleanly - lots of trailing CRs and a reject
[09:55] <amitk_> I wonder if the first part is pastebin's doing
[09:55] <NCommander> amitk, might be
[09:55] <NCommander> Hold on, let me just fire you an email
[09:56] <NCommander> amitk, you got mail
[09:58]  * amitk_ back from breakfast in 15
[10:22] <amitk_> NCommander: did you create the patch against the existing patch in git or against -4.7?
[10:22] <NCommander> The git patch I sent you was against git, the debdiff was against 4.7
[10:22] <amitk_> ahh
[10:42] <elmo> hmm
[10:43] <elmo> if, in a postinst, I'm starting an initscript that depends on ldconfig actually being run rather than triggered; what's the BP way to do that? just setting LDCONFIG_NOTRIGGER to something?
[10:48] <elmo> also, is there a better way than /etc/modules to get a module permanently installed, from a packaging POV
[10:48] <persia> elmo, In the one case where I encountered a package like that, I just called ldconfig.real in the postinst.  Best practice is probably to separate libraries from daemons so you never have to do that.
[10:49] <elmo> persia: I'm not sure that would help?  there's no guarante the trigger would have run by the time the daemon's package's postinst comes to run?
[10:49] <elmo> oh, duh, yeah there is.  don't mind me
[10:51] <elmo> persia: ta
[10:52] <NCommander> amitk_, the kernel smoke test works!
[10:52] <NCommander> amitk_, I'm testing to see if I can build modules against the headers
[10:56] <NCommander> persia, do you have a core-dev who can upload?
[10:57] <persia> lool, care to upload linux-lpia ?
[10:58] <elmo> next stupid question: why doesn't libc6-i686 include a ld.so.conf.d/ for */lib32/ ?
[10:58] <NCommander> persia, forget it for the moment
[10:58] <NCommander> persia, I caught a bug in the headers package
[10:59] <NCommander> One of the headers came out in /usr/src/linux-lpia-headers by accident
[10:59] <Hobbsee> bryce: not to pressure you, but will xserver-xorg-input-evdev appear soonish in the queue?
[10:59] <Hobbsee> OTOH, the buildds just got langpack'd, so you've got time..
[10:59] <amitk_> NCommander: I've folded in your latest patch with your previous one and pushed to git
[10:59] <NCommander> amitk_, d'oh
[10:59] <NCommander> (we just caught a bug)
[11:00] <NCommander> indep_hdrpkg = linux-lpia-headers-$(abi_release)
[11:00] <NCommander> indep_hdrdir = $(CURDIR)/debian/$(indep_hdrpkg)/usr/src/$(indep_hdrpkg)
[11:00] <NCommander> Two points to anyone who can see the bug :-)
[11:01]  * NCommander does note we're making progress here
[11:02] <persia> NCommander, You forgot a : ?
[11:02] <NCommander> No
[11:03] <NCommander> it needs to be usr/src/linux-headers-$(abi_release)
[11:03] <NCommander> or module-assistant can't find the headers
[11:03] <NCommander> (they came out in /usr/src/linux-lpia-headers)
[11:03] <persia> Ah.  I see.
[11:03] <wgrant> Hobbsee: bryce advised me that all of my rebuilds were uploaded, and he went to bed some time ago.
[11:04] <NCommander> persia, its just a minor oversight, so I just need to rebuild the kernel, and test in two/three hours
[11:04] <cjwatson> wgrant: bryce uploaded evdev to hardy by mistake ...
[11:04] <cjwatson> so somebody will need to fix that and reupload
[11:04] <Hobbsee> cjwatson: ah, was *that* the problem.
[11:04] <wgrant> cjwatson: Ah, that would do it.
[11:04] <cjwatson> same happened to xserver-xorg-video-intel
[11:04] <wgrant> Did the others go there?
[11:05] <wgrant> I'm no core-dev, so somebody else will need to do it.
[11:05] <cjwatson> the rest are in unapproved
[11:05] <Hobbsee> no
[11:05] <cjwatson> bryce: ^-
[11:05] <Hobbsee> cjwatson: were
[11:05] <cjwatson> :-)
[11:05] <NCommander> StevenK, ping
[11:05] <wgrant> 19:58:13 < bryce> ok, I'm too tired.  --> bed.  night
[11:05] <Hobbsee> -intel wasn't in the list of rebuilds..
[11:05] <mdke> Hobbsee: yes, ubuntu-docs will need a translations update which I'm aiming to do by thursday
[11:05] <cjwatson> intel was a different upload
[11:05] <wgrant> Hobbsee: Indeed, it wasn't relevant.
[11:05] <cjwatson> 2008-10-18 01:05:07 DEBUG     * 27_disable_fbc_on_965.patch:
[11:05] <cjwatson> 2008-10-18 01:05:07 DEBUG       - Works around issue where flash videos freeze after playing for a few
[11:05] <amitk_> NCommander: so it should be indep_hdrpkg = linux-lpia-headers ?
[11:05] <cjwatson> 2008-10-18 01:05:07 DEBUG         moments on i965 chipset, by disabling Frame Buffer Compression, which
[11:05] <cjwatson> 2008-10-18 01:05:07 DEBUG         is not working reliably on this chipset.  It can be re-enabled via the
[11:05] <cjwatson> 2008-10-18 01:05:07 DEBUG         FrameBufferCompression option for testing purposes.
[11:05] <Hobbsee> cjwatson: ah, right.  actually, That was in intrepid too.
[11:05] <cjwatson> ah, ok, I didn't check
[11:06] <cjwatson> right, really gone now
[11:06] <Hobbsee> mdke: cool
[11:06] <Hobbsee> cjwatson: cya!
[11:06] <Hobbsee> wgrant: if you put it somewhere, i can sponsor it.
[11:06] <Hobbsee> we won't discuss who then goes on to accept it
[11:06] <mdke> Hobbsee: the www-browser update for ubuntu-serverguide will go in at the same tim, unless you desperately need it earlier
[11:07] <wgrant> Hobbsee: It's a trivial rebuild - it's probably more work for you to apply a debdiff. But if you want me to, I'll do it.
[11:12] <Hobbsee> mdke: not really.  just hope it gets done.
[11:12] <Hobbsee> wgrant: sorry, that's what i meant
[11:12] <mdke> Hobbsee: well, it is done.
[11:13] <Hobbsee> mdke: ok, cool
[11:13] <wgrant> Hobbsee: You want a debdiff?
[11:13] <Hobbsee> wgrant: yeah, why not :)
[11:13] <wgrant> Hobbsee: Sure, give me a sec.
[11:16] <wgrant> Hobbsee: http://www.qeuni.net/f/1/2008/evdev.diff
[11:21] <Hobbsee> wgrant: thanks, got it
[11:22] <StevenK> NCommander?
[11:23] <NCommander> StevenK, 90% success
[11:23] <StevenK> NCommander: 90%?
[11:23] <NCommander> StevenK, we got the headers and sources packages building and installable
[11:23] <NCommander> StevenK, but one bit of the headers ended up int he wrong place when the package was installed (would break lpia-lrm)
[11:23] <wgrant> Hobbsee: Thanksl.
[11:23] <NCommander> StevenK, so we're almost there, I have a potential fix, but I need to wait for the build to finish to make sure the headers end up in the right folder
[11:25] <NCommander> StevenK, not bad for 24 hours of work and coming in with no git/no ubuntu-kernel experience ;-)
[11:26]  * NCommander has learned from his sponsors to slow down when doing work
[11:26] <NCommander> StevenK, second BTW, ubuntu-mid, when installed, doesn't seem to properly setup X11
[11:27] <StevenK> It ought to
[11:27] <NCommander> DIdn't for me in QEMU
[11:27]  * NCommander actually made sure the resulting kernel images were installable :-)
[11:27] <NCommander> StevenK, I want this to be a single upload to fix everything
[11:32] <NCommander> StevenK, so it should just be a matter of uploading, waiting for it to get published, and then clicking retry on lpia-lrm, and lpia-meta
[11:33] <StevenK> Er, yeah, I know all that.
[11:34]  * NCommander just feels the need to be complete
[11:37] <pitti> ion_: right, ted and I just discussed doing the latter (hiding "new guest session" if one is running), he's working on it
[12:12] <ion_> pitti: I emailed a preliminary patch to him last night. I didn’t get around to testing it or refreshing the following patches yet, though.
[12:24] <StevenK> NCommander: Any news?
[12:24] <NCommander> StevenK, not yet
[12:27] <NCommander> StevenK, well, it just finished compiling, now its installing
[12:47] <NCommander> StevenK, ok, it built
[12:48] <StevenK> \o/
[12:49] <NCommander> StevenK, testing module assistant now
[13:19] <persia> NCommander, dkms might be more interesting than module-assistant, given that more things use it.
[13:19] <NCommander> persia, I just want to make sure I can build a kernel module
[13:20] <NCommander> As long as a kernel module can be compiled, I'm satisfied ;-)
[13:20] <ion_> dkms handles kernel upgrades better.
[13:20] <persia> NCommander, Right, but the common case of compiling a kernel module in Ubuntu is going to be with DKMS, rather than with modass
[13:20] <NCommander> GIve me a command and I shall run it
[13:21] <persia> apt-get install kqemu-source ought to do it.
[13:26] <NCommander> persia, looking promising
[13:35] <NCommander> persia & StevenK: success!
[13:36] <lucas> sma
[13:36] <lucas> oops
[13:39] <StevenK> NCommander: So I can have a kernel now?
[13:40] <NCommander> StevenK, give me a moment
[13:43]  * NCommander is making a debdiff
[13:47]  * NCommander notes debdiff on the kernel is a SLOW process
[13:49] <NCommander> still debdiffing
[13:52]  * NCommander pokes his laptop to see if it just died without anyone noticing
[13:57] <gaspa> cjwatson: I tested and added a simple correction to a your patch on thi bug:#259761
[13:57] <gaspa> bug 259761
[14:03] <StevenK> NCommander: It's still debdiffing?
[14:04] <NCommander> The debdiff IS getting bigger
[14:04] <NCommander> so it hasn't stalled
[14:04] <NCommander> my HDD is trashing like mash
[14:04]  * NCommander thinks his laptop ready to segfault and die on me
[14:06] <persia> NCommander, You do have patchutils installed, right?  And you're using the same orig.tar.gz?
[14:06] <NCommander> persia, what orig.tar.gz?
[14:06] <NCommander> persia, the linux-lpia in the archive didn't have one
[14:06] <NCommander> (yes, it is debdiffing two 70MB tarballs)
[14:06] <persia> Oh, right.  I forgot.  No diff.gz shortcut.
[14:07] <NCommander> persia, yeah
[14:08] <NCommander> persia, someone needs to upload a orig.tar.gz
[14:08] <persia> NCommander, Not at this point in the release cycle.
[14:09]  * NCommander puts it on the jaunty todo
[14:09] <NCommander> "No-changes orig.tar.gz upload"
[14:10] <NCommander> DONE!
[14:10] <NCommander> FINALLY
[14:10] <NCommander> 31629 linux-lpia.debdiff
[14:10] <NCommander> :-)
[14:10]  * NCommander had to rename a directory
[14:11] <NCommander> woo, its a 1.9MB patch
[14:11] <StevenK> Oh, argh
[14:12] <NCommander> StevenK, where should I send it?
[14:13] <StevenK> NCommander: stevenk@canonical.com
[14:13] <StevenK> Given the size, I'll review it tomorrow
[14:13] <StevenK> NCommander: CC amitk@canonical.com, please
[14:13] <NCommander> StevenK, its just a directory rename, that's whats so massive
[14:15] <NCommander> StevenK, you got patches
[14:26] <n3hima> does anyone know of a way do extract a partition image from a disk image
[14:31] <Treenaks> n3hima: http://tuxinarow.com/2006/12/27/loopback_mountin_a_specific_partition_inside_a_disk_image ?
[14:31] <n3hima> Treenaks, thx v much
[14:32] <Treenaks> n3hima: It was a simple google query...
[14:32] <n3hima> hmm
[14:32] <n3hima> sorry
[14:34] <amitk> StevenK: NCommander:  1.9Mb?
[14:34] <NCommander> amitk, the directory rename
[14:34] <NCommander> amitk, really bloats a diff up REAL nice
[14:34] <persia> amitk, directory name change means that there's *lots* of duplication.  git supports rename, so git change would be much smaller.
[14:36] <amitk> NCommander: could you just send me the git diff. I don't care too much about debdiff...
[14:36] <NCommander> amitk, yes sire
[14:36] <amitk> NCommander: thanks.
[14:37] <amitk> NCommander: this will be on top of what is already in git, or on -4.7?
[14:37] <NCommander> Its a replacement for the last commit I gave you
[14:37] <NCommander> (reset that diff, and then put this in that place)
[14:44] <amitk> NCommander: ooh...
[14:45] <NCommander> yeah
[14:45] <NCommander> Hold on
[14:46]  * amitk hopes it is against e3a18175deaed9f2af0b7694e44e6dd686906f1e in the git tree
[14:49] <NCommander> amitk, nope
[14:49] <NCommander> amitk, its a one line change from that
[14:49] <NCommander> If you want, I can do that
[14:49] <NCommander> or tell you specifically what to change :-)
[14:50] <NCommander> amitk, I sent a patch that susposed to replace e3a18175deaed9f2af0b7694e44e6dd686906f1e
[14:50] <amitk> NCommander: ok... I'll diff it just to be sure.
[14:51]  * NCommander hugs amitk 
[14:51] <NCommander> THis is motivation to get me an account so you don't have to constantly merge in patches
[14:51]  * amitk thanks NCommander for his hardwork and promises him a beer if he is at UDS
[14:51]  * NCommander isn't 21 ;.;
[14:51] <amitk> then root beer for you :-p
[14:52] <Mithrandir> or you can come to a real country where you're allowed beer before 21.
[14:52] <Mithrandir> ;-)
[14:52] <NCommander> Mithrandir, cheaper to wait for 21
[14:52] <amitk> Mithrandir: true
[15:07] <lfaraone> Hey, there are a collection of GPL'd documentation for a variety of software included in Ubuntu at flossmanuals.net, I'm wondering how to go about packagign them for ubuntu and whether to make them a separate package from the projects they document. (sabdfl sent me here)
[15:19]  * NCommander asks that someone flog me
[15:23]  * lfaraone flogs NCommander 
[15:24] <NCommander> sweet
[15:24] <NCommander> I made a joke involving race conditions and a proof about P=NP :-P
[15:26] <persia> lfaraone, I'd recommend starting with a few cluster packages for related stuff, and working with all the upstreams to get the documentation for their stuff included.
[15:26] <persia> Once each thing is included upstream, it can be split out as foo-doc in the packaging, and removed from the combination package.
[15:27] <NCommander> persia, so StevenK got the linux-lpia patch
[15:27] <NCommander> its fixed
[15:27] <NCommander> finally
[15:27]  * NCommander feels his brain melt
[15:27] <persia> This is somewhat similar to that being done with ia32-libs : where some libraries are being updated to build 23-bit and 64-bit variants, and dropped from the combination package.
[15:28] <persia> NCommander, Don't we still have a few hours to wait until it hits the right count of publisher cycles and everything rebuilds?
[15:28] <NCommander> persia, that's for my sponsor to worry about. Once I'm an MOTU I'll worry about that bit ;-)
[15:28]  * NCommander runs
[15:29] <persia> Well, actually, linux-lpia is in main, so being MOTU doesn't make any difference.  That said, what one worries about ought have little relation to ones entries in an ACL : it's about what is interesting.
[15:30] <NCommander> persia, ok, core-dev
[15:31] <NCommander> persia, I'm sorta worried about sleep. By time I wake up, it should have all automagicially resolved itself ;-)
[15:31] <persia> NCommander, Again, no, it shouldn't matter.  If you change something, you've told the world you're responsible for that change, so it's worth making sure that anything else that needs doing is done, rather than counting on a sponsor.
[15:32]  * NCommander has to file a bug against ubuntu-mid about their daily image
[15:32] <persia> What's wrong with the ubuntu-mid daily image?
[15:32] <lfaraone> persia: so we'll have "flossmanauls-collection" which will include all the unassociated docs, and evrentually we'll have separaet "inkscape-fm-doc" etc packages?
[15:32] <NCommander> The lack of X11 working on install
[15:32] <persia> lfaraone, Or just inkscape-doc, if you can build the right spirit of collaboration.
[15:32] <NCommander> persia, I'm being sacastic. I realize that for any changes I make, I'm responsible for the resulting breakdown of the universe
[15:33] <lfaraone> persia: ah, kk. (in that spesific case, inkscape was the group that commissoned those docs, so yeah, that'd work)
[15:33] <persia> NCommander, Which package is missing?
[15:33] <NCommander> persia, I dunno. I can startx to a grey screen
[15:33] <lfaraone> persia: and we'd just make -doc a Reccomends: of inkscape?
[15:33] <NCommander> persia, I install it just fine, but I get dumped to a command line
[15:35] <persia> NCommander, I suspect it's an issue with something other than the image.  The image is responsible only for making sure certain packages get deleted on install (see http://paste.ubuntu.com/59306/)
[15:35] <persia> Which username are you using?
[15:35] <NCommander> persia, the one I set during install?
[15:35] <NCommander> persia, no, X11 doesn't come up period
[15:35] <NCommander> I get a terminal login prompt
[15:36] <persia> NCommander, RIght.  I suspect you want to file a bug against ubuntu-mid-default-settings that it doesn't work if the username isn't "ubuntu".
[15:37] <persia> I don't think it's an image problem.
[15:37] <NCommander> Ok, I shall do that
[15:39] <NCommander> persia, I'm just happy linux-lpia is resolved :-)
[15:40] <persia> NCommander, Create an "ubuntu" user and reboot to verify I've guessed the right bug.
[15:41] <NCommander> persia, why would it be dependent ont he existance of an ubuntu user?
[15:41] <persia> NCommander, read /etc/event.d/session
[15:42] <NCommander> persia, what priority would you mark that? I guess its low since normal users won't see it, but I'd like a second opinion
[15:44] <lfaraone> Are dates appropreate for version numbers of packages?
[15:44] <lfaraone> (Docs0
[15:46] <persia> NCommander, I'd call it medium.
[15:46] <NCommander> persia, yup, your right
[15:46] <persia> lfaraone, best to use a numerical format like 20081230 so it's guaranteed not to have issues (Nov10 > Dec15)
[15:47] <lfaraone> persia: Ok.
[15:54] <NCommander> persia, bug filed :-)
[15:55] <persia> NCommander, Cool.  Be jaunty before it's fixed, but handy to have for reference.
[15:56] <NCommander> persia, Ubuntu mobile looks pretty cool
[15:56] <NCommander> If I buy a freerunner
[15:56] <NCommander> Beware of port
[15:57] <pwnguin> isnt the freerunner arm?
[15:58] <lfaraone> pwnguin: yeah
[15:59] <pwnguin> that seems incompatible with mobile stuff / ubuntu
[15:59] <NCommander> pwnguin, like I said
[15:59] <NCommander> beware of port
[15:59] <NCommander> I AM crazy enough to port Ubuntu to bring -mobile/-mid to the freerunner
[15:59] <pwnguin> NCommander: last i knew, mobile had a flash component
[16:01] <pwnguin> NCommander: is the -mobile stuff installable via package & regular ubuntu yet?
[16:01] <NCommander> no idea
[16:02] <tseliot> pwnguin: you can install ubuntu-mobile
[16:02] <persia> pwnguin, mojo.handhelds.org
[16:02] <persia> pwnguin, Also, intrepid has everything you'd expect for ubuntu-mobile and ubuntu-mid.  Nothing external.
[16:03] <pwnguin> persia: ah; i got frustrated with the xephyr / chroot setup
[16:04] <persia> pwnguin, Yes, that's just pointlessly broken.  Use kvm, vbox, or some other virtualisation if you want to run it as a guest on your normal workstation.
[16:04] <pwnguin> i'd rather run it installed alongside my other stuff, but apparently this is not in the cards?
[16:04] <lfaraone> Hey, what package contains the Ubuntu keyring?
[16:05]  * james_w guesses ubuntu-keyring
[16:05] <pwnguin> alrighty. enough embedded stuff, at least until my Pandora arrives in December
[16:05] <ogra> nah, thats likely a trick question :)
[16:06] <lfaraone> Lol.
[16:06] <pwnguin> i got a complaint from upstream that the libgnomecanvcas shipped in ubuntu is broken
[16:06] <lfaraone> I have a feeling that bug 283890 will be a wontfix, am I right?
[16:07] <LimCore> could we allow to access medibuntu-keyring in ubuntu.org repos?  Just keyring, its legal;  It will close a possible security hole (how you know medibuntu keyring was not spoofed when you download it unsigned by ubuntu)
[16:07] <pwnguin> legal rammifications aside, i dont think it's a good idea to place keys from 3rd parties in by default
[16:07] <pwnguin> LimCore: the question is, should we trust medibuntu by default?
[16:08] <LimCore> no legal rammifications, just the key ring.  So the reason is that ubuntu developer can not trust medibuntu developers enought to sign it?
[16:08] <LimCore> pwnguin: dunno... I thought it was lead by trusted people asociated with ubuntu
[16:08] <lfaraone> LimCore: it's a potential MOTM attack.
[16:08] <lfaraone> LimCore: if you install it by default.
[16:08] <james_w> man on the moon?
[16:09] <LimCore> mitm attack?  man in the middle?   my idea is exactly to avoid mitm
[16:09] <jdong> it does NOT belong in ubuntu-keyring
[16:09] <jdong> I'd have no objection to having a medibuntu-keyring package in Ubuntu
[16:09] <LimCore> jdong: this is exactly what I said
[16:09] <jdong> but I do not want medibuntu's key as a part of the central Ubuntu keyring
[16:09] <LimCore> yes
[16:09] <LimCore> ok, so lets do it \o/ ?
[16:09] <jdong> sure, jaunty.
[16:10] <LimCore> well ok
[16:10] <pwnguin> I wonder if that would be contributory patent infrigement
[16:10] <jdong> haha does such a thing exist?
[16:11] <pwnguin> yes
[16:11] <jdong> accessory to patent infringement
[16:11] <pwnguin> http://en.wikipedia.org/wiki/Patent_infringement_under_United_States_law
[16:11] <NCommander> o_O;
[16:12] <NCommander> I
[16:12] <NCommander> ...
[16:12] <NCommander> No comment
[16:12] <pwnguin> 35 U.S.C. § 271(c), or "contributory infringement," is triggered when a seller provides a part or component that, while not itself infringing of any patent, has a particular use as part of some other machine or composition that is covered by a patent.
[16:13] <pwnguin> obviously wikipedia is not legal council
[16:13] <LimCore> lol
[16:13]  * LimCore loves USA... the Freedom country. lol yea
[16:13] <jdong> well I still don't think medibuntu's keyring falls under that.
[16:13] <jdong> I remind you that libdvdread contains a script that directly fetches medibuntu's css package.
[16:13] <pwnguin> heh
[16:14]  * LimCore sends troops to arrest all the evil patents terrorist from ubuntu
[16:14] <pwnguin> im just suggesting that maybe it's not cut and dried. canonical being incorporated in an offshore island territory helps them a bit i suppose
[16:14]  * LimCore back to back reporting - xorg crashes epically on intell in 8.10 up to date
[16:17] <pwnguin> there's also the fact that medibuntu provides some packages offensive to ~50 percent of the target userbase
[16:17] <Lutin> e.g. ?
[16:18] <pwnguin> http://packages.medibuntu.org/intrepid/hot-babe.html
[16:19] <Lutin> sigh. no one forces anyone to install it. ubuntu has firefox, too. which can offense potentially 100% of the userbase, as it allows access to internet.
[16:20] <lfaraone> pwnguin: 50? bah. I think you're underestimating people's level of offense.
[16:21] <pwnguin> i'm just trying to give a complete picture of the relationship between medibuntu and ubuntu proper. i can't say which parts are relevant from a key perspective
[16:22] <mr_pouit> pwnguin: the key is used to sign the Release.gpg files, nothing more…
[16:22] <lfaraone> So we can make it a medibuntu-keyring package.
[16:23] <pwnguin> http://packages.medibuntu.org/intrepid/medibuntu-keyring.html
[16:23] <pwnguin> on a related note, is it too hard to manually include a key?
[16:23] <lfaraone> Remind me, what's the package that ubuntu uses akin to WNPP in debian?
[16:24] <lfaraone> pwnguin: it's a security risk, you're downloading it over an unsecured line.
[16:24] <lfaraone> w/o auth
[16:24] <pwnguin> lfaraone: so use https
[16:24] <LimCore> pwnguin: lol?
[16:25] <LimCore> pwnguin: medibuntu uses real ssl cert? like from cacert?
[16:25] <pwnguin> LimCore: why not?
[16:25] <LimCore> The certificate is not trusted because it is self signed.
[16:25] <LimCore> The certificate is only valid for zeus.flosoft.info
[16:25] <LimCore> The certificate expired on 10/09/2008 09:08 PM.
[16:25] <LimCore> wow, that really helped.
[16:25]  * LimCore fells secure now
[16:25] <jdong> frankly if you use medibuntu you should not be worrying about security.
[16:25] <jdong> who the hell are making the packages?
[16:26] <jdong> are they in a verifiable build system such that the sources are turned into the binaries you see?
[16:26] <jdong> who maintains the server that it's hosted on?
[16:26] <pwnguin> jdong: i think you've got it backwards. if you care about security, don't use medibuntu ;)
[16:26] <lfaraone> jdong: well, the medibuntu team.
[16:26] <LimCore> most desktop media users will get medibuntu
[16:26] <pwnguin> but yes, those are the core reasons to not trust medibuntu
[16:26] <LimCore> its huge user base.  we should consider this
[16:27] <lfaraone> jdong: https://launchpad.net/~medibuntu-maintainers/+members
[16:27] <jdong> lfaraone: I know that.
[16:27] <LimCore> perhaps ubuntu should start another company (for legal resons), that would be trusted,  and they will run "officiall" medibuntu
[16:27] <LimCore> it is lead by trusted people from ubuntu staff? well, seems fine to me
[16:27] <pwnguin> lfaraone: you've already seen two of them speak here
[16:29] <jdong> oh great... more flash md5sum fun.....
[16:31] <pwnguin> ttps://bugs.edge.launchpad.net/ubuntu/+source/libgnomecanvas/+bug/284530
[16:31] <pwnguin> bah
[16:32] <pwnguin> http://bugs.launchpad.net/ubuntu/+source/libgnomecanvas/+bug/284530
[16:32] <pwnguin> i hope it's not too late to fix that
[16:33] <jdong> needs https://bugzilla.novell.com/attachment.cgi?id=242687 that patch?
[16:33] <LimCore> we have crashes on intel gfx card(s?) under openGL load.  https://bugs.launchpad.net/ubuntu/+source/xorg/+bug/285298
[16:33] <LimCore> if I can help more to debug it a bit, let me know :)   bl.
[16:34] <jdong> it would be more helpful if you attached logfiles so the discription isn't a 5 page register dump.
[16:35] <LimCore> jdong: the log file in 150 mb.   but ok I will attach the shortened version and remove it from descr
[16:35] <pwnguin> jdong: yes, it seems
[16:35] <jdong> yes, that's what I meant. thanks.
[16:35] <asac> hmm ... no sound on my X61 speaker :/
[16:35] <jdong> pwnguin: do we have any confirmation that fix works?
[16:35] <james_w> pwnguin: isn't that bug a dupe?
[16:35] <jdong> pwnguin: it's not too late to fix the bug but it's probably too late to play the *upload* "are the lights on yet?" game.
[16:35] <james_w> ah, no
[16:37] <pwnguin> jdong: there's confirmation the patch works in suse. nothing tried on ubuntu yet
[16:39] <james_w> the fix has been accepted upstream
[16:41] <pwnguin> im not sure what all patches are applied yet. i just started looking at this
[17:21] <avb> guys, im examining boot procedure of ubuntu
[17:21] <avb> i filled some bugs
[17:21] <avb> but im wondering
[17:22] <avb> what the point to load bunch of modules with modprobe at boot time on each pc instead of compiling them into kernel?
[17:22] <avb> im talking about /etc/init.d/acpid and /etc/init.d/powernowd
[17:23] <avb> they modprobing like 15 modules
[17:23] <avb> i convert acpid to use insmod to reduse load time, but its not that easy to do in powernowd, coz modules there have dependencies
[17:25] <avb> once this modules will be builtin into kernel, we will save about 1-2 seconds at boot
[17:36] <amitk> avb: these issues are already known and on the agenda to be fixed for Jaunty. You should attend UDS or participate in the teleconf in December if you would like to participate in the discussions.
[17:37] <avb> amitk: unfortunately im located not in US or Europe :)
[17:37] <avb> and its a bit hard to get visa for me
[17:37] <avb> at least that nice, that problem is known
[17:39] <amitk> avb: you can still call into various sessions of the UDS. Schedule will be published closer to 8th Dec.
[17:40] <avb> originaly im from belarus, but now im in dominican republic, caribbean
[17:40] <avb> maybe Mark can fund UDS summits on the boards of caribbean sea? :)
[17:41] <avb> anyway, we will see. thanks for the info
[21:34] <doggymenz> when someone fix http://start.ubuntu.com/8.10/ so it say 8.10 instead of 8.04 ?
[21:57] <mdke> doggymenz: the website team is working on updating that page in time for Ubuntu 8.10
[22:00] <doggymenz> ok, i want it get updated fast
[22:01] <doggymenz> so i can whine at them, if they do it wrong
[22:01] <doggymenz> somene tried sneak in an ugly wallpaper
[22:01] <doggymenz> but luckily we caught it, whined, and it got fixed, now we got a very pretty one
[22:02] <mdke> I preferred the previous one, myself.
[22:02] <mdke> anyway, no, you don't get to do that with this webpage, but you can of course subscribe to the webteam mailing list and participate in the discussions there
[22:03] <mdke> it's not whining, but it's second best
[22:09] <doggymenz> i think they should set up the page now, as per open source tradition "release early, release often"
[22:10] <doggymenz> because 8.04 sucks, it has google search, but it goes to .uk for all users, even those who not .uk
[22:14] <RainCT> mdke: uhm.. that page isn't displayed correctly on epiphany
[22:15] <RainCT> mdke: the "Ubuntu Merchandise" entry is not aligned with the other ones, unless you increase the text size
[22:16] <RainCT> and in Firefox two of the images get a weird border if you decrease the size o_O
[22:17] <mdke> RainCT: feel free to report that as a bug, I have a bad memory at the best of times, let alone for stuff I don't work on
[22:17] <RainCT> mdke: against which product should I fill it?
[22:17] <mdke> ubuntu-website
[22:17] <RainCT> ubuntu-website?
[22:17] <RainCT> ok
[22:19] <mdke> the page is getting a complete redesign from what I've read, but I don't know if that will be ready for 8.10, so it's worth filing bugs for the existing version
[22:40] <doggymenz> gnome start menu is much easier than kde
[22:41] <doggymenz> kde is slow and confusing to navigate
[22:58] <Plagman> hey
[22:58] <Plagman> my wireless adapter stopped working after upgrading to intrepid
[22:58] <Plagman> getting "rt2x00lib_request_firmware: Error - Failed to request Firmware." errors when trying to bring the interface up
[22:58] <Plagman> is this a known problem?
[23:06] <james_w> Plagman: install linux-firmware
[23:07] <james_w> Plagman: I think you just got unlucky with the time you upgraded
[23:07] <Plagman> oh.
[23:07] <Plagman> installing now
[23:08] <Plagman> sweet
[23:08] <Plagman> worked
[23:08] <Plagman> thanks a lot
[23:08] <Plagman> so it was just a temporary gap in the dependencies on the intrepid repositories and I was unlucky enough to dist-upgrade right then?
[23:09] <james_w> I think so
[23:09] <james_w> I got hit too
[23:09] <james_w> the -generic image depends on it, but I think we upgraded before that caught up
[23:09] <james_w> unless you don't have that installed
[23:09] <Plagman> I think it's installed
[23:10] <directhex> depends or recommends?
[23:10] <Plagman> anyway, thanks for the tip
[23:10] <james_w> depends
[23:11] <Plagman> time to unplug the good ol' rj45, see ya
[23:11] <Plagman> thanks again for the tip, I wouldn't have figured that out right away :)
[23:12] <calc> nomination appears to be broken on LP
[23:13] <calc> slangasek: bug 278943 (i can't seem to approve nomination
[23:16] <wgrant> calc: You don't get an "(approve/decline)" button on the nomination line?
[23:23] <persia> Could an archive-admin please reject linux-rt 2.6.27-3.6 from unapproved?  I'll be pushing 2.6.27-3.7 fairly soon (3.6 works against 7.11, but FTBFS against 7.12), so there's no advantage to keeping this one.
[23:33] <slangasek> persia: done
[23:37] <persia> slangasek, Thank you.
[23:57] <calc> wgrant: i do and it keeps giving me launchpad errors
[23:57] <calc> wgrant: er whenever i click approve
[23:58] <wgrant> calc: OOPSes?
[23:58] <calc> wgrant: i suppose so
[23:58] <calc> wgrant: looking at the bug again
[23:59] <wgrant> calc: Lovely. See if somebody else is able to do it.
[23:59] <calc> wgrant: gives me (Error ID: OOPS-1022F2097)