[12:19] <tkamppeter_> Mithrandir, cjwatson, thanks for the help on the cupsys package, I have put up an improved version on my web space now, biff
[01:57] <nrdb> I just heard that "update-modules" is depreciated, to reduce confusion, couldn't it be make a link or script that just runs depmod ? maybe with a message to use depmod instead.
[02:06] <sladen> nrdb: asdf
[07:52] <pitti> Good morning
[07:54] <ajmitch> hi pitti 
[07:59] <fabbione> so who is our compiz expert? :)
[08:00] <mneptok> fabbione: sudo aptitude remove ...
[08:00] <fabbione> mneptok: it's part of ubuntu-desktop now
[08:00] <fabbione> well it starts and it works somehow
[08:00] <fabbione> but i get no win decorations
[08:01] <fabbione> like the manager is not there
[08:01] <mneptok> please god let that not be in Main
[08:01] <ajmitch> mneptok: even better, it's on the cd
[08:01] <mneptok> i know.
[08:01] <fabbione> Filename: pool/main/c/compiz/compiz_0.3.6-1ubuntu7_all.deb
[08:01] <fabbione> mneptok: sorry :)
[08:01] <mneptok> no reason to apologize.
[08:02] <mneptok> if it's not removed from supported packages i'll just quit.
[08:03] <Hobbsee> mneptok: "you poor bastard"
[08:03] <fabbione> mneptok: people *NEED* bling
[08:04] <fabbione> mneptok: my son just made some strange noises when you started writing on IRC
[08:05] <mneptok> hehehhe
[08:05] <mneptok> he can detect the presence of an intellectual peer.
[08:05] <fabbione> mneptok: you bet  :)
[08:15] <Hobbsee> Mithrandir: finally some sense!
[08:15] <Hobbsee> jdong: you misquoted.  :P
[08:15] <jdong> Hobbsee: effin close enough
[08:16] <jdong> got the point across :)
[08:16] <Hobbsee> "i'd rather spend 5 minutes fixing a bug in feisty than two months fixing a bug in edgy"
[08:16] <Hobbsee> but yeah :)
[08:16] <jdong> :)
[08:16] <Hobbsee> you got it close enough that i recognised it :P
[08:16] <jdong> so I made it sound less severe :D
[08:16] <jdong> but the general gist is concerning nonehteless ;-)
[08:16] <Hobbsee> true
[08:16] <Hobbsee> in my opinion, stable releases are pretty much dead releases - no changing them :P
[08:17] <jdong> Hobbsee: I think it is true in practice but should not be that way :(
[08:49] <dholbach> good morning
[08:51] <_ion> ditto
[08:51] <dholbach> hi _ion
[08:53] <pitti> dholbach: yay, gthumb photo import mystery solved
[08:55] <dholbach> pitti: what was it?
[08:56] <pitti> dholbach: see bug 78756
[08:56] <Ubugtu> Malone bug 78756 in libgphoto2 "photo import does not work any more" [High,In progress]  https://launchpad.net/bugs/78756
[08:58] <dholbach> URG
[08:58] <dholbach> that wasn't really obvious
[09:02] <ajmitch> hm
[09:02] <ajmitch> since f-spot uses the same libs for importing
[09:02] <pitti> ajmitch: so it has the same problem?
[09:02] <ajmitch> no, I added libusb-dev to f-spot's build-deps :)
[09:03] <dholbach> pfffft :)
[09:03] <ajmitch> must have been awhile ago
[09:03] <dholbach> yay for photo import
[09:04] <dholbach> now if inserting my SD card doesn't crash the kernel anymore, I'll be real happy :)
[09:10] <pitti> carlos: hi
[09:10] <pitti> carlos: how are the imports?
[09:10] <carlos> we are still handling entries imported at the end of January...
[09:10] <carlos> danilo is profiling the process to see what's going on 
[09:11] <carlos> because it's being slow
[09:11] <pitti> doko: your rebuild-o-mania is finished now or shall I still wait with the Maintainer: stuff?
[10:11] <cjwatson> gpocentek,pitti: thunar-volman-plugin reprocessed now, thanks to cprov for fixing the code
[10:11] <cjwatson> should be in the archive shortly
[10:21] <cjwatson> StevenK: remaining cyrus-imapd-2.2 binaries should similarly be in the archive shortly
[10:23] <StevenK> cjwatson: Right, thanks very much.
[10:24] <Sp4rKy> please, must i update_initramfs when i change the casper scripts ?
[10:25] <lifeless> yes
[10:26] <Sp4rKy> ok
[10:30] <gpocentek> cjwatson, cprov-afk: thanks
[10:51] <seb128> Mithrandir: hi, could you give a retry to compiz-extra build?
[10:58] <Mithrandir> seb128: given-back
[10:58] <seb128> Mithrandir: thank you
[10:59] <ogra> cjwatson, i cant get console-setup to work on thin clients ... both init scripts are run, the configuration is correct (done with dpkg-reconfigure) but i dont get the right font or keymap on the console ... any tips ?
[10:59] <ogra> it works if i log in and run the initscript manually 
[10:59] <ogra> but not through init it seems
[11:01] <seb128> Mithrandir: compiz upstream is working on a 0.4 bug fixing version, gandalfn who works on the Ubuntu compiz made a pre-version package with a no-tfp patch which makes it work with fglrx for example, what do you think about updating? 
[11:01] <cjwatson> ogra: update-initramfs might fix it
[11:02] <cjwatson> ogra: (setupcon has to run before usplash starts)
[11:02] <seb128> Mithrandir: do you want an UVF request for it?
[11:02] <ogra> well, i see it getting set 
[11:02] <ogra> but its gone after usplash
[11:02] <ogra> directly after: Loading please wait ... the font switches ... then usplash kicks in
[11:03] <cjwatson> ok, I'm not sure then, sorry
[11:03] <ogra> hmm
[11:03] <ogra> does it need any writeable tings i have to aded to the tmpfs mounted files ?
[11:03] <ogra> *things
[11:03] <ogra> *add
[11:04] <ogra> (does it rewrite anything ?)
[11:05] <cjwatson> it's not meant to
[11:05] <cjwatson> setupcon --save will, but that's not run during the boot sequence
[11:06] <cjwatson> it does need to write to /etc/ while console-setup is being configured, of course
[11:06] <cjwatson> if you're seeing a font change during the initramfs, though, it's probably not thatt
[11:07] <cjwatson> almost sounds like it's changing the font back after usplash
[11:07] <ogra> yeah
[11:08] <cjwatson> compare /etc/default/console-setup and the various files in /etc/console-setup/ in and out of the initramfs, I guess
[11:08] <ogra> yup, wiul do
[11:08] <ogra> *will
[11:08] <cjwatson> I guess I should upload the console-setup work in progress I have - it doesn't really fix the problem I was trying to fix but it would make it easier to get somewhere with it
[11:10] <poningru> can someone help with a bug report?
[11:10] <poningru> https://bugs.launchpad.net/gnome-applets
[11:11] <poningru> http://bugzilla.gnome.org/show_bug.cgi?id=415242
[11:11] <Ubugtu> Gnome bug 415242 in gweather "Hazardous weather alerts" [Enhancement,Unconfirmed]  
[11:11] <poningru> want to file that bug in lp
[11:12] <dholbach> poningru: why?
[11:13] <poningru> dholbach: I shouldnt?... I was thinking just to keep a bug in lp.net as well
[11:13] <ogra> cjwatson, hmm, booting without splash fixes it ... 
[11:13] <dholbach> I didn't say you shouldn't. I just asked wanted to know if there's a special reason
[11:14] <ogra> its not changing back
[11:14] <poningru> dholbach: just because... /me likes lp.net > bgo
[11:15] <dholbach> poningru: well - there are 412k upstream bugs - we usually link bugs that 1) were reported in LP and then forwarded upstream or 2) were filed upstream and are really important to track for us
[11:16] <poningru> eek ok
[11:16] <dholbach> poningru: as it's "just" an enhancement bug, I personally wouldn't file it in LP - but you're free to do it of course
[11:16] <dholbach> poningru: http://launchpad.net/ubuntu/+source/gnome-applets/+filebug would be the appropriate URL
[11:17] <poningru> meh I will just work with the gnome people
[11:17] <poningru> thanks
[11:17] <dholbach> poningru: Why that?
[11:17] <poningru> http://bugzilla.gnome.org/attachment.cgi?id=84045&action=view btw
[11:17] <poningru> why what? just work with the gnome people?
[11:17] <dholbach> poningru: yes
[11:18] <poningru> I mean if they accept the code upstream it will trickle down to ubuntu so might as well contribute to gnome in general
[11:19] <giftnudel> I need a german translator for bug 60527, please
[11:19] <Ubugtu> Malone bug 60527 in language-pack-gnome-de "xchat-gnome /me misbehaviour" [Undecided,Confirmed]  https://launchpad.net/bugs/60527
[11:21] <dholbach> poningru: Yeah, it will - I just wasn't sure if you felt 'turned down' by my answer - I like the idea the bug suggests and appreciate work going on there, it's just that it doesn't make sense to track every upstream bug in LP -- if you want to have it in LP, I won't stop you though :)
[11:22] <poningru> hehe naah didnt feel turned down or anything
[11:22] <poningru> you just made sense
[11:22] <cjwatson> ogra: right, could well be the same thing I was trying to attack following a Turkish user's report; not finished yet
[11:22] <poningru> how dare you make sense
[11:22] <dholbach> poningru: I'll try to avoid it from now on ;-)
[11:23] <cjwatson> Kagou: do you have a reference (URL) to the list/blog/etc. discussion about fr-oss?
[11:23] <poningru> dholbach: good cause we have too much of that around here ;)
[11:37] <crimsun> mjg59: macbook/pro stuff pushed
[11:42] <Kagou> cjwatson: yes but in french ;)
[11:43] <Kagou> cjwatson: http://www.kagou.fr/post/2007/02/21/Clavier-sous-Ubuntu
[11:43] <Kagou> cjwatson: and https://lists.ubuntu.com/archives/ubuntu-fr-l10n/2007-February/001114.html
[11:53] <pitti> Mithrandir, seb128: could one of you please NEW restricted-manager? I don't want to approve my own pacakge
[11:53] <pitti> Mithrandir, seb128: doesn't need to happen immediately, but would be nice in the next two days or so
[11:54] <cjwatson> Kagou: ok, thanks; I'll take care of it
[11:54] <_ion> What is restricted-manager, btw?
[11:55] <Kagou> cjwatson: feel free to ask me more informations. I will try to answer you. Thanks
[12:07] <Mirv> _ion: I can guess it has something to do with easier selection of what non-free drivers or perhaps codecs to use/install
[12:08] <Mirv> _ion: https://launchpad.net/restricted-manager/
[12:08] <Mirv> just the restricted-component's drivers, that is
[12:13] <pitti> right
[12:14] <_ion> Ok. I take it it allows you e.g. to install and configure the proprietary nvidia/ati driver for use with xorg easily?
[12:14] <pitti> right
[12:14] <Mirv> pitti: just tested it, looks great. is "disable all" in plans, and would it basically give you a clean (as in freedom :) ) installation as far as main(+universe) in ubuntu is clean? currently I've restricted disabled on my desktop computer.
[12:15] <_ion> Nice
[12:15] <pitti> Mithrandir: if you don't have lrm installed, it should not list anything
[12:15] <pitti> erm, Mirv ^
[12:15] <pitti> Mithrandir: sorry, wrong nick completion
[12:16] <Mirv> pitti: yes, but on my laptop, and on any default installation? ie. is it somewhat similar to disable all there than what is it to disable the restricted component. does disabling everything there mean none of the restricted packages contents are used?
[12:16] <pitti> Mirv: yes, if you untick 'Allow' for everything, none will be used
[12:17] <pitti> however, they are still lurking on your disk, which might still be regarded as infestation :)
[12:17] <_ion> Someone who cares about that probably knows enough to purge the lrm package etc. :-)
[12:18] <Mirv> pitti: ok, just checking. but anyway, the tool looks great, and is educating the user in a right (and needed) manner.
[12:18] <Mirv> _ion: yes, indeed :)
[12:19] <Mirv> I do know this is not the really correct way to go :) - http://users.tkk.fi/~tajyrink/nouveau/
[12:19] <pitti> Mirv: why, what's wrong with nouveau?
[12:19] <Mirv> pitti: I mean, the message on the page
[12:19] <pitti> ah, heh :)
[12:20] <pitti> just opened it
[12:20] <pitti> sudo modprobe kitt ;)
[12:24] <_ion> /usr/bin/restricted-manager:44: DeprecationWarning: the module egg.trayicon is deprecated; equivalent functionality can now be found in pygtk 2.10
[12:26] <_ion> pitti: There's an "image not found" icon instead of the restricted-manager tray icon. I'm using the tangerine icon theme.
[12:26] <pitti> _ion: right, I know
[12:26] <pitti> _ion: do you use the current bzr head or where do you have the package from?
[12:27] <_ion> Yeah, bzr.
[12:27] <pitti> _ion: if you are interested in helping out with fixing some things or developing this further, I'd be really glad
[12:30] <doko> pitti: you're dreaming ;-) still 100, which I will do tomorrow and Thursday (ronne:~doko/libscan)
[12:30] <pitti> doko: alright
[01:00] <Mithrandir> seb128: new compiz> UVF request would be good.
[01:00] <seb128> Mithrandir: ok
[01:00] <Mithrandir> pitti: restricted-manager> I'll get to it, if seb doesn't beat me to it.
[01:01] <seb128> pitti: I'm busy with other things atm, feel free
[01:01] <pitti> seb128: ?
[01:02] <seb128> pitti: that was for Mithrandir
[01:09] <pitti> ogra: please kick hard enough to make esound fall out
[01:09] <ogra> heh, i'D love to
[01:09] <ogra> i wonder how it defines a smaple size ... i cant get the login/logound sound to play on ltsp ... 
[01:10] <mjg59> crimsun: Thanks!
[01:10] <ogra> esdplay and a click in the gui after login play them fine ... but on login pulse moans on the client "sample too large"
[01:11] <seb128> ogra: there is a new esound version to package, want to do the update?
[01:12] <ogra> not really
[01:12] <ogra> but if you need a hand i'll do it indeed
[01:12] <ogra> since i'm into pulse anyway
[01:17] <Mithrandir> pitti,seb128: did either of you source NEW compiz-extra and if so, why is it in main?
[01:17] <Mithrandir> I can't see an inclusion report for it
[01:17] <pitti> hm, can't remember NEWing it
[01:17] <pitti> but it's entirely possible that I did
[01:18] <seb128> Mithrandir: that was me and that looks like a mistake
[01:18] <seb128> sorry about that
[01:18] <Mithrandir> seb128: ok, thanks.  Just wondering.
[01:23] <asac> dholbach: if you have time, can you please look at http://pastebin.mozilla.org/4501 and tell me if the comment in line 19 is still valid?
[01:23] <asac> oh
[01:23] <asac> seb128: totem was yours, right? 
[01:24] <Mithrandir> pitti: r-m accepted.
[01:24] <bhale> seb128: you pinged?
[01:24] <pitti> Mithrandir: cheers
[01:24] <seb128> asac: yep
[01:24] <asac> can you look then?
[01:25] <asac> http://pastebin.mozilla.org/4501
[01:25] <asac> line 19
[01:25] <asac> NPPVpluginKeepLibraryInMemory is broken in mozilla :/ and contributes to lots of crashers we have
[01:28] <pitti> erk, why we still have tk8.3 in main?
[01:29] <StevenK> pitti: blt
[01:29] <Mithrandir> pitti: build-depends for blt.
[01:30] <pitti> erk, the binary has an |'ed dep to 8.4 | 8.3
[01:30] <StevenK> And BLT is just an extension library for TK, so why is it in main? :-)
[01:30] <pitti> StevenK: python-tk and python2.5-dbg rdepends
[01:30] <asac> seb128: afaik totem is run in a separate process ... so the question is if GObject is used at all by totem plugin in mozilla process.
[01:30] <StevenK> Ah
[01:32] <seb128> asac: I'm not sure, I don't really know a lot about the plugin, if you want to join #epiphany on irc.gnome.org chpe is upstream for epiphany and working on the totem plugin, he probably knows about that better
[01:32] <Mithrandir> and python2.[45] -dbg depends on blt.
[01:32] <asac> seb128: good
[01:32] <pitti> Mithrandir: right, but as I said, binary deps are not an issue, they are alternatives
[01:34] <pitti> doko: do you happen to know about blt? (You NMUed it in the past); can we easily drop the tk8.3 build dep?
[01:35] <doko> pitti: I used it for python-tk only, not using tk8.3 at all.
[01:37] <pitti> doko: it seems easy to do at first sight
[01:38] <doko> pitti: but we will have tcl8.3 still there (expect-tcl8.3 needs it on hppa)
[01:38] <pitti> argh
[01:38] <pitti> and we can't get rid of that?
[01:39] <pitti> hppa isn't even built any more
[01:39] <doko> probably not for feisty, but glibc starts looking better on hppa now
[01:43] <pitti> doko: hm, binutils and gcc-* depen on expect-tcl8.3 on all arches
[01:43] <pitti> so we could at least get rid of tk8.3
[01:43] <doko> pitti: yes, we can change that if you want
[01:44] <pitti> well, I don't want to start a new wave of significant work, it just looked like an easy target
[01:44] <mooey> bug 90093 is a duplicate of a bug somebody (seb128 i think) fixed recently, but i can't find the original report to mark it a duplicate of
[01:44] <Ubugtu> Malone bug 90093 in libxcb "GTK apps crashing via drag and drop" [Undecided,Unconfirmed]  https://launchpad.net/bugs/90093
[01:45] <seb128> mooey: it has not been fixed
[01:45] <seb128> mooey: bug #88608
[01:45] <Ubugtu> Malone bug 88608 in gtk+2.0 "[apport]  xchat crashed with SIGABRT in xcb_xlib_lock" [High,Confirmed]  https://launchpad.net/bugs/88608
[01:46] <mooey> thats the one, thanks seb128 
[01:46] <seb128> mooey: np
[01:47] <seb128> mooey: do you mark it dup now?
[01:47] <mooey> seb128, done
[01:47] <seb128> cool
[01:50] <doko> Mithrandir: could you reject my upload to dapper-backlports? wrong archive :-/
[01:51] <Mithrandir> doko: which upload?
[01:51] <doko> Mithrandir: java-gcj-compat
[01:51] <doko> ohh, it already was auto-rejected
[01:52] <Mithrandir> doko: ah, ok, good.  I got worried since I couldn't find it.
[01:55] <pitti> doko: is there a 'set -x' equivalent for Python?
[01:57] <Mithrandir> pitti: is it ok to promote thunar-volman-plugin now?  The binaries have been recovered.
[01:58] <pitti> Mithrandir: yes, it is
[01:58] <pitti> Mithrandir: I'll move the MIR to 'promoted' then
[01:58] <Mithrandir> pitti: I'll do it.
[01:59] <pitti> ah, you locked already
[02:17] <gpocentek> Mithrandir: thanks
[02:30] <pitti> seb128: did you happen to permanently install some packages into the retracer chroots? a lot of files are seb128:warthogs 755, so I cannot change them
[02:30] <seb128> pitti: no, I just used retrace-i386
[02:31] <seb128> pitti: I did ctrl-C one run though
[02:31] <pitti> seb128: ok, thanks; then there's another place that clobbers the umask
[02:31] <seb128> pitti: do you want me to fix those files?
[02:32] <pitti> seb128: well, either that (chmod -R g+w) or I just trash the entire chroot and rebuild it
[02:33] <pitti> seb128: I just don't understand why the files are there in the first place -- these packages are supposed to be unpacked and purged afterwards
[02:33] <seb128> pitti: as said before " pitti: I did ctrl-C one run though"
[02:33] <pitti> aah
[02:33] <pitti> this explains it
[02:33] <pitti> sorry, didn't see that
[02:34] <seb128> np
[02:34] <mooey> pitti, was the patch attached to bug ever uploaded (i dont know how to check)? i got the same bug when updating asterisk this morning
[02:34] <pitti> maybe I should just switch to tarballs and unpack them; shouldn't take too long
[02:34] <mooey> erk, bug 55374 * 
[02:34] <Ubugtu> Malone bug 55374 in asterisk "upgrade issue with configured asterisk" [Undecided,Fix released]  https://launchpad.net/bugs/55374
[02:34] <seb128> sould I just clean apport-retracer-i386/chroots/feisty/var/cache/apt/archives ?
[02:34] <pitti> mooey: I don't know, I didn't touch asterisk
[02:34] <pitti> seb128: no, please just chmod -R g+w the entire chroot
[02:35] <mooey> pitti, the last comment was by yourself. thanks anyway.
[02:35] <pitti> mooey: oh, I see; let me look; but as I said, I never uploaded asterisk
[02:35] <seb128> pitti: done
[02:35] <pitti> seb128: cheers
[02:37] <pitti> mooey: no, it wasn't uploaded; complain to Fujitsu about wrongly closing the bug
[02:37] <pitti> mooey: please reopen again
[02:37] <mooey> pitti, will do, thanks
[02:53] <jdong> pitti: it would be great if restricted-manager can AddARGBGLXVisuals too for nvidia cards
[02:54] <jdong> (non-legacy, that is)
[02:54] <pitti> seb128: I know the reason for the 404's during retracing -- I need to setup a cronjob that apt-get update/dist-upgrades the chroots daily
[02:54] <jdong> otherwise 3D effects would not work out of the box.
[02:54] <seb128> pitti: ah ok
[02:55] <jdong> pitti: it's just 'Option "AddARGBFlxVisuals" "True"' in the Screen section of xorg.conf
[02:55] <pitti> jdong: indeed; ubuntu-bug -p restricted-manager ?
[02:55] <jdong> okie :)
[02:55] <pitti> seb128: ok, chroot cleaned from the ^Ced run
[02:56] <jdong> pitti: that is sweet, I didn't know ubuntu-bug existed :D
[02:56] <seb128> pitti: cool, sorry again for the extra work
[02:56] <pitti> seb128: no problem
[02:59] <pitti> seb128: 'k, chroot update cronjobs set up
[03:03] <pitti> seb128: voila, bug 88508 retraces nicely now; unfortunately I didn't save the output
[03:03] <Ubugtu> Malone bug 88508 in gnome-utils "System Log Viewer copies the wrong line when filter is applied (dup-of: 47134)" [Low,Rejected]  https://launchpad.net/bugs/88508
[03:03] <Ubugtu> Malone bug 47134 in gnome-utils "log text copy fails while filter engages" [Medium,Confirmed]  https://launchpad.net/bugs/47134
[03:03] <pitti> seb128: erm, sorry, bug 88058
[03:03] <Ubugtu> Malone bug 88058 in rhythmbox "[apport]  rhythmbox crash in metadata_cb" [Medium,Confirmed]  https://launchpad.net/bugs/88058
[03:04] <seb128> pitti: no need, I retrace it on my desktop this morning ;)
[03:04] <gnomefreak> pitti: via bug 89916 the -u stops the 2 errors/warnings from apport but i get a non useful Stack. im gonna try in chroot after i update it and report back on bug. Thank you :)
[03:04] <Ubugtu> Malone bug 89916 in apport "[Feisty] apport-retrace fails to retrace bugs." [Low,In progress]  https://launchpad.net/bugs/89916
[03:04] <pitti> seb128: I think I leave the exception as it is then, since it indicates problems better than just a warning
[03:05] <seb128> pitti: do you know what lib or program prints the "** (gnome-cups-add:18745): WARNING **: IPP request failed with status 1028"?
[03:05] <seb128> pitti: ok
[03:05] <pitti> seb128: gnome-cups-icon, I'd say
[03:05] <seb128> pitti: no, I'm trying to add a printer with gnome-cups-manager and it doesn't work, I'm trying to figure on what to put a breakpoint
[03:06] <seb128> I would like to have a look on the URI it gives to cups
[03:06] <seb128> looks like libgnomecups
[03:07] <pitti> gnomefreak: hm, useless stackis usually (a) missing ddeb packages (check the warnings), or (b) outdated package versions (also check the warnings)
[03:08] <gnomefreak> pitti: im going to, but for some reason they were working fine for a while than they stopped working so i will fiddle around with it until i can come up with something useful. 
[03:09] <pitti> gnomefreak: right, as I said, feisty's package versions might be newer now, so that the libs don't match any more
[03:09] <gnomefreak> yeah i agree with that but it also seems im missing .so files (assuming they are the  -dev packages as normal)
[03:10] <pitti> the .so files in -dev are usually just symlinks
[03:10] <gnomefreak> s/are the/ are in the
[03:10] <gnomefreak> ah
[03:15] <Mithrandir> Riddell: re digikam> is upstream aware that jpeg 2k is patent encumbered and therefore problematic?
[03:16] <Riddell> Mithrandir: I expect not
[03:18] <Riddell> Mithrandir: but libjasper is already in main and depended upon by various things
[03:19] <Mithrandir> Riddell: ugh.
[03:20] <Mithrandir> pitti: ^^ ; any thoughts about this?
[03:24] <pitti> Mithrandir: off the top of my head just 'OMG'
[03:24] <pitti> Mithrandir: the question is whether it's an enforced patent or not, really
[03:24] <Mithrandir> pitti: that's a good initial thought. :-)
[03:25] <pitti> Riddell: is it on the Kubuntu CDs?
[03:25] <doko> heno, dholbach: were the impress template documents updated for feisty?
[03:25] <Mithrandir> pitti: it's on both kubuntu and ubuntu cds, it seems.
[03:25] <Mithrandir> http://en.wikipedia.org/wiki/JPEG2000 has a section about the legal issues.
[03:25] <Riddell> pitti: libmagick and kdelibs seem to rdepend on it so yes
[03:26] <dholbach> doko: no
[03:26] <heno> doko: no, do they need to be?
[03:26] <doko> heno, dholbach: no, just asking before an OOo upload
[03:27] <heno> ok
[03:27] <Sp4rKy> some gfxboot specialit here ?
[03:27] <Sp4rKy> i don't understand how change the font color in the menu 
[03:30] <cjwatson> Sp4rKy: GFXBOOT-BACKGROUND keyword in isolinux.cfg (and GFXBOOT-FOREGROUND for the highlighted text colour)
[03:30] <Mithrandir> Riddell: libjasper-support is possible to turn off?  If so, I don't see a problem with keeping it for now and we'll have to work out the legal implications a bit later (since we're already shipping it..)
[03:30] <Sp4rKy> cjwatson: ohhh, great !
[03:30] <cjwatson> Sp4rKy: e.g. 'GFXBOOT-BACKGROUND 0xB6875A' for Ubuntu
[03:30] <Riddell> Mithrandir: sure, it's just a compile time option
[03:31] <Sp4rKy> i'd seen that but i didn't think it is whati'm looking for :)
[03:31] <Mithrandir> Riddell: ok, thanks
[03:31] <cjwatson> the naming's not the best, sorry about that
[03:34] <doko> Mithrandir, pitti, seb128: I will uploads ooo-l10n first, which will land in binary NEW (please keep it there), then upload ooo, which will land in binary NEW (please keep it there until i386, amd64 and powerpc are built)
[03:34] <pitti> doko: ack
[03:36] <cjwatson> mvo: I fixed up the dist-upgrader-all stuff by hand (e.g. the current symlink); it'll be in the next archive push
[03:36] <cjwatson> 12:04 <cjwatson> the lack of a current symlink is because the versioning changed - he used an epoch
[03:36] <cjwatson> 12:04 <cjwatson> but the epoch isn't in the directory name because that breaks stuff
[03:36] <cjwatson> 12:04 <cjwatson> so the sorting code in dist_upgrader.py doesn't know where to put the current symlink
[03:36] <cjwatson> 12:05 <cjwatson> TBH I'd be inclined to just remove the dist-upgrader directories that used the old versioning scheme, do a one-time fix of the current symlink, and then it'll work fine from then on
[03:36] <cjwatson> so I did that
[03:37] <mvo> cjwatson: I suspected that the versioning change caused the trouble. thanks a lot for resolving it!
[03:52] <bddebian> Heya
[03:58] <Sp4rKy> heya bddebian 
[03:59] <bddebian> Hi Sp4rKy
[03:59] <Sp4rKy> so, i've a last issue with casper. in the 14locales file, when i do 
[03:59] <Sp4rKy> chroot /root /usr/bin/touch foo
[03:59] <Sp4rKy> the file foo is created
[03:59] <Sp4rKy> but if i do 
[03:59] <Sp4rKy> chroot /root /bin/echo "abcd" > foo
[04:00] <Sp4rKy> nothing is printed in the file foo
[04:00] <Sp4rKy> is there some special syntax ?
[04:04] <lemsx1> Sp4rKy: redirecting output happens at the terminal
[04:04] <lemsx1> Sp4rKy: try: chroot /root "echo 'hello' > foo "
[04:05] <lemsx1> brb
[04:10] <cjwatson> or chroot /root /bin/echo "abcd" > /root/foo
[04:10] <doko> Mithrandir: could you move the openoffice.org-l10n build to palmer, if I upload it?
[04:15] <cjwatson> Riddell: there are a bunch of bugs being filed on debconf which seem to be crashes in the KDE frontend - libqt-perl or libsmokeqt1
[04:15] <cjwatson> Riddell: I've been reassigning them to libqt-perl so far
[04:18] <Riddell> cjwatson: mm, ok
[04:42] <dholbach> ogra: new dia
[04:44] <_ion> https://code.launchpad.net/~ion/+branch/restricted-manager/ion in case anyone's interested.
[04:46] <dholbach> gpocentek: new gnumeric/goffice :)
[04:47] <siretart> is http://people.ubuntu.com/~pitti/ddebs/ still the source of choice for ddebs?
[04:49] <dholbach> siretart: yes
[04:55] <iwj> Dammit, now we've lost Rodrigo there's even less chance that anyone will be able to fix bug 68440 for me.
[04:55] <Ubugtu> Malone bug 68440 in xorg "X does not work in Xen, causes crash" [Undecided,Unconfirmed]  https://launchpad.net/bugs/68440
[04:58] <siretart> dholbach: too bad that it doesn't contain ddebs 'old' / superseeded packages :(
[04:59] <dholbach> siretart: it's (n+1)G big already
[04:59] <dholbach> but yeah, it'd be nice to have - or to have them auto-retraced - where works are underway
[05:05] <seb128> siretart: https://beta.launchpad.net/ubuntu/+source/apport/+bug/90135 doesn't look like a bug
[05:05] <Ubugtu> Malone bug 90135 in apport "unusable backtraces for xine-lib" [Undecided,Unconfirmed]  
[05:09] <seb128> siretart: did you install a libxine-extracodecs debug package and retraced on edgy with totem-xine installed?
[05:09] <seb128> siretart: 
[05:09] <seb128> #0  0xb16a41b5 in ifilter_bank () from /usr/lib/xine/plugins/1.1.2/xineplug_decode_faad.so
[05:09] <seb128> No symbol table info available.
[05:09] <seb128> #1  0x000003ff in ?? ()
[05:09] <seb128> 
[05:10] <seb128> that's retracing without the debug package for libxine-extracodecs
[05:14] <siretart> seb128: I think that the xine packaging is just borked, I'd rather like to know how to fix it
[05:14] <siretart> seb128: hm. let's try that in a edgy chroot
[05:14] <seb128> siretart: how borked?
[05:14] <seb128> siretart: non debug packages are useless you mean?
[05:14] <seb128> I pinged you about that some months ago IIRC
[05:15] <siretart> oh, so much time? damn :(
[05:15] <siretart> seb128: do you think it would help if we stop generating the -dbg package?
[05:16] <siretart> oh. some other point: retracing i386 crashes on  amd64 doesn't seem to be a too bright idea, no?
[05:16] <seb128> no it's not
[05:16] <seb128> you need to retrace on the same arch with the same package versions
[05:16] <seb128> if you try on an another arch gdb should complain about the dump format
[05:16] <siretart> hm. apport should at least warn on that
[05:16] <siretart> at least, it would be nice
[05:17] <seb128> apport feisty got a lot of love, it probably does already ;)
[05:17] <siretart> this was on feisty :/
[05:18] <seb128> open a wishlist then, pitti is amazingly fast to fix bugs ;)
[05:20] <dholbach> heno: do you know why a wiki change mail (DebuggingMemoryLeaks) was sent to ubuntu-bugsquad@lists.ubuntu.com?
[05:22] <heno> dholbach: no, was it meant to go elsewhere? Has someone signed up as a wiki user with that email and subscribed to the page?
[05:23] <heno> I guess you've noticed that I'm refactoring a bunch of pages :)
[05:23] <dholbach> heno: yes I did :-))))
[05:23] <dholbach> heno: no idea about why the list got that mail - I'll reject it from the queue
[05:23] <heno> as you seem to have subscribed to the entire wiki ...
[05:30] <doko> cjwatson, fabbione: the sched_setaffinity stuff seems to work on sparc, currenly no ildc hang on faure with the smp kernel
[05:36] <cjwatson> doko: neat
[05:47] <iwj> tepsipakki: Ah, nice to see you taking an interest in my Xen X bug, thanks.  Indeed, the logs are very similar.  ISTR someone speculating about memory layout.
[05:52] <alex-weej> trying to troubleshoot this bug
[05:52] <alex-weej> https://launchpad.net/ubuntu/+source/linux-source-2.6.20/+bug/78288
[05:52] <Ubugtu> Malone bug 78288 in linux-source-2.6.20 "kernel 2.6.20-5 doesn't boot with sata-hd" [Medium,Confirmed]  
[05:53] <alex-weej> what's the safest way for me to test a vanilla kernel in ubuntu
[05:53] <alex-weej> rather than installing fedora, like Martin suggested
[06:08] <seb128> siretart: http://bugzilla.gnome.org/show_bug.cgi?id=415326
[06:08] <Ubugtu> Gnome bug 415326 in general "Totem crash in LIRC code" [Normal,Resolved: fixed]  
[06:08] <seb128> siretart: https://beta.launchpad.net/ubuntu/+source/xine-lib/+bug/76566 rather
[06:08] <Ubugtu> Malone bug 76566 in xine-lib "Totem crash" [Undecided,Unconfirmed]  
[06:08] <seb128> siretart: retrace on edgy with dbg package, worked fine
[06:13] <siretart> seb128: k. will try. I have problems with accessing my chroots due to bug #38409
[06:13] <Ubugtu> Malone bug 38409 in lvm2 "creation of snapshots fails unpredictably" [High,Confirmed]  https://launchpad.net/bugs/38409
[06:13] <seb128> siretart: I've updated the bug with the debug retrace
[06:14] <siretart> still no debug symbols in /usr/lib/xine/plugins/1.1.2/xineplug_decode_faad.so :/
[06:15] <siretart> hm. which filtbank.c:309 is this?
[06:15] <siretart> seb128: oaky, this is more like homework for me
[06:16] <siretart> seb128: thanks for digging this out, I'll continue later on this
[06:16] <siretart> seb128: btw, is it recommended to join the launchpad beta group? i notice you throw around these 'beta' urls ;)
[06:16] <seb128> siretart: 309                 time_out[nflat_ls+nshort+i]  = overlap[nflat_ls+nshort+i]  + transf_buf[nflat_ls+nshort+i] ;
[06:18] <siretart> however, there is no filtbank.c in xine sources
[06:18] <siretart> I *think* it is in the faad sources
[06:18] <seb128> it's libxine-extracodec
[06:19] <siretart> argl, right. in edgy it was split
[06:21] <Ubugtu> Malone bug 90161 in xen-source-2.6.17 "dom0 oops crash on xm restore when memory is short" [Undecided,Unconfirmed]  https://launchpad.net/bugs/90161
[06:22] <siretart> iwj: is the lvm/mdadm/udev integration still on your radar?
[06:23] <iwj> siretart: Err, yes, although I'm not wholly clear on what everyone's symptoms are.
[06:25] <_ion> summon pitti
[06:27] <iwj> siretart: Do you have any symptoms or stuff you wanted to particularly get my input on or wanted me to do something about ?
[06:29] <siretart> iwj: I've now disabled boot and enabled verbose output, and now the boot succeeds in 2/3 of my attempts :/
[06:29] <siretart> and it always succeeds when I try to gain some debug info :/
[06:30] <siretart> iwj: wouldn't be offering some way to disable this 'full async udev boot' feature an acceptable workaround for such setups in feisty?
[06:31] <iwj> siretart: disable option> Yes, that would be good but unfortunately it's not exactly clear what that would mean.  Our previous arrangements had races that affected some random other set of people.
[06:32] <iwj> Have you got a failed boot when you got verbose output ?
[06:32] <iwj> siretart: If you have something failing 1/3 of the time then I'm definitely keen on using you as a test case.
[06:32] <iwj> WDYM `try to gain some debug info' ?
[06:33] <iwj> Sorry to bombard you with questions :-).
[06:44] <siretart> iwj: you told me to start udev 'by hand' with --debug info and redirecting it to a file, in order to see what udev does
[06:44] <siretart> iwj: each time when I do that, the system boots perfectly
[06:47] <siretart> k, need to go home -cu
[07:00] <Riddell> pitti: are you able to process my edgy-proposed dist-upgrade packages sometime?
[07:03] <iwj> siretart: Thanks.  Hmm.  Oh, damn.
[07:11] <pitti> Riddell: oh, did you upload them now?
[07:11] <pitti> Riddell: sure, I can process them
[07:16] <geser> pitti: is php4 still scheduled for removal?
[07:16] <pitti> geser: yes, of course, I just wanted to give our MOTUs some time to change some packages
[07:17] <nutmeg> Could somebody point me to the cause of "libksba (1.0.0-1build1) feisty; urgency=low   * Rebuild for changes in the amd64 toolchain."? At least the complete gnutls toolchain has been rebuilt and I just wonder why.
[07:29] <pitti> wow, codebrowse.launchpad.net - something new every day
[07:32] <jdong> hey cool tubgirl.launchpad.net!
[07:32] <jdong> (kidding)
[07:34] <kylem> very cool
[07:39] <jdong> doens't do anything for me...
[07:39] <pitti> jdong: tubgirl? hardly :)
[07:39] <jdong> pitti: LOL that's not what I meant :P
[07:39] <pitti> jdong: e. g. http://codebrowse.launchpad.net/~ubuntu-core-dev/apport/ubuntu
[07:39] <jdong> OH
[07:39] <jdong> OH WOW
[07:39] <jdong> it's loggerhead!
[07:39] <jdong> sweet
[07:39] <pitti> bzr - the WOW effect!!!
[07:40] <jdong> the WOW starts here!
[07:40] <pitti> right, I didn't quite remember the slogan
[07:41] <jdong> it's kind of good that you don't :)
[07:41] <jdong> I envy you.
[07:46] <jdong> well... brings whole new meaning to distributed weaves and knits.
[07:46] <jdong> ok wow that was awful :D
[07:48] <psusi> is there someone who can finally backport this important breakage fix that has been waiting for months?  https://bugs.launchpad.net/ubuntu/+source/dmraid/+bug/68294
[07:48] <Ubugtu> Malone bug 68294 in dmraid "Please backport dmraid to edgy - works in feisty" [Medium,Confirmed]  
[07:50] <geser> keescook: are you working on new packages for gnupg (new version 1.4.7) and gnupg2 (new version 2.0.3)?
[07:51] <Mithrandir> psusi: that should be done as an SRU, not a backport.  We're going to discuss changes in the backport policy for universe in about an hour.
[07:51] <psusi> Kronuz: and this is the file: ohh....
[07:52] <keescook> geser: I wasn't planning to yet; the "security vulnerability" described as fixed is a debatable issue.
[07:52] <pitti> hey keescook 
[07:52] <psusi> bah... just ohh ;)
[07:52] <keescook> hiya pitti!  :)
[07:54] <geser> keescook: so it isn't worth fixing? I haven't read the announcement yet completely
[07:54] <keescook> pitti: I haven't been following too closely, but did you prep an update to tzdata for the upcoming US DST change?
[07:55] <pitti> keescook: that has been done one or two months ago already
[07:55] <pitti> keescook: the currently pending SRU is for 2007b which also changes some DST rules, but only in very small places (not US)
[07:55] <keescook> geser: the issue is that on-terminal --verify's can be tricked, but this is always true due to embedded terminal emulation, etc.
[07:55] <jdong> pitti: is that going to be done for Breezy too?
[07:55] <jdong> pitti: had a person ask me about that yesterday
[07:56] <pitti> jdong: breezy is really really tricky, because it requires a new glibc
[07:56] <jdong> pitti: what a luckily timed EOL then :)
[07:56] <jdong> but surely there's a way to do it, right?
[07:56] <geser> Mithrandir: please give-back xulrunner on powerpc, ia64 and i386. thanks
[07:57] <pitti> jdong: there is, sure
[08:33] <pitti> mvo, seb128_: I'd be eternally thankful to you if you could write some hints how to GUI-install a package to bug 90205
[08:33] <Ubugtu> Malone bug 90205 in restricted-manager "enabling nvidia needs to check for nvidia-glx" [Undecided,In progress]  https://launchpad.net/bugs/90205
[08:34] <seb128_> pitti: we really need a lib for that
[08:34] <pitti> I just thought that codec-install etc. use the same functionality
[08:35] <pitti> seb128_: ah, it's more than just calling synaptics with a few command line args?
[08:36] <Mithrandir> geser: given-back
[08:37] <seb128_> pitti: it's pretty much calling synaptic, every app do the wrapping, UI dialogs needed for it, etc though
[08:37] <seb128_> pitti: would be nice to have a lib rather than copying the code
[08:37] <pitti> seb128_: ugh, special UI code needed? indeed
[08:38] <seb128_> well, would be nice to have a dialog saying what it's going to do and why
[08:38] <seb128_> same for codec installation
[08:39] <ajmitch> morning
[08:39] <seb128_> hi ajmitch
[08:42] <mvo> pitti: is r-m written in python?
[08:43] <pitti> mvo: yes
[08:46] <mvo> pitti: I updated the bug with the commandline options
[08:47] <pitti> mvo: thank you!
[09:03] <doko> its done
[09:07] <mdke> pitti: any news on how binary drivers will be installable in feisty? String freeze is in two days so I'd like to get something into the documentation
[09:42] <pitti> mdke: apt-get install restricted-manager
[09:42] <pitti> mdke: I think this has a good chance of becoming part of the default install
[09:42] <mdke> pitti: when will we know?
[09:42] <pitti> mdke: and it should more or less look like the final version
[09:42] <pitti> mdke: that's something that Keybuk and mdz have to decide, but I'm quite positive
[09:43] <mdke> did it go into the archive already? haven't got it here
[09:43] <pitti> yes, today
[09:43] <mdke> ah, i'll update
[09:43] <pitti> pro'ly not yet on the mirrors
[09:43] <pitti> but on archive.u.c.
[09:43] <mdke> I use that one
[09:43] <mdke> mdz: any idea on timescale for knowing whether restricted-extras will be shipped by default?
[09:44] <mdz> mdke: I don't follow.  by definition, it's not installed by default, and it's been available in the repositories for ages now
[09:44] <mdke> mdz: I beg your pardon
[09:44] <mdz> mdke: oh, you're talking about restricted-manager, not -extras
[09:44] <mdke> mdz: restricted-manager
[09:45] <mdke> :)
[09:45] <mdz> it's intended that it be installed by default, yes
[09:45] <mdke> great, that's perfect
[09:46] <mdke> we'll try and document it asap
[09:47] <pitti> mdke: great, thanks
[09:47] <mdke> pitti: does it do ati?
[09:50] <pitti> mdke: enabling and disabling the module, but I think it doesn't modify x.org yet
[09:50] <pitti> mdke: xorg.conf, that is
[09:50] <mdke> pitti: ok. I don't see ati in the list...
[09:50] <pitti> mdke: it's certainly supposed to, I just need to find someone to give me the instructions what to change in a bug report
[09:50] <pitti> mdke: odd, I have it
[09:51] <pitti> 'ATI Fire GL'
[09:51] <mdke> oh, I have ATI Fire GL, is that all ATI cards?
[09:51] <pitti> yes, the driver is called fglrx (fire gl)
[09:51] <mdke> oh, right
[09:51] <mdke> is it intended to continue to distinguish between legacy and non-legacy nvidia cards?
[09:52] <mdke> or will it do that for the user automatically?
[09:53] <pitti> mdke: hm, not sure actually
[09:53] <mdke> ok, we can proceed on the basis that it won't, and remove things as relevant if that feature is added
[09:54] <pitti> mdke: ah, no, because nvidia-glx and n-g-legacy Conflict: to each other
[09:54] <pitti> mdke: so you can only have one package installed
[09:54] <mdke> yes
[09:54] <mdke> but that doesn't stop you magically telling the user which one they need
[09:54] <mdke> most users are familiar with the difference
[09:54] <mdke> *not
[10:00] <mdke_> pitti: sorry, may have missed any response; pinged out
[10:01] <pitti> mdke_: I didn't answer yet (I'm not actually here any more, sorry)
[10:01] <mdke_> ok, thanks for your help
[10:01] <pitti> mdke_: right, I'll chat about this with people who know
[10:02] <siretart> Mithrandir: I just notice that you unsubscribed bug #64501 from ubuntu-archive
[10:02] <Ubugtu> Malone bug 64501 in openhackware "FTBFS" [Critical,Confirmed]  https://launchpad.net/bugs/64501
[10:02] <siretart> Mithrandir: the problem seems to be that the package only builds on ppc
[10:03] <siretart> Mithrandir: and binary:all packages are built on i386 only in ubuntu
[10:03] <Mithrandir> siretart: how is that something ubuntu-archive can change?
[10:03] <siretart> Mithrandir: I'm seeking for input on how to solve this issue
[10:04] <Mithrandir> siretart: fix CFLAGS to not include -mregnames?
[10:04] <siretart> which breaks compilation
[10:04] <Mithrandir> uh?
[10:05] <siretart> it needs an ppc assembler
[10:05] <siretart> cross compilation would be an option, but nobody is working on that. in debian, the problem doesn't exist
[10:05] <siretart> since binary uploads are possible there
[10:06] <Mithrandir> at least for now, yes.  *shrug*; it needs to be fixed to cross-compile in Ubuntu or something then.
[10:07] <siretart> err, we are talking about firmware, which qemu needs to boot emulated ppc systems
[10:07] <siretart> requiring the firmware to be cross compiled seems a bit awkward to me :/
[10:08] <siretart> hm. I could perhaps compile it on ppc, include it uuencoded, and just unpack it in the package
[10:08] <siretart> but *that's* really nasty :/
[10:09] <sistpoty> siretart: yep, that's nasty, but I guess it's the best option... have been doing this for mit-scheme
[10:09] <Mithrandir> hm, indeed.
[10:09] <Mithrandir> siretart: you could talk to Adam about it and see if he can do a manual build on a ppc box.
[10:10] <siretart> Mithrandir: we could indeed upload ppc binaries to the archive?
[10:10] <siretart> hm. okay, I'll subscribe him then
[10:40] <alex-weej> is bug buddy supposed to work in Feisty?
[10:43] <seb128_> alex-weej: we use apport
[10:43] <alex-weej> seb128_: i.e. bug buddy is disabled?
[10:43] <seb128_> alex-weej: it's working if you use it, we don't call it though
[10:44] <alex-weej> only i've been having some gnome-panel crashes, and lots of random apps will just crash occasionally without me even noticing
[10:44] <alex-weej> it seems apport isn't always working :(
[10:44] <seb128_> alex-weej: you can activate the gconf key /apps/bug-buddy/run_on_crash
[10:44] <alex-weej> seb128_: is apport still supposed to catch all crashes? it even used to catch segfaults in CLI tools once upon a time
[10:44] <seb128_> alex-weej: maybe they don't crash, apport don't catch abort for example
[10:45] <seb128_> alex-weej: it crashes every SIGSEGV and that works fine on my desktop
[10:45] <alex-weej> seb128_: if i kill -SEGV `pidof gnome-panel`
[10:45] <seb128_> kill -11 application
[10:45] <alex-weej> panel crashes
[10:45] <alex-weej> but nothing happens
[10:45] <seb128_> what linux version are you running?
[10:45] <alex-weej> feisty
[10:45] <seb128_> no, linux
[10:45] <alex-weej> 2.6.20-something
[10:45] <alex-weej> sec :P
[10:45] <seb128_> official feisty package?
[10:45] <alex-weej> 9-generic
[10:45] <alex-weej> yep
[10:46] <seb128_> do you have anything to /var/log/apport.log ?
[10:46] <alex-weej> plenty in there
[10:46] <seb128_> anything about your panel crash?
[10:47] <alex-weej> seb128_: yep
[10:47] <alex-weej> it even says it's being called etc.
[10:47] <alex-weej> it just doesn't pop up
[10:47] <seb128_> does calling "ubuntu-bug gnome-panel" works fine?
[10:48] <alex-weej> seb128_: yes
[10:48] <seb128_> you want to ping pitti or open a bug then :p
[10:49] <seb128_> does it write reports on crash?
[10:51] <alex-weej> seb128_: yes it does
[10:51] <alex-weej> seb128_: i've tested this with gedit and it seems to work
[10:51] <alex-weej> do you have any idea where the data for "don't report this crash again" or whatever the tickbox reads is?
[10:51] <seb128_> .apport-ignore.xml
[10:51] <seb128_> to your user directory
[10:52] <alex-weej> seb128_: no file = no ticks?
[10:52] <seb128_> correct
[10:52] <alex-weej> ok
[10:52] <seb128_> there is also a 3 crashes limit
[10:52] <alex-weej> ah
[10:52] <alex-weej> maybe that's it, it has crashed naturally a lot
[10:52] <alex-weej> or would that be in .apport-ignore.xml, too?
[10:52] <seb128_> remove the crash file from /var/crash then
[10:53] <seb128_> no
[10:53] <seb128_> it's to the crash file itself
[10:53] <alex-weej> should i just clear out /var/crash?
[10:53] <seb128_> correct
[10:53] <seb128_> and try again then
[10:53] <alex-weej> seb128_: ok ta
[10:53] <seb128_> np
[10:53] <alex-weej> seb128_: works now
[10:53] <seb128_> cool
[10:54] <alex-weej> however, i wasn't signalling it artificially before
[10:54] <alex-weej> and the reports just stopped happening
[10:54] <alex-weej> i take it it's 3 crashes per app
[10:54] <seb128_> what do you mean?
[10:54] <alex-weej> and not per... crash
[10:54] <alex-weej> basically it has been crashing lots lately
[10:54] <seb128_> right
[10:54] <alex-weej> and sometimes i don't have the time to go in and report stuff right away
[10:54] <seb128_> that 3 crashes in a day or something
[10:54] <alex-weej> i just need to get on with my work or whatever
[10:55] <seb128_> otherwise people send 10 times the same crash :p
[10:55] <seb128_> it's not often that the app crashes 3 times in different ways the same day usually
[10:57] <Sp4rKy> why all the "echo ..."  command doesn't work in casper ?
[10:58] <Sp4rKy> ie : chroot /root echo ... > foo doesn't work
[10:59] <_ion> What's the error message?
[10:59] <Sp4rKy> nothinf
[10:59] <Sp4rKy> just no output
[10:59] <_ion> In that case, it probably works.
[10:59] <_ion> cat foo
[11:00] <Sp4rKy> the file isn't created
[11:46] <impl> Any PHP maints around?