[12:12] <jdong> bluefoxicy: heh it's segfaulting on depmod :)
[12:13] <bluefoxicy> jdong:  wow
[12:13] <jdong> I'm guessing I'm doing something wrong
[12:13] <jdong> there wasn't an option that I checked that could cause that to happen , would there be?
[12:16] <jdong> bluefoxicy: I'm just gonna reset my .config and just use preset HIGH :)
[12:17] <bluefoxicy> heh
[12:17] <bluefoxicy> that kind of behavior is distinctly odd
[12:20] <jdong> bluefoxicy: is the default HIGH high enough that it would prevent at least a basic bootup?
[12:20] <jdong> bluefoxicy: all I'm looking for is my damn minimal ubuntu install to boot :D
[12:21] <bluefoxicy> I honestly don't know the defaults
[12:21] <bluefoxicy> the only thing i can think of it breaking should be X
[12:25] <bhale> using the grsecurity canned settings is foolish
[12:25] <bhale> you should know what the little switches do before turning any of them
[12:42] <mpt> hi StevenK :-)
[12:43] <StevenK> mpt: Have you got a sec to talk about AboutWindow?
[12:45] <mpt> sure
[12:45] <StevenK> mpt: Have you looked at my most recent changes?
[12:46] <mpt> I'm looking at them now
[12:46] <StevenK> mpt: The wiki page also says that it doesn't hook into the session manager, does it need to?
[12:46] <mpt> Well, it would be nice to not get a busy cursor for 15 seconds after it opens :-)
[12:46] <mpt> That's the only reason
[12:47] <StevenK> I don't recall seeing that on my system.
[12:50] <StevenK> mpt: I was also considering packaging it up in a neat .deb, but I wanted to talk to you about it first.
[12:55] <mpt> StevenK, sure, but then I'll *never* learn :-P
[12:56] <mpt> If I haven't done it by this time next week, however, I must be procrastinating, so you'd be welcome to
[12:59] <StevenK> mpt: Yes, which is why I wanted to talk to you about it. :-)
[01:21] <jdub> norman silverstone
[01:21] <Hobbsee> hey jdub 
[01:21] <jdub> yo Hobbsee 
[01:23] <ajmitch> morning jdub 
[01:37] <smallfoot-> if anyone know a hardware company that done something good or bad such as cooperate with open source or anti-competive, please add it to http://vendors.bluwiki.org/
[01:37] <HrdwrBoB> smallfoot-: please. stop spamming
[01:38] <Hobbsee> smallfoot-: might be more sensible to put that into #ubuntu-offtopic - that's not development related
[01:38] <mjg59> smallfoot-: You've been asked to stop before. Please do so, otherwise you'll be banned from the channel.
[01:39] <smallfoot-> but the developers are those who know what vendors make source code public and who dont
[01:40] <Hobbsee> ...and are working on other things, such as actual development...
[01:41] <ajmitch> smallfoot-: you've spammed that a couple of times now
[01:42] <infinity> At 09:11, 11:19, 15:23, and 17:37 according to my /lastlog
[01:42] <infinity> smallfoot-: Please stop.  It's not helping your case any.
[01:43] <mjg59> smallfoot-: You were asked to stop after the third time. You've just done it a fourth time.
[01:43] <smallfoot-> :(
[01:43] <smallfoot-> sry i forgot
[01:43] <smallfoot-> it was long time since last
[01:43] <infinity> 2 hours.
[01:43] <infinity> That's not a "long time".
[01:44] <smallfoot-> i think is long
[01:45] <bhale> not long enough to forget something you've been told 3 times already
[01:45] <bhale> don't fight about it, just don't do it again
[01:45] <mjg59> smallfoot-: The decision isn't up for discussion here. This channel is not for advertising websites - it is for discussing development of Ubuntu.
[01:46] <smallfoot-> true
[01:46] <smallfoot-> oh didnt know was discussinog for development only
[01:46] <smallfoot-> i just figured here are many developers
[01:46] <smallfoot-> and developer knows about device drivers
[01:46] <smallfoot-> and which vendors are good and bad
[01:47] <infinity> smallfoot-: Please just drop it, don't waste time justifying it.
[01:47] <infinity> smallfoot-: And promise it won't happen again.
[01:47] <smallfoot-> okie
[01:50] <sistpoty> infinity: just curious: did you get the mail regarding mit-scheme (from 10/6) I forwarded to you? (https://lists.ubuntu.com/archives/ubuntu-motu/2006-October/000836.html)
[01:51] <infinity> sistpoty: I'm notorious for poorly filtering spam occasionally (especially when travelling and leaning on the delete key to get through thousands of messages), so it may have disappeared. :/
[01:51] <infinity> Oh, no.  Wait.  I got that one.
[01:51] <infinity> Ugh.
[01:51] <infinity> I refuse to do a manual bootstrap on every single upload of the source.
[01:52] <sistpoty> infinity: sure... do you see a solution or have any hints?
[01:52] <infinity> If the only way it can build is with binaries from upstream, the binaries will have to be (ugh) bundled in the source package.
[01:52] <sistpoty> nice :(
[01:52] <infinity> Not really a license violation, since the source used to build said binaries is sitting next to them.
[01:52] <infinity> Just realy, really ugly.
[01:52] <infinity> And bloaty.
[01:53] <sistpoty> true... will you send him a quick answer or shall i?
[01:53] <jdong> infinity: not to distract you, but have you had a chance to happy-ize backports yet?
[01:55] <crimsun> infinity: if/when you have a suitable moment, please give back alsa-utils and alsa-plugins, thanks
[01:56] <infinity> sistpoty: Feel free.  He may want to consider a similar bootstrap bloat option for Debian too.  Not having the packages buildable from source is somewhat unacceptable.
[01:56] <infinity> jdong: Should get done during this wake cycle.
[01:56] <infinity> crimsun: On it.
[01:56] <sistpoty> infinity: ok, I'll do. thanks.
[01:56] <jdong> infinity: thanks, infinitely grateful for your time :)
[01:57] <infinity> crimsun: Err, nothing to give back...
[01:57] <crimsun> infinity: are dep-waits automatically retried?
[01:57] <infinity> crimsun: Looks like we're in dep-wait on libasound2-dev (>= 1.0.12)
[01:57] <infinity> crimsun: Yes, dep-waits get auto-cleared when available.
[01:58] <crimsun> infinity: ah, ok, thanks
[03:26] <keescook> uhm... "apt-get source" ignores Acquire::http::Proxy settings??
[03:35] <jdong> keescook: is that what it is?
[03:36] <jdong> and I thought I was doing something wrong :D
[03:36] <keescook> jdong: eh?  i was just complaining to myself...
[03:36] <jdong> keescook: I've experienced something like that before
[03:37] <jdong> keescook: IIRC setting HTTP_PROXY works around it
[03:37] <jdong> keescook: I was complaining too .... kind of to myself :D
[03:37] <keescook> jdong: I was also seeing that my sbuilds weren't using the proxy either.
[03:38] <keescook> seems like the minimal apt in my chroot was ignoring /etc/apt/apt.conf.d ... moving the file to /etc/apt/apt.conf seemed to fix it...
[03:38] <jdong> keescook: maybe I was being stupid trying to type the setting then :)
[03:38] <jdong> I've been known to do that
[03:39] <keescook> wild... yeah, apt-get source ignores /etc/apt/apt.conf.d ??  when I moved my setting into /etc/apt/apt.conf, it works for apt-get source too.
[04:58] <lifeless> Riddell: cool
[05:00] <keescook> I love source packages with test suites.  *happy sigh*
[06:59] <soulfire45> Hey everyone
[07:25] <dholbach> good morning
[07:25] <_ion> Evening.
[07:25] <dholbach> hey _ion
[07:25] <_ion> What's up?
[07:26] <dholbach> damned jetlag - i was up at 5:15 already *yawn*
[07:28] <Mithrandir> good morning, Daniel
[07:28] <dholbach> heya Tollef
[07:28] <dholbach> how are y'all?
[07:30] <Mithrandir> still not dead
[07:31] <keescook> always a good sign, breathing.  :)
[07:31] <dholbach> hey kees
[07:31] <keescook> hiya dholbach
[07:31] <_ion> I see the reason for feisty-wallpapers to conflict with edgy-wallpapers, but it would be cool if it was possible to install wallpaper packages from earlier Ubuntu versions.
[07:31] <fabbione> morning Germans
[07:32] <BenC> how do I request a sync from Debian for ndiswrapper?
[07:32] <fabbione> BenC: you need to file a bug in LP.. there is a procedure somewhere for it
[07:32] <dholbach> BenC: you could use pitti's requestsync script for that
[07:32] <fabbione> or that
[07:33] <dholbach> http://people.ubuntu.com/~pitti/scripts/requestsync
[07:33] <BenC> got it thanks
[07:33] <mvo> keescook: do you mind if I merge gdb (you touched it last)?
[07:34] <keescook> mvo: have at it, I was just doing security updates to it.  :)
[07:34] <dholbach> _ion: I'll think about how to solve it - the filenames need to change, I guess
[07:35] <infinity> BenC: Alternately, you can just fedex me a smoke and ask nicely.
[07:35] <infinity> (If it requires overwties and long explanations, filing a long-winded bug is better, though)
[07:35] <infinity> Paper trail, for the win.
[07:37] <BenC> there's only two trivial changelog entries, and requestsync seems to be stalling
[07:38] <BenC> actually only one, and that was a dash fixup, and it's been synced in debian
[07:38] <BenC> infinity: it's a clean sync, if you could take care of it for me
[07:38] <infinity> And a cosmetic debian/control change.
[07:38] <infinity> http://patches.ubuntu.com/n/ndiswrapper/ndiswrapper_1.18-1ubuntu2.patch
[07:39] <infinity> I assume we made that control change on purpose, dropping it isn't nice. :)
[07:39] <infinity> +ndiswrapper (1.1-4ubuntu2) breezy; urgency=low
[07:39] <infinity> +
[07:39] <infinity> +  * debian/control: Update description to point out that the kernel source
[07:39] <infinity> +    package is not required with the standard Ubuntu kernel.
[07:39] <infinity> +
[07:39] <infinity> + -- Martin Pitt <martin.pitt@ubuntu.com>  Fri, 30 Sep 2005 14:56:14 +0200
[07:39] <BenC> infinity: What's the best way to handle this then?
[07:40] <fabbione> BenC: with the new initramfs i will get pata_via directly.. right?
[07:40] <infinity> BenC: Merge away.
[07:40] <BenC> I'm not used to the whole syncing process
[07:40] <BenC> fabbione: correct
[07:40] <fabbione> BenC: ok. testing now
[07:40] <infinity> BenC: You get to do a merge if we want t okeep those changes, no syncing required.
[07:40] <BenC> infinity: Is there anything I need to do special when I'm done?
[07:40] <infinity> BenC: Upload it? :)
[07:41] <Hobbsee> run merge-genchanges on it
[07:41] <BenC> I remember seeing an email from colin about merge policy not being adhered to, just making sure :)
[07:41] <infinity> BenC: Surely, we've assigned merges to you before... (kernel-package, kernel-wedge?)
[07:41] <BenC> yeah, but I just uploaded them, and did nothing else :)
[07:41] <cypher1> fabbione: what is pata_via ?
[07:41] <infinity> BenC: Oh, the new-fangled merge policy is to, rather than interlacing all the old changelog entries, just have one changelog entry at the top that explains the current delta.
[07:41] <fabbione> cypher1: a kernel module
[07:41] <BenC> infinity: Ok
[07:42] <cypher1> fabbione: what does it do ?
[07:49] <fabbione> BenC: modulo the OOPS, it's ok. The initramfs is lacking cdrom or you need to blacklist sr_mod from being included otherwise you get a bunch of unresolved symbols
[07:49] <BenC> lacking cdrom?
[07:49] <fabbione> cdrom.ko
[07:49] <infinity> (base)adconrad@cthulhu:~$ modinfo sr_mod | grep ^depends
[07:49] <infinity> depends:        scsi_mod,cdrom
[07:49] <BenC> sounds like a bug I introduced
[07:50] <fabbione> BenC: yeah or blacklist sr_mod
[07:50] <BenC> cdrom should be in base modules
[07:50] <infinity> modules_add_dir probably doesn't do dep checking like manual_add_modules does.
[07:50] <BenC> nope, it doesn't
[07:50] <BenC> It actually just copies
[07:50] <infinity> cdrom really doesn't need to be there at all, though, IMO.
[07:50] <BenC> makes dmesg look ugly though, I suspect
[07:50] <infinity> However, this may be why we weren't using add_dir. :)
[07:50] <minghua> speaking of missing kernel modules, we also miss via82cxxx.ko in 2.6.19 kernels
[07:51] <fabbione> BenC: i suggest you fix that before going to sleep :)
[07:51] <infinity> With no dep-checking, who knows what other drivers may break.
[07:51] <fabbione> minghua: that's changed to pata_via
[07:51] <fabbione> minghua: and it has been fixed as we speak
[07:51] <BenC> I can make copy_dir do a find -name \*.ko and manual_add_module for each one
[07:51] <minghua> fabbione: I see.  So I'll just wait?
[07:51] <fabbione> minghua: yes
[07:51] <minghua> (I was thinking of filing bugs)
[07:51] <infinity> BenC: That was what I was about to suggest, yes.
[07:51] <minghua> fabbione: got it.  thanks.
[07:52] <BenC> let me finish this ndiswrapper sync and I'll fixup initramfs-tools
[07:52] <fabbione> minghua: there are already a few dups.. spare your time or check launchpad as you should do before filing
[07:53] <infinity> BenC: Shame that using add_dir probably gave up a speed boost that you're about to kill again, but hey, easy come, easy go. :)
[07:53] <BenC> heh, very true
[07:53] <infinity> s/gave up/gave us/
[07:54] <Mithrandir> hmm
[07:54] <Mithrandir> I wonder if we could watershed update-initramfs too
[07:54] <Hobbsee> hey Mithrandir 
[07:55] <infinity> Mithrandir: In what respect?
[07:55] <minghua> fabbione: Now I see the bug.  But honestly, searching via82cxxx.ko in https://launchpad.net/distros/ubuntu/+bugs doesn't give me anything.  I have to go to linux-source-2.6.19's bug page.  No wonder people are filing dups. ;-)
[07:55] <fabbione> minghua: it's an initramfs bug
[07:56] <minghua> hmm, so I should mark bug 72888 as a dup of that?
[07:56] <Ubugtu> Malone bug 72888 in linux-source-2.6.19 "Linux-image-2.6.19-6-generic package should include via82cxxx.ko" [Undecided,Unconfirmed]  http://launchpad.net/bugs/72888
[07:56] <Mithrandir> infinity: avoid running it half a zillion times on upgrades.
[07:57] <infinity> Mithrandir: Give me dpkg hooks.
[07:58] <Mithrandir> infinity: give me 48 hour days and I'll get you dpkg hooks.
[07:58] <fabbione> minghua: already killed that bug
[07:58] <infinity> Mithrandir: Pfft.  Just stop sleeping.
[07:58] <Mithrandir> infinity: our puppy already does that, which is.. tiring.
[07:58] <minghua> fabbione: thanks.  sorry for the bothering.
[07:59] <minghua> I mean 2.6.17
[08:02] <_ion> Exactly what are dpkg hooks? Is it the feature that allows packages to say e.g. "run update-initramfs once after the current dpkg actions have finished"?
[08:02] <Mithrandir> _ion: basically, yes.  
[08:03] <Lathiat> ooh, thats nifty
[08:04] <Mithrandir> _ion: a reason why it hasn't been implemented is we haven't decided on the semantics should a hook command fail.  Say, update-initramfs fails because of full disk.  Are packages unconfigured?  If so, which?  Which package is responsible for handling the failure, etc.
[08:06] <_ion> For that example, my first thought is that packages should remain configured, but the user should be told to fix the problem and dpkg should exit with a non-zero exit value.
[08:07] <Chipzz> _ion: wouldn't that break behaviour; ie the behaviour as it is now is that all the packages would be unconfigured, right?
[08:08] <Mithrandir> also, what are the semantics wrt packages depending on the package with a hook?  It might not work correctly until the hook completes.
[08:08] <Chipzz> not sure if anything actually depends on that behaviour, but it doesn't sound backward compatible
[08:09] <Mithrandir> Chipzz: you could argue the hooks should be done as a virtual package which is left unconfigured if any of the hooks fail.  That'd at least make sure they would be retried on next upgrade/dpkg --configure -a
[08:10] <Mithrandir> anyway, as you see, the semantics aren't trivial so it's not a SMOP but rather an IMOS.
[08:10] <Chipzz> Mithrandir: I was actually thinking of something like a 'Post-Depends', if that makes any sense ;)
[08:10] <Mithrandir> Chipzz: postream.no-really-I-mean-it?
[08:11] <Mithrandir> or rather, postinst.no-really-I-mean-it.
[08:11] <Chipzz> well, we have Pre-Depends semantics now to express the relations between packages
[08:11] <Chipzz> hooks are the opposite in a way
[08:12] <Chipzz> Post-Depend would be a (virtual) package which the package needs to be usefull
[08:13] <Chipzz> bleh, probably not making much sense ;)
[08:13] <Mithrandir> I'm not quite sure I follow you, no. :-)
[08:13] <Chipzz> nevermind then :)
[08:13] <Chipzz> I think the best solution would be to revert the state of all packages needing that hook to unconfigured if the hook fails
[08:16] <Mithrandir> so if your scrollkeeper hook failed, you'd have the full gnome desktop unconfigured?
[08:17] <Chipzz> hrrrm
[08:17] <Mithrandir> that sounds a bit harsh.
[08:17] <Mithrandir> also, what about recommends?
[08:17] <Chipzz> I'm thinking of a way which is backwards compatible
[08:17] <Chipzz> lemme rephrase maybe
[08:18] <Chipzz> I think the best solution would be to revert the state of all packages _which where upgraded in that particular run_ needing that hook to unconfigured if the hook fails
[08:18] <Chipzz> you're of course right that if a package isn't installed/upgraded, but does depend on the hook, it shouldn't be unconfigured
[08:19] <Chipzz> though in some cases it may make sense
[08:19] <Chipzz> lets say we run ldconfig from a hook
[08:19] <Chipzz> failing to write out /etc/ld.so* would affect all packages depending on that hook, right?
[08:19] <Mithrandir> depends on how it failed.
[08:20] <Mithrandir> if it ended up writing a corrup ld.so.cache, you might be left with a broken system.
[08:20] <Chipzz> in contrast, in the scrollkeeper case, it would only affect the packages being upgraded
[08:20] <Chipzz> the corrupt ld.so.cache was what I was referring to indeed
[08:20] <Chipzz> but that's a problem we don't handle correctly atm anyway, right?
[08:21] <Chipzz> even without hooks
[08:21] <Mithrandir> it'll break at the right point right now; with hooks it'd break somewhere else (which wouldn't be deterministic)
[08:22] <Chipzz> but it's broken either way ;)
[08:23] <Chipzz> running ldconfig from a hook wouldn't be a good idea anyway I presume, since it's quite fast and low overhead
[08:23] <Chipzz> in contrast to say running scrollkeeper-update or update-initramfs
[08:29] <Chipzz> just some random brain-dump: maybe a good rule would be that something can only be a hook if it previously was the last thing being ran in a postinst (or being able to be moved to be the last thing to be run...)
[08:37] <BenC> new initramfs-tools uploaded
[09:16] <fabbione> BenC: are you sure initramfs has been accepted? i can't see the mail to -changes
[09:17] <BenC> fabbione: Subject: Accepted initramfs-tools 0.69ubuntu22 (source)
[09:17] <fabbione> BenC: ok
[09:26] <cypher1> how do i control speaker volume from an application ?
[09:58] <pitti> Good morning
[09:58] <seb128> hey hey pitti
[09:59] <seb128> pitti: how do you feel today?
[09:59] <dholbach> heya pitti
[10:04] <pitti> hey seb128, moin dholbach 
[10:05] <pitti> seb128: much better already, I finally slept again last night, and cold gets better
[10:05] <seb128> pitti: good :)
[10:06] <seb128> good luck
[10:06] <seb128> I'm fighting with the ~1000 desktop bug mails backlog
[10:12] <Mithrandir> rodarvus: do you want to tell the people in https://launchpad.net/distros/ubuntu/+source/xkill/+bug/59567 how xkill works or should I?
[10:12] <Ubugtu> Malone bug 59567 in xkill "Firefox stops responding, and claims to be running even after killing it by xkill" [Undecided,Confirmed]  
[10:15] <Chipzz> Mithrandir: I was already thinking that was a pretty stupid way of killing firefox ;)
[10:24] <minghua> pitti: do you have any idea how to fix http://paste.ubuntu-nl.org/33437/ ?
[10:24] <minghua> pitti: the package has a po/ dir but doesn't seem to be doing any i18n, and therefore an empty po/ygraph.pot
[10:25] <fabbione> minghua: remove the empty .po
[10:25] <pitti> minghua: right, as fabbione says
[10:25] <minghua> fabbione: in debian/rule's clean?
[10:25] <fabbione> minghua: yes
[10:26] <minghua> fabbione, pitti: thanks
[10:26] <pitti> 'find po/ -empty | xargs rm' or so
[10:32] <Mithrandir> dholbach: could you ask nemiver upstream to update the FSF address in the copyright notices?
[10:39] <dholbach> Mithrandir: done
[10:40] <Mithrandir> dholbach: thanks
[10:51] <Mithrandir> dholbach: you're aware that bits of nemiver is MIT and not GPL?
[10:51] <Mithrandir> (this is fine, but you should not it in debian/copyright)
[10:51] <Mithrandir> note, even
[10:55] <dholbach> Mithrandir: I'll update it, thanks for noticing.
[10:56] <Mithrandir> dholbach: if you promise to do a new upload today I'll accept rather than reject the package. :-)
[10:56] <dholbach> promise
[10:56] <dholbach> :-)
[10:57] <Mithrandir> Running: "accept nemiver"
[10:57] <Mithrandir> there, done.
[11:04] <Keybuk> sweet
[11:04] <Keybuk> so the automake source package produces the automake1.4 binary
[11:05] <Keybuk> the automake binary package is produced by the automake1.10 source
[11:05] <Spads> I remember this game.
[11:05] <Keybuk> at least the latest version has the right binary name now ;)
[11:05] <Keybuk> and the right alternatives priority
[11:05] <Keybuk> so you get 1.10, unless you force otherwise
[12:42] <pitti> Keybuk: can you please commit your hal upload into the LP bzr tree?
[12:45] <Keybuk> pitti: err, sure
[12:46] <Fujitsu> cjwatson: If you're around and have time, can you please look at and let maxima into dapper-proposed?
[12:46] <pitti> Keybuk: thanks
[12:50] <MidMark> pitti: if you have time for dvd seen as blank I'm here
[12:52] <fabbione> Keybuk: thanks for changing redhat-cluster-suite B-D
[12:54] <mjg59> Keybuk: Any joy with that patch?
[01:01] <cjwatson> Fujitsu: done
[01:01] <Fujitsu> Thanks cjwatson!
[01:09] <pitti> MidMark: ok, great
[01:09] <pitti> MidMark: let's do this in /msg
[01:09] <MidMark> pitti wait I've to register to freenod
[01:10] <MidMark> pitti: in the meantime read the bug -> https://launchpad.net/distros/ubuntu/+source/hal/+bug/14692
[01:10] <Ubugtu> Malone bug 14692 in hal "hal detects written DVD as empty" [Medium,Confirmed]  
[01:11] <Keybuk> mjg59: haven't had time to even think about looking
[01:53] <cjwatson> Keybuk: replacement-initscripts> "set up keyboard" needs to depend on /dev being set up; it needs to get at /dev/tty* for instance
[01:54] <Keybuk> cjwatson: how does that work today then? :P  you're running it before udev
[01:55] <cjwatson> that's a very good question
[01:55] <cjwatson> are static devices there before udev runs?
[01:56] <Keybuk> no ... but you'll have /dev mounted if initramfs ran :p
[01:56] <Keybuk> so that probably breaks for elmo
[01:56] <cjwatson> ok, so that probably wants to be moved to after udev
[01:56] <Keybuk> *nods*
[01:57] <cjwatson> mind you, elmo surely has static devices on /
[01:57] <cjwatson> /dev/tty[1-6]  are pretty reasonable device nodes to have lying around if you aren't using initramfs
[01:57] <Keybuk> true
[01:57] <infinity> Any box where elmo doesn't have initramfs is also likely to not have udev. :)
[01:58] <Keybuk> infinity: you'd be surprised :)  I had to help him fix one the other week
[01:58] <infinity> (Where "elmo" is "some random sysadmin who compiles monolithic kernels)
[01:58] <Keybuk> he was dipping his toes into the initramfs waters, but hadn't yet got to udev
[01:58] <Keybuk> anyway, lunch
[01:59] <heno> cjwatson: will you be considering specs for approval before the meeting today? (like braille-support)
[01:59] <Treenaks> what about old machines :)
[01:59] <Keybuk> Treenaks: they won't boot
[01:59] <Keybuk> ha ha ha
[01:59] <Keybuk> etc.
[01:59] <infinity> ide-generic disabled.
[01:59] <Treenaks> ah
[02:00] <Keybuk> something's broken there, and I'm not sure what
[02:00] <infinity> Good thing we all use apt-listchanges... Right?
[02:00] <Keybuk> ISTR that Ben said something about not using it when we had libata anyway
[02:00] <infinity> I think libata was meant to obsolete ide-generic (finally), yes.
[02:00] <infinity> But have we fully transitioned?
[02:00] <Keybuk> no
[02:01] <Keybuk> but with ide-generic enabled, machines no booty-wooty :p
[02:01] <infinity> Booting is overrated.
[02:01] <infinity> I've had to boot with a livecd to fix my feisty about 5 times since upgrading already.
[02:01] <Keybuk> really?
[02:02] <dholbach> wow
[02:02] <Keybuk> I've only had the two breakages, and could fix them both from the system itself
[02:02] <infinity> Which reminds me, has anyone larted Fabio about that "mdadm makes machines explode" bug yet?
[02:02] <infinity> Had that about a day ago.  Was too livid to file a bug without cursing.
[02:03] <Hobbsee> Keybuk: which udev is this?  feisty version seems to be 093-0ubuntu18
[02:03] <Keybuk> Hobbsee: the one I uploaded a couple of hours ago
[02:03] <Hobbsee> oh right
[02:04] <cjwatson> heno: I probably won't get to approvals until after the meeting
[02:04] <heno> ok, np
[02:04] <cjwatson> heno: I need to talk with you about braille-support anyway - there's a lot of misunderstanding of the installer in there
[02:05] <heno> probably better that way round actually
[02:05] <heno> cjwatson: ok
[02:05] <cjwatson> heno: do you know what a udeb is at all?
[02:05] <heno> cjwatson: not really, no
[02:06] <cjwatson> heno: OK, a udeb is an installer component - in terms of format it's like a deb only smaller, but ONLY udebs can be used to provide facilities within the installer, and udebs can ONLY be used within the installer and not on the installed system
[02:06] <Keybuk> cjwatson: "Ubuntu Deb" ? :)
[02:06] <bhale> apt- wants to remove libmeanwhile1 even thought it is an rdepend on gaim, nice
[02:06] <cjwatson> Keybuk: :P
[02:07] <gnomefreak> infinity: i thought he fixed mdadm already. (unless you mean something else by explodes) ;)
[02:07] <cjwatson> heno: braille-support should not be talking about the "server install" - d-i is used in contexts other than server installations
[02:08] <heno> right, parts are used in ubiquity I guess
[02:08] <cjwatson> heno: irrelevant here
[02:08] <heno> and alternate of course
[02:08] <cjwatson> heno: d-i is also used for OEM installations, LVM/RAID (non-server), etc.
[02:08] <heno> ok
[02:09] <cjwatson> and places where the desktop CD just doesn't work
[02:09] <heno> right
[02:09] <heno> and that's where the debian braille udeb might e useful
[02:09] <heno> AFAIU
[02:10] <cjwatson> it's the only place it can possibly be useful :)
[02:10] <cjwatson> heno: anyway, my point is that there is no need for the specification to justify the use of brltty-udeb in the alternate installer - it's not possible to use anything else
[02:11] <cjwatson> at the moment, Debian appears to be including brltty-udeb in its installer images, so it probably works pretty well
[02:11] <heno> right. On the live CD we would use Orca with it's braille support
[02:11] <cjwatson> it's done by means of a brltty= boot parameter
[02:12] <cjwatson> see http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=355851
[02:12] <Ubugtu> Debian bug 355851 in brltty "Re: a blindunfriendly debian installer problem" [Wishlist,Closed]  
[02:12] <heno> ok, so inluding it is non-controvertial 
[02:13] <heno> cjwatson: thanks I'll polish the spec with this feedback in mind
[02:15] <cjwatson> heno: in fact, apparently the way it's set up in Debian at the moment is that brltty is automatically started if a USB Braille device is detected; you only need to supply brltty= as a boot parameter if you need a serial device
[02:15] <cjwatson> (or whatever)
[02:17] <heno> cjwatson: is it installed in debian by default?
[02:17] <cjwatson> heno: if the script described in the Implementation section is a shell script (preferable) or a C program (possible), then it can be run in d-i
[02:17] <heno> cjwatson: we installed it during dapper, but then disabled the automatic loading
[02:17] <cjwatson> heno: in the installed system? I don't know
[02:18] <cjwatson> heno: it's loaded as an installer component by default, AFAICS
[02:18] <heno> cjwatson: a default install always makes it more controversial :)
[02:18] <cjwatson> heno: "language: should this be python or a shell script?" <- if it's in python then you can't use it in d-i
[02:18] <heno> esp. if it may do odd things
[02:18] <cjwatson> so I recommend a shell script
[02:20] <cjwatson> heno: we made sure the daemon doesn't start by default on most systems; I have no problem with automatically starting the daemon if a Braille device is physically present, though
[02:20] <cjwatson> heno: detecting USB devices is done by udev rules
[02:20] <heno> I wasn't actually planning to call it from (or before) d-i, but that would also help 
[02:20] <cjwatson> those exist in brltty-udeb already
[02:21] <cjwatson> heno: I think we should
[02:21] <cjwatson> most of the work has already been done
[02:21] <heno> right, so if F5+6 happens and no USB device is found
[02:21] <heno> run the script no matter what system it is
[02:21] <heno> cool!
[02:23] <heno> cjwatson: does udev need more information about braille devices to do the right thing (start the deamon) or should that all be working already?
[02:23] <popey> Whats the procedure if someone wants an app to move from universe to main?
[02:24] <Hobbsee> popey: please see the /topic
[02:24] <Hobbsee> popey: developer resources page, there is a link to https://wiki.ubuntu.com/UbuntuMainInclusionRequirements
[02:25] <cjwatson> heno: it just goes on vendor/product ids; see debian/brltty-udeb.udev.rules in the brltty source package
[02:26] <heno> ok, cool
[02:26] <popey> excellent, thanks Hobbsee 
[02:26] <cjwatson> heno: the way it works at present in Debian is that if you used it in the installer it gets configured in /etc/brltty.conf in the target system; I don't know if that's quite right, and we should maybe use the udev rules in both places or something
[02:27] <cjwatson> heno: you might want to get Keybuk to have a look over it
[02:28] <heno> Ideally it should pick up a USB device whenever it's plugged in
[02:28] <heno> ie. added to the system later
[02:29] <heno> I emailed with Keybuk about it before writing the spec
[02:35] <Hobbsee> heno: http://sackheads.org/~bnaylor/spew/away_msgs.html
[02:40] <jpatrick> Hobbsee: i have the impression he's not here anymore
[02:41] <_ion> He'll surely see the message when he returns.
[02:41] <Hobbsee> jpatrick: true.  i could have removed him with that message, that is my normal practice
[02:56] <DaSkreech> Hello 
[02:56] <DaSkreech> Does the Live CD support LVM?
[02:56] <DaSkreech> Installing to LVM that is?
[02:57] <hunger> DaSkreech: AFAIK you need the alternate CD for that (and the expert mode there).
[02:58] <DaSkreech> there are no plans to support it in ubuiiquity
[02:58] <DaSkreech> ?
[02:58] <hunger> DaSkreech: Dunno.
[02:58] <hunger> DaSkreech: I am just a user.
[02:59] <DaSkreech> OK :-) I wasn't asking you personally. Just kinda in general
[03:01] <Keybuk> heno: I'd still like to read the finished spec
[03:04] <heno> Keybuk: sure, I'll ping you after updating it
[03:13] <frafu> heno: out of curisity: what spec are you talking about? 
[03:14] <heno> frafu: https://wiki.ubuntu.com/Accessibility/Specs/BrailleSupport
[03:15] <frafu> thanks
[03:16] <cjwatson> DaSkreech: it's planned, but only sketchily and some way in the future
[03:16] <cjwatson> hunger: you do not need expert mode to install to LVM
[03:17] <DaSkreech> Ok thanks cjwatson
[03:17] <cjwatson> DaSkreech: (it's dependent on a rewritten partitioner in ubiquity)
[03:20] <hunger> cjwatson: Are you sure? I am pretty certain that I could not use LVM when installing edgy in non-expert mode.
[03:20] <cjwatson> hunger: yes, I'm sure
[03:21] <hunger> cjwatson: Well, maybe I just missed the option... I could set up LVM partitions, but I could not figure out how to set up VGs and LVs on top of those.
[03:22] <cjwatson> hunger: "Configure the Logical Volume Manager" up at the top
[03:22] <cjwatson> partman in general is not terribly sensitive to expert mode, which is why I'm sure
[03:22] <hunger> cjwatson: Must have missed that, sorry for spreading misinformation.
[03:23] <cjwatson> there is no provision at present for the set of options presented in a given select list to depend on the debconf priority
[03:23] <cjwatson> (unless you compute it by hand, which partman doesn't)
[03:23] <hunger> cjwatson: When I ran the last install before that edgy thing the LVM stuff was shown after the partitioning.
[03:24] <hunger> cjwatson: That is where I was looking for it.
[03:24] <cjwatson> hunger: I don't recall that ever being the case
[03:25] <cjwatson> AFAIK you've always had to select "Configure the Logical Volume Manager"
[03:25] <cjwatson> the exact layout may have changed a bit but I'm pretty sure it's always been an option on that screen
[03:25] <hunger> cjwatson: Maybe I am wrong, or messing it up with debian or something. I rarely install Linux these days.
[03:26] <DaSkreech> so is there a roadmap on the partitioner?
[03:46] <cjwatson> DaSkreech: https://launchpad.net/distros/ubuntu/+spec/ubiquity-advanced-partitioner
[03:48] <DaSkreech> so possible feisty+1
[03:48] <DaSkreech> Grumpy Gorrila?
[03:57] <Keybuk> (0ubuntu2 didn't work for anyone with a SCSI, SATA or libata card :p)
[04:10] <rodarvus> Keybuk, you mentioned you would make feisty unbootable soon, but that was very quick :P
[04:13] <jsgotangco> Lol
[04:13] <DaSkreech> cjwatson: Thanks a lot ;_)
[04:13] <DaSkreech> I'm off now
[04:28] <zul> when is the dev team meeting?
[04:28] <zul> er..distro
[04:28] <seb128> 5utc
[04:28] <cjwatson> 95 minutes from now
[04:28] <seb128> 1.5 hour from now
[04:28] <zul> thanks
[04:55] <heno> Keybuk: I've tightened the braille spec up a: https://wiki.ubuntu.com/Accessibility/Specs/BrailleSupport Let me know if kit needs more detail WRT to udev or upstart
[05:56] <cjwatson> development team meeting in 7 minutes in #ubuntu-meeting
[06:04] <cjwatson> infinity,keescook: ping
[06:04] <cjwatson> (#ubuntu-meeting)
[06:20] <Keybuk> Whiteboard changed to:
[06:20] <Keybuk> Tollef has received training and is now working as an archive team
[06:20] <Keybuk> member.
[06:20] <Keybuk> -- 
[06:20] <Keybuk> see, I would have written that "Tollef is now our bitch"
[06:20] <fabbione> Keybuk: you wish :)
[06:20] <bhale> seems a bit like tollef gets thrown anywhere that is too scary for everyone else
[06:21] <Keybuk> bhale: that's because he's a robot
[06:21] <kylem> robots can handle hazardous environments...
[06:22] <Mithrandir> beep!
[06:23] <cypher1> i get "permission denied" when echo'ing to /proc .. what am i missing ?
[06:23] <PuMpErNiCkEl> Permission?
[06:23] <stgraber> maybe you just don't have the permissions ?
[06:23] <thom> you're missing that you're in a _dev_ channel asking _support_ questions
[06:23] <pitti> cypher1: if you tried 'sudo echo > /proc/' -> #ubuntu
[06:24] <cypher1> pitti, just found out using "sudo" wont work
[06:24] <cypher1> pitti, we have to do "sudo -s" and then echo as root
[06:24] <bhale> sudo echo > doesnt work
[06:24] <kylem> echo foo | sudo tee
[06:24] <bhale>  > is a function of the shell, sudo doesnt work on it.
[06:24] <spike> I'm suing these 3 lines in my preseed config file:
[06:24] <spike> d-i mirror/http/hostname string gb.archive.ubuntu.com
[06:24] <spike> d-i mirror/http/directory string /ubuntu
[06:24] <spike> d-i mirror/suite string dapper
[06:25] <spike> but now I'd like to add universe repo and I'm not entirely sure on how to do that
[06:25] <spike> I dont even see "main" specified in there...
[06:25] <spike> just took it from the preseeding example
[06:27] <cjwatson> spike: 'd-i apt-setup/universe boolean true'
[06:27] <cjwatson> spike: the edgy installation guide documents this
[06:27] <cjwatson> (in the preseeding appendix)
[06:31] <spike> cjwatson: oh, I see, thanks
[06:31] <Keybuk> iwj, pitti: imo, dbus should just do what upstart does ... it can be restarted quite happily
[06:32] <pitti> Keybuk: as I said, this would need to iterate over all session dbuses as well, and that would be a novum (packages touching user processes)
[06:32] <pitti> I'm not sure whether an old session dbus and a new sytem dbus would play well
[06:33] <pitti> (although it should work)
[06:33] <slomo_> pitti: notification-daemon does this already... "killall notification-daemon" in postinst
[06:33] <slomo_> and session/system bus have no connection between each other so that's no problem
[06:33] <pitti> ok
[06:34] <iwj> Keybuk: No, I don't think that's sufficient.  We want to survive dbus crashing too, right ?
[06:34] <iwj> So it has to be done in the library.
[06:34] <Keybuk> heh
[06:34] <Keybuk> I guess upstart crashing is ... less of a problem
[06:34] <iwj> *snort*
[06:34] <iwj> And the session bus is started by the session manager and we could just put a wrapper round it to restart it.
[06:35] <iwj> If the library would cope then it would all be fine.
[06:35] <iwj> You might have a bit of lossage at the time but bugs => lossage.
[06:35] <iwj> But I need to understand the protocols and use cases better.
[06:36] <iwj> wrapper> or some mad session upstart plan of course.
[06:36] <iwj> Keybuk: BTW, I can't remember where we ended up with the upstart config stuff.
[06:37] <Keybuk> iwj: I haven't dug out those notes yet
[06:37] <Keybuk> that's somewhere on my todo for next week
[06:37] <iwj> Right.  Let me know when you get round to it and what you decide.
[06:37] <iwj> Feel free to ping me or phone me to talk about it, too.
[06:37] <spike> cjwatson: another thing: I've got a serial console to this box. if I do a manual install, it works fine. with preseeding it just hangs after booting the pxe kernel
[06:38] <spike> cjwatson: I've dumped traffic a looked at logs, the request for the preseed file is never issued
[06:38] <spike> any idea what that could be?
[06:38] <spike> it's a pain not being able to monitor stuff via sc
[06:38] <spike> plugged in a monitor for the time being
[06:38] <cjwatson> spike: you need to preseed locale/keyboard stuff on the command line - d-i doesn't bring up the network straight away
[06:39] <cjwatson> I'm sure it's sitting there at the locale question
[06:39] <spike> cjwatson: erg, sorry, missed a detail :). preseed works fine without the serial console
[06:39] <Burgwork> Keybuk: ping
[06:40] <spike> cjwatson: so I dont think it's that
[06:40] <Keybuk> Burgwork: yo
[06:40] <spike> cjwatson: to summarize: manual + sc = fine, preseed - sc = fine , preseed + sc = breaks
[06:40] <cjwatson> spike: I'm in a meeting right now and will be leaving right afterwards, but perhaps you could mail me details of your setup and the problem
[06:40] <Burgwork> Keybuk: your blog is almost the same as https://wiki.ubuntu.com/LookingFowardAtFeisty Mind if I crib off it?
[06:40] <spike> that'd be great, thanks a lot
[06:40] <spike> cjwatson: to which address shall I contact you?
[06:41] <Keybuk> Burgwork: sure
[06:41] <Burgwork> Keybuk: if you want to edit that page, please feel free
[06:41] <cjwatson> spike: cjwatson@ubuntu.com
[06:41] <Keybuk> note that I didn't mention telepathy much, because it's more of a "underneath feature that will be cool in later releases"
[06:41] <cjwatson> Burgwork: "Forward"
[06:42] <Burgwork> cjwatson: oops. it was late
[06:42] <spike> cjwatson: ok, will send it tonight or tomorrow morning at worst. thanks a lot for your time
[06:42] <cjwatson> np
[06:47] <iwj> pitti: So the problem is this:
[06:47] <iwj> If I hibernate my machine, and then boot the desktop cd, and the desktop cd has grown the ability to spot my fs's and mount them, then:
[06:47] <iwj> The desktop cd will replay the journals of my fs's into the fs's while the hibernated install has them mounted.
[06:48] <iwj> Then later I resume the hibernated system and it keeps using the filesystems.
[06:48] <pitti> ah, right
[06:48] <iwj> Result: hideous filesystem nightmare corruption doom.
[06:48] <Mithrandir> iwj: so it shouldn't mount dirty fs-es.
[06:48] <iwj> Right.
[06:48] <iwj> This actually trashed my Ubuntu install at UBZ.
[06:49] <Mithrandir> the current livecd doesn't automount partitions, so that would have been through some action of yours though.
[06:49] <Mithrandir> in which case I'm a little less concerned.
[06:49] <iwj> Mithrandir: Indeed.  But isn't MountAllLocalFilesystems supposed to change that ?
[06:49] <pitti> we'll not do automatic mounting of partitions anyway
[06:49] <iwj> And anyway it happens if you dual boot, too.
[06:50] <iwj> Err, are you using `partition' to mean `on a hard disk' here ?
[06:50] <pitti> right, I do; sorry
[06:50] <iwj> Ie, distinguishing those from usb-storage.
[06:50] <iwj> Well, the problem exists with usb-storage too.
[06:50] <iwj> Do we automatically unmount usb-storage before hibernating ?  More to the point, does everyone ?
[06:50] <pitti> hm, people hibernate on removable partitions which aren't in fstab?
[06:51] <iwj> No, no, you misunderstand.
[06:51] <iwj> This trashing doesn't just happen to the disk you hibernate onto.
[06:51] <iwj> It happens to any disk mounted by the hibernated install, when during the hibernation another setup mounts it.
[06:51] <pitti> ah, I see
[06:51] <pitti> (sorry, half of brain is in meeting)
[06:51] <iwj> :-)
[06:52] <mjg59> Removable storage vanishes on hibernation right now
[06:52] <pitti> iwj: is there a way to tell if a partition is dirty?
[06:52] <mjg59> pitti: Not generically
[06:52] <pitti> if so, then we should generally refuse to gnome-/automount dirty partitions
[06:53] <pitti> mjg59: but for a particular fs type, I assume?
[06:53] <iwj> Note that journaled fs's generally replay the journal to the disk even if you mount readonly.  (!!!)
[06:53] <mjg59> pitti: Yes. You need to in order to know whether to fsck or not
[06:53] <iwj> TMBSNMOTW "readonly" OWIWPU etc.
[06:53] <mjg59> iwj: The fs wouldn't necessarily be consistent otherwise
[06:53] <iwj> mjg59: Well, duh.
[06:54] <iwj> Obviously I don't mind getting EIO for some of the contents.
[06:54] <mjg59> Semantically, "readonly" has two meanings
[06:54] <mjg59> But there's only one option
[06:54] <iwj> It used only to have one meaning and nowadays it has silently changed to let the fs write to the disk.
[06:54] <iwj> Mounting a dirty ext2 also involved mounting a possibly-inconsistent fs and you were supposed to fsck first.
[06:55] <iwj> But no-one suggested that you should fsck before mounting ro!
[06:55] <iwj> I can't believe you're defending this crazy behaviour.
[06:56] <mjg59> That didn't fit my recollection, but on checking the code, you're right
[06:58] <iwj> Err, I meant "before Linux hard journaled fs's" so I don't understand what you were checking.
[06:58] <mjg59> ext2 will print a warning about mounting an unchecked fs
[06:58] <iwj> Yes.
[06:58] <mjg59> But skips that if you mount it read-only
[06:58] <iwj> Obviously.  I don't mind it printing warnings.
[06:59] <iwj> OIC.
[06:59] <iwj> Yes.  But that's not my point.
[07:00] <iwj> Supposing ext2 fsck built into the kernel for some reason.  Then no-one would have tolerated it running that and writing to the disk when told to mount ro.
[07:07] <Keybuk> cjwatson: five second summary; new_id and bind aren't available to udev because the uevents come in too early
[07:07] <Keybuk> and because they're a function of the *driver*, something udev has no information about, and no mapping from modules to drivers
[07:07] <Keybuk> this needs fixing in the kernel
 I think the X driver saves the registers
