[12:32] <pygi> seb128, well, and do some changes to packaging ofcourse so it would play nice with FF and other browsers
[12:33] <seb128> pygi: I think you will get an uvf easily for 0.5.2
[12:33] <pygi> seb128, indeed =)
[12:33] <pygi> but it has to be done today :P
[12:34] <pygi> (if I'm not wrong today is the last day for NEW packages)
[12:36] <pygi> asac, you still alive? :)
[12:37] <pygi> seb128, asac : ok, good night now :) Asac, I'll poke during the day, hopefully we can get something done :)
[01:01] <Kopfgeldjaeger> gn8
[02:14] <geser> mathiaz: Hi, are you going to merge fetchmail? the last Debian upload fixes CVE-2007-4565. I guess keescook would be happy.
[02:17] <mathiaz> geser: not in the immediate time. You wanna do it ?
[02:18] <geser> I will do it then.
[02:18] <ion_> Avahi 0.6.21: This is an important bugfix release.
[02:18] <mathiaz> geser: excellent! - Thanks.
[03:10] <bathym> some ubuntu official devel in security hand?
[03:10] <keescook> bathym: I think I want to say "yes".
[03:11] <LaserJock> heh
[03:12] <bathym> ^^
[03:12] <bathym> i search him :P
[03:13] <keescook> bathym: what's up?
[03:14] <ajmitch> keescook: are you sure you want to admit to that?
[03:14] <bathym> query, if it`s possible
[03:14] <keescook> bathym: go ahead and ask.  :)
[03:42] <bathym> Nafallo: ping
[04:34] <lifeless> bryce: if you are around, I have a question about CRT displays and laptops
[04:35] <bryce> lifeless, about to head to dinner actually, but can try to answer if it's a quickie
[04:35] <lifeless> ok.
[04:35] <lifeless> basically, fn-F8 doesn't seem to work in X on my dell d430
[04:36] <bryce> yup
[04:36] <lifeless> which has a 945
[04:36] <lifeless> is this likely to be fixed before release, or is there a test driver I can grab?
[04:36] <lifeless> I have a presentation to give tonight ;)
[04:37] <bryce> upstream marked it "won't fix" actually, so there's no fix available
[04:38] <bryce> mjg59 might be able to explain it better, but as I understand it the issue is that acpi is not passing along the key combo correctly
[04:43] <mjg59> Dells don't send acpi events for that
[04:43] <mjg59> There needs to be something in userspace listening for the correct key
[04:43] <lifeless> sadness
[04:44] <lifeless> is someone working on this? Is there anything trivial I can do other than subscribing to the bug (which # is it  ?)
[04:44] <bryce> lifeless: 'rez' in launchpad is the tester at dell who has reported many of these previously
[04:45] <bryce> same issue happens with dell + nvidia
[04:45] <lifeless> what would be lovely is if plugin the monitor, then it just works as xinerama or something
[04:45] <kylem> lifeless, just mash it manually with xrandr.
[04:45] <lifeless> but thats a different discussion
[04:46] <lifeless> kylem: oh lovely, 1.2 is here isn't it
[04:46] <kylem> if you're on 945.
[04:46] <bryce> lifeless: yeah I'm hoping for hungry hippo we can put some work into that
[04:47] <ajmitch> kylem: is there hope for us on older intel chips (i915)?
[04:47] <kylem> yes, just use -intel...
[04:48] <bryce> kylem: btw, did you get a chance to put the discover-data upload in?  I noticed I'd listed 'feisty' in the changelog and uploaded a fixed version
[04:48] <ajmitch> useful, no doubt it's better than last time I used it, when it broke compiz :)
[04:48] <kylem> not yet. was going to leave it until tomorrow. guess i can do it now.
[04:48] <bryce> no hurry
[04:48] <bryce> ok, getting called to dinner.  bbl
[04:55] <mjg59> bryce: We discussed this in London
[04:55] <mjg59> bryce: The solution is pretty straightforward, but it needs some code adding to gnome-settings-daemon
[04:58] <lifeless> kylem: thanks
[04:58] <kylem> no problemo.
[04:59] <lifeless> kylem: xrandr --auto is love
[04:59] <kylem> lifeless, lol.
[05:00] <lifeless> I like things that just work.
[05:00] <lifeless> :)
[05:24] <LongPointyStick> pkern_: it means you need to see !uvf, and file an exception for anything you want synced.
[05:24] <LongPointyStick> i *wish* kmos would stop giving out wrong information.
[05:25] <ajmitch> heh
[05:31] <ajmitch> what's he presenting?
[05:33] <RAOF> How to write fast python
[05:34] <ajmitch> interesting
[05:34] <RAOF> Indeed.
[05:35] <RAOF> Hence the 'looking forward to it' :)
[05:35] <ScottK> Step 1: Get someone other than ScottK to write it.
[05:35] <bddebian> haha
[05:37] <lifeless> huh
[06:21] <jml> RAOF: when/where's this presentation?
[06:21] <RAOF> jml: SLUG, this evening.
[06:22] <jml> RAOF: man I wish I could live in a city.
[06:24] <RAOF> Heh
[06:25] <ajmitch> hobart not enough of a city?
[06:26] <LaserJock> city? who wants a city?
[06:26] <ajmitch> jml: come on, I'm in dunedin :)
[06:27] <Amaranth> RAOF: record it
[06:36] <lifeless> jml: come to sydney then
[06:37] <lifeless> it will be recorded anyway I expect by the slug av folk
[06:37] <jml> lifeless: I'll look out for it.
[07:04] <sponix> can I gripe here ?
[07:05] <nixternal> nope
[07:06] <nixternal> this is a development channel, griping won't get you far around here
[07:07] <LaserJock> sponix: maybe a bug report might work?
[07:07] <sponix> apt-get install vsftpd <enter> "The following packages will be REMOVED:  gadmintools gproftpd proftpd proftpd-mysql proftpd-pgsql"
[07:07] <sponix> why can you have 5 flavors of web server installed, but only one ftp daemon flavor ?
[07:07] <sponix> is it against the law to run proftpd on 65534 and vsftpd on inet port 21 ?
[07:08] <LaserJock> sponix: must be the dependencies
[07:08] <sponix> vsftpd has _no_ deps
[07:09] <infinity> No, all ftp daemons conflict.
[07:09] <sponix> minus glibc
[07:09] <infinity> As do all MTAs.
[07:09] <infinity> Etc.
[07:09] <nixternal> yup
[07:09] <sponix> but now webservers ?
[07:09] <RAOF> No, for some reason.
[07:09] <sponix> s/now/not/
[07:09] <infinity> http daemons are the odd one out here, due to many requests to allow multiples (for things like using lighttpd to server static content and apache to serve dynamic)
[07:10] <infinity> s/server/serve/
[07:10] <sponix> how do I give it the "force-it-you-biatch" flag, to keep it from nuking my other pkg while installing ?
[07:10] <sponix> well, vsftpd for anon && proftpd for pr0n !
[07:10] <infinity> proftpd does anon quite well too...
[07:10] <infinity> And does vhosting...
[07:10] <RAOF> You'd pull the source package, remove the conflicts:, and rebuild.
[07:10] <infinity> Not sure why anyone would really want more.
[07:10] <sponix> infinity:  I know, but vsftpd is a bit lighter for that
[07:11] <infinity> But, yes, you could rebuild one of the source packages to not Provide and Conflict ftp-server.
[07:11] <infinity> sponix: If proftpd is already running anyway, I'm not sure what's heavy about having it bind to two ports and have it serve anon on one.
[07:11] <sponix> hmm, apt-get build-dep vsftpd ?
[07:11] <infinity> Seems heavier to run two daemons.
[07:11] <RAOF> apt-get source vsftpd
[07:12] <sponix> infinity:  because its not what I _want_ *Grin*... Thats what t3H LuNiX is all about, it does what I fsck'n want it to
[07:13] <sponix> I still wonder why aptitude exist in the first place
[07:13] <RAOF> Because it's your one-stop apt shop.
[07:13] <infinity> sponix: Ahh, but it only does exactly what you want if you build it yourself, really.
[07:13] <sponix> ls
[07:13] <sponix> ha.. oops :P
[07:14] <sponix> when I suck it down with that apt-get source vsftpd does it apply the patches, or do I need to do that ?
[07:14] <nixternal> you need to apply the patches
[07:14] <sponix> Duh, it says it .. never mind
[07:14] <RAOF> nixternal: What??
[07:14] <infinity> See, and I just realised which "not a support channel" channel we're in, too.
[07:15] <sponix> nixternal:  sorry... it says that it applied the diff
[07:15] <nixternal> oh, the diff..I was thinking debian/patches..sorry
[07:15] <sponix> infinity:  yeah... I appreciate the help, and I'm sorry to take away from devel for my petty prefs ;)
[07:16] <sponix> RAOF:  good idea... thanks for the help
[07:16] <RAOF> sponix: https://wiki.ubuntu.com/UbuntuPackagingGuide/BuildFromDebdiff?highlight=%28debdiff%29 minus the debdiff part should do.
[07:17] <infinity> sponix: apt-get install devscripts fakeroot ; apt-get source vsftpd ; apt-get build-dep vsftpd ; sed -i -e 's/ftp-server//g' vsftpd-*/debian/control; (cd vsftptd-* && dch -i && dpkg-buildpackage -rfakeroot -uc -us -b)
[07:17] <sponix> RAOF:  RTFM ! *Grin*
[07:17] <infinity> sponix: There.  Now we can stop talking about it.
[07:20] <sponix> infinity:  that was above and beyond the call of duty. Especially since you think I'm a tard for wanting multiples ... Thanks a ton though
[07:21] <infinity> sponix: Don't feel too bad, I think everyone's a "tard"... There's a reason they don't let me lurk in support channels.
[07:21] <beuno> the parameter could be called 'args' inside the method as it is in the
[07:21] <beuno> caller and have a better docstring.  I can fix that and merge it if
[07:21] <sponix> aye, how long as the Redhat cluster suite be in the repos ?
[07:21] <beuno> er, wrong window  :D
[07:22] <infinity> sponix: Since before dapper.
[07:22] <sponix> just noticed it yesterday
[07:22] <StevenK> infinity: libnss-db!
[07:22] <sponix> Now if they just port the AD && coolkey stuff I'll be all set
[07:25] <infinity> StevenK: Never heard of it.
[07:27] <StevenK> infinity: Hmph
[07:28] <infinity> StevenK: I'll clear that off my TODO tonight.
[07:29] <infinity> StevenK: I've got a lull in OMG URGENT stuff, finally.
[07:30] <StevenK> infinity: *nods* Just want a "Okay, looks fine." or a "Uh, this is broken." and I'll fix it or upload it.
[07:32] <Chipzz> infinity: actually, devscripts is (knowingly) missing a dependency on some perl package for dch to work properly (as an aside ;))
[07:40] <YokoZar_> Which is correct for a control file:  libncurses5-dev | libncurses-dev [i386]   or  libncurses5-dev [i386]  | libncurses-dev [i386]   -- I want neither on non i386
[07:42] <infinity> YokoZar_: The latter.
[07:42] <YokoZar_> infinity: thanks
[09:04] <siretart> iwj: sure. btw, the comment in the 2nd hunk of debian/rules is a bit confusing. The cryptsetup binary isn't statically linked, is it?
[09:08] <Tonio_> hi
[09:13] <soren> noah__: Thank you very much!
[10:01] <TomaszD> does anyone know why the translations for xdg-user-dirs are not picked up at all?
[10:10] <pkern_> LongPointyStick: I thought uvf is for new upstream revisions and not Debian revisions?
[10:29] <asisak> ArneGoetje: I was told you might help me to handle bug 119588. It is not pressing at all, but I look for someone who can take care of this eventually.
[10:29] <ubotu> Launchpad bug 119588 in ubuntu "Wrong rendering of Arabic characters" [Medium,Incomplete]  https://launchpad.net/bugs/119588
[10:34] <ArneGoetje> asisak: I'll have a look
[10:34] <asisak> Thanks, ArneGoetje. Feel free to assign the bug to the right person.
[11:00] <seb128> ion_: hi, do you get bug #135650, could you try to get a valgrind log?
[11:00] <ubotu> Launchpad bug 135650 in gimp "GIMP crashes when trying to resize an image." [Medium,Incomplete]  https://launchpad.net/bugs/135650
[11:37] <iwj> siretart: You're right, that comment is confusing.  It's statically linked _against libcryptsetup_ but dynamically against external libraries.
[12:02] <ArneGoetje> iwj: could you please review https://wiki.ubuntu.com/MainInclusionReportLibhangul for me? Thanks. :)
[12:10] <iwj> ArneGoetje: Sure.
[12:33] <siretart> iwj: I can confirm that your test package didn't blow up my system. (but I don't have crypted root, "only" crypted /home)
[12:36] <iwj> siretart: That's a very helpful report, thanks.
[12:37] <iwj> I think with another quick test here I should be able to upload it.
[12:43] <ulaas> would like to report a scsi problem with gutsy tribe5 alternate install. this should be the right place, correct?
[12:43] <Amaranth> ulaas: http://bugs.launchpad.net/ubuntu
[12:48] <Ng> is the output of the scripts in /etc/acpi/ sent anywhere when, for example, sending&resuming?
[12:50] <seb128> Riddell: is that ok to upate icon-naming-utils to 0.8.6? The new version fixes some icon themes we have at the moment
[12:51] <soren> Ng: There's a bit in /var/lib/acpi-support ?
[12:51] <soren> Ng: What are you looking for specifically?
[12:52] <Ng> soren: hoping for some output of vbetool post, because it hangs quite a bit atm in gutsy for me
[12:53] <soren> Ng: Don't think that's stored anywhere. You can disable the vbetool stuff in /etc/default/acpi-support, though.
[12:53] <Riddell> seb128: sure
[12:54] <seb128> Riddell: thanks
[12:55] <Ng> soren: I need to post the card or I don't get the backlight, but sometimes it hangs and eats CPU (LP #134868)
[12:55] <ubotu> Launchpad bug 134868 in vbetool "100% cpu on resume" [Undecided,New]  https://launchpad.net/bugs/134868
[12:55] <iwj> ArneGoetje: Approved, thanks.
[12:55] <Ng> soren: but I can add some more debugging myself I guess :)
[12:55] <Kopfgeldjaeger> ho
[12:56] <soren> Ng: Ah, I see.
[12:57] <soren> Ng: It doesn't happen on my X40, FWIW.
[12:57] <soren> Ng: Ah.. I have tweaked it, though.
[12:57] <Ng> soren: it never happened to me in feisty and vbetool is the same version in gutsy
[12:57] <soren> Ng: I've set it to do doubel console switching.
[12:58] <Ng> soren: I've enabled that this morning to see if it helps, but I'd never needed it before. in feisty the acpi stuff on this machine was 99% reliable, certainly moreso than windows
[12:58] <soren> Ng: Did you use the -intel driver in Feisty, too?
[12:59] <Ng> soren: yes, the i810 didn't like resuming very much, I found
[12:59] <Ng> +driver
[01:00] <soren> Ng: Ok... I don't remember if I enabled the double console switching already back then, actually.
[01:00] <soren> Ng: Feisty was fine for me with i810.
[01:01] <Ng> soren: 8086:3582 for your graphics chip?
[01:02] <soren> Ng: Yup.
[01:15] <iwj> ogra: I have to say that reworking this cryptsetup main inclusion report hasn't given me a very good feeling about any similar reports from the same author in the future.  I've found a couple more falsehoods in it and it doesn't really seem like the package was investigated during the preparation of the original report.
[01:24] <ogra> iwj, well, that was a very old one, done with the old copy and paste habit, sorry for that
[01:25] <ulaas> zul, u around?
[01:28] <iwj> ogra: I don't think "the old copy and paste habit" is and excuse for multiple false statements, really.
[01:28] <iwj> s/and/an
[01:28] <ulaas> if anyone is interested about bug 127872 . i have a system with the same bug/scscichipset. and have time to get debug info from installer?
[01:28] <ubotu> Launchpad bug 127872 in linux-source-2.6.22 "scsi drives not detected " [Undecided,Incomplete]  https://launchpad.net/bugs/127872
[01:28] <ogra> iwj, what are the fals statements ? i have the first iteration of the doc open ...
[01:28] <iwj> That there are no binaries running as root, for example.
[01:29] <ogra> (there are not many statements at all)
[01:29] <ogra> ah
[01:30] <iwj> I don't know what the Debian BTS looked like when you wrote the report but by now I wouldn't say that "maintainence in Debian is good" without further qualification.  If you look at the Debian BTS and at LP it's clear the package has some "issues".
[01:31] <ogra> well, form an update pov its well maintained
[01:31] <iwj> I just wanted to point out that the next time I read a review from the same author I might treat the assertions in it with a bit more scepticism than I would hope would be necessary.
[01:32] <iwj> And because of that I have to do more work myself and it may not always be at the top of the queue.
[01:32] <ogra> and i see two oustanding bugs marked as important and one in pending upload
[01:32] <iwj> Did you read the one about the data loss ?
[01:33] <ogra> no, at least there is no bugtitle indication something like that anywhere
[01:35] <iwj> 428288
[01:35] <ogra> and i would expect such a bug to be tagged important, which it obviously isnt
[01:35] <iwj> My point is that if I can't rely on the report author to have done the research then I have to do it myself.  That's not really the role of the approver, for obvious reasons.
[01:36] <ogra> right
[01:36] <iwj> So next time I will expect you to understand why perhaps your report doesn't go straight to the top of the list.
[01:36] <ogra> i'll try to be more careful with future reports ... this was actually one i added really from the template since i had discussed it in person with pitti before
[01:37] <iwj> As I said just ^ up there, copying text from the template is no excuse for inclusion of false statements.  The one about no binaries running as root is a cut-and-dried example.
[01:37] <ogra> you will very likely get a new moodle report from me for gutsy if the edu team gets the package ready
[01:38] <ogra> i'll try to make that as good as i can ;)
[01:38] <iwj> Now if it were just that one little slip in an otherwise thorough review then I wouldn't be so bothered but that's not the case.
[01:38] <ogra> well, that was the report you started to change the policy for ...
[01:38] <ogra> and i didnt touch it after you rejected it ...
[01:39] <iwj> Are you asserting that the previous policy was to encourage the inclusion of false statements in MIRs ?!
[01:39] <ogra> no, but it made it easy to let one statement slip through
[01:39] <cjwatson> surely we have had this discussion about MIR policy at length before, and established that Ian was just making it clearer
[01:39] <ogra> which cant happen witrh the new tmplate
[01:39] <iwj> Well I think that as the review author you ought to take responsibility for that.
[01:40] <ogra> cjwatson, right, and that was actually the last MIR i wrote personally
[01:40] <ogra> iwj, i will do that if i write my next one
[01:41] <iwj> I see, well, I hope you'll forgive me if I still take a somewhat sceptical approach to the next one.
[01:41] <ogra> iwj, no, i actually appreciate that, simply as a selfcontrol mechanism :)
[01:42] <iwj> Thanks.
[01:47] <seb128> mjg59: bug ##136346 for you probably
[01:47] <seb128> bug #136346
[01:47] <ubotu> Launchpad bug 136346 in gnome-power-manager "gutsy: g-p-m 2.19.6-0ubuntu4 breaks brightness control" [Undecided,New]  https://launchpad.net/bugs/136346
[01:57] <iwj> cjwatson: So I think I've finished rewriting this review report but I was wondering if you would like to quickly look over the report and give me a second opinion ?   My view is that we probably ought to include it despite the fact that it does have some problems.
[01:57] <iwj> cjwatson: https://wiki.ubuntu.com/MainInclusionReportCryptsetup is the wiki page.
[02:10] <cjwatson> iwj: looking
[02:58] <EtienneG> hey guys
[02:58] <EtienneG> 6.06.2 is advertised as being due today, 2007-08-31
[02:58] <cjwatson> EtienneG: where? we changed that
[02:58] <EtienneG> I have not heard much about it ... just curious if we are going to make it
[02:58] <cjwatson> pushed to next month
[02:58] <EtienneG> cjwatson, https://launchpad.net/ubuntu/+milestone/ubuntu-6.06.2
[02:58] <cjwatson> I'll correct that, thanks
[02:59] <cjwatson> (as soon as I dig up the new date)
[02:59] <EtienneG> cjwatson, thanks, would like to know the new date
[03:00] <cjwatson> EtienneG: https://wiki.canonical.com/Ubuntu6.06.2
[03:00] <cjwatson> ha, it's a bit out of sync though
[03:01] <EtienneG> cjwatson, thanks a lot !  who's the release manager for that one ?
[03:01] <cjwatson> fixed
[03:01] <cjwatson> pitti
[03:01] <Fujitsu> Yay, secret documents.
[03:01] <cjwatson> (on holiday atm)
[03:01] <cjwatson> Fujitsu: the date in the public URL noted by EtienneG is up to date now
[03:02] <Fujitsu> Ah, good.
[03:02] <cjwatson> the full list is private at the moment because an awful lot of the drivers for the specifics of 6.06.2 are Canonical partners of one kind or another
[03:03] <EtienneG> cjwatson, sorry for bugging you during your holiday.  Not get away from the computer !!!  :)
[03:03] <EtienneG> s/Not/Now/
[03:03] <cjwatson> EtienneG: I'm not on holiday; pitti is
[03:04] <EtienneG> cjwatson, ok, sorry then!
[03:04] <EtienneG> he is having a well-deserved one
[03:07] <Chipzz> cjwatson: got a second to look at https://bugs.launchpad.net/ubuntu/+source/vim/+bug/125247 ? should be just applying :)
[03:07] <ubotu> Launchpad bug 125247 in vim "Apache config files in /etc/apache2/sites-available and /etc/apache2/sites-enabled do not alwyas have proper syntax highlighting" [Undecided,Triaged] 
[03:07] <cjwatson> Chipzz: sorry, no; I think somebody else has touched-it-last-maintainership of vim by now ;-)
[03:08] <Hobbsee> :)
[03:24] <soren> Chipzz: That would be me.. :/
[03:25] <soren> Chipzz: Oh, but I'm not core-dev. :)
[03:25] <Chipzz> soren: not important really, but is an easy fix, and it didn't get triaged yet though
[03:27] <Mirv> mjg59: hi, vbetool / libx86 debug output has now been going for ca. 7 hours, and the log file is 100MB. just because I don't know anything about instruction dumping works, is it sure other processes don't matter? ie. it only logs whatever the vbetool is doing? I'll let it be probably for this evening and night still.
[03:30] <mjg59> Mirv: Ok, once it's got that big it's /probably/ ok to stop it
[03:30] <mjg59> But yes, it'll only dump what vbetool is doing
[03:34] <Mirv> I'm yearning for the crash to happen :)
[03:35] <mjg59> Could you gzip what it's done so far and attach that to the bug?
[03:36] <kleinernik> hi, i want to help with bugfixing, i found a bug on lunchpad and i think i have got a patch to fix this bug. i uploaded this patch to lunchpad. it is not an important bug, but for me it is a good starting point. can anyone help me, i don't know what to do next, i.e. how to find someone to prove my fix and point out what are the next steps ..
[03:39] <Hobbsee> kleinernik: you might want to see https://wiki.ubuntu.com/MOTU/Contributing
[03:40] <kleinernik> Hobbsee: thank you
[03:42] <mjg59> Mirv: Though, ideally, it would be better if we could wait for it to actually crash, yeah
[03:49] <soren> Could someone please upload http://people.ubuntu.com/~soren/upload/dovecot/ for me?
[03:50] <seb128> Hobbsee, soren: does the goocanvas exception is also granted for pygoocanvas? ;)
[03:50] <Hobbsee> seb128: yes
[03:51] <zul> soren: sure
[03:52] <zul> soren: its ok to upload this one?
[03:52] <seb128> Hobbsee: thanks
[03:58] <iwj> cjwatson: Did you have an opinion about cryptsetup ?  If you're too busy I can ask someone else or just go ahead based on my own opinion.
[04:04] <cjwatson> iwj: whoops, sorry. I think it's reasonable for promotion with your changes. Could you file a bug against partman-crypto to note that it needs to forbid mounting a partition that needs cryptsetup on /usr, though?
[04:04] <StevenK> cjwatson: Since cryptsetup actually lives in /usr?
[04:05] <cjwatson> iwj: what are we doing about things like bug 105394?
[04:05] <ubotu> Launchpad bug 105394 in cryptsetup "Upstart needs some key pressed to show "Enter Passphrase" on boot /  cryptsetup problem" [Undecided,New]  https://launchpad.net/bugs/105394
[04:05] <cjwatson> StevenK: libraries it uses apparently
[04:05] <StevenK> cjwatson: Which is fair enough. Avoiding chicken and egg problems is good.
[04:06] <cjwatson> iwj: bug 90914 has a patch which looks perhaps helpful in part
[04:06] <ubotu> Launchpad bug 90914 in cryptsetup "initramfs cryptroot usplash support" [Undecided,Incomplete]  https://launchpad.net/bugs/90914
[04:07] <seb128> Riddell: how do I get flash non free being used by konqueror?
[04:07] <Riddell> seb128: settings->configure konqueror->plugins->scan for new plugins
[04:08] <Riddell> assuming you have it installed somewhere it's searching
[04:08] <Riddell> although it should do that on startup anyyway
[04:08] <seb128> utch
[04:08] <Riddell> oh, it does it at KDE startup, which I guess means not for you
[04:08] <seb128> 5 Configure items in the settings menu, KDE is impressive :p
[04:08] <Riddell> horrific isn't it
[04:09] <Riddell> one day I'll fix that
[04:09] <seb128> no plugins in the configure konqueror
[04:12] <StevenK> cjwatson: Shouldn't the patch use usplash_write if $count -gt 3 at the end instead of just echo'ing?
[04:15] <iwj> cjwatson: 105394> I don't think we're doing anything about it :-/.  I haven't tested that setup myself but I imagine one response would be `use luks' although of course we don't know if luks is affected too.
[04:16] <iwj> cjwatson: 90914> Yes, perhaps.
[04:16] <seb128> Riddell: flash works fine in konqueror for me
[04:16] <iwj> cjwatson: I think really the package needs some maintenance in Ubuntu but the question is really whether to put it in main now.
[04:16] <Riddell> seb128: with the current gtk or a patched one?
[04:16] <seb128> Riddell: current gutsy
[04:16] <seb128> I was trying to get the bug to fix it
[04:16] <seb128> but not way
[04:17] <Riddell> seb128: oh, that'll be our patch we added which adds a dependency on gtk
[04:17] <iwj> cjwatson: I think I'll call myself the maintainer of the package but I don't propose to fix it up very much for gutsy.  It really needs rather more invasive changes which ought to be done earlier in a cycle.
[04:17] <seb128> Riddell: oh, you did use the workaround?
[04:17] <iwj> cjwatson: So, err, thanks.
[04:17] <Riddell> seb128: for now, but obviously I'd much rather have a workaround in gtk than have konqueror depend on gtk and do the workaround for it
[04:18] <Riddell> seb128: you'll need to downgrade to 4:3.5.7-1ubuntu15 or earlier, or just use opera
[04:21] <iwj> cjwatson: partman-crypto> bug 136382
[04:21] <ubotu> Launchpad bug 136382 in partman-crypto "disallow encrypted separate /usr" [Undecided,New]  https://launchpad.net/bugs/136382
[04:27] <Riddell> asac: any idea what bug 136376 is all about?
[04:27] <ubotu> Launchpad bug 136376 in flashplugin-nonfree "automatic update for mozilla-flashplayer make using flashplayer impossible" [Undecided,New]  https://launchpad.net/bugs/136376
[04:28] <gnomefreak> ok here is good too ;)
[04:32] <Hobbsee> Mithrandir: could you give back krusader on all arches, please?
[04:34] <Mithrandir> Hobbsee: given-back
[04:34] <Hobbsee> Mithrandir: thankyou :)
[04:34] <asac> Riddell: looks like the alternative is no installed for firefox
[04:36] <StevenK> Mithrandir: libzzip-0-12 and libzeroc-ice-cil can be NBS'd out of the archive at your leisure.
[04:37] <StevenK> infinity: Ping, you said tonight.
[04:38] <Mithrandir> StevenK: I'm on too bad a line to want to do any non-urgent archive work, but thanks\.
[04:38] <Mithrandir> s/\\//
[04:38] <StevenK> Mithrandir: Meh, whenever
[04:39] <Mithrandir> yeah, sorry. :-/
[04:39] <Mithrandir> just being on the wrong side of the atlantic.  It's not as bad as being in .au, but getting there.
[04:40] <StevenK> You're helping, Mithrandir, really.
[04:40] <StevenK> :-P
[04:48] <bddebian> Heya
[04:52] <asac_the_2nd> Riddell: ok on amd64 its completely broken... the alternative just points to the wrong file ... e.g. the 32-bit one.
[04:54] <StevenK> Mithrandir: Have you got a sec to poke at kxdocker?
[04:54] <Hobbsee> StevenK: what about it?
[04:54] <Hobbsee> StevenK: it's gone, isnt it?
[04:54] <Mithrandir> StevenK: what kind of poking?
[04:54] <StevenK> It's marked superseded
[04:54] <StevenK> But what about kxdocker-data?
[04:54] <Hobbsee> StevenK: it's been removed, iirc
[04:54] <Hobbsee> that should have been gotten in the removal request
[04:55] <Hobbsee> hmm, seems its' a separate source
[04:55] <StevenK> Yup.
[04:55] <StevenK> But so it has.
[04:55] <StevenK> Mithrandir: Do you want a bug to kill kxdocker-data?
[04:55] <Hobbsee> seb might be able to do it, he's on a more stable connection
[04:57] <Mithrandir> StevenK: please, or just get seb to do it.
[04:57] <seb128> StevenK: it needs removal?
[04:58] <Hobbsee> seb128: yes
[04:58] <seb128> rational?
[04:58] <Hobbsee> seb128: "because i said so"
[04:58] <seb128> Hobbsee: well, just a small rational for the removal text would be nice
[04:58] <StevenK> seb128: It's data files for kxdocker, which was killed before and has been broken since Edgy
[04:58] <Hobbsee> seb128: there's one, right there :P
[04:58] <seb128> like superceded, or not maintained upstream, or ..
[04:59] <Hobbsee> seb128: because kxdocker got removed to brokenness, and someone forgot to ask for removal of both
[05:00] <seb128> Hobbsee, StevenK: removed
[05:00] <Hobbsee> thanks
[05:01] <Hobbsee> seb128: really, "because i said so" is a perfectly valid reason...
[05:01] <bddebian> Hell have no fury....
[05:01] <StevenK> Actually, it's 'hath'
[05:01] <seb128> Hobbsee: right, double checking doesn't hurt though and I like to do things because I agree and not because I've been told to do them ;)
[05:01] <bddebian> I know.. I couldn't think of the spelling atm.. :-(
[05:02] <Hobbsee> seb128: i know :)
[05:02] <bddebian> Hell hath no fury like a woman with a point stick!.. :-)
[05:02] <Hobbsee> seb128: coerced.  with Long Pointy Stick of DOOM!!!!!!!!!!!!!!! 
[05:02] <Hobbsee> es
[05:03] <bddebian> Damn I'm having a hard time getting motivated again.. :-(
[05:03] <bddebian> Gah, sorry, wrong channel
[05:04] <Hobbsee> bddebian: you can run, but you cant hide..
[05:05] <Mithrandir> bddebian: but she's very tickly.
[05:05] <bddebian> Heh
[05:06] <StevenK> But tickling Hobbsee is dangerous for one's ribs
[05:06] <maswan> StevenK: you need a long pointy stick of tickling then?
[05:06] <bddebian> Hobbsee: Are you coming to Boston?
[05:06] <StevenK> maswan: Or a straightjacket
[05:06] <bddebian> hah
[05:06] <Hobbsee> bddebian: perhaps.  we'll see.
[05:06] <Hobbsee> StevenK: yes, you've finally learned this, it seems :P
[05:07] <Hobbsee> Mithrandir: you shouldnt give away my secrets like that
[05:08] <bddebian> I can't decide whether to go or not..
[05:09] <bddebian> ScottK: Where are you?
[05:09] <ScottK> Outside Baltimore, MD, USA
[05:09] <Mithrandir> StevenK: I'll hold her, and you can tickle?
[05:09] <bddebian> Oh crap, you are closer than me then :-)
[05:09] <ScottK> bddebian: Where are you?
[05:09] <Riddell> asac_the_2nd: flashplayer-nonfree in feisty is broken?
[05:10] <bddebian> ScottK: Close to Philly
[05:10] <Hobbsee> Mithrandir: you do that, and i'll beat both of you.
[05:10] <asac> Riddell: huh ... is this bug for feisty?
[05:10] <StevenK> Mithrandir: Works for me :-)
[05:10] <Mithrandir> Hobbsee: we can throw you into the harbour, like a bale of tea, then?
[05:10] <ScottK> bddebian: Philadelphia is closer to Boston than Baltimore....
[05:10] <bddebian> Really?
[05:10] <Hobbsee> Mithrandir: no, i dont think so
[05:10] <ScottK> Yeah.  I'm south of you.
[05:11] <nixternal> haha
[05:11] <nixternal> ya, you have about a 1.5 hour lead time on baltimore silly :)
[05:11] <ScottK> About two hours driving in good traffic depending on where in Philly and how close.
[05:11] <bddebian> Well I'm an hour or more NW of Philly
[05:11] <nixternal> oh ya, I forgot turnpike traffic is nuts around philly
[05:12] <nixternal> but I prefer philly turnpike traffic over nyc turnpike traffic
[05:12] <Hobbsee> Mithrandir: something tells me you'd be a little too wounded to do that
[05:12] <bddebian> It's soo close I'd like to go but I have no idea what I'd bring to the table so I dunno..
[05:12] <Riddell> asac: I don't know, I could be wrong on that
[05:12] <asac> Riddell: honestly, I can't get much our of that bug report ... when was the last flashplugin roll-out we did?
[05:13] <nixternal> haha, Mithrandir is trying to recreate the Boston Tea Party with a barrel of LongPointyStick
[05:13] <nixternal> :p
[05:13] <Mithrandir> indeed.  The Ubuntu Tea Party will be great.
[05:13] <nixternal> hahaha, nice
[05:14] <asac> Riddell: he claims that he just received an update ... i don't understand that ... maybe he is talking about something different? some third party extension?
[05:14] <bddebian> Not nearly enough caffeine in Tea for nixternal
[05:14] <nixternal> nope, need a couple of starbucks red eyes for me
[05:17] <StevenK> seb128: Do you mind also killing libapache-mod-lisp; Apache 1.x only, Debian bug #431034
[05:17] <ubotu> Debian bug 431034 in ftp.debian.org "RM: libapache-mod-lisp -- ROM; obsolete; FTBFS" [Normal,Open]  http://bugs.debian.org/431034
[05:17] <bddebian> StevenK: File a bug ya lazy bum.. ;-P
[05:18] <StevenK> bddebian: Hmph
[05:18] <seb128> StevenK: done
[05:19] <StevenK> seb128: Danke
[05:21] <Riddell> asac: nothing very recent according to https://launchpad.net/ubuntu/+source/flashplugin-nonfree
[05:21] <Riddell> asac: I've no idea what the mozilla-flash is he's talking about
[05:23] <asac> yeah ... his description is just confusing and just guesswork. Lets wait for his answer.
[05:24] <Hobbsee> should make asac do it, instead of me.
[05:24] <asac> huh?
[05:25] <asac> Hobbsee: i think you are perfect for that :)
[05:25] <Hobbsee> asac: behind motu interviews.  yo ushould do one
[05:25] <Hobbsee> asac: bah.  i manage to have far too high a profile, even without doing interviews.
[05:29] <Hobbsee> asac: besides, what i'm wokring on keeps changing
[05:38] <bddebian> Hobbsee: Well that's better than working on nothing like me :-)
[05:40] <asac> bddebian: i have some work ... fix flashplugin-nonfree package for real :)
[05:40] <bddebian> What's wrong with it?
[05:40] <asac> well ubuntu5 - which you sponsored ;) - caused some mess ... now that i looked at it i saw that it messed up the target path of the amd64 alternative
[05:41] <gnomefreak> bddebian: might be better to ask what isnt wrong with it
[05:41] <asac> in ubuntu4 it pointed to the npwrapper.libflashplugin.so file in /var/lib/...
[05:41] <asac> now it points to the 32-bit binaries
[05:42] <asac> but i am not sure if the regression slipped in in ubuntu5 ... might have slipped in later as we are already at ubuntu8 :)
[05:42] <bryce> mjg59: I must have not been in the discussion in London about the font sizes (or my memory is failing me).  Was someone going to be adding the code to gnome-settings-daemon?
[05:42] <bddebian> Egads
[05:42] <seb128> bryce: what code?
[05:42] <bryce> seb128: don't know, mjg59 referred to adding some code
[05:43] <mjg59> bryce: Sorry, no, not the font sizes
[05:43] <mjg59> bryce: The display hotkey stuff
[05:43] <bryce> ahh, yes
[05:43] <mjg59> Something needs to catch the keycode and run xrandr --auto
[05:43] <Amaranth> oh, this was the bug filed against metacity and compiz and assigned to seb128
[05:44] <bddebian> I don't have an amd64 though.  Wanna send me one to test with? :-)
[05:44] <bryce> ok I do remember that.
[05:44] <Amaranth> if someone adds it to metacity we can add it to the integration stuff so compiz gets it too
[05:44] <seb128> bryce, mjg59: it's on my list of changes, I'll do it next week
[05:44] <bryce> awesome
[05:44] <gnomefreak> bddebian: i tried that excuse already ;)
[05:44] <bddebian> heh
[05:44] <mjg59> I suspect it makes more sense in gnome-settings-daemon than metacity/compiz
[05:44] <Amaranth> mjg59: true
[05:44] <seb128> yes
[05:45] <bryce> btw, things are looking fairly good for including the latest -ati, which has xrandr 1.2 support and theoretically could enable hotplug projectors for all ati cards
[05:45] <mjg59> bryce: The font size issue is separate. The server is caluclating DPI information now, which GTK is using. Sadly, it seems to be somewhat insane stuff.
[05:45] <mjg59> bryce: I suspect that hardcoding it to 100 would do
[05:45] <bryce> however in testing we've been finding a few regressions, so doing this change is not going to be without some pain.  However upstream is actively developing so I'm hoping the issues will gain fixes soonish
[05:46] <seb128> mjg59: it used to be set to 96 dpi and I think we will do that again for gutsy
[05:46] <bryce> mjg59: yes that's what seb128 and I decided to do.  don't know if the change is in yet
[05:46] <mjg59> Ok, 96 should work
[05:46] <seb128> bryce: no, will do that next week as well
[05:47] <bryce> seb128: ah excellent
[05:48] <bryce> Amaranth: btw, we're switching the default driver from intel hardware from -i810 to -intel soonish; the one major bug we know of is that Xv video playback in compiz is horked (sometimes?) with -intel.
[05:49] <Amaranth> bryce: it's always broken
[05:49] <bryce> however it sounds like Xv playback on -i810 is anyway, and it's more likely we'll see a fix for -intel than -i810
[05:49] <bryce> s/anyway/iffy anyway/
[05:49] <Amaranth> bryce: if i had to guess i'd say totem is picking the first offered xv output which is the textured video one but that only works with exa
[05:49] <Amaranth> but i don't own intel hardware so i can't test
[05:50] <Amaranth> it'd be stupid for the driver to offer it if it doesn't work
[05:50] <bryce> if you have patches or solutions in need of a test, I got one of the dell intel laptops I could run tests on
[05:51] <Amaranth> someone with intel hardware should check in gstreamer-properties to see what Xv 'devices' are offered
[05:52] <Amaranth> i don't know how to query for the info directly, i suppose xvinfo
[05:52] <mjg59> Yes, the first channel will be textured video
[05:52] <mjg59> 965 has no hardware overlay
[05:52] <Amaranth> xvinfo | grep Adaptor
[05:52] <mjg59> So compiz = no xv on 965 on xaa
[05:52] <Amaranth> mjg59: so we have to use Exa?
[05:52] <Ng>   Adaptor #0: "Intel(R) Video Overlay"
[05:52] <mjg59> "have"
[05:52] <Ng> 855GM
[05:53] <Amaranth> Ng: right, you're fine
[05:53] <mjg59> But if you want a composited desktop, yes
[05:53] <mjg59> 855 has no textured video
[05:53] <Ng> I don't use compiz, but I want -intel to be default very much :)
[05:53] <Amaranth> it's apparently only on the 965 since it only does textured video
[05:53] <mjg59> 915 and 945 have textured and overlay, with textured by default
[05:53] <mjg59> 965 only has textured
[05:54] <Amaranth> mjg59: shouldn't the driver just claim to not support any xv adaptors if exa isn't enabled?
[05:54] <mjg59> Amaranth: No, because it works fine if you're not using composite
[05:54] <Ng> mjg59: can I bug you about vbetool, or should I go after someone else? :)
[05:54] <bryce> my machine's only a 845GM, but here's xvinfo and lspci for it:  http://people.ubuntu.com/~bryce/tmp/
[05:54] <Amaranth> mjg59: how?
[05:54] <mjg59> Ng: YOu can try
[05:54] <mjg59> Amaranth: ?
[05:54] <mjg59> Textured video doesn't require exa
[05:54] <Ng> mjg59: it seems to be the same version as in feisty, but my X40 is now failing to resume a fair amount, with vbetool eating all the CPU
[05:55] <bryce> that's without compiz running, I don't know if that makes a difference for xvinfo
[05:55] <Amaranth> mjg59: I was told the textured video output required exa no matter what
[05:55] <mjg59> Amaranth: No
[05:55] <Amaranth> bryce: it doesn't
[05:55] <Amaranth> isn't Exa really...broken?
[05:55] <mjg59> If you mean "Is EXA ready for deployment", I suspect not
[05:55] <bryce> er, that should be 945GM not 845GM.  coffee hasn't reached my fingers yet apparently
[05:56] <Amaranth> bryce: do you get the bug?
[05:56] <Amaranth> bryce: from what mjg59 has said only 965 users should have this problem
[05:56] <bryce> hmm, let me check
[05:56] <bddebian> asac: BTW is flashplugin the one that you yelled at me for because it's in bzr?
[05:56] <Ng> mjg59: (134868 in LP. More than happy to do more debugging if I can)
[05:56] <Amaranth> i wish we could just default to the gl output in gstreamer :)
[05:56] <mjg59> Amaranth: ? No.
[05:56] <mjg59> Amaranth: Textured video is the default in 915 and 945
[05:56] <bryce> I don't recall seeing it, but I can check again
[05:56] <Amaranth> whee
[05:57] <mjg59> 16:53 < mjg59> 915 and 945 have textured and overlay, with textured by default
[05:57] <Amaranth> Drivers are always so messed up :/
[05:57] <Amaranth> hrm
[05:58] <Amaranth> i suppose we could add a gdk_screen_is_composited check or something to totem to tell it to use a different video output
[05:58] <Amaranth> i think totem can override the gstreamer default, anyway
[05:58] <mjg59> Still leaves 965 broken
[05:58] <Amaranth> why?
[05:58] <mjg59> Because it has no overlay hardware
[05:59] <Amaranth> i meant to tell it to use the non-xv sink
[05:59] <mjg59> Oh. No, we can't do that.
[05:59] <mjg59> Performance would be dire.
[05:59] <mjg59> You wouldn't get any hardware scaling
[05:59] <Amaranth> ok then, the gl sink
[05:59] <bryce> yup, I definitely can reproduce the bug here
[06:00] <bryce> tried on the Experience_ubuntu.ogg video and got a blank screen in totem.  Same with a ripped dvd movie
[06:00] <mjg59> Amaranth: I suspect that that won't work well either
[06:00] <Amaranth> oh, but that's in universe
[06:00] <Amaranth> bryce: blank screen is different
[06:00] <mjg59> I mean, I could say "Compiz is not ready for production use" again
[06:00] <Amaranth> bryce: you should get a crash
[06:00] <bryce> Amaranth: ah
[06:00] <bryce> no, no crash
[06:00] <Amaranth> i could have sworn mvo fixed the bug you seem to have
[06:01] <Amaranth> mjg59: i hate drivers :P
[06:01] <Ng> while you're talking about 3d stuff and intel chipsets - after a suspend/resume, all 3d textures on my 855GM are replaced with noise (so if you're using compiz, every window is entirely made of random noise)
[06:01] <Amaranth> apparently no one knew how horrible the new nvidia driver was before switching to it
[06:01] <Ng> (soren confirms seeing it on his too, fwiw)
[06:01] <bryce> this laptop is a few days out of date, so if it's a recent fix that may be why.  I'll update and check again
[06:01] <Hobbsee> night all
[06:02] <Amaranth> we could always use Xgl... :D
[06:03] <asac> bddebian: no
[06:03] <asac> bddebian: maybe gnash?
[06:04] <bddebian> Oh maybe
[06:04] <bddebian> I break so many things it's hard to keep track :-)
[06:04] <bryce>  -> breakfast.  bbiab
[06:04] <asac> hehe
[06:20] <ooo>  /server -m irc.master-online.org:12000
[06:26] <Amaranth> grr
[06:48] <doko> After unpacking 58.2MB disk space will be freed.
[06:48] <doko> Do you want to continue [Y/n] ?
[06:48] <doko> Bus error
[06:48] <doko> (Reading database ... 25795 files and directories currently installed.)
[06:49] <doko> iwj: ^^^ on sparc, this is a dselect-upgrade, continues ok after the bus error. which program is it that fails with the bus error?
[06:50] <iwj> Boggle.
[06:50] <iwj> This is dselect's apt method ?
[06:50] <iwj> Or apt's dselect method, or something ?
[06:50] <iwj> I don't know what that message is from.
[06:54] <ion_> seb128: Yeah, ive been fighting with gimps internal functionality that catches crashes and prints stack traces. I just cant seem to turn it off. Because of that, apport doesnt detect the crashes and using gdb is difficult. gimp --stack-trace-mode=never doesnt seem to work.
[06:55] <ion_> seb128: Almost all dialogs do crash without G_SLICE=always-malloc.
[07:36] <ArneGoetje> doko: sun-java6 deppends on libstdc++5, which is not in gutsy anymore. So, the packages are uninstallable.
[07:37] <cjwatson> libstdc++5 | 1:3.3.6-15ubuntu2 |         gutsy | amd64, i386, powerpc
[07:37] <doko> ArneGoetje: it should be, in universe
[07:37] <cjwatson> not even, it's still in main
[07:38] <doko> hrm
[07:40] <ArneGoetje> not on the taiwan mirror, it seems
[07:40] <ArneGoetje> my aptitude cannot find it
[07:48] <ArneGoetje> ok, found it.
[07:48] <mjg59> What's responsible for determining which types of block device to automount now?
[07:48] <ArneGoetje> seems the '++' needs to be escaped when searching for the package name...
[07:55] <ArneGoetje> doko: do you know which releases use sun-java5 ? the fonts entries there need to be fixed too, I suppose. (except the font packages on older systems have other configurations...)
[07:56] <doko> ArneGoetje: back to dapper, but I can add different versions of this file for every release if needed
[07:57] <alex-weej> doko: last week, you sync'd pyopengl from debian unstable. problem is that the version is 3.0 alpha, and i'm getting pretty bad performance out of it. :(
[07:58] <ArneGoetje> doko: uh... that means I have to try out every release since dapper...
[07:58] <doko> alex-weej: well, at least it works with python2.5. what are the problems?
[07:59] <doko> ArneGoetje: well, dapper and gutsy should be sufficient
[07:59] <alex-weej> doko: i don't know specifically because i don't have any python opengl benchmarks :(
[07:59] <alex-weej> doko: does 2.0.1 not work with python 2.5?
[07:59] <alex-weej> https://bugs.launchpad.net/bugs/135736
[07:59] <ubotu> Launchpad bug 135736 in pyopengl "Serious performance regression from recent update from 2.0.1 to 3.0" [Undecided,New] 
[08:00] <alex-weej> fwiw, there is an upstream stable 2.0.2 iirc
[08:00] <alex-weej> oh wait
[08:01] <alex-weej> maybe it isn't alpha after all :( i must have gotten confused :$
[08:02] <LaserJock> oh wow, python 3.0a1 is out
[08:04] <alex-weej> doko: does 3.0.0a6 mean alpha-6?
[08:07] <doko> alex-weej: I wouldn't mind 2.0.2, but this has to be checked on amd64, not just i386
[08:08] <alex-weej> doko: 2.0.2 isn't stable, i was wrong.
[08:09] <alex-weej> doko: also it is only with one specific game (i don't have any other pyopengl apps to test)
[08:09] <alex-weej> but it is consistent across r300 and fglrx on i386
[08:12] <alex-weej> doko: how difficult is it to get APT to downgrade a package anyway? if it's easy i guess it's not release critical
[08:14] <bryce> alex-weej: often it's as simple as just specifying the version.  E.g.:
[08:14] <bryce> apt-get install xserver-xorg-core=2:1.3.0.0.dfsg-4ubuntu
[08:14] <alex-weej> bryce: i mean automatically
[08:15] <alex-weej> for "the masses"
[08:15] <bryce> ah, nfc
[08:15] <alex-weej> nfc?
[08:15] <bryce> no friggin clue ;-)
[08:15] <bryce> good question tho
[08:16] <doko> alex-weej: either add an epoch (not recommended when debian doesn't do it), or have something like: 3.0.0a6really2.0.1...
[08:16] <alex-weej> heh :E
[08:16] <broonie> In other words, apt will never downgrade without explicit user intervention.
[08:17] <bryce> oh yeah, epochs
[08:17] <doko> Source: qt-x11-free
[08:17] <doko> Version: 3:3.3.8really3.3.7-0ubuntu9
[08:17] <bryce> *shudder*
[08:17] <azeem> there should be multi-level epochs
[08:18] <LaserJock> heh
[08:18] <LaserJock> that sounds fun
[08:19] <alex-weej> doko: so what should i do?
[08:19] <alex-weej> doko: try to find someone on amd64 and see if they get it too?
[08:19] <doko> yes, that would be best
[08:20] <alex-weej> anyone here? :P
[08:33] <bddebian> doko: Is kaffe supposed to include a /usr/lib/kaffe/include dir?
[08:34] <doko> bddebian: I have no idea about kaffe
[08:35] <bddebian> Damn, OK, sorry
[08:35] <bddebian> Hmm, maybe the includes should come from gcj
[08:40] <bddebian> Weird, there is a /usr/lib/kaffe/pthread/include which is a symlink to ../include but that dir doesn't exist
[08:41] <bddebian> POS
[08:43] <bddebian> Ahh, it's in the -dev package
[08:44] <bddebian> Heh, nice build-deps
[09:03] <bddebian> Any archive admins still aboot?
[09:04] <yatiohi> Hello
[09:05] <yatiohi> can i install somehow pthread man pages?
[09:05] <yatiohi> i m new to ubuntu :)
[09:05] <ScottK> yatiohi: #ubuntu is for help.
[09:06] <yatiohi> oh, sorry :)
[09:06] <norsetto> !support | yatiohi
[09:06] <ubotu> yatiohi: the official ubuntu support channel is #ubuntu. Also see http://ubuntu.com/support and http://ubuntuforums.org
[09:45] <ion_> Could someone please take a look at bug #136439? I reported it and another person set its status to invalid. In my opinion, he didnt understand what im saying and set the status to invalid based on his misunderstanding.
[09:45] <ubotu> Launchpad bug 136439 in gimp "--stack-trace-mode doesnt seem to work" [Undecided,Invalid]  https://launchpad.net/bugs/136439
[09:53] <DoctorMO> hello everyone
[09:53] <DoctorMO> is this a good place to talk about ideas for Hardy Heron?
[09:55] <LaserJock> DoctorMO: probably not so much
[09:55] <DoctorMO> LaserJock: drat
[09:55] <LaserJock> DoctorMO: we're still focused on Gutsy Gibbon
[09:55] <LaserJock> DoctorMO: best thing I can think of is to do a proposal on ubuntu-devel-discuss or something
[09:55] <LaserJock> writing up a wiki page spec is also helpful
[09:56] <LaserJock> if it's it's more than trivial
[09:56] <DoctorMO> LaserJock: yea, always a case. more than trivial; trivial changes I would impliment and bypass going up stream etc
[10:01] <geser> ion_: have you tried to talk to pedro_ about it?
[10:04] <ion_> In the bug discussion, yes. In IRC, no.
[10:05] <maxamillion> i recently heard that there is a need for a pypanel hacker for ubun2 and i was sent here from #ubuntu-artwork to ask ... is there any validity to this or was i mis-informed?
[10:16] <decriptor> anyone in here working on XEN
[10:16] <decriptor> or is there no future for XEN in ubuntu
[10:18] <kitche> decriptor, looks to me Xen works fine in ubuntu
[10:18] <decriptor> without having to bootstrap
[10:18] <decriptor> it
[10:19] <decriptor> other distros have some xen stuff on the cd so that you can install it as a paravirtualized guest right off the cd
[10:19] <decriptor> suse seems to be the only one that does this well
[10:19] <decriptor> with fedora  the only install option is netowrk
[10:19] <decriptor> ubuntu its you have to bootstrap it
[10:21] <decriptor> I'm kind of guessing that ubuntu isn't going to seriously support XEN?    more support pushed towards KVM?
[10:26] <LaserJock> decriptor: XEN is a  big thing for Ubuntu
[10:26] <LaserJock> we just need people of course
[10:26] <decriptor> ah
[10:27] <decriptor> LaserJock: just finding it really hard to find anyone interested in it
[10:27] <LaserJock> well, that's the nature of the beast
[10:27] <decriptor> suse seems to have the heaviest develop right
[10:28] <decriptor> so I'm wondering if others aren't working on it much and moving towards KVM
[10:28] <LaserJock> they can also pay people to work on it
[10:28] <kitche> decriptor, of course Xen is big with Novell
[10:28] <decriptor> does that mean it can't be elsewhere
[10:28] <kitche> sure it can just not like how Novell does it since Novell knows know Xen works inside and out
[10:29] <decriptor> true
[10:30] <decriptor> novell has some big resources working on it
[10:30] <decriptor> but
[10:31] <LaserJock> decriptor: so we don't have as much resources
[10:31] <LaserJock> decriptor: that doesn't me we don't care about XEN
[10:31] <decriptor> that's not why I thought that
[10:32] <decriptor> most ubuntu users that I know only talk about KVM
[10:32] <decriptor> and I get almost no response when asking about XEN
[10:32] <LaserJock> maybe KVM is just hotter, I don't know
[10:33] <LaserJock> the fad of the day ;-)
[10:33] <decriptor> I think you have a very good point in and outside of the conversation
[10:34] <decriptor> :-/
[11:02] <PauloZanoni> I added a "script.sh" in the rc2.d directory, its first line contained "#!/bin/bash", but ubuntu was running it as if it were a SH script (not BASH). then, I renamed it to "script" and ubuntu started running it as a BASH script... WHY is ubuntu looking at file name extensions???????
[11:11] <sbalneav> PauloZanoni: It doesn't
[11:13] <PauloZanoni> sbalneav: It happened only when the script was at rc2.d ...
[11:13] <PauloZanoni> there was a link to it there =)
[11:19] <PauloZanoni> sbalneav: just a correction: the link in rc2.d must have ".sh" in its name for the "bug" to be reproduced
[11:20] <sbalneav> It's not a bug.
[11:21] <sbalneav> have a look at /etc/init.d/rc
[11:21] <sbalneav>        # Debian Policy 9.3.1 requires .sh scripts in runlevel S to be sourced
[11:21] <sbalneav>         # However, some important packages currently contain .sh scripts
[11:21] <sbalneav>         # that do "exit" at some point, thus killing this process.  Bad!
[11:21] <sbalneav>         #[ S = "$runlevel" ]  && sh=.
[11:22] <PauloZanoni> sbalneav: I see....
[11:23] <PauloZanoni> sbalneav: isnt the unix philosophy to not look at file names?
[11:24] <sbalneav> Debian Policy 9.3.1 requires .sh scripts in runlevel S to be sourced
[11:24] <PauloZanoni> sbalneav: hmmm.... ok, thanks!
[11:25] <sbalneav> sometimes you may need things sourced, instead of executed separately.
[11:25] <sbalneav> if you do, you put a .sh.
[11:25] <sbalneav> it's a well defined policy for rc scripts.
[12:20] <Kopfgeldjaeger> gn8