[00:01] <pochu> mrooney: if only a few files are licensed under the CC license, after the GPL license, say something like "For $(files), the following license applies:" and then put the license
[00:01] <pochu> mrooney: e.g. http://packages.debian.org/changelogs/pool/main/e/emesene/emesene_1.0.1-2/emesene.copyright
[00:02] <pochu> that has the GPL for the application, but a few files are licensed under different terms
[00:06] <mrooney> pochu: what can I use to handle line lengths and indentations correctly, to fit in the specs for `copyright` ?
[00:06] <mrooney> for http://creativecommons.org/licenses/by/2.5/legalcode
[00:07] <pochu> no idea
[00:07] <pochu> I just copy&paste, and try to fit everything in 80 chars lines
[00:08] <pochu> are you following the new copyright format proposal?
[00:08] <pochu> if so, look at the specification :)
[00:10] <mrooney> pochu: well I mean it isn't within 80 chars and it is long, I don't want to trim it by hand
[00:10] <ScottK> m3ga: Hello.
[00:11] <ScottK> m3ga: Automatic syncing is all done from Sid, but we can pull from both Testing and Experimental if needed.
[00:11] <ScottK> We're past the point in this release cycle where it happens automatically now, so now would be a good time to do rebuilds to get things sequenced correctly.
[00:17] <m3ga> ScottK: i think the problem is that lanaguages like ocaml and haskell require a little more care in the packaging and that there hasn't been enough expert care in this area.
[00:17] <pochu> mrooney: if you leave it as is, does lintian complain?
[00:17] <pochu> mrooney: if not, I think you can leave it as is
[00:18] <ScottK> m3ga: As I understand it they have to be built in a certain sequence that our automated and semi-automated methods don't support.
[00:18] <ScottK> m3ga: I think that's a different way of saying the same thing.
[00:20] <m3ga> ScottK: i've got two packages in intrepid (one ocaml and one haskell) which are broken. i'll do an analysis of why and report back.
[00:20] <ScottK> m3ga: OK.  If you can look at Jaunty too, that would be very useful as this stuff is much harder to fix post-release.
[00:22] <m3ga> ScottK: yeah, i have jaunty in a vm. i'll  test there as well. However, my experience of the last several releases of ubuntu is that for ocaml libraries, it always a different one thats broken in some subtle way.
[00:24] <asomething> mrooney: I don't know what the diff between cc-by and cc-by-sa is, but human-icon-theme seems to have cc-by-sa 2.5 already formated. Might mean less work for you
[00:24] <ScottK> m3ga: This has come up before and I think the issue is they have to be built in a certain order.
[00:25] <mrooney> asomething: ahh cool, I'll look into that, thanks!
[00:26] <ScottK> m3ga: What we need is someone who understands the language/packages to help us get them sequenced right.
[00:32] <m3ga> ScottK: i think the problem is better solved by software tools rather than man power  :-)
[00:32] <ScottK> m3ga: All I need is the tool then.
[00:35] <RAOF> Wasn't the issue that some hash of the dependencies was encoded into each build, and so you needed to ensure that each rebuild of a node triggered the rebuild of all children?
[00:36] <m3ga> ScottK: I need to  do a little research and testing.
[00:36] <ScottK> m3ga: OK.  Let us know.
[02:22] <RAOF> I take it no-one is shephearding Banshee through the various gnome-sharp transitions?
[02:37] <_16aR_> Hello
[02:38] <RAOF> Hi
[02:38] <_16aR_> I have a question. I'm packaging a little software
[02:38] <_16aR_> So I thought I should post a need-packaging bugreport on launchpad first, right ?
[02:39] <vorian> that helps
[02:40] <_16aR_> but the problem is : I don't see the needs packaging option, and when I want to name my package, lp say it isn't there ...
[02:40] <_16aR_> normal, I don't have finished it yet
[02:40] <nhandler> _16aR_: File the bug against Ubuntu
[02:40] <nhandler> And there is no needs-packaging option. Just title the bug '[needs-packaging] Foo'
[02:41] <_16aR_> against project ubuntu instead of distribution/package ?
[02:41] <nhandler> Add the needs-packaging tag
[02:41] <_16aR_> ok
[02:42] <_16aR_> so : summary = mypackagename, tag = needs-packaging, distribution = ubuntu ?
[02:42] <_16aR_> and no text inside ?
[02:43] <nhandler> summary = '[needs-packaging] yourpackagename'
[02:43] <nhandler> Text includes the URL, license, and any other relevant info
[02:43] <RAOF> And a description of what it actually *does*!
[02:44] <_16aR_> ok
[02:44] <vorian> what does it to?
[02:44]  * vorian hopes for new kde goodness
[02:44] <_16aR_> hexdiff : a ncurses "visual" diff editor in hexadecimal
[02:44] <_16aR_> sorry
[02:45] <_16aR_> ncurses goodness, though
[02:45] <vorian> hehe
[02:45] <vorian> sounds promising
[02:46] <_16aR_> it helped me a lot, so ... I think it should be good to have it in ubuntu. moreover, it's only 5 .c source file. So, lightweight and easily compiled
[02:46] <vorian> fantastic!
[02:51] <nixternal> james_w: what is involved in listing teams a member belongs to (or admins possibly) with launchpadlibs? it seems the team_memberships isn't incorporated yet
[02:56] <james_w> nixternal: it might be person.memberships_details
[02:56] <nixternal> ahh, let me try that
[02:56] <nixternal> thanks
[02:58] <james_w> https://edge.launchpad.net/+apidoc/#team_membership if you haven't found it
[02:58] <james_w> teams = [mem.team for mem in person.team_memberships]
[02:59] <james_w> but you'll want to filter on status
[03:08] <nixternal> ahhh haaa, that's the one :)
[03:25] <_16aR_> in cdbs, how to override or add value to the CFLAGS variable for example ,
[03:25] <_16aR_> ?
[03:26] <_16aR_> in my makefile, it does CFLAGS+=blabla, but when pbuilder build it, they don't appear :(
[03:27] <RAOF> _16aR_: It depends on what cdbs rules you're using.
[03:27] <RAOF> _16aR_: I'd guess you want to be here: https://perso.duckcorp.org/duck/cdbs-doc/cdbs-doc.xhtml#id2528304
[03:27] <_16aR_> debhelper and makefile
[03:28] <_16aR_> already read
[03:28] <RAOF> So DEB_MAKE_ENVVARS is your winner.
[03:28] <RAOF> It gives exactly an example of setting something in CFLAGS there.
[03:29] <_16aR_> RAOF: ok, but all I want is to add the cdbs default CFLAGS, to the one already in the Makefile of my Package
[03:29] <RAOF> It'll set that automatically.
[03:30] <_16aR_> I can copy the CFLAGS of the package into the debian/rules, but if it could be automated
[03:30] <_16aR_> not really, it overrides it :(
[03:30] <RAOF> Then you need to patch the makefile.
[03:31] <_16aR_> ok
[03:31] <RAOF> Or, rather, if the CDBS flags are overriding the ones in the Makefile then you need to add the Makefile's flags to the ones specified by CDBS.
[03:31] <RAOF>  / build environment.
[07:38] <stochastic> can anyone point me in the direction of how to format a debian/watch file?
[07:39] <TheMuso> stochastic: the uscan manpage probably has something about them.
[07:39] <dholbach> good morning
[08:42] <hyperair> can anyone review my package? it's already got an advocate. http://revu.ubuntuwire.com/details.py?package=codelite
[09:09] <didrocks> dholbach: morning (and yes, I was awake before ;))
[09:09] <dholbach> good morning didrocks! :)
[09:09] <dholbach> I was not saying that you're slacking :)
[09:09] <didrocks> I hope so :p
[09:20] <directhex> http://www.wkowtv.com/Global/story.asp?S=9667184
[09:20] <directhex> :/
[09:23] <liw> directhex, that's a pretty unfortunate piece of news, and shines a rather bad light... on Verizon and MATC
[09:24] <directhex> liw, but to the drooling residents of madison, wisconsin, who looks like the baddie?
[09:24] <liw> directhex, they're blissful in their ignorance and nothing can make them look bad
[09:25] <directhex> liw, the article was televised, even
[09:27] <slytherin> I wonder if the girl even bothered looking into the applications menu to see that there was already a word processor.
[09:28] <directhex> slytherin, the article is bunk. afaik there isn't even a link to dell.com/ubuntu from the main dell.com site, certainly no full-size laptops in their regular site come with or can be configured with ubuntu
[09:29] <directhex> slytherin, obviously blame shifting to cover dropping out. 2 semesters of work, over pretend requirements for windows? nah, not happening
[09:29] <directhex> given at the bottom both parties involved said they'd get their stuff working for her anyway
[09:30] <slytherin> right. And if I was spending $1100 to buy a laptop I would make sure 10 times that I was getting exactly what I wanted. Claiming that Ubuntu was provided without any prior notification is a complete lie in my opinion.
[09:31] <directhex> "The main thing to note is that when you choose open source you don’t get a Windows® operating system. If you’re here by mistake and you are looking for a Dell PC with Windows, please use the following link."
[09:31] <directhex> from the warning text on dell.com/ubuntu, which you need to individually seek out
[09:35] <stochastic> nasty letters need to be written to that editor
[09:37] <stochastic> whaddya know, here's the contact info: http://www.wkowtv.com/Global/story.asp?S=8388593&nav=menu1362_12_1
[09:46] <milli> crimeny that's just lousy journalism
[09:49] <james_w> vorian: I wish you hadn't uploaded ncpfs, there are quite a few problems with the package that I am working on
[10:45] <savvas> does anyone know someone from pkg-puppet-devel in debian? http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=511826
[10:48] <savvas> I provided patches, I need that fixed so I can request a sync and close bug #116417 on launchpad :)
[11:06] <stochastic> I've run into some issue uploading a package I'm working on to my PPA, I get this rejected message: phat_0.4.1-0ubuntu1.dsc: Section '-' is not valid
[11:06] <stochastic> here's the control file: http://paste.ubuntu.com/105100/
[11:07] <stochastic> sorry, I should post this question in #launchpad shouldn't I
[11:09] <siretart> stochastic: better paste the changes file you've uploaded
[11:09] <siretart> in addition to the dsc file
[11:10] <stochastic> http://paste.ubuntu.com/105101/ the changes file
[11:10] <karooga> hi, anyone got a moment to review my package?
[11:10] <siretart> there you have it. the section is empty
[11:11] <karooga> It's: http://revu.ubuntuwire.com/details.py?upid=3660
[11:12] <stochastic> well there's two different sections in the control file
[11:12] <stochastic> here's the dsc file: http://paste.ubuntu.com/105102/
[11:13] <stochastic> how do I format that?
[11:16] <siretart> stochastic: you probably need to specify a section for the source as well
[11:17] <savvas> ah yes
[11:17] <savvas> I had that problem before
[11:18] <savvas> I think you have to use Section: libs for source
[12:16] <stochastic> would someone like to give my package a REVU? http://revu.ubuntuwire.com/details.py?package=calf
[12:29] <stochastic> If I'm building a series of packages that depend upon one another, is there any way to get pbuilder to be configured to pull from a PPA repo?
[12:34] <mok0> stochastic: yes
[12:34] <mok0> stochastic: you're not talking about a circular depency I hope
[12:35] <stochastic> nope, linear
[12:35] <mok0> stochastic: you have to use the --othermirror switch
[12:36] <stochastic> okay, thanks I'll look into that
[12:36] <mok0> stochastic: or, --login to the pbuilder with --save-after-login and exit the source.list file
[12:37] <mok0> s/exit/edit
[12:57] <stochastic> mok0, it doesn't seem to be able to pull from the repo, though it did get the listing from pbuilder update and I can see the package in apt-cache policy
[12:57] <stochastic> am I missing something?
[12:58] <stochastic> do I need pbuilder to verify the repository?
[13:00] <mok0> stochastic: sorry I was afk
[13:00] <mok0> stochastic: Is the package in the Build-Depends?
[13:00] <stochastic> yes
[13:01] <mok0> stochastic: how did you add the repo?
[13:02] <stochastic> I went through the .pbuilderrc file as directed here: https://wiki.ubuntu.com/PbuilderHowto#Using%20the%20%27othermirror%27%20option
[13:03] <mok0> stochastic: hm, I wonder if you also need to include the --othermirror option when you invoke the build
[13:04] <stochastic> I'll give it a try, but it pulled the new source when I did pbuilder update
[13:04] <mok0> stochastic: that should be enough I would think, but you never know :-)
[13:06] <slytherin> stochastic: What is the problem you are facing?
[13:07] <stochastic> slytherin, I'm trying to get pbuilder to pull a dev library from my PPA repo
[13:07] <slytherin> stochastic: let me take a look at your pbuilderrc
[13:07] <slytherin> stochastic: have you pasted it anywhere?
[13:08] <stochastic> http://paste.ubuntu.com/105150/
[13:09] <stochastic> I know the second part is kinda pointless, but that's what the howto told me to add
[13:10] <slytherin> stochastic: when you did pbuilder update, did you use --override-config option?
[13:10] <stochastic> nope
[13:10] <stochastic> I guess I should have?
[13:10] <slytherin> stochastic: yes
[13:11] <stochastic> off I go...
[13:13] <stochastic> success!!
[13:13] <norsetto> huats!!!
[13:13] <mok0> yiiihaa
[13:13] <mok0> norsetto!!
[13:13] <huats> norsetto: !!!
[13:13] <norsetto> mok0!V
[13:13] <huats> so happy to see you my old friend  !
[13:13] <mok0> huats: you can SEE him?
[13:14] <huats> we miss you !
[13:14] <norsetto> huats: I'm not old, I'm just generationally challenged ;-)
[13:14] <mok0> lol
[13:14] <huats> norsetto:  :)
[13:14]  * pochu waves :)
[13:14] <norsetto> heya pochu
[13:14] <pochu> hey hey norsetto!
[13:14] <pochu> hi huats and mok0
[13:15]  * pochu refreshes his ppa waiting for a build to start
[13:15] <huats> hey pochu
[13:15] <mok0> Hi pochu!
[13:15] <james_w> hey norsetto
[13:15] <norsetto> hi james_w , how's life in lovely Bristol?
[13:15] <james_w> norsetto: great thanks, how are you?
[13:15] <norsetto> huats: better not to ask about Toulouse  ;-)
[13:16] <norsetto> james_w, surviving ;-)
[13:16] <james_w> good :-)
[13:16] <huats> norsetto: ;)
[13:17] <mok0> OK guys let's not get all emotional here... back to work!
[13:17]  * pochu goes back to refresh his ppa :P
[13:18] <norsetto> mok0: he, this reminds me the joke about the two finnish drinking together
[13:18] <mok0> norsetto: yes?
[13:18] <norsetto> mok0: well, one of the two said skoll to the other
[13:19] <mok0> :-)
[13:19] <mok0> haha
[13:19] <norsetto> mok0: and the other replied, in an harsh tone, are we drinking or talking!?
[13:20] <mok0> I guessed that! :-D
[13:20] <norsetto> mok0: well, I knew you would, you viking ;-)
[13:22] <mok0> raphink: Can we nuke greycstoration from REVU?
[13:22] <raphink> hmmm we could mok0
[13:22] <raphink> although it could be an interesting package to have
[13:23] <raphink> since this functionality is not included in gimp
[13:23] <mok0> raphink: The last comment from norsetto says it's part of gimp-plugin-registry
[13:23] <mok0> raphink: I agree, that app is awesome, I have used it on some of my photos
[13:24] <mok0> raphink: ok, I'll leave it, I thought you might have given up on it
[13:25] <norsetto> mok0: yes, quite a catch-all that package, can't say I like the approach ...
[13:25] <mok0> norsetto: oh? Why not?
[13:26] <norsetto> mok0: not very maintainable IMHO
[13:27] <norsetto> mok0: and why should one oblige a user to install 30 applications when all he needs is one?
[13:27] <mok0> norsetto: is that what goes on? I only recall that it makes an app
[13:27] <mok0> and a plugin
[13:28] <mok0> norsetto: in any case, cgreystoration is superb at removing visible noise from your photos...
[13:29] <mok0> norsetto: much better than anything else I've seen, even PhotoShop
[13:29] <norsetto> mok0: I was talking about the gimp-plugin-registry package
[13:29] <mok0> norsetto: ah
[13:29] <mok0> Well, in that case, shouldn't we push that package forward? raphink?
[13:32] <raphink> mok0: sure
[13:32] <mok0> get to work, raphink ;-)
[13:32] <raphink> mok0: some KDE apps have it by default now, like krita and digikam e.g.
[13:32] <raphink> mok0: well, has it been reviewed yet?
[13:32] <mok0> raphink: greycstoration? Yes a long time ago
[13:33] <mok0> http://revu.ubuntuwire.com/details.py?package=greycstoration
[13:34] <raphink> I lack time ;)
[13:34] <raphink> you can tell, I'm sure ;)
[13:34] <hyperair> mok0: could you review codelite again please? http://revu.ubuntuwire.com/details.py?package=codelite
[13:35] <mok0> hyperair: I've already advocated the package, someone else needs to, as well
[13:35] <mok0> hyperair: just don't do any new uploads
[13:35] <raphink> oh and you reviewed it yourself even mok0
[13:35] <raphink> ;)
[13:35] <mok0> raphink: that's why I asked
[13:36] <raphink> hehe I see
[13:36] <hyperair> mok0: i know you have, but i did a new upload
[13:36] <raphink> I'm probably not very up-to-date with new rules
[13:36] <raphink> considering maintainers and so on
[13:36] <hyperair> mok0: nhandler has advocated the package, but yours was lost after upstream came up with a new version
[13:36] <raphink> I think that it might not be a really good thing that policy changes so fast
[13:36]  * mok0 looks
[13:36] <raphink> so people who knew the rules a year ago don't anymore and need to spend time re-reading them
[13:37] <mok0> raphink: I don't see an upload since the comments
[13:37] <raphink> no, I didn't upload anymore mok0
[13:37] <raphink> I have to find time to look at it ;)
[13:38] <raphink> quiet a few things in your comments are new to me
[13:38] <raphink> it wasn't done like that last time I made new packages ;)
[13:38] <raphink> so I need to check these new rules
[13:38] <mok0> raphink: yeah, just ask here
[13:39] <raphink> mok0: the last comments seems to indicate that greycstoration is already packaged
[13:39] <raphink> as part of another package
[13:39] <mok0> hyperair: I am puzzled, AFAICS my advocation is still there, but REVU fails to count it
[13:39] <mok0> hyperair: ah, it's for another upload
[13:40] <hyperair> mok0: yeah it's another upload. nhandler advocated this upload, but not the one you advocated. partly because debian/copyright was off and there was a new version from upstream
[13:42] <mok0> hyperair: very strange, it keeps adding my comment to the previous upload...
[13:42] <mok0> hyperair: never mind
[13:42] <mok0> hyperair: I will upload it now
[13:43] <hyperair> mok0: thanks
[13:43] <mok0> Thanks for your work, hyperair
[13:44] <hyperair> np
[14:02] <mok0> hyperair: codelite is now in the new queue https://edge.launchpad.net/ubuntu/jaunty/+queue?queue_state=0&queue_text=
[14:06] <hyperair> mok0: okay thanks
[14:24] <apachelogger> siretart, lool: could one of you please take a look at bug 290768
[14:25] <mok0> siretart: pinnngg
[14:26] <lool> apachelogger: Is there any backtrace of this crash somewhere?  I see a crash file, but I suspect it wasn't sent with apport and hence hasn't the proper tags / wasn't retraced
[14:27] <lool> Ah there's a partial one upstream
[14:27] <siretart> mok0: yes?
[14:27] <mok0> I am not able to log on to revu although I am an -admin
[14:31] <lool> siretart: Do you reproduce the above crash with xine?
[14:34] <lool> siretart: With LC_ALL=it_IT.UTF-8 or fr_FR.UTF-8, it doesn't crash
[14:34] <lool> Ah that's intrepid actually
[14:34] <lool> and amd64
[14:39] <lool> apachelogger: Ok; it's a bug in the italian translation on launchpad
[14:39] <lool> English: load_plugins: static plugin found
[14:39] <lool> Current Italian: load_plugins: plugin %s trovato
[14:41] <JontheEchidna> it's a bug with german too
[14:41] <JontheEchidna> I think it'd probably be a good idea if most translations were checked
[14:41] <lool> JontheEchidna: I don't seem to have the right to change them
[14:41] <lool> JontheEchidna: Do you know who to contact for such cases?
[14:41] <mok0> "Would you hold it against me if I said you had beautiful thighs?"
[14:42] <lool> I wonder whether that qualify as a SRU regression
[14:42] <mok0> "A hoovercraft has eels"
[14:42] <JontheEchidna> lool: nope, I just had a german guy in #kubuntu with the same crash yesterday
[14:42]  * JontheEchidna speaks english
[14:42] <JontheEchidna> obviously ;-)
[14:43] <lool> JontheEchidna: I also tried looking at the reporters and thought some didn't have an italian sounding name
[14:45] <lool> I'm moving the discussion to #ubuntu-devel as it sounds like a SRU regression
[14:50] <lool> Err kubuntu-devel
[14:51]  * directhex mails mok0 an eel-filled hovercraft
[14:54] <siretart> lool: sorry, I don't have a jaunty system to test
[14:58] <lool> siretart: it's an intrepid issue
[14:58] <lool> siretart: It seems like a string issue
[15:03]  * mok0 thanks directhex
[15:04] <siretart> hm. gxine works fine for me in german locale on i386
[15:04] <siretart> needs more investigation...
[15:04] <mok0> Ah none of you young guys remember the Monty Python sketch about the Romanian Parleur
[15:10] <directhex> hungarian?
[15:10] <mok0> directhex: yes, sorry hungarian
[15:12] <directhex> http://www.thisisawar.com/LaughterMPHungarian.htm
[15:12] <mok0> Hehe yes that's the one... priceless
[15:15] <mok0> directhex: re: JontheEchidna asking for a review of all translations ;-)
[15:15] <directhex> sounds like a rather major task
[15:16] <directhex> can't we just put an automatic check on matching numbers of %s et al on all languages, when publishing translations?
[15:17] <JontheEchidna> apparently the rosetta dudes are gonna scan the translations for the errors
[15:18] <directhex> that's okay then
[15:34] <directhex> apachelogger, remember the ubuntu-calendar packages?
[15:43] <apachelogger> directhex: nope
[15:47] <anakron> Hi all
[15:47] <anakron> :) good morning...here in chile
[15:47] <anakron> good [random]
[15:49] <RainCT> hi
[15:49] <directhex> apachelogger, it was some wallpaper, released monthly, a while back. there may have been boobies involved. check packages.ubuntu.com
[15:49] <JontheEchidna> "there may have been boobies involved". You now have my full, undivided attention. :P
[15:49] <JontheEchidna> [/sexist remarks]
[15:51] <anakron> hi rain
[15:53] <mok0> I just reviewed http://revu.ubuntuwire.com/details.py?package=nx but I feel very unsure about that package. I'd appreciate if someone else could take a look.
[15:57] <hyperair> ooh nx
[15:57] <hyperair> i remember there was an unofficial repository containing that once
[15:58] <directhex> JontheEchidna, i suspect that's why it was removed. despite the month with the naked guy.
[15:58] <JontheEchidna> O.o
[15:58] <JontheEchidna> do not want
[16:00] <directhex> JontheEchidna, check the deps/suggests of http://packages.ubuntu.com/dapper/ubuntu-calendar - no promises on which contains whom and in what state of undress.
[16:02] <directhex> hint: you won't like jan
[16:51] <apachelogger> directhex: oh well, I am not a fan of boobies :P
[16:51] <jpds> ...
[16:51] <hyperair> ..what was that and what prompted it?
[16:51] <jpds> hyperair: I'd rather not know.
[16:52] <directhex> apachelogger, but that was probably a major factor in the calendar being dropped
[16:52] <Nafallo> hyperair: calendar packages back in warty
[16:52] <Nafallo> late response :-P
[16:52] <jpds> Nafallo: Ah right.
[16:52]  * apachelogger was on his way home
[16:53] <apachelogger> directhex: kubuntu-wotm wouldn't go to official archives and either way have moderation
[16:53] <directhex> apachelogger, the calendar was moderated. t'was in main i think!
[16:53] <directhex> anyway, hometime
[16:53] <apachelogger> one moderation crew that was :P
[16:54] <Nafallo> the calendar was paid for photographic art AFAIK
[16:55] <hyperair> Nafallo: you mean the monthly ubuntu calendar thing?
[16:55] <Nafallo> hyperair: yes.
[16:55] <hyperair> ah those
[16:55] <karooga> is it acceptable to include copyright+licence info as a patch for files in a package which don't have it included (from upstream)?
[16:57] <hyperair> no i don't think so
[16:58] <hyperair> but i feel lucky that the upstream maintainer was cooperative regarding the license issues
[16:58] <hyperair> you should contact upstream and see if they're willing to cooperate
[16:58] <karooga> hyperair: i had cooperation initially but now about 3 months later - nothing.
[16:59] <hyperair> karooga: bug the upstream maintainer some more?
[16:59] <hyperair> if not ask a motu for guidance
[17:00] <hyperair> whoever it is who reviewed your package perhaps
[17:00] <karooga> hyperair: RainCT
[17:00] <RainCT> yes?
[17:00] <karooga> hyperair: i've already sent a couple of emails upstream.
[17:01] <hyperair> karooga seems to be having some issues with upstream and copyright stuff
[17:01] <hyperair> RainCT: ^
[17:01] <karooga> oh hi, RainCT :-)
[17:01] <hyperair> heh that was prompt
[17:01] <karooga> RainCT:  fixing up final bits and following your review http://revu.ubuntuwire.com/details.py?upid=3660
[17:06] <karooga> RainCT: any ideas?
[17:06] <RainCT> okay, so you are more productive than me right now (/me just removed a directory with some stuff which will take him hours to redo :'()
[17:09] <hyperair> poor thing
[17:09] <karooga> RainCT: balls! sorry to hear it.  apt-get install recover... or apt-get install e2undel?
[17:10] <hyperair> those only work with ext2 =(
[17:11] <jpds> RainCT: no backups?
[17:11] <karooga> hyperair: but ext3 is just ext2 + a journal?
[17:13] <RainCT> jpds: no, I hadn't much yet, but it's stuff with which I have nearly no experience yet so I'll have to go through the docs again.. (writing python bindings in C/C++)
[17:13] <hyperair> karooga: yes, but apt-cache show recover e2undel said it won't work with ext3
[17:13] <jpds> RainCT: Ouch..
[17:13] <karooga> :-/
[17:14] <hyperair> i'm interested to try out ext4. it's just ext3 + extents right?
[17:15] <karooga> hyperair: with 16TB file limits
[17:15] <hyperair> ah
[17:15] <hyperair> right
[17:15] <hyperair> but my hard disk doesn't even reach 1TB
[17:16] <hyperair> so to hell with that damn limit lol
[18:27] <hggdh> question for any: Evolution 2.26 will require libpst at an updated version (0.6.x) than what is available on either Ubuntu or Debian. How do you want me to request it?
[18:38] <slytherin> hggdh: asking in wrong channel. evolution is in main. So check if anyone has already thought about this or working on this in #ubuntu-devel.
[18:41] <hggdh> slytherin, Evo is in main, but libpst is currently in Universe. After upgrading we will need a MIR on it
[18:42] <slytherin> hggdh: right. But you should still check if the maintainers of evo have already thought about this or not.
[18:44] <hggdh> slytherin, I did. I also help on Evolution...
[18:45] <slytherin> hggdh: hmm. in that case file a bug for update of libpst. And you can work on as well if you want. :-)
[18:46] <hggdh> heh
[18:46] <hggdh> my doubt is Debian does not have an up-to-date libpst, so we would need to package from source -- and I am not sure of the process here...
[18:47] <hggdh> (so it will not be a sync, but a real needs-packaging from source)
[18:48] <slytherin> hggdh: that is all right. Debian is in deep freeze currently. So you probably won't see new libpst in Debian unstable till Lenny is released.
[18:49] <slytherin> hggdh: can you tell me exact name of the package. I can not find any libpst package in Debian/Ubuntu.
[18:53] <hggdh> slytherin,  on Debian and Ubuntu it is listed as readpst, source package libpst
[18:54] <slytherin> hggdh: Ok. I was just checking if the package has any updated version in Debian experimental.
[18:54] <hggdh> no...
[18:55] <hggdh> (I had already checked, this is why I came here)
[18:55] <slytherin> hggdh: please proceed with your plan then. :-)
[18:56] <hggdh> slytherin, thanks. I did not want to get anything started before checking here
[18:57] <slytherin> hggdh: make sure you log a bug first. And assign it to yourself.
[18:58] <hggdh> slytherin, I will start with a needs-packaging, of course ;-)
[18:59] <ScottK> Actually for an updated package it should be tagged 'upgrade'  'needs-packaging' is just for new packages
[19:15] <slytherin> james_w: I was just wondering. Is there any point of keeping serpentine in archives when it offers no advantage over other tools like brasero.
[19:22] <ScottK> slytherin: Unless it's abandoned upstream there's no pressing reason so remove it from Universe.
[19:23] <slytherin> ScottK: well there is no reason to maintain as well. Anyway, I will leave it as it is.
[19:24] <hggdh> ScottK, I will correct the bug. Thanks
[19:25] <hggdh> ScottK, would the 'needs-packaging' tag still be applicable, or is there another tag to be used?
[19:26] <directhex> poopies. intrepid doesn't support audio on this motherboard
[19:28] <slytherin> hggdh: upgrade is correct tag
[19:31] <Chris`> I have just finished packaging my first package, can someone check over the debian/control for me?
[19:32] <maxb> Chris`: For submission to Ubuntu, or for personal/limited use?
[19:32] <Chris`> maxb: For submission to Ubuntu
[19:32] <Chris`> http://pastebin.com/m5eeda7cd
[19:32] <Chris`> There is the control file
[19:32] <maxb> Chris`: Have you read about REVU?
[19:32] <nhandler> !revu | Chris`
[19:32] <Chris`> maxb: Yeah however I'd rather just make sure that this is correct first :)
[19:33] <maxb> Section: unknown
[19:33] <Chris`> Yeah just editted )
[19:33] <maxb> Priority: Networking !
[19:33] <Chris`> Section: Networking priority: extra
[19:33] <Chris`> :D
[19:33] <Chris`> I'm concerned about the maintainer field
[19:33] <directhex> jaunty supports it though
[19:33] <Chris`> Should that be motu?
[19:33] <maxb> yes
[19:33] <Chris`> What's the name and address for the MOTU?
[19:34] <nhandler> Ubuntu MOTU Developers<EMAIL_ADDRESS>[19:34] <Chris`> nhandler: Thanks ;)
[19:34] <nhandler> You're welcome Chris`
[19:35] <Chris`> So when I have finished this, what must I do with the pbuilder/result directory?
[19:35] <jpds> Chris`: I think Prioirity ought to be optional, extra is rarely used.
[19:35] <jpds> Chris`: Upload the source package to revu.
[19:35]  * Chris` goes back and edits :)
[19:35] <maxb> Your own name and email go in XSBC-Original-Maintainer:
[19:35] <nhandler> Chris`: You don't need to do anything with the pbuilder/result directory. But you could mention that it built cleanly (if it did)
[19:35] <jpds> Chris`: Latest Standards-Version is 3.8.0 too. :)
[19:36] <maxb> You have some things in your Depends that I would have expected ${shlibs:Depends} to have taken care of
[19:36] <jpds> Chris`: And you should have a new line every 80 spaces.
[19:37] <Chris`> The Depends section, how does one go about fixing that?
[19:37] <karooga> jpds:  is 80 the magic number from 80x25 in a terminal?
[19:38] <jpds> Chris`: {$shlibs:Depends} autodetectes what your package needs normally.
[19:38] <maxb> Remove all library packages from depends. Build. Check that the shlibs:Depends substituted everything you expected it to
[19:38] <jpds> karooga: Yes, and it makes it easier to read.
[19:38] <maxb> Read http://www.debian.org/doc/debian-policy/ch-binary.html#s-descriptions about the Description field
[19:41] <Chris`> http://pastebin.com/d7e36385 How does this look? :)
[19:42] <maxb> 'Networking' is not a valid Section. You get to choose from the list defined in paragraph 2.4 of the debian-policy-manual only
[19:42] <directhex> **** network manager
[19:42] <directhex> it keeps ignoring my static configurating, re-creating the "auto eth0" setting, and using that
[19:43] <Chris`> net?
[19:43] <nhandler> There is a web section
[19:43] <maxb> You imply you might be using rdesktop but don't build-depend on it
[19:44] <Chris`> I haven't build-depended rdesktop, have I?
[19:49] <Chris`> "dput revu package_version_source.changes" -- Is that all that is required?
[19:49] <jpds> Chris`: Yep.
[19:49] <jpds> Chris`: No, make sure you've logged into REVU first via the web interface.
[19:50] <nhandler> Chris`: Also make sure your gpg key is in LP
[19:50] <Chris`> I am but what about the source tarball?
[19:50] <nhandler> Use debuild -S -sa
[19:50] <nhandler> That will include the .orig.tar.gz in your upload
[19:50] <Chris`> Am I only uploading the changes file using that command? Or am I uploading the changes and the orig
[19:50] <Chris`> ah ok
[19:51] <jpds> Chris`: and .diff.gz and .dsc.
[19:51] <Chris`> Ok uploading... finally :)
[19:51] <Chris`> Successfully uploaded packages.
[19:51] <Chris`> Not running dinstall.
[19:52] <Chris`> Is that bad?
[19:52] <maxb> no
[19:52] <Chris`> So dinstall is just something that I shouldn't worry about?
[19:52] <maxb> Not running dinstall. == "I'm not debian" more or less
[19:52] <Chris`> Ah ok cool
[19:53] <Chris`> To close the bug, should I attach anything to launchpad now?
[19:54] <jpds> Chris`: If you did the changelog right, the bug will be automagically closed when the package is uploaded to the archives.
[19:54] <nhandler> Chris`: You shouldn't close the bug until the package gets uploaded to the repositories
[19:54] <nhandler> The changelog entry should include (LP: #NNNNNN) to close the bug
[19:55] <ScottK> hggdh: The tag is upgrade
[19:55] <Chris`> Oh snap, "(Closes: lp:#314430)" Does the lack of space mean much?
[19:55] <ScottK> Yes it does
[19:55] <maxb> Chris`: You seem to have uploaded an old version
[19:55] <nhandler> You don't need the word "Closes"
[19:55] <jpds> Chris`: (LP: #NNNNN).
[19:56] <nhandler> (LP: #314430) -- assuming that is a LP bug
[19:56] <Chris`> maxb: What do you mean old? I just got that tarball from the homepage
[19:56] <ScottK> If this is for a new package, last I noticed close in changelog didn't work for them anyway
[19:56] <maxb> The version I see in revu lacks changes you just discussed in this channel
[19:57] <Chris`> My control file?
[19:58] <maxb> yes
[19:58] <Chris`> Ah strange, lemme just refix ti
[19:58] <Chris`> *it
[19:59] <Chris`> dpkg-source: error: syntax error in grdc-0.2.0/debian/control at line 15: line with unknown format (not field-colon-value)
[19:59] <Chris`> dpkg-buildpackage: failure: dpkg-source -b grdc-0.2.0 gave error exit status 9
[19:59] <Chris`> debuild: fatal error at line 1329:
[19:59] <Chris`> debuild error =\
[19:59] <nhandler> What is line 15 in debian/control?
[19:59] <maxb> You've got all kinds of boilerplate comments left over in your debian/rules too
[19:59] <Chris`> application and a Gnome applet. Features include scrollable window, floating
[20:00] <nhandler> Chris`: Is that in the description? If so, did the line start with a space?
[20:00] <Chris`> nhandler: I'll try with a space now then :)
[20:01] <Chris`> maxb: I don't understand the rules file, how can I go about removing the "boilerplate" stuff?
[20:02] <karooga> nhandler: should all source files contain copyright+licencing info?
[20:02] <nhandler> karooga: That would be ideal
[20:03] <maxb> Chris`: You should not have commented out commands or comments that are instructions to you from the template rules file left over in the actual upload
[20:03] <Chris`> maxb: I haven't touched the rules file, that was left over from dh_make
[20:04] <nhandler> Chris`: Well, you are going to have to touch the rules file. You probably don't need everything in there
[20:04] <karooga> nhandler: is it a deal breaker though?  I'm battling to get hold of upstream.  Or should I use a patch to add the details?
[20:05] <nhandler> karooga: What package is this?
[20:07] <karooga> nhandler: a python handler for an fortran library http://revu.ubuntuwire.com/details.py?upid=3660
[20:08] <karooga> nhandler: s/handler/bindings/
[20:10] <nhandler> karooga: I'm not seeing any license in that code. I highly doubt it would get accepted in its current state
[20:12] <Chris`> Ok I have finished with the debian files now and I have reuploaded :)
[20:19] <Jazzva> hi, do I need e-mail addresses of all upstream authors, or will one or two be enough for debian/copyright?
[20:24] <karooga> nhandler: the upstream tarball doesn't have any licence.
[20:25] <nhandler> karooga: I know. That is an issue. It needs to have a license in it
[20:27] <karooga> nhandler: I agree, that's why I added some lines in get-orig-source  http://revu.ubuntuwire.com/revu1-incoming/ppgplot-0901150900/ppgplot-1.3/debian/rules
[20:28] <nhandler> I don't think you are allowed to simply coppy /usr/share/common-licenses/LGPL-2.1 to the source.
[20:30] <mok0> nhandler: you're not
[20:30] <nhandler> I know mok0
[20:30] <mok0> karooga: you have to ask upstream to include a license file
[20:30] <mok0> karooga: COPYING or whatever
[20:30] <karooga> nhandler: this is what ScottK suggested I do...
[20:31] <karooga> mok0: upstream is being uncooperative :-(
[20:31] <ScottK> mok0: You can repack the tarball to add license if needed.
[20:31] <mok0> karooga: then we can't distribute the software
[20:31]  * ScottK got one in the archive that way.
[20:31] <ScottK> If it's clear what the intended license is.
[20:31] <ScottK> You can't just make one up.
[20:32] <nhandler> ScottK: I don't think it is clear
[20:32]  * JontheEchidna makes up the rainbow unicorn license
[20:32] <karooga> ScottK: hehe... no it's not made up.
[20:32] <nhandler> ScottK: There are no license headers and no mention of the license in the readme or anything
[20:32] <mok0> Correct, I checked it too
[20:33] <karooga> ScottK: I had coms with upstream before he went silent.
[20:33] <mok0> There's nothing outside debian/ saying what the license is
[20:33] <karooga> that was about 3-4 months ago
[20:34] <mok0> karooga: I've had to abandon packages where upstream was not responsive
[20:34] <mok0> karooga: it's no fun
[20:34] <karooga> mok0: so what are my options? tarball myself and dump on launchpad or sourceforge?
[20:35] <mok0> karooga: you mean distribute it yourself?
[20:35] <karooga> mok0: yup?
[20:35] <mok0> karooga: It's a possibility
[20:36] <karooga> mok0: it's really only 3 files in total anyway...
[20:37] <karooga> I think I'll try sending a forth email to upstream
[20:37] <mok0> karooga: we're talking about ppgplot, right?
[20:37] <karooga> mok0: yes
[20:39] <mok0> karooga: tbh, if you need it for your own work, just package it and use it locally. There's a ton of plotting packages in Ubuntu, some much more advanced. Yes I am brutal :-)
[20:39] <karooga> mok0: perhaps I can make it easy for him by including a patch to his code... maybe even a script to repackage it.
[20:39] <mok0> karooga: well that is a good way to get things done
[20:40] <mok0> karooga: you are really in love with this software, huh ;-)
[20:40] <karooga> mok0: I'm already doing that :-)  but there's no coolness factor for getting your first package accepted.
[20:40] <mok0> karooga: I understand, but there's LOTs of other software that you could package
[20:41] <mok0> karooga: you might even "hijack" a package from REVU, many are abandoned there
[20:41] <karooga> mok0: hehehe... it's a love-hate relationship - I hate the C/fortran interface.
[20:41] <karooga> mok0: loving the python one.
[20:42] <mok0> karooga: ok! Just probing you...
[20:45] <maxb> Do people manually sweep revu for packages that are outdated, or is it worth pointing out, for example, that the unetbootin in revu is older than the one in jaunty?
[20:45] <maxb> s/manually/regularly/
[20:45] <karooga> mok0: I did start http://revu.ubuntuwire.com/details.py?package=pyephem  but realised I had to package the library separately
[20:45] <nhandler> maxb: Usually, when a MOTU reviews a package, they check if it is the most recent version before advocating
[20:46] <mok0> karooga: ok, anyways, since you are keen to do work, while you are waiting for an answer to your ppgplot patches, I am sure there are REVU uploaders that could use assistance pushing packages through. Look for old ones in the "Needs Work" section and contact the packager if you can take over
[20:46] <maxb> yup, but what about discarding unreviewed obsolete packages?
[20:46] <mok0> maxb: what do you mean?
[20:46] <nhandler> maxb: They would have had to have been reviewed in order for someone to notice it was old ;)
[20:47] <karooga> mok0: cool beans - any recommendations off hand?
[20:47] <mok0> karooga: it depends on your interest
[20:47] <maxb> Well, if the version in jaunty is greater than the version in revu, it would be reasonable to semi-automatedly archive them?
[20:48] <mok0> karooga: there's one called python-crontab that even has one advocate
[20:48] <nhandler> maxb: If it is in Jaunty, it shouldn't be on REVU
[20:48] <nhandler> maxb: REVU is only for brand new packages
[20:48] <maxb> Well that's the point. I'm asking if it's useful to point out such erroneous packages, and if so, how is best.
[20:49] <mok0> karooga: ah, python-crontab is not that old
[20:49] <nhandler> maxb: Poke a MOTU. They can then archive the upload on REVU
[20:50] <mok0> karooga: python-polib is old and has a not-answered review
[20:51] <maxb> MOTUs, consider yourself poked re http://revu.ubuntuwire.com/details.py?package=unetbootin to be archived :-)
[20:52] <mok0> maxb: why?
[20:52] <karooga> mok0: great thanks.  Will look into them.
[20:52] <nhandler> mok0: He said it was in jaunty
[20:52] <mok0> ah I see
[20:52] <maxb> in jaunty with greater version
[20:52] <nhandler> mok0: You want to handle it? If not, I'll do it in a minute or two
[20:52] <mok0> maxb: thanks. Done.
[20:54] <mok0> nhandler: archived
[20:54] <nhandler> :)
[20:55] <mok0> So, we're well into REVU day!
[20:56] <nhandler> mok0: I still have 11 more hours
[20:56] <karooga> mok0: I see there is a newer version of python-polib out.  Does one work on newest version and archive the old one?
[20:57] <mok0> karooga: you'd just package the newer one and overwrite it
[20:57] <nhandler> karooga: When you upload a newer version to REVU, it will replace the older one
[20:57] <mok0> we often ask uploaders to upgrade
[20:58] <karooga> nhandler: brill!
[20:58] <nhandler> That is another reason why a debian/watch file or a get-orig-source rule is so great
[20:58] <nhandler> karooga: ???
[20:59] <karooga> nhandler: a big thumbs up to the guys working on revu code :-)
[20:59] <nhandler> karooga: Thank RainCT, not me
[20:59] <karooga> is an MIT licence a problem?
[20:59] <Chris`> http://revu.ubuntuwire.com/details.py?package=grdc -- If you have the chance, can you review this for me please?
[21:00] <mok0> karooga: I hope not, otherwise we can't run the X-server
[21:01] <mok0> ;-)
[21:01] <mok0> Chris`: I'll take a look
[21:01] <Chris`> mok0: Thanks :)
[21:01] <iulian> Could someone please unsubscribe uus from bug #317544?
[21:02]  * nhandler goes to look
[21:02] <mok0> iulian: can't you do that yourself?
[21:02] <iulian> mok0: I'm not a member of uus.
[21:02] <iulian> So, I cannot.
[21:02] <mok0> iulian: ah, but you should be
[21:03] <mok0> iulian: you're MOTU now
[21:03] <nhandler> iulian: Done
[21:03] <iulian> nhandler: Thanks.
[21:03] <nhandler> You're welcome. Now go and join UUS
[21:04]  * iulian looks for an uus admin.
[21:04] <nhandler> iulian: Bug persia about it
[21:05] <savvas> what's your opinion on debhelper and debian/compat version? should I use as minor as possible for backport reasons?
[21:05] <jpds> nhandler: You can't file bugs against people tho.
[21:05] <nhandler> jpds: I wonder what the LP admins would say if I created a bug report about that
[21:06] <Chris`> mok0: I have just fixed a Gnome --> GNOME bug, I'm going to reupload assap
[21:08] <persia> iulian, You want to be a member?
[21:08] <RAOF> savvas: You don't need to worry about backporting; hardy has debhelper 7 in backports, too.
[21:09] <savvas> RAOF: there's no obligation to put up the newest debhelper version, right?
[21:09] <savvas> I mean, I've looked in debian and ubuntu policies, couldn't find anything
[21:09] <RAOF> savvas: No.  You don't have to use compat 7.
[21:09] <iulian> persia: Yes, please.
[21:09] <persia> Done.
[21:10] <iulian> That was fast. Thanks.
[21:10] <RAOF> savvas: You might _want_ to use compat 7, so you can use the moderately awesome dh tool.
[21:10] <RAOF> Like CDBS, but without so much crazy arcane makefile hunting!
[21:10] <savvas> new features?
[21:10] <savvas> hm..
[21:10] <persia> iulian, Thanks for helping out: closing all the bugs for which we have  fix already available is fairly high priority :)
[21:11] <superm1> RAOF, is it in misc different backports for earlier releases so you dont lose backportability?
[21:11] <savvas> RAOF: Could you point me to a link with more information? :)
[21:12] <RAOF> superm1: It certainly works back to hardy; I'm not sure if dh 7 is backported to gutsy or earlier, though.
[21:12] <superm1> RAOF, oh an you just said that above. sorry i should have read scrollback more than 3 lines up
[21:13] <RAOF> savvas: The dh manpage is pretty good http://manpages.ubuntu.com/manpages/jaunty/en/man1/dh.1.html
[21:14] <maxb> rmadison says no backports other than hardy
[21:14] <savvas> ok thanks
[21:17] <mok0> Chris`: ok, I attached my review!
[21:17] <Chris`> mok0: Thanks a bunch :)
[21:36] <karooga> In the upstream tarball, is the licence in COPYING or LICENCE? or does it not really matter too much as long as it's there?
[21:38] <Chris`> karooga: I'd assume as long as it's there it should work but wait for a proper MOTU to answer ;)
[21:39] <karooga> Chris`: yeah, that's my gut feeling too.
[21:40] <nhandler> karooga: If it is there, you are fine. The name doesn't matter. While you are at it, try and get license/copyright headers for the actual script too
[21:41] <karooga> nhandler: i will do.
[21:42] <karooga> nhandler: I see revu complains about copyright in the examples - is this an issue?
[21:42] <nhandler> What examples karooga? And what does it complain about?
[21:44] <karooga> nhandler: I should say the complaint is "*No copyright* UNKNOWN".  The examples are are example scripts shipped with package.
[21:44] <karooga> nhandler: http://revu.ubuntuwire.com/report.py/legal?upid=4490
[21:44] <nhandler> karooga: It is complaining about the scripts not having proper license/copyright headers
[21:46] <karooga> nhandler: yeah.  But am I just being academic about wanting to fix them too?
[21:48] <nhandler> karooga: You personally can't fix it. Upstream would need to do that. The headers aren't as important as including a license in the source, but some MOTUs don't like packages without headers
[21:50] <karooga> nhandler: cool
[21:52] <karooga> thanks for the help this evening nhandler, mok0 and Chris`.  Lights out time.
[21:52] <Chris`> karooga: Nos da ;)
[22:45] <LaserJock> what the way to enter a directory before running make in debian/rules?
[22:45] <DktrKranz> jpds, I hadn't the chance to look at new launchpadlib feature in ubuntu-dev-tools, how can I use requestsync to avoid "IOError: No credentials found" each time?
[22:45] <RAOF> LaserJock: cd dir && $(MAKE) ?
[22:45] <jpds> DktrKranz: Get the latest version in jaunty.
[22:45] <RAOF> Other options probably include $(MAKE) -C $DIR
[22:45] <DktrKranz> jpds, I've it already
[22:46] <jpds> DktrKranz: 0.55?
[22:46] <DktrKranz> yes
[22:47] <jpds> DktrKranz: OK; look at: man manage-credentials
[22:47] <DktrKranz> I launched manage-credentials as suggested, imported credentials but it still fails with IOError
[22:47] <DktrKranz> probably I don't use it correctly
[22:48] <jpds> DktrKranz: Where did your credentials get saved?
[22:49] <jpds> DktrKranz: It ought to be: ~/.cache/lp_credentials/ubuntu-dev-tools-write_public.txt .
[22:49] <DktrKranz> /home/dktrkranz/.cache/lp_credentials/ubuntu-dev-tools-write_private.txt.
[22:52] <pochu> does that belong to .cache or to .config?
[22:52] <jpds> DktrKranz: Odd, it's working here..
[22:52] <jpds> pochu: .cache.
[22:52] <DktrKranz> jpds, I re-launched manage-credentials with -e parameter and this time it worked
[22:53] <jpds> DktrKranz: Hmm, didn't use that for my token.
[22:56] <jpds> DktrKranz: Can you check if /usr/share/ubuntu-dev-tools/common.py has something like: http://pastebin.ubuntu.com/105356/ ?
[22:57] <DktrKranz> jpds, it has. My error was probably due to the fact I played with my environmental variables such as DEBEMAIL
[22:57] <jpds> DktrKranz: Ah, ok.
[22:57] <DktrKranz> I'll try to have a look tomorrow
[22:57] <DktrKranz> with a  clean environment
[22:58] <jpds> Report any bugs/errors, I'll fix them :)
[22:58] <DktrKranz> sure :)
[23:15] <Skiessi> hey
[23:16] <Skiessi> can I ask here for a package to be upgraded?
[23:16] <nhandler> Skiessi: It would be best to file a bug report about it on Launchpad
[23:19] <Skiessi> yes but I'm not the bug-reporting-in-launchpad type
[23:21] <Skiessi> I'll just mention it here and be wondering in a few years why they still haven't updated it
[23:36] <quadrispro> nhandler: thank you very much for your feedback! (you're right, and finally I've attached an ubuntu-to-ubuntu.debdiff to the last merge I've worked on :))
[23:37] <nhandler> I'm glad to hear that quadrispro
[23:37] <nhandler> I have no doubt that you will make a fine MOTU
[23:37] <nhandler> Keep up the great work
[23:37] <quadrispro> nhandler: thanks a lot
[23:56] <Chris`> Hello can someone explain to me how to build my debian/watch file?
[23:57] <pochu> Chris`: look at uscan(1), it has some examples
[23:57] <Chris`> uscan(1)?
[23:58] <pochu> uscan's manpage (section 1)
[23:58] <nhandler> Chris`: http://manpages.ubuntu.com/manpages/jaunty/en/man1/uscan.1.html
[23:58] <Chris`> Ok thanks pochu & nhandler
[23:58] <pochu> yw
[23:58] <pochu> hey nhandler :)
[23:58] <nhandler> Chris`: There is also https://wiki.ubuntu.com/PackagingGuide/Recipes/DebianWatch
[23:58] <nhandler> Hi pochu
[23:58] <pochu> didn't we have a cool bot for manpages?
[23:58] <nhandler> Not in here
[23:58] <nhandler> I know I added manpage support to my bot
[23:58] <pochu> ah ok
[23:58] <Chris`> nhandler: I've found the recipes guide to be absolutely no help at all regarding Debian/watch =x
[23:59] <nhandler> What didn't you like about them Chris` ?
[23:59] <Chris`> That they didn't work :)
[23:59] <Chris`> Ah the manpages are helping though


[00:23] <Akiva-Mobile> I am starting a project (A Tactical Realtime MMO game) for ubuntu phone, that I have thus far split into 5 branches: Client, Server, Database, Local Files, and Website. The server and perhaps database I want to keep partially closed source for pragmatic reasons (Advice taken from developers of other opensource mmorpg's). Never used launchpad really, and reading through the documentation,
[00:24] <Akiva-Mobile> I understand that you can't host any partly closed source applications on it? Am I incorrect?
[00:29] <lifeless> you can't host closed things for free; you can pay and host them.
[00:35] <Akiva-Mobile> lifeless: Cost allot?
[00:35] <Akiva-Mobile> I guess I could check :P
[00:38] <lifeless> I don't know the current price, sorry.
[00:42] <Akiva-Mobile> Found it
[00:42] <Akiva-Mobile> Launchpad Commercial Subscription (basic)£147.39
[00:42] <Akiva-Mobile> is that a one time subscription, or is it ongoing?
[00:45] <lifeless> I believe its annual
[00:47] <maxb> and priced per project, which could be annoying if your server and database were best developed as separate projects
[00:50] <Akiva-Mobile> maxb: I only branch it to make it easy for contributors. Hopefully, if I do use it, I can just keep the two in the same project
[02:08] <Akiva-Thinkpad> what is ubuntu's preferred open source license? I think linus's is gpl3.
[04:05] <Akiva-Thinkpad> I don't get this. In launchpad, do I just create one master project, and I can branch it appropriately from there (My project branches will have different licenses), or for every branch I want to have, I create a seperate  project for it, and then from there connect it to a master project?
[04:05] <Akiva-Thinkpad> Or should I not have a master project, just a Master Team?
[04:05] <Akiva-Thinkpad> and thus 5 seperate projects?
[06:34] <Akiva-Thinkpad> Having trouble understanding launchpad. I have a project that I want divided into 5 branches, some of which will be closed source. Do I do this with a single project, and create 5 bazaar branches, (which I don't understand given  mixed licences) or do I create multiple projects on launchpad, each dealing with a particular branch and its project?
[06:34] <Akiva-Thinkpad> The reason why I ask is because launchpad is not letting me create multiple projects saying that they are duplicates.


[02:05] <cprofitt> hello -- anyone available?
[02:22] <cprofitt> http://ftbeowulf.wordpress.com/2012/01/11/the-importance-of-accessibility/
[02:22] <cprofitt> let me know if you have any suggestiong to improve the post


[00:14] <fta> asac, does it build ? my 1st try didn't went very far
[00:16] <asac> fta: it built
[00:16] <asac> and the unittests work
[00:16] <asac> but its not the browser
[00:16] <asac> just the infrastructure
[00:16] <asac> the whole chrome/ and browser/ directory isnt build from what i saw
[00:18] <fta> i probably didn't use the right sources then
[00:19] <kgoetz> are you packaging google chrome?
[00:19] <fta> seems it's too early to do that
[00:20] <asac> fta: the latest fixes landed in the last checkins
[00:20] <asac> maybe run a svn up first
[00:21] <asac> kgoetz: i think it will take quite some time untl we are close to the browser
[00:21] <asac> the build dependencies dont even include any xlib ;)
[00:21] <asac> so all the UI is most likey non-existing ;)
[00:21] <kgoetz> ah, hehe. this could be a long term project *g*
[00:22] <asac> but maybe its all there and just excluded from build
[00:22]  * kgoetz wonders if this channel will become #ubuntu-webbrowsermanglers
[00:22] <asac> but most likely behind the walls at google ;)
[00:23] <asac> kgoetz: why not ;) ... approaching a broader audience gives more flexibility to bundle forces where they suite well ;)
[00:23] <kgoetz> asac: hehe, expanding your empire, one .deb at a time.
[00:25]  * kgoetz heads off to work. catch you in 90 minutes all :)
[00:25] <asac> well i wil be in bed hopefully
[00:27] <kgoetz> sleep well then, catch you another day
[09:48] <huats> Hi  there.
[09:48] <huats> I am updating a package that was depending on libxul previously and now depends on xulrunner-1.9
[09:49] <huats> The build went fine by the remplacement of libxul-dev with xulrunner-1.9-dev
[09:49] <huats> but when I launch it, I get an error of a missing libxul.so
[09:49] <huats> Of course I have xulrunner-1.9 installed
[09:50] <huats> (which provides the.so in question)
[09:50] <huats> but it is not yelling if I install xulrunner-1.9-dev
[09:50] <huats> any idea what might be wrong ?
[09:51] <huats> on a side note I have noticed with lintian that a rpath problem might be found there...
[09:51] <huats> do you think it is the cause of my problem (i am not very handy with rpath)
[10:06] <asac> huats: most likely it requires a bit of porting
[10:11] <huats> asac: ok
[10:12] <asac> huats: most likely your application uses pkg-config --cflags --libs libxul
[10:12] <huats> asac: AFAIK the application has been ported to xulrunner-1.9... It is really the packaging here...
[10:12] <asac> you need to use libxul-embedding-unstable
[10:12] <huats> ok
[10:12] <asac> huats: if its ported then you probably need to change a configure flag
[10:12] <huats> ok I'll have a look then
[10:13] <huats> asac: the thing is the problem is not at build time but at the execution time... which is why I am suprised
[10:18] <asac> huats: i am not surprised
[10:19] <asac> thats a wrong configure flag
[10:19] <asac> ;)
[10:19] <huats> :)
[10:19] <huats> asac: ok
[10:19] <huats> :)
[10:19] <huats> I'll check then
[10:19] <huats> asac: thanks
[10:25] <asac> huats: remember that some apps claim to have been ported to 1.9, but they are not
[10:25] <huats> asac: ok
[10:25] <huats> :)
[10:25] <asac> huats: the reason is that some project still dont understand the difference
[10:25] <huats> asac: I'll try to understand that... :)
[10:26] <asac> of compiling a plugin (which is basically what happens when you just build it like 1.8)
[10:26] <asac> and compiling and starting a standalone application
[10:26] <huats> asac: I think in that case it is the case since it works fine when I install xulrunner-1.9-dev
[10:26] <asac> which is different now in 1.9
[10:26] <asac> lots of project claimed to support 1.9, but it didnt even work ;)
[10:26] <huats> asac: I'll remember that :)
[10:26] <asac> huats: it works fine?
[10:27] <huats> asac: it can be executed yep
[10:27] <huats> but not if I remove the xulrunner-1.9-dev (and thus simply have the xulrunner-1.9)
[10:27] <huats> that is what suprise me
[10:28] <huats> thus I think the app have been really ported to 1.9 :)
[10:29] <asac> sounds wierd
[10:29] <huats> that was my guess too :)
[10:30] <huats> (and indeed with a simple ldd I can see that with the xulrunner-1.9-dev installed it founds libxul.so and libxpcom.so while not if I remove xulrunner-1.9)
[10:31] <huats> I have tried to change the configure flag "--with-gecko=xulrunner" to "--with-gecko=xulrunner-1.9" but same pb
[10:33] <asac> huats: look in configure.in/ac
[10:34] <asac> do they use PKG_CHECK_MODULES( .... libxul) ?
[10:34] <huats> nope
[10:34] <huats> asac: the only reference to xul in configure.ac is
[10:34] <asac> huats: so how do they get the build flags for xulrunner?
[10:34] <huats> LIBXUL_INIT
[10:34] <huats> LIBXUL_DEFINES
[10:34] <asac> huats: ok. that means they have a .m4 file
[10:35] <asac> which does that
[10:35] <asac> search for it ;)
[10:35] <asac> maybe libxul.m4
[10:35] <huats> asac: I was looking for it already :)
[10:35] <huats> indeed
[10:35] <huats> it is m4/libxul.m4
[10:35] <asac> huats: then look how that crappy thing does it ;)
[10:36] <asac> most likely it doesnt use PKG_CHECK_MODULES; but attempts to do stuff manually ;)
[10:36] <asac> but better check
[10:36] <asac> standalone applications need: libxul-embedding ... or libxul-embedding-unstable if you need more symbols
[10:37] <huats> ok
[10:37] <asac> (pkg-config --config libxul-embedding)
[10:37] <asac> err
[10:37] <asac> --cflags ;)
[10:37] <asac> and --libs
[10:37] <huats> there is no CHECK_MODULES reference in it
[10:37] <huats> simple CHECK_EXISTS
[10:37] <asac> as usual ... this file most likely comes directly from stoneage
[10:37] <asac> huats: ok. what CFLAGS do they define?
[10:38] <huats> that is what I am looking
[10:38] <huats> I need to read it
[10:38] <asac> try to search for XPCOM_GLUE
[10:38] <asac> if that string isnt there and they do it manually then its not properly ported to the standalone approach
[10:38] <huats> since they mention both (libxul and libxul-embedding  with a test case)
[10:38] <huats> ok
[10:38] <asac> huats: ok
[10:38] <huats> looking
[10:39] <asac> libxul-embedding is what is wanted
[10:39] <asac> pkg-config --cflags libxul-embedding will give you -DXPCOM_GLUE
[10:39] <asac> and other things
[10:39] <asac> but that is the important part
[10:40] <huats> no reference of XPCOM_GLUE in the .m4 file but there are such reference in the Makefile.{am,in}
[10:42] <huats> Apparently I can give a parameter to LIBXUL_INIT to use libxul-embedding instead of libxul (I'll try that right now)
[10:47] <asac> huats: yes. do that
[10:47] <asac> withoug libxul-embedding it wont work
[10:47] <huats> asac: ok
[10:48] <huats> but the questions remain why it work with xulrunner-1.9-dev :)
[10:49] <asac> not sure
[10:49] <huats> don't worry
[10:49] <asac> but i wouldnt waste time looking inot that
[10:49] <huats> sure
[10:49] <asac> unless we know they use libxul-embedding
[10:49] <huats> sure :)
[10:49] <huats> thanks a lot so much :)
[11:20] <huats> asac: stupid question : in the control file is it better that I build-depend on xulrunner-dev or xulrunner-1.9-dev ?
[11:21] <huats> so far I have used xulrunner-dev (since it is an empty package that depend on xulrunner-1.9-dev)
[11:21] <huats> but I'd like to be sure...
[11:21] <huats> and regarding the problem I am facing, I am working on that :)
[12:06] <asac> huats: if its a merge from debian keep xulrunner-dev
[12:06] <asac> otherwise use xulrunner-1.9-dev
[12:06] <huats> ok
[12:06] <huats> asac: thanks
[13:30] <fta> asac, yesterday, i finally had chrome fully built. indeed it's incomplete, just reftests for now. my previous attempt was with a direct svn checkout (~666M), about the same thing that we import in lp, it's far from complete. the sync using gclient brings 2.5G of junk, tons of ms binaries (exe, dlls) in the 3rd party dir but it's "buildable"
[13:31] <fta> i think i'll wait for it to move a bit further before i touch those scons file to see make the browser part build
[13:33] <asac> fta: we will create a chromium-project product
[13:33] <asac> with all the bitsw we need
[13:35] <fta> we need equiv of the --system-foo of mozilla, we already have most of the 3rd parties
[13:35] <fta> not sure about webkit though, they use a tag, slightly patched, don't know what we have
[13:38] <fta> seems there are also bin only files
[13:38] <fta> ex gears
[13:38] <fta> "The binaries in this directory were an official build for chrome"
[13:43] <asac> fta: from what i can tell we need "base" "v8" and "webkit" and "build" and chrome
[13:43] <asac> (out of my head)
[13:43] <asac> "net"
[13:43] <Volans> asac: you are already trying to compile google chrome for Ubuntu? :)
[13:44] <asac> Volans: it builds ... but is useless
[13:44] <Volans> no GUI?
[13:44] <asac> Volans: there is no gui code for linux in the "Hammer" build apparenlt
[13:45] <asac> they dont even have a single x-related library in build dependencies
[13:45] <asac> fta: there are a bunch of bin-only files
[13:45] <fta> i know
[13:46] <Volans> so they are far from an alpha version...
[13:46] <asac> imo the google folks confused svn with "storage" ;)
[13:46] <asac> maybe because they have this "we want all data syndrom" ;)
[13:46] <Volans> moreover I know that there are many problems with 64bit
[13:46] <asac> they are far far away
[13:46] <fta> there's even a full build of cygwin
[13:46] <asac> 64bit isnt going to fly
[13:46] <asac> and unless that works i wont even consider a alpha a real alpha
[13:47] <asac> fta: i think we need non of those binary stuff on linux
[13:47] <asac> we dont need third_party tools either i think
[13:47] <asac> scons is in the ubuntu archive and worked for me
[13:47] <asac> ill try if a build with the directories above works
[13:47] <asac> or see what else is missing
[13:47] <fta> we just need 1 or 2 of those stuff
[13:48] <asac> fta: what do you think we need?
[13:49] <asac_> reconnect
[13:50] <asac_> 14:47 < fta> we just need 1 or 2 of those stuff
[13:50] <fta> i don't remember which ones, i pointed out 1 or 2 yesterday. i need to recheck but it doesn't really matter for now, too early to spend time on that imho.
[13:50] <asac_> 14:48 < asac> fta: what do you think we need?
[13:50] <asac_> 14:48 < asac> if WebKit is the webkit code then maybe yes,
[13:50] <asac_> 14:48 < asac> but we probably want to try to use src/webkit bindings with our webkit ;)
[13:50] <asac_> 14:49 < asac> wtf is modp_b64 ;)
[13:50] <asac_> 14:49 < asac> sounds like a bomber :-D
[13:50] <asac_> fta: well. we could make a v8 package ;)
[13:50] <asac_> chromium-v8
[13:51] <asac_> i feel reluctant to put all that in one big piece of orig  ;)
[13:51] <fta> agreed
[13:52] <fta> if we split; we'll have to patch those scons files.. brrrr
[13:52] <asac_> well. i have to learn scons i guess ;)
[13:53] <asac_> but agree ... i feel like "why do i need to learn this again?"
[13:53] <asac_> doesnt look to difficult. but getting the best-practices right might not be trivial
[13:57] <fta_> reco
[13:58] <asac_> fta: when i run scons in v8
[13:58] <asac_> it starts like http://paste.ubuntu.com/43623/
[13:59] <asac_> (dont be confused ... its src/v8/src/third_party
[13:59] <asac_> not src/third_party ;)
[13:59] <asac_> lets see what comes out of building v8
[13:59] <fta_> ./third_party
[13:59] <fta_> ./base/third_party
[13:59] <fta_> ./chrome/third_party
[13:59] <fta_> ./chrome/Hammer/third_party
[13:59] <fta_> ./chrome/Hammer/base/third_party
[13:59] <fta_> ./googleurl/third_party
[13:59] <fta_> ./v8/src/third_party
[13:59] <asac_> most likely someone has opened an ITP in debian
[14:00] <asac_> lets see
[14:00] <asac_> fta: ye
[14:00] <asac_> ss
[14:00] <asac_> just running scons in v8 appears to work ;)
[14:00] <asac_> it produces a libv8.a ;)
[14:01] <fta_> probably but running scons in chrome will want to rebuild v8, that's what i meant by patching if we split
[14:01] <asac_> ah
[14:03] <asac_> fta: debian bug #497701
[14:04] <fta_> Version: 20080903-1  yeck
[14:05] <asac> fta: ok. want to take that ITP?
[14:05] <asac> ;)
[14:05] <fta_> Binary: libv8-dev, libv8b1.. libv8b1 ??
[14:07] <fta_> asac, not sure. i want to work on the full thing but it seems like a lot of work = lot of time and as i said, i'm still busy with work
[14:07] <fta_> but we'd better do something now if we think it's not going in the direction we want it to go
[14:08] <fta_> Build-Depends: debhelper (>= 5) .. not even python or scons ??
[14:08] <asac> fta_: that package of that guy?
[14:09] <fta_> yes
[14:09] <asac> havent looked
[14:09] <fta_> i want branches for all this
[14:09] <asac> does it produce a shared lib?
[14:10] <fta_> yes: http://paste.ubuntu.com/43630/
[14:10] <fta_> a lib without include/-dev packages...
[14:11] <asac> and with a non-existing shlibs version ;)
[14:13] <fta_> +++ libv8-20080903/debian/cron.d.ex
[14:13] <fta_> @@ -0,0 +1,4 @@
[14:13] <fta_> +#
[14:13] <fta_> +# Regular cron jobs for the libv8 package
[14:13] <fta_> +#
[14:13] <fta_> +0 4	* * *	root	libv8_maintenance
[14:13] <fta_> ?????????
[14:13] <fta_> oh, .ex
[14:13] <asac> most likely not a reasonable packaging ,)
[14:14] <asac> jcastro: hurry. wake up
[14:14] <fta_> nope
[14:14] <asac> jcastro: we need to setup a bunch of more chromium projects ;)
[14:14] <asac> jcastro: and you got stuck after https://edge.launchpad.net/chromium-project ;)
[14:15] <asac> (which should become a super project)
[14:15] <asac> https://edge.launchpad.net/chromium-v8
[14:15] <asac> https://edge.launchpad.net/chromium-net
[14:15] <jcastro> yep yet
[14:15] <asac> https://edge.launchpad.net/chromium-base
[14:15] <jcastro> waiting for the super project to be approved
[14:15] <asac> https://edge.launchpad.net/chromium-webkit
[14:16] <asac> http://v8.googlecode.com/svn/trunk
[14:16] <asac> http://src.chromium.org/svn/trunk/src/webkit
[14:17] <asac> all a bit messy i have to admit ;)
[14:17] <asac> jcastro: ok. lets wait then
[14:18] <fta> asac, create a page on the wiki so we can write down ideas
[14:20] <fta> what's happening to my motu application ? still stuck ?
[14:21] <fta> refused ?
[14:23] <asac> fta: no ... not all votes have been casted
[14:24] <asac> fta: dholbach is on it ... kicking the other council members ;)
[14:24] <fta> i see that one motu has been approved this morning, so it's not blocked for everyone :P
[14:28] <fta> meeting
[15:10] <asac> still frozen for alpha5 ... damn
[15:53] <thvdburgt> I was forwarded here from ubuntu-devel with this question:
[15:53] <thvdburgt> I have a question, I'm testing intrepid right now and when I open something I downloaded via the firefox download-dialog it does not respect my 'Open With' settings. Why isn't gnome-open or something similar used for this (I understand this opens it with the preferred operation)?
[15:59] <asac> thvdburgt: where did you configure the open with ..?
[16:03] <thvdburgt> Properties of the file. For instance. I use totem with .ogv files, but when I open it via FF's download-dialog it opens with banshee-1 . Looking at it now, does FF get the application from Preferences-Prefered Applicaions (Media-tab)?
[16:06] <thvdburgt> highlight asac
[16:15] <XioNoX> Hi!
[16:15] <asac> hi
[16:16] <asac> thvdburgt: go to preferences -> applications
[16:16] <asac> and change the app you wnat to use
[16:16] <asac> XioNoX: what i made out of it is now on the branch
[16:16] <asac> things work quite well
[16:16] <asac> in order to use the plugin switcher without the full_path option you need the latest xulrunner
[16:17] <asac> from  ~mozillateam
[16:17] <asac> PPA
[16:17] <XioNoX> the one in your PPA ?
[16:17] <XioNoX> ok
[16:17] <XioNoX> I have it
[16:17] <asac> otherwise it will only work with full_path on
[16:17] <asac> (well ... in hardy you need PPA anyway)
[16:18] <asac> XioNoX: only feature left is that we add a menu entry "search and install ..."
[16:18] <asac> which will spwawn the pluginfinder dialog
[16:18] <XioNoX> ?
[16:18] <XioNoX> We have already an menu entry
[16:19] <asac> XioNoX: no ... i mean in the plugin alternatives window
[16:19] <XioNoX> you mean not only for the activ page ?
[16:19] <asac> the popup that allows you to switch
[16:19] <asac> should also get a menu entry to search and install ... ;)
[16:19] <asac> (instead of switching)
[16:20] <XioNoX> ok
[16:20] <XioNoX> no news from mconnor ?
[16:21] <asac> Ill do it different ;)
[16:21] <XioNoX> ?
[16:21] <asac> ill open a new bug ... "allow preferred plugin for mime-type" ... to get the xulrunner patch with the prefs in
[16:21] <XioNoX> ok
[16:21] <XioNoX> nice
[16:21] <asac> when that has landed Ill try to get the ability to switch plugins in the preferences -> applications panel
[16:22] <asac> and when all that is done te only thing left is the plugin finder wizard
[16:22] <asac> but given that alternatives are then supported, we have a better argument to beg for that
[16:23] <XioNoX> ok
[16:23] <XioNoX> good
[16:26] <XioNoX> so there are things that I can do ?
[16:27] <asac> XioNoX: you can add that menu entry ;)
[16:27] <asac> look at how the popups look like in applications pane
[16:27] <asac> there is a separator and the then there are is an option "open with ..."
[16:27] <XioNoX> but I don't really understand what does this application menu
[16:27] <asac> or "choose other..."
[16:27] <XioNoX> err menu entry
[16:28] <asac> i opens the plugin finder wizard
[16:28] <asac> with the mimetype
[16:28] <asac> of the entry
[16:28] <XioNoX> ha
[16:28] <XioNoX> I understand
[16:28] <asac> do you know which popup i am referring  to?
[16:28] <asac> http://people.ubuntu.com/~asac/screenshots/plugin.alt.png
[16:28] <asac> the popup you see in that screen
[16:28] <XioNoX> so the user could chose directly what plugin file manage a mimetype ?
[16:29] <asac> XioNoX: well. he can do that now with that dialog
[16:29] <asac> what we want is that he can search for more plugins that serve that mime-type
[16:29] <asac> so if you just have adobe flash
[16:29] <asac> you cannot swtich atm
[16:29] <asac> so we add a menu entry that installs a new one
[16:29] <asac> so you can switch afterwards
[16:30] <asac> XioNoX: antoher thing we need is to hardcode plugin -> description mapping
[16:31] <asac> currently there is "Shockwave Flash 10.0..." for adobe
[16:31] <asac> and "Shockwave Flash 9.xx r999" for gnash
[16:31] <asac> i talked to gnash and swfdec guys
[16:31] <asac> and they said they cannot add something better to description as detection scripts sometimes look at that
[16:31] <asac> so we need to manually translate those plugins to something readable
[16:32] <asac> the idea is to look what the filename is and if contains
[16:32] <asac> libgnash ... its "Gnash, SWF Player"
[16:32] <XioNoX> ok
[16:32] <asac> if its libswfdec...  its "Swfdec, SWF Player"
[16:32] <asac> XioNoX: so what we want is to fix the GetDesc function
[16:32] <asac> to consider that
[16:32] <XioNoX> ok
[16:33] <asac> ok ... i am going to sports now ;) ... cu later
[16:33] <asac> (hopefully alpha5 freeze will be over tonight)
[16:33] <XioNoX> ok
[16:33] <XioNoX>  cu
[16:33] <XioNoX> thanks
[20:19] <fta> http://nion.modprobe.de/blog/archives/651-guid.html
[21:21] <fta> asac, http://ubuntuzilla.wiki.sourceforge.net/