[12:11] <Enola_Gay> cu all
[12:13] <Draconicus> Your distro is making me think about taking up drinking. ._.
[12:16] <shawarma> Draconicus: Because it's so easy to use that being drunk won't matter?
[12:17] <Draconicus> shawarma: Naw... Because if, god forbid, something unusual happens and something goes wrong, you'll never, ever be able to figure out the cause of it all. ._.
[12:17] <Draconicus> Though chances are at this point that my problem is tragically hardware related.
[12:18] <Draconicus> And I don't mean generic problems or distro bugs..
[12:18] <shawarma> Draconicus: You think Ubuntu is harder to debug than other distros?
[12:18] <Draconicus> No... Actually it's about the same.
[12:18] <Draconicus> Linux is Linux is Linux.
[12:18] <Draconicus> I just felt like poking fun at the subject matter. Nothing personal.
[12:19] <Draconicus> It's not like I'm interrupting some vital conversation or something. This channel has cobwebs. :P
[12:19] <Draconicus> Though on the off chance that I AM disrupting such a conversation... sorry. 
[12:19] <shawarma> Draconicus: it's the weekend.
[12:19] <Draconicus> You're a weekend! D:<
[12:20] <Draconicus> Anyway, I'll go away now. Toodles.
[12:20] <shawarma> cheers
[12:20] <Draconicus> Happy developing. You really do have a wonderful distro, despite my silly comments. :)
[01:33] <smithj> the ubuntu-patches mailing list seems to have not gotten any patches since march 7. given that i don't think ubuntu has ceased development, what's up with that?
[01:34] <smithj> see https://lists.ubuntu.com/archives/ubuntu-patches/2007-March/date.html as a reference
[01:44] <cjwatson_> smithj: I believe that's because the machine running that has run out of disk space; there's a sysadmin ticket open for it
[01:44] <smithj> cjwatson_: is that ticket open to the non-ubuntu-masses to follow?
[01:45] <cjwatson> afraid not, but it's not exactly interesting
[01:45] <smithj> ok
[01:45] <cjwatson> "dear sysadmins, casey ran out of disk space, love Scott" ;-)
[01:45] <smithj> thanks for the info
[01:45] <smithj> well, its been out for almost a month now :-/
[01:45] <cjwatson> yeah, but the sysadmins are largely busy relocating Canonical HQ to a new office
[01:45] <smithj> ah
[01:46] <_ion> One would think the "ran out of disk space" problem would be easy to prevent in advance. ;-)
[01:46] <cjwatson> _ion: ?
[01:46] <smithj> nagios ftw
[01:47] <cjwatson> (a) that doesn't prevent you running out of disk space, merely ensures you know about it (b) the Canonical sysadmins already use nagios
[01:47] <_ion> cjwatson: For example, use one of the tools available to draw a graph of the free disk space on each server and tell one of the employees to take a look at them every once in a while.
[01:47] <cjwatson> _ion: I suppose you might also quit patronising the admins ...
[01:48] <cjwatson> (hello, obviously this is done, that doesn't mean there's always time to deal with it when lots of other stuff is going on.)
[01:49] <cjwatson> and I know it's done because when machines where I'm responsible for services are running low on disk space, one of the admins asks me to have a look at it well before it's critical
[01:52] <cjwatson> however, the problem was being escalated as of when I last heard about it on Thursday, so
[01:52] <smithj> not to be overly pestersome (if thats a word), but isn't patch mail a critical system? without overview of changes, anyone with commit access could knowingly commit a security flaw... even if you trust them not to do that, commit mail is essential to code review...
[01:53] <cjwatson> that would be true if we used that service for code review ;-)
[01:54] <smithj> even if canonical doesn't use it for code review, the community might want to
[01:54] <cjwatson> I hope it will come back before feisty releases
[01:54] <smithj> ok. i anxiously await :)
[02:17] <shawarma> cjwatson: Still around?
[02:18] <cjwatson> shawarma: just ...
[02:18] <shawarma> cjwatson: Since at least a few weeks ago I've been unable to install feisty in qemu. It boots fine, but after that it's unable to detect either the emulated hard drive or the cdrom. Tollef thought my might be able to tell at a glance what was wrong.
[02:18] <cjwatson> I can have a quick look at syslog if you have it handy
[02:19] <cjwatson> or if you give me a recipe that somebody with no brain at 1:20am can follow
[02:20] <shawarma> cjwatson: Simple: Download a recent feisty image (anything since at least the beta will do), do a "qemu-img create hda.img 5G; qemu -cdrom ubuntu-feisty-server.iso -hda hda.img -m 128", wait for little while, and do your magic thing.
[02:22] <cjwatson> several ata exceptions on boot there
[02:22] <shawarma> cjwatson: Yes. Those went away witht the updates the day before yesterday, but the problem remains.
[02:22] <shawarma> cjwatson: I should have mentioned that.
[02:25] <shawarma> cjwatson: Specifically, the exceptions went away with the d-i update which made it into dailies 20070330.1 and onwards.
[02:25] <cjwatson> detects the hard disk fine here but not the CD
[02:25] <cjwatson> nothing in /sys/block other than ramdisks etc. and sda
[02:25] <shawarma> cjwatson: Do you actually have access to the hda block device or does the boot log just mention its existence?
[02:26] <shawarma> cjwatson: sda? That's odd.
[02:26] <cjwatson> it's sda, and udev certainly knows about it
[02:26] <cjwatson> this is a slightly old alternate CD
[02:26] <shawarma> cjwatson: That might be interesting. How old?
[02:26] <cjwatson> not really surprising though? presumably it's just libata doing its thing
[02:26] <cjwatson> not that old, 2.6.20-12 kernel of some vintage
[02:27] <shawarma> cjwatson: Oh, /dev/hd[a-z]  is history?
[02:28] <cjwatson> not entirely but many such devices have moved
[02:28] <cjwatson> depends on the driver IIRC
[02:28] <cjwatson> so I only seem to have one IDE interface, according to lspci, and /dev/sda is on that
[02:28] <shawarma> cjwatson: I see. I never noticed due to the UUID fstab goodness. :-)
[02:29] <cjwatson> I'm not entirely clear where the CD device would be
[02:29] <shawarma> cjwatson: Nor I.
[02:29] <shawarma> cjwatson: Neither Tollef nor I had access to the hard drive, IIRC.
[02:29] <cjwatson> at any rate, my snap diagnosis would be a kernel problem, but I've no idea where
[02:29] <cjwatson> since the device isn't appearing
[02:30] <shawarma> cjwatson: Both using daily image from the 31st.
[02:30] <shawarma> cjwatson: Just as I suspected. I'll file a bug.
[02:30] <shawarma> cjwatson: Thanks for your help.
[02:32] <cjwatson> you're welcome, sorry I couldn't be of more assistance
[02:34] <cjwatson> the exceptions on ata2 seem relevant, since they're on the device that isn't claiming to have a hard disk attached. I wonder if they're merely hidden in newer versions
[02:34] <shawarma> cjwatson: I don't think so.. There was a bug about it somewhere. 2 sec.
[02:35] <shawarma> https://bugs.beta.launchpad.net/ubuntu/+source/linux-source-2.6.20/+bug/94637
[02:35] <ubotu> Malone bug 94637 in linux-source-2.6.20 "[vmware]  ata1: reset failed, giving up" [Medium,Fix released]  
[02:36] <shawarma> But mdz still manages to continue his install => clearly a different issue.
[02:36] <cjwatson> shawarma: those aren't the messages I'm seeing.
[02:37] <shawarma> cjwatson: no?
[02:38] <cjwatson> "ata2.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x2 frozen" etc.
[02:39] <cjwatson> anyway, I'm grabbing a newer image and will retry on Tuesday or so (I'm away tomorrow)
[02:39] <shawarma> cjwatson: Cool. I'll be sure to /msg you if I work something out with BenC.
[02:39] <mjg59> cjwatson: Hm. Just speaking to someone else who's ended up with an unbootable 2.6.17 after upgrading userland to feisty.
[02:40] <shawarma> mjg59: udev in feisty requires 2.6.19, doesn't it?
[02:40] <cjwatson> udev in feisty also version-checks that before updating the initramfs
[02:40] <mjg59> Conceivably, though breaking people's existing initramfs is sub-optimal
[02:40] <mjg59> cjwatson: Ok, so that's meant to work now? Good to know.
[02:40] <shawarma> True.
[02:40] <mjg59> I'll try to figure out what happened.
[02:41] <cjwatson> I don't think udev broke it, but something else may have done
[02:41] <cjwatson> seeing as half a zillion packages update the initramfs
[02:41] <mjg59> Does update-initramfs check?
[02:41] <mjg59> Or is it just the udev package?
[02:41] <mjg59> If the latter - ouch.
[02:41] <cjwatson> it's based on the MINKVER variable in hooks
[02:42] <cjwatson> it shouldn't actually be bad to regenerate the initramfs providing dependencies are satisfied, normally
[02:42] <cjwatson> unless there's some weird circular dep thing going on
[02:42] <mjg59> It checks all hooks and then bails if the kernel is older than any of them?
[02:42] <mjg59> Sounds sane.
[02:43] <cjwatson> yes, see check_minkver at the end of /usr/share/initramfs-tools/hook-functions
[02:43] <cjwatson> a number of packages got upgraded before udev last I checked, though
[02:43] <cjwatson> should be possible to data-mine it from /var/log/dpkg.log, and possibly the initramfs timestamp to save effort
[03:06] <shawarma> mjg59: It seems to be reproducable. :-(
[03:17] <shawarma> mjg59: Gah.. the initrd is 0 bytes long.
[03:46] <shawarma> mjg59: I've found it, I think.
[03:48] <shawarma> mjg59: update-initramfs grabs a backup of the initrd, but when mkinitramfs fails due to MINKVER not being met, it doesn't restore that backup. It's fine, if it's only run once since the initrd...dpkg-bak is still around, but the next time update-initramfs is run, a new backup (this time of the trunced initrd) is made overwriting the good one. 
[03:56] <shawarma> mjg59: http://linux2go.dk/update-initramfs.diff fixes it.
[03:57] <shawarma> mjg59: Or so it would seem, anyway.
[03:57] <shawarma> Goodnight
[04:00] <wasabi> There certainly needs to be some tighter package binding of some sort between linux-restricted-modules, the kernel, the X config, and nvidia-glx
[04:00] <wasabi> I am getting a bit tired of accedently updating only part of all of that and having my media box boot up to a black screen.
[04:01] <wasabi> oh. fun. this time it just didn't boot.
[04:22] <wasabi> Um... there a launchpad way to mark a bug as critical for feisty in such a way that somebody will look at it before releasing feisty?
[04:22] <Burgundavia> yes
[04:23] <Burgundavia> change it so that it is proposed for this milestone --> https://launchpad.net/ubuntu/+milestone/ubuntu-7.04
[05:26] <atoponce> question asked to me in my loco channel, and i don't know the answer:
[05:27] <atoponce> "how long have the UUIDs for partitions been incorperated into the kernel?"
[05:28] <crimsun> atoponce: do (s)he mean "into Ubuntu's kernels"?
[05:28] <crimsun> s/do/did/
[05:29] <atoponce> yeah
[05:29] <atoponce> think so
[05:30] <crimsun> well, the udev side is 093-0ubuntu5 (as of Mon, 24 Jul 2006 22:44:22 +0100)
[05:32] <atoponce> i guess that works for him.
[05:32] <atoponce> crimsun: thx
[06:24] <stub> Launchpad is going down in 15 minutes for an update. Estimated downtime is 15 mins.
[07:18] <grndslm> sorry to intrude...but i'm wondering why the devs place more emphasis on apt-get as opposed to aptitude (i.e. - in the command_not_found app)
[07:18] <Hobbsee> grndslm: because it shows errors clearer
[07:19] <grndslm> Hobbsee:  I see...so there's no plans to use aptitude ever?
[07:20] <Hobbsee> who knows.  we may use smart.  depends on how they all evolve.  why do you ask?
[07:21] <grndslm> i'm just curious...i've just never understood why you would use a "dumber" package manager...was just confusing to me
[07:23] <grndslm> ubuntu's decisions seem to be the best possible, other than this...but cleared messages could be what's necessary...was just wondering
[07:23] <grndslm> *clearer
[07:25] <Treenaks> grndslm: in some ways, aptitude is dumber... if you have weird conflicts during upgrade, sometimes aptitude wants to delete EVERYTHING except the broken package, while apt does it the other way around
[07:25] <Treenaks> grndslm: all options have their pros and cons, it's just that apt-get is "well-known", also by the devs
[07:26] <grndslm> true, true...well, thanks for the clarification guys
[07:27] <popey> grndslm: there has already been a bug reported about that
[07:27] <popey> bah
[07:28] <Treenaks> popey: too late! :)
[07:28] <popey> so i see
[07:28] <ubotu> Malone bug 92862 in command-not-found "Shouldn't be apt-get-centric" [Wishlist,Fix committed]  https://launchpad.net/bugs/92862
[07:29] <Treenaks> popey: btw, what do/did you use to create those "instruction videos" ?
[07:29] <popey> https://wiki.ubuntu.com/ScreencastTeam/RecordingScreencasts <- that
[07:29] <Treenaks> ooh cool
[07:30] <popey> :)
[07:30] <Treenaks> thanks
[07:30] <popey> np
[08:12] <fabbione> morning
[08:12] <orkid> hello
[08:14] <Hobbsee> hey fabbione!
[08:15] <fabbione> hey hey
[08:16] <pitti> Good morning
[08:16] <fabbione> hey Martin
[08:16] <Hobbsee> heya pitti 
[08:16] <pitti> Padre!
[08:16] <pitti> Bella donna!
[08:16] <fabbione> ROFL
[08:16] <fabbione> pitti: what's all this italian? trying to score chicks? :)
[08:16] <pitti> fabbione: si :)
[08:17] <fabbione> eheh
[08:17] <Hobbsee> heh
[08:17] <Hobbsee> good luck with that, pitti :P
[08:18] <pitti> Hobbsee: grazie
[08:18] <Hobbsee> pitti: *g* 
[08:22] <mneptok> pitti: ora sono destato. grazie.
[08:24] <mneptok> Hobbsee: don't be jealous. pitti and i have something special that doesn't affect the love you and i share.
[08:25] <mneptok> (and by "love you and i share" i mean "the nausea you experience when thinking of me")
[08:27] <Hobbsee> heh
[08:41] <ajmitch> morning pitti, mneptok 
[08:49] <ajmitch> hi Mithrandir 
[08:51] <pitti> hi Mithrandir, good morning
[08:51] <Mithrandir> morning Andrew, Martin
[08:53] <kylem> morning Mithrandir 
[08:54] <Mithrandir> hiya Kyle
[08:55] <Mithrandir> we have over 100k bugs in malone now.
[08:57] <kylem> scary, eh?
[09:21] <afflux> siretart: do you still need the patch for bug #82343 ? just noticed this is still not implemented and is not a big fix... the patch on launchpad doesn't work anymore, though. I can give you a working one ;)
[09:21] <ubotu> Malone bug 82343 in cryptsetup "init.d/cryptdisks doesnt create symlinks in /dev/disk/by-*" [Undecided,Unconfirmed]  https://launchpad.net/bugs/82343
[09:25] <dholbach> good morning
[09:26] <Sp4rKy> hi there
[09:26] <Sp4rKy> 'morning dholbach 
[09:26] <pitti> hey dholbach 
[09:26] <siretart> afflux: looking
[09:27] <Sp4rKy> i'm the sysadmin of medibuntu repos, and i would know how update-manager test update at a predefined hour, and not randomly
[09:28] <siretart> afflux: the patch looks indeed sane. I need to test it this evening
[09:28] <siretart> afflux: thanks for your patch!
[09:29] <afflux> siretart: i think the line numbers changed, I have a working one for the 1.0.4+svn26
[09:29] <afflux> not sure about that
[09:29] <Sp4rKy> because, at about 6h45/7h UTC, all the server gets all connection due to update-manager
[09:30] <siretart> afflux: in doubt, please attach a working one to lp
[09:30] <afflux> alright
[09:30] <glatzor> Sp4rKy: the cron job is in /etc/cron.daily/apt
[09:31] <Mithrandir> ogra: What's happening with the trace on 97342?
[09:31] <Sp4rKy> glatzor: yes, but what i would know is _why_ all the update is done at the same hour
[09:31] <Mithrandir> dholbach: do you think desktop-team would be a sensible assignee for bug 69799?
[09:31] <ubotu> Malone bug 69799 in gnome-system-tools "services-admin reorders acpid startup" [Medium,Confirmed]  https://launchpad.net/bugs/69799
[09:31] <Sp4rKy> and why update-manager didn't choose an hour randomly at installation
[09:31] <dholbach> hi Sp4rKy, hi pitti
[09:32] <dholbach> Mithrandir: probably yes
[09:32] <seb128> Mithrandir: we don't have anybody really working on g-s-t atm
[09:33] <Mithrandir> seb128: it's release-targeted, I suspect it's easy to fix.
[09:33] <seb128> I think mvo spoke with upstream about it
[09:34] <seb128> mar 07 12:30:35 <mvo_>	hey garnacho! fancy to look at https://launchpad.net/bugs/69799 ?
[09:34] <seb128> mar 07 12:33:01 <garnacho>	mvo_: there's little we can do with that ATM (services-admin can't really guess the priority to use, might guess it from the other runlevels, but it could be still pretty rough...)
[09:34] <seb128> mar 07 12:33:44 <garnacho>	mvo_: maybe the "properties" context menu option should be more visible... (there you can edit per-runlevel priorities)
[09:34] <ubotu> Malone bug 69799 in gnome-system-tools "services-admin reorders acpid startup" [Medium,Confirmed]  
[09:35] <glatzor> Sp4rKy: could you please fill a problem report? It could be already to late for feisty to address this issue.
[09:35] <seb128> Mithrandir: ^
[09:36] <glatzor> seb128: hi, are going to upload a gnome 2.18.2 before the feisty release? otherwise I would have to import some translations manually.
[09:36] <seb128> glatzor: no, 2.18.2 will be in some months
[09:36] <Mithrandir> seb128: but it doesn't put everything at 10 if you disable and rename the service?
[09:36] <seb128> glatzor: we will ship with 2.18.1
[09:37] <seb128> Mithrandir: I'll have a look,, I don't want to break my desktop, I'll try later on my laptop
[09:38] <Mithrandir> seb128: just install something you don't care about, like an FTP server or something?
[09:38] <seb128> right, lemme try
[09:38] <glatzor> seb128: ah, fine
[09:39] <Sp4rKy> glatzor: yep i know. But i would talk with some responsible here before,to know if i can fill a bug report or if it's not necessary because this "issue" will not change
[09:39] <Sp4rKy> :/
[09:41] <seb128> Mithrandir: I've just tried with apache2, it does 91 -> 50
[09:42] <Mithrandir> seb128: ugh. :-/
[09:47] <Mithrandir> seb128: I really wonder where those values come from, though.  They don't seem to come from g-s-t itself, nor from liboobs
[09:49] <seb128> Mithrandir: looks like g-s-t uses 50 for everything
[09:49] <seb128> Mithrandir: 
[09:49] <seb128> $ grep 50 system-tools-backends-2.2.0/Init/Services.pm 
[09:49] <seb128>     $priority = 50 if ($priority == 0); #very rough guess
[09:50] <Mithrandir> seb128: ugh.  We could extend the frontend to just setting it from a static table.
[09:52] <seb128> Mithrandir: 
[09:52] <seb128> mar 07 12:39:39 <mvo_>	garnacho_: could we assign default priorities to the things? so that we can genertate (or auto-generate) that based on the defatuls in ubuntu?
[09:52] <seb128> mar 07 12:41:16 <garnacho_>	that'd be great :)
[09:52] <seb128> mar 07 12:41:42 <garnacho_>	hmm, even better would be getting rid of those pointless priorities :P
[09:52] <seb128> Mithrandir: not sure that's something we want to start on now though
[09:52] <Mithrandir> we are not going to transition the whole system to upstart events two and a half weeks before release. :-)
[09:54] <seb128> right, I was speaking about the priorities list
[09:56] <ubotu> Malone bug 100000 in malone "There are still too many bug reports" [Undecided,Confirmed]  https://launchpad.net/bugs/100000
[09:56] <zyga> hey
[09:58] <Mithrandir> seb128: oh, true, but do you have a better idea?
[09:59] <seb128> Mithrandir: not really no, the bug is not new though, that's no a regression and we didn't get many complains about it during previously cycles, I would not bother too much
[10:03] <Mithrandir> seb128: hm, point.
[10:04] <Mithrandir> Keybuk: do you have any plans wrt upstartification for feisty+1
[10:04] <Mithrandir> ?
[10:04] <doko> fabbione, pitti: any idea why https://launchpad.net/+builds/+build/315658 would fail in dh_strip?
[10:04] <Mithrandir> (and do we have a name for feisty+1 soon?)
[10:04] <Mithrandir> I want a giraffe.
[10:05] <doko> gargoyle
[10:05] <pitti> strip: debian/eclipse/usr/lib/eclipse/eclipse: File format not recognized
[10:05] <pitti> urgh
[10:05] <fabbione> doko: that's pitti's deb mangler
[10:07] <doko> fabbione: I'm not sure ...
[10:07] <Keybuk> pitti: I have to tag bugs to get them retraced, right?
[10:07] <Keybuk> Mithrandir: vague plans, yes
[10:07] <pitti> Keybuk: right
[10:07] <Keybuk> pitti: what are the tags?
[10:07] <pitti> Keybuk: need-{amd64,i386,powerpc}-retrace
[10:07] <fabbione> doko: did you try on faure?
[10:08] <fabbione> doko: does it happen without the package mangler?
[10:09] <doko> fabbione: doesn't build on faure, smp problems ... please fix it
[10:10] <pitti> doko: AFAICS, it's strip itself that fails, and thus the original dh_strip fails
[10:10] <fabbione> doko: file a bug on the kernel and ask Ben to look at it. kthxbye
[10:11] <pitti> exec $REAL_DHSTRIP "$@"
[10:11] <pitti> ^ it fails here
[10:11] <doko> fabbione, BenC: that bug is now open for months ...
[10:11] <fabbione> doko: you opened one on OOo
[10:11] <fabbione> i haven't seen any on eclipse
[10:11] <doko> fix that first
[10:11] <fabbione> doko: plus you have a sparc with a chroot to test.. does it happen there too?
[10:11] <doko> fabbione: yes
[10:12] <fabbione> same cpu as faure?
[10:12] <fabbione> is it SMP or UP?
[10:12] <doko> fabbione: I don't have a sparc besides faure at the moment
[10:12] <fabbione> doko: you told me you had one with a chroot != faure
[10:13] <fabbione> doko: anyway there isn't much i can fix.. testing kernels on faure is not really an option without full root access on the box...
[10:13] <fabbione> and nether me or davem have that kind of CPU at home
[10:14] <fabbione> doko: the only thing would be to take down faure -> move it somewhere i can get full root access -> try to fix -> return faure back
[10:14] <ogra> Mithrandir, can you approve 96103 as RC ?
[10:14] <Keybuk> siretart: ping
[10:15] <Keybuk> Mithrandir: context for question?
[10:15] <Mithrandir> Keybuk: bug 69799
[10:15] <ubotu> Malone bug 69799 in gnome-system-tools "services-admin reorders acpid startup" [Medium,Confirmed]  https://launchpad.net/bugs/69799
[10:16] <Mithrandir> ogra: no.  If you have a complex setup, don't use NM (yet).
[10:16] <Keybuk> Mithrandir: why does gst do that?!
[10:16] <ogra> Mithrandir, i thought you said you would add a config option to /e/n/i for that
[10:17] <siretart> Keybuk: yes?
[10:17] <Keybuk> siretart: did the packages I made help you at all?
[10:17] <tepsipakki> please test 0.7.7.7:
[10:17] <ogra> Mithrandir, when i asked if i should undeed it for edubuntu
[10:17] <tepsipakki> sorry
[10:17] <tepsipakki> middleclick error :)
[10:17] <Mithrandir> ogra: yes, that bug is not asking for that, it's asking for support for multiple NICs in NM.
[10:18] <siretart> Keybuk: I'm sorry to tell you that your package broke the bootup procedure of my system completely, I had to revert to the feisty ones
[10:18] <Mithrandir> Keybuk: because it smokes crack.  Or rather, guesses and guesses wrongly.
[10:18] <Keybuk> siretart: more verbose
[10:18] <Keybuk> what broke and how?
[10:18] <siretart> Keybuk: the mdadm-raid init script timout'ed on every LV, and disabling that init script didn't help
[10:18] <siretart> Keybuk: my system timeouted somewhere else
[10:19] <pitti> Keybuk, cjwatson, other british folks: would you say that the majority of users considers Monday as start of the week? (I have a bug about changing it, current setting is Sunday, I think) 
[10:19] <ogra> Mithrandir, well, thats nitpicking, the bug starts with: I have two NICs and I want them both active at the same time.
[10:19] <Keybuk> pitti: Sunday is the canon start day
[10:19] <pitti> Keybuk: ISO 8601 says Monday, and two bugs requested it, so I'm not sure
[10:19] <siretart> Keybuk: this however is a problem after having my root volume, the initramfs brought up my raid devices correctly, but not lvm
[10:19] <siretart> Keybuk: I still had to 'lvm vgchange -ay' by hand to get my root volume
[10:19] <Keybuk> siretart: I'll need you to debug more
[10:20] <Mithrandir> ogra: then the submitter should have used a better title.  He is complaining about NM not supporting more than one nic, he's not saying "I want to do this and I can't because of $foo".
[10:20] <Keybuk> pitti: actually, UK tradition may be Monday as the first
[10:21] <siretart> Keybuk: FYI: on friday, I tested iwj's test packages again, and they showed the same behavior in the initramfs: all raid devices fine, no lvm
[10:21] <Keybuk> siretart: iwj's test packages?
[10:22] <fabbione> Keybuk: one udev rules question for you.. when the kernel adds a block device, udev starts executing all the rules related to block devices in the numbering order as they appear in rules.d/ .. let say that one of these rules needs to wait for 5 seconds before the next one is executed.. can that be done by adding a sleep or udev does not wait and just execute all the rules?
[10:23] <Keybuk> fabbione: it can be done with a sleep
[10:23] <fabbione> Keybuk: thanks
[10:23] <Keybuk> though that suggests a race condition?
[10:23] <Keybuk> it would be better to not sleep, since you can't guarantee you'll sleep long enough?
[10:23] <siretart> Keybuk: http://www.chiark.greenend.org.uk/~ian/d/udev-nosyslog/
[10:23] <Keybuk> siretart: right, that just adds an option for debugging
[10:24] <Keybuk> siretart: are you going to be able to help debug your problem today?
[10:24] <fabbione> Keybuk: yes it's a very very specific corner case where I know the response time of the hw
[10:24] <Keybuk> fabbione: ah, shouldn't be a problem then
[10:24] <siretart> I think he changed that a bit further, and told me to patch one script.. need to fetch the irc log
[10:24] <fabbione> Keybuk: nope.. i just have to make sure that udev will wait before executing the next rules...
[10:25] <Mithrandir> asac: about bug 99655, what is your take on that?  Should we drop pango-libthai and use the support in pango proper?
[10:25] <ubotu> Malone bug 99655 in pango-libthai "pango-libthai ships nothing" [Undecided,Confirmed]  https://launchpad.net/bugs/99655
[10:26] <siretart> Keybuk: http://paste.debian.net/24837 is what iwj told me to do
[10:28] <Mithrandir> sladen: I think 98648 is bogus and should be rejected, do you disagree?
[10:28] <Keybuk> siretart: will you be able to install new packages and test with them?
[10:29] <ogra> Mithrandir, ok, i un-duplicated Bug #100021 and added n-m 
[10:29] <ubotu> Malone bug 100021 in ltsp "[Feisty]  LTSP fails on multi-homed server due to network manager touching predefined static interfaces" [Undecided,Confirmed]  https://launchpad.net/bugs/100021
[10:31] <siretart> Keybuk: this evening, sure. I'm currently at work
[10:31] <Keybuk> siretart: damn
[10:31] <Keybuk> unfortunately if I can make this work for me in vmware, I may have to upload because it seems to fix it for others
[10:31] <Keybuk> this evening will be too late
[10:32] <siretart> Keybuk: can you imagine what could have caused the mdadm-raid script to timeout?
[10:32] <Keybuk> siretart: I understand very little about mdadm/lvm
[10:32] <Keybuk> I don't even understand what that script *does*
[10:33] <siretart> Keybuk: I could install them remotely, and tell my gf to watch the boot procedure. However, if the system doesn't boot any longer, I cannot access it until I get back home
[10:33] <Mithrandir> pitti: I know you're a postgres and not a mysql guy, but do you have a bit of time to look at bug 95821?
[10:33] <ubotu> Malone bug 95821 in mysql-dfsg-5.0 "Replication failure with auto-increment and on duplicate key update" [Undecided,Unconfirmed]  https://launchpad.net/bugs/95821
[10:34] <pitti> Mithrandir: sounds complex and upstreamish, but I can take a look at it if you really need me to
[10:35] <siretart> Keybuk: perhaps Nafallo wakes up and can test your packages?
[10:35] <Mithrandir> pitti: I don't have anybody better suited for the task, and it looks kinda critical-ish.
[10:35] <pitti> Mithrandir: alrighty
[10:45] <asac> Mithrandir: yes, the idea is to build pango with libthai-dev ... should do the trick (according to thep)
[10:46] <Mithrandir> asac: ok, can you make sure that happens (in coordination with seb128 or dholbach, I suspect)
[10:47] <asac> Mithrandir: sure ... will do
[10:47] <Mithrandir> asac: thanks a lot.
[10:51] <Mithrandir> pitti: about the mysql bug, maybe it's better to just update to the newer upstream version?
[10:51] <pitti> Mithrandir: if you would generally be fine with that, sure
[10:52] <pitti> Mithrandir: upstream's microreleases are generally fine
[10:52] <pitti> Mithrandir: otherwise we can still backport the single bug fix commit
[10:52] <pitti> Mithrandir: but I'd be happy to grab 5.0.38 and give it some test runs
[10:52] <Mithrandir> pitti: I'd want to take a look at an debdiff just to make sure they didn't rewrite half the engine, but if they're generally cautious about the microreleases, I'm not opposed to it.
[10:52] <Mithrandir> pitti: if you could, that'd be great.
[10:53] <pitti> Mithrandir: sure, I'll review the diff and changelog for general sanity and report back to you
[10:53] <pitti> there are probably more fixed we are interested in
[10:53] <Mithrandir> pitti: coolie.
[10:53] <Mithrandir> Keybuk: new dog?
[10:54] <Keybuk> Mithrandir: yeah, a second border collie
[10:54] <Mithrandir> Keybuk: yay, dogs++. :-)
[10:54] <Keybuk> he arrived at the weekend, so is still in that "scream the house down hourly every night" phase
[10:54] <Mithrandir> yeah
[10:55] <Mithrandir> and you have to make sure to take him out fairly often and such.
[10:55] <\sh> Mithrandir: do we include a patch fopr 
[10:55] <Keybuk> yup
[10:55] <\sh> for mysql bug #27294?
[10:55] <ubotu> Malone bug 27294 in esound "esound: breaks since ALSA 1.0.10 transition; fixed by Ubuntu patches" [High,Rejected]  https://launchpad.net/bugs/27294
[10:55] <Keybuk> he's being surprisingly good actually, and waiting until I take him out before going to the loo
[10:55] <\sh> grmpf
[10:56] <Mithrandir> \sh: that's hardly a mysql bug. :-P
[10:56] <Keybuk> of course, he goes again as soon as he gets back in, but the spirit is there
[10:56] <\sh> http://bugs.mysql.com/bug.php?id=27294
[10:56] <\sh> Mithrandir: for sure ;) 
[10:56] <Mithrandir> Keybuk: yup, that's good.
[10:59] <Mithrandir> \sh: no idea, but we might want to.
[10:59] <\sh> Mithrandir: I could prepare something for feisty...cause the bug was produced here, and patch fix as well.
[11:01] <\sh> Mithrandir: there is also another fix for the same problem http://bugs.mysql.com/bug.php?id=21322 ;)
[11:01] <Mithrandir> \sh: if you could coordinate with pitti who's looking at updating mysql for another problem, that would be good.
[11:02] <\sh> Mithrandir: surew
[11:04] <pitti> Mithrandir: ubuntu seeds updated to fight downsizing; doing Kubuntu now
[11:04] <Mithrandir> pitti: cheers
[11:06] <pitti> Kubuntu done as well
[11:06] <pitti> edubuntu is okay
[11:09] <pitti> seb128, tepsipakki: hmm; I built/installed your new libx11 package, purged *xcb*, restarted X, and I still get the xcb assertion with vmware; where could this come from now?
[11:09] <seb128> vmware
[11:09] <pitti> tepsipakki: oh, maybe vmware is statically linked against xcb?
[11:10] <tepsipakki> maybe
[11:10] <tepsipakki> do you have 6.0rc?
[11:10] <pitti> tepsipakki: no, 5.5.3
[11:11] <tepsipakki> ok, xcb didn't exist then :)
[11:12] <seb128> pitti: remove the libx11 old build you have to /usr/local :p
[11:12] <fabbione> Keybuk: i assume what you told me about the sleep is true for dapper/edgy/feisty, right?
[11:13] <fabbione> Keybuk: and if i change a rule do i need to restart udev or it will be executed as new at the first trigger?
[11:13] <tepsipakki> pitti: that error is from libx11 anyway
[11:13] <seb128> pitti: does the "non-xcb libx11" works fine for you?
[11:13] <pitti> seb128: no, as I wrote
[11:13] <pitti> very same error
[11:14] <pitti> tepsipakki: ooh, wait
[11:14] <pitti> tepsipakki: I didn't purge libxcb-dev before building
[11:14] <pitti> tepsipakki: maybe configure picked it up and used libxcb again?
[11:14] <pitti> however, there's no libxcb library any more
[11:14] <seb128> pitti: my question was not clear, "no regression over the xcb version"?
[11:15] <tepsipakki> pitti: the version I built still had the deps
[11:15] <seb128> like "should we upload the non xcb version now"
[11:15] <pitti> seb128: ah; nothing noticeable so far
[11:15] <Keybuk> fabbione: yup, just put RUN+="/bin/sleep 5" in
[11:15] <Keybuk> fabbione: shouldn't need to restart
[11:15] <Milan> hi! I've just seen on Feisty that udatedb is run by cron daily. Is this really useful for most of users ?
[11:15] <pitti> seb128: I guess this more or less matches the edgy version again then?
[11:15] <fabbione> Keybuk: yeps.. thanks.. 
[11:16] <seb128> pitti: new upstream version though, not sure on how much they changed out of xcb
[11:16] <pitti> tepsipakki: indeed, the package still b-deps on xcb
[11:23] <pitti> tepsipakki: your libx11 builds fine without the xcb build deps
[11:29] <Milan> nobody can tell me what updatedb is run for? I don't see the point of having locate work on a standard desktop station.
[11:29] <Keybuk> Milan: geeks expect it to work
[11:29] <Keybuk> and geeks are the only people who tend to leave their computer on over night
[11:30] <Milan> Keybuk: ;-) why do we set it on by default?
[11:30] <Keybuk> because it's on in Debian
[11:30] <Keybuk> it'd be work for us to turn it off
[11:30] <pitti> Keybuk: and thanks to anacron it even works for people who switch it off
[11:30] <Milan> Keybuk: rm /etc/crond.daily/slocate
[11:30] <pitti> but locate is love!!
[11:30] <Keybuk> Milan: yes, but why would we do that?
[11:31] <Keybuk> Milan: is it causing you a problem?
[11:31] <Milan> pitti: that's the problem: turning on my computer, the HDD is working
[11:31] <Keybuk> Milan: at which point?
[11:31] <Milan> Keybuk: locate is really useless for 90% of users, and it's working everyday to check the FS
[11:31] <pitti> Milan: many people turn on beagle, which makes the problem ten times worse..
[11:32] <Milan> pitti: I know, there's a bug in /etc/cron.daily/beagle-crawl-system too. But Beagle is useful for some people
[11:32] <Keybuk> Milan: anacron will only fire sometime *after* boot if the system isn't busy
[11:32] <Milan> I mean: wouldn't it make sense to trun locate off by default, assuming that geeks will turn it on easily ?
[11:35] <Milan> I think it would be worth discussing that issue
[11:36] <pitti> Milan: to a certain degree I agree
[11:37] <Milan> oh good :-)
[11:37] <Milan> the thing is my dekstop is too often working without I know what it is doing, and this is really not a good point
[11:37] <Keybuk> Milan: start a discussion on the ubuntu-devel-discuss mailing list
[11:38] <Keybuk> suggest that it (and maybe other daily sysadmin-specific activities) be disabled by default
[11:38] <Keybuk> and work out with people there how it would be enabled again, etc.
[11:38] <Keybuk> and then produce a specification and register it in launchpad for the next release
[11:38] <Milan> I'll mail about it - but I have certainly no time to write a spec now
[11:39] <cjwatson> it's not only geeks who use locate; it's also people who are told by wiki page instructions etc. to use locate t ofind something
[11:39] <Milan> we'll see what the thread will tell
[11:39] <doko> seb128, dholbach: is the tangerine theme something else than the tango theme?
[11:39] <c4n3R> geldim a.q
[11:39] <c4n3R> :D
[11:39] <cjwatson> beagle isn't installed by default so it doesn't count yet
[11:39] <dholbach> doko: yes
[11:39] <seb128> doko: yes, tango is blue
[11:39] <seb128> doko: tangerine is orange ;)
[11:40] <c4n3R> kanka by_KuSs:D
[11:40] <by_KuSs> Sieeeeeeeeee
[11:40] <c4n3R> amn ziktiklerim konusuyo bak :D
[11:40] <doko> seb128: so it's called "human" as well?
[11:40] <by_KuSs> a.qdukLarm
[11:40] <c4n3R> haha:D
[11:40] <c4n3R> HHHHHH
[11:40] <c4n3R> :D
[11:40] <seb128> doko: no, Human is the Ubuntu theme
[11:40] <doko> I'm confused ...
[11:40] <c4n3R>  seb128 ; anann am... :D
[11:40] <seb128> doko: tangerine is tango with an orange palette
[11:41] <seb128> doko: Human is an original design, tangerine is tango style icons made to work with the Human color I think
[11:41] <by_KuSs> A.q Szn.
[11:41] <by_KuSs> AmckLar.
[11:41] <c4n3R> :D
[11:41] <c4n3R> yaa
[11:41] <c4n3R> zokaym
[11:41] <c4n3R> amna
[11:41] <seb128> doko: dholbach knows that better though
[11:41] <c4n3R> seb128 turkce
[11:41] <c4n3R> konus
[11:41] <doko> seb128: ok, thanks.
[11:41] <c4n3R> :D
[11:41] <c4n3R> o.D:
[11:41] <c4n3R> IRC.DiyalgoTR.Com
[11:41] <c4n3R> :D
[11:41] <c4n3R> D:
[11:41] <NapaLmDeath> c4n3R
[11:41] <NapaLmDeath> :D
[11:41] <c4n3R> :))
[11:41] <NapaLmDeath> HelaL 
[11:41] <NapaLmDeath> :D
[11:41] <c4n3R> burdareklam
[11:41] <c4n3R> yapcaz
[11:41] <c4n3R> anneklerini
[11:41] <c4n3R> sikicem ben
[11:41] <c4n3R> :D
[11:41] <NapaLmDeath> AnaLArn Sikerim
[11:41] <NapaLmDeath> unLarn 
[11:41] <NapaLmDeath> :D
[11:42] <c4n3R> :D
[11:42] <c4n3R> by_KuSs
[11:42] <c4n3R> sende zi:D
[11:42] <NapaLmDeath> kanaL opu iLe yok aq :D
[11:42] <c4n3R> seb128 Fuck off:D
[11:42] <c4n3R> ama
[11:42] <by_KuSs> Ahauyabauahah
[11:42] <by_KuSs> :D
[11:42] <by_KuSs> AnneSzLer.
[11:42] <NapaLmDeath> :D
[11:42] <c4n3R> :D
[11:42] <Fujitsu> !ops
[11:42] <ubotu> Help! Mez, LjL, elkbuntu, imbrandon, DBO, gnomefreak, Hobbsee, rob, ompaul, Madpilot, Burgundavia, Seveas, CarlK, crimsun, ajmitch, tritium, Nalioth, thoreauputic, apokryphos, tonyyarusso, PriceChild, Amaranth or jrib
[11:42] <c4n3R> see you:D
[11:42] <by_KuSs> ubotu
[11:42] <by_KuSs> Skm ye :D
[11:42] <c4n3R> ubotu
[11:42] <c4n3R> anan
[11:42] <NapaLmDeath> !op
[11:42] <c4n3R> bi
[11:42] <NapaLmDeath> :D
[11:42] <by_KuSs> Skm ye :D
[11:42] <c4n3R> zikerim
[11:42] <by_KuSs> Skm ye :D
[11:42] <c4n3R> warya
[11:42] <c4n3R> :D
[11:42] <by_KuSs> :D
[11:42] <c4n3R> akln
[11:42] <c4n3R> durtur
[11:42] <c4n3R> gtn tawana wrur
[11:42] <c4n3R> ;)
[11:42] <NapaLmDeath> HEy WomenLer sikerim sizi :D
[11:42] <by_KuSs> :D
[11:42] <c4n3R> :D
[11:42] <by_KuSs> a.q
[11:42] <apokryphos> hm, we need more ops in here.
[11:43] <by_KuSs> ne Skm
[11:43] <c4n3R> a.k:))
[11:43] <by_KuSs> Server
[11:43] <by_KuSs> CycLe ot :; )
[11:43] <c4n3R> annene,
[11:43] <c4n3R> in
[11:43] <c4n3R> here:D
[11:43] <c4n3R> achil was here..!
[11:43] <c4n3R> D:
[11:43] <c4n3R> klsfmslfs
[11:43] <NapaLmDeath> apokryphos Sikeyim seni orospu Cocugu YunanL :D
[11:43] <by_KuSs> NapaLmDeath
[11:43] <by_KuSs> falfa
[11:43] <vciaglia> that's really a stupid thing
[11:43] <jenda> hello
[11:43] <NapaLmDeath> bigjools Aq Senin La ingiLiz Orospusu
[11:43] <by_KuSs> yes yes
[11:43] <by_KuSs> Anan Skcem :D
[11:43] <c4n3R> EMPTY, THIS PLACE, 
[11:44] <c4n3R> EMPTY, THIS PLACE, 
[11:44] <c4n3R> ananz
[11:44] <apokryphos> jenda: ^ :)
[11:44] <c4n3R> sikerim
[11:44] <c4n3R> yoksa
[11:44] <c4n3R> :D
[11:44] <c4n3R> EMPTY, THIS PLACE, 
[11:44] <c4n3R> :D
[11:44] <NapaLmDeath> vciaglia Aanan Sikerim Senin Stupid ide
[11:44] <c4n3R> geldi
[11:44] <c4n3R> amciklar:D
[11:44] <Mithrandir> imbrandon: could you please apply a bunch of bans here?
[11:44] <by_KuSs> qRsLere ak A.q
[11:44] <SeJo> sorry jenda i'm out :-) 
[11:44] <Fujitsu> Mithrandir: Nobody around has powers... But jenda is here, so all should be good.
[11:44] <c4n3R> LEAVE, THIS PLACE,  Mithrandir
[11:44] <c4n3R> :D
[11:44] <imbrandon> Mithrandir, i'm trying seems my access is gone
[11:44] <by_KuSs> las
[11:44] <by_KuSs> gfi
[11:44] <c4n3R> hay
[11:44] <c4n3R> ananz sikim tya
[11:44] <c4n3R> :D
[11:44] <c4n3R> bye
[11:44] <c4n3R> a.q
[11:44] <c4n3R> :
[11:44] <c4n3R> :D
[11:45] <c4n3R> 
[11:45] <c4n3R> 
[11:45] <by_KuSs> ehefjaf
[11:45] <Mithrandir> Keybuk: you seem to have ops, care to clean up?
[11:45] <imbrandon> jenda, can you clean this up and then poke about where my access went
[11:46] <apokryphos> we'll get more ops added once Seveas is around
[11:46] <jenda> imbrandon: no, I can't sorry.
[11:46] <RichiH> imbrandon: so, whatcha need?
[11:46] <apokryphos> imbrandon: freenode/staff/ isn't in, as well :/
[11:46] <cjwatson> we should have a few more core developers with ops, since we tend to pay close attention here
[11:46] <Fujitsu> There does seem to be a bit of an op shortage lately.
[11:46] <imbrandon> apokryphos, ahh figures
[11:46] <mneptok> ooo! fabbione!
[11:46] <apokryphos> Fujitsu: not in the other channels, but here (since it's so rarely had problems). We can easily fix that though.
[11:46] <mneptok> fabbione: can you add me to the access list for -devel?
[11:46] <fabbione> humpf.. 2 minutes that i am behind the rack resetting the SAN and the world goes foobar
[11:47] <fabbione> mneptok: i don't have the channel password...
[11:47] <fabbione> i was made op
[11:47] <Fujitsu> apokryphos: Takes a few minutes in #ubuntu at times...
[11:47] <jenda> fabbione: and maybe you could add *@freenode/staff/* too :)
[11:47] <mneptok> fabbione: alright. i'll bother Dennis.
[11:47] <denny> fabbione doesn't have access to modify the access list  :)
[11:47] <apokryphos> fabbione: have to wait for Seveas or thom
[11:47] <fabbione> jenda: same as what i said to mneptok .. i don't have the channel password
[11:47] <cjwatson> the ops list here dates from 2004.
[11:47] <denny> needs to be thom
[11:47] <Fujitsu> Only thom and staff can modify it.
[11:47] <fabbione> thom: ping?
[11:48] <apokryphos> Fujitsu: or Seveas, yes.
[11:48] <Fujitsu> apokryphos: Ah, I suppose he would have the password.
[11:48] <cjwatson> mneptok: asa@85.98.111.224 and Yuzuk-4@88.243.106.131 were the other two troublemakers
[11:48] <cjwatson> ah, you're on it
[11:48] <jenda> apokryphos: nope.. only staff when told to by Seveas.
[11:48] <jenda> (and thom)
[11:48] <apokryphos> jenda: same thing; just indirectly :)
[11:49] <jenda> hehe
[11:49] <RichiH> fabbione: it would probably be a good idea to poke whoever can set access levels to add freenode staff to the list. that means we know we are allowed to do emergency stuff
[11:49] <RichiH> of course, if there is a huge flood, i would just set the channel +m, anyway
[11:49] <RichiH> but we will not do anything against lesser stuff unless we know we are allowed to by channel owners
[11:50] <mneptok> RichiH: beats screaming "WE'RE DOOMED" and trampling the children to reach the door.
[11:51] <apokryphos> RichiH: we do tend to have staff on the access lists for all ubuntu channels (it's one of our policies); just must've missed it on this one; soon.
[11:51] <RichiH> mneptok: heh, i generally avoid trampling anything i do not plan to eat
[11:51] <RichiH> apokryphos: yah, no worries
[11:51] <RichiH> you can probably force jenda to write a script to check regularly
[11:51] <mneptok> RichiH: are you hitting on me?
[11:51] <mneptok> ;)
[11:52] <RichiH> mneptok: of course i am ;)
[11:52] <mneptok> @lart 37 RichiH 
[11:52] <jenda> RichiH: That would be hard...
[11:52] <mneptok> bah
[11:52] <mneptok> !lart 37 RichiH 
[11:52] <ubotu> Sorry, I don't know anything about lart 37 richih - try searching on http://bots.ubuntulinux.nl/factoids.cgi
[11:52] <mneptok> the bots taunt me.
[11:52] <jenda> @lart 37 mneptok 
[11:52] <jenda> hehe, probably not in -devel :)
[11:53] <Keybuk> Mithrandir: someone beat me to it I think
[11:53] <Keybuk> :p
[11:53] <RichiH> jenda: not too much, with chanserv list and access list parsing, you should be able to do it rather easily in perl. the fact that you can look through private bits helps, of course
[11:54] <jenda> RichiH: I meant, forcing me would be hard.
[11:55] <RichiH> ah
[11:55] <RichiH> jenda: they should just employ the local mafia
[11:56] <jenda> RichiH: how many times am I going to tell you, 1) There is no mafia in this country 2) They wouldn't dare touch their own boss.
[11:57] <mneptok> that is, if they had a boss. if they existed. which they don't.
[12:00] <RichiH> jenda: 42
[12:04] <pitti> \sh: I'm currently evaluating 5.0.37; what was it you wanted to see there?
[12:14] <gnomefreak> guys the correct ops are now listed when called !ops in here 
[12:17] <mvo> Riddell: AYT?
[12:19] <Riddell> mvo: whit?
[12:20] <mvo> Riddell: 
[12:20] <mvo> Riddell: I wonder about #100074
[12:20] <mvo> Riddell: (and duplicates). it seems its only triggered under kde, is the tmpdir extraction in adept changing the permissions of the files somehow?
[12:22] <Riddell> shouldn't do
[12:22] <jenda> mneptok: you can take off the bling now ;)
[12:22] <Riddell> mvo: what's it trying to run?
[12:22] <jenda> adios
[12:23] <mvo> Riddell: a included script that is run after the upgrade
[12:24] <mvo> Riddell: urgh, I just checked, it seems to remove all "x" bits 
[12:28] <Riddell> mvo: mm, so it does
[12:29] <Riddell> mvo: I wonder why it would do that
[12:30] <mvo> Riddell: I work around it for now
[12:30] <linuxero> hello
[12:31] <linuxero> a question
[12:43] <dholbach> pitti: bughelper is broken with the new LP UI
[12:44] <dholbach> pitti: just to let you know that a fix for launchpadBugs is in the works
[12:48] <pitti> dholbach: oh, thanks for notifying; for the public LP as well, or just for beta?
[12:49] <StevenK> pitti: Beta has been released.
[12:49] <pitti> uuh, indeed
[12:49] <pitti> no beta. any more
[12:50] <StevenK> For about a week, sabdfl said in his blog.
[12:50] <Fujitsu> Beta is still beta, just public.
[12:51] <pitti> Fujitsu: not visible in the URL any more, then
[12:51] <Fujitsu> That too.
[12:55] <dholbach> pitti: ok, seems that Bug() is unaffected
[12:55] <dholbach> pitti: BugList seems broken though - which does not need to bother you :)
[12:55] <pitti> dholbach: I think it does
[12:56] <pitti> ./bin/launchpad-crash-digger:        for b in BugList(Struct(url = self.list_url, upstream = None
[12:56] <dholbach> pitti: oh ok - I'm poking it
[12:56] <pitti> dholbach: /me wants xmlrpc
[01:01] <Mirv> pitti: do you know why some of the 20070329 language packs are not getting build?
[01:01] <pitti> Mirv: no, I don't; buildd congestion?
[01:03] <Mirv> pitti: yeah, I tried to find out but to no avail. there are many packages that have been built since. but I just found a bug report too: https://bugs.launchpad.net/ubuntu/+source/language-pack-gnome-pt-base/+bug/99525
[01:03] <ubotu> Malone bug 99525 in language-pack-gnome-pt-base "Can't install Portuguese Language gnome " [Undecided,Confirmed]  
[01:04] <Mirv> but maybe some builds are done at a different place and there is a congestion somewhere that only affects some packages
[01:05] <Mirv> anyway, five days is quite a long time for packages not to build
[01:07] <shawarma> cjwatson: I found the bug mjg59 talked about last night. The one about doing an edgy->feisty userland upgrade breaks. 
[01:07] <shawarma> cjwatson: I don't know if you saw the patch I sent?
[01:09] <shawarma> cjwatson: Oh. you're the last uploader. :-)
[01:09] <cjwatson> also on holiday today, so going to do other things now ;)
[01:09] <shawarma> cjwatson: Oh, right. I forgot. Sorry.
[01:09] <cjwatson> shawarma: no I'm not (the last uploader) ..
[01:10] <shawarma> cjwatson: Oh, ok. I must be a few days behind on the updates.
[01:12] <ogra> hmm, whats wrong with the mailman archives ? https://lists.ubuntu.com/archives/feisty-changes/ doesnt have any april entrie
[01:12] <ogra> *entries
[01:12] <ajmitch> it's getting further & further behind
[01:12] <pochu> do we know when the herd6 candidates will be available?
[01:12] <ajmitch> iirc the box can't keep up 
[01:13] <Fujitsu> ubuntu-bugs is 12 hours behind.
[01:13] <shawarma> ogra: The disk is full, AFAIK.
[01:13] <Fujitsu> (that's not the archives, but the actual mail)
[01:13] <ajmitch> shawarma: I thought that was a separate issue?
[01:13] <shawarma> ajmitch: Possibly. 2 sec.
[01:13] <cjwatson> shawarma: that's a different machine.
[01:13] <Fujitsu> I know one of the LP servers filled up a few days back...
[01:13] <cjwatson> mailman archiving => slow, merge-o-matic => ENOSPC
[01:13] <shawarma> 01:33 < smithj> the ubuntu-patches mailing list seems to have not gotten any patches since march 7. given that i don't think ubuntu has ceased  development, what's up with that?
[01:13] <ogra> shawarma, ah
[01:14] <Fujitsu> cjwatson: Ah.
[01:14] <shawarma> 01:44 < cjwatson_> smithj: I believe that's because the machine running that has run out of disk space; there's a sysadmin ticket open for it
[01:14] <shawarma> ajmitch: ^^
[01:14] <ajmitch> shawarma: yes, that's what I was referring to
[01:14] <shawarma> cjwatson: Ah, ok. Sorry.
[01:14] <Fujitsu> It's still an issue after almost a month? Must be busy sysadmins.
[01:15] <ajmitch> very
[01:15] <Keybuk> Fujitsu: canonical has just moved office, I suspect they're mostly tied up with that :-/
[01:16] <Keybuk> not to mention the LP beta, upcoming Ubuntu release *and* other pending releases
[01:16] <Fujitsu> Keybuk: Ah.
[01:16] <Keybuk> StevenK: ?
[01:17] <ajmitch> StevenK: why so? I run vmware server without any issues
[01:17] <pitti> StevenK: xcb assertion startup?
[01:17] <StevenK> No, worse than that. It wants /lib/ld-linux.so.2
[01:17] <\sh> pitti: rational bug: http://bugs.mysql.com/bug.php?id=25526, there is a patch which is really fixed in http://bugs.mysql.com/bug.php?id=21322
[01:18] <ajmitch> you have the relevant ia32-libs stuff installed?
[01:18] <\sh> pitti: sorry for answering now...but I had some nightmare with out ldap servers
[01:19] <StevenK> ajmitch: It seems not, given I hadn't heard of that package.
[01:19] <pitti> \sh: I'll check if it is applied in 5.0.37
[01:19] <ajmitch> StevenK: not sure if it'll help
[01:21] <StevenK> ajmitch: That seems to be it.
[01:21] <\sh> pitti: if not, I 'll prepare a patch...we (@combots) are running all the time into this error
[01:21] <\sh> brb...dner time ,-)
[01:22] <Keybuk> kebab?
[01:22] <pitti> \sh: Guten Appetit
[01:22] <ogra> hmm
[01:22] <ogra> *gets
[01:23] <ogra> to bad i just sat down in my deckchair in the garden and am to lazy to pock up a kebab
[01:23] <ogra> *pick
[01:26] <mneptok> ogra: wait for a squirrel to fall into your mouth?
[01:26] <ogra> haha
[01:27] <ogra> no barbecue in the trees here ....
[01:27] <ogra> i dont eat raw squirrels .... way to furry
[01:27] <bhale> ogra: you wre supposed to skin them
[01:28] <mneptok> Fujitsu: die Weltherrschaft ist fast komplett.
[01:28] <ogra> bhale, bah
[01:28] <ogra> i thought *they* are supposed to fall in my mouth
[01:28] <Fujitsu> mneptok: Nein!
[01:28] <Fujitsu> mneptok: Geh Heim.
[01:29] <mneptok> Fujitsu: 
[01:29] <mneptok> 
[01:29] <mneptok> Fujitsu: Babel Fish Translation   	Help
[01:29] <mneptok> Auf deutsch:
[01:29] <mneptok> ;)
[01:30] <mneptok> OK, time to go home.
[01:30] <mneptok> ach so.
[01:30] <mneptok> just wait. you'll learn more soon.
[01:30] <mneptok> yes. very soon now ...
[01:30] <bhale> mneptok: tschuss!
[01:30] <pitti> bhale: you still have to practice Umlauts :)
[01:31] <Fujitsu> mneptok: Macht spass!
[01:31] <bhale> pitti: my keyboard doesnt enjoy them.
[01:31] <ogra> bhale, ou can fix that by adding an e behind ...
[01:31] <bhale> if i change the layout there is something to be done with the Compose key
[01:32] <ogra> tschuess would be the right one ;)
[01:33] <shawarma> bhale: I think Compose+" followed by u would do it?
[01:33] <Fujitsu> shawarma: That'd be right.
[01:34] <pitti> \sh: doesn't look like even being committed upstream, let alone released; there's an almost-correct patch attached to http://bugs.mysql.com/bug.php?id=27294 
[01:36] <pitti> \sh: that one's easy enough to adapt, though
[01:37] <Nafallo> Keybuk: packages? :-)
[01:38] <bhale> shawarma: i changed keymap to us intl with deadkeys, set caps lock to compose in gnome-keyboard-properties, every time i hit capslock-u it beeps at me
[01:40] <Monk-e> Fujitsu, how does that work exactly?
[01:40] <shawarma> bhale: If you've got deadkeys, you shouldn't need compose.
[01:40] <shawarma> bhale: On Danish keyboards there's a button with an umlaut. Pressing that and then an a gives me .
[01:40] <Nafallo> Keybuk: btw, http://home.nafallo.info/bugs/udev.txt :-)
[01:41] <pitti> seb128, tepsipakki: indeed, StevenK brought it up: of course vmware uses the ia32-libs version of libx11, which still has xcb; so we'd just need to update it once again
[01:41] <pitti> tepsipakki: so my recent failure was due to the recently updated ia32-libs
[01:44] <seb128> pitti: ah, ok
[01:46] <pitti> seb128: so I'll update ia32-libs after the new libx11 is in
[01:46] <seb128> ok
[01:50] <jwendell> hi, pitti 
[01:50] <pitti> Hi jwendell 
[01:51] <jwendell> pitti, is there any problem with language-pack-gnome-pt-base package build?
[01:51] <jwendell> pitti, it's not available in repository yet
[01:51] <Mirv> jwendell: i just asked pitti about it, there's a bug reported about it and other similar problems
[01:51] <pitti> not sure, it says 'successfully built'
[01:52] <Mirv> jwendell: https://bugs.launchpad.net/ubuntu/+source/language-pack-gnome-pt-base/+bug/99525
[01:52] <ubotu> Malone bug 99525 in language-pack-gnome-pt-base "Can't install Portuguese Language gnome " [Undecided,Confirmed]  
[01:52] <pitti> jwendell: language-pack-gnome-pt-base | 1:7.04+20070329 | http://archive.ubuntu.com feisty/main Packages
[01:52] <pitti> jwendell: looks good ot me
[01:52] <pitti> s/ot/to
[01:52] <pitti> jwendell: even on the German mirror already
[01:52] <jwendell> pitti, 
[01:52] <jwendell> wendell@wendell-laptop:~$ LANG=C apt-cache policy language-pack-gnome-pt-base
[01:52] <jwendell> language-pack-gnome-pt-base:
[01:52] <jwendell>   Installed: 1:7.04+20070313
[01:52] <jwendell>   Candidate: 1:7.04+20070329
[01:52] <jwendell>   Version table:
[01:52] <jwendell>      1:7.04+20070329 0
[01:52] <jwendell>         500 http://archive.ubuntu.com feisty/main Packages
[01:52] <jwendell>  *** 1:7.04+20070313 0
[01:52] <jwendell>         100 /var/lib/dpkg/status
[01:53] <pitti> so, that's fine; where's the problem?
[01:53] <shawarma> Who to bug about initramfs-tools bugs? The kernel team? infinity?
[01:53] <jwendell> wendell@wendell-laptop:~$ LANG=C apt-cache policy language-pack-gnome-pt
[01:53] <jwendell> language-pack-gnome-pt:
[01:53] <jwendell>   Installed: 1:7.04+20070313
[01:53] <jwendell>   Candidate: 1:7.04+20070313
[01:53] <jwendell>   Version table:
[01:53] <jwendell>  *** 1:7.04+20070313 0
[01:53] <jwendell>         500 http://archive.ubuntu.com feisty/main Packages
[01:53] <jwendell>         100 /var/lib/dpkg/status
[01:53] <pitti> jwendell: ah, that's not -base
[01:53] <jwendell> pitti, yep, sorry :)
[01:53] <pitti> successfully built as well
[01:54] <pitti> Mithrandir: any idea why some built packs might be missing? failed-to-move again?
[01:54] <Mirv> yeah, language-pack-gnome-pt, language-pack-gnome-fi-base and language-pack-fi as examples are not in the archive
[01:54] <Keybuk> Nafallo: http://people.ubuntu.com/~scott/packages/
[01:54] <Mirv> while eg. language-pack-gnome-fi and language-pack-fi-base are
[01:54] <pitti> Mithrandir: (not that I would know what f-t-m is all about, but it was the reason for such problems in the past)
[01:55] <Mithrandir> pitti: yes, 19 packages, reprocessing.
[01:55] <\sh> pitti: 5.0.38 should have it, afaik
[01:55] <pitti> Mithrandir: cheers
[01:55] <pitti> \sh: latest upstream release is .37
[01:55] <Mirv> Mithrandir: thanks!
[01:55] <\sh> pitti: jepp, but .38 is on it's way ;) but nothing for feisty, yes
[01:59] <Mithrandir> 11 language packs in accepted now.
[02:00] <\sh> pitti: and we can backport this patch to dapper/edgy
[02:07] <janimo> can a TB member please extend my membership in MOTU and core-dev? LP has been mailing me that it will expire in a few days.
[02:10] <Mirv> mpt: thanks for https://bugs.launchpad.net/launchpad/+bug/100000 , I just happened to check if 100k has been reached and it was :)
[02:10] <ubotu> Malone bug 100000 in malone "There are still too many bug reports" [Undecided,Confirmed]  
[02:14] <Keybuk> Janimo: done
[02:21] <janimo> Keybuk: thanks
[02:26] <siretart> Nafallo: run_program: '/lib/udev/watershed' (stderr) 'mdadm: failed to add 8:35 to /dev/md/2: Invalid argument' <- this sounds scary.. 
[02:27] <Nafallo> ouch :-P
[02:28] <Nafallo> maybe I should wait til I figured out why my client dies all the time...
[02:28] <siretart> but according to the log, it seems that your lvs are started as they should
[02:28] <siretart> hm
[02:30] <Nafallo> aha. you were looking at my log :-)
[02:30] <siretart> oh, I should have told you before ;)
[02:30] <Nafallo> case still holds though. my headless server is the only reliable computer I have atm :-/
[02:31] <Nafallo> not sure if I can do much testing while I don't know when things are going to die hard.
[02:32] <jsgotangco>  hey Hobbsee
[02:34] <tepsipakki> pitti: ok, maybe I should just upload libx11 which doesn't use xcb, unless someone objects
[02:34] <pitti> tepsipakki: *nod*, works fine here
[02:34] <pitti> tepsipakki: oh, can you upload yourself now?
[02:34] <tepsipakki> pitti: sure ;)
[02:34] <pitti> tepsipakki: oh, cool
[02:35] <tepsipakki> for a week now
[02:36] <Hobbsee> heya jsgotangco!
[02:51] <ogra> sladen, did you merge the seeds with edubuntu after your NM change to ubuntu-meta
[02:51] <ogra> ?
[02:54] <ogra> Riddell, the ubuntu seeds look wierd, what is rev 935 about ? ("Merge with Ubuntu" but not further note)
[02:55] <Riddell> ogra: err, I messed up, hang on
[02:56] <ogra> looks like a kubuntu entry ... :)
[02:56] <Riddell> yes, it should have been
[02:59] <Riddell> ogra: the -debug change reverted
[03:10] <kwwii> anyone know which package this bug should correctly be assigned against? #17561
[03:12] <Mithrandir> kwwii: xserver-xorg-video-nv, I'd guess
[03:12] <kwwii> Mithrandir: thanks :-)
[03:15] <pitti> _ion: hm, may it be that the 'bc03' matching algorithm is buggy somehow? (bug 101883)
[03:18] <pitti> _ion: also, since the device class consists of four digits, why do the bc* patterns only have two?
[03:38] <Riddell> pitti: http://kubuntu.org/~jriddell/tmp/edgy-updates/
[03:40] <Riddell> Seveas: ubotu seems not to be in #kubuntu
[03:41] <Seveaz> Riddell, it's still connecting/join
[03:41] <pitti> Riddell: hmm, can you please make the changelog SRU conformant? I. e. include the names of the testers, and the SRU bug number?
[03:41] <Seveaz> bugtracker is dead by the way, I'm fixing it but it may take a while
[03:41] <pitti> Riddell: also, code changes relative to -proposed are not policy conformant
[03:41] <Keybuk> siretart, Nafallo, keescook: how do you handle swap and md/lvm ?
[03:42] <Riddell> pitti: how else could I do that meta-release-{,development} change?
[03:43] <Riddell> Seveaz: thanks
[03:43] <pitti> Riddell: ah, that's for preventing people from upgrading to feisty prematurely? I see
[03:43] <Keybuk> (or anyone else who thinks that mounting a root filesystem should be "fun" :p)
[03:43] <siretart> Keybuk: swap is on /dev/mapper/cswap, which is an encrypted swap space (key /dev/random) on /dev/md1 (mirrored raid)
[03:44] <Keybuk> so you have raid-mirrored swap?
[03:44] <pitti> Riddell: ok, except for the tester names, these look ok
[03:44] <Keybuk> md1 being sda2 and sdb2 ?
[03:46] <siretart> md1 being sd{a,b}5
[03:46] <siretart> Keybuk: yes, swap is mirror, so my system doesn't lockup if a harddrive dies
[03:46] <Keybuk> right
[03:46] <Keybuk> so if I set the following up
[03:46] <Keybuk> hmm
[03:46] <Keybuk> actually, where is your /boot ?
[03:47] <Keybuk> I assume grub can't read lvm-on-md ?
[03:47] <siretart> no, /boot is on /dev/md1, which is mirrored on /dev/sd{a,b}2
[03:47] <Keybuk> I thought you said swap was /dev/md1 ?
[03:47] <siretart> no, /boot is on /dev/md0, which is mirrored on /dev/sd{a,b}2
[03:47] <siretart> sorry, typo
[03:47] <Keybuk> lol
[03:47] <siretart> ;)
[03:47] <Keybuk> what's sda,b 1?
[03:48] <Keybuk> grub can read md then?
[03:48] <siretart> NTFS partition, reserved for future use ;)
[03:48] <Keybuk> ah
[03:48] <Keybuk> so sda/b 6 is your lvm?
[03:48] <siretart> Keybuk: grub doesn't need to deal with md. if the volume is mirror, grub doesn't really care, I think
[03:49] <Keybuk> ok...
[03:50] <iwj> Well, yes, provided you tell grub the right drives etc.
[03:50] <Keybuk>    Device Boot      Start         End      Blocks   Id  System
[03:50] <Keybuk> /dev/sdb1               1          63      506016   fd  Linux RAID autodetect
[03:50] <Keybuk> /dev/sdb2              64        1044     7879882+   5  Extended
[03:50] <Keybuk> /dev/sdb5              64         126      506016   fd  Linux RAID autodetect
[03:50] <Keybuk> /dev/sdb6             127        1044     7373803+  fd  Linux RAID autodetect
[03:50] <Keybuk> so that would be similar?
[03:50] <iwj> I'm pretty sure the default setup doesn't do that but my tests of md-based installs have all resulted in lilo.
[03:51] <siretart> Keybuk: this looks pretty similar to my system
[03:51] <siretart> Keybuk: in fact, I have two volume groups, one on a stripe (hades_stripe) and one on a mirrored raid device (hades_mirror)
[03:52] <Keybuk> what's a stripe?
[03:53] <Keybuk> ah, raid0
[03:53] <siretart> Keybuk: stripe == raid level 0, data is striped on all members. improves disk access (speed)
[03:53] <Keybuk> what do you do differently with them?
[03:54] <siretart> I keep important data on the mirror, volatile data (chroots, checkouts) on stripe
[03:55] <Keybuk> hmm, that gave me "/dev/sdb1 is too small: 0K"
[03:55] <siretart> you're testing inside vmware?
[03:56] <Keybuk> yes
[03:57] <iwj> Keybuk: I had a similar problem with my new SATA disk, which was solved by updating to the latest feisty kernel.  I have no idea if it's related.
[04:03] <_ion> pitti: bc is class, sc is subclass. A "0300" device would be equivalent to bc03sc00 in modalias format.
[04:03] <pitti> _ion: ah, thanks
[04:03] <pitti> _ion: so we need to fix sc* to sc00, I figure
[04:05] <pitti> _ion: still, I don't see any PCI device in seb128's lspci output that would match 03*
[04:06] <_ion> pitti: I'm not quite sure sc* should be changed. By default, the nvidia driver lists pci:v000010DEd*sv*sd*bc03sc02i00* and pci:v000010DEd*sv*sd*bc03sc00i00*
[04:07] <iwj> siretart: Do you have a udevd --verbose --suppress-syslog output for your current booting problem ?  (lvm not triggered, you say)
[04:07] <_ion> pitti: I posted a reply to the bug report.
[04:07] <pitti> _ion: thanks
[04:07] <_ion> seb128: 
[04:07] <iwj> siretart: (thanks for your report last Friday night btw)
[04:08] <siretart> iwj: not at hand, I can generate it this evening if you want
[04:09] <iwj> siretart: Thanks.
[04:09] <iwj> Though I really ought to think about this some more today to try to minimise the number of round trips of this kind.
[04:09] <seb128> _ion: 37 lines, anything special you are looking for there?
[04:10] <Nafallo> Keybuk: /dev/sd?1 is /dev/md0 is swap
[04:10] <Nafallo> Keybuk: /dev/sd?2 is /dev/md1 is root
[04:10] <Riddell> pitti: http://kubuntu.org/~jriddell/tmp/edgy-updates/  updated
[04:10] <Nafallo> Keybuk: /dev/sd?3 is /dev/md2 is LVM
[04:10] <iwj> Nafallo: You don't have a udev log from your boot which now fails just like siretarts, you say, do you ?
[04:11] <Nafallo> iwj: http://home.nafallo.info/bugs/udev.txt
[04:11] <_ion> seb128: If you don't mind, please paste the whole thing to the bug report, just in case i notice something important i'm not initially looking for.
[04:11] <iwj> Nafallo: Oh, excellent.
[04:11] <Nafallo> iwj: seemed straightforward that time though, broke premount and just did scripts/init-premount/udev :-)
[04:11] <iwj> That's with the `watershed -i ... true' changed to -li I take it.
[04:12] <Nafallo> yes
[04:12] <iwj> Excellent.  Thanks.
[04:13] <ogra> can anyone explain to me why our nfs mode in initramfs-tools uses nfsmount and not mount (which is there in the initramfs anyway and supports all options /which nfsmount doesnt))
[04:13] <seb128> _ion: done
[04:16] <iwj> Nafallo: Do I have a note somewhere of your raid/lvm setup ?
[04:16] <Keybuk> ogra: I didn't think we had the full mount in the initramfs
[04:16] <iwj> Oh, just a mo, does this udev.txt contain the second udevtrigger run too which you did to make it work ?
[04:16] <iwj> Unfortunately these debug files don't have timestamps.
[04:16] <Keybuk> I'm pretty sure mount comes from klibc too
[04:17] <Nafallo> iwj: no, just scripts/init-premount/udev and then ctrl+d IIRC
[04:17] <Mithrandir> dholbach: what is the plan for universe wrt release freeze?
[04:18] <pitti> _ion: weird; there is just one bc03 in Seb's output, and that is the ATI card
[04:18] <iwj> Nafallo: Hmm.  So which lvm didn't come up ?
[04:18] <_ion> seb128: What does the following print? python -c 'from RestrictedManager.core import *; print connected_hardware(load_restricted_list())'
[04:18] <iwj> run_program: '/lib/udev/watershed' (stdout) '  8 logical volume(s) in volume group "root" now active'
[04:18] <seb128> _ion: set([] )
[04:18] <Nafallo> iwj: this time none of them. and I don't think I got the annoying message :-)
[04:19] <_ion> seb128: Hmm... How about python -c 'from RestrictedManager.core import *; print connected_hardware(load_restricted_list(True))'
[04:19] <pitti> _ion: set(['vmnet', 'vmmon', 'nvidia'] ) for me in both cases; that looks right
[04:19] <seb128> _ion: him
[04:19] <seb128> hum
[04:19] <seb128>   File "/usr/lib/python2.5/site-packages/RestrictedManager/core.py", line 231, in save_restricted_list
[04:19] <seb128>     print >>restricted_file, module + " " + " ".join(alias_patterns)
[04:19] <seb128> IOError: [Errno 28]  No space left on device
[04:20] <seb128> $ python -c 'from RestrictedManager.core import *; print connected_hardware(load_restricted_list(True))'
[04:20] <seb128> set(['fglrx'] )
[04:20] <_ion> Ok, it probably saved a b0rked cache file, and then made the decision based on it.
[04:21] <_ion> Does restricted-manager -C work now?
[04:21] <seb128> yes
[04:21] <_ion> Alright.
[04:21] <seb128> funny bug ;)
[04:21] <pitti> _ion: so that seems to sort out itself when the modaliases are moved to l-r-m
[04:21] <iwj> Nafallo: So what made you say the lvm didn't come up ?  Or perhaps it only doesn't work if you do a normal uninterrupted boot (which would be about typical ...)
[04:22] <_ion> As it had *no* patterns for either nvidia or fglrx in the cache file, it assumed it's better just to show the hardware as a choice in the list. In the case of -C, the same code decided the driver should be installed, which might not be exactly what we want...
[04:22] <_ion> pitti: But yeah, that will sort it out.
[04:22] <_ion> s/hardware/driver/
[04:22] <Keybuk> iwj: so, my investigation so far seems to say that there is an unknown time period between (ADD /block/md*) and the array being useful enough to run things like vol_id on
[04:23] <pitti> _ion: hmm, wouldn't that also hit people who uninstalled l-r-m? it doesn't seem to do this in that case
[04:23] <_ion> pitti: I think r-m should specifically check that l-r-m is installed, and offer to install it if it isn't.
[04:24] <pitti> _ion: it does that now on interactive startup
[04:24] <iwj> Keybuk: Right but IIRC what I told Nafallo and siretart to do included the strange blocking PROGRAM= call which ought to make vol_id start only after mdadm has finished.
[04:24] <pitti> but not with -C
[04:24] <_ion> pitti: Perhaps it should print an error message and exit, if it's called with -C and l-r-m isn't installed.
[04:25] <pitti> _ion: right, I agree; that won't prevent that funny broken cache behaviour, though
[04:26] <_ion> pitti: The save_restricted_list exception handling probably should let the exception propagate forward if there was an error *during* the write operation, but ignore the error if it occurred during the file was being opened for writing.
[04:26] <iwj> Keybuk: And indeed I can see evidence of it in Nafallo's udev.txt.
[04:27] <Keybuk> iwj: then it gets "unknown volume type"
[04:27] <Keybuk> run_program: 'watershed -li udev-mdadm true'
[04:27] <Keybuk> run_program: '/lib/udev/watershed' returned with status 0
[04:27] <Keybuk> run_program: 'vol_id --export /dev/.tmp-9-2'
[04:27] <Keybuk> run_program: '/lib/udev/vol_id' (stderr) '/dev/.tmp-9-2: unknown volume type'
[04:27] <Keybuk> run_program: '/lib/udev/vol_id' returned with status 4
[04:27] <pitti> _ion: oh, right, in this case l-r-m modaliases won't help us
[04:27] <bddebian> Heya folks
[04:27] <Keybuk> because the md has been added, but no drives yet added to it
[04:27] <Keybuk> md* get created whenever you run mdadm for the first time and vaguely go near that device
[04:28] <Keybuk> ADD /block/md0 doesn't mean md0 is ready
[04:28] <iwj> Keybuk: Yes, that's expected.  But you get a change later, right ?
[04:28] <Keybuk> it means you have at least one block device of the set now
[04:28] <Keybuk> no
[04:28] <iwj> Oh, FFS.
[04:28] <Keybuk> you don't get a CHANGE with current kernels
[04:28] <Keybuk> that's the problem I was talking about on friday
[04:28] <Keybuk> that's the patch we're waiting for
[04:28] <iwj> I don't want to try to fix this in the kernel.  Just more different versions of crack.
[04:28] <Keybuk> BenC: ping
[04:29] <iwj> The trick perhaps is to remove all non-active md's in the local-top/mdadm script ?
[04:29] <Keybuk> I'm not sure that'll help?
[04:30] <Keybuk> the kernel still seems to know about it
[04:30] <iwj> If we remove the device when it's dead then when local-top/mdadm finally decides to activate it it will ... 
[04:30] <iwj> ... damn.
[04:30] <Keybuk> there doesn't seem to be a kill-the-md-and-forget-about-it except rmmod
[04:30] <Keybuk> just "stop"
[04:30] <Nafallo> iwj: found the log from my tests. when I runned it without break=premount it stopped with this:
[04:30] <iwj> And after it's created you get nothing.
[04:30] <Nafallo>   mdadm: No devices listed in conf file were found.
[04:30] <Nafallo>   Failure: failed to assemble all arrays.
[04:30] <Keybuk> (you certainly don't get a remove caused by stop)
[04:31] <Keybuk> quest md% grep kobject_uevent md.c
[04:31] <Keybuk>         kobject_uevent(&mddev->gendisk->kobj, KOBJ_CHANGE);
[04:31] <Keybuk> hmm
[04:31] <Keybuk> that's interesting
[04:31] <Keybuk> the kernel code does call change
[04:32] <iwj> Keybuk: If you're right there are three answers: 1. kernel patch you mention to produce change on change; 2. make mdadm synthesize a udev event somehow; 3. make the mdadm bootup script never attempt to assemble arrays which aren't completely ready by replicating all of the logic in mdadm.
[04:32] <iwj> Oh and  4. make a special test mode for mdadm which doesn't actually create the device.
[04:32] <iwj> If it segfaults you know you can run it for real :-).
[04:33] <Keybuk> ok, well, in theory, if I reboot this vmware image, I now have a root md-on-lvm just like siretart's set up
[04:34] <iwj> Keybuk: Just a mo.
[04:34] <iwj> No, never mind.
[04:34] <iwj> Keybuk: I have one here and obviously it WFM.
[04:34] <Keybuk> iwj: I haven't got any thoughts yet :-/
[04:34] <iwj> If I knew where to put sleeps ...
[04:35] <Keybuk> putting a sleep in the udev rules for md devices cures the problem
[04:36] <Keybuk> loooong sleep :p
[04:36] <iwj> Keybuk: Oh, that's probably coincidence.  Something else makes vgscan run and then you're fine.
[04:37] <iwj> Let me get my own log and see if I can see the change I'm expecting.
[04:37] <iwj> This machine has a usb stick as half of the root mirror so it ought to demonstrate the race if it's just the lack of this change event.
[04:38] <iwj> Of course it doesn't but maybe the log will tell me something.
[04:38] <Keybuk> hmm, that didn't work to boot
[04:38] <Keybuk> it couldn't find the kernel
[04:38] <iwj> I don't think that's relevant.  I hope ...
[04:40] <ogra> Keybuk, well, mount supports a lot more options ... like proto=tcp/udp for nfs ....
[04:41] <ogra> and i think nfsmount is only a sylink to klibc-munt
[04:41] <ogra> *mount
[04:41] <ogra> but i might be wrong here 
[04:51] <Keybuk> iwj: I'm trying a test
[04:51] <iwj> Keybuk: I'm definitely getting some kind of event relating to md0 when my md0 changes from   mdadm: /dev/md0 assembled from 1 drive (out of 2), but not started  to  /dev/md0 has been started with 2 drives
[04:51] <iwj> It then runs vol_id and gets the right answers.
[04:51] <Keybuk> what event?
[04:51] <iwj> It's a bit hard to tell what with all the usb noise.
[04:52] <iwj> udev_event_run: seq 1631 forked, pid [2877] , 'change' 'block', 0 seconds old  I think.
[04:52] <iwj> Err, these seqs are sequence numbers, right ?  Why do I see the same one more than once ?
[04:52] <iwj> root@samual13:~# grep 'seq 1631 forked' /root/ul  | wc -l
[04:52] <iwj> 22
[04:54] <iwj> But I'm sure this event is happening because I see
[04:55] <iwj> udev_node_add: creating device node '/dev/md0', major = '9', minor = '0', mode = '0660', uid = '0', gid = '0'
[04:55] <iwj> and then it runs vgscan.
[04:58] <iwj> Perhaps the device isn't useable even immediately after mdadm returns although you would have expected someone else to notice that.
[04:59] <iwj> Nafallo, siretart: I really need that failing udev log I think which an explanation of why you think the log is of a failing run :-).  (See my previous request for info, as I sent to the bug on Friday ...)
[04:59] <iwj> s/which/with
[05:04] <ogra> mdz, !!!
[05:04] <ogra> mdz, WELCOME TO EUROPE !!!!!
[05:04] <ogra> :D
[05:04] <mdz> hi
[05:04] <Keybuk> iwj: multiple things forked for the same event?
[05:26] <iwj> Keybuk: Oh, IC, like that.
[05:26] <iwj> Anyway, it's clear that I do get an event which looks like a change.
[05:26] <Keybuk> yeah
[05:26] <Keybuk> looking for that now
[05:26] <Keybuk> (I stuck udevmonitor in the initramfs)
[05:29] <Keybuk> MD/LVM-lovers
[05:29] <Keybuk> how do you persuade GRUB that your /dev/md0 is actually /boot and not / ?
[05:30] <Keybuk> or do you lie to it, and just use / ?
[05:33] <Nafallo> Keybuk: my /dev/md1 is / :-)
[05:34] <Nafallo> plan to change that in the future though :-)
[05:34] <Keybuk> Nafallo: where's your /boot then?
[05:35] <mdz> Keybuk: I think making a symlink boot -> . is the traditional hack
[05:35] <Nafallo> Keybuk: on / :-)
[05:35] <Keybuk> Nafallo: oh, you literally fill your / with kernel images and have a /grub ?
[05:36] <wasabi_> Wait what's up with this?
[05:36] <Nafallo> Keybuk: no, I have a / with a /boot and everything else that's usually on / :-)
[05:36] <wasabi_> --root-device on grub-install
[05:36] <Keybuk> wasabi: yeah, but then grub doesn't know where /boot is?
[05:36] <wasabi_> or root (the md partition)
[05:36] <Keybuk> if my root is LVM-on-MD, grub can't read that, so cannae find kernels
[05:36] <wasabi_> Shouldn't care...
[05:37] <Keybuk> it needs to load the kernel? :p
[05:37] <wasabi_> pop open teh grub console...   root(partiton of /boot)     setup (real drive)
[05:37] <wasabi_> repeat for each drive.
[05:37] <Keybuk> yeah, but then you have to put kernel /vmlinuz... and initrd /initrd.img...
[05:38] <wasabi_> in /boot, yes.
[05:38] <Keybuk> which update-grub cheerfully overwrites with /boot/...
[05:38] <wasabi_> But you've told it what partition.
[05:38] <Keybuk> you're not understanding me
[05:38] <wasabi_> guess not. ;0
[05:38] <Keybuk> update-grub writes me entries that look like this:
[05:39] <Keybuk>   root     (hd0,0)
[05:39] <Keybuk>   kernel   /boot/vmlinuz-2.6.20-13-generic root=UUID=...
[05:39] <wasabi_> Oh, that's groot in meny.lst
[05:39] <wasabi_> Oh with the /boot in front of it.
[05:39] <Keybuk>   initrd   /boot/initrd.img-2.6.20-13-generic
[05:40] <wasabi_> hmm mine isn't doing that.
[05:40] <Keybuk> the problem is that hd0,0 is /boot
[05:40] <Keybuk> so those need to be /vmlinuz and /initrd.img
[05:40] <Keybuk> if I change it to hd0,6 (the real root) then it fails, because that's LVM-on-MD
[05:40] <Keybuk> and doesn't contain /boot anyway
[05:40] <wasabi_> not sure. mine is just doing /kernel name
[05:40] <wasabi_> looking around
[05:41] <wasabi_> my groot is set to (hd0,0)
[05:41] <Keybuk> groot?
[05:41] <wasabi_> in menu.lst
[05:41] <bddebian> :)
[05:41] <Keybuk> what's a groot?
[05:41] <Keybuk> oh, the option thingy
[05:41] <wasabi_> The option grub uses to find it's own partition.
[05:41] <wasabi_> I bet it uses that and realizes the kernels are in the same dir.
[05:41] <wasabi_> maybe heh
[05:42] <wasabi_> # directory's to look for the grub installation and the menu file
[05:42] <wasabi_> grub_dirs="/boot/grub /boot/boot/grub"
[05:42] <wasabi_> then i think it steps up one level to find the kernels.
[05:43] <Keybuk> . o O { one day, there's going to be an accident, and mdadm and lvm2 are going to accidentally slip into universe }
[05:43] <wasabi_> no no no. =(
[05:44] <wasabi_> # figure out where grub looks for the kernels at boot time
[05:44] <wasabi_> kernel_dir=/boot
[05:44] <wasabi_> if [ -n "$boot_device" ]  ; then
[05:44] <wasabi_>         kernel_dir=
[05:44] <wasabi_> fi
[05:44] <wasabi_> Hmm.
[05:44] <wasabi_> That has something to do with it. :0
[05:45] <Nafallo> Keybuk: . o O { ...and then Keybuk will have to move them back to main again ;-) }
[05:45] <Keybuk> Nafallo: "have to" ? :p
[05:45] <Nafallo> Keybuk: if you don't want to break users setups :-)
[05:46] <Keybuk> Nafallo: does your setup work perfectly? :p
[05:46] <Keybuk> (and it wouldn't result in things being uninstalled, after all)
[05:46] <wasabi_> Mine is NEAR perfect.
[05:46] <wasabi_> I'm missing only evms. ;0
[05:46] <Keybuk> I'm just saying that we appear lack the skills, and the patience, to make this work :p
[05:46] <Nafallo> Keybuk: it did pre-feisty ;-)
[05:46] <wasabi_> Which I made sure to propose for feisty heh
[05:46] <wasabi_> The udev stuff helped.
[05:46] <wasabi_> watershed and all that
[05:47] <Keybuk> actually, I'll be fair
[05:47] <Keybuk> lvm seems to largely work
[05:47] <Keybuk> it's mdadm that's causing problems
[05:47] <Nafallo> agreed
[05:47] <wasabi_> I still vote for discarding mdadm.
[05:47] <wasabi_> And using evms. :0
[05:47] <wasabi_> A single cohesive system that knows about all the moving pieces.
[05:48] <Keybuk> wasabi: evms has the same problems ... it doesn't generate events to say that it's finished moving the pieces :p
[05:48] <wasabi_> Fixable.
[05:48] <Keybuk> you get an "I'm going to make a move sometime soon" event
[05:48] <Keybuk> wasabi: by whom?
[05:48] <wasabi_> The same guy who would potentially fix mdadm. :0
[05:48] <wasabi_> (you)
[05:48] <Keybuk> and who is that? :p
[05:48] <Keybuk> isn't me
[05:48] <wasabi_> Do we not have a demand for these things yet? I mean, "raid" is a commodity these days.
[05:49] <Keybuk> with any luck, someone with lots of mdadm, evms and LVM experience will apply for one of those open Ubuntu Server Developer positions
[05:49] <Keybuk> (planet-sized-hint :p)
[05:49] <wasabi_> Heh.
[05:49] <Nafallo> LOL
[05:50] <Nafallo> must be Win2K serial :-)
[05:52] <iwj> Keybuk: My setup works perfectly :-).  But I'm using lilo which is what the dapper installer gives you.
[05:52] <iwj> I think lilo uses fancy kernel ioctls to find out where the real data is.
[05:52] <iwj> Presumably it only reads from the first half of a mirror.
[05:53] <wasabi_> I dunno, my grub has been working perfectly.
[05:53] <wasabi_> It writes entries without /boot in front of them
[05:53] <Keybuk> randomly, GRUB has started behaving as wasabi says now
[05:53] <Keybuk> it must have not liked me having the old disk partially around
[05:53] <wasabi_> Oh, it's working?
[05:53] <Keybuk> apparently
[05:53] <Keybuk> last update-grub removed /boot from the front of everything
[05:53] <wasabi_> What'd you change?
[05:54] <Keybuk> it's still slightly kooky having grub peer at one half of a RAID-1, but it suffices
[05:54] <Keybuk> wasabi: nothing
[05:54] <wasabi_> Yeah, that's all you can do though.
[05:54] <wasabi_> What we need is a grub that can try bios drives in order.
[05:54] <wasabi_> Or some list there of.
[05:54] <Nafallo> that would rock! :-)
[05:54] <BenC> Keybuk: pong
[05:54] <wasabi_> linuxbios actually seems to have stuff for this. Which is very slick.
[05:54] <Keybuk> BenC: unping
[05:54] <wasabi_> So any drive can fail, and it can still boot.
[05:54] <iwj> wasabi_: If your BIOS doesn't do raid then are you hoping it will boot of your second disk ?
[05:55] <iwj> s/ of / off /
[05:55] <wasabi_> iwj: Yes.
[05:55] <iwj> I haven't tried that I have to admit.  I suppose it probably even works with SATA ...
[05:55] <wasabi_> iwj: It depends on your bios.
[05:55] <wasabi_> Most crappy one will just hang.
[05:55] <wasabi_> Some of the intel server boards I've used will actually try the next drive.
[05:55] <wasabi_> Which works wonderfully.
[05:56] <Keybuk> SATA scares me
[05:56] <wasabi_> Probably also depends on how the drive dies.
[05:56] <Keybuk> it randomly reordered my drives because I added a new one
[05:56] <wasabi_> Yeah, but we're not supposed to care about that naymore.
[05:56] <wasabi_> With evms and uuids and stuff.
[05:57] <wasabi_> Another solution is to grab a flash ROM and put that in there. ;)
[05:57] <Keybuk> grub still cares which one hd0 is, no?
[05:57] <wasabi_> Yup. Grub does.
[05:58] <wasabi_> Actually, I guess I'm not totally sure how it deals with that. The BIOS grabs stage0 or something, then that loads stage1? And I'm not sure how stage0 finds stage1.
[05:58] <Keybuk> iwj: oh, now this is a random failure
[05:58] <Keybuk> raids are assembled
[05:58] <Keybuk> lvm has been activated
[05:58] <Keybuk> but no uuid
[06:00] <wasabi_> so what do you mean about evms? It doesn't emit events for stuff in /dev/evms?
[06:00] <Keybuk> wasabi: I haven't even looked at evms yet
[06:00] <Keybuk> I'm still stuck on mdadm
[06:00] <wasabi_> heh.
[06:01] <poningru> [11:56:11]  <Keybuk> SATA scares me <--- that statement scares me to no avail
[06:01] <dholbach> Mithrandir: what do you think about bug 98525?
[06:03] <seb128> Mithrandir: could you have a look on https://bugs.launchpad.net/ubuntu/+source/rhythmbox/+bug/101953 also?
[06:05] <iwj> Keybuk: Freaky.
[06:05] <iwj> You've got lvm-on-raid ?
[06:05] <Keybuk> iwj: yeah
[06:05] <iwj> SATA is great.  You too can confuse your boot device with a camera.
[06:06] <Keybuk> iwj: ?  shouldn't; BIOS normally offers boot from removable/USB storage separately than SATA
[06:06] <iwj> Keybuk: The lack of uid is a bit odd but normally you wouldn't expect a uuid link for an lvm volume.
[06:06] <iwj> Keybuk: Yes, the bios knows but the modern Linux approach makes it a bit harder.
[06:07] <iwj> mkfs.msdos /dev/sdb2
[06:07] <iwj> oops!
[06:07] <iwj> and other amusements.
[06:07] <Keybuk> how would you name them to avoid that?
[06:07] <Keybuk> by path?
[06:07] <ogra> BenC, https://launchpad.net/ubuntu/+source/ltsp/+bug/97456 do you think its possible we can sit down together at UDS and talk about a -ltsp kernel flavor (i'm willing to take over maintenance/responsibility for the config)? 
[06:08] <BenC> ogra: Sure
[06:08] <iwj> Keybuk: Something like that.  Part of the problem is homogenisation of the device names.  If the USB drives were /dev/usbda1 or something (udev could tell from the path) then it would be much less confusing.
[06:08] <Keybuk> iwj: it's certainly doable
[06:09] <Keybuk> SUBSYSTEM=="block", SUBSYSTEMS=="usb", NAME="usbd%n"
[06:09] <Keybuk> type thing
[06:09] <iwj> Right.
[06:10] <iwj> Not sure what to do to make SATA drive naming more stable.  (As stable as scsi used to be would be fine ...)
[06:10] <ogra> BenC, seems the feisty kernel needs minutes instead of secods to boot on certain HW
[06:10] <Keybuk> SATA is stable
[06:10] <iwj> Keybuk: What, different drives on different controllers are always numbered in the same order ?
[06:10] <Keybuk> the single kernel storage device layer is the bit that isn't stable, since drives get assigned a letter in the order they request it
[06:10] <iwj> Keybuk: So anyway re your booting problem.  You say you have no uuid but why is that a problem ?
[06:10] <Keybuk> that was never stable for SCSI
[06:11] <iwj> Keybuk: In practice it was stable for scsi.
[06:11] <iwj> Anyway, this is a very old argument :-).
[06:11] <Keybuk> sure, -v will'#s patches
[06:11] <Keybuk> and in practice, it's equally stable for SATA
[06:11] <Keybuk> the problem is that SCSI, SATA and USB are all vying for the same enumerated namespace
[06:12] <iwj> Keybuk: That's part of it, yes.
[06:12] <Keybuk> and tbh, it just exposed a problem that was always there
[06:12] <Keybuk> dicking around with cables could always change the order
[06:12] <iwj> I tend to think removeable devices should be named by path.  So usb stuff would be named by the port you put it in.
[06:12] <iwj> dicking> very true.
[06:12] <Keybuk> so kinda like /dev/disk/by-path then?
[06:12] <iwj> Keybuk: Yes, only less crazy.
[06:12] <Keybuk> iwj: *shrug*
[06:12] <Keybuk> it's not that crazy
[06:12] <iwj> I mean, more friendly.
[06:13] <Keybuk> people actually do care which pci controller it turned up on
[06:13] <iwj> Yes, yes, but normal people want to know which usb stick is the one in the top hole.
[06:13] <Keybuk> sure
[06:13] <Keybuk> and this lets you do that, no?
[06:13] <iwj> So you should number the holes sequentially.
[06:13] <iwj> Like it used to be with disks and floppies.
[06:13] <Keybuk> pci-0000:00:02.1-usb-0:7:1.0-scsi-0:0:0:0@
[06:14] <iwj> It doesn't matter if the top hole turns out to be called 4 and the bottom one 3 provided it stays that way.
[06:14] <iwj> Keybuk: Nice string for the user's desktop.
[06:14] <Keybuk> first usb device in hole 7 on the second hub of the internal USB controller
[06:15] <iwj> That 7 doesn't necessarily correspond to a hole.
[06:15] <Keybuk> and that's a device name in /dev, that never shows up on the user's desktop
[06:15] <iwj> And most of the numbers there are useless.  Anyway, let's talk about this in a bar sometime.
[06:15] <Keybuk> HAL icons show up on the users desktop
[06:15] <iwj> I'm trying to talk to you to debug mdadm :-).
[06:15] <Keybuk> and those have a pretty picture that looks kinda like what you plugged in, and describe it
[06:15] <Keybuk> in my case "1GB disgo flash device"
[06:16] <Keybuk> right
[06:16] <Keybuk> so
[06:16] <Keybuk> err
[06:16] <Keybuk> what I've got, consistently is
[06:16] <Keybuk> /dev/md0..2 fired up, both drives active, etc.
[06:16] <Keybuk> /dev/mapper filled out, with /dev/ubuntuvg containing both things
[06:17] <Keybuk> but nothing in /dev/disk/by-uuid
[06:18] <iwj> Right.
[06:18] <iwj> That's correct.
[06:18] <iwj> Why do you need /dev/disk/by-uuid ?
[06:18] <Keybuk> no, I should have the UUIDs of the filesystems on the LVM LVs
[06:19] <iwj> Last time we had this conversation you said `no, we should be using the lv names'.
[06:19] <Keybuk> sure
[06:19] <Keybuk> but then I thought about it a bit more
[06:19] <iwj> Ah.
[06:19] <Keybuk> and realised that if that didn't work, it meant there was a race somewhere
[06:19] <Keybuk> which would be mad for trying to mount it anyway
[06:19] <iwj> I think it is more correct to use the name because if you re-mkfs the lv then you still wanted mounted the same way.
[06:19] <Keybuk> so may as well turn on uuid-for-dm and see what happens
[06:19] <iwj> IC
[06:19] <Keybuk> sure, I'm making a pathological test case though
[06:19] <Nafallo> Keybuk: feisty+1 please :-)
[06:19] <Keybuk> tower-of-hanoi of drives
[06:20] <iwj> Keybuk: OK.  I have lvm-on-md-on-(lvm-on-usb)+(lvm-on-ide)
[06:20] <iwj> But the crazier the better.
[06:21] <iwj> Anyway, your 65-persistent-storage.rules, does it run vol_id and persistent_storage_path_uuid stuff for dm-* change ?
[06:21] <iwj> The one I have here seems to although the LABELs are misnamed.
[06:23] <Keybuk> yes
[06:23] <iwj> So it runs vgchange and then after that has finished it runs vol_id but vol_id fails ?
[06:24] <iwj> vgchange> I mean this command:  watershed sh -c '/sbin/lvm vgscan; /sbin/lvm vgchange -a y'
[06:24] <Keybuk> interesting, running udevtrigger causes the uuids to show up
[06:24] <Keybuk> so definite race
[06:24] <Keybuk> but between _what_ ?
[06:24] <Mithrandir> dholbach: 98525 looks good to me
[06:24] <iwj> Yes, running udevtrigger fixes most things in this area :-).
[06:24] <dholbach> Mithrandir: gracias
[06:24] <iwj> There are practically no bugs but races.
[06:24] <Keybuk> iwj: an evil hacky solution occurs to just stick a once-a-second udevtrigger into the "Waiting for root filesystem" loop
[06:25] <iwj> OMG WTF BBQ
[06:25] <Keybuk> assuming we don't find the (ahem) root of the problem
[06:25] <j1mc> anyone know when the herd6 candidates will be announced?  i'd like to coordinate for xubuntu testing.  thanks.
[06:25] <iwj> You know I'm almost tempted to say `do it anyway'.
[06:25] <ogra> BenC, also, will all debugging flags get switched off in the fial kernel image ? 
[06:25] <ogra> *final
[06:25] <siretart> Keybuk: I can confirm this behavior. udevtrigger virtually always fixes things for me, but only when called manually. putting it into the boot script didn't :/
[06:25] <iwj> Turn it off again for the early feisty+1's to give us a chance to find more bugs.
[06:25] <Mithrandir> seb128: rhythmbox > go for it.
[06:25] <Keybuk> udevtrigger is cheap, it just tickles the kernel
[06:25] <seb128> Mithrandir: thank you
[06:26] <ogra> j1mc, afaik we wont do herd6
[06:26] <iwj> Keybuk: Every 1s would probably be too often though; some of these things seem to take more than 1s to do and it might get tangled up with itself.
[06:26] <Mithrandir> j1mc: oh, thanks for reminding me, I'll send a mail to u-d-a saying we won't have them.
[06:26] <Keybuk> which, since it can only repeat uevents that have already happened, implies that an event happens too early to be useful
[06:26] <iwj> Keybuk: It makes udevd repeat all the processing some of which is quite slow.
[06:26] <Keybuk> yeah
[06:26] <Keybuk> udev sulks if it receives too many events
[06:26] <siretart> on my system (amd64 3000+, it takes about 3 seks for udevtrigger to settle down)
[06:27] <iwj> Keybuk: So do you have a udevd --verbose --suppress-syslog >>something  for your symptoms ?
[06:27] <j1mc> Mithrandir: thanks.  we'll just have the single RC release then?
[06:27] <ogra> siretart, get an amd64 6000+, then it will only take 1.5 :P
[06:27] <Keybuk> well
[06:27] <iwj> Keybuk: Maybe we should have an optional boot arg  `udevtrigger_repeat_interval'  which defaults to 0 meaning turned off.
[06:27] <Keybuk> the good news is that we *do* get a CHANGE /block/md0
[06:27] <iwj> Keybuk: Yes, I get one too.
[06:28] <Mithrandir> j1mc: yes.
[06:28] <Keybuk> UDEV  [1175529927.085968]  change   /block/md0 (block)
[06:28] <Keybuk> UDEV_LOG=6
[06:28] <Keybuk> ACTION=change
[06:28] <Keybuk> DEVPATH=/block/md0
[06:28] <Keybuk> SUBSYSTEM=block
[06:28] <Keybuk> SEQNUM=1596
[06:28] <Keybuk> MINOR=0
[06:28] <Keybuk> MAJOR=9
[06:28] <Keybuk> UDEVD_EVENT=1
[06:28] <Keybuk> DEVNAME=/dev/md0
[06:28] <iwj> So that's supposed to run    watershed sh -c '/sbin/lvm vgscan; /sbin/lvm vgchange -a y'
[06:28] <iwj> which evidently works.
[06:28] <Keybuk> and the result of the change is that the dm-* appear
[06:28] <Keybuk> oh, d'oh, vol_id isn't run for change because I forgot about the silly udev != | bug
[06:28] <j1mc> Mithrandir: ogra: thanks.  :)
[06:28] <iwj> Keybuk: Oh, that'll be it.
[06:29] <iwj> Doesn't happen for me because my rules look different.
[06:29] <iwj> We're still in the dark about Nafallo and siretart's systems though.
[06:29] <keescook> Keybuk: did you get what you needed wrt swap-on-md?  (It looks like you did from the irc log)
[06:29] <Nafallo> iwj: I'm fine if you fix your systems first ;-)
[06:30] <iwj> Nafallo: Mine works just fine, as I say.  If only it would break like yours that would be lovely ...
[06:30] <Keybuk> keescook: yeah, I have that working
[06:30] <Keybuk> iwj: given change, I really don't think we need the extra watershed -l bit ?
[06:31] <keescook> Keybuk: anything I can help with atm?
[06:31] <Nafallo> iwj: hmm. nothing could have made it break because the computer was installed a long time ago? warty or so... ;-)
[06:31] <iwj> Keybuk: Well, you can take it out if you like but I'm mistrustful.
[06:31] <iwj> It's definitely harmless (I think) and we don't understand mdadm well enough to be sure it's not needed.
[06:31] <iwj> And of course we can't prove it's not needed without fully analysing mdadm.
[06:32] <iwj> Nafallo: My test install is from dapper.  It might make a difference but the right approach is to try to collect debugging data etc. so we can try to understand your system's failure.
[06:32] <Nafallo> iwj: ofcourse :-)
[06:33] <iwj> I don't think I read through what was in your initramfs udev rules but I assume it's similar to siretart's which I did eyeball.
[06:33] <Keybuk> ok, now if I do (from break=premount), /scripts/init-premount/udev
[06:33] <Nafallo> as soon as I have a backupclient online and working I can try some more reboots :-)
[06:33] <Keybuk> after a few seconds, my three MD and two LVs are both assembled
[06:33] <Keybuk> and UUIDs are available for all of them
[06:34] <Nafallo> Keybuk: kewl! :-)
[06:34] <Keybuk> so I can do mount-by-uuid for LVM-on-MD
[06:34] <iwj> Keybuk: Congratulations on failing to reproduce the bug :-).
[06:34] <Keybuk> actually probe-for-root-fs (since that's the root= one)
[06:35] <Keybuk> and that's before scripts/local-top/mdrun or scripts/local-top/mdadm are even called
[06:35] <Keybuk> so, err, what do those do?
[06:35] <iwj> .../mdrun is a fossil and exits because .../mdadm exists.
[06:35] <iwj> .../mdadm is the thing run from udev.
[06:35] <Keybuk> right, but does initramfs need to run it as well?
[06:36] <Keybuk> I guess it doesn't hurt, but it's worth remembering we might be able to take it away later
[06:36] <iwj> It used to be called manually from init (and I think it still is) and I decided not to move it.
[06:36] <iwj> Indeed. so.
[06:36] <Keybuk> likewise for the two init scripts in the main boot sequence
[06:36] <iwj> I didn't want to rename it since it was full of stuff I didn't want to understand too closely.
[06:37] <Keybuk> we don't appear to need either the mdadm-raid or lvm init scripts either
[06:38] <Keybuk> the only thing we do need to do is "understand" the mdadm initramfs script, and turn it into a /lib/udev/mdadm that we can use in both initramfs and the real filesystem
[06:38] <Nafallo> do we need lvm-common to dep mdadm? :-)
[06:39] <Keybuk> Nafallo: no
[06:40] <Nafallo> Keybuk: you might want to change that then... ;-)
[06:40] <Keybuk> already done
[06:40] <Nafallo> kewl! :-)
[06:40] <iwj> mdadm-raid is ebw.
[06:41] <iwj> Keybuk: It's not clear to me what the right functionality for /lib/udev/mdadm is.  I don't like the security properties of all this automatic device scanning.  But I think I'm probably just doomed.
[06:43] <Keybuk> ebw?
[06:46] <pitti> seb128, dholbach, *: launchpad-crash-digger updated for new python-launchpad-bugs, so it now actually works again with new LP
[06:46] <dholbach> nice
[06:46] <seb128> pitti: rock on
[06:46] <iwj> Evil, Bad and Wrong.
[06:49] <pitti> Mithrandir: yay, https://launchpad.net/ubuntu/+milestone/ubuntu-7.04 finally sorts correctly after 'Status'; I guess that makes you really happy :)
[06:51] <pitti> Mithrandir: if only it would ignore duplicates...
[06:52] <seb128> doko, pitti: do you remember what component has the bug ctrl-left,right doesn't work on a command line? bash? readline?
[06:53] <seb128> pitti: I do reject duplicates ;)
[06:53] <pitti> seb128: I never knew, I think
[06:53] <seb128> ok
[06:53] <pitti> just that it is really annoying :/
[06:53] <seb128> pitti: do you know if there is a bug open or if that was only mentionned on IRC?
[06:53] <seb128> there was one on gnome-terminal which is wrong
[06:53] <seb128> I reassigning to bash, not sure though
[06:57] <seb128> Mithrandir: do you have an opinion on whether "dcraw" should be added to desktop or ship or somewhere else?
[07:08] <Mithrandir> seb128: for f-spot?  -desktop, then.
[07:08] <seb128> Mithrandir: yes, ok, thank you
[07:52] <mvo> cjwatson_: could it cause any problems if I change ubuntu-meta so that the Section is "metapackages" instead of "base"? this should fix bug #82876
[07:52] <ubotu> Malone bug 82876 in apt "Synaptic wants to reinstall all recomended packages on upgrade" [Undecided,Confirmed]  https://launchpad.net/bugs/82876
[07:52] <Mithrandir> mvo: apart from the fact that you need it changed in the archive? :-P
[07:55] <mvo> Mithrandir: its overwritten for the Packages files already (if that is what you mean)
[07:56] <Mithrandir> mvo: the overrides in the archive would be where it would actually be changed, what's in the package is just advisory.
[07:57] <mvo> Mithrandir: right. but whats in the package goes into /var/lib/dpkg/status and I want the Section: metapackages there :) 
[07:58] <mvo> Mithrandir: so that even if the archive is not available (or the version in the archive) the section is correct. apt is currently doing some magic (recommends, auto-install) for section. metapackages
[07:58] <mvo> Mithrandir: I just want to be sure that it does not break any assumptions somewhere else (soyuz, germinate etc)
[08:04] <Mithrandir> ogra: can you respond to svu on 97342, please?
[08:04] <ogra> oh, indeed
[08:12] <siretart> iwj: do you have anything to test for me?
[08:21] <ogra> siretart, there were two uploads on -changes ....
[08:22] <siretart> mmh. shall I dare to break^Wupgrade my system? ;)
[08:23] <ogra> you have a fallback laptop, dont you ? ;)
[08:24] <siretart> I do :)
[08:25] <desrt> so
[08:25] <desrt> launchpad got bling
[08:26] <desrt> looks nice :)
[08:26] <siretart> hm. I see uploads of lvm, mdadm and udev, but I only see the udev binaries in the archive. hmm
[08:28] <siretart> desrt: launchpad got bling?
[08:28] <siretart> oh, finally the beta phase ended! \o/
[09:16] <siretart> ok. first try with Keybuks packages: success. let's try another boot.
[09:17] <siretart> 2nd boot as well. w00t! \o/ :)
[09:33] <ajmitch> morning
[09:34] <Burgwork> morning ajmitch
[09:34] <ajmitch> Burgwork: you mentioned something about zope earlier?
[09:35] <Burgwork> yep, poor fedora people are still struggling with the python2.4 issue
[09:35] <ajmitch> ah
[09:36] <da_man_2007> hi,,does the crash handler code really help ?
[09:37] <da_man_2007> I have direct reason for asking so bear with me
[09:47] <boitono> I recently upgraded a server from dapper to edgy and one of the packages we rely on, otrs, was downgraded from 2.0.4 to 1.33~.  I found that otrs 1.33~ was added to the edgy repository and took the name otrs and otrs 2.0.4 was renamed otrs2. Why did this happen? Can anyone give me some more info?
[10:26] <KnowledgEngineer> hello
[10:26] <KnowledgEngineer> make menuconfig return a strange output
[10:27] <KnowledgEngineer> http://rafb.net/p/PaU1bK89.html
[10:27] <KnowledgEngineer> someone can help me please?
[10:27] <KnowledgEngineer> i need just to change the timer frequency 
[10:27] <KnowledgEngineer> and recompile the kernel
[10:27] <LeeJunFan> KnowledgEngineer: you need ncursed-dev
[10:28] <LeeJunFan> libncurses5-dev
[10:29] <LeeJunFan> really not a question for the devel channel though.
[10:29] <KnowledgEngineer> tks
[10:38] <KnowledgEngineer> for low latency kernel i must change the timer frequncy from 250 to 1000 or form 250 to 100
[10:38] <KnowledgEngineer> Hz
[10:40] <Mithrandir> uh, why not just install the low-latency kernel from universe?
[10:41] <KnowledgEngineer> a good
[10:42] <KnowledgEngineer> the rest of configuration is the same of default ubuntu kernel ?
[10:42] <Mithrandir> should be
[10:44] <Nafallo> no
[10:44] <Nafallo> something with PREMPT aswell :-)
[10:45] <KnowledgEngineer> i need enable preempt
[10:45] <KnowledgEngineer> in what submenu is preempt ?
[10:45] <LeeJunFan> KnowledgEngineer: not if you install the low-latency kernel.
[10:45] <Nafallo> KnowledgEngineer: as Mith said, just install it from universe :-)
[10:46] <KnowledgEngineer> i prefer do not install the low latency kernel if i'm not totally sure that the rest of configuration is the same of current kernel that i'm using
[10:46] <Nafallo> KnowledgEngineer: the only changes are HZ and PREEMPT AFAIK
[10:47] <Nafallo> KnowledgEngineer: just try it and see if it works?
[10:47] <KnowledgEngineer> ok
[10:47] <KnowledgEngineer> apt-get install what ??
[10:48] <Nafallo> linux-image-2.6.20-13-lowlatency
[10:48] <Nafallo> or linux-image-lowlatency to be up-to-date
[10:49] <Lure_> KnowledgEngineer: these are all the changes between generic and lowlatency: http://git.kernel.org/?p=linux/kernel/git/bcollins/ubuntu-2.6.git;a=blob_plain;f=debian/config/lowlatency.config;hb=HEAD
[10:51] <KnowledgEngineer> Nafallo, apt do not find linux-image-lowlatency
[10:52] <KnowledgEngineer> source.list
[10:52] <KnowledgEngineer> deb http://archive.ubuntu.com/ubuntu/ edgy universe main multiverse restricted
[10:52] <Mithrandir> it's only in feisty.
[10:53] <KnowledgEngineer> deb http://archive.ubuntu.com/ubuntu/ edgy-updates universe main multiverse restricted
[10:53] <KnowledgEngineer> and other ....
[10:53] <Mithrandir> doko: why is glibc built with -g1 and not just -g?
[10:58] <KnowledgEngineer> 1) ( ) No Forced Preemption (Server)
[10:58] <KnowledgEngineer> 2) ( ) Voluntary Kernel Preemption (Desktop)
[10:58] <KnowledgEngineer> 3) ( ) Preemptible Kernel (Low-Latency Desktop)
[10:58] <KnowledgEngineer> what of this option i need to select?
[10:58] <KnowledgEngineer> aaa 3
[10:59] <Mithrandir> KnowledgEngineer: this channel is not for support; try #ubuntu
[11:06] <mjg59> pochu: New liferea crashes whenever I try to view the original post
[11:06] <mjg59> pochu: That is, whenever I click on the subject line to spawn the viewer
[11:06] <pochu> mjg59: actually updating it
[11:06] <mjg59> pochu: Score :)
[11:06] <pochu> mjg59: there is a new release (5 minutes ago)
[11:06] <pochu> mjg59: and there are already 5 bugs about it ;)
[11:06] <mjg59> Ha, excellent
[11:07] <pochu> mjg59: are you in the release team?
[11:07] <mjg59> Nope
[11:07] <pochu> ok, np
[12:10] <tbf> hi, notification-daemon 0.3.6 seriously leaks X11 windows
[12:10] <tbf> each notification leaves two root windows behind