[00:12] <ScottK> Dear everyone: Please testbuild before you upload.  I just 'love' it when I see FTBFS that there is no way could ever have worked.
[00:12] <ScottK> kthnxbye
[00:14] <directhex> i'm getting better at that!
[00:15] <dolanor_> (that's so a real pain to find email for the debian/copyright file !!)
[00:15] <dolanor_> 30 min to find a mail of a developer for 1 .h ... :(
[00:16] <directhex> dolanor, welcome to debian/copyright
[00:16] <directhex> please enjoy your stay
[00:17] <ScottK> directhex: In the case that caused me to save that the uploader had inexplicably added a new patch name to debian/patches/series when all the changes in the revision where in the debian dir (no patch).
[00:17] <ScottK> So it FTBFS when it couldn't find the non-extant patch.
[00:18] <dolanor_> directhex: thanks ^^'
[00:18] <ScottK> There is no way in God's green Earth that was test built.
[00:18] <ScottK> Unfortunately Daniel Hahler lives in +0100, so I imagine he uploaded and went to bed.
[00:20] <ScottK> If you see him, let him know I want that 15 minutes of my life back.
[00:20]  * ScottK steps off the soap box.
[00:21]  * Laney snoops
[00:23]  * directhex burns soapbox for warmth
[00:23]  * directhex also wonders the chances of a motu in the UK having an intel core i7 processor
[00:25] <Laney> Good god, how can I still *never* remember to run update-maintainer?
[00:26] <Laney> also, how does my housemate not understand that running your torrents at full upstream is not a good idea?
[00:26]  * Laney mutters
[00:26] <directhex> fire him into the sun?
[00:26] <directhex> also, bedtime
[00:27] <Laney> I think I will
[00:27] <Laney> nn
[00:27] <dolanor_> and when some people do captcha for email, that's even harder !
[00:27] <dolanor_> http://www.smilax.org/101
[00:28] <dolanor_> (love the area code of his)
[00:28] <ScottK> Laney: This will make your snooping easier: http://launchpadlibrarian.net/22618531/lighttpd_1.4.19-5ubuntu2_1.4.19-5ubuntu3.diff.gz
[00:28] <dolanor_> but when you see what 123people do, you understand why some become paranoid ...
[00:28] <Laney> ScottK: Yeah, I found it
[00:28] <Laney> why test build locally when you have several powerful buildds to do it for you?
[00:29] <ScottK> Yes, why confine the breakage to your system when you can break the archive.
[00:29] <ScottK> dolanor: Captcha for email?  You mean like Challenge and Response?
[00:34] <directhex> ScottK, "click this url and fill in the captcha for your mail to be relayed"
[00:35] <ScottK> I take stuff like that as a sign they don't actually want mail from me.
[00:35] <directhex> heh
[00:35] <directhex> anyway, bed
[01:05] <dolanor_> ScottK: yes some captcha
[01:05] <dolanor_> not automatic, though
[01:06] <dolanor_> You have to understand english to determine his mail or physical address
[01:06] <dolanor_> hmmm, is the mail in copyright mandatory ? I've search for 30 min for 1 email, and can't find any clue for that ...
[01:08] <nhandler> dolanor_: I don't think it is mandatory
[01:12] <dolanor_> nhandler: ok, so i'll skip this one :o
[01:12] <dolanor_> lucky me, he was the last one
[01:18] <dolanor_> what is the command to avoid typing gpg password at each debuild ?
[01:19] <ScottK> dolanor: Install gnupg-agent.
[01:21] <dolanor_> i have gpg-agent running, is it that ?
[01:23] <tgm4883> dolanor, I followed this https://help.ubuntu.com/community/KMailGPGAgent
[01:24] <tgm4883> F me
[01:24] <tgm4883> dolanor, and by that link, I meant https://help.ubuntu.com/community/GnuPrivacyGuardHowto
[01:24] <tgm4883> sorry about that
[01:27] <quadrispro> dolanor_: hi! hexdiff looks good, I'm test-building it now
[01:28] <dolanor_> sorry quadrispro, I misguided you with X-Comment
[01:28] <dolanor_> you were right !
[01:28] <dolanor_> I was too lazy to read the entire RFC :o
[01:28] <quadrispro> :)
[01:28] <quadrispro> it builds fine -> http://home.alessiotreglia.com/jaunty/result/hexdiff_0.0.53-0ubuntu1/hexdiff_0.0.53-0ubuntu1.buildlog
[01:28] <dolanor_> I'm reading it tgm4883, thanks :)
[01:29] <quadrispro> dolanor_:  there's just a little thing -> I: hexdiff: hyphen-used-as-minus-sign usr/share/man/fr/man1/hexdiff.1.gz:7
[01:36] <dolanor_> quadrispro: oh, I thought I corrected that one
[01:37] <dolanor_> hmmmm, that's the original manpage
[01:37] <dolanor_> I didn't modify it at all
[01:37] <dolanor_> must I provide a patch ?
[01:37] <quadrispro> dolanor_: no no
[01:37] <quadrispro> dolanor_: it's not very important
[01:39] <dolanor_> tgm4883: hmmm, the pinentry-gtk doesn't work for me
[01:39] <dolanor_> I can't use the graphical gpg manager of gnome
[01:39] <quadrispro> dolanor_: the application name is Visual Hexdiff -> http://tboudet.free.fr/hexdiff/
[01:39] <dolanor_> don't know why ...
[01:39] <dolanor_> I can't type in
[01:39] <quadrispro> dolanor_: why upstream doesn't provide the last release?? :-/
[01:40] <dolanor_> Not sure :) google for it. If you type "visual hexdiff", it find some sites speaking of this one. If you type "Visuel hexdiff", you get the official website
[01:40] <dolanor_> because I'm in close contact with upstream
[01:41] <quadrispro> ah-ah! you're right
[01:41] <quadrispro> ok ok
[01:41] <dolanor_> he wait for me to upload the new version
[01:41] <dolanor_> since he is quite busy, he hasn't time to upload every minor thing that I change :p
[01:42] <quadrispro> I understand
[01:52] <quadrispro> dolanor_: uploaded to Jaunty NEW
[01:52] <quadrispro> bug 317331
[01:58] <tgm4883> doko, did you go though the tips and tricks part of that link/
[02:00] <dolanor_> quadrispro: \o/
[02:00] <dolanor_> thanks :)
[02:01] <quadrispro> you're welcome
[02:01] <quadrispro> thanks for your work ;)
[02:02] <ScottK> dolanor: pinentry-gtk you almost certainly don't want.  Try pinentry-gtk2.
[02:04] <TheMuso> c
[02:05] <ScottK> dolanor: What release are you running?
[02:07] <dolanor_> ScottK : the pinentry bug since I use SCIM ...
[02:07] <dolanor_> https://bugs.edge.launchpad.net/ubuntu/+source/seahorse/+bug/284044
[02:08] <ScottK> dolanor: seahorse is not much of an agent.  It's pretty broken.
[02:08] <ScottK> dolanor: The reason I ask is that we removed pinentry-gtk in Gutsy, so either you've upgraded your system several times or you're using an olde release.
[02:09] <dolanor_> no no, I was using a shortcut
[02:10] <dolanor_> I don't know exactly what utility it use, but this is the window from seahorse when I have GPGKEY env set
[02:10] <dolanor_> can't I use the gpg-agent with only terminal prompt ?
[02:11] <ScottK> You should be able to.  I don't use Gnome, so I can't say how Seahorse gets involved.
[02:13] <jmarsden> dolanor_: sudo apt-get install gnupg-agent  && man gpg-agent
[02:14] <dolanor_> jmarsden: already done, the bug is between scim and seahorse
[02:14] <dolanor_> :)
[02:14] <ScottK> jmarsden: Part of the problem is that Seahorse is involved.  It's a crap gpg-agent in it and the actual gnupg-agent don't play well together.
[02:14] <dolanor_> I've killed the seahorse-agent processus, and relaunched gpg-agent --daemon
[02:14] <jmarsden> OK... so just use gpg-agent in your .profile and forget seahorse... right.
[02:14] <dolanor_> and now I've got some Qt4 window, lol... But at least... It works :)
[02:15] <kolby> seahorse could get better.
[02:15] <kolby> right now it isn't very useful.
[02:16] <dolanor_> another question ... Any cdbs guru there ?
[02:17] <ScottK> kolby: As recently as the version in Hardy it would do 'fun' stuff like remove an existing gnupg.conf and replace it with a blank one (except I nice comment confessing it's sins).
[02:17] <ScottK> !ask
[02:17] <ScottK> dolanor: ^^
[02:17] <dolanor_> ^^
[02:18] <kolby> World of Goo came out for Linux today
[02:18] <kolby> it's a game I've never heard of... it has a debian package => it's related to motu.
[02:18] <kolby> (not really) I just found it interesting.
[02:19] <dolanor_> In debian/rules with cdbs, it tells : put any env var here (after the makefile.mk include, etc ...) but if I set DEBBUILDDIR after the include ... the options is not passed to make
[02:19] <dolanor_> kolby: world of goo is a great game
[02:19] <dolanor_> I don't really like puzzle game, but I think I like this one very much :)
[02:19] <kolby> Yay !  ^^
[02:19] <kolby> I have the demo
[02:20] <dolanor_> yes me too
[02:20] <kolby> I might buy it then
[02:20]  * kolby plays games...
[02:20] <dolanor_> I can't afford the 15€ right now (french taxes, ouch), but next month, he is mine
[02:20] <sbaginov> hi all! got a bug to file... any info on how to do it?
[02:20] <dolanor_> so I'll play the demo ... And for now I'm blocked by tower of goo
[02:20] <kolby> launchpad, right?
[02:21] <dolanor_> sbaginov: just fill the bug description in launchpad :) (But verify if it doesn't exist on launchpad already)
[02:21] <kolby> Then there's this:  https://help.ubuntu.com/community/ReportingBugs
[02:21] <sbaginov> thank you
[02:22] <kolby> I hope I gave you the right info.  I'm new here.
[02:23] <sbaginov> yes, i found the bugs list and no info on mine, but i did not know how to report it even if i was logged in. i thought that motu had its page to report bugs
[02:24] <dolanor_> I think I'll buy world of goo for my mother... I just installed ubuntu for her ^^ Must keep her on it by any means :p She is fond of those type of games
[03:08] <tgm4883> Can I please get a REVU on http://revu.ubuntuwire.com/p/mythnettv
[03:35] <dolanor_> tgm4883: looking at it
[03:35] <tgm4883> dolanor_, thanks
[03:38] <dolanor_> tgm4883: ftbfs
[03:38] <tgm4883> :/
[03:38] <dolanor_> tgm4883: just kidding
[03:39] <dolanor_> but I'm no expert in python package
[03:39] <tgm4883> lol, you got me ;)
[03:39] <dolanor_> from what I see, it is good
[03:39] <dolanor_> except from the COPYING file
[03:39] <dolanor_> it is still in the .deb
[03:39] <tgm4883> what about the copying file?
[03:39] <tgm4883> hmm
[03:40] <tgm4883> let me get on that like a pirate getting some booty
[03:41] <dolanor_> as said superm1 or mok0, there shouldn't be a COPYING file in the .deb, only the source file
[03:41] <dolanor_> I'm commenting on revu
[03:45] <dolanor_> did you patch yourself the original source package ?
[03:45] <dolanor_> without dpatch ?
[03:46] <tgm4883> dolanor_, when adding the license?
[03:48] <dolanor_> I speak for setup.py
[03:48] <dolanor_> hmmmm, I may be dumb
[03:48] <dolanor_> wait :p
[03:49] <dolanor_> no I'm not that dumb :p
[03:49] <tgm4883> all editing i've done should be in either dpatches or done upstream
[03:49] <dolanor_> so you wrote setup.py in upstream ?
[03:49] <tgm4883> yea
[03:49] <dolanor_> ok
[03:49] <dolanor_> so, 1 more issue with copyright :)
[03:49] <dolanor_> gflags.py is full of google coder copyright
[03:49] <dolanor_> and BSD license i think
[03:49] <dolanor_> you should add it
[03:49] <tgm4883> hmm
[03:50] <tgm4883> ok, will do
[03:50] <dolanor_> Added comment on revu
[03:50] <dolanor_> and now ... goind to bed ..., already 5:50
[03:50] <dolanor_> bye
[03:52] <tgm4883> night
[09:46] <kpirc> Anyone around who could have a peek at one last issue I'm having with a package on REVU? It's "modglue".
[09:51] <persia> kpirc, What issue are you having?
[10:03] <kpirc> persia, another MOTU made a remark concerning re-factoring of debian/rules to account for arch all in the -dev package. I don't understand what that comment means.
[10:06] <persia> kpirc, Well, packages that are arch-specific or arch-any will run the binary-arch rule.  Packages that are arch-all will run the binary-indep rule.  Your current binary-indep rules doesn't do anything, so it won't build the arch-all binary.
[10:07] <kpirc> persia, strange, when I build the binary packages I do get a -dev package which contains the relevant files. In any case, should I just copy the stuff below binary-arch to the binary-indep section?
[10:08] <persia> kpirc, Also, it's recommended to pass -a and -i to debhelper programs when building both arch-dependent and arch-independent packages from the same source.
[10:08] <persia> Well, you might not need all of them, but yes.
[10:09] <persia> In fact, you don't need all the ones you have listed now for arch-specific.  Read the manpages: I suspect you'll find that many can just be removed.
[10:09] <persia> What architecture do you run?
[10:09] <kpirc> i386
[10:09] <persia> Try setting up an lpia pbuilder or sbuild chroot in parallel.
[10:10] <persia> When you build packages on i386, it builds both arch-dependent and arch-independent binary packages by default.
[10:10] <persia> With lpia, it won't build the arch-independent binary packages by default.
[10:10] <persia> If you try your current source, you'll find that it builds your -dev package also on lpia, which is the source of the complaint.
[10:11] <persia> (for those with amd64 environments, the recommendation is to use i386 and amd64 chroots, as amd64 doesn't get arch-all by default either: no lpia required).
[10:13] <wgrant> persia: Can one not also test just with i386?
[10:15] <kpirc> ok, so now I'm thoroughly confused. Can you give me a rough guess of what my binary-indep and binary-arch parts of debian/rules should look like? I see no dh_* calls which seem to have anything to do with installing the header files, so I don't understand how to change these sections.
[10:16] <persia> wgrant, I suppose.  I find it easier to launch two sbuild sessions in separate architectures and examine the results than remember the appropriate flags to pass to override the default behaviour, and build twice.
[10:17] <persia> kpirc, First lets trim you binary-arch rule.  Do you need each of the helpers?  Also, you want to pass -a as an argument.
[10:20] <kpirc> I don't think there's any helpers that can be dropped, given that this is building a shared library. Should '-a' be given as an argument to all helpers or only specific ones?
[10:20] <persia> OK.  Let's look at some specifics.  How are you using dh_installdocs?
[10:21] <persia> -a should be passed to all helpers in the binary-arch target, and -i to all helpers in the binary-indep target
[10:22] <kpirc> I don't know whether that gets used. I never understand which files these helpers act on, so I was assuming that READMEs and other related material would get installed by this helper.
[10:22] <persia> Does reading man dh_installdocs help you determine this?
[10:23] <kpirc> well, it mentions installing debian/copyright, so I guess I need this one.
[10:23] <persia> OK.  It would also install a README if your package had one, but it doesn't, so it's not important, and yes, you need this one.
[10:23] <persia> How about dh_installexamples?
[10:25] <kpirc> Bad man page for that one. How does dh_installexamples figure out which files count as 'examples'? Does it not do anything without parameters?
[10:26] <persia> It can either take arguments, or look in the contents of a file named "debian/package.examples".  It does nothing if there are no arguments, and this file doesn't exist.
[10:26] <persia> In the case of your package, you have a nice examples directory, which you probably want to install as examples.  Given that it's dev examples, you probably want to install it in the -dev package.
[10:27] <persia> I'd recommend only having `dh_installexamples -i -plibmodglue1-dev` in binary-indep, and not including it in binary-arch.
[10:27] <kpirc> ok. Why the explicit -plibmodglue1-dev ?
[10:28] <persia> Because I think you want to include the examples only for that package.  Of course, you could run it for all arch:all packages, and just only have debian/libmodglue1-dev.examples contain anything.  Your choice.
[10:29] <persia> With the extended argument, I believe you can just use debian/examples.
[10:29] <persia> Since it doesn't matter which way you do it, please pick the one that makes more sense to you.
[10:31] <kpirc> ok
[10:35] <persia> Shall we go through the others individually, or would you like to go through them, and just ask if you have questions?
[10:37] <kpirc> I would say that for a minimal -dev which only installs the 'examples' directory and the header files, I need
[10:38] <kpirc> 	dh_testdir -i
[10:38] <kpirc> 	dh_testroot -i
[10:38] <kpirc> 	dh_installexamples -i
[10:38] <kpirc> 	dh_fixperms -i
[10:38] <kpirc> 	dh_installdeb -i
[10:38] <kpirc> 	dh_gencontrol -i
[10:38] <kpirc> 	dh_md5sums -i
[10:38] <kpirc> 	dh_builddeb -i
[10:38] <kpirc> (plus the debian/libmodglue1-dev.examples file containing 'examples').
[10:38] <persia> Well, I'd probably put the manpages in the -dev package, so put dh_installman there, and dh_compress
[10:39] <StevenK> kpirc: Please use a pastebin
[10:39] <persia> I'd also suggest putting the changelog there, either with dh_installchangelogs, or with dh_link to the changelog from the actual library.
[10:40] <kpirc> no, there are some small binary helper programs which go into the non-dev package, and they need manual pages.
[10:40] <directhex> i'd use dh7, and not manually list any dh_foo stuff
[10:40] <kpirc> (the library itself is still not properly documented; have been spending my time making debian packages ;-))
[10:40] <kpirc> StevenK: sorry
[10:41] <persia> kpirc, So you'd have your section 1 pages in the tools package and the section 3 pages in the -dev package, so you'd put it in both (and need to add a couple package.manpages to get them included with the right binary.
[10:42] <persia> Where "both" means binary-arch and binary-indep (sorry for the lost referent).
[10:43] <kpirc> I only have section 1 pages so far, so I'll keep this as-is for now.
[10:44] <persia> Well, OK, but don't be too surprised if some future reviewer balks at a lack of manpages :)
[10:45] <kpirc> I know. The problem is that I'm only packaging modglue because it is needed by my cadabra package (also waiting on REVU). If I had known all this I would probably have stuffed the lot into cadabra itself, and made it non-public and statically linked to the binary.
[10:46] <persia> kpirc, Well, then you would have had complaints about static linking and embedded libraries :)
[10:47] <persia> Anyway, I'm not sure everyone checks for library-missing-manpage: you might get lucky.
[10:47] <kpirc> you can never please them all...
[10:47] <kpirc> It's work in progress, I can't do all at once _and_ get a decent number of users interested.
[10:48] <kpirc> Release early, release often, so to say.
[10:48] <loic-m> kpirc: you can also just check a common library man page and use it as a model - it saves a lot of time, and might end up faster ;)
[10:49] <persia> loic-m, Except that a *good* set of library manpages actually document each function call, which is a bit more documentation than most application manpages.
[10:49] <kpirc> loic-m: any recommendations for a good C++ library man page? I never use them, they are mostly of the microsoft form: "do_something():  this function does something."
[10:50] <loic-m> persia: that would be quite a pain then ;)
[10:52] <persia> loic-m, Which is precisely why not everyone checks for library-missing-manpage.  Pretty much every reviewer checks for binary-missing-manpage, as that's more directly exposed, and much easier to fix in packaging.
[10:54] <loic-m> kpirc: I can't remember having read any... As long as the doc is there in a way or another (I just checked a bit and couldn't find one ;) )
[10:55] <kpirc> All in the header files so far. It takes _a lot_ of effort to write good library docs, I'd rather have none than a bunch of useless pages.
[10:57] <persia> loic-m, The manpages-dev package as some very good examples, as does glibc-doc.
[10:57] <kpirc> neither of those are C++
[10:57] <directhex> monodoc!
[11:00] <persia> kpirc, libcrypto++-doc has some C++ examples (dunno how good).  Anyway, as discussed above, let's skip writing full documentation for a single-user library right now, and focus on your packaging.
[11:04] <kpirc> persia, ok, I have uploaded a new version to revu, can you give that a look?
[11:04] <mok0> kpirc, look at doxygen
[11:05] <persia> kpirc, I thought you had manpages for some of the helper binaries that belonged in an arch-specific package.
[11:05] <mok0> It can extract documentation from your source files
[11:05] <AndrewGee> Hey all. Any MOTUs available to review my package, gpxviewer? It's an application that allows users to look at GPS traces files in GPX format. Thanks :) http://revu.ubuntuwire.com/details.py?package=gpxviewer
[11:05] <kpirc> mok0: I don't like doxygen, it tends to focus on documentation in which each and every function is documented well, but there is no proper overview (I know, you can do that with doxygen too, but it does not really help you in that area).
[11:06] <persia> kpirc, Also, you either need to install a changelog for your arch:any stuff, or link it with dh_link.
[11:06] <persia> Lastly, how are you using dh_link for your arch:any packages?
[11:06] <persia> On another note, why does control specify debhelper (>=5) and compat have "4"?
[11:06] <kpirc> persia, "dh_link -a". I guess that can go too.
[11:07] <kpirc> persia, because it took me more than 6 months to have someone look at this package... In the meantime versions bumped several times.
[11:07] <mok0> kpirc: that depends on how you do the markup
[11:07] <mok0> mok0: up to you of course
[11:08] <persia> kpirc, I understand the delay, which is why I'm not suggesting dh7: it's just the inconsistency that stands out.
[11:10] <persia> kpirc, Reading through the comments, I'm also curious why you haven't included mok0's contributed symbols file.
[11:12] <persia> kpirc, You probably also want to check the "legal" link from your REVU upload.  I suspect there may be issues with some files (I didn't look in depth).
[11:13] <kpirc> persia: ok, fixed dh_link, compat version, included the symbols file (was on a different machine, forgot to check it in there). Will now check legal.
[11:15] <kpirc> persia: legal, ouch, this is a serious pain, will have to go through all files now. Hang on.
[11:33] <kpirc> persia, ok, have uploaded a new version. Please have a look, and leave a comment on REVU if there's anything else missing (have to run now). Thanks a lot for the help!
[11:55]  * directhex smiles sweetly @ motu-release
[11:56] <sebner> DktrKranz: your turn \o/
[11:57] <DktrKranz> sebner, huh?
[11:58] <DktrKranz> btw, congrats Debian! \o/
[11:58] <sebner> DktrKranz: heh, MD2 beta needs motu-release love to make it into the archive ;D
[11:58] <DktrKranz> md2?
[11:58] <sebner> DktrKranz: monodevelop 2 :P
[11:59] <DktrKranz> heh
[11:59] <DktrKranz> it's not motu-release time already
[11:59] <directhex> DktrKranz, not until tuesday, but reality has a horrible habit of doing things an expected way... see https://lists.ubuntu.com/archives/ubuntu-motu/2008-November/005025.html
[12:02] <DktrKranz> directhex, which stage is current development?
[12:02] <directhex> DktrKranz, beta 1 preview packages are building and being tested
[12:03] <DktrKranz> directhex, has schedule for 2.0 final been defined?
[12:03] <directhex> DktrKranz, yes, let me find their release schedule...
[12:03] <mok0> Is it ok if I tag packages on REVU with my nick? It is a useful way to keep track of  packages I've looked at. It does pollute tag-space, though
[12:04] <sebner> DktrKranz: mid march -> final releaes
[12:04] <sebner> DktrKranz: http://www.monodevelop.com/Development_Roadmap
[12:04] <directhex> DktrKranz, http://monodevelop.com/Development_Roadmap
[12:04] <directhex> hah
[12:04] <sebner> :)
[12:04] <DktrKranz> which one should I follow? :P
[12:04] <DktrKranz> not sebner's ;)
[12:04] <directhex> DktrKranz, we delayed packaging work until upstream feature freeze, so updating the packages would be 0-effort
[12:05] <binarymutant> is there a ruby package that doesn't use cdbs?
[12:05] <directhex> i.e. who knows what would break from alpha1->alpha2 from a packager perspective, but beta1--->final should just be uupdate
[12:06] <DktrKranz> directhex, if we have 2.0beta1 now, I think we can safely ship 2.0 final before release day
[12:06] <DktrKranz> the question is if we want 2.0beta1 now
[12:06] <DktrKranz> I guess there will be several bugs fixed since 1.0
[12:07] <directhex> DktrKranz, yes, and some major new features
[12:07] <directhex> DktrKranz, hence worried about feature freeze more than bug fixes, since bug fixes are due in beta2 and final too
[12:07] <DktrKranz> could we gather some informations and bug fixed somewhere, and make packages available for testing?
[12:09] <directhex> DktrKranz, trying to get my hands on a source package for ppa love
[12:10] <DktrKranz> I could test it from a mono-dumb perspective
[12:10] <DktrKranz> (so I can understand C# a bit)
[12:10] <directhex> DktrKranz, well MD is a nice IDE for other languages too
[12:10]  * DktrKranz is basically a Python-lover guy
[12:11] <directhex> it has a python plugin afaik
[12:12] <directhex> though c# is the main focus of it, that's true
[12:23] <DktrKranz> Laney, gnome-do-plugins FTBFS applying 03_buildsystem_respect_mcs.dpatch, removing it should fix it. Mind looking at it?
[12:23] <Laney> DktrKranz: I am
[12:23] <Laney> and there's another problem
[12:38] <DktrKranz> Laney, re bug 328224, it seems package in experimental didn't transition to new gnome-sharp2 packages
[12:43] <Laney> DktrKranz: is it uninstallable?
[12:44] <DktrKranz> it is until we ship old gnome-sharp2 packages, which are scheduled for removal before release
[12:44] <directhex> DktrKranz, the gnome# transition is a mess. experimental doesn't help
[12:44] <geser> aren't the old gnome-sharp2 packages already on NBS?
[12:44] <DktrKranz> geser, they are
[12:44] <directhex> geser, yes
[12:45] <DktrKranz> directhex, fortunately we're close to finish it
[12:45] <directhex> DktrKranz, excellent
[12:45] <Laney> DktrKranz: Then you'll submit all patches to Debian?!
[12:45] <Laney> ;)
[12:45] <geser> iirc only package build-depending on it are still to be done (tomboy is in progress)
[12:46] <DktrKranz> Laney, not sure if they already have new gnome-sharp2
[12:46] <directhex> problem is there's a little API breakage as well as ABI
[12:46] <directhex> DktrKranz, in experimental... but experimental is a funny beast
[12:46] <DktrKranz> heh :)
[12:46] <Laney> we need to do this transition somehow
[12:46] <Laney> we = debian
[12:46] <directhex> DktrKranz, i.e. you cherry-pick version numbers on things, so building against mono from exp but gnome# from sid is possible
[12:46] <directhex> and infact building against gnome# from exp is hard
[12:46] <DktrKranz> I noticed ;)
[12:47] <DktrKranz> but I noticed it in jaunty, which should *not* be a funny beast at this stage
[12:47] <geser> re Debian experimental: someone set an alias for experimental on the Debian archive: rc-buggy :)
[12:47] <c_korn> http://pastebin.com/d38c51efc lintian message misses the important part. do you know what is going wrong?
[12:48] <geser> remove build-essential from your Build-Depends line in debian/control
[12:48] <DktrKranz> directhex, Laney: except for b-d mangling, there aren't many changes. I just faced some GnomePrint routines (obsolete) to be removed
[12:49] <DktrKranz> I use sed to make this transition ;)
[12:49] <DktrKranz> sed -i 's/libgconf2.0-cil/libgconf2.24-cil/;s/libgnome2.0-cil/libgnome2.24-cil/;s/libgnome-vfs2.0-cil/libgnome-vfs2.24-cil/;s/libart2.0-cil/libart2.24-cil/' debian/control
[12:49] <c_korn> geser: I had the build-dependency g++ before there. lintian wanted me to replace it with build-essential
[12:50] <geser> c_korn: you don't need g++ in Build-Depends unless you need it versioned (very unlikely)
[12:51] <c_korn> so g++ can be expected to be installed in every build environment?
[12:52] <directhex> DktrKranz, we can start to move things to unstable now, where the "funny" goes way..... but meebey's priority is now MD2 ;)
[12:52] <geser> yes, it's guaranteed that build-essential (and it dependencies) are always installed
[12:53] <c_korn> ok, thanks
[12:53] <DktrKranz> directhex, if I can borrow a hand... I'm definitely not good in C#, but it's a good way to learn things
[12:57] <directhex> DktrKranz, i've been working hard in the background really at the debian end... if you need specific help with something, let me know
[12:57] <DktrKranz> sure
[12:57] <DktrKranz> thanks ;)
[12:57] <directhex> DktrKranz, i contribute to ubuntu through alioth & LAUNCHPAD ;p
[12:58] <directhex>  BAH capslock
[13:30] <Laney> DktrKranz: I will fix muine and muinescrobbler
[13:31]  * DktrKranz hugs Laney 
[13:34] <_16aR_> Hello
[13:44] <DktrKranz> does anybody notice sound issues with jaunty. my audio is quite distorted
[13:53] <dolanor_> is it possible to have some sort of orig.tar.gz like that : soft_x.y.z-revision.orig.tar.gz ?
[13:53] <dolanor_> with revision made of text
[13:54] <pop79> hi
[13:54] <pop79> im wanting to get involved
[13:54] <dolanor_> pop79: no problem :)
[13:54] <pop79> wait
[13:54] <persia> dolanor, You can certainly do that, although it's only in the rare case you wish to do so.
[13:54] <dolanor_> Lot of work to be done :)
[13:54] <pop79> what im wanting to do is design a presentation of ubuntu
[13:55] <dolanor_> persia: the fact is that the revision is some sort of branch of the original soft. Not already released right now (I've asked upstream to do so). This branch only add Cmake support
[13:55] <mok0> dolanor: doesn't the 1.2.3.4.5.... scheme give you enough variables for defining your version ;-)
[13:55] <pop79> i was discussing it on #ubuntu-offtopic, but they didn't like the idea
[13:55] <persia> pop79, Based on what you've said above, and what you've said on #ubuntu-devel, I'd recommend chatting with the folk in #ubuntu-docs to both build on the work already done, and integrate with future efforts.
[13:56] <pop79> ok
[13:56] <persia> dolanor, Hrm.  That's trickier.  It's usually only used for things like ~ppaX or +dfsgX.  Dunno how to advise you.
[13:56] <pop79> there is only one person there
[13:56] <persia> mok0, Think multiple parallel trees...
[13:56] <dolanor_> persia: and since the original Makefile aren't that cool (I have to modify a lot to have shared lib compiling instead of static, with soname support, etc... With cmake, only a 1 line patch do this
[13:57] <dolanor_> or else, I do a static lib package, but I don't like the idea
[13:58] <pop79> there is soooo much i want to do to help the ubuntu project
[13:58] <dolanor_> as it is preferred to have dynamic lib into debian
[13:58] <dolanor_> (that's a 2d physcis engine in C++)
[13:59] <persia> dolanor, I'd recommend working with upstream to build a common solution, rather than patching in a branch, and packaging your branch.  It will save considerable coordinate issues later.
[13:59] <dolanor_> ok... I try to do with my version and see what happens ?
[13:59] <dolanor_> ok
[14:00] <dolanor_> because right now, the original upstream is ok to add cmake support. But hasn't done it. So the only package is an embedded archive in the forum. Or else you must get it from a branch in the svn
[14:09] <iulian> DktrKranz: Yes, I have the same issue.  I believe there is a bug reported, not sure though.
[14:10] <DktrKranz> iulian, nice to know. If you will remember, could you please subscribe me?
[14:10] <iulian> Sure
[14:21] <geser> dolanor_: using x.y.z-revision as upstream is possible but you have to use an pkg-revision also, e.g. x.y.z-revision-0ubuntu1
[14:21] <geser> as packageversion
[14:26] <persia> One shouldn't use "-" for that, if it can be avoided, as it's confusing.  "+" is generally preferred.
[14:27] <dolanor_> no problems if I use + instead of - then ?
[14:28] <dolanor_> so If I use : box2d_2.0.1+cmake.orig.tar.gz, every body is ok ?
[14:29] <dolanor_> I can even drop the cmake if wanted. That was just better to track from what source it was since it wasn't the official release available in the download section of sourceforge
[14:29] <geser> it's a least better than using 2.0.1-cmake
[14:29] <dolanor_> but i forgot to say that it correct some FTBFS error of the original package n linux :) so it is better anyway :)
[14:30] <dolanor_> allright, I'll use +cmake then, I'm happy with that :)
[14:30] <dolanor_> i'm going now, bye
[14:31] <persia> dolanor, It's still *much* better to coordinate with upstream about it.
[14:32] <persia> dolanor, Given that box2d isn't in either Ubuntu or Debian now, your best bet is to get it into squeeze sometime in the next couple months, and that gives you enough time for upstream to complete the transition and make a proper release.
[14:35] <Laney> Miriam has started packaging box2d in SVN
[14:35] <Laney> (not read context, ignore me if you know this)
[14:52] <RainCT> If I modify the .diff.gz manually, is there some script to update the .diff.gz and .changes files accordingly?
[14:53] <geser> why would you want to modify the .diff.gz manually?
[14:53] <persia> RainCT, Just manually modify the md5sums.
[14:54] <persia> RainCT, Be *very* careful manually adjusting diff.gz: use editdiff if you are at all unsure, and don't upload the result.
[14:54] <RainCT> geser: to remove some crap from it to minimize the debdiff to the previous version, without having to touch debian/rules (as this would allso increase the diff)
[14:54] <persia> RainCT, What!  What are you doing?
[14:54] <RainCT> don't worry, it's not for Ubuntu
[14:54] <RainCT> :P
[14:55] <geser> RainCT: why not edit the debdiff?
[14:55] <persia> No, but trimming diff.gz to minimise debdiff is very rarely actually useful.
[14:55] <RainCT> right, not really sure why I'm messing with this anyway XD
[14:57] <Tamass> hi
[14:58] <RainCT> geser: (because it's not me who is going to look at the debdiff, but someone else who will create it himself)
[14:58] <RainCT> hi Tamass
[14:58] <Tamass> :)
[15:04] <RainCT> uhm.. why did  cowbuilder-hardy login --bindmounts $(pwd)  just delete everything I had in $(pwd)? -.-
[15:07] <pochu> RainCT: I hope $(pwd) wasn't ~ :(
[15:08] <RainCT> heh nope, only half an hour of work but I can redo it in 5 minutes :P
[15:27] <ia> hello. I have set of scripts, which can be installed via "./acpi-scripts.sh install" command. But I would like to make deb package for it. So, could you tell me, please, which the best way to do it? for additional info see http://pastebin.com/m6bf2f60b
[15:28] <RainCT> ia: does that script allow to specify the root dir?
[15:29] <RainCT> ia: you must tell it to install the files into $(CURDIR)/debian/<pkgname> instead of /
[15:31] <ia> RainCT: 1. looks like no. 2. yes, i've tried "$(MAKE) DESTDIR=$(CURDIR)/debian/eeepc-acpi-support install" in "install" section of "rules", but the result was the same (
[15:32] <RainCT> ia: that's for make, not for the script
[15:32] <RainCT> if it doesn't you'll have to patch the script, or do whatever it does yourself in debian/rules
[15:36] <quadrispro> nellery: about bug 329495, I've just prepared a patch :)
[15:44] <mok0> RainCT: Is it OK if I use my nick as a tag on REVU to mark the packages I am following?
[15:45]  * RainCT won't complain, mok0 
[15:45] <mok0> RainCT: perhaps there's a better way to achieve the same, though
[15:45] <RainCT> mok0: you don't want e-mail notifications, or?
[15:46] <mok0> RainCT: I am thinking of listing all the packages I'm involved in
[15:46] <RainCT> because packages to which you are subscribed are displayed in your profile..
[15:46] <mok0> ah
[15:46] <RainCT> you can also have a feed for them but then you've to modify the URL every time you want to add a new package
[15:47] <RainCT> revu.ubuntuwire.com/feeds.py?package=pkg,pkg2,pkg3  it's something like that iirc
[15:47] <RainCT> * feed.py
[15:47] <RainCT> I'll add a "Packages which I've commented:" option to the profle
[15:48] <mok0> RainCT: If you click the "mok0" tag, you can see what kind of thing I am lookign for
[15:48] <RainCT> or a filter in index.py even
[15:48] <mok0> RainCT: yes
[15:49] <RainCT> for packages where you've left a comment.. then i'd achieve the same as a tag
[15:49] <mok0> RainCT: right
[15:52] <RainCT> mok0: ok, let me eat something and then I'll get to it
[16:07] <mok0> RainCT: amazing!
[16:14] <superm1> mok0, can you look at tgm4883's other package, mythnettv? it's paired with mythnettv-gui, so i'd like to be able to upload the pair?
[16:28]  * nhandler still thinks the automatic package checks should tag the packages (i.e. bad-maintainer, missing-watch, no-bug-closed, etc)
[16:54] <mok0> superm1: will do
[16:57] <RainCT> mok0: ready, uploading now :)
[16:58] <RainCT> «WHERE sp.sid IN (SELECT sid FROM Upload WHERE upid in (SELECT upid FROM Comments WHERE usid IN (SELECT usid FROM Users WHERE nickname IN ('mok0','rainct'))))»
[16:58] <RainCT> nice, eh? :P
[17:01] <RainCT> (and yes, you can now do /tag/tag1,tag2,tag3 and ?user=user1,user2, etc.)
[17:02] <RainCT> ok, it's up
[17:03] <RainCT> mok0: http://revu.ubuntuwire.com/?user=mok0 (and you can combine it with &tag, &archived and &updated, of course)
[17:03] <nhandler> RainCT: You have no idea how much better you made my REVU life with that feature
[17:04] <mok0> RainCT: cute
[17:05] <mok0> RainCT:  I just deleted the "mok0" tags, and discovered that when you edit the tags, you get a strange string with part of an url
[17:05] <nhandler> RainCT: One more suggestion, add a message at the very top of REVU that says "Showing [archived/unarchived] [new/updated] pacakges [commented on by foo]
[17:09] <RainCT> nhandler: hehe great :)
[17:09] <RainCT> mok0: uhm.. where? that shouldn't happen
[17:09] <RainCT> oh
[17:10] <RainCT> ah, right
[17:10] <RainCT> because I linkified them
[17:11] <mok0> You see it?
[17:11] <RainCT> now I don't know how to fix this properly :(
[17:11] <mok0> I still works
[17:11] <mok0> heh, IT still works
[17:11] <RainCT> does someone know how to get the text between <a ..>HERE</a>, for serveral links, with JS?
[17:14] <Laney> innerText isn't it?
[17:15] <RainCT> Laney: perhaps, but to get it for all of them?
[17:15]  * RainCT is sad JS has no nice list comprehensions :P
[17:16] <Laney> document.getElementsByTagName('a') will give you all of the 'a' tags
[17:17] <Laney> RainCT: And you can use map on that like a good functional programmer
[17:17]  * RainCT grumbles about a   <script language="text/python"   support in Firefox :P
[17:18] <Laney> to get a list of all the innerTexts
[17:18] <Laney> https://developer.mozilla.org/En/Core_JavaScript_1.5_Reference:Objects:Array:map
[17:18]  * RainCT wonders why nobody has though of adding Python scripting support to webbrowsers before! :P :P
[18:33] <kpirc> persia, are you able to advocate the modglue package you helped me with earlier today? (provided, of course, you don't see anything else wrong with it).
[18:41] <kpirc> Is anyone here able to advocate a package for me? (modglue, on REVU) I went through the final bits of cleanup earlier today, just need a second MOTU to ok it.
[19:32] <AndrewGee> Hey all. Any MOTUs available to review my package, gpxviewer? It's an application that allows users to look at GPS traces files in GPX format. Thanks :) http://revu.ubuntuwire.com/details.py?package=gpxviewer
[19:35] <RainCT> Laney: so, how can I convert the result of document.getElementById('tags-list').getElementsByTagName('a') into an array?
[19:37]  * danielm thinks that is already an array
[19:38] <RainCT> directhex: but I save that as  var tags  and then try tags.map but that says that it doesn't have "map"
[19:44] <danielm> i'm not sure but you can try ".length" to check if there is elements on it
[19:44] <RainCT> there is
[19:44] <RainCT> I've now got around this with:   var tags = document.getElementById('tags-list').getElementsByTagName('a'); var tags = Array.prototype.map.call(tags, function(x) { return x.innerText });
[19:44] <RainCT> but the content of tags becomes just ",,"
[19:48] <RainCT> oh, now it works
[19:49] <RainCT> ah
[19:49] <RainCT> innerHTML works, innerText not
[19:50] <danielm> :)
[19:59] <ajmitch_> RainCT: javascript is an evil language to be dabbling in :)
[20:00] <ajmitch_> or maybe it's just my recent struggles with it at work that have made me annoyed with it
[20:00] <RainCT> hhehe yeah
[20:01] <RainCT> at the end I got it working with jquery.. $('#tags-list a').map(function() { return $(this).text(); }).get().join(' ');
[20:19] <tgm4883> can I get a 2nd revu on http://revu.ubuntuwire.com/p/mythnettv
[21:54] <RainCT> mok0: got something nice for you
[21:54]  * RainCT waits for LP to process his commit -.-
[21:56] <RainCT> http://revu.ubuntuwire.com/?search_name=py  :)
[21:57] <nhandler> RainCT: I still think having a search box is the way to go.
[21:57] <RainCT> nhandler: that's on my TODO ;)
[21:58] <andersk> Is there a MOTU sponsor available to review a quick fix in bug 34376? I fixed a regression introduced by the last patch.
[21:59] <andersk> I think that it can then be closed, because the original problem has been addressed.
[21:59] <nhandler> RainCT: Would the search box allow you to restrict the results in the same way as the current URL parameters do?
[21:59] <RainCT> nhandler: yep
[22:00] <RainCT> (it would not be a single box, but a form -hidden by default like the help- with inputs for the different filters)
[22:02] <nhandler> RainCT: Sounds awesome. Would it be possible to get RSS feeds for these custom lists?
[22:02] <RainCT> yeah, I'll work on that too (..somewhen :P)
[22:13] <RainCT> (Now you can also do exclusive searches based on tags, with ?exclude-tag=)
[22:13] <RainCT> this way we can ignore mono packages :D
[22:13]  * RainCT runs away from directhex 
[22:15]  * directhex chases after RainCT with a sharpened gpg signature
[22:15] <nhandler> Could we automatically tag packages based on language?
[22:17]  * directhex tags nhandler "visual basic 6"
[22:17]  * nhandler filters all non perl packages and nukes them
[22:19]  * directhex deletes nhandler's kernel
[22:19]  * RainCT helps directhex 
[22:21] <ajmitch> RainCT: so how are they tagged? :)
[22:23] <RainCT> ajmitch: above the comment box there is "Tags: [edit]"
[22:23] <RainCT> mok0: caution, games is catching up with python :P
[22:24] <ajmitch> RainCT: I'd take a look, but firefox has decided to die
[22:24] <RainCT> :(
[22:24]  * ajmitch wonders if it'd be possible to encourage the use of debtags
[22:25] <RainCT> here Firefox is stable like a rock since I'm using Flash through ndiswrapper :P
[22:25]  * ajmitch has flashblock enabled, but firefox can still hang
[22:26]  * nhandler wishes pbuilder would behave as well as Firefox does
[22:26] <ajmitch> maybe having 100+ tabs open is a bad thing
[22:27] <RainCT> and most of the times I look at a flash thingie (I also have flashblock, btw) it's greyed out (=crashed) or crashes in the middle, so I don't want to imagine how Firefox would behave without ndiswraper :P
[22:27] <RainCT> nhandler: uhm? It never crashed for me
[22:27] <RainCT> the only weird thing it did was delete a folder a while ago, but that was cowbuilder :P
[22:27] <nhandler> RainCT: It doesn't crash for me. It just refuses to create a Jaunty chroot (works fine for intrepid and sid)
[22:27] <RainCT> nhandler: are you using the script from ubuntu-dev-tools?
[22:28] <ajmitch> create an intrepid chroot & login, --save-after-login & dist-upgrade ?
[22:28] <RainCT> and do you have installed the backported <Idon'trememberwhat>
[22:28] <nhandler> RainCT: No. I have separate .pbuilderrc files for intrpeid, jaunty, and sid. I tried using pbuilder-dist with the same result. And I do have backports enabled
[23:12] <binarymutant> how do I go about asking for a debian sync request? Anyone have any links to that info?
[23:13] <directhex> requestsync
[23:13] <geser> binarymutant: https://wiki.ubuntu.com/SyncRequestProcess
[23:13] <directhex> from ubuntu-dev-tools
[23:13] <binarymutant> thanks :)
[23:17] <RainCT> good night
[23:37] <dolanor_> re
[23:37] <dolanor_> back
[23:38] <dolanor> If use box2d-2.0.1+cmake.orig.tar.gz, do i need to work under the box2d-2.0.1+cmake/ directory too ?