[01:46] <_Groo_> hi/2 all.. any motu alive?
[01:49] <_Groo_> im having trouble with webkit and java in kubuntu
[01:56] <_Groo_> aparently the java plugin (sun) doesnt work with both libwebkit and qt 4.5. both midori and arora cant run the plugin, midori says is misses a symbol
[02:40] <_Groo_> eya all
[02:43] <_Groo_> any motu alive?
[02:45] <cypher1> is there anyway i can help to get the fix for bug 188468 in intrepid ? there is a debdiff already attached by someone else in the bug, but i am not not seeing it in the ubuntu packages
[03:00] <Snova> How would one go about requesting something be packaged?
[03:03] <cypher1> Snova: just curious to know is that a new package or a fix to an existing package ?
[03:05] <Snova> New package.
[03:06] <jdong> Snova: generally wave-the-wand package christmas lists don't produce much effect; would you be interested in packaging it? :)
[03:06] <Snova> I don't even know how. :) Somebody else asked if something could get packaged, I was going to tell him after finding out here. :P
[03:07] <cypher1> maybe raise a bug with the url of the package homepage may get it to the next release ?
[03:08] <persia> Well, only if someone happens to find the bug and want to package it.
[03:08] <persia> The general rule is that the person who wants to package something decides what will be packaged.
[03:08] <persia> This rule is sometimes called doocracy
[03:10] <cypher1> persia: how about bug 188468.. someone has uploaded a debdiff too.. how can i help to get that into intrepid ?
[03:11] <persia> cypher1, The patch provided actually makes the file violate the specification.
[03:11] <persia> I'm certain that isn't the correct fix.
[03:12] <persia> It's probably a missing call to dh_icons or something.  As I never encountered that issue in Intrepid, and used it for about 9 months, I doubt anyone would consider it important enough for SRU.
[03:13] <persia> (and I use epiphany-browser by preference, so I ought be affected)
[03:14] <cypher1> persia: but wouldnt these kind of bugs gets fixed and made available on intrepid-updates ? or is it as you say because of not being very important ?
[03:14] <persia> Well, the provided patches actually violate the spec, so they'd likely get ignored or rejected.
[03:15] <persia> But, yes, I don't think this is important enough for -updates (because I never saw it, and used epiphany every day in intrepid for many months).
[03:15] <persia> But I'm not one of the people who decides whether something is important enough, so I may be mistaken.
[03:15] <cypher1> persia: ok thanks.. i have this problem and i think i say some others reporting too
[03:15] <jdong> Snova: I guess technically the process is to open a bug against Ubuntu wishing for the package to be made, but it probably is like throwing a penny down the well (minus the dead mollusks)
[03:15] <persia> The problem is that it isn't in the menu at all, or that the icon is ugly until you restart the session?
[03:16] <jdong> Snova: Better to find someone interested in learning packaging to take up the job
[03:16] <Snova> jdong: More or less what I said. Thanks.
[03:16] <cypher1> persia: for me it is not there in menu.. i have restarted many times after that
[03:17] <persia> cypher1, OK.  Do you see it as disabled if you edit the menu?
[03:19] <cypher1> persia: ah.. i do see multiple entries for it in menu editor. epiphany browser and epiphany browser (gecko) and one of them has the show enabled
[03:19] <persia> And it doesn't show?
[03:20] <cypher1> no.. i tried checking the other also and now it has shown up
[03:20] <persia> Odd.
[03:20] <cypher1> let me deselect what i have just done and see whether it goes away
[03:20] <persia> https://bugs.launchpad.net/ubuntu/+source/epiphany-browser/+bug/201224/comments/6 could probably use some more investigation.
[03:20] <persia> Perhaps there's some way to change the menu handling infrastructure, but that's too much change for -updates: it would be for some future release.
[03:21] <cypher1> persia: i deselected the one i selected but the menu changed but the earlier one epiphany browser still shows
[03:21] <cypher1> so it seems my problem is solved
[03:21] <cypher1> persia: thank you very much
[03:22] <persia> cypher1, I didn't do anything, and the problem isn't fixed.  Check the comment link above: there's a race condition, and it ought be soluable.
[03:23] <persia> Just needs someone to dig into it.  I suspect your dpkg log has useful information to help understand it, so you're in a better position than most of us to track down the bug.
[03:53] <cypher1> persia: sorry i was away.. sure i will try to find the root cause..
[03:55] <persia> cypher1, Good luck: there's a lot of reasons it's nice to have .desktop files in different packages than binaries: right now most people simply duplicate the .desktop file in lots of places, which is wasteful.
[03:56] <cypher1> ok! can i contact you if i need to have some help on this bug ?
[03:57] <persia> I don't know much about it: I'd recommend asking for help in #ubuntu-desktop once you understand the race condition.
[03:57] <cypher1> ok sure.. thanks!
[04:00] <artfwo> Hi! After a sponsored package upload I've got a lot of e-mails with subjects like "Import problem - Galician (gl) - inkscape in Ubuntu Jaunty package "inkscape"" - what can I do with those?
[04:01] <artfwo> Is it safe to ignore them, or can something be done?
[04:01] <dtchen> those look like translation issues
[04:05] <dtchen> generally you'd want to fix those
[04:06] <artfwo> well, here's what launchpad said: "To fix this problem, please upload the file again, but with the 'PO-
[04:06] <artfwo> Revision-Date' field updated."
[04:06] <artfwo> but PO-revision-date field is normally updated when a translation is revised
[04:07] <artfwo> so, if a translation is unchanged, there is no sense in bumping revision-date?
[07:33] <Toadstool> g'morning
[08:44] <geser> imbrandon: are you there for the MC meeting in #ubuntu-meeting?
[08:57] <savvas> isn't there a lintian rule check about .desktop that have to be in the same binary package with the binary they represent?
[08:57] <persia> savvas, Yes, but like any lintian rule, it's not always correct (just usually correct, for most packages, most of the time).
[08:58] <persia> In the case where a given .desktop file has a very large number of translations, and long strings, it's nice to have it be in a -common package, to save archive space.
[08:58] <savvas> ah so it's not based on a debian policy :)
[08:58] <persia> But that means that it's subject to the race condition that causes the previously described bug.
[08:59] <persia> Um, well, policy follows practice, so it's somewhat murky.
[08:59] <savvas> is there anything someone could do about bug 201224?
[08:59] <savvas> logging out and back in leaves the user misguided
[08:59] <persia> As I explained earlier, all the patches presented actually break things more.
[09:00] <persia> Plus, it's probably not important enough for an SRU.
[09:00] <savvas> it's not just hardy unfortunately, it's in jaunty as well
[09:01] <savvas> it's that "race condition" between packages sebastian bacher explained
[09:01] <persia> Right, but adding the deprecated "Application" to Categories doesn't address that.
[09:02] <persia> The two ways to address it are 1) put the .desktop file in the package with the binaries, or 2) fix the menu system to not be broken.
[09:02] <persia> And 2) can be done in several different ways, of which I think processing through triggers is the least broken.
[09:03] <savvas> hm..
[09:03] <savvas> 2 sounds like a good way of fixing it
[09:04] <persia> That's what I thought :)  Mind you, it probably needs to be for Karmic, as it's invasive.
[09:04] <savvas> do you happen to know what handles the registration of desktop files? update-desktop-database ?
[09:05] <savvas> sure, I don't mind, as long as in the near future (my) users have the package available the minute it's installed :)
[09:06] <persia> I think that only processes the MIME entries.
[09:06] <savvas> ok I'll look into it a bit more
[09:06] <savvas> thanks for the tip!
[09:06] <persia> Good luck.
[09:07] <savvas> something tells me I'll need it :P
[09:56] <iulian> Is there any configuration tool for notifications?
[09:58] <jpds> No.
[09:59] <jpds> iulian: The configuration for notifications for each app are in the apps options themselves.
[10:00] <iulian> Ah-ha, thanks.
[10:56] <quadrispro> hi guys, anyone release manager here?
[10:56] <quadrispro> s/anyone/any
[10:56] <persia> quadrispro, You might try #ubuntu-release
[10:57] <quadrispro> thanks persia
[11:20] <zorael> How long does it take for a "fixed" package to hit jaunty repositories? OpenJDK has a bug that makes the IcedTea plugin not work at all (just maxes cpu), supposedly fixed in a newer version (6b14-1.4.1-0ubuntu5) as per https://bugs.launchpad.net/ubuntu/+source/openjdk-6/+bug/344705, but it doesn't seem to be in the repos
[11:31] <mok0> zorael: that depends how often the mirror updates the repo
[11:33] <mok0> zorael: it hit's Ubuntu's main archive within an hour or so
[11:40] <zorael> mok0: okay, thanks, launchpad post was ~19h ago so should pop up soon then
[11:42] <soc> flashplugin-installer requires nspluginwrapper and ia32-libs on amd64, should i file a bug about it?
[11:45] <persia> soc, Well, does the flashplugin it installs require those?
[11:46] <soc> no
[11:46] <persia> Then it's probably worth a bug.  I thought we were recommending people install adobe-flashplugin anyway.
[11:46] <soc> flashplugin.installer installs the newest alpha refresh which runs native on 64bit
[11:47] <soc> persia: adobe-flashplugin doesn't ecist, but flashplugin-installer uses the binary from adobe
[11:49] <persia> soc, It's a free/non-free thing.  adobe-flashplugin pulls a binary from adobe.  http://archive.canonical.com/ubuntu/pool/partner/a/adobe-flashplugin/ contains packaging of adobe's player under license.
[11:50] <soc> ah ... ok weird ...
[11:50] <persia> MInd you, some people may want the "free-ness" of having an open code download, but others may trust Canonical's packaging.
[11:50] <soc> mhh, there is now package for amd64 in canonical's archive
[11:51] <soc> s/now/no
[11:51] <persia> Well, it's because Debian needs flashplugin-installer, because nobody (to my knowledge) has an agreement with adobe to distribute flash for Debian, so we import it.
[11:51] <persia> Oh, hrm.  Dunno.
[11:51] <soc> imo, we should fix the dependencies of flashplugin-installer
[11:51] <persia> I think both should be fixed, but fixing the Canonical archive is outside the scope of this channel :)
[11:52] <soc> that's not about canonical's archive
[11:52] <soc> it's in universe
[11:52] <persia> Right.
[11:52] <persia> So, fix the one you can fix, and let others fix the other :)
[11:53] <soc> it has wrong dependencies, which results in 128 mb wasted
[11:53] <persia> I just remembered reading somewhere that Canonical's flash packaging was recommended, as it was a normal package, rather than being a downloader (and I also remember *many* complaints about flashplugin-installer being broken because adobe changed something on their site).
[11:54] <soc> yes, that might be true
[11:55] <soc> but canonical has no amd64 package!
[11:55] <persia> RIght,  Like I said, you probably want to fix flashplugin-installer, and let someone else fix adobe-flashplugin.
[11:55] <persia> At least one of the two should work
[11:56] <soc> yes, that's what i do
[11:56] <persia> Mind you, I'm being a bit hypocritical, as I use gnash, but still.
[11:58] <jpds> soc: There is no amd64 package for it as it's considered 'unstable'.
[11:59] <soc> yepp, so people _must_ use the package from universe ...
[11:59] <persia> jpds, That's adobe-flashplugin, or flashplugin-installer pulling the 32-bit version?
[11:59] <jpds> persia: Both.
[12:00] <persia> soc, Based on that, I'd say that the dependencies aren't the bug: that it's not downloading the 32-bit version in the bug.
[12:00] <soc> persia: huh?
[12:02] <persia> soc, from the above, I have the impression that flashplugin-installer is supposed to pull the 32-bit version, because of the apparent stability of the 64-bit version.
[12:03] <soc1> afaik there is no 32bit version that 64bit alpha prerelease ...
[12:03] <jpds> soc1: http://irclogs.ubuntu.com/2009/04/09/%23ubuntu-devel.html look 19:40 onwards.
[12:03] <pmjdebruijn> thus far the 64bit flash player has worked great over here :)
[12:03]  * pmjdebruijn thinks it's a share it's not packaged
[12:03] <jpds> See log!
[12:04] <soc1> ok, let me see if i understand that:
[12:05] <soc1> a) the version we use is unstable b) so we use the 32bit binary pulling 128mb of 32bit libraries + nspluginwrapper c) we hope that's more stable than using the 64bit binary
[12:07] <pmjdebruijn> seems so
[12:09] <pmjdebruijn> heh
[12:09] <pmjdebruijn> right
[12:09] <soc1> mhh, is there a tool to find out if a binary is a 1386 or a amd64 binary?
[12:09] <pmjdebruijn> soc1: file?
[12:09] <soc1> s/1386/i386
[12:10] <pmjdebruijn> try file
[12:10] <pmjdebruijn> anyway, too bad there aren't two packages
[12:10] <soc1> "file" worked ... -> 32bit
[12:11] <persia> soc, Which means the dependencies are correct after all.  Bug belongs to adobe: maybe they will fix it for the next cycle.
[12:11] <soc1> i wonder how that should be maintained ...
[12:11] <soc1> persia: ok
[12:12] <soc1> i guess i build me the package for personal use ...
[12:13] <soc1> manually copying things to /usr/lib/mozilla is not the way i like it ... although it works at least
[12:16] <pmjdebruijn> anyway, the current 32bit flash can't be maintained by anybody other than adobe as well, so that point is very moot
[12:40] <soc1> pmjdebruijn: i meant the whole ia32 and nspluginwrapper mess around it ...
[12:44] <persia> soc1, That's known unmaintainable.  Various people keep talking about adjusting the relevant rules files to build an ia32 variant of the libraries on amd64, but nobody every does enough of them.
[12:57] <soc1> mhh, how long does it take until an upload to my ppa appears in launchpad?
[12:57] <pmjdebruijn> soc1: yeah, but the point was, because the 64bit plugin isn't official, it can be maintained, but any binary blob can't be maintained... so wether it's beta or not... the point is moot... not even considering the nspluginwrapper mess around it
[12:58] <soc1> yes ... i understand, it's hard to get something right, if people have different views on that matter
[12:59] <soc1> i just took tha package modified it to suit my needs and i'm happy with it ...
[13:22] <t325> Hello, I'm trying to build mysql-5.1.33 from the generic source code on an Ubuntu box (not sure of the version, it's an EC2 box) with OpenSSL; cannot figure out which value I have to pass to --with-ssl= in the configure statement (--with-openssl doesn't exist anymore in the last MySQL 5.1 releases, you have to specify the path where to find the OpenSSL libs). Have the openssl package installed.
[13:22] <t325> btw is here the right place to ask?
[13:22] <persia> Probably not :)
[13:22] <persia> You might try looking in the debian/rules file of the packaged mysql server to see what happens there.
[13:23] <persia> You might try asking in #ubuntu-server, but I don't know if they support that.
[13:23] <persia> You might try asking in #mysql or similar fora
[13:24] <t325> I am trying to add new functionality to MySQL and would like to test it on Ubuntu.
[13:24] <t325> the default tree builds fine with bundled yaSSL lib, but I need OpenSSL
[13:25] <persia> right.  That's a great goal.  I'm just not sure of the best place for you to get your questions answered.
[13:25] <t325> What is the channel for developing apps on Ubuntu?
[13:25] <persia> I don't think there's any channel that specifically provides support for developing on Ubuntu
[13:25] <t325> hmm
[13:26] <persia> There's several channels that specifically don't, and many of them would send you to #ubuntu, but I'm not sure the folk there can help either, as most of them concentrate on support for using Ubuntu, rather than developing on it.
[13:26] <persia> That's why I suggest #ubuntu-server, as probably the closest.
[13:26] <t325> ok thanks
[13:26] <persia> At least it's the team that maintains mysql in Ubuntu, so you may find someone with a kindred interest.
[13:27] <persia> Or somewhere in #mysql-* in case it's more on the development side, and less on the Ubuntu side.
[13:27] <t325> no, it is Ubuntu-specific
[13:27] <persia> Yeah, then the server channel is probably the closest.
[13:28] <persia> It might be worth starting a "Developing on Ubuntu" channel.  Something like #ubuntu-app-devel
[13:28] <persia> But I doubt you'd find that many people there today (but it would be good for next time).
[13:30] <t325> yes, that would be fine.. but in fact there must be some private canonical channel about it - they just seem to have decided not to do it in public
[13:33] <persia> I doubt it.
[13:33] <persia> Most of the packages in Ubuntu are pulled from somewhere else.
[13:34] <soc1> ok, if someone wants native 64bit flash, here it is: https://launchpad.net/~soc-krg-nw/+archive/ppa package was built now
[13:34] <t325> persia: I found this explanation for doing it on Debian Etch http://talkingcode.co.uk/2007/11/12/error-2026-hy000-ssl-connection-error-the-joy-of-mysql-ssl-on-debian/ ; could you provide me some hints to adapt it to Ubuntu?
[13:35] <persia> t325, I'm really not an expert with either mysql or openssl.
[13:36] <persia> I'd expect it to be mostly the same, although intrepid is closer to lenny than etch.
[13:37] <t325> ok thanks; will try #openssl, maybe they know/care about having their stuff work with MySQL on Ubuntu..
[13:37] <persia> Good luck.  Sorry I don't know more to help you.
[15:51] <Adri2000> asac: what's the rationale for renaming flashplugin-nonfree two weeks before the final release?
[15:52] <imbrandon> morning all
[15:52] <nhandler> Hi imbrandon
[15:52] <directhex> is there a package for the 64-bit plugin yet?
[16:34] <soc1> directhex: yes
[16:35] <soc1> i made one, a few hours ago ... https://launchpad.net/~soc-krg-nw/+archive/ppa
[16:38] <directhex> i kinda meant in the real archive
[16:39] <soc1> no
[16:39] <soc1> probably for 9.10
[16:39] <soc1> i wouldn't expect, that they would change that in the middle of 9.04
[17:37] <bdmurray> What should happen with something like bug 358608?
[18:04] <leifdk1978> hello
[18:36] <leonel> scottK for the  intrepid/hardy clamav  security updates what is the plan   backport from Jaunty the packages or apply the patches to the Intrepid,Hardy clamav packages ...
[18:36] <leonel> scottK  in the debian-clamav list there are the patches for 0.94-dfsg2 version
[19:53] <hggdh> a question -- the .la files should belong to the -dev or the normal (run-time) packages?
[19:55] <Laney> neither
[19:55] <Laney> don't package them
[19:56] <Laney> (in general)
[19:57] <chrisccoulson> but if they are packaged, they tend to go in -dev
[21:38] <DawnLight> hello. is this an ok place to ask for a small project to be packaged?
[21:41] <Laney> DawnLight: not really, filing a needs-packaging bug on launchpad is
[21:42] <DawnLight> Laney: any docs on that, please?
[21:42] <Laney> https://wiki.ubuntu.com/UbuntuDevelopment/NewPackages#Requesting%20a%20new%20package%20for%20Ubuntu
[21:44] <DawnLight> thanks
[21:49] <directhex> and it'd better be an interesting project, or nobody's going to want to give away their time to you for free to work on it
[21:49] <directhex> oh, he ran away
[21:49] <sebner> directhex: you scared him :P
[21:59] <savvas> how rude!
[21:59] <savvas> :p
[21:59] <savvas> RainCT: is there any chance you might implement a backports parameter for build/create of pbuilder-dist? :)
[22:01] <directhex> RainCT is going to UDS, is he not?
[22:01] <RainCT> savvas: Good idea, patches welcome :)
[22:01] <RainCT> directhex: Yep
[22:01] <directhex> RainCT, yay! you can buy me cake! :p
[22:02] <savvas> hm...
[22:02] <savvas> hey it's python!
[22:02] <savvas> I'll see what I can do
[22:03] <savvas> RainCT: license the cake as GPL, so directhex must share it with everyone :P
[22:04] <directhex> savvas, just don't relicense from lgpl2.1 to gpl3
[22:06] <RainCT> Why would I buy directhex a cake? o_O
[22:06]  * hyperair wants cake too
[22:06] <directhex> RainCT, for awesomeness in the face of duty
[22:10] <directhex> RainCT, and to celebrate my being at UDS
[22:11] <RainCT> Heh. Get Mono out of Ubuntu and you have a chance... :D
[22:11]  * RainCT runs
[23:37] <savvas> what happened to epiphany-webkit?
[23:39] <directhex> it's hiding?
[23:39] <savvas> anyone?
[23:40] <savvas> no seriously, it was in jaunty :p
[23:40] <savvas> http://changelogs.ubuntu.com/changelogs/pool/main/e/epiphany-browser/epiphany-browser_2.26.0-0ubuntu3/changelog
[23:42] <savvas> ah wait
[23:42] <jpds> savvas: Best ask seb about that (re: 2.25.91-0ubuntu1 upload).
[23:42] <savvas>     - don't build a webkit variant the upstream tarball doesn't allow doing now,
[23:43] <savvas>       this version uses gecko and the next one will use webkit (lp: #317305)
[23:43] <savvas> found it!
[23:43] <jpds> ☺
[23:44] <savvas> now that's a tiny cute smile :)