[07:09] <fabbione> cjwatson: not always.. some drivers almost reinit the card each time you switch stuff around like console <-> X
[07:10] <mjg59> fabbione: But they try to switch back to whatever mode you switched out of
[07:10] <fabbione> mjg59: true
[07:11] <mjg59> So if we want to switch back to text mode, we need to switch out of text mode
[07:11] <lamont> pitti: got a minute?
[07:11] <lamont> pitti: why does gvm say this in it's logfile: A security policy in place prevents this sender from sending this message to this recipient, see message bus configuration file (rejected message had interface "org.freedesktop.Hal.Device.Volume" member "Mount" error name "(unset)" destination "org.freedesktop.Hal")
[07:11] <pitti> lamont: in meeting, but I'll answer in a bit
[07:11] <lamont> pitti: want me to email you all 5 files?
[07:11] <Mithrandir> mjg59: ok, since it's per-driver, that won't work.  We can't work around that somehow either, I presume.
[07:12] <pitti> lamont: probably you tried to mount a non-removable file system?
[07:12] <pitti> lamont: sure, mailing log files is fine
[07:12] <lamont> pitti: nope.  worked fine under dapper, dist-upgrade to edgy --> borked.
[07:12] <lamont> pmount /dev/sdg1 works just fine
[07:12] <mjg59> Mithrandir: Not in any way that springs to mind
[07:13] <mjg59> Mithrandir: Best we could manage would be to use vesafb, but then we have suspend/resume nightmares
[07:13] <pitti> lamont: or there is something wrong with libpam-console
[07:13] <mjg59> Mithrandir: Hm. Actually...
[07:13] <pitti> lamont: erm, s/pam-console/pam-foreground/
[07:13] <dade`>  me fa ridere
[07:13] <pitti> lamont: ok, I'll look at the logs
[07:13] <mjg59> If we could fix vesafb so it can be unregistered and unloaded...
[07:13] <mjg59> We might be able to make that fly
[07:14] <mjg59> Mithrandir: I'll look into that. I can't promise anything, though.
[07:15] <Mithrandir> mjg59: that'd "just" require vesafb to save the state when it's loaded, wouldn't it?
[07:15] <Mithrandir> and then restore that on unload.
[07:16] <mjg59> Mithrandir: No
[07:16] <mjg59> Mithrandir: vesafb is in-kernel. It can't make vesa calls.
[07:17] <Mithrandir> point
[07:17] <Mithrandir> unless we embed x86emu in the kernel
[07:17] <mjg59> Haha. NO.
[07:20] <Mithrandir> ok, that was a bad idea. :-)
[07:41] <tkamppeter> cjwatson, sfllaw, should I put a new SRU request into the bug report, with the successful test by the original poster and Scott's review of the UDEV rules as justification, and with the debdiff of the new 2ubuntu2 version?
[07:41] <tkamppeter> cjwatson, sfllaw, it is about bug 65618
[07:41] <Ubugtu> Malone bug 65618 in foo2zjs "Firmware upload to LJ 1000/1005/1008/1020 broken (fix to be proposed as Edgy update)" [Medium,Fix committed]  http://launchpad.net/bugs/65618
[07:44] <tkamppeter> cjwatson, sfllaw, I cannot upload the fix to edgy-proposed, as I do not have upload access rights.
[07:44] <sfllaw> cjwatson: Yes, put a new SRU request.  Send an e-mail.  Tag the bug.
[07:44] <sfllaw> tkamppeter: ^^^
[07:44] <sfllaw> tkamppeter: You will want to get someone here to upload the package for you.
[07:45] <cjwatson> BTW, "udev" is not an acronym
[07:45] <tkamppeter> pitti, can you upload the update from bug 65618 to edgy-proposed as soon as the SRU is approved? Thanks.
[07:45] <Ubugtu> Malone bug 65618 in foo2zjs "Firmware upload to LJ 1000/1005/1008/1020 broken (fix to be proposed as Edgy update)" [Medium,Fix committed]  http://launchpad.net/bugs/65618
[07:45] <pitti> tkamppeter: sure, please ping me once it is approved
[07:45] <cjwatson> I'll look at it tomorrow
[07:45] <cjwatson> have to run now, I'm afraid
[07:46] <tkamppeter> sfllaw, how should I tag the bug, with what? I have already subscribed it to the SRU team.
[07:46] <tkamppeter> And state is "Fix committed".
[07:46] <cjwatson> tkamppeter: please read the StableReleaseUpdates wiki page; it has all the information
[07:47] <tkamppeter> sfllaw, what is your e-mail address? Or should I mail to the SRU team?
[07:47] <Burgwork> cjwatson: GNOME is turning on AT stuff during their dev cycle as well
[07:47] <cjwatson> no need to mail the SRU team; I am aware
[07:47] <cjwatson> Burgwork: I'll discuss later
[07:48] <Burgwork> cjwatson: just wanted to tell you. Nothing to discuss, really
[07:48] <sfllaw> tkamppeter: In the "Edit Description" field, you can add tags.
[07:48] <cjwatson> but the one-line summary is that it is generally a mistake to turn things on during development that are difficult to turn off on upgrade to final
[07:48] <cjwatson> at least for us, since we have many people who install development releases and upgrade
[07:49] <tkamppeter> cjwatson, I have found what you meam, tagging comes in a later step.
[07:49] <bhale> cjwatson: it isnt the Ubuntu Device Explosion Five?
[09:02] <dade`> gaim keeps crashing, grr
[09:10] <tahorg> hi
[09:10] <tahorg> who is maintaining mysql-server-5.0 ?
[09:10] <tahorg> looks like a direct import from debian
[09:11] <robertj__> ooh the "Ask Mark" hour looks fine..."So Mark, are you...a Goer eh? You know, do you go?"
[09:12] <tahorg> https://bugs.launchpad.net/distros/ubuntu/+source/mysql-dfsg-5.0/+bug/45694
[09:12] <Ubugtu> Malone bug 45694 in mysql-dfsg-5.0 "Socket missing with mysqld" [Medium,Unconfirmed]  
[09:12] <mc44> *Python jar
[09:13] <tahorg> the title is bad, it's more precisely "mysqld is TOTALLY BROKEN on amd64"
[09:24] <Mithrandir> tahorg: no, it's not.  It's just broken on intel em64t.
[09:25] <Mithrandir> (due to a gcc bug)
[09:25] <tahorg> Mithrandir: ho, I see.
[09:25] <tahorg> Mithrandir: is there any way to workaround it with a gcc option ?
[09:25] <tahorg> (I was removing the PREFETCH macros in the code)
[09:27] <Mithrandir> tahorg: compiling it with -march=x86_64 should work, I'd think
[09:28] <tahorg> Mithrandir: ok thanks
[09:28] <Mithrandir> or -mno-3dnow
[09:35] <giskard> Mithrandir, news about NM ?
[09:36] <Mithrandir> giskard: no, not yet.  ETOOBUSY
[09:36] <giskard> no problem :)
[09:45] <Riddell> how oh how do I get emacs to let me edit .diff files?
[09:45] <Mithrandir> M-x toggle-read-only
[09:46] <Riddell> perfect, thanks
[10:11] <mdke_> [OT]  can anyone share a procmail recipe for filtering wiki/spec mail?
[10:16] <stgraber> mdke_: I think I have one, let me check
[10:17] <stgraber> mdke_: http://paste.ubuntu-nl.org/33537/
[10:18] <mdke_> stgraber: why thanks
[10:45] <shawarma> I have a Edgy system, I installed via debootstrap, so that might the reason why, but having a /dev/root with mode 644 does not seem right... 
[10:46] <shawarma> Have you all upgraded to Feisty yet, or can any of you confirm the presence and/or the need for that file?
[10:54] <Adri2000> shawarma: ls: /dev/root: No such file or directory
[10:55] <jdong> following mdke_'s format....
[10:55] <jdong> [OT] : What's the best way to get Xen on Dapper?
[10:55] <shawarma> jdong: I think there'a howto on the wiki somewhere.
[10:56] <jdong> shawarma: yeah, a few howtos on the wiki
[10:56] <jdong> all slightly different from each other :)
[10:56] <jdong> and even more to be found with googling
[10:56] <shawarma> Adri2000: Ok. Thanks for checking. It must be a leftover from somewhere in my installation process.
[10:58] <frandavid100> hi guys
[10:58] <mdke_> jdong: great opportunity to tidy up the howtos!! maybe make one howto to rule them all on help.u.c
[10:58] <frandavid100> can someone tell me how to create a new screensaver from an existing one?
[10:59] <jdong> mdke_: hehe, I'll do that if I ever figure out how to set up Xen :)
[11:00] <mdke_> :)
[11:02] <ajmitch> there are multiple howtos since xen isn't exactly supportable on pre-edgy
[11:02] <ajmitch> not without grabbing stuff from edgy, or rolling your own
[11:05] <jdong> ajmitch: I was considering going with xen sources and rolling my own
[11:05] <jdong> ajmitch: I guess I'll improvise :)
[11:06] <jdong> Edgy Xen hypervisor didn't boot on my machine, which puzzled me
[11:06] <jdong> maybe I'm trying to use xen on a cursed machine
[11:06] <jdong> oh well, what the heck else am I supposed to do on thanksgiving?
[11:06] <Spads> thankstaking
[11:07] <jdong> Spads: get all the camping gear ready for black friday day :)
[11:08] <ajmitch> hi Spads, you heard that the latest kernel I got off zul booted a bit further?
[11:11] <Spads> ajmitch: when?
[11:11] <Spads> jdong: which black friday is that then?
[11:11] <ajmitch> Spads: hm, a day or so ago
[11:11] <jdong> Spads: tomorrow, silly :)
[11:12] <Spads> ajmitch: yeah, I've been able to boot into the hypervisor, but never been able to get a guest up, in i386 *or* amd64
[11:12] <Spads> jdong: oh, what does camping gear have to do with it?
[11:12] <ajmitch> Spads: not even with 2.6.16 & loading the appropriate modules manually?
[11:13] <Spads> tomorrow is simply the day that americans justify building shopping mall parking lots at 300% capacity
[11:13] <jdong> Spads: if you want all the good stuff you gotta camp for em :)
[11:13] <ajmitch> what a country..
[11:13] <jdong> Spads: at least around my place you do
[11:13] <jdong> Spads: in fact, at this point there's 200-long lines at a few stores already....
[11:13] <Spads> jdong: I don't know that they do much of that in London
[11:13] <jdong> there goes my RAID 
[11:14] <jdong> Spads: we US guys are crazy I guess :D
[11:14] <HrdwrBoB> call me crazy
[11:14] <HrdwrBoB> but I'd much rather sit at home in comfort
[11:14] <Spads> I've never shopped on the day after thankstaking
[11:14] <HrdwrBoB> and go the next day and pay full price
[11:15] <HrdwrBoB> than fight hundreds of people
[11:15] <jdong> HrdwrBoB: ah, but see, I'm asian :)
[11:15] <jdong> (j/k)
[11:17] <jdong> that looks a lot more simple to set up :D
[11:17] <Spads> jdong: let me know how that works for you
[11:17] <ajmitch> Spads: I've had no problems with xen on i386, at least
[11:18] <ajmitch> I just haven't tried i386 xen on the amd64
[11:18] <jdong> ajmitch: I couldn't get the hypervisor to boot on one of my amd64's in 64-bit
[11:18] <ajmitch> hopefully in a day or two
[11:18] <jdong> ajmitch: I'm guessing it's PEBKAC though
[11:18] <ajmitch> jdong: couldn't get the hypervisor to go, or the kernel didn't boot?
[11:19] <jdong> ajmitch: I think it's the hypervisor
[11:19] <jdong> ajmitch: I get less than half a screenful of text and then a reset
[11:19] <ajmitch> ok
[11:19] <jdong> ajmitch: so I couldn't really determine if it was the hypervisor or trying xen0
[11:19] <jdong> it was an AMD64 with LVM/device-mapper
[11:19] <jdong> so it might've been an unusual setup
[11:19] <ajmitch> hardly unusual
[11:20] <jdong> ah, ok
[11:20] <jdong> maybe I just gave up too early then
[11:20] <jdong> ajmitch: though I would expect mkinitramfs to put in all the modules that all my other initramfs'es have?
[11:20] <ajmitch> sure, but I wasn't using a packaged kernel as such
[11:21] <jdong> ah, ok
[11:21] <ajmitch> the only bit I copied in over the existing xen image was vmlinuz
[11:22] <jdong> mmm I see
[11:22] <jdong> well, off to reboot into xen
[11:23] <jdong> hope for the best :)
[11:25] <ajmitch> Spads: 2.6.16 is known to work with xen on amd64, as long as you load the appropriate modules in order to start guests
[11:26] <Spads> ajmitch: oh?
[11:27] <Spads> ajmitch: which modules?
[11:29] <ajmitch> blkbk, xenblk, and there was one other iirc
[11:29] <ajmitch> let me just look it up
[11:30] <Spads> hmmmm
[11:30] <ajmitch> they were previously loaded by the xend initscript
[11:31] <Spads> that begs the question...
[11:31] <ajmitch> why aren't they now? because they were compiled in for 2.6.17
[11:31] <Spads> Ah, right
[11:32] <ajmitch> blkbk, netbk, netloop
[11:39] <Spads> hmmmmmm
[11:39] <Spads> thanks
[11:40] <ajmitch> something is working?
[11:44] <Spads> ajmitch: no, I'll have to try that tomorrow after I reinstall the amd64 version
[11:48] <ajmitch> alright
[11:48] <zul> Spads: can you try a kernel im building as well tomorrow
[11:48] <ajmitch> hey zul 
[11:48] <zul> hey ajmitch 
[11:49] <Spads> zul: what sort?
[11:50] <zul> its another amd64 kernel
[11:50] <Spads> okay, I'll give both a try
[12:02] <jdong> ajmitch / Spads : wow, it worked quite nicely
[12:02] <jdong> the only thing that didn't work stably was fglrx
[12:03] <jdong> I hacked it to compile cleanly....
[12:03] <jdong> but on any glx app I get a kernel oops