[00:10]  * away_Sgiomlairea is now away - Reason : dinner
[00:10] <ion> Gee, thanks a lot for the information!
[00:10] <micahg> !away | away_Sgiomlairea
[02:44]  * Sgiomlaireachd is no longer away : Gone for 2 hours 34 minutes 41 seconds
[03:24] <TheMuso> !away | Sgiomlaireachd
[05:05] <poolie> TheMuso: that's at least twice today
[07:10] <pitti> Good morning
[07:10] <pitti> mdeslaur: yes, I did run the tests on maverick, they all succeeded
[07:10] <pitti> mdeslaur: ah, good
[07:45] <[newbie]> hello
[07:45] <Crissi> how the graphical installer is named?
[07:45] <Crissi> i found a bug into it
[07:45] <pitti> ubiquity
[07:46] <Crissi> ah
[07:46] <Crissi> i tested the rc of maverik and install fails
[07:46] <Crissi> because i cant install to the iscsi hdd
[07:46] <Crissi> its not selectable
[07:55] <\sh> pitti: any clue how to change the order of sys.path ? I would like to have /usr/local/lib/python<VER>/dist-packages included before /usr/lib/python...
[07:56] <\sh> good morning btw
[08:08] <\sh> ok, sys.path shows me that $HOME/.local/lib/python<VER>/site-packages comes before /usr/lib/python2.6, but it still imports the old version of a lib which is installed in $HOME/.local/... and /usr/lib/python2.6/... argl
[08:10] <YokoZar> Is a final ia32-libs update possible (to sync it with the other libraries) ?
[08:22] <pitti> \sh: hey
[08:22] <pitti> YokoZar: that depends on whether that's shipped on any of the images
[08:23] <pitti> i. e. xubuntu or edubuntu; probably not, but we need to check
[08:23] <YokoZar> pitti: it's larger than the size of a CD, so I imagine it isn't
[08:23] <pitti> YokoZar: ? ia32-libs is not that bad
[08:23] <pitti> 33 MB or so
[08:23] <YokoZar> err nm I'm thinking source pacakge
[08:23] <pitti> the source is a hog, sure
[08:24] <pitti> \sh: hm, some old .pyc files perhaps?
[08:25] <pitti> \sh: did you try python -v -c 'import mymod' to see what it's doing?
[08:27] <amitk> morning
[08:28] <\sh> pitti: http://paste.ubuntu.com/508583/ <- this looks wrong
[08:28] <\sh> it's using the pyOpenSSL version from the /usr/lib path, but not from the .local path
[08:28] <dholbach> good morning!
[08:29] <pitti> \sh: perhaps add a "print sys.path"?
[08:30] <\sh> pitti: http://paste.ubuntu.com/508586/ <- this is wrong...$HOME/.local comes after /usr/lib/python2.6 ...
[08:31] <\sh> but all easy_install.pth eggs are before...(btw...even installing under /usr/local/lib/python<ver>/dist-packages doesn't help
[08:31] <\sh> hey dholbach
[08:31] <dholbach> heya \sh
[08:37] <\sh> pitti: I wonder if this is actually right, to set /usr/local after /usr in sys.path, while all setuptools installed modules are coming before /usr... there is (IMHO!) a mistake in setting this path
[08:38] <\sh> normally someone wants to overlay the system libs in /usr/local/lib or $HOME/.local/lib/
[08:56] <jibel> mvo, hey, how are things ?
[08:57] <jibel> mvo, We received bug 639933 this morning again. This is affecting kubuntu users trying to upgrade to 10.10
[09:01] <mvo> jibel: I tried to reproduce this yesterday without success, were you be able to reproduce?
[09:02] <mvo> jibel: I try again today
[09:02] <jibel> mvo, no I didn't. I haven't tested hard tough. I finish some wubi testing this morning and I'll try again.
[09:04] <mvo> jibel: thanks
[09:06] <\sh> pitti: sys.path.insert(0,"/home/shermann/.local/lib/python2.6/site-packages/") helps to overcome the bugger now...but I think we need to fix this sys.path problem somehow
[09:13] <\sh> doko: you are my python man ;) do you eventually know why $HOME/.local/lib/python<VER>/site-packages and /usr/local/lib/python<VER>/dist-packages are included in sys.path after /usr/lib/pymodules/* , while I expected that those paths are before the system paths (for overlaying python system libs with newer version)?
[09:16] <doko> \sh: I didn't change anything with this. I hope /usr/lib/pymodules/* will be gone in 2.7. ask barry about it
[09:17] <\sh> barry: ^^ :)
[09:29] <YokoZar> pitti: I'm going to bed, but if you could please check the seeds for any use of ia32-libs and if it comes up clean just do a ./fetch-and-build and reupload it would be great
[09:30] <YokoZar> or I suppose I could do that right now and you can accept/reject as you wish
[09:34] <kklimonda> slangasek: hmm, have you synced python-django 1.2.3-1 or did you manage to stop it? :)
[09:35] <kklimonda> slangasek: i.e should I prepare a 1.2.3-1ubuntu1 or even 1.2.3-1ubuntu0.1 or is 1.2.3-0ubuntu1 still valid
[09:36] <cjwatson> Crissi: ubiquity isn't expected to support iSCSI - missing feature rather than bug
[09:36] <persia> kklimonda, rmadison (from devscripts) suggests 1.2.1-1 is current (you may find this tool generally useful)
[09:36] <Crissi> no
[09:36] <Crissi> its a bug
[09:36] <kklimonda> persia: oh, it works in the real time? :)
[09:36] <Crissi> it should be possible to install on it
[09:36] <cjwatson> call it what you like.  but it won't be, in 10.10
[09:36] <Crissi> it can be the only one system hd
[09:36] <cjwatson> sorry
[09:36] <Crissi> it should
[09:36] <Crissi> in 10.10
[09:36] <cjwatson> it will not.  period
[09:36] <persia> kklimonda, My understanding is that it hits a CGI that queries current status: might be old by a publisher run or so.
[09:36] <cjwatson> far too late to be adding that kind of thing to ubiquity
[09:36] <Crissi> hrrr
[09:37] <Crissi> no
[09:37] <cjwatson> you're welcome to file a bug report and we can consider it for later releases
[09:37] <Crissi> thats bug was in 10.04 and 09.10 too
[09:37] <cjwatson> sure, that feature has never been available in ubiquity
[09:37] <Crissi> still done
[09:37] <Crissi> why?
[09:37] <Crissi> its important
[09:38] <cjwatson> ubiquity is a desktop installer.  you're literally the first person I'm aware of to care about it having iSCSI support
[09:38] <Crissi> if i install a opensuse i can select in graphical installer...
[09:38]  * wgrant hasn't seen an iSCSI desktop before.
[09:38] <Crissi> iscsi has nothing to do if desktop or not
[09:38] <cjwatson> we have a different installer for servers, which supports iSCSI
[09:38] <persia> YokoZar, ia32-libs -> wine1.2 -> lmms-vst -> ubuntustudio-audio -> Ubuntu Studio images
[09:38] <cjwatson> that's as may be, but you are the first person to ask for it on desktop
[09:38] <Crissi> its an media like scsi, ide, flash, ...
[09:38] <cjwatson> you can use the alternate CD to install a desktop on iSCSI
[09:38] <cjwatson> you just can't use the desktop CD
[09:38] <Crissi> huh? that cant  be true.
[09:39] <cjwatson> it is true.
[09:39] <YokoZar> persia: is that spun yet?
[09:39] <Crissi> :(
[09:39] <Crissi> that a pity.
[09:39] <cjwatson> use the alternate CD and be happy. :-)
[09:39] <Crissi> i usedd the server cd which provides it in text installer
[09:39] <cjwatson> the alternate and server CDs use the same installer, yes
[09:39] <Crissi> but it really should be available in graphical installer
[09:39] <cjwatson> the alternate CD will install desktop packages
[09:40] <persia> YokoZar, http://iso.qa.ubuntu.com/qatracker/build/ubuntustudio/all is present, but I admit I'm not sure if there's currently a concern that would result in a respin.
[09:40] <YokoZar> persia: how about a new ia32-libs ;)
[09:40] <persia> YokoZar, You'd have to ask ScottL : it depends on tester availablility more than anything, I think.
[09:41] <Crissi> just a hint: download a opensuse cd/dvd and install in a virtual machine (like virtualbox) and see how easy it can be. dont understand me wrong, i like ubuntu/debian but opensuse is has a nice way to install graphically for end users
[09:41] <YokoZar> ScottL: well hopefully he'll see the backscroll and this gets handled (or not) while I'm asleep
[09:41] <persia> He's in a timezone not fara removed from your usual, so unlikely to see it for a few hours, at best.
[09:41] <Crissi> then you will got some useful ideas for the graphical debian installer :)
[09:43] <Crissi> btw: the graphical installer hangs after selecting german and click next if run in kvm :(
[09:43] <Crissi> vbox works
[09:45] <cjwatson> testing that
[09:53] <cjwatson> seems to work fine for me in kvm
[09:53] <cjwatson> remember that kvm's default memory is set to 128M which is unlikely to be enough
[09:56] <lifeless> sladen: ping
[09:56] <lifeless> https://edge.launchpad.net/~contributor-agreement-canonical/+invitation/uff-contributors - why?
[09:57] <doko> cjwatson: maybe not the best time, did see the thread about CD space and wanted to point at the fdupes output, but couldn't find any. is fdupes installed on the CD build host?
[09:58] <doko> mvo suggested that ...
[10:02] <cjwatson> doko: livefs build logs
[10:03] <cjwatson> doko: e.g. http://people.canonical.com/~ubuntu-archive/livefs-build-logs/maverick/ubuntu/latest/livecd-20101007-i386.out
[10:05] <sladen> lifeless: so that @canonical.com employees can commit
[10:05] <doko> cjwatson: thanks, was looking at the wrong logs ...
[10:05] <sladen> lifeless: is there a better way of doing that?
[10:06] <sladen> lifeless: or should I just add anyone who needs to (eg. Mark) individually
[10:15] <cjwatson> sladen: if you do that, aren't we all going to get even more mail about stuff we don't care about?
[10:27] <lifeless> sladen: give me some context
[10:27] <lifeless> sladen: the group you've invited is the list of folk that have *signed the contrib agreement*, which is a necessary but not sufficient condition for community contributors to canonical projects
[10:28] <lifeless> sladen: if you're using this for ACL's, its misguided.
[10:28] <lifeless> sladen: that list is a useful hint, its a) not the authoritative list (legal hold that) and b) not appropriate for subscribing (directly or indirectly) to objects in LP.
[10:29] <sladen> lifeless: okay, fair enough.  So the answer is eg. to check against that list if somebody makes a request, and then to add them individually
[10:29] <lifeless> yes
[10:29] <sladen> lifeless: awesome, can you DENY that invitation (I can't seem to cancel it, even with hand-hacking +member URLs
[10:30] <lifeless> done
[10:42] <poolie> sladen, lifeless, uh if you're happy to grant access to anyone who's signed the agreement, you can use that team
[10:42] <poolie> having signed the agreement does not necessarily guarantee they know what they're doing
[10:43] <poolie> s/use/grant access to
[10:44] <poolie> excess mail  being sent to that group could be more or a problem
[11:04] <kklimonda> lifeless: btw, should I be added to the ~c-a-c group if I've been asked to sign the agreement? Or should I care about it only when I get asked again to sign it? ;)
[11:04] <poolie> kklimonda: normally you will be added when the project lead receives your assent
[11:48] <dpm> hi pitti, re: the e-mail I sent you some days ago about a language pack update schedule, is it ok if I subscribe you to the blueprint to participate in the session at UDS?
[11:50] <pitti> dpm: sure, please do; right, I still need to get to this mail
[11:52] <dpm> pitti, cool, thanks. Don't worry too much about the e-mail, as I said it's not urgent, and I know you've probably got enough on your plate right now
[12:26] <ScottL> persia, YokoZar : i'm not sure what is being asked, the RC image was tested and now two more images were released, are we asking for a another respin?
[12:29] <persia> ScottL, There's been a refresh of ia32-libs, which differs from that on the 20101007 images currently at iso.qa.ubuntu.com.  Since that falls in your image, your input to the release team on whether to accept it or push to a post-release update is likely of considerable interest.  If you request a respin, any tests done to 20101007 would need to be repeated.
[12:30] <ari-tczew> slangasek: plymouth in Ubuntu maverick not looks good. I have a photo, I'll file a bug.
[12:58] <ScottL> persia, it appears that on image 20101007 no amd64 test have been completed but 2/3 i386 test have been done
[12:58] <ScottL> persia, however, i can cover all the i386 test tonight if there is a respin today
[12:59] <ScottL> persia, and if we can still get a few days to test the image i imagine we could find someone to test amd64 fully
[13:04] <persia> ScottL, Tell the release team: I can't do anything other than give warning that a package does affect an image :)  -release is probably an excellent forum.
[13:05] <soren> Litterman?
[13:07] <soren> Ah, and entirely different Scott. :) Sorry :)
[13:07] <soren> s/and/an/
[13:12] <pitti> kirkland: http://blog.dustinkirkland.com/2010/10/try-ubuntu-server-in-cloud-on-our-dime.html is a great idea!
[13:42] <kklimonda> pitti: does apport save crash in /var/crash even if package isn't genuine (and don't remove it) ?
[13:46] <pitti> kklimonda: yes
[13:46] <kklimonda> thanks
[14:14] <Riddell> mvo: wibble bug 656876
[14:14] <jibel> pitti, we are receiving lots of upgrade failures for postgresql since the latest security update.
[14:14] <jibel> pitti, the error is FATAL:  could not create shared memory segment: Invalid argument
[14:14] <jibel> pitti, do you think they are all misconfigured installations or there is something with the update
[14:14] <jibel> pitti, ?
[14:14] <pitti> jibel: it's bug 264336
[14:15] <pitti> it's been around for ages, but so far there hasn't been a satisfying solution yet, except for locally changing the size limits :(
[14:15] <ScottK> Would that be worth mentioning in a revised USN?
[14:15] <pitti> it's not specific to that update really
[14:15] <pitti> it's been around for ages
[14:15] <mvo> Riddell: looking
[14:16] <mvo> Riddell: hm, no backtrace :( ?
[14:16] <Riddell> mvo: nothing in the logs no, the DistUpgrade process is still running but the UI is frozen
[14:16] <mvo> Riddell: this is the kde frontend, right?
[14:16] <mvo> Riddell: can you type into the terminal?
[14:17] <Riddell> mvo: I can
[14:17] <Riddell> well not into the DistUpgrade terminal
[14:17] <Riddell> that window is just a grey box now
[14:18] <jibel> pitti, are you okay for a bugpattern then ?
[14:18] <pitti> jibel: that'd be great
[14:18] <jibel> pitti, great, will do, thank you
[14:19] <pitti> thanks to you!
[14:21] <mvo> Riddell: meh, ok, I try to reproduce now
[14:29] <mvo> Riddell: I get a window with the conffile prompt, do you get that as well?
[14:29] <mvo> Riddell: can you give me a ps afx output?
[14:33] <Riddell> mvo: I got the window with the conffile prompt, then when I clicked on "show more" it crashed
[14:33] <Riddell> only interesting thing in ps was the DistUpgrade process
[14:34] <Riddell> but I'm starting a new install now I'm afraid
[14:37] <mvo> Riddell: hm, hm, let me try to reproduce
[14:37] <Riddell> mvo: it was started from kpackagekit is that would change anything
[14:41] <scott-work> YokoZar, persia:  Scott.K and c.jwaston have agreed to respin ubuntu studio images for ia32lib
[14:53] <mvo> Riddell: so the empty diff can be explained by dpkg lying on its status-fd, it sends "file-old", "file-new", but "fild-old" does not actually point to the right file *sigh*
[14:53] <mvo> Riddell: I fix that now (well, workarond)
[14:54] <jcastro> hey mvo, aquarius thinks he can fix apt.ubuntu.com to work with other browsers with a little bit of javascript
[14:55] <mvo> jcastro: oh, cool
[14:56] <jcastro> ok so he can fix it, and then it's just filing an RT ticket, but of course we'd like to run it past you
[14:58] <jcastro> mvo: ok so are there any concerns you are worried about or should we Just Do It and see what you think?
[15:01] <mvo> jcastro: that is fine with me
[15:17] <mvo> Riddell: what is the thing that looks for restart required messages in kubuntu? the process name of that?
[15:18] <Riddell> mvo: it's a kded module
[15:18] <Riddell> qdbus org.kde.kded /modules/notificationhelper
[15:19] <Riddell> qdbus org.kde.kded /kded org.kde.kded.unloadModule notificationhelper   would be how to stop it
[15:19] <mvo> Riddell: will that work as root?
[15:20] <mvo> Riddell: when the upgrade starts, this needs to be unloaded
[15:20] <mvo> Riddell: or killed
[15:20] <kirkland> pitti: thanks :-)
[15:23] <Riddell> mvo: hmm no, needs to be user
[15:28] <mvo> Riddell: can you add it to your code then please? bug #650481 fyi
[15:29] <mvo> Riddell: I will reassign to kpackagekit
[15:29] <mvo> Riddell: (assuming that is the right package?)
[15:32] <Riddell> mvo: kpackagekit starts DistUpgrade, kubuntu-notifications-helper is the notifier.  You want kpackagekit to kill kubuntu-notifications-helper before starting DistUpgrade?
[15:33] <mvo> Riddell: if its kubuntu-notifications-helper then I can kill it when the upgrade starts in u-m (after the point of no-return)
[15:34] <mvo> Riddell: otherwise it needs to be done by whatever starts the upgrade
[15:34] <Riddell> mvo: kubuntu-notifications-helper is the kded module which needs the dbus bit run as user
[15:35] <mvo> Riddell: ok, so after kpackagekit started the release upgrader, it should disable that and re-enable it if the user cancels, I will add that info to the bugreport
[15:37] <Riddell> mvo: right
[15:38] <mvo> Riddell: I fixed the empty conffile prompt now, but I can reproduce the hang (yet?)
[15:39] <Riddell> mvo: can or can't?
[15:39] <mvo> Riddell: sorry, I can't
[15:39] <mvo> Riddell: but I try some more
[15:39] <Riddell> mvo: I'm trying it again too
[15:39] <mvo> I have issues with kvm in maverick unfortunately, that makes it less streamlined than it used to be (this kind of testing)
[15:40] <Riddell> mvo: what was the empty conffile prompt?
[15:40] <mvo> Riddell: dpkg did send a incorrect filename over its status fd
[15:40] <Riddell> mvo: but you think that's unrelated?
[15:40] <mvo> Riddell: yeah, I don't think its causing the crash
[15:51] <penguin42> mvo: Which particular kvm issues?
[15:52] <mvo> penguin42: when I do a test upgade from lucid->maverick on a maverick host (amd64) it hangs at some point. but only when running in gui mode, not when I run headless (vnc)
[15:53] <penguin42> mvo: Can you just explain what you mean by gui mode?
[15:55] <mvo> penguin42: when I run "kvm -m 768 lucid-desktop.qcow2" (the sdl window). when I run my automatic tests, the use -nographics and that seems to be working fine
[15:55] <penguin42> mvo: sdl on kvm on maverick is just dead as far as I can tell, there's a bug against it
[15:55] <penguin42> mvo: bug 615077
[15:55] <mvo> penguin42: thanks, that is rather unfortunate, if its a known problem at least its known
[15:56] <penguin42> mvo: Yeh it's a pain; it seems to be related toa ccess to .Xauthority but IMHO it can fail really badly and try and do framebuffer which kills X
[15:59] <mvo> penguin42: thanks, I will try to bring it into the broken state again and report a bug
[16:00] <mvo> penguin42: or add info on it at least
[16:13] <tseliot> cjwatson: is this patch for grub still relevant in maverick's grub? I'm asking as grub_memset has changed in maverick: http://pastebin.ubuntu.com/508850/
[16:14] <tseliot> cjwatson: note: I'm not asking whether it applies cleanly ;)
[16:14] <cjwatson> tseliot: it's not - a different version was applied upstream
[16:14] <tseliot> cjwatson: ah, is it already in maverick or only upstream?
[16:14] <cjwatson> the vast majority of the speed benefit was in doing wordwise writes rather than bytewise writes, and that can be done in plain C, so we did that
[16:14] <mvo> Riddell: upgrade test is running, let see how it goes
[16:14] <cjwatson> maverick too
[16:15] <tseliot> cjwatson: ah, great. Thanks
[16:15] <cjwatson> using rep stos* in assembly was a tiny additional improvement, but not worth maintaining the more delicate code - I think that's true even in OEM, it was milliseconds at most
[16:15] <cjwatson> and I think not even that with the MTRR patch on top
[16:16] <tseliot> oh, ok
[16:16] <cjwatson> tseliot: see http://lists.gnu.org/archive/html/grub-devel/2010-06/msg00128.html and thread for the history if you care
[16:18] <cjwatson> oh, and http://lists.gnu.org/archive/html/grub-devel/2010-07/msg00162.html
[16:19] <tseliot> cjwatson: thanks. BTW I've also ported your MTRR patch
[16:21] <GPenguin> hi guys. where did /etc/inittab go?
[16:22] <GPenguin> i wanted to change the default runlevel
[16:22] <Riddell> mvo: mine went fine that time but I didn't click "show more", going to try again on amd64
[16:24] <cjwatson> tseliot: *nod* that should have been a simple forward-port
[16:25] <cjwatson> GPenguin: replaced by upstart
[16:25] <GPenguin> will read up on upstart then, thanks
[16:25] <cjwatson> GPenguin: you can edit /etc/init/rc-sysinit.conf if for some reason you still care about the default runlevel
[16:25] <GPenguin> ah, nice
[16:25] <cjwatson> or put DEFAULT_RUNLEVEL=3 (or whatever) on the kernel command line, as mentioned in that file
[16:26] <cjwatson> er, sorry, just 3
[16:26] <tseliot> cjwatson: yes, that was easy
[16:26] <GPenguin> thats even nicer
[16:27] <cjwatson> tseliot: we may still integrate something like that upstream in future, but it will need to be more configurable ... it's not straightforward
[16:28] <tseliot> cjwatson: right, I read that in the mailing list
[16:44] <YokoZar> is -proposed opened?
[16:44] <cjwatson> technically, it's been open since April ;-)
[16:45] <cjwatson> you can upload to it, when it gets accepted is a different question
[16:45] <cjwatson> we probably won't start accepting until tomorrow at the earliest
[16:45] <YokoZar> ok, then I can be a bit lazy about Wine 1.2.1
[16:53] <kees> YokoZar: so, what's the deal with the ptrace fix for wine1.2? you reverted it?
[16:59] <slangasek> kklimonda: it didn't get synced
[18:19] <mvo> Riddell: when click on show diff I get the issue you described now too
[18:39] <jbarnes> I'm seeing a failure with mountall which prevents pretty much everything from starting
[18:39] <jbarnes> I have a sw raid setup, two disks striped to create /dev/md0
[18:40] <jbarnes> but they came from a previous hw raid config; I saw some bugs related to that
[18:40] <jbarnes> was just curious how to correct things
[18:42] <penguin42> jbarnes: Is that a case of kicking dmraid down?
[18:42] <jbarnes> penguin42: no it's an mdadm setup
[18:42] <jbarnes> oh it could be dmraid related, I think that's used for the so-called "hardware" raid configs?
[18:43] <penguin42> jbarnes: So why did you point out they had come from a previous hw raid config?
[18:43] <jbarnes> some of the bugs indicated that could be an issue
[18:43] <jbarnes> thanks for reminding me about dmraid
[18:43] <penguin42> no prob
[18:43] <penguin42> jbarnes: Are you the intel_ips person?
[18:43] <jbarnes> yes
[18:44] <penguin42> jbarnes: That bug apw posted the patch for where the i915 symbols aren't found and it oopses; I was wondering why the symbols weren't found
[18:44] <jbarnes> probably because i915 hadn't loaded yet
[18:44] <jbarnes> or failed to load for some reason
[18:45] <penguin42> jbarnes: Yeh so if it's a loading ordering issue then it might need a different fix; although at least one of the reporters that had the problem had an i5 or the like but with an external graphics chip which makes me wonder if the built in graphics was disabled
[18:45] <jbarnes> yeah could be
[18:45] <penguin42> one to watch out for I guess
[18:46] <jbarnes> yeah if they load out of order, you won't get gfx turbo, which would be sad
[18:46] <Sarvatt> especially on ULV parts, ugh
[18:47] <jbarnes> yeah
[18:47] <penguin42> jbarnes: Yeh hence I'm not sure that fix was the only fix needed, I don't think you can force the ordering since if they are using an extrenlal graphics chip you can't be sure it will load
[18:48] <jbarnes> yeah
[18:48] <penguin42> not sure what the right fix is though
[18:50] <jbarnes> damn no luck with dmraid
[18:51] <jbarnes> it can't find any metadata about my old raid config, so I guess that's not the issue
[18:51] <jbarnes> [root@jbarnes-vaio ~]$ service mountall start
[18:51] <jbarnes> mountall stop/waiting
[18:51] <jbarnes> that seems wrong
[18:51] <jbarnes> UUID="40e6fb47-8d67-4210-858a-64b14ca3025c"       /               ext3    errors=remount-ro 0       1
[18:51] <jbarnes> that's the only entry in /etc/fstab
[19:07] <achiang> jbarnes: maybe #linuxfs? or are you thinking this is a distro issue?
[19:08] <jbarnes> achiang: distro issue is my guess right now
[19:08] <jbarnes> mountall isn't starting
[19:09] <achiang> hasn't mountall be upstart'ified?
[19:09] <achiang> s/be/been/
[19:10] <achiang> jbarnes: what if you just say: mountall --daemon ?
[19:11] <jbarnes> achiang: nothing happens
[19:12] <achiang> jbarnes: btw, for upstart jobs, the syntax is start <jobname>, although i guess service <jobname> might still work for compat reasons
[19:12] <achiang> jbarnes: how far are you getting in boot?
[19:12] <jbarnes> system boots up to a prompt
[19:12] <jbarnes> but dbus doesn't start, no gdm, etc
[19:13] <jbarnes> and I think it's because local-filesystems is never emitted
[19:14] <jbarnes> mountall -v doesn't report errors
[19:15] <achiang> jbarnes: if you pass --debug as a kopt, upstart should write a logfile in /var/log somewhere
[19:15] <achiang> well, technically it's not a kopt, but you do pass it on the kernel command line
[19:15] <jbarnes> ok trying that
[19:16] <Chipzz> achiang: I think there never was a non-startup-ified mountall in the first place
[19:17] <Chipzz> mountall was written specifically for startup iirc
[19:25] <jbarnes> not sure if this log has anything interesting or not
[19:25] <jbarnes> init: mountall main process (396) became new process (397)^M
[19:25] <jbarnes> init: job_process_handler: Ignored event 20 (19) for process 398^M
[19:25] <jbarnes> init: job_process_handler: Ignored event 1 (0) for process 396^M
[19:25] <jbarnes> init: job_process_handler: Ignored event 40 (1) for process 397^M
[19:25] <jbarnes> init: mountall main process (397) became new process (398)^M
[19:25] <jbarnes> init: mountall state changed from spawned to post-start^M
[19:25] <jbarnes> init: mountall state changed from post-start to running^M
[19:25] <jbarnes> init: event_new: Pending started event^M
[19:25] <jbarnes> init: Handling started event^M
[19:25] <jbarnes> init: event_finished: Finished started event^M
[19:25] <jbarnes> init: job_process_handler: Ignored event 1 (0) for process 397^M
[19:26] <jbarnes> init: event_new: Pending mounted event^M
[19:26] <jbarnes> init: Handling mounted event^M
[19:26] <jbarnes> so it's emitting mount events
[19:26] <jbarnes> but I never see local-filesystems get emitted
[19:28] <micahg> !pastebin | jbarnes
[19:28] <jbarnes> sorry
[19:33] <achiang> jbarnes: but the raid actually works i guess? that is, your filesystem isn't hosed?
[19:34] <jbarnes> yeah system is working fine other than most stuff not starting up :)
[19:34] <jbarnes> I think it's a mountall problem
[19:36] <achiang> nod
[19:36] <achiang> jbarnes: i gotta run some errands, but i'll be back in an hour or so
[19:36] <jbarnes> cool
[19:40]  * jbarnes needs Keybuk, he could probably solve this in a minute
[19:44] <jcastro> hi jbarnes
[19:44] <jcastro> are you coming to uds?
[19:48] <jbarnes> jcastro: oh sorry the invite got buried in my inbox
[19:48] <jbarnes> jcastro: I'm not planning on it, I have too much travel around that time
[19:48] <jcastro> no worries
[19:48] <jcastro> maybe next time!
[19:48] <jbarnes> yeah hopefully! :)
[20:19] <YokoZar> kees: it didn't apply but it's in wine 1.2.1
[20:19] <YokoZar> kees: which I'm putting in -proposed today
[20:23] <kees> YokoZar: oh, heh. I just uploaded a backport that works, but your 1.2.1 will be even better. :)
[20:23] <kees> YokoZar: so, feel free to have them reject mine once yours is ready
[21:04] <DocMAX> can someone help me with cross compiling samba? i make a ./configure --host=arm-linux (also also tried --host=i686 --target=arm-linux)
[21:04] <DocMAX> but i still get an i686 executable
[21:18] <DocMAX> can someone help me with cross compiling samba? i make a ./configure --host=arm-linux (also also tried --host=i686 --target=arm-linux)
[22:42] <ArtArfon> Possibly important...
[22:42] <ArtArfon> http://mange.dynalias.org/linux/misc/Fedora12_GVFS_Crash_2010_10_08_Crash_GUI_Didnt_Let_Me_Type_In_Password_Twice/ccpp-1286569191-7930_GVFS_CRASH_2010_10_08/
[22:46] <ArtArfon> Pärskans! :)
[22:50] <dawning_> Sorry for the support question - how do I get everything a meta package references nuked?
[22:50] <ArtArfon> dawning_ Que?.. :)
[22:51] <dawning_> ArtArfon: I want to remove everything from ubuntu-desktop, but if I go apt-get remove ubuntu-desktop, it only removes the meta package and not all the stuff it defines
[22:52] <ArtArfon> dawning_: Ah, to remove the entire desktop. Easy enough for someone perhaps.
[22:53] <ArtArfon> dawning_: Remove its first dependency can be a qualified guess.
[22:54] <ArtArfon> dawning_: kde* :)
[22:54] <dawning_> Thanks
[22:54] <ArtArfon> np
[22:55] <ArtArfon> Walk the line - Ministry of sound... awesome! :)
[22:58] <dawning_> This solved it for me:
[22:58] <dawning_> http://www.psychocats.net/ubuntu/purekdekarmic
[23:04] <ArtArfon> Haha, catmonkies :)
[23:06] <ArtArfon> Tiger valigns
[23:10] <ArtArfon> Tiger haligns / Feisty :)
[23:26] <penguin42> removing libgtk should remove most of ubuntu-desktop - I hate to think what else it takes with it :-)
[23:27] <ArtArfon> yes, kde people really reaks.
[23:56] <ScottK> ArtArfon: If you want to be insulting, do it elsewhere.