[00:15] <savvas> * Fri Jun  6 2008 Alexander Kahl <akahl@iconmobile.com> - 0.40.14-5
[00:15] <savvas> - disabled sid support for now, problems on ppc
[00:15] <savvas> heh, looks like fedora disabled sid for bmpx
[00:38] <TheMuso> savvas: hrm ok, I can easily try disabling sid for ppc, without your diff...
[00:39] <savvas> TheMuso: is it appropriate to disable sid for only one arch?
[00:39] <TheMuso> savvas: Well if another distro is having the same problem, I say so.
[00:39] <TheMuso> I'd say so even
[00:39] <savvas> I mean if it breaks only one arch, is it ok to disable it for that one?
[00:39] <savvas> ah ok
[00:40] <TheMuso> savvas: I think so.
[00:40] <savvas> it can be done in debian/rules I think
[00:40] <savvas> let me try, it's good for practice :)
[00:41] <TheMuso> savvas: debian/control should be enough to do it.
[00:41] <TheMuso> Unless there is code in rules to explicitly enable it.
[00:41] <savvas> there is, --enable-sid :)
[00:42] <savvas> I was thinking of checking DEB_HOST_ARCH := $(shell dpkg-architecture -qDEB_HOST_ARCH) before passing the arguments
[00:48] <TheMuso> That could work, although thats a lot of work, especially if can be done a lot more simply, but whatever works.
[00:49] <savvas> http://paste.ubuntu.com/123596/plain/
[00:49] <savvas> does this rules file look ok TheMuso ?
[00:50] <savvas> I'm not familiar with makefile variables yet
[00:51] <TheMuso> savvas: that looks ok.
[00:51] <TheMuso> savvas: and to make it even more clear that sid is disabled on powerpc, you disable dis as a build dependency on powerpc, so it doesn't get installed at build time/.
[00:53] <savvas> er.. libsidplay1-dev [!powerpc] ?
[00:54] <savvas> in debian/control I mean
[00:56] <TheMuso> savvas: correct.
[00:56] <savvas> TheMuso: will that exclude it from the ${shlibs:Depends} and ${misc:Depends} that bmpx binary package depends on?
[00:57] <TheMuso> savvas: Yes, because the library won't be in the chroot where it gets built.
[00:57] <TheMuso> And disabling sid in the config arguments will also prevent it.
[00:57] <savvas> cool, that should work then :)
[01:04] <savvas> TheMuso: here it is: http://paste.ubuntu.com/123599/
[01:04] <TheMuso> savvas: ok will test.
[01:04] <savvas> thanks :)
[01:06] <savvas> I'll go poke around a bit more with that old patch.. it was supposed to work, they used it on pld-linux: http://ftp.pld-linux.org/dists/th/PLD/SRPMS/RPMS/bmpx-0.40.14-5.src.rpm - I wonder if it actually works on a powerpc
[01:11] <TheMuso> ok
[01:13] <TheMuso> savvas: ah you have the if clause for detecting powerpc as host arch a little mixed up. THe --disable-sid and --enable-sid strings should be swapped around. I'll do that here now.
[01:15] <savvas> TheMuso: right, sorry - it's 2.15 am here :)
[01:15] <TheMuso> savvas: thats fine.
[01:15] <savvas> I'll probably be heading for bed hehe
[01:16] <TheMuso> savvas: thats fine. If this builds ok, do you want me to upload the change?
[01:17] <TheMuso> savvas: ok bmpx is now building on powerpc, as in its actually compiling.
[01:18] <savvas> great news
[01:22] <TheMuso> savvas: so do you want me to upload if this succeeds?
[01:23] <savvas> TheMuso: Can I let you know tomorrow?
[01:23] <TheMuso> savvas: sure.
[01:24] <savvas> ok, I just want to be sure about that patch - I mean, how come it builds on pld-linux?
[01:25] <TheMuso> savvas: I'll take a look in a bit, busy with something else atm.
[01:25] <savvas> TheMuso: sure, ok :)
[01:44] <savvas> hm..
[01:45] <savvas> pld-linux use autoconf and automake, whereas the debian package uses autotools-dev and this:
[01:45] <savvas> 	ln -sf /usr/share/misc/config.guess config.guess
[01:45] <savvas> 	ln -sf /usr/share/misc/config.sub config.sub
[02:00] <TheMuso> savvas: that shouldn't be a problem however. I haven't looked at it myself, so I'd need to look at everything before commenting.
[02:08] <savvas> TheMuso: alright, we'll talk tomorrow, or highlight me if you find anything - goodnight :)
[02:08] <TheMuso> savvas: sure
[05:43] <dholbach> good morning
[05:47] <fabrice_sp_> Good morning dholbach ;-)
[05:48] <dholbach> hiya fabrice_sp_
[06:27] <fabrice_sp> Hi. I've found a package that needs a fix because of a FTBFS, but it doesn't have a .orig tarball. As it's a native package, may I then change the configure file directly or should I add a patching system to the package? it's libhid.
[06:27] <ScottK> Change it directly.
[06:27] <dholbach> fabrice_sp: I guess it doesn't use a patch system, does it? :-)
[06:28] <ScottK> For a native package it doesn't make a huge amount of sense.
[06:28] <dholbach> no, it doesn't
[06:28] <ScottK> ... but /me is tired and going to bed..
[06:28] <fabrice_sp> no patch system, no
[06:28] <dholbach> but I've seen a lot of "accidental" native packages already :)
[06:29] <fabrice_sp> good night Scottk
[06:29] <dholbach> so there's nothing that surprises me anymore :)
[06:29] <dholbach> night Scott
[06:29] <fabrice_sp> it's this one: https://launchpad.net/ubuntu/+source/libhid
[06:29] <dholbach> just go ahead then
[06:30] <fabrice_sp> great! will be easier without adding a patching system :-)
[06:30] <fabrice_sp> thanks ;-)
[07:23] <Toadstool> g'morning everybody
[07:25] <dholbach> hiya Toadstool
[07:26] <Toadstool> hey dholbach!
[08:03] <didrocks> dholbach: ahem... /me hides :) (strange, as if I ran dch in my pbuilder? :/)
[08:03] <didrocks> dholbach: concerning the missing file, I am investigating, but normally I checked them
[08:04] <didrocks> (yeah, the hook is still there)
[08:07] <didrocks> dholbach: I think this issue may appears now because of the new python installer location (no more /usr/lib/python*/site-packages) and as my sponsor request is older than this change... Investigation in progress :)
[08:11] <dholbach> thanks didrocks :)
[08:34] <goshawk> hi, if someone has free time, can please review http://revu.ubuntuwire.org/p/dsss ?
[08:34] <goshawk> thx
[08:45] <Toadstool> goshawk: looks good to me but I'd rather let persia or rainCT judge since it's been a long time since I did not review packages
[08:46] <goshawk> oki thanks a lot Toadstool
[08:46] <goshawk> :)
[10:46] <slytherin> Hi friends one question. Acer Aspire 4530, AMD 64, NVIDIA 9100 M G graphics card. Which version to install? Intrepid or jaunty and i386 or amd64?
[10:56] <savvas> TheMuso: if bmpx for powerpc was built fine, please upload it. I've sent a bug report to Debian about this: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=517373
[12:06] <sistpoty|work> hi folks
[12:11] <mok0> hi sistpoty|work
[12:11] <sistpoty|work> hi mok0
[12:12] <mok0> did you get somewhere with the copyright parser?
[12:12] <mok0> sistpoty|work: ^
[12:13] <sistpoty|work> mok0: not really (as in parse a new machine readable copyright format)
[12:13] <mok0> sistpoty|work: ah ok
[12:13] <sistpoty|work> mok0: however I started writing my own tool, that can generate a copyright file from sources (given that the sources have sane license headers)
[12:14] <mok0> sistpoty|work: cool!!
[12:14] <geser> slytherin: like you want, but with an amd64 install it's easier for you to test amd64 packages (if you don't have an amd64 install already)
[12:43] <directhex> i signed a key!
[12:43]  * directhex is special
[12:44] <slytherin> geser: actually it is not a laptop for me. It is for a relative. The requirements are very generic (no voip, no DVD playing). I have never used amd64 so I was not sure if nvidia cards will work.
[12:44] <directhex> slytherin, nvidia has been fine on amd64 for about 5 years
[12:44] <slytherin> Considering that xorg is getting updated frequently in jaunty, I think I will go with intrepid.
[12:45] <savvas> is there a patch gui editor? or something that allows me to quickly filter out file patches from a diff file?
[12:45] <geser> slytherin: then use i386 as you don't need to fight with flash, acroread or other 32bit non-free software
[12:45] <slytherin> geser: acroread is not an issue. evince works fine. and flash is available for 64 bit.
[12:46] <geser> slytherin: I didn't try flash on amd64 yet. does it work reliable?
[12:47] <directhex> geser, yes, but adobe AIR sites may not work
[12:47] <sistpoty|work> savvas: I use vim for this :P (or filterdiff)
[12:47] <geser> slytherin: I had to use acroread a few months ago for a PDF. I could view the PDF with evince but not use it because of javascript
[12:48] <slytherin> geser: I have one week to test before I hand over the machine. So in worst case I will need to install ii386 before hand over.
[12:49] <geser> other than that both amd64 and i386 are good
[12:49] <slytherin> another related question. Would a single / partition for 160 GB HDD create any problem? The reason I want to have a single partition is to not limit size of home folder.
[12:50] <savvas> thanks sistpoty|work :)
[12:50] <geser> I'd probably do something like 20 GB for / (should be enough for everything) and the remaining part /home
[12:51] <geser> having /home on a separate partition makes it easier if a reinstall is needed (for whatever reason)
[12:51] <mok0> Better yet: have / on a separate disk
[12:52] <mok0> Then use rsnapshot to create a backup of your /home disk to / disk
[12:52] <slytherin> That is also fine. My /root with about 7 GB has not filled in last 3 years. So 20GB / is more than enough.
[12:52] <slytherin> I hope this experiment succeeds. :-)
[12:52] <geser> slytherin: perhaps 10 GB for / root is also ok
[12:52] <savvas> sistpoty|work: found geany :P
[12:58] <didrocks> doko: do you mean that python 2.5 will be removed in jaunty and python 2.6 will be the only release available?
[12:59] <mok0> didrocks: As I understand, 2.6 will be default, but 2.5 will still be available
[13:00] <doko> didrocks: likely not removed in time for jaunty
[13:00] <mok0> doko: There was talk of keeping 2.4 around, even
[13:00] <didrocks> doko: ok, and in a package which retreive python version in debian/rules with pyversions -vr debian/control, what do you advise?
[13:01] <mok0> Users might be using extension modules that are not part of Ubuntu
[13:01] <mok0> Esp. if they are commercial modules, it can be a pain to upgrade.
[13:01] <mok0> That
[13:01] <didrocks> mok0: yeah, of course
[13:02] <didrocks> I'm just unsure to see if I need to ship both version (cdbs seems to want to make that) or just one
[13:02] <mok0> didrocks: that said, I haven't followed what changes have happened in the API between 2.4 and 2.5
[13:03] <didrocks> mok0: don't know either :/
[13:03] <mok0> didrocks: yeah, the way all versions are packaged together makes it worth considering...
[13:03] <mok0> didrocks: now, if it were possible to separate all 2.4 and 2.5 stuff out into separate packages....
[13:05] <didrocks> mok0: yeah, it will be better...
[13:05] <didrocks> but there is a lot of issue if I support 2.5 and 2.6, for instance together
[13:05] <didrocks> site-packages/dist-packages in .install for instance
[13:05] <mok0> didrocks: sure.
[13:06] <mok0> didrocks: pycentral is nice that way
[13:06] <didrocks> (yeah, I ask for sponsoring before this change, and now, when dholbach tried, it FTBFS because of dh_install ^^)
[13:06] <mok0> didrocks: Murphey's law
[13:06] <didrocks> mok0: obviously ^^
[13:06] <didrocks> mok0: when i put 2.5 in debian/control.in, it builds against 2.5 and 2.6
[13:07] <didrocks> I think this is the behavior of pycentral but I am not familiar with it
[13:07] <mok0> didrocks: oh? Like, it builds >= 2.5 ?
[13:07] <didrocks> mok0: apparently, that's why I ask some advices, not a python packager specialist ^^
[13:08] <didrocks> XS-Python-Version: >= 2.5
[13:08] <mok0> didrocks: I think it should be able to build everything you ask for, so if you ask for >= 2.4, it should build 2.4, 2.5 & 2.6
[13:08] <didrocks> ok, and so, because of .install and site-packages/dist-packages change, it fails :)
[13:08] <didrocks> I can explicitely named what I want to copy
[13:09] <didrocks> but is it necessery? Or I just bump to 2.6...
[13:09] <mok0> didrocks: oh yes, that
[13:09] <savvas> so.. "XS-Python-Version: current" ?
[13:09] <didrocks> savvas: it will take which version, when several are available like now?
[13:09] <mok0> savvas: I think that just takes all the currently supported versions
[13:10] <savvas> didrocks: no idea, I just saw it in a package and got me puzzled as well :)
[13:10] <didrocks> :)
[13:10] <mok0> basically, current and all mean the same thing
[13:10] <doko> didrocks: if the package doesn't install (dependency on python (<< 2.6)), install pkgbinarymangler, try a local rebuild, see if it succeeds. if it's a no change rebuild, upload with a buildN release number, if you have to do local changes, upload a new version
[13:11] <doko> didrocks: no, if it says >= 2.5, it's fine and doesn't need to be changed
[13:11] <mok0> didrocks: .... and so you were hoping that 2.4 wasn't supported :-)
[13:12] <didrocks> doko: but dh_install fails because of site-packages/dist-packages changes beetween 2.5 & 2.6
[13:12] <didrocks> mok0: no, I just need 2.5 at least :p
[13:12] <didrocks> doko: so, it's better to adapt the .install for 2.5 and 2.6 cases.
[13:12] <didrocks> ?
[13:12] <mok0> doko: is the dist-packages policy valid for 2.5 too?
[13:13] <didrocks> mok0: apparently, not, dh_install yell at me :)
[13:13] <dholbach> best to discuss in #ubuntu-devel so doko hears about it too :)
[13:13] <savvas> didrocks: is there a pyversions file in the package?
[13:13] <doko> didrocks: yes, use something like usr/lib/python*/*-packages
[13:13] <doko> dholbach: ?
[13:13] <dholbach> ah, he's here as well :)
[13:13] <dholbach> doko is lurking everywhere
[13:13] <dholbach> :)
[13:13] <didrocks> doko: ok, that was my question, it's better to support both versions in install files, ok :)
[13:14] <savvas> dholbach: by the way, I've sent the patch for glife gtk-2/gnome-2 upstream :)
[13:14] <dholbach> savvas: ROCK!
[13:14] <didrocks> dholbach: as seb128, he told me this morning "congrats for your first self-sponsored package" (yeah, I mainly touch "main" GNOME packages)
[13:14] <didrocks> mok0 and doko : thanks :)
[13:14] <savvas> :)
[13:14] <didrocks> savvas: as well ^^
[13:14] <mok0> savvas: he calls you a rock
[13:15] <dholbach> I don't, really :)
[13:15] <mok0> ;-)
[13:15] <savvas> mok0: :P
[13:16] <savvas> er..
[13:16] <savvas> why is libboost1.37-doc in the libboost1.37-dev dependencies ?
[13:17] <mok0> savvas: maintainer's choise
[13:17] <mok0> should be Suggests: though
[13:18] <savvas> I know, every time I use apt-get build-dep I get that huge doc package :p
[13:18] <mok0> ha!
[13:19] <savvas> same for libboost1.35-dev
[13:19] <savvas> mok0: did you see a bug report about it?
[13:19] <mok0> savvas: you can ask yourself what the point is of splitting the docs out then
[13:19] <mok0> savvas: no
[13:19] <savvas> ok, I will
[13:19] <mok0> savvas: ROCK!
[13:20] <mok0> hehe
[13:20] <savvas> :P
[13:20] <savvas> I know I ROCK your world!
[13:20] <mok0> savvas: oh, so that's what's going on atm
[13:21] <savvas> hehe :)
[13:22] <slytherin> if a package in main has gained dependency on a package in universe what should be the approach to fix depwait?
[13:23] <didrocks> slytherin: MIR for the dependency if you can't drop it
[13:23] <slytherin> didrocks: I have never really worked on MIR. :-(
[13:23] <didrocks> slytherin: let me seek for the link
[13:24] <slytherin> calc: do you have time for doing MIR for libbcprov-java? it is build dependency of libitext-java which currently is in DEPWAIT state.
[13:26] <didrocks> slytherin: https://wiki.ubuntu.com/MainInclusionProcess
[13:26] <didrocks> dholbach: this page is hard to find, can I add MIR in the title?
[13:27] <dholbach> didrocks: maybe link it from UbuntuDevelopment/KnowledgeBase ?
[13:27] <dholbach> and a redirect from  /MIR ?
[13:30] <didrocks> dholbach: both done (not sure to know how to redirect automatically, btw for /MIR)
[13:31] <didrocks> dholbach: we don't use moins moins in ubuntu-fr :)
[13:32] <dholbach> #REDIRECT MainInclusionProcess
[13:33] <didrocks> done
[13:33] <dholbach> super
[13:53] <savvas> wow, I just managed to crach reportbug :P
[13:53] <savvas> reportbug -B debian -p libboost1.37-dev -V 1.37.0-5 -s "libboost1.37-dev: libboost1.37-doc should be in Suggests" -S wishlist --paranoid --exit-prompt
[13:54] <savvas> ah, --exit-prompt
[13:59] <savvas> wrong format, without -p and libboost1.37-dev at the end :P
[14:04] <savvas> is there a shell application that reads ini configuration files?
[14:07] <RainCT> savvas: cat $file | grep ^<sth> | cut -d'=' -f2
[14:07] <geser> . configfile  (if it's in shell syntax)
[14:08] <RainCT> geser: and let bad stuff happen ;)
[14:09] <RainCT> geser: btw, what happens if there's a "[header]"?
[14:17] <geser> hmm, looks like I overlooked the "ini" in savvas question
[14:22] <savvas> thanks :)
[14:23] <savvas> I was looking for a single command, but that works as well :P
[14:27] <AdamDH> can any one explain why this happens http://paste.ubuntu.com/123826/? the file names are the same so I have the correct .orig in my package but it still says its not there, I showed an ls -l just to show it is def there
[14:34] <RainCT> AdamDH: it's in the wrong directory
[14:35] <RainCT> AdamDH: the .orig.tar.gz must be in the parent directory, not in the source dir; so,   mv *.tar.gz ../      ;)
[14:37] <savvas> RainCT: is the email for revu fixed?
[14:38] <AdamDH> thanks RainCT
[14:38] <AdamDH> did not know that
[14:40] <savvas> AdamDH: that's a huge packaging version number :)
[14:40] <savvas> not that I'm saying it's wrong, but it's long hehe
[14:41] <RainCT> savvas: no :/
[14:41] <RainCT> but I don't know why.. it's mad :P
[14:41] <AdamDH> savvas, I know but due to the way this project is working out at the moment I am using that packaging version number and will change it later
[14:42] <savvas> RainCT: are you sure it's not faulty on the software side?
[14:43] <RainCT> savvas: No, e-mails are delivered fine if I send them manually (the same way REVU does).
[14:43]  * RainCT goes to debug a bit more
[14:43] <savvas> ah ok
[14:43] <savvas> :)
[14:45] <savvas> AdamDH: are you using get-orig-source ? Can I take a look at your debian/rules if you don't mind? (learning)
[14:45]  * RainCT hates mod_python, btw :P
[14:46]  * POX suggests mod_wsgi
[14:47] <RainCT> POX: I know, I know.. The guys in #python told me that a lot of times already ;)
[14:47] <RainCT> I just don't hate it enough yet as to switch spooky and REVU to it :P
[14:48] <savvas> you have other frameworks, http://webpy.org/ or web2py http://mdp.cti.depaul.edu/ :p
[14:51] <RainCT> savvas: OK, it doesn't like sending mail to multiple people.
[14:52] <RainCT> savvas: err, wrong. if I write two addresses of mine instead of mine and yours it works o_O
[14:52] <savvas> so.. it doesn't like me? :p
[14:53] <bddebian> Heya gang
[14:54] <RainCT> savvas: did you get mail?
[14:54] <ScottK> Heya bddebian.
[14:54] <bddebian> Hi ScottK
[14:55] <ScottK> bddebian: I ran across one of your old packages yesterday.
[14:56] <ScottK> It looks like libticables3 (or something close to that, I'm sure you'll remember) needs some adjustment due to the kernel modules it needs now being i the standard kernel and not a sepatate package.
[14:56] <ScottK> bddebian: Dunno if you still have any interest in the package, but I thought I'd mention it.
[14:58]  * RainCT restarts savvas 
[14:58] <bddebian> Eeks I'll see if I can check it out, thanks
[14:59] <ScottK> Great.
[15:01] <savvas> santiago-ve: hold a sec, checking :)
[15:01] <savvas> oops, sorry santiago-ve - I meant RainCT
[15:02] <savvas> RainCT: nope, only a debian bug confirmation I reported earlier
[15:02] <santiago-ve> savvas: no prob
[15:18] <savvas> RainCT: by the way, is the code for revu posted somewhere?
[15:18] <dholbach> savvas: lp:revu
[15:18] <savvas> nice, thanks :)
[15:19] <RainCT> (see the README for installation instructions)
[15:22] <savvas> RainCT: got Last test. too :)
[15:23] <savvas> To all the revu reviewers: Send your emails again (just kidding!) :)
[15:24] <sistpoty|work> RainCT: just saw part of the revu diff, which was s.th. like self.mailserver.sendmail()... does this use the system mta as backend?
[15:25] <RainCT> sistpoty|work: it uses smptlib, not sure how that works
[15:25] <sistpoty|work> RainCT: hm... not too sure either... I hope it uses the system mta, because iirc we've got a route via uni MTA setup from this
[15:25] <sistpoty|work> RainCT: I could check the exim log though :)
[15:26] <RainCT> sistpoty|work: William Grant mentioned they go through some other server
[15:26] <sistpoty|work> RainCT: ah... /me wonders why it's working in the first place then *g*
[15:29] <sistpoty|work> RainCT: hm...  "<= noreply@revu.ubuntuwire.com H=localhost": looks like smtplib does use the local exim :)
[15:30]  * DktrKranz is wondering how to track python2.6 rebuilds/changes for universe
[15:32] <AdamDH> seems as if my package built correctly https://launchpad.net/~adamhorden/+archive/ppa, thanks for the help guys
[15:33] <savvas> DktrKranz: you mean something like: rmadison python2.6 ?
[15:34] <AdamDH> ok maybee not
[15:34] <savvas> DktrKranz: or: aptitude changelog python2.6 ?
[15:35] <AdamDH> what dependancy is required for make: dh_testdir: Command not found?
[15:35] <dholbach> debhelper
[15:35] <dholbach> build-depends
[15:36] <DktrKranz> savvas: I mean something to easily discover which packages need love to manage python transition in time for the release.
[15:36] <DktrKranz> we have python in build-depends, depends, and nowhere.
[15:37] <savvas> ah, no idea sorry :)
[15:37] <james_w> DktrKranz: what do you need to know?
[15:37] <james_w> Arch: any packages that build-depend on python?
[15:37] <james_w> they are the ones that will need a rebuild to pick up the new python version
[15:37] <james_w> what else is there?
[15:38] <DktrKranz> james_w: a list of arch:any packages potentially affected would be nice
[15:38] <james_w> DktrKranz: a bit of grep-dctrl magic should be able to do that
[15:38] <james_w> I'll have a go in a bit
[15:48] <RainCT> james_w: are we dropping python2.5?
[15:48] <james_w> nope
[15:48] <RainCT> james_w: why/what packages are being updated then?
[15:49] <james_w> http://irclogs.ubuntu.com/2009/02/25/%23ubuntu-meeting.html
[15:49] <james_w> see around 16:20
[15:49] <RainCT> thanks
[15:49] <james_w> RainCT: arch: any packages are python-extensions
[15:49] <DktrKranz> RainCT: also see today's email
[15:49] <james_w> i.e. compiled C code against the headers of each python version
[15:49] <james_w> when you add a new python version you have to rebuild all of these packages so that they pick up the new version and build for it
[15:50] <james_w> otherwise you couldn't use the extensions under python2.6
[15:50] <RainCT> DktrKranz: I saw the mail, but couldn't get anything out of it :P
[15:51] <RainCT> ah, of course
[15:52] <RainCT> arr why did the remove string exceptions? they are great for debugging :P
[16:14] <RainCT> can someone refresh my memory about whether UI Freeze affects universe?
[16:16] <DktrKranz> RainCT: we haven't tranlations in rosetta for universe packages, so UIfreeze is not affecting universe directly, I think only CD-flavours packages (such as xubuntu) have some issues.
[16:19] <RainCT> DktrKranz: OK, thanks.
[17:23] <jdong_> mmmph.
[17:23] <jdong_> this pyrex stuff aint as intuitive as I would have hoped
[17:23] <jdong_> I take that back. This HOWTO aint as good as it seemed
[17:30]  * Laney loves a good pyrex dish
[17:30] <Laney> jdong_: Fancy poking a couple of ancient SRUs that I've had lying around for ages?
[17:32] <jdong_> Laney: I am on a crippled net connection currently, perhaps in a couple hours
[17:32] <Laney> ok
[17:32] <jdong_> feel free to link em and I will look at my scrollback
[17:34] <Laney> bug 280129 bug 243163
[17:40] <ploum_> Hello
[17:40] <ploum_> I have a python application
[17:40] <ploum_> and I want to make a .deb on a ppa out of it
[17:41] <savvas> ploum_: does it use the standard setup.py script ?
[17:43] <ploum__> Hello
[17:43] <ploum__>  I have a python application
[17:43] <ploum__>  and I want to make a .deb on a ppa out of it
[17:43] <ploum__>  the application is on launchpad
[17:43] <ploum__>  is there an howto or a specific chan where I can get help for that ?
[17:43] <savvas> 18:41:55 < savvas> ploum_: does it use the standard setup.py script ?
[17:44] <savvas> ( For future reference: It would be better if you pasted all that in one line though :) )
[17:45] <savvas> ploum__ can you reply?
[17:45] <savvas> is belgium adsl that bad? :P
[18:07] <mrooney> How might I download a Jaunty deb (from universe) in Intrepid?
[18:07] <Laney> mrooney: You can get them from LP or packages.ubuntu.com
[18:08]  * sistpoty|work heads home... cya
[18:08] <Laney> or add Jaunty to your sources.list and aptitude download foo/jaunty
[18:09] <mrooney> Laney: so I am here http://packages.ubuntu.com/jaunty/wxbanker, but I don't see where I can get the deb
[18:09] <Laney> mrooney: Click on "all"
[18:11] <mrooney> Laney: doh, thanks :)
[18:29] <AnAnt> Hello, is it possible to change a source package name ?
[18:40] <ScottK> It is.
[18:40] <ScottK> Why do you need to?
[18:40] <fatal_> AFAIK there's nothing you guys can do about this, but maybe someone could poke the right person? https://bugs.launchpad.net/ubuntu/+source/iproute/+bug/335554
[18:41] <fatal_> (reported by upstream himself)
[18:41] <fatal_> <--- debian co-maintainer
[18:42] <ahasenack> I have a package foo-1.0 with a file in /etc/cron.hourly/foo
[18:42] <ahasenack> I changed it to have the file in /etc/cron.d/foo
[18:42] <AnAnt> ScottK: the package was ubuntume-gdm-themes, but the distro got renamed to sabily, due to trademark issue, so I will have to rename the package to sabily-gdm-themes
[18:42] <ahasenack> dpkg --contents ./foo-1.0.deb shows the change
[18:42] <ahasenack> but when I upgrade it with dpkg -i, the cron.hourly file is not removed
[18:42] <ahasenack> and, omg, dpkg -L doo | grep cron now shows *both* files
[18:43] <ScottK> AnAnt: We can do that.  Just put it on REVU with the new name and ping me.
[18:43] <ahasenack> why would the installed package suddenly list a file that is not in the package?
[18:43] <AnAnt> ScottK: ok, what should I do in old changelog entries ?
[18:43] <james_w> ahasenack: file in /etc are usually "conffiles" and they are handled specially
[18:43] <fabrice_sp__> bddebian, ScottK: i made a debdiff to fix the FTBFS in libticables2 (Bug #335271)
[18:43] <ScottK> AnAnt: Leave them there, just change the name in the top one.
[18:44] <fatal_> ahasenack: files in /etc are considered configuration files... those are not removed until a package is purged.... you need to handle the upgrade case and migrate carefully.... remove the file if it's md5sum matches the one you shipped, otherwise don't install the new one in cron.d ...
[18:44] <AnAnt> ScottK: ok, thanks
[18:44] <fabrice_sp__> I noticed you spoke about that earlier
[18:44] <james_w> ahasenack: the packaging system won't remove them by itself when you remove (or upgrade the package)
[18:44] <ahasenack> james_w: so I need to explicitly remove it in some script?
[18:45] <james_w> ahasenack: http://wiki.debian.org/DpkgConffileHandling will tell you about it
[18:45] <james_w> ahasenack: yeah, that page gives you the snippet to use
[18:45] <ahasenack> james_w: thanks
[18:45] <james_w> fatal_: hey, is the package in Debian yet, or just in git?
[18:45] <james_w> argh!
[18:49] <ahasenack> james_w: I would have thought that to be part of the package manager's job software, but I'm not going to argue with several years of experience
[18:50] <ahasenack> james_w: the part about avoiding mistakes made me chuckle, though
[18:51] <james_w> ahasenack: many would agree with you
[18:51] <ScottK> bddebian: Do you want to look at the libticables2 fix or should I?
[18:52] <james_w> the fact that this is handled by copy-paste from a web-page is particularly unfortunate
[18:52] <james_w> but most people learn about this from exactly the same experience as you
[18:52] <fabrice_sp__> some packages are FTBFS because the file rgb.txt has been dropped from x11-common. Would it be ok to copy the rgb.txt file from x11-common of intrepid to add it to each package in Jaunty?
[19:00]  * sebner winks geser =)
[19:17] <bddebian> ScottK: Should we even be carrying libticables2 anymore?
[19:17] <ScottK> bddebian: You tell me?
[19:17] <ScottK> It was your package.
[19:18] <fabrice_sp> bddebian, it's still used in one app
[19:18] <ScottK> I think we should fix it or remove it.
[19:18] <ScottK> And since fabrice_sp has it fixed, that seems sensible.
[19:18] <bddebian> I thought I did the new upstream that should have used libticables3.. Hmm
[19:19] <fabrice_sp> I checked, and that's strange: tilp uses libticables3 but litp2 uses libticables2
[19:19] <fabrice_sp> and on the homepage of tilp, both version are there
[19:20] <fabrice_sp> the fix is simple: only drop the dependency, and it build and install fine
[19:20] <bddebian> Right, that was it
[19:20] <bddebian> There was a soname issue or something.  libticables2 is actually newer than libticable3
[19:20] <fabrice_sp> yes :-/
[19:21] <fabrice_sp> and the same for libticalcs2 and family
[19:21] <fabrice_sp> (litifiles, also)
[19:21] <bddebian> ScottK: Would you mind uploading the fix, I'm still without an Ubuntu machine :(  It looks sensible.
[19:21] <ScottK> Not at all.
[19:22] <ScottK> Just thought I'd give you first crack.  I remember how much 'fun' you had getting that in the archive in the first place.
[19:22] <bddebian> Heh, aye
[19:23] <ScottK> fabrice_sp: I'm looking at it now.
[19:23] <bddebian> And I see Debian still doesn't have it.. Sheesh
[19:23] <phil_ps> hello, I am trying to find the page on the wiki that shows how to setup my name for package uploads
[19:23] <fabrice_sp> ScottK, thanks!
[19:24] <phil_ps> I hosed my virtualbox installation and lost some files (including my private pgp key that I used to sign a patch I made)
[19:28] <phil_ps> okay, I found it!
[19:31] <RainCT> OT, Can somebody tell me what the CLI tool to spam myself with notifications is called? :P
[19:31] <ScottK> fabrice_sp: Uploaded.  Thank you for your contribution to Ubuntu.  BTW, I did edit debian/changelog slightly to a more preferred style.  Please have a look.
[19:31] <ScottK> bddebian: It's uploaded.  Thanks for looking at it.
[19:32] <fabrice_sp> ScottK, ok. I'll check. Thanks!
[19:32] <bddebian> ScottK: No, thank YOU and fabrice_sp :)
[19:33] <fabrice_sp> bddebian, you're welcome :-)
[19:33] <james_w> RainCT: notify-send?
[19:34] <RainCT> james_w: thanks
[19:35] <jdong_> heh. so pyrex is not magic sauce for making things magically faster.
[19:35] <fabrice_sp> so no opinion on rgb.txt?
[19:35] <RainCT> btw, anyone here running Jaunty on his normal PC?
[19:35]  * RainCT is pondering updating his system..
[19:36] <jdong_> ah. array type.
[19:36] <fabrice_sp> ScottK, I'll update 2 more patch I have to fix FTBFS to avoid the line with the LP code. Thanks!
[19:37] <ScottK> Great.
[19:37] <fabrice_sp> jdong, it has been dropped from x11-common, and I saw 2 or 3 packages that FTBFS because of that, so I was wondering if putting rgb.txt in each package to fix the FTBFS
[19:41] <onnadi3> Hi all. I hope this is the right channel. I'd like to know why xampp is not an official package even though (AFAIK) it is included in the ubuntu server install.
[19:41] <ScottK> That's not actually possible.
[19:44] <directhex> xampp is just a bundle of stuff already available in ubuntu
[19:45] <onnadi3> directhex: But I thought the value of xampp was in the lampp tool wherein 1 command starts and stops everything. Ain't that worth packaging?
[19:45] <directhex> onnadi3, is that valuable?
[19:46] <onnadi3> I think so. THen I could do "apt-get install xampp" from the cmdline :)
[19:46] <directhex> so... an init script in a metapackage?
[19:46] <phil_ps> on this page: https://wiki.ubuntu.com/Bugs/HowToFix I don't see how to make a .deb file
[19:47] <onnadi3> directhex: I'm an ubuntu packaing noob, but that sounds like it
[19:47] <phil_ps> but under testing the fixes, it says sudo dpkg -i *.deb
[19:49] <directhex> "Once you have a patch, reenter the source directory, and build the package. "
[19:50] <directhex> "debuild -us -uc"
[19:50] <jdong_> does installing the LAMP stack packages in ubuntu not already start everything automatically?
[19:51] <jdong_> the missing feature would be stopping/restarting the whole stack.
[19:51] <onnadi3> jdong_: yeah.
[19:51] <jdong_> for which I question the usecase unless it is like a personal development setup you only want to run a small subset of the time
[19:52] <jdong_> sounds to me like a 20 second bash script job :)
[19:53] <onnadi3> jdong_: I fear you are right. I guess xampp is of more value to Win/OSX where installation isn't that easy
[19:53] <jdong_> onnadi3: that is my opinion too
[19:53] <jdong_> on those platforms when not using a package manager pulling in the LAMP stack manually is quite a tedious task.
[19:53] <jdong_> on Linux IMO you can even name the entire LAMP stack in an apt-get install line without breaking a sweat :)
[19:54] <onnadi3> that's why I'm an Ubuntu :0
[19:55] <onnadi3> jdong_, directhex: Thanks for bouncing ideas with me
[19:56] <jdong_> sure thing
[19:57] <ScottK> onnadi3: sudo tasksel install lamp-server is all you need.
[20:00] <onnadi3> ScottK: I'm unfamiliar with tasksel and the manpage isn't very helpful. What does the above command do?
[20:00] <directhex> tasksel is a simple debian app to install "tasks"
[20:00] <ScottK> It will install all the packages that are defined in the lamp-server task.
[20:01] <ScottK> So that's the equivalent of picking the LAMP option at install time.
[20:03] <onnadi3> ScottK: ah. So the Ubuntu installer is just a bunch of tasks and tasksel lets you pick individual bits, huh?
[20:04] <ScottK> It's not just a bunch of tasks, but it has a bunch of tasks.
[20:04] <onnadi3> OK
[20:07] <directhex> NCommander, ping?
[20:08] <NCommander> directhex, pong
[20:09] <RainCT> | ·   |
[20:10] <NCommander> |           . |
[20:11] <directhex> NCommander, i think i found what i was looking for... want an ARM qemu image...
[20:11] <NCommander> ah
[20:11] <directhex> ports.ubuntu.com seems to be trying for "slowest server not featured on slashdot"
[20:13] <NCommander> Its on slashdot?
[20:13] <NCommander> ports.u.c. always sucks w.r.t to speed
[20:14] <directhex> and it seems ogra is the person to poke. i should stop thinking "port == NCommander" really
[20:15]  * NCommander can help with the ARM port no issue
[20:17] <directhex> NCommander, i'm attempting to help the novell people get some non-conventional arches going in qemu, for moonlight. except since there's no arm suse, i'm sanity-checking the RootfsFromScratch guide for them. which makes me giggle a bit
[20:18] <NCommander> Its probably better to run through the installation in d-i
[20:18] <directhex> where's a d-i image?
[20:19] <NCommander> directhex, http://ports.ubuntu.com/dists/jaunty/main/installer-armel/current/images/versatile/netboot/
[20:19] <NCommander> give them to QEMU with the -kernel and -initrd options
[20:19] <NCommander> (you need to -append "console=tty1 root=/dev/ram")
[20:25] <directhex> ports.u.c is in a huff with me :(
[20:25] <ScottK> You should talk nicer about it.
[20:35] <ScottK> NCommander: https://launchpad.net/ubuntu/+source/plasma-widget-toggle-compositing/0.2.3-0ubuntu2/+build/865664/+files/buildlog_ubuntu-jaunty-armel.plasma-widget-toggle-compositing_0.2.3-0ubuntu2_FAILEDTOBUILD.txt.gz looks like one of your classic armel porting issues if you care to have a look?
[20:35] <NCommander> Oooh
[20:35] <NCommander> a universe package
[20:35] <NCommander> I can get an upload
[20:36]  * NCommander hasn't uploaded anything in ages
[20:36] <ScottK> yep.
[20:41] <directhex> am i the only one who can't talk to ports.u.c? :(
[20:43] <jdong_> doesnt speak with me either on HTTP
[20:43] <directhex> it hates me. waa :'(
[20:43] <jdong_> speaks on other ports though so it is not dead
[20:43] <directhex> #canonical?
[20:43] <jdong_> canonical-sysadmin
[20:44] <NCommander> hrm
[20:44] <NCommander> damn it
[20:44] <NCommander> ports.u.c. is down
[20:45] <directhex> not just me then
[20:45] <directhex> bears, i suspect
[20:45] <jdong_> black bear
[20:46] <AnAnt> ScottK: regarding my previous question about source package renaming, should I add Replaces: <old package name> in debian/control ?
[20:47] <AnAnt> ScottK: I mean for the target (binary) package
[20:47] <ScottK> Yes.
[20:47] <ScottK> It's a little more complex than that though.
[20:48] <AnAnt> how so ?
[20:48] <directhex> NCommander, <elmo> it's got hardware issues atm
[20:49] <AnAnt> ScottK: what do you mean by more complex ?
[20:49] <ScottK> AnAnt: You need to provide the old package name as a transitional package for upgrades.
[20:49] <ScottK> AnAnt: https://launchpad.net/ubuntu/jaunty/+source/plasma-widget-toggle-compositing/0.2.3-0ubuntu2/+files/plasma-widget-toggle-compositing_0.2.3-0ubuntu2.diff.gz is a good example.
[20:49] <NCommander> Oh
[20:49] <NCommander> Ugh
[20:49] <NCommander> -_-;
[20:50] <AnAnt> ScottK: Provides: <old package name> ?
[20:50] <AnAnt> oh
[20:50] <ScottK> Look at the example.
[20:50] <ScottK> The old package needs to exist and depend on the new one so the new one will get installed.
[20:50] <AnAnt> I see
[20:50] <ScottK> Note: You don't always need the conflicts.  That's only if they actually conflict.
[20:51] <directhex> NCommander, <elmo> directhex: hey, it's 9pm and I'm in the office ,working on it :-P
[20:51] <AnAnt> yes, I'm not using conflicts indeed
[20:51] <fabrice_sp> Hi again. ia32-libs-tools FTBFS according to qa.ubuntuwire.com/ftbfs, but it's building successfully in an amd64 schroot here. So what can I do?
[20:51] <AnAnt> ScottK: thanks a lot
[20:51] <ScottK> AnAnt: You're welcome.
[20:52] <directhex> fabrice_sp, try pbuilder
[20:52]  * NCommander will buy Elmo a beer next time I see him
[20:53] <fabrice_sp> directhex, will try, but I'm already using sbuild to build it
[20:53] <fabrice_sp> so should be the same
[20:53] <directhex> fabrice_sp, what does the build log show?
[20:53] <RainCT> persia: btw, you are right about showing the license at the bottom if it's repeated multiple times in debian/copyright with the new format
[20:54] <fabrice_sp> directhex, http://pastebin.com/d2012d41f
[20:55] <fabrice_sp> it's building fine also in pbuilder
[20:55] <directhex> fabrice_sp, no binary-arch rule?
[20:56] <fabrice_sp> in this case, it would fail also in sbuild and pbuilder, right?
[20:57] <fabrice_sp> binary-arch:
[20:57] <fabrice_sp> # We have nothing to do.
[20:57] <fabrice_sp> it's there, in debian/rules
[20:57] <fabrice_sp> (with nothing to do)
[20:58] <fabrice_sp> the build is 2 month old. Is it possible to force a rebuild of ia32-libs-tools?
[21:00] <fabrice_sp> anyway, as it has never been built, when successfully build, it will go to the NEW queue. so is it compatible with FF?
[21:00] <fabrice_sp> or it needs a FFE?
[21:03] <c_korn> why is this bug still undecided although someone ACKed it? https://bugs.launchpad.net/ubuntu/+source/scilab/+bug/334362
[21:07] <ploum> Hello
[21:07] <RainCT> hi ploum
[21:07] <ploum> Hi RainCT
[21:07] <ploum> I was there to ask a question a few hours ago but my wireless router decided to die at that moment
[21:07] <phil_ps> what is the launch pad pgp keyserver?
[21:07] <tdomhan> anyone got some time to review a package(http://revu.ubuntuwire.com/p/gpicsync)? :D
[21:08] <ploum> sorry to the one who was answering me
[21:08] <ploum> so here's my question
[21:08] <ploum> I've a full python application in a bzr repository on launchpad and I want to make a deb on a ppa out of it
[21:09] <ploum> and I've no experience with building python deb files or ppa
[21:09] <ploum> can anyone help me ?
[21:09] <ploum> or give me some pointers ?
[21:13] <ploum> argh
[21:13] <ploum> there was someone replying me a few hours ago
[21:13] <ploum> damn wireless router
[21:15] <ScottK> We do Ubuntu here.  Launchpad does PPAs.  If you were interested in getting your package into Ubuntu more people might be interested in helping.  There is also #launchpad for PPA questions.
[21:17] <ploum> ScottK : thanks
[21:17] <ploum> I'm also interested in getting my package in Ubuntu, of course
[21:17] <ploum> but ppa is the first step I guess
[21:19] <onnadi3> ploum: this what you're looking for? https://wiki.ubuntu.com/PackagingGuide/Complete
[21:21] <RainCT> Will the menu be happy if I put a 64x64 PNG into /usr/share/pixmaps instead of a 48x48 one?
[21:22] <RainCT> (as in, would that be acceptable?)
[21:28] <ploum> onnadi3: thanks, will take a look at that
[21:38] <ploum> onnadi3: hmm, it's what I was fearing. It explains all about making packages for C programs. But for python, it should be different I guess
[21:42] <RainCT> ploum: the debian/rules file will be a bit different, but most of the documentation applies for any sort of package
[21:42] <onnadi3> FYI, I'm a packaging noob, but it seems like the instructions aren't C-specific; they just seem to need make is all. What part wouldn't work for Pythong?
[21:43] <RainCT> onnadi3: see http://wiki.debian.org/DebianPython/NewPolicy for what's required for Python
[21:43] <RainCT> basically you have to get the files to install into the correct place (with distutils, make, dh_install or whatever) and then call either dh_pysupport or dh_pycentral (and add some stuff to debian/control) to get byte-compilation support
[21:46] <onnadi3> RainCT: I see. Could you please explain why C/Python get special instructions and other languages like Ruby/Haskell don't?
[21:47] <RainCT> onnadi3: Ruby has no byte-compilation (afaik) or any other special need, so for Ruby applications it's enough to just throw them into a directory
[21:49] <onnadi3> thanks
[21:50] <RainCT> You're welcome. Ask if you have any other question :)
[21:52] <ploum> thanks RainCT
[22:10] <ianto> Hello; I'm having  some issues regarding my rules fiile in the package that I'm building, here is the current version of it: http://revu.ubuntuwire.com/p/star-merchant
[22:11] <ianto> any help would be much appreciated ^ :D
[22:12] <RainCT> ianto: what's the problem?
[22:13] <ianto> RainCT: /bin/sh: mkdir -p /tmp/buildd/star-merchant-1.1/debian/star-merchant/usr/bin: not found
[22:13] <ianto> I believe my rules is messed up
[22:13] <RainCT> (btw, you can remove all the commented out stuff, especially lines 3-7, #docbook-to.. and the commented out dh_ calls)
[22:13] <RainCT> incorrect: remove the quotes around that line
[22:14] <RainCT> err, sorry, ianto
[22:14] <incorrect> i haven't said anything
[22:14] <rgreening> ScottK: ping
[22:14] <RainCT> incorrect: sorry, that was for ianto (nice name, btw :P)
[22:15] <incorrect> openldap 2.4.15 was nice and easy to package and compile on hardy
[22:15] <ianto> RainCT: Thanks for the tip I'm gonna pbuilder build it now :)
[22:15] <rgreening> ScottK: I'm doing up my application for motu, and was hoping to apply during (possibly) the next meeting.
[22:17] <rgreening> JontheEchidna: ^
[22:17] <rgreening> NCommander: hey
[22:17] <JontheEchidna> Oh, I need to put my feedback on your application soon
[22:17] <NCommander> hey rgreening
[22:18] <rgreening> JontheEchidna: yeah, my app is being written (hopefuly finish tonight).
[22:19] <rgreening> JontheEchidna: Here's where it will be : https://wiki.ubuntu.com/rgreening/DeveloperApplicationMOTU
[22:19] <rgreening> not finished yet.
[22:19] <rgreening> NCommander: when I get my app done, wouldn't mind your comments too.
[22:20] <NCommander> sure
[22:20] <rgreening> ty NCommander :)
[22:20] <ianto> RainCT: Removing the quotes results in the following error: http://paste.ubuntu.com/124032/
[22:21] <rgreening> building kde takes so long... :)
[22:28] <RainCT> ianto: where does that "cp" come from?
[22:29] <RainCT> ah
[22:29] <ianto> RainCT: hyperair recommended it to me because it relied on the directory to bbuild
[22:30] <RainCT> cp $(OUTFILE) /usr/bin/$(OUTFILE)
[22:31] <RainCT> not sure.. try removign the $(OUTFILE) from the end
[22:39]  * ianto is kinda confused as to where to place that RainCT 
[22:40] <directhex> aw, i ran out of teh rams
[22:40] <AdamDH> hi all, hit some snags with my package, took a look at some other packages and they have no .orig.tar.gz in the package? the source is all ready extracted, why is this?
[22:49] <AdamDH> grr cannot get my package to build on launchpad works fine when built locally
[22:50] <RainCT> (Any DD around who is free to sponsor a package update?)
[22:52] <RainCT> ianto: Sorry, I was away. In the Makefile there's that line - try changing it to "cp $(OUTFILE) /usr/bin/"
[22:52] <jelmer> RainCT, For which package?
[22:52] <RainCT> jelmer: screenruler
[22:53] <jelmer> RainCT, sorry, not familiar with ruby :-/
[22:54] <sistpoty> jelmer: I'd have another one then: min12xxw (plain c) :P
[22:55] <directhex> it's a jelmer!
[22:55] <RainCT> jelmer: I also have another (new) C package for which I need a sponsor :P
[22:56] <sistpoty> damn RainCT *g*
[22:56] <jelmer> directhex: dude!
[22:56] <RainCT> :)
[22:56] <directhex> my favourite @samba.org!
[22:57] <jelmer> sistpoty: That one should be doable :-)
[22:57] <jelmer> sistpoty, please upload to mentors.debian.net and email/privmsg me the link
[22:57] <sistpoty> jelmer: sure, (I'll just need to find it myself... it's somewhere in collab-maint/ext-main) *g*
[22:57] <sistpoty> +t
[22:58] <ianto> RainCT: Same error without that in the makefile
[22:59] <ianto> cp starmerch /tmp/buildd/star-merchant-1.1/debian/star-merchant/usr/bin
[22:59] <ianto> cp: cannot create regular file `/tmp/buildd/star-merchant-1.1/debian/star-merchant/usr/bin': No such file or directory
[22:59] <RainCT> ianto: uhm.. I don't know then :)
[22:59] <RainCT> jelmer: and mine? *g*
[22:59] <Laney> directhex: do you have a list of the 1.0 libs (i.e. most important to be transitioned) handy?
[23:00] <directhex> Laney, the install cd libs are all done, so afaik there's no priority list
[23:00] <ianto> RainCT: Meh jpds said that it'd be easy and volunteered me for it :p -- I've been stuck for a a fortnight :(
[23:00] <Laney> well the ones which are going to ftbfs
[23:00] <directhex> Laney, pick whatever's red on http://wiki.debian.org/Teams/DebianMonoGroup/Mono20TransitionTODO
[23:00] <Laney> should be done first right
[23:00] <jelmer> RainCT: sorry, I don't have enough time for a new package right now
[23:01] <directhex> Laney, remember that the pkg-cli-libs ones can be uploaded to debian straight away, sans ubuntu1
[23:01] <RainCT> well, I guess I'll get a chance to try how effective mentoris.debian.net is then :P
[23:02] <Laney> directhex: for sure, I'm just trying to prioritise
[23:02] <jelmer> RainCT, just out of curiosity, what's the package?
[23:03] <RainCT> jelmer: vilistextum (a HTML to text converter)
[23:03] <Laney> directhex: Also lamalex in #gnome-do is moaning about md in Jaunty
[23:05] <directhex> Laney, what about it? o_o
[23:05] <Laney> 27/02 22:52:29 <lamalex> it is buggier than from source
[23:05] <Laney> 27/02 22:52:42 <lamalex> I think it's packaging fails, not a problem with upstream
[23:05] <directhex> we barely patch it
[23:06] <directhex> real actual bugs, file against debian
[23:06] <Laney> dunno what his problem is
[23:06] <Laney> I told him to come see you or file bugs
[23:13] <AdamDH> whats the best way to build a source package?
[23:14] <AdamDH> debuild -S
[23:14] <AdamDH> ?
[23:14] <Laney> yep
[23:14] <AdamDH> in the root with the debian folder etc?
[23:15] <RainCT> AdamDH: Yes. If it's a new package or a new version, you'll also need  -sa
[23:15] <RainCT> (to include the .orig.tar.gz in the .dsc)
[23:16] <AdamDH> thanks RainCT, the problem I have is the way I have versioned my package its causing me some headaches, as I am unsure about the upstream source tarball
[23:22] <AdamDH> the .orig.tar.gz is the actual upstream source and this is kept outside the root of the package?
[23:37] <RainCT> uhm.. I should have a look at fsniper, perhaps we can use it to have REVU immediatelly process uploads
[23:47] <RainCT> well, good night :)
[23:47] <Laney> night
[23:48] <directhex> is it? :o
[23:48] <RainCT> directhex: it's always night :)
[23:49] <RainCT> .. and always day ^^