=== ember_ is now known as ember
=== doko_ is now known as doko
[01:52] <[reed]> bryce: I can't figure out why my X is dying because silly bulletproof-x overwrites the Xorg logs when it tries to use Xorg.conf.failsafe
[01:52] <[reed]> I was told that's your fault
[01:52] <[reed]> is there a way I can work around it? :)
[01:52] <[reed]> so I can figure out what's really wrong
[01:52] <[reed]> and fix it
[01:54] <persia> [reed]: Setting the log rotation to keep a few logs, and looking in the log before last may help.
[01:55] <[reed]> where do I set that?
[01:56] <persia> [reed]: I don't remember.  I did it once, and now have .0, .1, and .2 in /var/log/  Sorry.
[01:56] <[reed]> I have Xorg.N.log(.old)? where N == 0, 9, 20... 20 is really old log from when X was working, 9 is some testserver thing, and 0 is the failsafe stuff
[01:58] <persia> [reed]: What is 1?
[01:59] <[reed]> persia: I don't have 1
[01:59] <[reed]> I only have 0, 9, and 20
[01:59] <[reed]> :/
[01:59] <persia> [reed]: Odd.
[02:00] <bryce> [reed]: hmm, I thought we'd configured bpx to only write a higher numbered log
[02:00] <bryce> [reed]: anyway, you can disable bpx entirely by commenting out the line in /etc/gdm/gdm.conf:
[02:01] <bryce> # FailsafeXServer=/etc/gdm/failsafeXServer
[02:01] <[reed]> ok, restarting with that commented out, my old (and known working) xorg.conf in place, and xorg.conf.failsafe* removed
[02:02] <bryce> one thing you could check is run /etc/gdm/failsafeDexconf, and then examine /etc/X11/xorg.conf.failsafe to see where it went wrong; the most common error I've seen is that it gets the BusID wrong
[02:03] <[reed]> all of this is because I tried out displayconfig-gtk to see if I could change the resolution on my second monitor
[02:03] <[reed]> and now X won't even start properly
[02:03] <[reed]> :(
[02:04]  * [reed] will never use displayconfig-gtk ever again
[02:04] <bryce> look at the end of /var/log/Xorg.0.log
[02:05] <[reed]> yeah, one sec... I restarted, and I'm just looking at a black screen right now
[02:05] <[reed]> so, let me get to a console and check some logs
[02:08]  * emgent hi
[02:09] <[reed]> bryce: looks like fglrx runs through a lot of modelines, sets dpi / virtual size / display dimensions, runs through more modelines, and then crashes out with a backtrace
[02:09] <[reed]> with signal 11
[02:13] <bryce> [reed]: sort of sounds like you have new gfx hardware that the drivers don't know about.
[02:13] <[reed]> like what? it's been working fine for months
[02:13] <[reed]> I haven't changed any hardware
[02:13] <[reed]> :/
[02:14] <[reed]> I did get a new 22" monitor to play with, but I backed up my xorg.conf before I changed anything, and this is crashing now with my old xorg.conf
[02:14] <[reed]> ugh
[02:14] <bryce> well, you're not giving me much information, and so I'm limited to making guesses
[02:14] <[reed]> ok, what info do you need, and I'll do my best to give it to you :)
[02:16] <bryce> https://wiki.ubuntu.com/X/Debugging - see "What to Include in Bug Reports"
[02:17] <[reed]> ok, coming right tup
[02:17] <[reed]> -t
=== zen-afk is now known as zenrox
[02:33] <[reed]> bryce: http://primedirective.net/xorg/
[02:33] <[reed]> let me know if you need anything else
[03:11] <bryce> your backtrace matches bug 165068
[03:11] <ubotu> Launchpad bug 165068 in linux-restricted-modules-2.6.8.1 "Enabling restricted driver causes X to start in low graphics mode, defaulting to a failsafe vesa driver" [Undecided,New] https://launchpad.net/bugs/165068
[03:21] <[reed]> ok
[03:21] <[reed]> brb
[03:26] <lamont> kobodeluxe 0.4.1-1ubuntu1
[03:26]  * lamont phears what we changed.
[03:31] <LaserJock> maybe it's Ubuntu branded ;-)
[03:37] <Fujitsu> lamont: Phear the .desktop revolution.
=== asac_ is now known as asac
[04:47] <[reed]> bryce: going to try the latest driver now
=== bddebian2 is now known as bddebian
[05:41] <nixternal> siretart: you know there are problems with xine-lib right? you have libxine-dev deps on libxine1 which has been replaced with libxine1-bin
[05:58] <fabio> hello
[05:58] <fabio> im new here
[05:58] <fabio> im translator of portuguese
[06:01] <fabio> 	
[06:01] <fabio> Everyone is asleep»
[06:02] <Burgundavia> fabio: try #ubuntu-pt
[06:03] <fabio> burgundavia: hello friend
[06:03] <fabio> thanks for the tip
[06:06] <nixternal> siretart: also an issue with libxine1-dbg dep on libxine1
[06:06] <persia> nixternal: Does shlibs still define libxine1 as the dep?
[06:06] <nixternal> no
[06:07] <nixternal> libxine-dev and libxine1-dbg had libxine1 in the deps
[06:08] <nixternal> I am rebuilding on my amd64 box so I can install it on my other amd64 box to get kde4 to build...so all of it has worked thus far after a change for libxine-dev
[06:30] <nixternal> woohoo, rebuilt xine-lib locally..removed libxine1, and then s/libxine1/libxine1-bin/ for -dbg and -dev build-deps and it is working like a champ
[06:56] <siretart> nixternal: ops, you're right. working on it
[06:56] <nixternal> siretart: no biggy, very simple fix...already did it locally and tested it..works great
[06:57] <nixternal> libxine-dev and libxine1-dbg need libxine1 changed to libxine1-bin...I think that is all I fixed to get it to build
[06:57] <nixternal> and seeing as libxine1-bin replaces libxine1, can you just rip that from control so it doesn't build that as well? not 100% sure on the rules there...you have to file a removal request probably I would assume
[06:58] <siretart> libxine1 cannot be dropped before hardy
[06:59] <persia> siretart: Could it be a transition package, with versioned conflicts for libxine1-bin, so both the meaningless transitional library and the replacement could be simultaneously installed?
[07:02] <siretart> persia: it is already (more or less)
[07:03] <persia> siretart: OK.  I just got libxine1 knocked out when doing the last upgrade (maybe 10 hours ago), but it could be a local issue.
[07:03] <siretart> yes, the conflict is wrong, fixing that
[07:03] <nixternal> that is because libxine1-bin replaces (<< libxine1) iirc
[07:07] <warp10> Hi all!
[07:10] <siretart> nixternal: fixed package uploaded
[07:11] <nixternal> and why do you rock hardcore again? :)
[07:11] <nixternal> thanks siretart...I figured it was just easier to bug ya about it as I knew you would be around shortly
[07:13] <siretart> nixternal: yes, in this case this was indeed better, because I applied the fix to the debian packaging branch first, and merged that into the ubuntu hg branch
[07:13] <siretart> -4 should really be a sync candidate, so that we can finally drop the diversion
[07:14] <nixternal> ya, that was another reason for poking ya, plus by the time I got everything figured out, you were here anyways :)
[07:14] <nixternal> I would have filed a bug and hit submit...waste of a bug number..plus didn't feel like adding to the stats for boogs :)
=== elkbuntu_ is now known as elkbuntu
=== stu1 is now known as stub
[08:43] <geser> good morning
[08:45] <dholbach> good morning
[08:46] <Mithrandir> hm, I thought the cups PDF thingy wasn't supposed to overwrite files?
[08:48] <soren> Mithrandir: Dream on.
[08:53] <soren> Mithrandir: There might be a hug in it for you, if you fix it?
[08:54] <Mithrandir> soren: currently I'm angry over so much b0rkedness here that I'm not going to do it now.
[08:55]  * soren pats Mithrandir
[08:55] <soren> There, there.
[09:08] <lool> doko: Sorry to bug you about this, but since the fontconfig merge, I have had ugly fonts in firefox here so I guess it is something I should be fixing on my side, do you have a pointer on this?
[09:09] <lool> I think pitti had the problem the same day I did, dunno if he found a workaround
[09:10] <doko> lool: hmm, I forgot about that; have to check in the new year ...
[09:10] <lool> Okay
[10:23] <soren> cjwatson_: Do you happen to know who maintains the gfxboot patch in SuSE? I want to send the updated patch back to them.
[10:24] <soren> seb128: Hi!
[10:24] <seb128> hey soren
[10:24] <soren> seb128: The consolekit patch seems to work brilliantly.
[10:24] <soren> seb128: Thanks!
[10:24] <seb128> soren: good, thanks for testing :-)
[10:24] <soren> :)
[10:26] <Kmos> the sparc buildd is fixed? there are several of that need a given-back on there
[10:29] <geser> Kmos: I'd say no as there is a new log for sparc with the same error from the last hour
[10:32] <Kmos> geser: we should wait.. thanks
[10:32] <Mithrandir> Kmos: we'll give back all those once we've fixed the problem.  No need to ask for each of them.
[10:32] <Kmos> Mithrandir: ok, thanks
=== seb128_ is now known as seb128
[10:45] <geser> Mithrandir: please give-back: tklib. Thanks.
[10:51] <soren> At what point will the buildd's start picking a package as a build-dependency? As soon as Launchpad says it's built or not until it's been published?
[10:52] <Mithrandir> geser: given-back
=== pedro is now known as pedro_
=== iSchnee is now known as Schneeflocke
=== pedro__ is now known as pedro_
[11:42] <Riddell> Mithrandir: please give back kdepimlibs/4:3.97.0-1ubuntu3 (since you seem to be the giving back type today)
=== dholbach_ is now known as dholbach
[11:43] <Mithrandir> Riddell: given-back
[11:45] <Mithrandir> doko: there's nothing special we need to do wrt java on lpia?  You're working on icedtea and all that shiny, right?
[12:01]  * soren kicks java.. hard!
[12:25]  * Hobbsee waves
=== illovae is now known as Pere_Noel
[12:54] <dholbach> MOTU Q&A session in 6 minutes in #ubuntu-classroom
[13:11] <tkamppeter> Is the OpenOffice.org packager here?
[13:11] <Hobbsee> calc is not
[13:12] <tkamppeter> problem is that "apt-get dist-upgrade" on Hardy wants to uninstall OOo.
[13:14] <ion_> Often such things are due to some parts of a huge project having been built, and others being still in the queue. Unless something is actually wrong in the packaging, that problem often goes away by time.
[13:15] <tkamppeter> ion_ it is the case now for more than one week. I hope our build servers are not that time behind.
[13:17] <ion_> apt-get -o Debug::pkgProblemResolver=true -V dist-upgrade might print useful information.
[13:17] <Hobbsee> tkamppeter: the less OOo builds, the better.
[13:17] <Hobbsee> it's probably waiting for a bigger change
[13:18] <tkamppeter> I have stepped back to "apt-get upgrade" now to get the more than 200 packages updated which queued up in that week.
[13:35]  * soren kicks the sparc buildd
[13:36] <dholbach> soren is angry today
[13:36] <StevenK> He's kicking everything
[13:36] <soren> I've just spent >1½h trying to get java working.
[13:36] <soren> That will make anyone angry.
[13:37] <ion_> That’s one of Java’s features.
[13:37] <dholbach> soren: did you chat with doko about it?
[13:37] <soren> And when I finally got it to work (in a gutsy vmware instance), the frickin' applet didn't work properly with firefox.
[13:39] <soren> dholbach: No.. It was not so much a debugging-and-making-notes-along-the-way kind of thing, but more of a get-the-bloody-thing-to-bloody-work-right-bloody-now-'cause-I-just-don't-want-to-know-about-it session.
[13:40] <soren> Lots of files were copied around, symlinks were created, swear words were invented, core dumps removed..
[13:40]  * soren grrrrrs
[13:40] <soren> I just want to forget it ever happened.
[13:41] <tkamppeter> -ion I have tried "apt-get -o Debug::pkgProblemResolver=true -V dist-upgrade" and it seems that OOo depends on an old version of libhsqldb-java and so the update of libhsqldb-java triggers the removal of OOo
[13:42] <persia> tkamppeter: During this period of agressive archive churn, you may find aptitude's conservative update behaviour helpful.
[13:48] <doko> soren: gutsy, or hardy?
[14:06] <doko> soren: amd64?
[14:08] <Mithrandir> doko: hiya, did you see my question about lpia and icedtea?
[14:08] <Mithrandir> (or the stock JRE)
[14:12] <doko> Mithrandir: no difference compared to i386 (currently ftb on the buildd); don't know why
=== mvo_ is now known as mvo
[14:13] <Mithrandir> doko: good to hear (well, the no difference part, not the ftbfs part).  You don't need us (the mobile team) to do anything in particular for java apps and the web browser plugin to work, then?
[14:13] <doko> Mithrandir: not currently
[14:14] <Mithrandir> doko: ok, thanks.
[14:15] <soren> doko: hardy. Both i386 and amd64.
[14:16] <soren> doko: on amd64, j2re1.4 makes firefox crash whenever I access a page with java on it. On i386 I just couldn't get anything to really work at all.
[14:17] <doko> j2re1.4? how about icedtea?
[14:24] <Keybuk> there's stuff in the installer that calls udevinfo directly, isn't there?
[14:25] <Mithrandir> there's stuff in casper that does, at least.
[14:25] <Keybuk> bugger
[14:25] <soren> doko: It doesn't provide a plugin for mozilla, does it?
[14:26] <doko> soren: icedtea-java7-plugin
[14:27]  * soren takes it for a spin
[14:29] <soren> doko: Well, it shows up in about:plugins, but the test thing on java.sun.com doesn't seem to work.
[14:30] <soren> doko: It just leaves a grey box where the cool stuff should be.
[14:31] <doko> soren: amd64?
[14:31] <soren> doko: Yes.
[14:31] <doko> on gutsy?
[14:31] <soren> doko: Hardy.
[14:32] <doko> strange
[14:32] <soren> doko: Sorry, I'll try to be more explicit.
[14:32] <doko> did work for me. start firefox from a terminal and look at the output. my test was to open classpath.org (and seeing the man stomping the fork)
[14:34] <Mithrandir> Keybuk: why is that a problem?
[14:34] <soren> doko: No go. I has saved a log file for me.
[14:34] <soren> doko: You want it?
[14:36] <soren> doko: Ah, there's an update for icedtea-java7-bin
[14:36] <soren> doko: I'll try again.
[14:37] <soren> No luck.
[14:41] <soren> doko: Exact same thing happens on hardy i386.
[14:43] <doko> soren: ok, I'll have it running here. strange. have to look at it after xmas
[14:44] <soren> doko: Will the hs_err_pidXXXX.log files be of any use to you?
[14:46] <doko> soren: not really, there's a bug report with some duplicates which have these as well.
[14:46] <soren> doko: They all say "#  SIGSEGV (0xb) at pc=some_address pid=some_pid tid=some_tid" at the top.
[14:46] <soren> doko: Ah, bug 152362 ?
[14:46] <ubotu> Launchpad bug 152362 in icedtea-java7 "icedtea-java7-plugin always crashes firefox" [High,Confirmed] https://launchpad.net/bugs/152362
[14:46] <doko> soren: one thing you could try: build the package locally and try again. we had problems with the package built on the buildd before
[14:47] <soren> doko: My firefox doesn't crash. The applet just never does anything useful.
[14:47] <doko> soren: maybe ask tmarble (#ubuntu-java) as well
[14:47] <doko> soren: hmm ... we did switch from firefox-dev to xul recently ...
[14:48] <soren> doko: As a b-d?
[14:48] <soren> doko: I can grab an older version and try that?
[14:48] <doko> soren: try it, yes
[14:49] <soren> doko: Which version should be good?
=== cprov is now known as cprov-lunch
[14:52] <soren> ..trying 7~b23-1.5~20071124-4
[14:53] <soren> Same.
[15:11] <Keybuk> weird
[15:11] <Keybuk> when I login, I get a strange "Language en_GB doesn't exist, using system default" warning
[15:15] <Spads> Keybuk: yeah, server installs don't include locales
[15:15] <Keybuk> this is a desktop
[15:16] <Spads> Ah well.  an en_US desktop?
[15:16] <Keybuk> no
[15:16] <Keybuk> an en_GB desktop
[15:17] <ion_> keybuk: I get the equivalent message.
[15:17] <Spads> I got nothing.
[15:17] <Keybuk> Spads: are you on hardy?
[15:17] <ion_> It says the same about en_US in Finnish.
[15:18] <Spads> Keybuk: nah
[15:18] <ion_> My locale settings: LANGUAGE=en_US:en LANG=fi_FI.UTF-8 LC_MESSAGES=en_US.UTF-8 LC_NUMERIC=en_US.UTF-8
[15:20] <Keybuk> LANGUAGE=en_GB:en
[15:20] <Keybuk> LANG=en_GB.UTF-8
[15:20] <Keybuk> LC_COLLATE=C
[15:20] <Keybuk> seems to be LANGUAGE it's complaining about?
[15:23] <Keybuk> (whatever "it" is - I'm grepping strings currently)
[15:24] <ion_> Whatever “it” is, “it” has a bug in a bug: it should have said the error message in English according to my locale settings. :-)
[15:34] <minghua> ion_: Do you have en_US.UTF-8 in your "locale -a" output?
[15:35] <minghua> ion_: (en_US.utf8, actually)
[15:35] <ion_> minghua: Yes.
[15:39] <minghua> ion_: I don't know, maybe try "LANGUAGE=en_US.UTF-8:en_US:en"...
[15:40] <minghua> ion_: I assume you don't have en_US in "locale -a" output?
[15:40] <ion_> minghua: I don’t think one is supposed to put .UTF-8 into LANGUAGE.
[15:40] <ion_> minghua: Yes, there’s no en_US.
[15:40] <minghua> ion_: I don't think so either, but who knows. :-)
[15:41] <minghua> Alternatively, maybe you can do something to make en_US appear in "locale -a" output and see if that helps.
[15:41] <ion_> There should be no need to do that. It used to work.
[15:43] <geser> Mithrandir: please give-back: yorick-yeti smpeg-xmms whizzytex. Thanks. (I'd have asked pitti if he were here).
=== cprov-lunch is now known as cprov
[16:03] <Mithrandir> geser: given-back
[16:04] <Keybuk> Mithrandir: was the bundle ok?
[16:04] <Mithrandir> Keybuk: looks fine to me, yes.
[16:05] <Mithrandir> Keybuk: I'm assuming you know what udevadm does and how it's called; I haven't verified that. :-)
[16:05] <Keybuk> there were unuploaded changes in the trunk, so I figured that a bundle would let you worry about the history ;)
[16:05] <Keybuk> (since merging it will make it look like you merged a branch, rather than retconning history on a new revision)
[16:07] <Mithrandir> ah, true
[16:16] <Keybuk> soren: ?
[16:16] <Keybuk> ImportError: No module named debian_bundle.changelog
[16:16] <soren> Ah, I thought someone fixed that already.
[16:16] <soren> You need python-debian
[16:18] <Keybuk> right
[16:18] <Keybuk> thanks
[16:18] <Keybuk> it gave me an editor
[16:18] <Keybuk> does it expect me to explain the patch there
[16:18] <Keybuk> or is that just to review the patch?
[16:18] <soren> First, you review the patch.
[16:18] <soren> debian/Changelog is already filtered out.
[16:19] <soren> Anything else that is not appropriate for Debian, you remove manually.
[16:19] <soren> :wq
[16:19] <soren> and then an editor shows up with the body of the bug report, which will be based on the latest entry in debian/changelog
[16:20] <Keybuk> it didn't filter out the "diff" line for debian/changelog ;)
[16:21] <soren> True.. Feel free to fix filterdiff to do that :)
=== jpatrick_ is now known as jpatrick
[16:22] <Keybuk> also you don't handle epochs properly
[16:23] <soren> How so?
[16:24] <Keybuk> epochs don't appear in filenames
[16:24] <soren> You /are/ running hardy, aren't you?
[16:24] <soren> Keybuk: Oh, good point.
[16:24] <soren> Keybuk: ubuntu-dev-tools depends on python-debian in hardy.
[16:25] <Keybuk> http://people.ubuntu.com/~scott/std.patch
[16:25] <soren> Keybuk: Thanks very much.
[16:36] <geser> Mithrandir: please give-back: texpower. Thanks.
[16:38] <Mithrandir> geser: given-back
[16:46] <alex-weej> mvo: hi.
[16:46] <alex-weej> can you prod this through please? https://bugs.launchpad.net/bugs/175646
[16:46] <ubotu> Launchpad bug 175646 in notification-daemon "Notification summaries should not be parsed as markup" [Low,Triaged]
[17:10] <ion_> Some guy is saying it’s been decided that this <http://img520.imageshack.us/img520/734/basicidealsactionattachqj1.jpg> will be 8.04’s default theme. Please say that’s not true. :-)
[17:11] <_MMA_> ion_: Thats concepts only.
[17:14] <_MMA_> https://wiki.ubuntu.com/Artwork/Incoming/Hardy/Alternate/BasicIdeals
=== evand_ is now known as evand
=== Pici` is now known as Pici
[17:43] <Riddell> cjwatson_: am I ok to create a kubuntu-kde4 seed?
[17:44] <Riddell> Mithrandir: could you give back kdebase-kde4/4:3.97.0-1ubuntu4
[18:09] <geser> slangasek: need all merges of packages in main now a freeze exception?
[18:09] <slangasek> geser: in a very limited sense, yes
[18:10] <slangasek> geser: any Ubuntu developer can "grant" a freeze exception
[18:11] <geser> I looked at texlive-bin which can be synced now and the new packages it produces would be nice to have as the would allow to install texlive-full (which now has two unmet deps)
[18:11] <slangasek> geser: don't look at me, after 5 years of bad experiences with tex packaging, I reflexively run screaming at the mention :)
[18:12] <geser> I just wanted to know what's needed to get it synced (besides the sync request)
[18:14] <slangasek> I think a sync request is sufficient generally; for texlive, if I were the one processing the request I might want some greater detail to reassure me that it's not going to blow up
[18:15] <soren> slangasek: So the lesson is: Find a miniscule patch that needs to applied, and just upload yourself?
[18:15]  * soren runs away
[18:22] <geser> slangasek: have you some ideas how that "greater detail" might look like? pbuilder build-log?
[18:22] <slangasek> geser: probably an analysis of any changes to debian/control
[18:36] <slomo> asac: can you try if http://go-mono.com/sources/gluezilla/gluezilla-1.2.6.tar.bz2 builds with new xul? :)
[18:37] <asac> slomo: wanna help? i am on holiday till jan 2 :)
[18:37] <asac> i can try it, but would appreciate to rather help then do it myself :)
[18:37] <slomo> asac: you have new xul already installed, i just want to hear if "./configure && make" worked ;)
[18:37] <slomo> but it can wait until after your holidays if you prefer that :)
[18:38] <asac> slomo: i even have gluezilla here as source :)
[18:38] <asac> and no ... it doesn't build because it doesn't look for the right pkg-config files
[18:38] <asac> (without trying)
[18:40] <slomo> ok
[18:40] <slomo> thanks
[18:42] <geser> slangasek: bug #176411 if you want to look on it
[18:42] <ubotu> Launchpad bug 176411 in texlive-bin "[Sync request] Sync texlive-bin (2007.dfsg.1-2) from Debian (main)" [Undecided,New] https://launchpad.net/bugs/176411
[18:43] <slangasek> geser: well, /looks/ safe to me... :)
[19:08] <mvo__> alex-weej: thanks, I check out 175646
[19:08] <alex-weej> cool
=== ion__ is now known as ion_
[19:19] <geser> Mithrandir: please give-back: libchipcard offlineimap c++-annotations cffi. Thanks.
[19:39] <ivoks> Burgundavia: heh, regarding your blog post :)
[20:08] <ScottK> I notice that there are a few backports builds for AMD64 on Gutsy that have been sitting and waiting for quite some time while the buildds are idle.  Is there an issue with the Gutsy AMD64 buildd?
[20:10] <infinity> ScottK: Which builds?
[20:10] <ScottK> infinity: https://edge.launchpad.net/ubuntu/+source/dkim-milter/2.4.0.dfsg-1ubuntu2~gutsy1/+build/470770 is the one I was waiting for.
[20:10] <ScottK> When I looked at needs-building I saw at least one other.
[20:12] <infinity> ScottK: At a guess, I'd say it's just been backlogged behing hardy builds...
[20:13] <ScottK> infinity: OK.  I'd thought it was different machines.  That makes sense.  Thanks.
[20:13] <infinity> ScottK: Nah, it's all the same hardware, and *-backports comes last in the queue.
[20:13] <infinity> updates -> proposed -> release -> backports.
[20:14] <infinity> (security is on different gear)
[20:14] <ScottK> Sure.  Makes sense.  Thanks.
=== cprov is now known as cprov-away
[20:19] <imbrandon> ugh ok, i have a problem, about to email the ML about it but i thought i would kick it arround here first, as most know adobe released a new flash ( 9,0,115,0 ) and i have the updated flashplugin-nonfree in hardy and an SRU in -proposed ... here is the issue
[20:20] <imbrandon> it works perfect with geko based browsers as reported on the bug, but it breaks Konquorer due to a bug that only this flash exposes
[20:20] <imbrandon> so if a SRU is pushed ALL konqueror flash installs get broke, but if its not pushed then all new installs are broke
[20:21] <ScottK> imbrandon: The first thing I'd do is mention that in the bug if it's not already.
[20:21] <imbrandon> and hardy is broke, soooo do we update and then SRU a patch to konqueror also when it becomes available ? or ....
[20:21] <imbrandon> ScottK: it is
[20:21] <ScottK> OK.
[20:22] <imbrandon> see my delima though ? its like leave it broken or fix some people and knowingly break others
[20:23] <ScottK> Yeah.
[20:23] <imbrandon> i hate binary blobs
[20:23]  * ScottK too.
[20:23] <ScottK> Well your a Kubuntu dev, where's the Konqueror SRU to go with it? ;-)
[20:23] <imbrandon> there is no fix ( even upstream yet )
[20:23] <imbrandon> and likely wont be soon
[20:24] <imbrandon> as it requires konqueror to support XEmbed ( a new feature that might not be SRU worthy anyhow )
[20:24] <ScottK> Is it something we could figure out in Kubuntu if we focused on it?  We'll need it fixed for Hardy.
[20:24] <imbrandon> add XEmbed to konqueror heh
[20:24]  * ScottK is just saying...
[20:25] <imbrandon> no no i totaly understand, but thats the fix
[20:25] <ScottK> OK.  So how hard is that?  Maybe we should --> #kubuntu-devel
[20:26] <imbrandon> the only other options ( none will go over well with users ) is not support flash-nonfree in konqueror OR only support gnash
[20:26] <imbrandon> have them conflict
[20:26] <imbrandon> or something
[20:26] <imbrandon> ScottK: k
=== ivoks_ is now known as ivoks
[20:50] <alex-weej> mvo_: happy with the patch?
[21:09] <mvo_> alex-weej: patch is fine. if you don't like the patch stuff, maybe we can do something else? instead of a patch in debian/patches just include it inline in the package?
[21:09] <mvo_> alex-weej: and/or put it into bzr
[21:10] <alex-weej> i just think it's inefficient to roll out a new notification-daemon every time we change our theme
[21:10] <alex-weej> is all :)
[21:10] <alex-weej> doesn't really bother me that much though, i just remembered you talking about it before
[21:10] <mvo_> yeah
[21:11] <mvo_> its really not ideal this way, I think the best course of action is to try to get it upstream
[21:11] <mvo_> but last I talked about it, he didn't like the yellow :)
[21:11] <alex-weej> well this is the thing, we don't put ubuntulooks in upstream gtk-engines
[21:11] <alex-weej> why should we do it for the notification daemon theme?
[21:12] <Chipzz> alex-weej: you could also reverse the question
[21:13] <Chipzz> why don't we put ubuntu-looks in upstream gtk-engines? there may be some people who like it and want to use it, who aren't running ubuntu
[21:13] <Chipzz> and ubuntu-looks is not a patch I suppose, rather a seperate engine
[21:13] <alex-weej> Chipzz: and at that point, we basically relinquish control over the theme to gtk-engines maints
[21:14] <Chipzz> how so? you would be upstream, pushing changes to gtk-engines
[21:14] <alex-weej> heh
[21:14] <alex-weej> assuming i have commit access
[21:14] <Chipzz> alex-weej: point being, notification daemon is a patch, gtk-engines is a seperate engine
[21:14] <alex-weej> no
[21:14] <alex-weej> notification daemon theme is an engine too
[21:14] <alex-weej> it's its own sofile
[21:15] <mvo_> yeah, we could put it into its own source package
[21:15] <Chipzz> heh. then I misunderstood
[21:15] <alex-weej> and maintain it in bzr
[21:17] <somerville32> There is a bug in the linux kernel that prevents xfce4-battery-plugin from compiling and I'd like to have this merge done for the next alpha because it contains important patches we'd like tested. Basically, apm_event{,info}_t are userspace types but they got hidden behind #ifdef __KERNEL__ by mistake in commit ee8e7cfe9d330d6f1ce0b9b1620d6df5d9cf6b70
[21:18] <Chipzz> (alex-weej: as an aside; yes there are people actually doing that (I think); a friend of mine made a post about it in his blog)
[21:18] <somerville32> I imagine this might also cause other applications (such as xscreensaver) from compiling
[21:18] <alex-weej> Chipzz: doing what?
[21:18] <geser> somerville32: could you tell me when this is fixed as I've seen also other packages FTBFS because of this?
[21:18] <Chipzz> alex-weej: using ubuntu gtk-engine outside of ubuntu
[21:18]  * somerville32 nods at geser 
[21:19] <somerville32> geser, I was actually wondering if maybe the kernel team would be willing to apply the very non-evasive patch to fix this in the mean time
[21:19] <alex-weej> Chipzz: foresight do it, iirc
[21:20] <slangasek> somerville32: addressing yourself directly to the kernel team (by name, or in #ubuntu-kernel) is probably going to be more effective at getting you an answer
[21:22] <somerville32> slangasek, ok
[21:23] <Lutin> would anybody have a look at bug #173717 ?
[21:23] <ubotu> Launchpad bug 173717 in grub "Grub has a build-depends-indep against a multiverse package" [High,New] https://launchpad.net/bugs/173717
[21:27] <slangasek> oh, clever; there are two copies of mkisofs in gutsy and hardy, even, one in multiverse and one (the dummy package) in main
[21:28] <slangasek> someone should've forced package name changes on cdrtools when it was reintroducde
[21:28] <slangasek> Lutin: well, I've looked but I can't upload it ;)
[21:28] <mjg59> I'm sure the one in multiverse was supposed to have been removed
[21:29] <mjg59> The licensing is still inconsistent
[21:29] <slangasek> oh?  no bug report about it assigned to ubuntu-archive
[21:30] <mjg59> Ah. I'd discussed it in email with elmo, but never actually filed a bug
[21:30] <mjg59> CDDLed code linking against GPLed library without any exemptions
[21:30] <Lutin> slangasek: ok :)
[21:31] <mjg59> I need to email Jörg back about that, but haven't had time yet
[21:32] <slangasek> mjg59: could you file a bug report if you want it removed in the meantime, so I have something I can act on (and point to :)?
[21:33] <mjg59> Can't make promises about when it'll happen, but yeah
[21:37] <alex-weej> Chipzz: oh, gtk engine, hm dunno then. foresight use our notification theme
[21:53] <smcintyre> bug 102982
[21:53] <ubotu> Launchpad bug 102982 in linux-source-2.6.22 "intel_rng: FWH not detected " [Low,Confirmed] https://launchpad.net/bugs/102982
[21:55] <smcintyre> Would that bug ^^^ relate to my not being able to reboot?
[21:56] <mjg59> No
[21:56] <smcintyre> Hmm ok
[21:57] <mjg59> Given that that's not a bug, merely an informational message
[21:57] <smcintyre> failed to reset NO_REBOOT flag, reboot disabled by hardware
[21:57] <smcintyre> that's my informational message
[22:00] <smcintyre> Which I would suppose relates to my not being able to reboot :)
[22:00] <mjg59> That's not related to the bug you mentioned...
[22:00] <mjg59> And again, no, that won't prevent you from rebooting - that's only relevant for the hardware watchdog
[22:01] <smcintyre> Ok I saw on the forums that they might be related and that page comes up when you search for the error message and Ubuntu
[22:01] <smcintyre> So I guess there is no known workaround?
[22:02] <mjg59> The messages you're getting are unrelated to your inability to reboot
[22:02] <mjg59> So you should open a new bug about that
[22:02] <smcintyre> mjg59: What?
[22:03] <smcintyre> mjg59: The message reboot disabled by hardware is not related to my not being able to reboot?
[22:03] <mjg59> smcintyre: Correct. It's only referring to the hardware watchdog, which isn't generally used.
[22:03] <smcintyre> Ah
[22:03] <mjg59> The watchdog is a piece of hardware that automatically reboots the system if the kernel hangs
[22:03] <smcintyre> mjg59: Anyway I can get more information as to where reboot stops since that should help you
[22:03] <mjg59> Yeah. It ought to be a new bug, though.
[22:03] <smcintyre> mjg59: I see :) thanks for that info
[22:04] <smcintyre> hi Hobbsee!
[22:04] <smcintyre> mjg59: ok I have to run right now but I'll bug it later today
[22:04] <Hobbsee> heya!
[22:04] <smcintyre> thanks for the insight
[22:05] <mjg59> No problem
[22:07] <smcintyre> mjg59: Would reboot abilty from the Live CD be helpful in the bug?
[22:08] <smcintyre> mjg59: I get libhal errors on shutdown (which works) would that be more related?
[22:09] <mjg59> Nope, hal can't really interfere with reboots
[22:09] <mjg59> ANd yeah, the liveCD should be a perfectly fair test
[22:09] <smcintyre> Ok heading out then.
[22:18] <ion_> Yay for tracker-applet.
[22:19] <somerville32> TheMuso, ping
[22:20] <somerville32> TheMuso, Can you come for a visit in #ubuntu-artwork?
[22:33] <Mithrandir> geser,Riddell: given-back
[22:34] <geser> Hi Hobbsee
[22:35] <Hobbsee> hey geser!
[22:39] <soren> eroyf: /win 7
[22:39] <soren> doh..
[22:43] <mekius> anyone know anything about pata_via?
[22:50] <soren> mekius: that's not really the question you need answered anyway, is it?
[23:03] <mekius> soren: :)
[23:03] <mekius> soren: Well I'm mostly wondering why it's not included
[23:03] <soren> No idea.
[23:04] <mekius> soren: k
[23:05] <mekius> we need it for some hardware and was hoping to avoid an extra package