[00:45] <hakaishi> Hey folks! Anyone up to advocate/review qt-shutdown-p? It is a small program to shutdown the computer. http://revu.ubuntuwire.com/p/qt-shutdown-p
[02:51] <lucas> Is Chuck Short around?
[02:52] <ajmitch> doesn't appear to be, he's usually online as zul
[02:53] <mrburns> hi all i am interested in getting involved with ubuntu and i hear that motu is a good place to start does anyone have any suggestions how to start?
[02:53] <RAOF> mrburns: Find a bug that annoys you, and fix it.
[02:54] <RAOF> That's generally the best thing to do.
[02:54] <mrburns> ok sounds good
[02:57] <RAOF> The easiest bugs to fix are those that have been reported upstream, fixed there, but not yet fixed in the Ubuntu packages.  In that case, it's generally just a matter of adding a patch to the Ubuntu package, which is one of the simplest packaging changes you can make.
[03:04] <mrburns> RAOF: should i just search around launchpad bugs and find something there?
[03:17] <RAOF> mrburns: Yeah, that works.  dholbach's harvest (http://daniel.holba.ch/harvest/) can help finding patches for stuff.
[03:19] <mrburns> RAOF: thanks
[07:18] <dholbach> good morning
[07:26] <slytherin> dholbach: good morning
[07:26] <ara> I have a packaging question, maybe someone can help me
[07:26] <ara> We used to have ldtp source, which provided ldtp (core, written in C) and python-ldtp (python bindings).
[07:26] <ara> Now, ldtp2 has just been released with the core completely rewritten in python and we need to package it for lucid. What would you recommend:
[07:26] <ara> a) Keep the core (now in python) in the ldtp binary, the python library in python-ldtp with version 2
[07:26] <ara> b) Put everything in ldtp binary (core and libraries)
[07:26] <ara> c) Create a new package called ldtp2 that replaces the two above
[07:27] <dholbach> hey slytherin
[07:27] <ara> non of the above?
[07:27] <dholbach> ara: is there a use-case for having any of them separated somehow?
[07:27] <ara> dholbach, no that I can think of
[07:28] <dholbach> one thing to bear in mind is coordinating the naming scheme with the debian people, so you don't end up maintaining a different package name for a longer while
[07:28] <ara> one important thing is that ldtp < 2 and python-ldtp <2 cannot cannot be installed at the same time as ldtp >= 2
[07:29] <ara> dholbach, I am already in contact with the debian packager
[07:29] <dholbach> or having conflicts/replaces that you need to maintain on your own for a long time in ubuntu (because of lts upgrades)
[07:29] <dholbach> nice
[07:29] <ara> dholbach, in fact, I am coomaintainer of the debian package
[07:29] <slytherin> ara: if parallel installability is not an option then simplest thing would be to completely replace existing packages with new version.
[07:29] <dholbach> ara: so Kartik ist leaving the decision to you? :)
[07:30] <ara> dholbach, yes, he has no time now to maintain it
[07:30] <dholbach> I see
[07:31] <slytherin> I believe Kartik has too may packages with his name on him. :-)
[07:31] <slytherin> s/him/them
[07:32] <ara> so, slytherin, you're suggesting to keep the division between core and libraries?
[07:33] <slytherin> ara: the split looks sane enough to me. But I don't use the package so probably I am not the best person to ask advice about it.
[07:36] <ara> dholbach, what do you think¿
[07:37]  * dholbach downloads source
[07:39] <LLStarks|Lazy> hi guys
[07:39] <LLStarks|Lazy> gst plugins bad needs the new dirac dependency
[07:40] <slytherin> LLStarks|Lazy: it was already uploaded but seems to have failed to build.
[07:41] <slytherin> LLStarks|Lazy: https://edge.launchpad.net/ubuntu/lucid/+source/gst-plugins-bad0.10/+builds
[07:41] <LLStarks|Lazy> ah gotcha
[07:41] <LLStarks|Lazy> thanks
[07:42] <slytherin> I am not able to access the build log at this time so I can not check if it was real failure or transitional failure.
[07:43] <slytherin> LLStarks|Lazy: if you can download the log, unzip it and post the relevant bits on pastebin may be I can decide if we should retry the build.
[07:44] <LLStarks|Lazy> will do
[07:44] <LLStarks|Lazy> hope its gzipd
[07:44] <slytherin> yes it is
[07:44] <slytherin> that is the reason I can not access it. the content filtering system in my office filters anything that ends with .gz
[07:45] <LLStarks|Lazy> asinine
[07:47] <dholbach> ara: I'm a bit unsure... at the moment I can't think of use-cases for splitting it, but I just had a look at http://www.debian.org/doc/packaging-manuals/python-policy/ch-module_packages.html#s-package_names - not sure if that would result in some kind of "oversplitting" as seb128 would call it :)
[07:47] <LLStarks|Lazy> looks like an sdl library problem
[07:49] <ara> dholbach, well, even if the use case is not clear, shouldn't be simpler to keep it split for the sake of maintainability?
[07:49] <ara> dholbach, (to avoid having to keep a lot of replaces)
[07:50] <dholbach> ara: the API of python-ldtp broke, right?
[07:50] <slytherin> LLStarks|Lazy: can you paste the log on pastebin?
[07:50] <ara> dholbach, yes
[07:51] <ara> dholbach, they are 90% compatible, but not 100%
[07:51] <LLStarks|Lazy> http://paste.ubuntu.com/359443/
[07:51] <dholbach> hmhm - I wonder if you'd need to rename stuff anyway in that case
[07:52] <dholbach> there's only mago depending on it afaics
[07:55] <SevenMachines> slytherin, LLStarks|Lazy: you might want to look at Bug #509442 , gst-plugins-bad0.10 is fixed upstream in debian but i'm guessing its actually an issue with sdl dev
[07:58] <slytherin> Looks like we need merge from debian package
[07:59] <dholbach> ara: you could ask seb128 when he shows up, he should know a bit better than I do
[07:59] <ara> dholbach, OK, I will, thanks :)
[08:02] <SevenMachines> slytherin: that would be best, it does need both the changes from 0.10.17-2 and 0.10.17-3 though, those are the ones i used and they work. i dont know where 0.10.17-3 is in terms of unstable/testing though
[08:02] <slytherin> SevenMachines: -3 is not yet in testing.
[08:23] <slytherin> Does anyone know at what version of glib, gio APIs were introduced?
[08:45] <tranx> Hi,
[08:45] <tranx>  I am having some difficulties for creating a package for "cython" application.
[08:45] <tranx> I was wondering whether it would be the good room to get some support on this issue ?
[08:46] <tranx> s/for "cython" application/for a cython application/g
[08:51] <randomaction> !ask
[08:53] <tranx>  I need to build a package that uses cython, but default pbuilder cannot resolve  "cython" when put into "build-depends" ..
[08:54] <randomaction> you need to enable universe - see https://wiki.ubuntu.com/PbuilderHowto#Universe%20support
[08:55] <tranx> is this enabled on build farms ?
[08:56] <johe|work> hi all
[08:56] <johe|work> i have a problem with an package maintained by motu https://bugs.launchpad.net/ubuntu/+source/python-pysnmp4/+bug/509495
[08:57] <johe|work> i would really need help on that
[08:57] <tranx> i.e. launchpad
[08:58] <tranx> I meant, I manage to get a working pbuilder with cython on my personal desktop, but I wonder how to get it working on launchpad, or other build servers.
[09:02] <johe|work> so than, this goes out to any python developer, if i dont get pysnmp working on karmic i need to programm my stuff in perl, and i really dont like :-(
[09:03] <randomaction> tranx: on buildds, build-dependencies from universe are disabled for packages in main. In other cases, they're allowed
[09:06] <tranx> randomaction: thanks for these elements.
[09:36] <slytherin> tranx: Paste the debian/control file somewhere so that we can check if there is any problem with build dependencies
[13:00] <ockham> sry for nagging, but as i can't see any communication going on here (only logon/offs): is there anybody at all?
[13:02] <geser> yes, but most people are probably busy with other things (like e.g. work)
[13:04] <ockham> too bad... gotta leave...
[15:30] <menesis> can I upload a fixed package to REVU with the same version number?
[15:31] <randomaction> menesis: yes, version should stay the same
[15:33] <menesis> do I have to include orig.tar.gz again?
[15:37] <menesis> looks like yes
[19:25] <hyperair> will there be a MC meeting on the 12th of february?
[19:29] <geser> hyperair: no, see the announcement
[19:29] <hyperair> geser: i saw. so how should i go about applying for motuship?
[19:30] <hyperair> the thursday meeting is at 3AM my time
[19:35] <geser> wait on the next DMB meeting, I hope we get a little bit further about the MOTU future on that meeting
[19:36] <geser> I hope the DMB comes about a decision what to do about MOTU applications while the future of MOTU is shaped
[19:46] <POX> porthose: :P (re: your mail to debian-python)
[19:48] <porthose> POX, :)
[22:25]  * StevenK tickles wgrant 
[22:26]  * wgrant swats StevenK 
[22:26]  * StevenK dodges wgrant's ineffective swat
[22:26] <wgrant> You can't dodge me, I'm next to yuuyou.
[22:26] <ajmitch> find a room, people
[22:27] <highvoltage> rofl
[22:27] <ajmitch> which talk are you at?
[22:28] <StevenK> MS versus FOSS
[22:28]  * ajmitch is staring at slides of PHP code, brains are leaking out
[22:28] <wgrant> We have found a room! Illot!
[22:29] <StevenK> Not so private, sadly
[22:29] <wgrant> Terrible.
[22:29] <pucko-> Hello.. I have a package I would like to see in ubuntu. I have made a deb archive of it (which needs some minor tweaking yet). can it be included even though there is no upstream url available? (I got the source by mailing the company)
[22:29] <RAOF> Are you able to distribute the source?
[22:29] <pucko-> it is a driver for a smart card reader btw
[22:30] <pucko-> yes. it is lgpl2.1
[22:30]  * ajmitch will have to watch that talk on video afterwards
[22:33] <pucko-> I'm not sure if it should be packaged separetely or of it should be included in libccid (which is a package for many other smart cart readers)
[22:34] <StevenK> wgrant: Saw a website recently that said "Microsoft has spent billions on Windows, how can Linux possibly run on a computer without Windows code, since Linux is free."
[22:35]  * StevenK should find the source
[22:35] <ajmitch> the leaps in logic there are interesting
[22:36] <StevenK> ajmitch: Absolutely.
[22:37] <RAOF> pucko-: Maybe it should end up in libccid, but that would require the code to be submitted to the libccid project.  As it's a separate source tree, it should (almost certainly) be a separate package.
[22:38]  * RAOF goes to wrestle with bugs.gnome.org to submit some gjs patches.
[23:11] <pucko-> RAOF, so how should I proceed? I believe I need some help
[23:14] <RAOF> pucko-: It'd be good if the source was easily available somewhere on the web, but I don't *think* that's a dealbreaker.
[23:14] <RAOF> pucko-: What you could do next is refine your package and upload the source package to REVU.
[23:14] <RAOF> !revu
[23:16] <pucko-> ok. the main thing is the lintian error messages. but I guess I can come back here later and ask for help about those..
[23:17] <RAOF> Absolutely.
[23:17] <RAOF> Note that running lintian with with -i will give lots of nice info about the errors, and generally how you might fix them.
[23:23]  * RAOF decides gjs probably doesn't want these patches.
[23:23] <pucko-> ok, thanks