[00:46] <jdub> cjohnston: 'oom never' no longer needed in maverick's /etc/init/ssh.conf ?
[00:47] <jdub> cjwatson: 'oom never' no longer needed in maverick's /etc/init/ssh.conf ?
[00:47] <jdub> sorry cjohnston :-)
[00:50] <lifeless> jdub: zomg, you still know how to irc:)
[01:44] <Lrrr> anyone here got LXC to work with libvirt properly?
[02:47] <Redache> '8
[03:33] <jono> hey all
[03:33] <jono> I am thinking of upgrading to Maverick, how stable is it right now?
[03:35] <ion> I still have to run the Lucid kernel for fglrx and vuze stopped working since a Gtk change (apparently related to RGBA), but i haven’t had problems other than that. :-Pppppp
[03:35] <jono> cool
[03:35] <ion> :-P even. (The keyboard battery is dying.)
[03:35] <jono> thanks!
[03:37] <ion> Basically, i’m imposing problems on myself by running proprietary crap and Java crap. ;-)
[03:37]  * ajmitch hasn't had anything die horribly in a VM since upgrading this morning, fwiw
[03:38] <RAOF> jono: Maverick's tracking pretty nicely here.
[03:38] <jono> awesome, thanks RAOF
[03:38] <jono> kicking off the upgrade now :)
[03:41] <psusi> I can't wait for the new lvm2 to get packaged and hit maverick... support for snapshot merging, so you can make a snapshot, update, and if things break, revert by merging the snapshot back into the origin
[03:47] <ion> psusi: I take it user data that must not be reverted along has to reside on a separate partition?
[03:47] <ion> I guess it would be the filesystem’s job to provide partial snapshots and reverting.
[03:47] <ion> btrfs? :-)
[03:51] <psusi> ion, yes, obviously a revert is for everything on the fs, but should not be a problem if you are just testing an upgrade to make sure it still boots and a few cursory checks of applications that still work before you decide to delete the snapshot or revert to it
[05:32] <freeaks> hi there,
[05:32] <freeaks> i'm trying to follow this tutorial:
[05:32] <freeaks> http://www.wedevblog.com/gnome-panel-applet-part-1.html
[05:32] <freeaks> to learn making a gnome panel applet
[05:33] <freeaks> i have install build-essential package as well was libpanel-applet2-dev
[05:33] <freeaks> but when i try to compile i get this error:
[05:33] <freeaks> error: panel-applet.h: No such file or directory
[05:33] <freeaks> error: gtk/gtklabel.h: No such file or directory
[05:34] <freeaks> ..
[05:34] <freeaks> ?
[05:34] <freeaks> it seems as if my gnome source, headers aren't found ?
[05:35] <freeaks>  i can see /usr/include/panel-2.0/panel-applet.h
[05:35] <freeaks> the file is here
[05:36] <freeaks> but somehow i can't seem to be able to compile
[05:36] <freeaks> what could i do ?
[05:38] <freeaks> i'm using this: g++ $(pkg-config –cflags –libs libpanelapplet-2.0) -o helloworld example-applet.c
[05:42] <ScottK> freeaks: This is development of Ubuntu here, not on Ubuntu.  IIRC there is #ubuntu-app-devel or something similar.
[05:44] <freeaks> ScottK, ok, thanks
[08:19] <pitti> Good morning
[08:26] <dholbach> good morning
[09:55] <tseliot> cjwatson: can you approve nvidia in lucid-proposed now that it was been tested in maverick, please? (LP: #580763)
[09:55] <tseliot> s/was/has/
[10:07] <cjwatson> tseliot: done
[10:13] <seb128> cjwatson, hi, I know you are busy but do you think you could review the gnome-keyring rhythmbox brasero srus today?
[10:13] <seb128> they should be pretty easy to review
[10:14] <seb128> the brasero update fixes audio cd recording not working
[10:18] <cjwatson> seb128: didn't I already review rhythmbox?  it isn't in the queue
[10:18] <cjwatson> seb128: I'll look at the others now
[10:20] <seb128> cjwatson, you didn't comment on bug #569380 if you accepted rhythmbox
[10:20] <seb128> cjwatson, thanks
[10:24] <tseliot> cjwatson: thanks a lot
[10:25] <cjwatson> seb128: odd.  running sru-accept on it now
[10:25] <seb128> cjwatson, thanks
[10:30] <cjwatson> seb128: the CLEANFILES target in gnome-keyring/daemon/Makefile.in looks wrong
[10:30] <cjwatson> seb128: shouldn't it be org.freedesktop.secrets.service rather than org.freedesktop.service?
[10:30] <cjwatson> seb128: (not critical for SRU, it'll just mean the package doesn't clean correctly)
[10:31] <cjwatson> looks like it was a bug in the patch submitted upstream
[10:32] <seb128> cjwatson, oh, right, I will follow up upstream about it
[10:32] <cjwatson> thanks
[10:33] <seb128> cjwatson, thank you for spotting it
[10:34] <cjwatson> I find GNOME package versions very hard to tell apart visually, somehow :-)
[10:34] <cjwatson> it usually takes me a couple of goes to spot the difference between 2.30.0-0ubuntu1 and 2.30.1-0ubuntu1
[10:34] <mpt> ev, http://pastebin.ubuntu.com/440300/
[10:34] <mpt> Oh bother, that's not quite right
[10:35] <mpt> Delete "With a USB key or SD card," -- that's left over from when I was thinking you could write to CDs
[10:36] <mpt> And when that bit is deleted, the repetition of "also" grates a little more, but you get the idea
[10:39] <cjwatson> seb128: ok, done now
[10:40] <seb128> cjwatson, thanks!
[10:45]  * hyperair wonders why he keeps getting ssl errors for *.debian.org addresses
[10:57] <hrw> cjwatson: is it possible to use variables in *.install files?
[10:59] <pitti> hrw: see man dh_install; it's not
[11:00] <pitti> hrw: if you want to do something dynamic, you need to install files in debian/rules
[11:01] <hrw> thx
[11:16] <cjwatson> hrw: remember that it's perfectly possible to generate the .install file before running dh_install
[11:17] <cjwatson> hrw: see the groff source package for an example
[11:18] <hrw> cjwatson: I see
[11:35] <ogra> Keybuk, http://paste.ubuntu.com/440283/ amitk tries to boot nfsroot without initramfs, do you have any idea why all tmpfs mounts seem to fail here ?
[11:35] <ogra> parse_filesystems seems to find tmpfs properly
[11:36] <ogra> (and according to amit devtmpfs support is compiled in but it desnt seem to be found by parse_filesystems)
[11:37] <amitk> ogra: Keybuk: bug 586275 filed against mountall until I know more
[11:37] <amitk> it has kernel config and the boot logs
[11:38] <ogra> amitk, err
[11:38] <ogra> # CONFIG_TMPFS is not set
[11:38] <ogra> why the heck does it show up in /proc/filesystems though
[11:39] <amitk> hmm
[11:39]  * ogra doesnt get that, do you have /proc from the server mounted in the root ? 
[11:39] <ogra> though that would probably also find devtmpfs
[11:40] <amitk> ogra: \o/ you rock
[11:40] <ogra> heh
[11:40] <hrw> ;d
[11:41] <dmart> asac, ogra: hi, do you know a good person to ask about X input device issues?
[11:42] <ogra> dmart, tseliot
[11:42] <ogra> he's our Xinput god :)
[11:42] <tseliot> what's up?
[11:42] <tseliot> heh
[11:42] <dmart> hi there
[11:42] <tseliot> hi
[11:42] <dmart> I have a weird ARM platform configuration with a rather old kernel
[11:43] <dmart> most stuff works, but there are some udev problems, and X does not detect input devices properly
[11:43] <dmart> Could you take a look at a log?
[11:44] <tseliot> sure but can you also tell me what kind of input devices you're talking about? Mice?
[11:44] <dmart> keyboard and mouse in this case, over USB
[11:44] <tseliot> ok, don't they work at all?
[11:45] <dmart> They don't appear to.  I do have /dev/input/{mice,input*}, and catting them produces data when I type / wiggle
[11:45] <tseliot> ok, I'll need a dmesg and a /var/log/Xorg.0.log
[11:45] <tseliot> ah
[11:48] <hrw> dmart: use evtest for testing input devices rather then cat
[11:48] <dmart> hrw: cool, I will try that
[11:48] <dmart> (cat is a bit primitive ;)
[11:48] <hrw> ;)
[11:49] <hrw> evtest is kind of xev for terminal
[11:49] <dmart> hrw: ah, right
[11:51] <dmart> tseliot: http://pastebin.ubuntu.com/440337/
[11:51] <dmart> This the contents of /dev and the Xorg log
[11:52] <dmart> Unfortunately I don't have the platform running right now, but I can get dmesg output later if you need.
[11:52] <tseliot> ok
[11:53] <dmart> What's weird is that X detects stuff, be then doesn't use the evdev driver:
[11:53] <dmart> config/udev: Adding input device USB keyboard (/dev/event1)
[11:53] <dmart> (II) No input driver/identifier specified (ignoring)
[11:53] <dmart> But the driver is definitely in the fs ...
[11:55]  * ogra wonders if your kernel has CONFIG_INPUT_EVDEV set
[11:56] <dmart> ogra: I thought of that, but it's definitely supported
[11:56] <tseliot> can you also try to get a backtrace, please?
[11:56] <dmart> You don't get /dev/input/event* otherwise
[11:56] <ogra> also it seems strage that xorg picks /dev/event1 instead of /dev/input/event1
[11:57] <tseliot> good point
[11:57] <dmart> tseliot: I can try--- note that server reset or shutdown always segfaults on ARM right now.  I don't think we're seeing any other crash here--- X runs until it is shut down
[11:58] <tseliot> dmart: ah, ok
[11:58] <dmart> ogra: good spot... I move the input devices into /dev/input because udev is confused by the old kernel and puts them straight in /dev, maybe I shouldn't
[11:58] <ogra> not sure
[11:58] <tseliot> what kernel is that?
[11:58] <dmart> I still get similar X input problems even if the device nodes aren't moved... but I could try and get a log
[11:59] <dmart> 2.6.29 unfortunately... and hard to upgrade in this case
[11:59] <ogra> how about usbfs and friends ?
[11:59] <ogra> iirc we stopped supporting the old style usbfs a while ago
[11:59] <dmart> dunno... do you mean something that ought to be mounted is not?
[11:59] <ogra> no, a missing kernel option rather
[11:59] <dmart> Note that I have lucid Xorg working even on 2.6.26
[12:00] <ogra> iirc i had probs when some deprecated USB options were set in a test kernel i built recently
[12:00]  * ogra cant remmeber which though and the kernel is fixed now
[12:00] <dmart> hmmm... might be worth a check
[12:01] <dmart> tseliot, ogra: well, I think I have some next things to try now... I'll come back when I know more
[12:01] <ogra> and iirc udev has issues with CONFIG_SYSFS_DEPRECATED_V2
[12:01] <ogra> not sure that affects the input layer though
[12:02] <dmart> ogra: oh yes :)  But Xorg still works!  (I'm as surprised by this as anyone...)
[12:03] <tseliot> dmart: if udev catches the device and applies the settings for the mouse you should get something like:
[12:03] <tseliot> (II) config/udev: Adding input device Razer Razer Salmosa (/dev/input/event4)
[12:03] <tseliot> (**) Razer Razer Salmosa: Applying InputClass "evdev pointer catchall"
[12:04] <dmart> tseliot: yup, I see this on other, more normal platforms
[12:04] <tseliot> maybe dmesg will show something interesting
[12:04] <dmart> I'll take a look
[12:04] <dmart> thanks
[12:04] <tseliot> np
[12:50] <apachelogger> jdong: hey, it would be very nice if you could take a quick look at bug 583735 regarding sru :)
[13:29] <zul> StevenK: ping
[13:29] <StevenK> zul: contentless pong
[13:30] <zul> StevenK: sorry...debian renamed the source package for mysql-dfsg-5.1 with mysql-5.1 can we replace the mysql-dfsg-5.1 that is in main right now with mysql-5.1 which I uploaded yesterday?
[13:31] <StevenK> pitti: ^
[13:31] <StevenK> pitti: I just want an ok, I'm happy to fiddle it
[13:31] <hrw> cjwatson: is there a script which will generate *.install from packages contents maybe? :D
[13:31] <pitti> StevenK: sure, seems obvious
[13:33] <zul> StevenK: thank
[13:33] <lool> hrw: Hmm you dont actually want to do that
[13:34] <lool> hrw: You want to use the current logic in rules, not the contents of the packages
[13:34] <StevenK> zul: I should demote, or remove mysql-dfsg-5.1?
[13:34] <zul> remove mysql-dfsg-5.1
[13:34] <lool> hrw: BTW I had a call with doko to go over his input on the spec, I'll update the spec to clarify
[13:34] <hrw> thx
[14:35] <skeledrew>  hello. is there any detailed specifications on how Wubi and Lupin works/what EXACTLY they do? also, how can i go about getting the code in http://bazaar.launchpad.net/~ubuntu-installer/wubi/trunk/files and http://bazaar.launchpad.net/~ubuntu-installer/lupin/hardy/files ? my web spider isn't exactly cooperating.
[15:03] <free> mvo: hi! I noticed that lucid is not yet listed in http://changelogs.ubuntu.com/meta-release-lts, I guess that's on purpose right?
[15:12] <smoser> anyone seen something like this before: http://ubuntu-server-new-bugs.notlong.com
[15:12] <smoser> i'm triaging server bugs, there are 8 or so (awstats and munin) SIGSEGV bugs in perl on karmic
[15:14] <mvo> free: yeah, that is on purpose, the plan is to enable it by default for 10.04.1
[15:14] <free> mvo: cool then
[15:14] <mvo> thanks
[15:15] <cjwatson> skeledrew: detailed spec> probably not to the exactitude you're looking for if you're trying to implement an equivalent for another OS (this is a guess but you're about the fourth person to ask that kind of thing, so ...).  Use bzr to check out the source.
[15:20] <skeledrew> cjwatson: yes. i'd like to make it more generic to install other downline Ubuntu distros, such as peppermintos that don't have it.
[15:35] <ogra> tedg, heya, i added a workitem for you on https://blueprints.launchpad.net/ubuntu/+spec/mobile-m-lightweight-panel-for-efl
[15:37] <tedg> ogra, Cool, thanks!
[15:43] <Drakeson> I am a bit confused with the version number of a package: libdbus-1-3 has version 1.2.16-2ubuntu4.  Does it mean it is dbus 1.3 or not?
[15:44] <Keybuk> no
[15:44] <Keybuk> it means it contains libdbus-1.0.so.3
[15:44] <Drakeson> *sigh*, thanks
[15:44] <Keybuk> library versioning is not orthogonal to package versioning
[15:45] <Keybuk> libdbus-1.0.so.3 is the *current* library version of dbus, as shipped in, e.g. 1.2.16
[15:45] <Drakeson> I see. thanks :)
[15:46] <Drakeson> btw, is dbus 1.3 on the roadmap for maverick?
[15:46] <Ian_Corne> am I right to say -number indicates the version in the distribution, not of the actuall thing, and .number is for the real version?
[15:47] <Ian_Corne>   Candidate: 1.2.16-2ubuntu4
[15:48] <cjwatson> upstreamversion-packagingrevision
[15:48] <cjwatson> so that means "upstream version 1.2.16, Debian revision 2, Ubuntu revision 4"
[15:51] <ogra> pitti, did the cronjob for the WI tracker stop working ?
[15:51] <pitti> ogra: no, it crashed since someone broke maverick.cfg
[15:51] <pitti> (and didn't commit it either)
[15:51] <ogra> ouch
[15:52] <pitti> I just fixed the syntax
[15:53] <ogra> pitti, while you're at it, can you replace asac with me for mobile ?
[15:55] <pitti> ogra: that's already done in maverick.cfg
[15:55] <ogra> oh, then i seem to look at the wrong branch
[15:56]  * ogra is looking at trunk
[15:56] <pitti> ogra: right, as I said, someone edited it on lillypilly without committing
[15:56] <ogra> ah
[15:56] <pitti> JFo, asac: someone added https://wiki.ubuntu.com/UbuntuARMTeam/ReleaseStatus/MaverickTasks?action=raw to maverick.cfg; should't that rather get into ubuntu-arm.cfg?
[15:57] <pitti> it looks weird to distribute the ubuntu-arm WIs like that, but your call of course
[15:57] <JFo> good question pitti
[15:59] <JFo> pitti, I am asking amitk about it now
[16:01] <ogra> pitti, i think someone == JamieBennett
[16:01] <ogra> amitk just summons him :)
[16:01] <pitti> oh, did I pick the wrong Jamie? sorry
[16:02] <amitk> pitti meet JamieBennett
[16:02] <JamieBennett> amitk: pitti: heh
[16:02] <JamieBennett> whats up
[16:03] <blue_anna> in man 2 mkdir it says that it is made to conform to Posix.1-2001 -- but there is no Posix.1-2001 .. the last POSIX.1 standard was 1995
[16:03] <blue_anna> what standard are they actually following?
[16:03] <amitk> JamieBennett: 17:57 < pitti> JFo, asac: someone added https://wiki.ubuntu.com/UbuntuARMTeam/ReleaseStatus/MaverickTasks?action=raw to maverick.cfg; should't that rather get into ubuntu-arm.cfg?
[16:04] <JamieBennett> amitk: I contemplated that but as all spec's moved into the ubuntu project I added to the maverick.cfg file
[16:04] <JamieBennett> oh and pitti it seems it hasn't been run since 13:12 or so
[16:05] <blue_anna> because mkdir is returning before the directory is actually made
[16:06] <ogra> JamieBennett, yes, it crashed
[16:06] <JamieBennett> there maybe a call to keep it as ubuntu-arm, I would like to see it that way but as the blueprints are now under ubuntu its a grey area
[16:08] <pitti> JamieBennett: right, there was a syntax damage in maverick.cfg, just fixed
[16:08] <pitti> JamieBennett: well, whichever way works better for you, it was just a question
[16:08] <dholbach> mdeslaur will give a Packaging Training session about "Preparing Security Updates" in #ubuntu-classroom at 18:00 UTC
[16:10] <JamieBennett> pitti: ideally under ubuntu-arm I think. As that wasn't being generated at the time I thought I would tag it into the maverick.cfg to see if it was getting generated there, both weren't for the reason you said. I'll remove it from the maverick.cfg file then and if you could take a look at ubuntu-arm.cfg to make sure I got it right that would be great.
[16:13] <pitti> JamieBennett: sure, ping me once you moved it
[16:15] <JamieBennett> pitti: done
[16:22] <pitti> JamieBennett: looks fine
[16:22] <JamieBennett> pitti: great, thanks
[16:23] <pitti> let's wait how the next cycle will look like
[16:30] <mdz> dholbach, what's the shortcut you use to do this: [[LaunchpadHome:dholbach]] <<DateTime(2010-05-27T16:27:29+0100)>>
[16:32] <dholbach> mdz: @SIG@
[16:32] <mdz> dholbach, thanks
[16:33] <dholbach> anytime
[16:42] <hrw> dpkg-deb: warning: 'debian/gcc-4.4-source/DEBIAN/control' contains user-defined field 'Original-Maintainer'
[16:42] <hrw> I wonder why Ubuntu did not patched that out
[16:46] <cjwatson> hrw: I've been trying desperately to reduce the number of patches we're carrying against dpkg, so I don't want to add patches for things that are essentially cosmetic
[16:46] <hrw> just was curious
[16:47] <hrw> doko, cjwatson: can you look at http://hrw.pastebin.com/4qb2McVD and tell is it good way?
[16:47] <hrw> I have cpp-4.4.install and cpp-4.4.links files
[16:48] <cjwatson> I'll leave that to doko
[16:48] <cjwatson> er, well, I wouldn't use sed -i if I were you - have .install.in and .links.in files instead
[16:48] <cjwatson> since otherwise it isn't going to work the second time
[16:48] <hrw> cjwatson: ok, like in groff
[16:49] <cjwatson> (and keeping backup files and restoring them is annoying and fragile)
[16:49] <hrw> right
[16:50] <JamieBennett> pitti: still no generation of the work items, how often does it get done?
[16:54] <pitti> JamieBennett: 5 past the hour for ubuntu, 25 past the hour for arm
[16:54] <pitti> ah, it crashed again
[16:55] <pitti> KeyError: 'arm-ubuntu'
[16:55] <doko> hrw: what do you want to achieve? in general, I think .install files are a bad idea for gcc. what do you want to fix/improve?
[16:56] <pitti> JamieBennett: there is no https://launchpad.net/~arm-ubuntu, as stated in ubuntu-arm.cfg
[16:58] <pitti> JamieBennett: the other three seem fine, so I just comment out arm-ubuntu for now
[16:58]  * pitti re-runs
[17:04] <hrw> doko: first wanted to get rid of dh_movefiles, now it is gaining debhelper packaging skills. I think that I will postpone it until there will be a time/realneed for it.
[17:04] <doko> hrw: honestly, there are more pressing things than "gcc gaining debhelper packaging skills"
[17:05] <hrw> sure
[17:05] <hrw> doko: and I learnt more about debian way to build toolchain
[17:05] <doko> ok
[17:12] <jono> seb128, are you aware of an issue in Evo in Maverick with the cursor not visible when composing a mail?
[17:12] <seb128> jono, no
[17:12] <jono> ok, will look into filing a bug
[17:12] <seb128> jono, but I'm not using maverick yet ;-) I didn't read bugs about it though
[17:13] <jono> seb128, slacker
[17:13] <jono> :P
[17:13] <jono> I have never been able to say that about seb128 before
[17:13] <Drakeson> while you're discussing evolution, is the icon for junk-email (or was it not-junk-email) added to the default icon-theme, yet? the toolbars tend to get huge otherwise.
[17:13] <jono> seemed like a good opportunity
[17:13] <jono> :)
[17:13] <seb128> jono, lol, not you slacker, I need to get work done, you might have the leasure to spend your week fixing your computer, I don't ;-)
[17:13] <jono> Drakeson, that is fixed upstream I believe
[17:13]  * seb128 runs
[17:13] <pitti> JamieBennett: went through, see http://people.canonical.com/~pitti/workitems/ubuntu-arm/ ; now with per-team reports \o/
[17:13] <jono> seb128, haha
[17:14] <jono> seb128, ok, I will file a bug :)
[17:14] <seb128> thanks
[17:14] <seb128> I will try in my mini
[17:14] <ccheney> shtylman: i synced master and 3-2-1
[17:14] <seb128> I run maverick there for now
[17:14] <ccheney> shtylman: haven't done a build yet so it might have bugs
[17:14] <seb128> I'm still trying to get some lucid sru dones before switching my laptop
[17:15] <shtylman> ccheney: cool
[17:15] <ccheney> shtylman: i got it ready before the rc3 ooo-build release tomorrow :)
[17:16] <shtylman> rc3 of 3-2-1 ?
[17:20] <ccheney> shtylman: yea
[17:27] <tkamppeter> pitti, hi
[17:31] <pitti> hello tkamppeter
[17:33] <ccheney> grr is there a way to make gtg to make something not a subtask, i accidently converted something to one
[17:36] <ogra> pitti, any idea why i still have two specs from the arm team on http://people.canonical.com/~pitti/workitems/maverick/canonical-mobile.html ?
[17:36] <tkamppeter> pitti, I have done a small change on the CUPS startup script for bug 369850. I let it also load the parport_pc module in addition to lp and ppdev. This is a nice minimum-invasive solution for a Lucid SRU.
[17:38] <pitti> tkamppeter: that sounds wrong, though; parport-pc has proper modaliases
[17:38] <tkamppeter> pitti, the SRU should also contain the fixes for bug 468701 (newline in device ID breaks CUPS) and bug #578181 (white rectangles yellow in printout).
[17:38] <pitti> it should be autoloaded
[17:39] <pitti> tkamppeter: aren't the other two already in -proposed?
[17:39] <pitti> yes, they are
[17:40] <tkamppeter> pitti, OK, then next SRU should contain the parport_pc load and also
[17:40] <tkamppeter> pitti, something that assures that CUPS gets loaded on boot
[17:40] <pitti> tkamppeter: we'd load that module on every platform, which would just be a waste for 99% of people out there, though
[17:48] <tkamppeter> pitti, and in the CUPS init script we should add something which restarts Samba if Samba is already running as in Lucid we have the perfect race condition, Samba started by native Upstart and CUPS by System V scripts.
[17:48] <tkamppeter> pitti, for Maverick we should move to an Upstart job for CUPS.
[17:49] <pitti> agreed for maverick
[17:49] <pitti> but it seems for lucid we should rather fix samba's upstart job instead of restarting it
[17:51] <tkamppeter> pitti, what is your fix suggestion? Should the upstart job simply get a loop added which waits until the CUPS daemon is up and running (check with "lpstat -r")? Or should the Samba Upstart job start CUPS if it is not yet running and only after that start Samba?
[17:51] <pitti> nonono
[17:51] <pitti> samba should just wait on cups
[17:52] <pitti> I suggest to discuss that with Keybuk, he asked to get consulted for upstart job fixes
[17:52] <pitti> tkamppeter: cups' init script could emit a "cups-started" event which samba can wait for; it just needs to handle the case when cups is not started or installed at all
[17:54] <tkamppeter> pitti, here the Samba upstart script would need to check somehow whether CUPS is installed and configured for being started on boot.
[17:55] <pitti> right, that's the bit which should be discussed with Keybuk; I do not have enough experience with upstart scripts for a tricky thing like that, I'm afraid
[17:57] <tkamppeter> pitti, but the biggest problem to be SRUed is that CUPS need to start reliably on boot for every user, bug 554172.
[17:59] <pitti> tkamppeter: do these people get anythign else started in /etc/rc2.d/? such as kerneloops, rsync, binfmt-support, postgresql, etc.?
[17:59] <pitti> I don't quite believe that this is a cups specific problem
[18:01] <pitti> ogra: because pwlars is in ~canonical-mobile, I presume?
[18:02] <ogra> pitti, he isnt anymore since 11UTC
[18:02] <ogra> i cleaned that up after he showed up
[18:02] <ogra> s/he/his specs/
[18:02] <ogra> so i would expect them to vanish again
[18:04] <pitti> ogra: ah, the membership is updated daily only, midnight
[18:05] <pitti> so should be good tomorrow
[18:05] <ogra> pitti, ah, thanks ... sorry to waste your time then
[18:05] <pitti> np :)
[18:05]  * pitti -> dinner
[18:05] <SpamapS> Question: I'm working on merging the 'moin' package, which has a delta because the debian verison is dependent on some stuff in universe but moin itself is in main... should we just keep maintaining this delta or try to MIR the packages? They were removed because the dependency was added really close to LTS release.
[18:06] <tkamppeter> pitti, for me it also looks like an upstart problem, I have already tried to move the bug to upstart, but it got promptly moved back to cups, by slangasek.
[18:08] <zul> SpamapS: MIR
[18:08] <tkamppeter> pitti, in bug 524186, comment #2, a simple approach of native upstart support for CUPS is tested, but only run-level based, so only half-native upstart. This approach still leaves many users without CUPS as under upstart their runlevel stays "unknown".
[18:09] <tkamppeter> pitti, this would mean that for that users all legacy System V scripts would not start.
[18:09] <pitti> right, what I suspected; there might be a problem with a broken lo device, or whatnot
[18:10] <SpamapS> zul: I believe, sir, that I will owe you an entire case of Gambrinus 12° by the time we get to Prague
[18:10] <zul> SpamapS: sooner preferably ;)
[18:11] <tkamppeter> pitti, legacy System V support is started on the "filesystem" event (successfully concluded "mountall") AND on "lo" being up and running.
[18:11] <tkamppeter> pitti, so it can also be a mountall problem.
[18:12] <slangasek> tkamppeter: I reassigned it back to cups because there was zero evidence in that bug report that upstart was failing to run the init scripts, and the original submitter said the problem was fixed for him by reinstalling the cups packages - which has nothing to do with upstart
[18:13] <tkamppeter> slangasek, pitti, later on other posters told that reinstall of CUPS only helped once and later boots failed and also other legacy System V scripts and not only CUPS did not start.
[18:16] <tkamppeter> slangasek, the real fix would be to move all services to native upstart, but this is too invasive for a Lucid SRU. And in addition, legacy System V support needs to work reliably in upstart, to support third-party packages containing services. AFAIK the LSB requires System V init script support.
[18:16] <tkamppeter> pitti ^^
[18:16] <slangasek> tkamppeter: then that poster may have a different bug, probably a broken configuration; I don't think that's sufficient to treat the whole bug as an "upstart problem".
[18:17] <slangasek> this needs debugged as a cups bug first instead of jumping to the conclusion that upstart is broken
[18:17] <slangasek> because upstart *does* run the sysvinit scripts reliably, unless something else is broken on the system
[18:19] <tkamppeter> slangasek, pitti, we have again an example of the big problem of all bug tracking systems: Users post into the same bug if they have the same symptoms but different bugs (happens very often on the printing side). One should have the possibility to move single comments and attachments from one bug to another (like one can do in web forum systems).
[18:19] <slangasek> tkamppeter: "especially as users have the same problem with other services than CUPS" -- what users where?  I don't see any mention of problems with other init scripts
[18:19] <slangasek> oh, https://bugs.launchpad.net/ubuntu/+source/cups/+bug/554172/comments/41 mentions vboxdrv, ok
[18:19] <slangasek> but again, no evidence that his bug is the same as the others
[18:20] <tkamppeter> slangasek, pitti: You mentioned it already, comment #41.
[18:22] <tkamppeter> slangasek, pitti, is there any debug logging facility in upstart, so that users can get a log showing what upstart is actually doing?
[18:25] <slangasek> tkamppeter: boot with --verbose, post /var/log/boot.log: https://help.ubuntu.com/community/UpstartHowto
[18:25] <tkamppeter> slangasek, pitti, comment #47 has a list attached with all services which do not get started on a boot where CUPS did not get started.
[18:30] <slangasek> tkamppeter: attached as an OpenOffice document.  Perhaps you would like to convert that into a usable format?
[18:39] <nemo> is there a libtalloc2-dbg somewhere?
[18:39] <tkamppeter> slangasek, for me it opens on a double-click, OOo is part of the standard desktop installation ...
[18:40] <slangasek> tkamppeter: I'm not going to visually inspect some ridiculous OpenOffice spreadsheet to extract the equivalent of a text diff
[18:40] <slangasek> tkamppeter: if you want to convert that into text files for me, I'll be happy to review it
[18:41] <slangasek> but it's probably better to get the poster to just send us the text output in the first place
[18:41] <slangasek> instead of working from something that's been manually munged twice
[18:43] <tkamppeter> slangasek, so I will ask him to post the information inline into the bug report, so that the reader does not need anything but his browser.
[18:44] <nemo> getting help elsewhere finding 'em. thanks anyway
[18:46] <slangasek> tkamppeter: no, not inline, text attachments.  I need something I can sensibly *diff*
[18:50] <tkamppeter> slangasek, sorry, will do a second approach of instructions ...
[18:56] <tkamppeter> slangasek, I asked him now to reboot repeatedly, to see how much relationships between CUPS not starting and other services not starting depend on each other.
[19:01] <james_w> SpamapS: I think there is already an MIR in progress for that package. If I could remember the name then I would grab the bug number for you.
[19:01] <tkamppeter> slangasek, to which command line do I have to add --verbose? to the kernel command line or to the initrd command line?
[19:02] <james_w> SpamapS: found it, bug 566537
[19:02] <tkamppeter> slangasek, I have found it, kernel command line.
[19:09] <tkamppeter> slangasek, thanks for the instructions on how to get Upstart into verbose logging mode. I have added the instructions to the bug report.
[19:17] <jono_> pitti, any chance you could re-gen http://people.canonical.com/~pitti/workitems/maverick/canonical-community.html so that the trend now starts at the top?
[19:25] <slangasek> tkamppeter: sure thing - I'm sorry that we haven't done a better job up to now of publicizing the upstart troubleshooting information
[19:27] <jdong> apachelogger: looking now
[19:27] <apachelogger> jdong: super, thanks :)
[19:28] <jdong> apachelogger: hehe interesting "fix" :)
[19:28] <tkamppeter> slangasek, pitti, someone should create a page like https://wiki.ubuntu.com/DebuggingPrintingProblems for Upstart.
[19:28] <jdong> apachelogger: ACKed, now just hope nobody tries starting KDE over NFS on dial-up ;-)
[19:29] <apachelogger> lol
[20:02] <SpamapS> james_w: right, sorry just saw your help finding that MIR.. yes..libapache2-mod-wsge was one of the 4 that need to happen for moin to drop most of its delta.
[20:02] <SpamapS> james_w: which brings me to my next question..
[20:02] <james_w> SpamapS: ah, sorry, I didn't realise there was more than one
[20:02] <SpamapS> at some point python-xml was even dropped from universe for some reason.. but it is still in debian..
[20:04] <SpamapS> anyway, python-xml is suggested by the debian package.. but removed from the ubuntu package .. which at this point will be the final bit of delta we have to maintain.. if we found it worthwhile to drop python-xml .. could we also push for debian to drop it? Really I'm trying to find the rationale for dropping/blocking python-xml
[20:10] <james_w> SpamapS: it has been dead and deprecated for years, with people advised to use what is in the standard library now, or one of the other libraries if that doesn't cut it. For a "Suggests" there is no reason to diverge from Debian, as it has no real effect.
[20:10] <SpamapS> ahh.. google has provided .. wow.. contentious
[20:10] <SpamapS> https://bugs.launchpad.net/ubuntu/+source/python-xml/+bug/343242
[20:11] <james_w> yeah
[20:11] <SpamapS> james_w: so a package in main is allowed to suggest a non-existant package?
[20:12] <james_w> SpamapS: yes
[20:12] <james_w> SpamapS: because it doesn't break anything. It's obviously not very elegant, but is used from time to time to suggest non-free packages and the like.
[20:13] <james_w> plus there are cases like this where because there is no effect it's not worth diverging from Debian over it
[20:13] <SpamapS> Well sweet
[20:14] <SpamapS> I believe that means that once the 4 MIR's are approved and completed, we can just request that moin be synced. +1 for reduce (Al Gore would be proud)
[20:16] <SpamapS> "…it looks like you were trying to look for `python-xml' binary package. The Package Tracking System is source based, therefore you should have looked for `python-xml'"
[20:16] <SpamapS> brilliant
[20:18] <lifeless> nice
[20:20] <SpamapS> damn one more MIR, fckeditor
[20:20] <SpamapS> great package name
[20:22] <soren> SpamapS: What for? Moin?
[20:24] <SpamapS> soren: yeah... its recommended in the debian package
[20:24] <SpamapS> and actually
[20:25] <SpamapS> wow it has a horrendous security record doesn't it?
[20:25] <soren> SpamapS: Hm. We could just drop back to a Suggests.
[20:25] <soren> Unless of course something changed in moin that makes that troublesome somehow.
[20:25] <SpamapS> soren: indeed, I think its probably worth maintaining that as a change.
[20:25] <SpamapS> soren: no fckeditor is disabled by default
[20:25] <SpamapS> its fine
[20:27] <SpamapS> yeah I think we'll maintain that delta.. fckeditor looks like just the sort of thing we want to keep out of main
[20:27] <soren> SpamapS: I don't even see the changelog entry where it's bumped to Recommends.
[20:30] <SpamapS> soren: we've bumped it from recommends to suggests in ubuntu.. but its still recommended in debian.
[20:30] <leini> hi you
[20:30] <soren> SpamapS: Oh, we've done that all along?
[20:31] <leini> done what where?
[20:31] <soren> SpamapS: I thought Debian had bumped it from Suggests to Recommends recently since you were looking at doing an MIR.
[20:32] <SpamapS> soren: no I was looking at doing a MIR because its the only change left to avoid just syncing w/ debian
[20:33] <soren> SpamapS: Oh, I see.
[20:34] <SpamapS> soren: but really, I think its worth it.. and it should merge easily with just that one change in rules
[20:34] <soren> SpamapS: Certainly.
[21:01] <teurastaja> i have a permanent graphics address remapping table bug with possible asic involvement
[21:02] <teurastaja> neither #ubuntu nor #ubuntu-bugs can help
[21:03] <teurastaja>  the kernel tries to force the gart to 32M just after chainloading
[21:04] <teurastaja> it freezes for a very long time and if i reboot no sidebar interaction with running programs is possible
[21:06] <teurastaja> it says "[17.983732] [drm:rs400_gart_adjust_size] *ERROR* Forcing to 32M GART size (because of ASIC bug?)"
[21:08] <teurastaja> can i fix this?
[21:09] <teurastaja> if i try to minimize windows i lose them
[21:09] <teurastaja> i have KDE
[22:14] <andersk> Can I get someone to upload my bash-completion debdiff for bug 546794?  The current bash-completion spews bash syntax errors every time you start a shell (apparently nobody tested that patch at all?).