[03:05] <achiang> how do i 'push' patches if the patch system is cdbs? i want to see what the source code looks like when all patches are applied
[03:46] <broder> achiang: i'm pretty sure you can run debian/rules patch
[03:49] <achiang> broder: hm. ok, i'll try that. (my workaround was to say cdbs-edit-patch <name of patch i want to go to>)
[03:49] <achiang> and then issuing exit 1 after i was done looking at the source
[03:59] <achiang> broder: yep, that worked, thanks
[03:59] <broder> np
[05:04] <AtomicSpark> So I have questions! What patches does MOTU apply to Netbeans. Why is the Launchpad project page for it seem to be dead/not touch since 5.x. How do I poke someone to get on the 7.x release which has been RC forever and just released into Ubuntu+2? Etc.
[05:05] <lifeless> AtomicSpark: which launchpad page ? (there are upstream pages and ubuntu pages, the distinction does matter)
[05:06] <AtomicSpark> The Ubuntu package page links to https://launchpad.net/netbeans
[05:06] <AtomicSpark> Which adds packages but doesn't seem to be used for a project. Series and milestones, etc only lists version 5.
[05:07] <lifeless> right
[05:07] <lifeless> launchpad is many things
[05:07] <lifeless> among them are:
[05:08] <lifeless>  - a software forge where software development tools (bugtracker etc) can be used in developing software
[05:08] <lifeless>  - a directory where software *developed elsewhere* can be listed and important metadata added
[05:09] <lifeless> https://launchpad.net/netbeans has on its front a link to the real home page - 'Home page' -> http://www.netbeans.org/products/platform/
[05:09] <lifeless> so its in the second category
[05:14] <AtomicSpark> It looks like the ubuntu package just adds Software Center metadata to it.
[05:15] <lifeless> and packaging rules I expect
[05:15] <lifeless> the diff on the source package page is authoritative
[05:17] <lifeless> https://launchpad.net/ubuntu/+archive/primary/+files/netbeans_6.9-0ubuntu2.diff.gz
[05:17] <lifeless> (from https://launchpad.net/ubuntu/+source/netbeans/6.9-0ubuntu2)
[05:20] <AtomicSpark> Netbeans is incredibly outdated in Debian. Even in sid. Looks like it needs maintainers.
[05:20] <AtomicSpark> Sad, Eclipse doesn't handle J2EE stuff very well.
[05:21] <micahg> AtomicSpark: in the past, someone from sun was updating it
[05:24] <AtomicSpark> Well. Maybe now that 7.0 is relased, someone will magically package it for 11.10.
[05:26] <micahg> AtomicSpark: feel free to give it a shot :)
[05:31] <AtomicSpark> micahg: I just might do that. Hopefully the dependancies haven't changed/we get a build failure. Debian seems to be having issues with Netbeans. Was reading http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=543907
[05:38] <micahg> AtomicSpark: you might want to join the Debian pkg-java team and ask what you can do to help
[08:01] <dholbach> good morning
[08:46] <laszlok> I am the upstream maintainer for glipper (a clipboard gnome applet). Who should I contact about getting the new version with app indicator support from my PPA into universe? (Otherwise the app is useless in Unity)
[08:49] <dholbach> hey laszlok, try https://wiki.ubuntu.com/SponsorshipProcess
[08:50] <dholbach> laszlok, best to file a bug on the ubuntu package and link to the ppa package and subscribe ubuntu-sponsors (and ubuntu-release because we're after almost all freeze dates already)
[08:53] <laszlok> dholbach: so I can just subscribe ubuntu-sponsors, and they will notice it, or should I follow up?
[08:54] <dholbach> they will notice it
[08:54] <dholbach> if they have questions/concerns they'll leave comments in the bug
[08:55] <laszlok> ok thanks
[10:07]  * laszlok hugs dholbach 
[10:36]  * dholbach hugs laszlok back :)
[11:52] <evaluate> Hello.
[11:54] <evaluate> A package of mine seems to have problems with the application indicator fallback. That means if the program is compiled with application indicator support, but the user doesn't use the indicator, but the systray, the app crashes.
[11:54] <evaluate> I'm not sure where exactly the problem is, but I'd guess it's with the application indicator fallback, since both the application indicator and the program compiled without the indicator support work perfectly fine.
[11:56] <evaluate> I thought about having the normal package and then an additional package -indicator. The normal would be built without indicator support and the -indicator one with indicator support and they could 'Conflict' with each other, so that a user can't have them both installed. This would solve the problems, I'm not sure if this is acceptable though...
[11:58] <evaluate> Also, I'd regard the bug report as RC (since the program isn't usable at all if the user doesn't use the indicator), I can't change it accordingly though. Is there any way to give a user access to manipulate bugs for a single package?
[12:22] <sladen> hello evaluate, just reading your long post
[12:22] <evaluate> Sure, take your time. :-)
[12:23] <sladen> evaluate: okay, first dumb question.  Which package/program, and are there any bug numbers already filed in the bug tracker?
[12:24] <sladen> evaluate: (my apologies if I missed it in the above)
[12:24] <evaluate> sladen, no, it was my bad that I didn't mention it. The package I'm talking about is 'clipit' and the bug is #702316
[12:24] <evaluate> https://bugs.launchpad.net/ubuntu/+source/clipit/+bug/702316
[12:34] <evaluate> sladen, so basically from what I can tell, there would be 3 solutions to this problem. Either the ayatana guys fix the fallback, which I find highly unlikely in the remaining time until the relaease, or clipit should drop indicator support for good or offer 2 packages to users, one with indicator support, the other one without.
[12:35] <sladen> evaluate: I've updated the description for the bug to try and give a better high-level context.  Would you be able to read it over and confirm that it's accurate (I've had to guess/fill in the gaps)
[12:36] <sladen> evaluate: all very good solutions; but before we can figure out /solutions/ we need to work out the problem, and how to reproduce it!
[12:37] <evaluate> sladen, description looks good to me.
[12:37] <evaluate> Thing is, I think fluxbox doesn't have indicator support, but the old systray, that is the reason for the crash and that is also the reason why under a default natty install it works fine.
[12:38] <evaluate> I can easily reproduce the bug in maverick if I install clipit with indicator support and let it run in the systray.
[12:38] <sladen> evaluate: I get a dropbox menu with "About" "Manage History" " Preferences" "Quit"  Is that the fallback
[12:38] <sladen> evaluate: (this is on natty)
[12:38] <sladen> evaluate: oh.  So this bug is *only* about fluxbox?
[12:39] <sladen> evaluate: and nothing in the default configuration?
[12:39] <evaluate> Not sure if that's the fallback or not, let me explain a little.
[12:40] <evaluate> Not all desktop managers support the application indicator and thus, the ayatana guys have written a 'fallback' so that: if I write my program with indicator code (which is a bit different from the systray code) and then run it under a DE which doesn't support indicators, the application indicator automatically applies a fallback, so the program runs just like if it was written with systray code.
[12:40] <evaluate> Hope that makes sense, English isn't my first language...
[12:42] <evaluate> That means, clipit normally is built with indicator support under ubuntu. Under the normal DE, which supports applications indicators, it works perfectly fine, but if a user runs a DE which doesn't support application indicators, the fallback gets applied, which is buggy and makes the program crash X
[12:43] <evaluate> I'm not sure where this fallback exactly lives, if I were to guess, I would say it's probably in the patched GTK code that the ayatan guys have done...
[12:43] <evaluate> ayatana*
[12:44] <evaluate> Also, the bug is not *only* about fluxbox, it's about all DEs that don't support application indicators.
[12:48] <sladen> evaluate: could you pop into #ayatana
[12:56] <sladen> evaluate: could you also click edit and expand the bit about "Parcellite" to give more context.  I don't know what that reference currently is (is it relevant?)
[12:57] <sladen> evaluate: is it saying that Parcellite doesn't cause a crash?
[12:58] <evaluate> Joined #ayatana.
[12:59] <evaluate> Regarding Parcellite, thing is, clipit is forked from Parcellite, so it may be that installing both programs wouldn't work well, I didn't investigate that closely yet.
[13:05] <evaluate> I also think this can be set to 'Confirmed', since there is an easy way to reproduce the bug (at least in maverick there is)
[13:06] <evaluate> And I'm pretty sure that running it in a DE that doesn't support indicators under natty does the exact same thing...
[13:10] <evaluate> I just installed Parcellite too and ran both clipit and Parcellite together and can't see anything misfunctioning. I think that part needs more expanding from the person that reported the bug...
[17:27] <bdmurray> tumbleweed: I've fixed my ubuntu-dev-tools merge proposal based on your feedback