[00:54] <rgreening> dtchen: hey
[00:54] <dtchen> rgreening: hi.
[00:55] <rgreening> I should be soon done with my current project. I can help with pulse/gstreamer then.. dtchen
[00:55] <dtchen> rgreening: great
[00:55] <rgreening> np.
[00:55] <rgreening> hopefuly by end of this week.
[02:26] <Vantrax> anyone here good with pulling information out of gnome?
[02:26] <Vantrax> im trying to work out how to pull the value for the gnome power manager idle timer via dbus-send. It should look something like dbus-send --session --dest=org.gnome.PowerManager --type=method_call --print-reply --reply-timeout=2000 /org/gnome/PowerManager org.gnome.PowerManager.<something to do with idle timer> I just cant find the end bit
[02:32] <RAOF> Vantrax: You're probably better off in #gnome-hackers on irc.gimp.org for questions like that.  Having said that, the d-feet dbus browser will be your friend.
[02:35] <Vantrax> thanks for that RAOF, ill check into both
[02:54] <Vantrax> RAOF: d-feet doesnt show buses existing that are listed in the gnome docs, has ubuntu changed things? org.gnome.PowerManager doesnt even exist
[02:55] <RAOF> As far as I know, org.gnome.PowerManager has been gone for a release or two; it changed to org.freedesktop.PowerManager, and now most if it seems to have been subsumed with org.freedesktop.DeviceKit.Power on the system bus.
[02:56] <Vantrax> ahh
[02:56] <Vantrax> old doco
[03:00] <Vantrax> im not showing devicekit, only consolekit, but im seeing what im after there i think
[03:01] <RAOF> Vantrax: It's changed in Karmic.
[03:01] <RAOF> New gnome-power-manager, new DBus API.
[03:05] <Vantrax> ahh
[03:05] <Vantrax> so its consolkit now, but changing to devicekit
[03:08] <RAOF> No, it's still ConsoleKit, but DeviceKit has joined it.
[03:08] <RAOF> There's a big proliferation of Kits.  And not the cool car, sadly.
[03:09] <lifeless> its freaking annoying
[03:09] <lifeless> consolekit devicekit realtimekit sillynamekit
[03:30] <Vantrax> no wonder im getting confused
[03:30] <Vantrax> so, im 90% of the way there.
[03:31] <Vantrax> im getting an error from this command: dbus-send --system --dest=org.freedesktop.ConsoleKit --type=method_call --print-reply --reply-timeout=2000 /org/freedesktop/ConsoleKit/Manager org.freedesktop.ConsoleKit.Manager.GetSystemIdleSinceHint string:iso8601_datetime
[03:31] <lifeless> should make a smileyfacelibrary called 'sadkit'
[03:31] <Vantrax> Error org.freedesktop.DBus.Error.UnknownMethod: Method "GetSystemIdleSinceHint" with signature "s" on interface "org.freedesktop.ConsoleKit.Manager" doesn't exist
[03:31] <Vantrax> i dont know what the signature "s" means
[03:31] <lifeless> string
[03:32]  * Vantrax is creating an idle shutdown timer
[03:32] <Vantrax> so the error is likely with 'string:iso8601_datetime'
[03:33] <Vantrax> thats what d-feet is showing the value as tho...
[03:33]  * Vantrax is now very confused
[03:40] <Vantrax> RAOF any ideas where the error is in that command, it should be fine based on what d-feet is spitting out
[03:41] <RAOF> Vantrax: No idea whatsoever, sorry.
[03:41] <RAOF> #gnome-hackers :)
[03:41] <Vantrax> lol
[03:41] <Vantrax> thanks again
[03:41] <RAOF> Or possibly #I-Hate-*Kit
[03:41] <Vantrax> now to find my way to irg.gimp.org
[03:41] <Vantrax> i live there:P
[03:41] <StevenK> #I-Hate-*Kit actually exists? :-)
[04:10] <Vantrax> RAOF you still floating aroudn?
[04:10] <RAOF> Yeah, but not for long.
[04:10] <Vantrax> dbus-send --system --dest=org.freedesktop.ConsoleKit --type=method_call --print-reply --reply-timeout=2000 /org/freedesktop/ConsoleKit/Manager org.freedesktop.ConsoleKit.Manager.GetSystemIdelSinceHint is now working, but not returning anything but and empty stromg
[04:10] <Vantrax> string
[04:10] <Vantrax> and empty string
[04:11] <Vantrax> from what i gather, its supposed to return the date/time that the system has been idle for
[04:11] <RAOF> I'm blank.  I've got no better idea than d-feet gives me.
[04:11] <Vantrax> he he he
[04:11] <Vantrax> #gnome-hackers:P
[04:18] <TheMuso> cat Spads
[04:18] <TheMuso> woops wrong window, and damn tab completion. Sorry Spads.
[05:13] <bgamari> Where is the debug info package for gnome-settings-daemon
[05:15] <RAOF> gnome-settings-daemon-dbgsym
[05:16] <RAOF> bgamari: Specifically: https://wiki.ubuntu.com/DebuggingProgramCrash
[05:16] <bgamari> RAOF, that package doesn't seem to be available for karmic
[05:17] <bgamari> I don't think debugging symbols are generated for this package
[05:17] <bgamari> could it be a packaging mistake?
[05:17] <RAOF> No.  They're there, but if you follow that link you'll see you need to add the dbgsym repository.
[05:18] <bgamari> ahh, yep
[05:18] <bgamari> my bad, sorry. new to debian-esque distros
[05:19] <RAOF> Well, this is something Ubuntu-specific.  As a part of our build process we automatically strip all the debug symbols out into -dbgsym packages.
[05:39] <bgamari> RAOF, sure
[05:39] <bgamari> RAOF, What exactly are the -dbg packages in that case?
[05:48] <cjwatson> geser: pdftk> I'd be inclined to say that unless the copyright holder is demanding it then we should just fix it in Karmic. It would take heroic measures to remove those files from stable releases in a meaningful way, and I'm not sure it's worth it unless we have to
[05:50] <slangasek> morning
[06:24] <pitti> Good morning
[06:24] <Hobbsee> orning pitti!
[06:24] <pitti> slangasek: ugh, please file a bug, yes
[06:25] <pitti> hey Hobbsee
[06:25] <slangasek> pitti: yep, will file it later today
[06:25] <StevenK> Morning pitti
[06:25]  * Hobbsee throws pitti a few gummy bears
[06:25]  * pitti munches
[06:25] <slangasek> pitti: so where is pkgbinarymangler getting hooked in that's causing this?  I thought it used to only hook into dh_strip?
[06:25] <pitti> slangasek: right, and it still does
[06:26] <pitti> slangasek: argh, sorry; that was pkg-create-dbgsym
[06:26] <pitti> pkgbinarymangler is dpkg-deb
[06:26] <slangasek> ok
[06:26] <pitti> slangasek: it needs to update the md5sums of *.desktop
[06:27] <slangasek> darn, there's no way to hook it earlier?  fixing up the md5sums file after invalidating it feels dirty to me
[06:27] <pitti> slangasek: we could do it earlier, of course
[06:27] <pitti> but more diversions
[06:28]  * slangasek nods
[06:28] <slangasek> (dh_desktop? :)
[06:29] <pitti> very few programs use that
[06:29] <pitti> dh_install is too early, misses a lot of them
[06:30] <slangasek> waah
[06:30] <slangasek> ok
[06:30] <pitti> dh_md5sums :)
[06:30] <slangasek> heh
[06:30] <StevenK> Hasn't dh_desktop been mostly killed anyway?
[06:31] <slangasek> StevenK: yah, manpage says it's obsolete
[06:31] <StevenK> I thought so
[06:31] <pitti> slangasek: that could only be an alternative route, though, since again packages might not actually use it
[06:31] <slangasek> pitti: right
[07:24] <\sh> moins
[07:34] <dholbach> good morning
[07:43] <ak4d7>  hi everyone i need help recovering a ubuntu installation after crashing it with a compiz configuration now it won't login or start
[07:45] <Hobbsee> (please don't cross post, and #ubuntu for support questions)
[08:10] <lifeless> TheMuso: ping; dmraid
[08:28] <geser> good morning
[08:30] <The_Warlock> i made a quirk for my intel graphics cared as the resolution was very low. but upon restart my resolution falls back to very low resolution unless i restart xserver.
[08:30] <The_Warlock> how do i fix this?
[08:32] <The_Warlock> this is 9.04
[08:35] <TheMuso> lifeless: Yeah I have been neglecting it somewhat. Re the dmraid-activate problem, I really don't know, as I've been unable to reproduce it here, although Ihaven't tried with karmic. As for your lba patch, I'll push it to debian and do an Ubuntu upload with it included.
[08:37] <lifeless> cool
[08:38] <lifeless> my patched version boots fine with libata.ignore_hpa=1, so I'm sure I haven't borked anything
[08:38] <TheMuso> ok
[09:17] <asanchez> Hi everybody, I would ask for someone with a Toshiba Dynabook UX netbook
[09:19] <asanchez> I ask in this channel because I remember to see one guy from Canonical with this netbook
[09:20] <asanchez> We are planning to buy hundreds of units of this model but we aren't able to make sound work under 9.04 but it works under 8.10
[09:20] <mok0> Hm, sound
[09:21] <mok0> asanchez: you might have better luck asking in ubuntuforums
[09:21] <asanchez> mok0, i have just reported a bug
[09:22] <asanchez> but there is a very few people with this model and there is no info in any forum jet
[09:22] <mok0> asanchez: that's fine, but ubuntuforums has hundreds of thousands of users and your luck there may be better. You can also try asking a question on LP instead of a bug
[09:23] <asanchez> I'll do, thanks
[09:23] <mok0> asanchez: did you try the trivial things such as turning up the volume on the mixer?
[09:23] <asanchez> of course
[09:23] <mok0> asanchez: sorry, I had to ask :-) It's the most common problem, I've had it myself
[09:24] <asanchez> mok0, :-) We are working together with Toshiba engineers but something has changed between alsa versions of intrepid and jaunty
[09:25] <mok0> asanchez: Interesting... well it's pretty quiet around here just now, you may be able to reach a -dev that can help you later
[09:26] <mok0> asanchez: you can also try sending a message to ubuntu-dev-discuss ML
[09:27] <The_Warlock> can somebody tell me how to fix my low resolution issue on upgrading to 9.04
[09:27] <asanchez> mok0, ok I'll try later, thanks
[09:27] <The_Warlock> i use 00:02.1 Display controller: Intel Corporation 82Q33 Express Integrated Graphics Controller (rev 02)
[10:17] <bigon> autosync from debian still active for main pkg too?
[10:32] <slangasek> bigon: yes
[11:17] <pitti> mvo: is compiz still blacklisted on 965 in karmic?
[11:17] <ogra_> shouldnt be anymore
[11:18] <pitti> bryce: good feedback with jaunty-proposed -intel, I copy the stuff across now
[11:18] <ogra_> (i know it was changed in bzr a while ago)
[11:18] <pitti> the bug task is still open, I wonder whether I should close it
[11:19] <pitti> mvo: nevermind, saw the changelog
[11:23]  * Hobbsee cheers at pitti for attempting to fix the intel graphics borkage
[11:23] <pitti> Hobbsee: does it work for you now?
[11:24] <Hobbsee> pitti: no :(
[11:24] <Hobbsee> pitti: i've had X die and make the machine unresponsive 3 times today.  two of those times werer in 10 minutes of each other
[11:25] <Hobbsee> pitti: however, under metacity, it appears to work fine.  No screen blankings, no X server suiciding, or anything
[11:29] <pitti> hm, since today, one of my CPUs is constantly at 100%, and top shows nothign (just 10% gconf); does that happen to anyone else?
[11:29] <pitti> might be xorg-edgers breakage
[11:30] <ogra_> not here
[11:30] <ogra_> even my swap seems calm (system was running over the weekend and upgraded yesterday the last time)
[11:34] <Hobbsee> pitti: i don't see it, fwiw
[11:34] <pitti> hah
[11:34] <pitti> killall metacity did it
[11:53] <pitti> cprov, al-maisan: hm, why does https://edge.launchpad.net/ubuntu/+source/sg3-utils/1.27~repack-0ubuntu1 not show any more that the binaries are NEW
[11:53] <pitti> ?
[11:54] <StevenK> pitti: There's a bug about that
[11:54] <pitti> ah, ok
[12:01]  * al-maisan looks
[12:02] <al-maisan> pitti: it says "PENDING: Karmic  pocket Release  in component main  and section admin"
[12:03] <pitti> al-maisan: right, I overwrote it to main in the NEW queue, but didn't accept them
[12:03] <pitti> (since I uploaded them)
[12:03] <pitti> so they should be stuck in NEW until some archive admin reviews them
[12:04] <al-maisan> pitti: did you observe that expected behaviour in previous similar cases?
[12:04] <pitti> al-maisan: yes, it always said the queue after the build status before
[12:05] <pitti> like (ACCEPTED), or (NEW), or (DONE)
[12:05] <pitti> al-maisan: check non-edge: https://launchpad.net/ubuntu/+source/sg3-utils/1.27~repack-0ubuntu1
[12:06] <al-maisan> pitti: it got published in the mean time
[12:06] <pitti> right, the source, but not the binaries
[12:06] <al-maisan> pitti: right, I see now.
[12:08] <al-maisan> pitti: sorry, I would not know the reason; it was changed only recently (edge vs. non-edge)
[12:08] <al-maisan> pitti: I am sure cprov will comment on it though.
[12:09] <pitti> al-maisan: thanks
[12:11]  * StevenK digs up the bug number
[12:13] <StevenK> pitti, al-maisan: Bug 388690
[12:14] <al-maisan> StevenK, pitti: "status: Triaged → In Progress"; so it looks cprov is already working on it.
[12:17] <pitti> ok, so it seems this wasn't intended then
[12:18] <al-maisan> yep
[12:44] <mok0> I am getting a libtool (internal?) error in netcdf:  ../libtool: line 847: X--mode=compile: command not found
[12:48] <mok0> hrmph, trying libtoolize -fc
[12:50] <seb128> mok0: try autoreconf rather
[12:51] <mok0> seb128: libtoolize works...
[12:52] <mok0> seb128: I plan to let the new ltmain.sh etc. come via diff.gz, you agree it's ok to do it like that?
[12:52] <mok0> seb128: the .diff.gz is pretty dirty already
[12:52] <seb128> I don't know this package enough to comment
[12:53] <seb128> I tend to put autotools changes in a patch in the debian directory
[12:53] <mok0> seb128: me too, but for a rebuild I'd rather not mess with patches
[12:53] <seb128> a rebuild should not break this way
[12:54] <seb128> if it does that's because you have a bug
[12:54] <mok0> seb128: the bug is that upstream is distributing an age-old version of libtool files
[12:54] <seb128> which is fine if you don't run autotools at build time
[12:55] <mok0> seb128: it's not run
[12:56] <mok0> seb128: ... and it's also not fine :-)
[12:56] <seb128> it's probably run because of a timestamp issue or something
[12:56] <seb128> there is no reason why it should break otherwise
[12:57] <mok0> seb128: oh, ltmain.sh is always run, to make libraries
[12:58] <mok0> seb128: that's why it helps to use a newer one
[12:58] <seb128> it's rather some autotools which are run there or you would not have the error
[12:59] <seb128> "line 847: X--mode=compile: command not found"
[12:59] <seb128> you usually get that when running autotools not correct
[12:59] <seb128> ie missing some update commands
[12:59] <mok0> seb128: that disappears after running libtoolize -fc in srcdir
[12:59] <seb128> right
[13:00] <seb128> as said the bug is there when you don't run all the required commands
[13:00] <mok0> seb128: it IS doing something strange in the build...
[13:02] <mok0> seb128: damn, he's patching acinclude.m4
[13:02] <mok0> ... and configure .ac
[13:03] <mok0> http://launchpadlibrarian.net/28195811/buildlog_ubuntu-karmic-i386.netcdf_1%3A3.6.2-3.1build1_FAILEDTOBUILD.txt.gz
[13:06] <seb128> pedro_: ola!
[13:07] <pedro_> bonjour seb128!
[13:19] <apw> mvo, you just uploaded a grub fix, do you know if the same issues appear in grub2?
[13:20] <cjwatson> grub2 doesn't handle the crashkernel stuff right now
[13:27] <mvo> apw: as cjwatson said, the whole crashfile stuff needs to be ported to grub2
[13:27] <mvo> apw: I'm struggling with "crash" right now, it does not want to give me something useful, even with linux-image-debug-`uname -r` installed
[13:28] <apw> cjwatson, mvo, thanks for the info
[13:28] <apw> mvo sound like a bit of a mare
[13:28] <mvo> apw: btw, do you plan to merge kexec-tools? or should I do it? its something that the linux-crashfile stuff needs too
[13:29] <mvo> apw: it is :) its my first contact with the spec and I already feel like making more tea is required to cope
[13:29] <apw> mvo, it isn't on my radar right now, so feel free to do it.  not something i really know how to do yet
[13:29] <mok0> Hrmph, /me is annoyed -- most Debian packages I look at have sucky sucky packaging
[13:29] <mvo> apw: ok, thanks
[13:30] <ogra_> mvo, oh, have fun :P
[13:30] <mvo> ogra_: "thanks"
[13:30] <ogra_> there is no common ancestor anymore after last merge
[13:31] <mvo> *wiiieee*
[13:31]  * mvo mubbles that it will be all good, all good
[13:31] <StevenK> And there we see mvo running for the kettle
[13:31] <ogra_> lieb just rolled a new upstream, newer than debian
[13:31] <ogra_> :)
[13:46] <cjwatson> mvo: really, grub2's legacy update-grub script should be a copy of grub's; but since we haven't merged grub in ages there's a bit of work required to get there
[13:46] <cjwatson> mvo: I have a half-completed merge on my disk
[13:48] <mvo> cjwatson: thanks, so best is to just wait for this merge to be completed?
[13:48] <mvo> cjwatson: there is tons of other stuff to look at before and grub1 is fine for testing, so I guess that should be fine
[13:48] <cjwatson> mvo: yeah, I think so
[13:49] <mvo> ok, thanks
[13:56] <slangasek> asac: bug #321442> no!  there's *no reason* that network-manager should be second-guessing the file permissions - if I leak the secret by making the file world-readable, then it's already leaked, and this is no reason to not use the config info
[13:57] <ubott2> Launchpad bug 321442 in network-manager ""system"-level connection doesn't start up until nm-applet is launched" [Medium,Triaged] https://launchpad.net/bugs/321442
[13:58]  * ogra wonders where his indicator applet went in karmic
[13:59] <ogra> ogra@osiris:~$ ps ax|grep indicator
[13:59] <ogra>  4961 ?        S      0:03 /usr/lib/indicator-applet/indicator-applet --oaf-activate-iid=OAFIID:GNOME_IndicatorApplet_Factory --oaf-ior-fd=32
[13:59] <ogra> its not visible on the panel ...
[14:03] <alkisg> ogra, `gconftool-2  -a /apps/panel/applets/indicator_applet_screen0` ?
[14:03] <ogra> nothing
[14:04] <alkisg> gconftool-2  --all-dirs /apps/panel/applets ?
[14:04] <alkisg> No indicator at all?
[14:04] <ogra> ah, its applet_10
[14:05] <alkisg> Look at the position and the right_stick value..
[14:05] <ogra> panel_right_stick = false and position = 1466 seems ok to me
[14:05] <alkisg> No, position is #applet
[14:05] <alkisg> Not in pixels
[14:05] <alkisg> So it should be somewhere betwee 5-10 or so...
[14:06] <ogra> oh, since when ?
[14:06] <ogra> "The position of this panel object. The position is specified by the number of pixels from the left (or top if vertical) panel edge. "
[14:06] <alkisg> Ooops... looking
[14:06] <ogra> thats what gconf-editor tells me
[14:07] <alkisg> Well, all my applets use an index, not pixels
[14:07] <ogra> i think its rather a bug in the applet code in karmic
[14:07] <alkisg> Try to put the same settings as in jaunty: panel_right_stick=true, position=4
[14:09] <ogra> no change
[14:09] <alkisg> OK
[14:09]  * alkisg is installing karmic, will see first-handed soon :)
[14:09] <ogra> tedg, is there a known bug with the indicator applet not being visible ?
[14:10] <ogra> (in karmic)
[14:10] <tedg> ogra, Not known by me :)
[14:10] <ogra> weird
[14:10] <tedg> ogra, you can look at /usr/lib/indicator-applet/listen-and-print and see if it shows anyone on the bus.
[14:10] <ogra> it must have vamished with one of the recent upgrades here
[14:10] <ogra> just execute ?
[14:11] <tgpraveen> ogra: it must be due to empathy becoming default
[14:11] <tedg> ogra, Yeah, it's a listener.  If it doesn't print anything, that means no one is indicating anything.
[14:11] <tgpraveen> from pidgin so maybe it is getting upgraded to support empathy
[14:11] <ogra> tedg, yeah, it stays quiet
[14:12]  * ogra waits for a mail 
[14:12] <tedg> ogra, Okay, so no one is indicating.  So its either a evolution/pidgin/gwibber/etc. bug depending on what you expect to be indicating.
[14:12] <ogra> tedg, but there is nothing in my panel either
[14:13] <tedg> ogra, it should be virtually invisible unless someone is indicating something.  That's changing after the discussion at UDS, but I haven't fixed it yet :)
[14:13] <ogra> shouldnt i at least have the mail envelope ?
[14:13] <ogra> hmm, ok, might be evo then
[14:38] <alkisg> Hi asac, ogra told me you're the nm maintainer. I'm having this bug both in Jaunty and Karmic: https://bugs.launchpad.net/ubuntu/+source/network-manager/+bug/367227 - can I somehow help debugging it?
[14:38] <ubott2> Launchpad bug 367227 in network-manager "network manager connection editor adding wired connections does not work" [Undecided,New]
[14:39] <stgraber> pitti: Hey, did you get my mail about cups ? I talked with the Debian maintainer for LTSP and he says that the future would be appreciated by his users too.
[14:41] <pitti> stgraber: I got it, just didn't find time to answer yet, sorry
[14:41] <stgraber> np
[14:50] <ScottK> mterry: When you're around I have a comment on the syslog migration spec ....
[14:50] <mterry> ScottK: OK, shoot!
[14:51] <ScottK> mterry: There were a couple of packages that had package specific functionality to support starting chrooted in the old sysklogd package.  Are you migrating those too?
[14:51] <ScottK> I added stuff for unbound and I think ltsp had something too.
[14:52] <ScottK> I didn't see it mentioned in the spec, so I thought I'd ask.
[14:52] <mterry> ScottK: The spec talks about that -- says it's out of scope for the spec, but an email should be sent saying how to do it in rsyslog
[14:52] <mterry> ScottK: Under "Other packages"
[14:53] <mterry> ScottK: Unless I'm misreading you
[14:53] <ScottK> mterry: OK.  I missed that.  It seems to me it's a regression not to migrate that stuff.
[14:53] <mterry> ScottK: Yeah, migration would be good.  I just think we wanted to consider it not a blocker
[14:54] <ScottK> mterry: I just re-read that bit.  You are misreading me I think.
[14:54] <ScottK> These are Ubuntu unique bits that are in the ksyslogd package.
[14:54] <ScottK> It's stuff to help other packages, but shipped in our default syslog.
[14:56]  * mterry looks a bit more
[15:03] <mterry> ScottK: No, I think I'm still reading you right.  For example, with unbound, you can now instead drop a config file in /etc/rsyslog.d that contains a line like "$AddUnixListenSocket /var/lib/unbound/dev/log".  This would be done in unbound pkg, not rsyslog
[15:08] <ScottK> mterry: In sysklogd there's also an update to the rc script needed.  Is such a thing not needed with rsyslog?
[15:08] <mterry> ScottK: No, the default config file includes all files in /etc/rsyslog.d that end in '.conf'
[15:08] <ScottK> OK.
[15:10] <ScottK> So it looks like I have to install the package specific conf file and then restart rsyslog
[15:10] <mterry> ScottK: postfix has an example of doing just that -- adding a socket
[15:10] <mterry> ScottK: Uh, yeah, sounds right
[15:11] <ScottK> mterry: Thanks.  I'll look at that.
[15:11] <ScottK> stgraber: ^^^ affects you too for ltsp I believe.
[15:12] <lool> cjwatson: Hey, I'd like to push that sudo patch for /etc/environment parsing; are you ok with this?
[15:12] <cjwatson> lool: I haven't had time to review it, I'm afraid, but go for it
[15:12] <lool> Ok, thanks
[15:15] <stgraber> ScottK: I'll need to check, AFAIK the only thing LTSP does with syslog is redirecting everything to a remote syslog server (usually on the LTSP server) so I'll need to check what happens to the config file for that
[15:16] <ScottK> stgraber: I didn't look into details, just that you had some package specific magic that would need to be considered.
[15:19] <ogra> stgraber, no, it doesnt
[15:20] <ogra> stgraber, by default ltsp doesnt log at all
[15:20] <stgraber> ogra: right, but the only use we have for syslog is to do remote logging right ?
[15:20] <ogra> but the syslog initscript has an override so you can put ltsp specific defaults into /etc/ltsp
[15:20] <stgraber> ah, that I didn't know :) will need to look at that then
[15:20] <ogra> thats the only change thats applied to syslog related to ltsp
[15:21] <ogra> but not overly important to keep imho
[15:21] <stgraber> thought we only generated a syslog.conf, didn't know we had a patch on syslog
[15:24] <ogra> we dont touch syslog.conf
[15:24] <ogra> its a conffile :)
[15:24] <ogra> # allow ltsp to override
[15:24] <ogra> test ! -r /etc/ltsp/syslogd || . /etc/ltsp/syslogd
[15:24] <ogra> thats the patch
[15:27] <ogra> meh, wheer is my approx initscript gone
[15:27] <ogra> *where
[15:28] <ogra> argh
[15:28] <ogra> * Change approx to run under inetd (closes: #517217, #479493)
[15:28] <ogra> how silly
[15:35] <ScottK> mterry: In the postfix example, how does rsyslog get restarted?
[15:35] <mterry> ScottK: Let me see.  Maybe it doesn't
[15:35]  * ScottK eyeballs lamont.
[15:36] <mok0> Requesting a give-back on gdal for arch armel https://edge.launchpad.net/ubuntu/+source/gdal/1.5.4-4/+build/1051957
[15:36] <ScottK> mok0: I'll do it.
[15:36] <mok0> ScottK, thanks a lot
[15:36] <mterry> ScottK: Yeah, don't think it does.  Comment in .conf file says "when rsyslog is restarted."  Probably should restart
[15:37] <ScottK> mok0: It's already retried.  Also since it's in Universe you could do it yourself.
[15:37] <mok0> ScottK, Hm, I don't have the link to rebuild...
[15:37] <ScottK> mok0: It's already needs-building.
[15:38] <mok0> ScottK, ah,  that's why, I see
[15:38] <mok0> ScottK, thx
[15:38] <lamont> ScottK: I was just acking the debian NMU
[15:38] <ScottK> No problem.
[15:39] <ScottK> lamont: OK.  Well if I understand it right, rsyslog won't know about the socket until after it's restarted.  That doesn't seem right to me.
[15:39] <ScottK> Install package and some indeterminate time later logging works ....
[15:39] <ScottK> mterry: What's the preferred solution here?
[15:40] <mterry> ScottK: It should be harmless to restart rsyslog.  I've never done that before (restart a service when installing a different package), so I'm not clear on most-recommended way of doing it
[15:40] <mterry> ScottK: But seems like it's worth doing
[15:41] <ScottK> mterry: OK.  I think it's reasonable as part of the "Other packages" part of the spec for the spec to recommend the appropriate solution.
[15:42] <ScottK> I'll implement it for unbound and (if lamont doesn't first) postfix, but I'd like to be following a standard approach.
[15:42] <mterry> ScottK: Agreed.  I was going to work on that section when it came time to send the email out
[15:42] <ScottK> mterry: OK.  What's your timeline for that?
[15:43] <lool> libsgutils1 and 2 recommend sg3-utils since dapper with no rationale; I see sg3-utils only contains doc and binaries and libsgutil* don't reference any exec symbols, so it seems like this dep could be dropped and we could save space on the CD; any reason not to demote it?
[15:43] <mterry> ScottK: Wanted to get my changes committed at least.  But they don't affect this part of rsyslog.  No reason it can't be done sooner rather than later.  I'll look at it
[15:43] <ScottK> mterry: Thanks.
[15:43] <mterry> ScottK: Certainly could do it this week
[15:43]  * ScottK sits back and waits for the mail.
[15:44] <mterry> :)
[15:44] <cjwatson> or you could have rsyslog use inotify for its configuration directory
[15:46] <mterry> True, but I'd rather not patch it like that if possible
[15:51] <ScottK> It might be simpler and more reliable that making every package that uses a chroot restart syslog.
[15:51]  * ScottK resumes sitting.
[16:01] <cjwatson> mterry: I meant ask upstream for that feature :)
[16:01] <mterry> cjwatson: Yar
[16:04] <tkamppeter> pitti, hi
[16:04] <pitti> hi tkamppeter
[16:06] <tkamppeter> pitti, about bug 382379
[16:08] <tkamppeter> pitti, I have found a problem in my fix in Poppler. Duplex does not work any more with it. I ahve fixed it already and I am adding debdiffs for Karmic and Jaunty to the bug. Can you upload the new package versions as soon as the debdiffs are there? Thanks.
[16:09] <pitti> tkamppeter: can do
[16:10] <mterry> ScottK: https://wiki.ubuntu.com/FoundationsTeam/Specs/Rsyslogd#Other%20packages has example code now.  Not quite ready to send out email, but there ya go if you're anxious
[16:10]  * ScottK looks
[16:12] <ScottK> mterry: Wouldn't that be on purge, not remove?
[16:12] <ScottK> (for the postrm)
[16:12] <mterry> ScottK: Yes!  duh
[16:13] <mterry> ScottK: fixed
[16:13] <ScottK> Great.
[16:14] <mterry> ScottK: And I suppose, if you were feeling very fancy, the postinst restart would be only run when the package changes the config file...
[16:14] <tkamppeter> pitti, Karmic debdiff is ready.
[16:22] <ogra> hmm, using grub2 to boot from SD makes it hang for about 5minutes
[16:23] <ogra> on the same HW booting from hdd works as expected
[16:35] <tkamppeter> pitti, Jaunty debdiff is in place.
[16:37] <pitti> tkamppeter: can you please send the updated patch to upstream/Debian BTS as well, to avoid them uploading broken packages?
[16:39] <tkamppeter> pitti, I have already sent the patch to upstream: https://bugs.freedesktop.org/show_bug.cgi?id=19777
[16:39] <pitti> tkamppeter: cool, thanks; jaunty and karmic uploaded
[16:42] <tkamppeter> pitti, the Karmic task is now "Fix Released", the Jaunty package is in the Approval queue.
[16:43] <pitti> tkamppeter: processed
[16:49] <alkisg> Hi asac, ogra told me you're the nm maintainer. I'm having this bug both in Jaunty and Karmic: https://bugs.launchpad.net/ubuntu/+source/network-manager/+bug/367227 - can I somehow help debugging it?
[16:53] <tkamppeter> pitti, thank you very much.
[17:00] <tkamppeter> pitti, Debian bug 530731 is also updated now.
[17:00] <ogra> tedg, oh ... Jun 22 18:00:01 osiris dbus-daemon: Rejected send message, 1 matched rules; type="method_call", sender=":1.59" (uid=1000 pid=4961 comm="/usr/lib/indicator-applet/indicator-applet --oaf-a") interface="org.freedesktop.DBus.Properties"
[17:01] <ogra> tedg, thats why i dont get any indications since i upgraded to karmic
[17:01] <ogra> (from auth.log)
[17:22] <karmictest2> hello there
[17:24] <karmictest2> i have found a small bug, ( i am not an technical person, but try to convey it any way ) , and am trying to track it down
[17:24] <karmictest2> its the devkit deamon that keeps on polling and trying to mount a floppy drive..
[17:25] <ogra> known
[17:25] <karmictest2> and makes an terrible noise doing it..
[17:25] <karmictest2> like its killing the thing, this is on karmic 2
[17:25] <ogra> bug 384469
[17:25] <karmictest2> fresh install
[17:27] <karmictest2> yes thats the one, now i try to find an nice solution, here is the same bug that fedora users run into :
[17:27] <karmictest2> https://bugzilla.redhat.com/show_bug.cgi?id=489083
[17:27] <ogra> well, there is a workaround posted in the LP bug
[17:27] <karmictest2> yes i just posted the work around
[17:27] <ogra> devkit-disks --inhibit-polling /dev/fd0 &
[17:28] <ogra> but as you can see its fixed upstream already
[17:28] <karmictest2> that was my next question...
[17:28] <ogra> so it will show up with the next update of the package
[17:29] <ogra> https://bugs.freedesktop.org/show_bug.cgi?id=22149 is the upstream bug (as you can see on the launchpad bug)
[17:29] <karmictest2> its upstream meaning its not in the updates yet?
[17:29] <karmictest2> ok, very good, i lay my head at rest... :)
[17:29] <ogra> the ubuntu task is in "fix committed" status
[17:29] <ogra> so its in the bzr branch already, just not uploaded yet
[17:30] <karmictest2> thanks for your time, and good directing, its sure to be fixed in the next cycle of release, so ok, good!
[17:30] <ogra> but will show up with the next upload of the devicekit-disks package
[17:30] <karmictest2> :)
[17:30] <ogra> should be fixed within the next days ... whenever pitti finds the time ;)
[17:31] <karmictest2> hmm, great, great!
[17:31] <karmictest2> ok, going to do the dishes, yes this too has to be done...
[17:31] <karmictest2> :P
[17:31] <karmictest2> bye
[17:32]  * karmictest2 doing dishes
[17:35] <pitti> karmictest2: it's known/fixed upstream
[17:35] <pitti> karmictest2: and I uploaded the latest devkit-disks into https://edge.launchpad.net/~ubuntu-desktop/+archive/ppa today
[17:35] <pitti> karmictest2: so, if you want to test that, appreciated
[17:43]  * pitti eyes 'New "libc" project libposix started' -- YALI?
[17:44] <tedg> ogra, no that's an error because of (in my opinion) is a misconfig of DBus System bus.  It shouldn't effect things on the session bus though.
[17:44] <ScottK> pitti: Ought to be done is a few weeks, so we can switch for Karmic, right?
[17:44] <ogra> hmm, k
[17:44] <ScottK> ;-)
[17:45] <ogra> ScottK, only if you promise to backport it to jaunty and intrepid too
[17:46] <ScottK> If it gets into Karmic, I'll be glad to backport it.
[17:46] <directhex> nothing says "eligible for backports" like a new libc
[17:48] <karmictest2> pitti : this package https://edge.launchpad.net/~ubuntu-desktop/+archive/ppa/+files/devicekit-disks_005-0ubuntu1~ppa2_i386.deb , right?
[17:49] <karmictest2> hmm
[17:49] <karmictest2> its not that easy, seems to need : libpolkit-backend-1-0
[17:50] <pitti> karmictest2: right, you need the entire PPA
[17:50] <pitti> it has a load of dependencies
[17:50] <karmictest2> ah...
[17:50] <pitti> karmictest2: and conversely, I suppose you need the new libgdu* bits as wel
[17:51] <pitti> karmictest2: this is just a staging area for what will go into karmic in the next time anyway, so feel free to just dist-upgrade with the ppa
[17:51] <pitti> all the versions are running on my machine, and it's not very broken
[17:51] <karmictest2> sure
[17:51] <pitti> some minor bits, like "doesn't remember privileges within the session", but nothing serious
[17:51] <karmictest2> i dont mind breaking it,
[17:51] <karmictest2> its an full install for testing , so nproblem
[17:53] <karmictest2> seems to depend on : libpolkit-gobject-1-0
[17:53] <karmictest2> libpolkit-backend-1-0
[17:57] <karmictest2> pitti , did no go well, the installation spits out an error about Package status and progres file descriptor , that it could not read...
[18:00] <karmictest2> ok
[18:00] <karmictest2> better now
[18:01] <karmictest2> installed from synaptic
[18:01] <karmictest2> going for the reboot, to see if it is fixed...
[18:04] <karmictest2> pitti , yes it is fixed now
[18:06] <pitti> karmictest2: thanks \o/
[18:07] <bryce> pitti, thanks for copying the -intel bits into jaunty
[18:09] <pitti> bryce: I'm glad that we can (hopefully) close this chapter now :)
[18:11] <karmictest2> pitti , shall i add the fix to the bugtracker?..
[18:11] <karmictest2> like this : This bug will be fixed in the next release, but you can do this :
[18:11] <karmictest2> add to your repositories :
[18:11] <karmictest2> deb http://ppa.launchpad.net/ubuntu-desktop/ppa/ubuntu karmic main
[18:11] <karmictest2> then install the package :  devicekit ( search with synaptic ) and install any dependecies as well, reboot , fixed....
[18:12] <pitti> karmictest2: sure, if you want
[18:12] <karmictest2> ok..
[18:13] <pitti> good night everyone
[18:13] <karmictest2> night , and thanks
[18:13] <karmictest2> :)\
[18:22] <karmictest2> ok bye
[19:00] <janisozaur> do the -dbg packages provide profiling information?
[19:01] <joaopinto> janisozaur, no, they provide debug information
[19:05] <tjaalton> joaopinto, janisozaur: the profiler tools need debugging symbols, so yes
[19:06] <joaopinto> hum, debugging symbols does not mean profiling information :)
[19:06] <janisozaur> tjaalton, according to http://www.cs.utah.edu/dept/old/texinfo/as/gprof.html (for gnu gprof) they require additional info to just -g, as in -pg
[19:07] <janisozaur> tjaalton, but your statement is of course correct, they *need* debugging symbols, just it's not  enough
[19:08] <tjaalton> ok
[19:09] <janisozaur> actually it kind of makes sense - as compiling an app for profiling generates lots of output into a file and all the additional calls to handle that make an app run slower, so it would be useless for day-to-day use after installing -dbg
[19:44] <NCommander> Is the wiki lagging for anyone else?
[19:51] <janisozaur> it's fine here (PL)
[20:00] <magcius> Is Canonical planning to do anything with freedesktop.org's projects, like PackageKit, ConsoleKit, DeviceKit, PolicyKit?
[20:09] <tgpraveen1> magcius: devicekit,policykit
[20:09] <tgpraveen1> are used in ubuntu
[20:09] <tgpraveen1> already
[20:09] <magcius> DeviceKit is used?
[20:09] <magcius> PolicyKit isn't used nearly at all... I can only think of a couple applications that use them.
[20:10] <tgpraveen1> magcius: devicekit will be actively used from karmic
[20:14] <Riddell> kees: poke on bug 374973
[20:16] <NCommander> directhex, ping, is there known issues with mono on ARM?
[20:17] <wjblack> Hello!
[20:19] <wjblack> I recently backported the r8169 driver from 2.6.30 to 2.6.28 (big missing interrupt fix) and was wondering what the "blessed" way to make a package of just this driver is.  I've made .debs before and am interested in possibly doing a PPA.  Anyone have a doc link handy (I couldn't find anything terribly obvious)?
[20:21] <wjblack> ...or am I better off asking in #ubuntu-kernel?
[20:22] <kees> Riddell: thanks for the reminder!
[20:23] <kees> Riddell: approved and noted.
[20:24] <andrew_sayers> wjblack: I worked out how to put packages in a PPA by reading through the Ubuntu Packaging Guide (https://wiki.ubuntu.com/PackagingGuide).  It's probably not the quickest solution, and I'm probably not the best person to ask, but it worked for me.
[20:24] <andrew_sayers> (and scraps from half a dozen other places, IIRC)
[20:25] <wjblack> Okie-dokie.  That's a start.  (Was looking for a pointer more than a handout anyway ;-) ).
[20:26] <wjblack> I suppose the whole "How do I package?" question is nearly orthogonal to the "what should I call it?" question, too.  Perhaps the latter is a question best suited for the kernel folks.
[20:26]  * wjblack joins another channel :-)
[20:36] <statik> jdstrand: i just got your message regarding python-testtools, thanks and sorry for the trouble. I'll look at fixing that now. It was uploaded by a sponsor via the REVU queue, so whats the right process to go about getting a new upload - go through REVU again with an explanation of what happened, or contact the last sponsor directly?
[20:40] <jdstrand> statik: np. it isn't clear based on https://wiki.ubuntu.com/MOTU/Packages/REVU, but I would talk to the upload sponsor. I wouldn't think just adding the LICENSE would constitute it having to be rereviewed by everyone
[20:42] <ScottK> statik: Usually after an archive admin rejection you just need one MOTU to re-ack and upload.
[20:42] <statik> scottK: thanks!
[20:44] <magcius> tgpraveen1, what about PackageKit and ConsoleKit?
[20:44] <tgpraveen1> magcius: package kit is mostly not going to be used
[20:44] <magcius> tgpraveen1, why not?
[20:45] <tgpraveen1> not sure about console kit
[20:45] <tgpraveen1> magcius: go to karmic koala section of ubuntu forums there is a thread named package kit thread
[20:46] <tgpraveen1> with a LOOONG discussion
[20:46] <tgpraveen1> magcius: and this # is not best for this type of discussion
[20:46] <magcius> tgpraveen1, would #ayatana be better for this?
[20:47] <tgpraveen1> magcius: no that # is for usability and design team and all.
[20:47] <tgpraveen1> magcius: maybe #ubuntu / #ubuntu+1
[20:47] <tgpraveen1> also use the forum for that post that I mentioned
[20:48] <magcius> tgpraveen1, I'm trying to find it.
[20:49] <magcius> Ah, found it.
[20:54] <magcius> tgpraveen1, I would think it would be a dream for developers not to have to worry about packaging systems and things like this, and have PackageKit abstract the entire thing.
[20:54] <magcius> What's the primary motivation for Ubuntu *NOT* to adopt it? I haven't seen one in the thread.
[20:56] <ScottK> magcius: Magical theoretical package systems don't usually pan out in real life.
[20:56] <ScottK> Since virtually no developers inhabit the forums, forums threads are generally a good source of developer opinions on stuff.
[20:57] <magcius> PackageKit is far from "magical"
[20:57] <magcius> And it's not even a package system.
[20:57] <magcius> It's an API that abstracts the interface to the lower-level package management system.
[20:58] <ScottK> Right which is why it's completely orthogonal to not having to worry about packaging
[20:58] <magcius> What do you mean?
[20:59] <ScottK> I mean "Use packagekit" doesn't mean "developers don't have to worry about packaging systems"
[21:00] <ScottK> Also packagekit does not completely abstract the Debian system anyway.
[21:00] <ScottK> We switched to using KPackageKit in Kubuntu and are missing features as a result.
[21:01] <magcius> Hmmph.
[21:02] <magcius> What about ConsoleKit?
[21:02] <ScottK> magcius: One example is we don't have a way to let users know about configuration file conflicts and resolve them.
[21:02]  * ScottK knows less about that.
[21:02] <magcius> ScottK, shouldn't it be the apps'
[21:02] <magcius> app's job to handle migration?
[21:03] <ScottK> magcius: No.  It's the package's job.  The app may not even be running when the upgrade happens.
[21:03] <magcius> Yeah... an app breaking backwards-compatibility with old configuration files and not migrating them is not the sign of a good app.
[21:04] <ScottK> In Debian/Ubuntu it's the package manager's job.
[21:04] <magcius> Most users don't see or want to see configuration files... how can you expect them to know how to merge conflicts?
[21:04] <ScottK> That was the argument for moving to kpackagekit.
[21:04] <ScottK> It's a regression from what we had before.
[21:04] <magcius> Can't Canonical work on the front-ends?
[21:05] <magcius> I know gnome-package-kit sucks, but aren't Red Hat and Canonical working on that?
[21:05] <ScottK> If one wants to arbitrarily redefine package management to be what packagekit supports, then it's great.
[21:05]  * ScottK has no idea.
[21:05] <magcius> Canonical's position of this one huge AppCenter makes less sense to me.
[21:06] <magcius> It's like they want to ignore standards and proprietarize the Linux app market.
[21:06] <ScottK> packagekit also lacks the ability to let the user select from different ways to resolve dependencies.
[21:06] <magcius> ScottK, I have never needed to select that. Ever.
[21:06]  * ScottK has.
[21:06]  * Sarvatt has too, MANY times
[21:07] <magcius> ScottK, isn't it fairly easy to resolve dependencies?
[21:07] <ScottK> Usually
[21:07] <magcius> Just look at the Depends metadata, and traverse down each package, hoping nothing will conflict.
[21:07] <ScottK> It's what happens when hope fails that gets complex.
[21:08] <ScottK> Have a look at Aptitude's dependency resovler code for some idea how complex.
[21:08] <magcius> What about smart?
[21:08] <magcius> PackageKit can be used on top of smart.
[21:08] <Sarvatt> packagekit-gnome is in the repos now, whats the problem?
[21:08] <magcius> Sarvatt, yeah, but it doesn't provide the integration like Fedora has.
[21:09] <magcius> And it's also the outdated 0.3 branch
[21:09] <magcius> Sarvatt, http://fedoraproject.org/wiki/Features/AutoFontsAndMimeInstaller
[21:09] <Sarvatt> speaking of which, are there any plans to package polkit-gobject alot of things are starting to need?
[21:10] <magcius> I would love to see PolicyKit be used instead of gksu/gksudo :(
[21:13] <ScottK> That's a goal for Ubuntu for Karmic
[21:13] <magcius> Are they going to provide patches to GNOME upstream or patch downstream?
[21:14] <magcius> How far along is Karmic right now?
[21:16] <evanrmurphy> magcius: Here's the Karmic release schedule: https://wiki.ubuntu.com/KarmicReleaseSchedule
[21:16] <ScottK> slangasek: Are you doing archive stuff today?
[21:17] <magcius> Also... would the broken hibernate be considered a papercut?
[21:25] <evanrmurphy> magcius: IMO hibernate would be nontrivial to fix, so I don't think it's a papercut. But it's certainly a serious bug.
[21:26] <magcius> evanrmurphy, do you know what the cause is?
[21:28] <magcius> Also... is Upstart still a dream or is there actually some concrete progress?
[21:29] <evanrmurphy> magcius: Unfortunately I'm not certain, but my impression is it has to do with the headaches of interfacing with hardware. Perhaps less-than-great drivers are a contributing factor... anyone else wanna chime in here?
[21:30] <magcius> evanrmurphy, supposedly people have fixed it with s2disk and s2ram
[21:35] <magcius> ScottK, #gnome says that GNOME has used PolicyKit for some time now (for the Administration menu items), and that Debian is patching it.
[21:36]  * ScottK is a KDE guy, so doesn't really keep track.
[21:43] <jpds> magcius: Yes, we use PolicyKit for some bits and pieces, don't know the details myself.
[21:43] <magcius> jpds, #gnome said that Debian was the one that did the integration with gksu/gksudo, and that GNOME has had a dependency on PolicyKit for some time now.
[23:02] <onexused> I see there are screenshots for some programs in synaptic, but not all.  Where could I contribute screenshots for the programs that I use? (Is this the correct place to ask?)
[23:05] <mathiaz> kees: should a MIR for mysql-dfsg-5.1 be written in order to move 5.1 to main and 5.0 to universe?
[23:10] <kees> mathiaz: yes, with coverage of why we're using 5.1 instead of maria, to maybe?
[23:11] <mathiaz> kees: you mean mariadb?
[23:11] <mathiaz> kees: AFAICT there isn't mariadb package available
[23:12] <kees> mathiaz: ah, dang.  should poke mneptok about it
[23:12] <ajmitch> how mature is that now?
[23:12] <kees> no idea
[23:13] <ajmitch> website says a release of mariadb 5.1 in august, at least
[23:13] <mathiaz> ajmitch: right
[23:13] <kees> *snore*
[23:14] <mathiaz> ajmitch: maria is basically the maria storage engine with some community patches that have been around for some time and that haven't been integrated in mysql yet
[23:15] <mathiaz> ajmitch: some of the community patches are probably the ones from percona
[23:15] <mathiaz> ajmitch: the thing is that I haven't seen any debian packages
[23:15] <ajmitch> probably because the debian mysql maintainer has been fairly overloaded
[23:16] <mathiaz> ajmitch: yeah - totally - norbert is doing an amazing job as he is the only one actively maintaining mysql packages
[23:16] <mathiaz> ajmitch: 5.1 is available from experimental
[23:17] <ajmitch> yeah, I've got it installed here on a sid install
[23:17] <mathiaz> and I think we should move 5.1 to main for the next LTS
[23:17] <ajmitch> since we use mysql a lot at work
[23:17] <mathiaz> otherwise kees is going to cry for the next 5 years
[23:17] <mathiaz> ajmitch: are you using 5.0 or 5.1?
[23:18] <ajmitch> 5.0 for production, on lenny at the moment
[23:19] <mathiaz> kees: should I write up a MIR for 5.1 before uploading the new 5.1 package that will do the switch to the archive?
[23:24] <mrooney> pitti: if an mp3 player is missing from the hal list of audio devices, should a bug go against hal or devicekit, or somewhere up stream?
[23:31] <ajmitch> mathiaz: I'll take a quick look at getting some mariadb packages working, I'd like to try it out & see how it goes
[23:32] <mathiaz> ajmitch: awesome - thanks.
[23:32] <mathiaz> ajmitch: once you get something working, let mneptok know about it
[23:32] <mathiaz> ajmitch: he should greatly appreciate it
[23:32] <directhex> NCommander, current issues: nothing worth noting. with the 2.4+dfsg-4 upload, we now include unit testing as part of the build, so we have an easy way to notice arch issues. older arches may contain bugs, but in the absence of test kit, hard for us as packagers to isolate
[23:33] <NCommander> directhex, yeah, I discovered for some reason my board didn't upgrade with dist-upgrade, so karmic is ok, but jaunty/mono is very very hosed
[23:36] <directhex> NCommander, hosed at what point - runtime? compile? app execution? etc
[23:40] <directhex> NCommander, best bet is to quiz vargaz on #mono on gimpnet - if anyone can think of specific commits relating to specific runtime problems, it's him
[23:42] <NCommander> directhex, runtime
[23:43] <NCommander> directhex, care to introduce me?
[23:48] <NCommander> directhex, he responded BTW