[00:53] <ScottK> bddebian: If it's bug fix only, no FFe is needed.
[01:21] <andersk> Can someone sponsor the one-line patch in bug 336436?
[01:27] <ScottK> andersk: lsb in Main, so you need to look in #ubuntu-devel and subscribe ubuntu-main-sponsors.
[01:41] <theholyduck> argh.. i cant for the life of me figure out why this source package wont compile normaly
[03:32] <swegner1> Is there documentation somewhere for the workflow of creating a new package with source files and the debian/ directory in seperate bzr repositories (probably using bzr-builddeb) ?
[03:39] <ScottK> I'm sure there is, but it may take some patience as that's not really the standard work flow most people use here.
[03:40] <swegner1> ScottK: hmm, gotcha.  Well actually I'm just starting a new project and thought that might be a good organization for it.  Is there a better way?
[05:26] <lidaobing> hello, I did not know the python 2.6 transition until today
[05:26] <lidaobing> did I miss some maillist?
[05:26] <lidaobing> thanks
[06:01] <Hobbsee> lidaobing: yes, iirc - about three of them.
[06:01] <lidaobing> Hobbsee, which one?
[06:01] <Hobbsee> lidaobing: it got posted to ubuntu-devel-announce, ubuntu-devel, and probably -discuss as well, i think
[06:01] <lidaobing> Hobbsee, thanks
[07:08] <didrocks> morning
[07:16] <ttx> morning
[08:36] <Toadstool> g'morning!
[09:39] <Handrix> morning
[10:27] <directhex> james_w, ta for all your mono lib transition bugs
[10:27] <james_w> np
[11:06] <c_korn> hello
[11:06] <c_korn> finally jeuclid made it into jaunty
[11:06] <c_korn> can someone push scilab in?
[11:06] <c_korn> https://bugs.launchpad.net/ubuntu/+source/scilab/+bug/272264
[11:06] <c_korn> all build-dependencies are now in jaunty
[11:26] <c_korn> mok0: hello
[11:26] <c_korn> jeuclid made it into jaunty
[11:26] <mok0> c_korn: hi
[11:26] <c_korn> ubuntu 334767
[11:26] <mok0> c_korn: great. I will upload scilab then
[11:26] <c_korn> ok, thank you
[11:27] <mok0> c_korn: I think all the dependents are there
[11:27] <mok0> c_korn: dependencies, rather
[11:27] <c_korn> yes, they are
[11:27] <c_korn> after scilab is in there is sivp missing which requires scilab >=5 to compile
[11:27] <mok0> c_korn: right
[11:28] <mok0> c_korn: we have FFE's for everything so I prefer to upload serially
[11:28] <c_korn> ok
[11:32] <Handrix> hello
[11:32] <Handrix> when i try to build a package
[11:32] <Handrix> it ask me for a Maintainer
[11:33] <Handrix> i run debuild -S
[11:34] <Handrix> can anyone help me on this
[11:35] <directhex> your debian/control should have a Maintainer line
[11:36] <Handrix> yes
[11:37] <Handrix> and it has to contain an @ubuntu.com
[11:37] <Handrix> right ?
[11:44] <directhex> ubuntu packages should be set to Maintainer: Ubuntu MOTU Developers <ubuntu-motu@lists.ubuntu.com>
[11:46] <Toadstool> Handrix: https://lists.ubuntu.com/archives/ubuntu-devel-announce/2007-January/000235.html explains what to do with the Maintainer field
[11:51] <directhex> if a lib package has no rdeps, is it worth keeping in the archive?
[11:52] <geser> which lib is it?
[11:52] <Handrix> libdev-db
[11:52] <directhex> geser, libtapioca-cil
[11:52] <Handrix> sorry libdb-dev
[11:53] <Handrix> thanks Toadstool
[11:53] <Handrix> can you tell me where can i report a needs packaing bug
[11:53] <james_w> directhex: but I just fixed that!
[11:53] <directhex> james_w, i know. i'm casting a critical eye at divergences
[11:54] <directhex> james_w, e.g. autopano-sift being heavily patent-encumbered
[11:54] <directhex> (hence not in debian)
[11:54] <james_w> but yeah, if it would have been any harder to fix I might have asked to have it removed instead
[11:56] <geser> directhex: if it's not needed anymore IMHO it should be removed as we probably won't maintain it much in the future
[11:57] <directhex> geser, seems to be bindings to a lib used only by a dead app
[11:58] <geser> then request a removal, we don't need cruft in the archive (I guess we already have too much)
[11:58] <directhex> sorry james_w!
[11:59] <directhex> geser, is there an easy "requestsync" equiv for RM?
[11:59] <geser> no
[12:03] <directhex> cc ubuntu-archive?
[12:05] <james_w> u-u-s
[12:06] <EagleScreen> I cannot unsuscribe or edot my preferences in motu mail list
[12:06] <EagleScreen> i cannot log in and I never receibe the confirmation e-mail
[12:10] <EagleScreen> but my address is in the list, everyday I receibe docens of mails
[12:11] <pochu> soren, nixternal ^
[12:11] <pochu> (you are listed as administrators in lists.ubuntu.com)
[12:14] <EagleScreen> am I an administrator of the list? i cannot understand why
[12:21] <pochu> EagleScreen: not you, but soren and nixternal :)
[12:21] <pochu> they may be able to help you
[12:21] <pochu> EagleScreen: do you want to be removed from the list or?
[12:36] <EagleScreen> yes becouse I cannot atend that amount of mails
[12:36] <EagleScreen> I think I have to be removed and may be create another mail address only for motu usage
[12:44] <savvas> dh_clean
[12:44] <savvas> You must specify a valid JAVA_HOME or JAVACMD!
[12:44] <savvas> make: *** [ant-sanity-check] Error 1
[12:44] <savvas> what does this mean?
[12:44] <pschulz01> What verion format should I use for 'changelog' in PPA uploads?
[12:44] <sistpoty|work> savvas: do you have build-depends installed?
[12:45] <savvas> ah wait, found it sistpoty|work, wrong JAVA_HOME in debian/rules :)
[12:45] <sistpoty|work> even better .)
[12:45] <sistpoty|work> :)
[12:46] <savvas> debian seems to use "JAVA_HOME            := /usr/lib/jvm/java-gcj"
[12:47] <savvas> hm.. package java-gcj-compat-headless should be in build-depends
[12:53] <savvas> last change: actually debian's source bcel build-depends should use default-jdk :P
[12:53] <savvas> much better hehe
[13:19] <bddebian> sistpoty|work, ScottK: Thanks.  Do I just turn that bug into a sync request or file a seperate bug for the sync and point at that one for approval?
[13:20] <geser> bddebian: apply kiss and reuse the bug
[13:21] <bddebian> *smack*
[13:21] <bddebian> Hi geser :)
[13:21] <geser> Hi bddebian :)
[13:43] <geser> huats: Hi, what's your plan for the sync request of pywebkitgtk?
[13:44] <huats> hey geser
[13:44] <huats> sorry not not replying yet
[13:44] <huats> I have seen your comment
[13:44] <huats> )
[13:44] <huats> :)
[13:45] <huats> geser: I would rather have a sync
[13:45] <huats> BUT
[13:45] <huats> so I can make the changes that are applyable for debian (since I am the maintener)
[13:46] <huats> geser: let me some time (say 1h) so that I can tackle a few stuffs and have a better view ok ?
[13:47] <huats> I was sick for a few days, and away from my computer so I have lots of stuffs to check :)
[13:48] <geser> huats: sure, as I know now that you will take care of it, you can take even more time if you need
[13:48] <huats> :)
[13:48] <huats> thanks for raising the question anyway :)
[13:48] <savvas> does anyone know how to re-create the folders in /var/spool/postfix/public/ ?
[13:51] <savvas> nvm, wrong channel :p
[13:53] <theholyduck> ;O this is pretty amusing
[13:53] <theholyduck> i created a post in multimedia&video. 30 minutes ago. and nobody has even VIEWED it :P
[13:53] <theholyduck> on the ubuntu forums
[13:55] <directhex> theholyduck, try making a post about how great arch linux is, if you want responses
[13:56] <theholyduck> directhex, but arch sucks even more than ubuntu
[13:56] <theholyduck> wich quite frankly is quite an archivement
[14:02] <savvas> damn sendmail-bin, the process wasn't killed
[14:03]  * theholyduck licks directhex http://ubuntuforums.org/showthread.php?t=1084588 gief me a read :P
[14:04] <theholyduck> actually i got a couple now. but no replies yet :P
[14:04] <savvas> theholyduck: I use debian-multimedia :P
[14:05] <theholyduck> i wouldnt trust it directly in ubuntu
[14:05] <theholyduck> without causing alot of breakages
[14:05] <theholyduck> pluss its not perfect
[14:05] <theholyduck> im just basing it on that currently
[14:05] <theholyduck> it still doesnt have good enough mplayer pacakges
[14:05] <theholyduck> and good enough variety of them
[14:06] <theholyduck> i just needed to get my head aroudn packaging that fits in ubuntu.  and a debian dir that works for creating ffmpeg :P
[14:06] <theholyduck> since fffmpeg wants to be like 80 bazzillion .debs in ubuntu
[14:07] <directhex> why not work with siretart instead of against him?
[14:08] <theholyduck> because you cant do a full ffmpeg up date in the middle of the 6 month cycle :P
[14:08] <theholyduck> where as my solution will eventually update every other day or so
[14:08] <theholyduck> it would cause too much potential breakages in releases. thus it will never be accepted
[14:08] <theholyduck> and i went for the. make my own solution
[14:09] <directhex> and you don't think siretart would have any insight on uninvasive ways to do things like package naming or automation?
[14:10] <theholyduck> well my current sollution seems to work:P
[14:10] <theholyduck> atleast partially :P
[14:10] <theholyduck> figuring it out yourself is half the fun
[14:10] <savvas> I'll have to agree on that :)
[14:10] <theholyduck> though admitedtly. if siretart want to make a constantly updated media repo. i'd be the first to join in
[14:11] <theholyduck> *wanted
[14:11] <theholyduck> he probaly has way more experience than me in packaging
[14:13] <savvas> medibuntu isn't updated anymore?
[14:14] <savvas> ah wait, there's no ffmpeg in medibuntu
[14:14] <theholyduck> among other things :P
[14:15] <theholyduck> their mplayer doesnt seem to be built from svn aswell
[14:15] <savvas> correction, there's no ffmpeg for jaunty in medibuntu :P
[14:15] <theholyduck> savvas, or intrepid
[14:15] <savvas> theholyduck: I know, they said that they follow ubuntu
[14:15] <theholyduck> savvas, and their 8.04 ffmpeg is from 2007 b:P
[14:15] <theholyduck> wich is like dinosaur levels
[14:17] <savvas> theholyduck: you could make a team for it, ubuntu-media-edge :)
[14:17] <theholyduck> savvas, well i could. but i dont have enough confidence in my packaging to start a actual team :P
[14:17] <theholyduck> not to mention the fact that i pretty much refuse to use ubuntu :P
[14:17] <savvas> (boo!!! :p)
[14:18] <theholyduck> savvas, im just here to fix it to make my life easier
[14:18] <theholyduck> i dont personally wanna use it
[14:18] <theholyduck> though admitedtly i managed to bork my 2 and a half year old debian sid install. and installed ubuntu 8.10 the other day
[14:19] <siretart> theholyduck: well, there is the motumedia PPA. or you could use your personal ppa
[14:20] <theholyduck> siretart, motumedia is still pretty damn outdated :P
[14:21] <theholyduck> ffmpeg from early 2008. x264 from late 2009
[14:21] <theholyduck> err
[14:21] <theholyduck> late 2007
[14:21] <siretart> upload new packages in your ppa and I can copy them over
[14:21] <mok0> theholyduck: oh, I thought you were from teh future
[14:22] <theholyduck> siretart, https://launchpad.net/~m-frydenlund/+archive/ppa
[14:22] <theholyduck> these work here :P
[14:22] <theholyduck> ffmpeg, x264, faac, xvid core :P
[14:23] <savvas> we have a motumedia? cool!
[14:23] <siretart> oh, nice. even with these unredistributable amr packages:/
[14:23] <theholyduck> siretart, :P
[14:24] <theholyduck> well medibuntu distrebuted them :P and i figured it wouldnt hurt too bad
[14:24] <theholyduck> but making ffmpeg not use them is pretty easy
[14:24] <theholyduck> id need to reup it thoguh
[14:24] <theholyduck> though you know that :D
[14:24] <siretart> medibuntu doesn't seem to care too much about licenses and legal problems. last time I looked they even had libdvdcss in their repos
[14:25] <directhex> siretart, if a package is known to violate a protected patent, is that grounds for an RM request?
[14:25] <mok0> directhex: you wanna remove mono :-P
[14:25] <theholyduck> though a ubuntu-media-edge team wouldnt be the worst idea ever
[14:25] <broonie> directhex: Arguably that applies to the kernel now.
[14:26] <directhex> mok0, mono has no "known" violations, the package in question even names the owner in LICENSE
[14:26] <siretart> anyways, it seems that you updated x264 from marillat. I'll make a note to review your update and upload it to motumeida this night
[14:26] <directhex> broonie, FAT32 4 evar!
[14:26] <siretart> directhex: only if you have evidence that the patent is actively enforced
[14:26] <savvas> so.. what happens if someone sues medibuntu?
[14:27] <siretart> theholyduck: do you have some mechanism to update the packages automatically or do you rely on marillat to update them?
[14:27] <theholyduck> siretart, well currently i just got it directly off debian-multimedia and modified some debs :p
[14:27] <mok0> directhex: Patent violations are only such if a case is made in court (AFAIK)
[14:27] <directhex> savvas, they die
[14:27] <theholyduck> siretart, i will eventually
[14:27] <savvas> ouch
[14:27] <theholyduck> im working on that part :P
[14:27] <siretart> theholyduck: tell me if you have something, I'll happily review it
[14:27] <theholyduck> siretart, hehe :)
[14:29] <theholyduck> siretart, anyways thats the hope. a relativly automated system that lets me maintain ubuntu media packages
[14:30] <theholyduck> without having to do much work myself
[14:30] <siretart> ah, it seems you have found the main problem in maintaining packages..
[14:31] <theholyduck> siretart, indeed :P
[14:31] <theholyduck> maintaining them :D
[14:31] <savvas> the "sanity check" problem heh
[14:31] <theholyduck> the problem with ffmpeg is that they have a tendency to change things randomly :P
[14:31] <theholyduck> so i need ot make it fairly modular and easy to fix again
[14:32] <siretart> did you have a look at debian/README.upstream-upgrade?
[14:33] <theholyduck> did not :P
[14:34] <siretart> check out the ffmpeg branch  at git.debian.org
[14:36] <sistpoty|work> thanks for the upload, siretart :)
[14:37] <theholyduck> siretart, intresting :P
[14:39] <theholyduck> siretart, also its "Only" 1 month outdated
[14:39] <theholyduck> on sid :P
[14:39] <theholyduck> wich quite frankly isnt BAD :P
[14:39] <theholyduck> when you consider the shit most distros package
[14:41] <theholyduck> but it will have to wait. im pretty damn tired currently. i spent all nite trying to make ppa stop being stupid :P
[14:41] <siretart> I'm considering another update in the next days, tbh
[14:41] <theholyduck> or rather makinig myself package correctly
[14:42] <mok0> What's up with MoM? She ain't working
[14:44] <savvas> and DaD was sued and gave the children to MoM :p
[14:44] <mok0> DaD simply left the family
[14:44] <savvas> (just kidding:))
[14:46] <savvas> can someone issue a rebuild on aptoncd?
[14:47] <savvas> I think it doesn't require any changes for the python transition
[14:48] <maxb> ooi, has anyone made a "still needs transition" tracker?
[14:49] <savvas> hm..
[14:50] <savvas> maxb: find me a name :)
[14:50] <maxb> name for what?
[14:50] <savvas> I'll start a wiki article
[14:51] <savvas> well, with all the packages: grep-available -F Depends "python (<< 2.6)"|grep ^Package
[14:51]  * maxb notes that grep-dctrl can take an -sPackage flag
[14:53]  * POX points savvas to '-s' option
[14:53]  * maxb also suggests grep-aptavail, lest you be relying on a potential out of date dpkg-available db
[14:53] <POX> maxb: oh, didn't see your msg :)
[14:53] <geser> savvas: looking at aptoncd
[14:53] <maxb> and I guess a tracker is hardly required, given it's only one command away. Didn't stop to think it would be *quite* that trivial :-)
[14:54] <savvas> geser: thanks :) It was built successfully, but I didn't keep the package unfortunately - let me find the link to the log
[14:55] <savvas> 21:17:03< savvas> aptoncd builds fine - just needs a rebuild: http://launchpadlibrarian.net/23268539/buildlog_ubuntu-jaunty-i386.aptoncd_0.1.98-0ubuntu4~ppajaunty1_FULLYBUILT.txt.gz
[14:55] <savvas> geser: ^
[14:55] <geser> savvas: no need to search for as I always test build before I sponsor something
[14:55] <savvas> oki doki
[14:56] <savvas> maxb: a tracker could be useful, given that some packages wait for approval
[14:56] <geser> savvas: aptoncd isn't a simply rebuild (look at the package contents)
[14:57] <savvas> geser: ok, I'll check it once more :\
[14:58] <geser> savvas: I've done the needed changes already
[14:58] <mok0> geser: yeah it doesn't rebuild as-it, you have to add --install-layout=deb
[14:58] <geser> mok0: I know
[14:59] <mok0> geser: sorry
[14:59] <geser> savvas: the problem are the files in /usr/local mentioned in your PPA build log
[15:00] <mok0> geser: is there only 1 supported python version in jaunty?
[15:00] <savvas> geser: they ought to contain python2.5 as well?
[15:01] <mok0> only 2.6 modules are built
[15:01] <geser> mok0: pyversions -s => python2.5 python2.6
[15:01] <mok0> geser: hm
[15:02] <geser> aptoncd doesn't loop over the supported python versions during build but only uses the default version
[15:02] <mok0> geser: yes
[15:02] <mok0> geser: the source package has some lintian warnings too
[15:03] <geser> it would perhaps be good to use python-(shared|central)
[15:04] <savvas> oooh I get it, /usr/lib instead of /usr/local/lib ?
[15:04] <geser> savvas: yes
[15:04] <mok0> savvas: the default of setup.py has been changed to install in /usr/local
[15:05] <savvas> so that's why you suggested --install-layout=deb above, I see
[15:06] <mok0> savvas: yes
[15:06] <savvas> mok0: when was this changed?
[15:06] <mok0> savvas: with python 2.6
[15:06] <savvas> good to know :P
[15:06] <savvas> thanks :)
[15:07] <mok0> savvas: It's a feature provided by Python authors so distros can install in a separate tree
[15:08] <james_w> it's a feature added in the Ubuntu packages
[15:08] <mok0> james_w: oh? I thought it was upstream
[15:08] <james_w> I don't think so
[15:09] <mok0> james_w: ok
[15:09] <mok0> james_w: perhaps it's correct to say that it is prompted by upstream then?
[15:10] <james_w> I'm not sure
[15:10] <mok0> james_w: I think b/c Debian/Ubuntu's way of doing things interferes with theirs
[15:10] <james_w> http://www.mail-archive.com/debian-devel@lists.debian.org/msg268410.html
[15:11] <mok0> james_w: yeah I read it, but found it hard to understand :-)
[15:11] <mok0> james_w: all the talk of /usr/local was confusing
[15:18] <mok0> Hi RainCT
[15:19] <mok0> RainCT: did you kill off MoM?
[15:19] <lidaobing> hello, who can help check bug 335796, thanks
[15:20] <RainCT> Hi mok0
[15:20] <RainCT> mok0: No, I don't even have access to it.
[15:20] <mok0> RainCT: Oh :-P
[15:21]  * RainCT mentions this in #canonical-sysadmin
[15:25] <RainCT> mok0: they're on it
[15:26] <mok0> RainCT: many thanks!
[15:26] <RainCT> np
[15:27] <mok0> Jeez, this python build scared the sh*t out of me...
[15:32] <sistpoty|work> lidaobing: I'll take a look at qterm (in regards to sponsoring)
[15:32] <lidaobing> sistpoty|work, thanks
[15:36] <ScottK> bddebian: Editing that one into a sync request is best.
[15:39] <sistpoty|work> lidaobing: looks all good, ack'd
[15:39] <lidaobing> sistpoty|work, thanks
[15:40] <sistpoty|work> thanks for maintaining qterm ;)
[15:41]  * theholyduck likes his urxvt
[15:41] <theholyduck> why anyone would use a terminal OTHER than urxvt is beyond me
[15:49] <mok0> theholyduck: here's a reason: E: Couldn't find package urxvt
[15:50] <theholyduck> mok0, well rxvt-unicode
[15:50] <theholyduck> :P
[15:50] <theholyduck> is the package name
[15:50] <savvas> hm..
[15:50] <theholyduck> mok0, basicly urxvt does EVERYTHING:P
[15:50] <savvas> the packages should have python2.5 support as well, right?
[15:51] <theholyduck> diffrent fonts for diffrent kinds of text. extendable via perl scripts
[15:51] <theholyduck> etc,etc,etc
[15:51] <theholyduck> basicly urxvt is one of the fastest most extendable and configurable terminal emulators around
[15:53]  * savvas tries to use python$* ./setup.py install ...
[15:53]  * mok0 is happy with terminator
[15:58] <phomes> Any reason mobile-broadband-provider-info is not being updated? Current version (20081015) lacks one of the major danish providers and support questions for this are frequently popping up
[15:59] <mok0> phomes: Do you know how to add it?
[16:01] <phomes> mok0: it is already added to the newest version (20081124) at http://svn.gnome.org/viewvc/mobile-broadband-provider-info/tags/
[16:01] <RainCT> mok0: terminator rocks :)
[16:01] <mok0> phomes: so what you want is an update of the package, from upstream?
[16:02] <phomes> mok0: yes, if possible
[16:02] <mok0> phomes: then please file a bug report on LP
[16:02] <mok0> phomes: otherwise we'll forget
[16:02] <phomes> mok0: okay. Thanks
[16:03] <bddebian> ScottK: Yeah I adjusted it, though I probably did it wrong. :)  Thanks!
[16:03] <ScottK> K
[16:07] <mok0> james_w: you were right, --install-layout is patched on in the package
[16:07] <ScottK> RainCT: rgreening, whose upload you sponsored over the weekend, has a MOTU application pending.  You might want to comment: https://wiki.ubuntu.com/rgreening/DeveloperApplicationMOTU
[16:09] <mok0> ScottK, any plans of backporting python2.6?
[16:09] <ScottK> No.
[16:09] <ScottK> I think it's too intrusive.
[16:09] <mok0> probably, yeah
[16:09] <rgreening> RainCT: btw, the two fauz-pas... thanks for pointing out. Im used to working kdepackages which are already -*ubuntu*'ized, and the maintainer field is there. I;ll keep on my list for new ones. And the lp bug report. honest mistake. *slap* :)
[16:10] <mok0> ScottK, it builds fine under intrepid, though
[16:10] <rgreening> I shouldn't work on things at 4AM with no sleep :)
[16:10] <ScottK> My concern isn't will it work, but the impact having a new system Python will have on the rest of the system.
[16:11] <mok0> Yes, everything needs rebuilding
[16:13] <geser> mok0: only if you backport also python-default else you only need to backport/rebuild the packages which should have a python2.6 module
[16:14] <mok0> geser: k
[16:15] <phomes> mok0: looks like it already has a bug for updating. Should any special motu address be subscribed to the bug?
[16:16] <mok0> phomes, bug number?
[16:16] <phomes> mok0: 317860
[16:16] <mok0> bug 317860
[16:18] <doko> geser: thanks for the python updates in universe :-) how many are left? ;)
[16:19] <mok0> phomes: hm, that file ought to be dynamically updated
[16:20] <mok0> phomes: the package is in main, so you need to get hold of a core-dev
[16:21] <mok0> phomes: you should subscribe ubuntu-main-sponsors to the bug
[16:22] <phomes> mok0: okay. Thanks. Just subscribe ubuntu-main-sponsors and that is fine? Or should I go hunt for a core-dev as well?
[16:22] <mok0> phomes: you can do both :-)
[16:22] <phomes> mok0: I'll do that then. Core-devs hang out at #ubuntu-devel?
[16:23] <mok0> phomes: yes
[16:23] <mok0> phomes: we have some here, but they are hiding
[16:23] <ScottK> doko: Would you please update python-xml?  It looked like more trouble than I wanted to mess with.
[16:24] <mok0> phomes: it seems fairly important & a simple fix so I think you can find someone
[16:24] <geser> doko: around 250 binary packages according to 'apt-cache unmet -i | grep "python (< 2.6)" -c' :(
[16:24] <doko> ScottK: we did want to remove it post-intrepid ...
[16:24] <phomes> mok0: okay. Thanks for your help
[16:24] <mok0> np!
[16:24] <ScottK> doko: Yes, but there are still packages that need it IIRC.
[16:25] <savvas> should aptoncd have /usr/lib/python2.5/site-packages/ as well? I only get /usr/lib/python2.6/dist-packages/
[16:27] <bddebian> Anyone know who Devid Filoni is?
[16:27] <geser> savvas: for that the aptoncd packaging needs a little work as it currently only uses the default python version
[16:28] <JontheEchidna> bddebian: devfil on irc
[16:28] <bddebian> JontheEchidna: Thanks
[16:28] <geser> bddebian: LP knows it :) https://edge.launchpad.net/~d.filoni
[16:29] <savvas> geser: ok, I'll look into it :)
[16:29] <bddebian> I've come to despise LP these days :(
[16:29] <bddebian> I'm just curious why crystalspace seems to build fine with java in Debian but FTBFS in Ubuntu
[16:29] <geser> using the same JDK in both cases?
[16:30] <bddebian> afaik
[16:30] <bddebian> Devid did a lot of work on it though so I was curious if he had a clue
[16:34] <geser> bddebian: https://edge.launchpad.net/ubuntu/jaunty/+source/crystalspace shows that it build on amd64 and i386 at least
[16:34] <geser> but I can't see any java in the build-depends
[16:34] <bddebian> Yeah I couldn't either that's what makes it even weirder
[16:35] <bddebian> Unless gcj is getting brought in in Debian with something else..?
[16:36] <bddebian> ANd of course I forgot to save a build log and this thing take FOREVER to build :)
[16:36] <geser> no mentioning of gcj in the Debian build log for amd64
[16:37] <bddebian> I'll have to look at it
[16:42] <lajjr> hello dholbach
[16:42] <dholbach> hi lajjr
[16:43] <lajjr> do you by chance know when the next meeting is for motu??
[16:44] <dholbach> isn't it on  https://wiki.ubuntu.com/MOTU ?
[16:44] <lajjr> TBD
[16:45] <dholbach> lajjr: then I don't know - sorry - I think there was a call for MOTU Meeting organisation on the mailing list
[16:46] <billybigrigger> dholbach, is there going to be another open week after jaunty release?
[16:46] <billybigrigger> or was that a 1 time thing
[16:46] <dholbach> billybigrigger: there's definitely going to be - we had like 3 of them already
[16:46] <billybigrigger> oh ya
[16:46] <dholbach> billybigrigger: I don't have dates yet
[16:46] <dholbach> billybigrigger: jcastro might know
[16:46] <billybigrigger> haha, i missed 'em, loved open week after intrepid release
[16:46] <lajjr> oh good I was going to package a few things and kill some bugs to add to my application.
[16:47] <lajjr> so I have time ...lol
[16:47] <dholbach> billybigrigger: there should be logs of them
[16:47] <dholbach> lajjr: rock on!
[16:48] <billybigrigger> dholbach, im only seeing the last open week on the wiki, but im not digging too deep
[16:49] <dholbach> billybigrigger: check these out:
[16:49] <dholbach> https://wiki.ubuntu.com/MeetingLogs/openweekintrepid
[16:49] <dholbach> https://wiki.ubuntu.com/MeetingLogs/openweekhardy
[16:49] <dholbach> https://wiki.ubuntu.com/MeetingLogs/openweekgutsy
[16:49] <billybigrigger> dholbach, ahhh there they are :P just have to open the eyes a bit more
[16:49] <dholbach> https://wiki.ubuntu.com/MeetingLogs/openweekfeisty
[16:49] <dholbach> https://wiki.ubuntu.com/MeetingLogs/openweekedgy
[16:49] <lajjr> Thanks Daniel. My application the way it stands will be weak. I will build it up. I have time to do so..
[16:50] <dholbach> lajjr: bring it on! :-)
[16:50] <billybigrigger> dholbach, yup just found them thanks :)
[16:50] <jpds> Woah.
[16:51]  * lajjr gotta get to it...
[16:51] <lajjr> Have a great day everyone...
[18:06]  * sistpoty|work calls it a day... cya
[18:39] <AdamDH> hi, what does dh_strip actually do?
[18:40] <fabrice_sp_> AdamDH, get rid of all the debug info in the binaries
[18:40] <fabrice_sp_> (for libraries and executables)
[18:42] <AdamDH> thanks, so in my case I do not need that, I need to ensure that my packages are not stripped? is there anything else I need to do to stop stirpping of executables and shared libraries?
[18:46] <quadrispro> hi fabrice_sp_
[18:46] <fabrice_sp_> AdamDH, your packages needs to be stripped, otherwise you will get a warning in lintian (except if you want to do a debug package)
[18:46] <fabrice_sp_> hi quadrispro
[18:46] <quadrispro> fabrice_sp_: I'm looking at bug 335300
[18:46] <fabrice_sp_> ok
[18:46] <quadrispro> and I see you listed libtool twice in Build-Depends
[18:47] <fabrice_sp_> do you understand how it was possible to build this package before?
[18:47] <fabrice_sp_> arghh
[18:47] <fabrice_sp_> I'll check
[18:47] <quadrispro> thx
[18:47] <AdamDH> fabrice, I am packaging a cross compiler and I have had a few issues with the libc not working, and I can only put that down to it been stripped?
[18:47] <fabrice_sp_> you're right: it was already there
[18:48] <fabrice_sp_> quadrispro, ^^
[18:48] <fabrice_sp_> I'll update my debdiff
[18:48] <quadrispro> fabrice_sp_: I dont know how it  was possible build it before now :/
[18:48] <quadrispro> fabrice_sp_: however, i'm test-building it right now
[18:49] <quadrispro> fabrice_sp_: ah-ah! -> https://launchpad.net/ubuntu/+source/libhid/0.2.15+20060325-2.2
[18:50] <quadrispro> in fact, it ftbfs
[18:50] <fabrice_sp_> but if was building fine before
[18:50] <slytherin> AdamDH: AFAIK, striiping should not create functionality problems.
[18:50] <savvas> anyone working on decompyle?
[18:53] <AdamDH> in my package I keep getting: strip: Unable to recognise the format of the input file
[18:55] <savvas> Any motus to review/sponsor a patch? http://paste.ubuntu.com/125421/ http://launchpadlibrarian.net/23309069/buildlog_ubuntu-jaunty-amd64.decompyle_2.3.2-4.1ubuntu1~ppajaunty1_FULLYBUILT.txt.gz
[19:00] <savvas> I'll file a bug :)
[19:01] <fabrice_sp> AdamDH, are you generating a binary in your package?
[19:01] <RainCT> savvas: please don't mess with DH_COMPAT
[19:01] <AdamDH> yes
[19:02] <savvas> RainCT: ok, I'll revert that change - thanks :)
[19:02] <RainCT> savvas: (unnecessary divergence from Debian) Also, does the application work with Python 2.7?  that "<< 2.6" in XS-Python-Versions looks suspicious
[19:04] <RainCT> savvas: well, actually I don't mind about the compat change (anyone doing a merge should know that if it remains as the only divergence we should sync), and I used to do such changes too :P, but it's pretty much useless
[19:05] <quadrispro> fabrice_sp: building -> http://home.alessiotreglia.com/jaunty/pool/libhid_0.2.15+20060325-2.2ubuntu1/libhid_0.2.15+20060325-2.2ubuntu1.buildlog
[19:05] <maxb> AdamDH: The host system's strip doesn't know how to strip cross-binaries. (I don't know what the proper fix is, though)
[19:06] <savvas> RainCT: er.. I don't know if it works with 2.7, but i managed to build it fine in PPA - never tested it though
[19:06] <savvas>  Note that it cannot yet decompile byte-code from Python 2.4 and 2.5.
[19:06] <savvas>  Decompyle converts Python byte-code back into equivalent Python source.
[19:06] <savvas> RainCT: ^
[19:06] <pkern> Hi, could somebody on jaunty please confirm that "Secure WebDAV (HTTPS)" is listed in Places, Connect to server on Gnome?
[19:06] <savvas>  It accepts byte-code from any Python version between 1.5 and 2.3 inclusive.
[19:07] <fabrice_sp> quadrispro, with my change, right? It's building fine ;-)
[19:07] <jdong_> IMO it is not hard to put together a Python decompiler
[19:08] <savvas> RainCT: it seems that decompyle is no longer available - only commercially
[19:08] <RainCT> Uhm.. Is that of any use nowadays? Python 2.3 max...
[19:08] <quadrispro> fabrice_sp: I did some little changes (unnecessary libtool on b-d && changelog entry)
[19:08] <savvas> RainCT: I don't know.. how do you file a package removal?
[19:11] <quadrispro> fabrice_sp: uploaded
[19:11]  * quadrispro going to have dinner
[19:11] <RainCT> savvas: file a bug asking for removal from Jaunty and blacklisting from syncs
[19:11] <fabrice_sp> quadrispro, thanks.
[19:11] <RainCT> Does anyone thing we should keep decompyler?
[19:12] <jdong_> is it official that python 2.3 is obsolete?
[19:12] <pkern> Anyone with Gnome on Jaunty up for three clicks?
[19:12] <ScottK> jdong: It's not in the repos.
[19:12] <ScottK> Hasn't been for a long time.
[19:12] <ScottK> Dapper I or maybe even before.
[19:12] <ScottK> ... I think ....
[19:12] <jdong_> ok then it is pretty pointless of a project for us to keep
[19:13] <jdong_> especially since3 upstream has gone commercial
[19:13] <RainCT> Debian switched to 2.3 early 2006
[19:13] <RainCT> err 2.4
[19:13] <savvas> I'll file the bug then
[19:13] <savvas> should I subscribe someone?
[19:14] <ScottK> savvas: ubuntu-universe-sponsors
[19:14] <savvas> ok thanks
[19:14] <RainCT> savvas: tell us the number and someone of us will ack it and subscribe ubuntu-archive
[19:14] <ScottK> Then a MOTU will subscribe the archive-admins after they review
[19:14] <savvas> ok hold a sec
[19:14] <savvas> actually, 5 minutes :P
[19:19] <savvas> https://bugs.edge.launchpad.net/bugs/336859
[19:20] <billybigrigger> pkern, yes, places/connect "secure webdav (https) is in jaunty
[19:20] <pkern> ScottK: ^^ I had expected that, but did not check myself, TBH.  Thanks, billybigrigger.
[19:21] <billybigrigger> pkern, np
[19:23] <eMerzh> Hi, i've a lintian warning but i don't know how to fix .... the error is desktop-mimetype-without-update-call....since my debian/rules file is tiny ( http://bazaar.launchpad.net/~emerzh/%2Bjunk/sqliteman/annotate/head%3A/rules ) ...i don't know how to call the "update-desktop-database" ...
[19:24] <eMerzh> should i just add a postinst with this?
[19:27] <savvas> eMerzh: try using debhelper (>= 7) in control and 7 in compat
[19:27] <RainCT> savvas: Ack'd, thanks.
[19:28] <savvas> RainCT: no, thank you! :P I kept the patch however, it seems good to keep for the rest hehe
[19:28] <RainCT> eMerzh: call dh_desktop
[19:28] <eMerzh> RainCT, where ? at the end of my rules ?
[19:29] <RainCT> Bumping to 7 won't do; iirc dh_desktop is only called by gnome.mk and the like (probably also kde.mk, etc.)
[19:29]  * savvas notes
[19:29] <RainCT> eMerzh: Yes, in a binary-install target
[19:30] <RainCT> eMerzh: So:   binary-install/<pkgname>::\n\tdh_desktop       where \n is "next line" and \t a tab :P
[19:30] <savvas> RainCT: what if he had the desktop file in the /debian/ directory?
[19:30] <mrooney> Would anyone mind giving me a hand with bug 333639, I am not sure what to provide to get the ubuntu package updated from upstream
[19:30] <RainCT> savvas: doesn't matter, it will look at debian/<pkgname>/usr/share/applications
[19:30] <savvas> aah ok
[19:32] <eMerzh> RainCT, juste at the end of a file like this  too? (http://bazaar.launchpad.net/~emerzh/%2Bjunk/sqliteman/annotate/head%3A/rules)
[19:33] <james_w> mrooney: are you going to do an actual "upstream" release of the package?
[19:33] <RainCT> eMerzh: http://paste.debian.net/29600
[19:34] <eMerzh> RainCT, ok thanks a lot, i'll try this :)
[19:34] <RainCT> No problem. I'm off now, have to learn for an exam :(
[19:35] <savvas> good luck :)
[19:35] <mrooney> james_w: I did an upstream 0.4.1.0 release, it is linked in the bug report
[19:36] <RainCT> thanks
[19:37] <james_w> mrooney: well, with the packaging included in that, it could be just uploaded if you added a .dsc and a .changes
[19:37] <james_w> mrooney: but if there are any fixes needed it's not that easy
[19:37] <mrooney> james_w: what do you mean by "fixes needed", as in if the packaging isn't right?
[19:37] <james_w> well, easy, but perhaps slightly misleading
[19:37] <james_w> yeah
[19:38] <james_w> for instance the version number is not standard for a native package, which is what you have created
[19:39] <mrooney> hmm
[19:40] <mrooney> james_w: so how might I go from, the upstream 0.4.1.0 release to having an appropriate .dsc and .changes?
[19:40] <james_w> mrooney: well, you can't really do it, it needs to be a MOTU
[19:40] <mrooney> I am looking forward to not being overwhelmed by packaging and updates soon :)
[19:40] <mrooney> soon I will understand it all!
[19:41] <mrooney> I hope
[19:41] <james_w> heh :-)
[19:41] <mrooney> james_w: ahh so, should I update the bug report in some way?
[19:41] <mrooney> I am just worried about time constraints, and want to make sure I am doing everything I should be
[19:41] <james_w> a debdiff won't work
[19:41] <james_w> so just a pointer to your tarball again
[19:42] <james_w> and explain what you explained to me the other day
[19:42] <mrooney> okay, do you have time to add a brief comment? I feel like you might be able to explain an aspect or two that I don't fully grasp
[19:42] <james_w> sure
[19:42] <mrooney> thanks :)
[19:43] <kirkland> persia: hi, are you around?  question regarding https://bugs.edge.launchpad.net/ubuntu/+source/kvm/+bug/277517
[20:03] <fabrice_sp> Hi. Could some archive admin try to rebuild ia32-libs-tools? I've been able to build it successfully in a pbuilder, and I think a rebuild should fix it.
[20:03] <fabrice_sp> (ftbfs: http://launchpadlibrarian.net/23239676/buildlog_ubuntu-jaunty-amd64.ia32-libs-tools_11_FAILEDTOBUILD.txt.gz)
[20:12] <eMerzh> If a new version of program that i've packaged and waiting in the revu is released, should i add a line in the changelog?
[20:13] <mrooney> eMerzh: I don't believe since the updated version is still going to be the initial release in Ubuntu
[20:13] <mrooney> that's how I did it anyway
[20:14] <eMerzh> ok mrooney ...
[20:15] <mrooney> eMerzh: just change the version in the changelog
[20:16] <eMerzh> yep :) thanks for the reminder :)
[20:16] <RainCT> fabrice_sp: I've scheduled it on two arches (any MOTU can do). If it builds, poke me and I'll do the remaining ones
[20:17] <fabrice_sp> RainCT, did knew MOTU could do that. Thanks!
[20:22] <savvas> /usr/bin/ld: cannot find -lz
[20:22] <savvas> collect2: ld returned 1 exit status
[20:22] <savvas> -lz ?
[20:23] <hyperair> is there any freeze on that prevents universe packages from being upgraded?
[20:23] <savvas> ah zlib1g-dev
[20:23] <pkern> hyperair: feature freeze
[20:24] <hyperair> pkern: feature freeze includes versions?
[20:24] <hyperair> in that case i should put it to karmic then
[20:24] <pkern> hyperair: bugfixes only
[20:25] <hyperair> pkern: this is a new upstream release
[20:25] <hyperair> well i'll just set it to karmic then
[20:25] <superm1> hyperair, well are there new features in the upstream release, or is it a bugfix only release?
[20:25] <hyperair> probably new features as well
[20:26] <superm1> if it's bugfix only, it can still be uploaded, otherwise it would need a feature freeze exception, and unless you have a compelling reason, it should generally be deferred then
[20:26] <hyperair> i don't have a compelling reason =p
[20:26] <hyperair> so how should i go about it? i file the bug now, attach the diff.gz, and then after karmic opens up, subscribe universe-sponsors?
[20:28] <savvas> https://wiki.ubuntu.com/FreezeExceptionProcess
[20:28] <savvas> (I think)
[20:28] <savvas> ah wait, misread :P
[20:28] <savvas> ignore me :)
[20:29] <pkern> hyperair: Get it uploaded to Debian and autosynced to Karmic when it opens up.
[20:29] <hyperair> pkern: it's taking ages= \
[20:29] <pkern> hyperair: (You don't need to take care of the latter if there are no Ubuntu-specific changes.)
[20:29] <hyperair> it isn't in debian at the moment
[20:30] <hyperair> i'm trying to get it in, but nobody seems to be interested in sponsoring
[20:32] <eMerzh> My packgage freshly updated...(after a long wait for licence issue) http://revu.ubuntuwire.com/details.py?package=sqliteman ...if someone want to revu it again :) thanks
[20:36] <hyperair> eMerzh: what's dh_desktop for in debian/rules?
[20:37] <hyperair> hmm isn't cdbs supposed to take care of the dh_* stuff?
[20:38] <eMerzh> hyperair, it's to update the .desktop database...RainCT told me to do so :)
[20:38] <hyperair> eMerzh: i'd actually look into using /usr/share/cdbs/1/class/{kde4,xfce,gnome}.mk instead =\
[20:39] <hyperair> well i suppose it doesn't really matter
[20:39] <hyperair> though i didn't use it for my packages
[20:42] <savvas> er..
[20:42] <savvas> ./usr/lib/python2.6/site-packages/cs_helpers.py
[20:42] <savvas> this should be dist-packages right?
[20:43] <hyperair> eMerzh: i think you're missing the license text for the bsd license
[20:43] <ScottK> savvas: Yes.  2.6 and site-packages is wrong.
[20:44] <eMerzh> hyperair, ok just a copy of http://www.freebsd.org/copyright/freebsd-license.html ?
[20:44] <savvas> thanks ScottK - I'm trying out to update capisuite to python 2.6 :)
[20:45] <hyperair> eMerzh: yeah i think that should do
[20:46] <hyperair> eMerzh: well other than that, it looks good to me. i didn't try building it though =p
[20:47] <hyperair> eMerzh: make sure the binaries are lintian clean
[20:47] <hyperair> and poke a motu
[20:47] <hyperair> i'm not one
[20:47] <eMerzh> hyperair, ok thanks ... i'll  update the freebsd and upload :)
[20:47] <hyperair> eMerzh: alright
[21:02]  * eMerzh poke a MOTU to review his freshly updated package :) (http://revu.ubuntuwire.com/details.py?package=sqliteman)
[21:06] <savvas> Is there a python command to get the default python module directory?
[21:07] <maxb> default in what sense? :-)
[21:07] <savvas> maxb: something like this: python -c "from distutils import sysconfig; print sysconfig.get_python_lib(1,1)"
[21:09] <savvas> but to return the dist-packages directory for 2.6 or site-packages for 2.5
[21:09] <james_w> savvas: check /usr/share/python/python.mk
[21:11] <savvas_> ok let's hope I stick around this time :P
[21:13] <RainCT> include /usr/share/pycentral-data/pycentral.mk          $(call sitedir,$(python_ver))
[21:14] <RainCT> the $(...) gives either site-packages or dist-packages depending on the value of $python_ver, not sure if that's what you want
[21:18] <asomething> are bindings ok in /usr/lib/python-support/*/python2.6/ ?
[21:19] <ScottK> that looks right.
[21:26] <savvas_> ls
[21:27] <savvas_> oops
[21:30] <savvas> hm.. I wonder if I should patch acinclude.m4 and aclocal.m4 or just move the built files from site-packages to dist-packages in debian/rules
[21:30] <savvas> or should I patch configure? :\
[21:31] <pkern> Bah, is there a way with kvm/qemu to switch virtual consoles?
[21:32] <jcfp> With a python app not working with 2.6, should I just restrict python versions to 2.5, and make it point #!/usr/bin/python2.5?
[21:33] <ScottK> jcfp: No.  Generally stuff should work.
[21:33] <ScottK> savvas: Better to have the build system put stuff in the right place than shove it around in debian/rules.
[21:34] <ScottK> jcfp: Usually there are minor packaging changes are all that's needed to get stuff working with 2.6.
[21:35] <jcfp> ScottK: but in case it doesn't? Upstream is aware of it and attempting to fix things for a future release, out in the summer somewhere.
[21:35] <ScottK> Yes.  then do that.
[21:35] <jcfp> ok thanks
[21:37] <pkern> ScottK: Hm, the bug also applies to hardy.  Trying the fix now...
[21:37] <ScottK> pkern: Thanks for checking.
[21:38] <pkern> Apart from bloody ubuntu-vm-builder.  Not setting a password for root and gdm not letting root log in and no gdm configuration panel available.
[21:39] <pkern> ScottK: The fix will be identical, although I don't know if also packaging-wise...
[21:40]  * ScottK nods.
[21:45] <pkern> ScottK: Same patch applies cleanly \o/
[21:45] <ScottK> ok
[21:45] <ScottK> Please shove a debdiff in the bug and I'll deal with it from there.
[21:45]  * pkern will attach another debdiff to the bug shortly.
[21:50] <pkern> ScottK: attached, thanks
[21:50]  * ScottK looks
[22:00] <fabrice_sp> Can someone unsubscribe U-S-u from Bug #336904? I have to convert it into a sync request, with a FFe... thanks
[22:02] <ScottK> Done
[22:03] <ScottK> pkern: Uploaded.  Thank you for your contribution to Ubuntu.
[22:04] <fabrice_sp> thanks
[22:07] <pkern> ScottK: Heh. ;-)
[22:11] <AdamDH> what happens if you have to ship a binary inside your package? there is no source to compile from. Do I just use install to install the programme and required libarys?
[22:12] <ScottK> AdamDH: First, that means it has to go in Multiverse.
[22:12] <AdamDH> where do I tell my package it has to go in Multiverse? I was going to leave it in my ppa
[22:13] <ScottK> If it's uploaded to Ubuntu, the archive admins will take care of that.
[22:13] <james_w> I'm not sure you can upload it to your PPA
[22:14] <ScottK> Yeah.  That was going to be my next comment.
[22:14] <AdamDH> might be easier for people to just get the binary and libs away from a package for it
[22:14] <ScottK> You need to read the PPA terms of service closely and see if it's allowed in a PPA.
[22:15] <AdamDH> I will take a read and ask in launchpad
[22:15] <savvas> AdamDH: you could use get-orig-source: in debian/rules for that
[22:15] <ScottK> savvas: I think you're answering a different question than he's asking.
[22:15] <savvas> but still.. the package will probably cause problems with the terms of service
[22:16] <AdamDH> its proprietary code so they just ship a binary
[22:16] <savvas> oh..
[22:16] <savvas> ScottK: right, sorry :P
[22:16] <ScottK> AdamDH: I'm pretty sure that can't go in a PPA.
[22:17] <AdamDH> So if I just place it on my website, whats the best way to create a package for it? its two libarys and a binary
[22:17] <savvas> AdamDH: you could add a script and explain them to run the script and include that proprietary program :) or just ask the developers of that program to open up :P
[22:18] <AdamDH> savvas they will not open up the linux version has not been updated in a while to support new devices (its a programme to programme msp430 micros via gdb its a proxy) the windows version is allways up to date
[22:18] <savvas> ScottK: I managed to patch capisuite, thanks for the suggestion before :)
[22:19] <ScottK> You're welcome.
[22:21] <tuxmaniac> anyone on jaunty who can test bug 291075 ?
[22:21] <tuxmaniac> I believe it is a libtool issue and there has been updates to libtool in Jaunty
[22:22] <tuxmaniac> oops may be its not related to #u-motu but more related to #u-bugs
[22:22] <tuxmaniac> sorry
[22:25] <savvas> doko: here? you commented something on bug 336344 - should capisuite build-depend on zlib1g-dev or should I try and remove the -lz library call?
[22:29] <savvas> tuxmaniac: you could also try #ubuntu+1 :)
[22:30] <tuxmaniac> aah yeah forgot. thanks savvas
[22:32] <savvas> np hehe
[22:33] <DktrKranz> james_w, hi. did you have the chance to look at bug 336067? It blocks some applications (such as requestsync), so it could be useful to have it. I tested the upstream patch and seems good.
[22:33] <james_w> DktrKranz: I'm getting to it
[22:33] <james_w> DktrKranz: thanks for testing though
[22:33] <DktrKranz> cool, thanks :)
[22:33] <james_w> DktrKranz: feel free to upload :-)
[22:33] <DktrKranz> ok then, I'll have a look
[22:55] <AdamDH> where would I find the termcap library on ubuntu? I have a dependancy for it but cannot find it on packages.ubuntu etc
[23:00] <jpds_> OK...
[23:04] <directhex> jms@destiny:~$ apt-file search libtermcap
[23:04] <directhex> libncurses5-dev: /usr/lib/libtermcap.a
[23:04] <directhex> libncurses5-dev: /usr/lib/libtermcap.so
[23:06] <tgm4883> geez directhex, what button did you push?
[23:07] <directhex> tgm4883, just finished installing evil M$ trojans on freenode
[23:07] <tgm4883> Windows?
[23:08] <tgm4883> or is there another MS trojan?
[23:09] <directhex> depends who you believe
[23:27] <Laney> DktrKranz: here?
[23:27] <DktrKranz> Laney, for a little while
[23:27] <Laney> "Disable PrintSample support, obsolete" in gtksourceview-sharp2
[23:27] <Laney> I'm wondering what that's for?
[23:27] <Laney> (just looking at it in Debian)
[23:28] <DktrKranz> Laney, IIRC, it fixed a FTBFS
[23:28] <Laney> oh, weird
[23:28] <Laney> don't see it in sid
[23:28] <Laney> let me try in Jaunty
[23:38] <savvas> goodnight everyone :)
[23:40] <savvas> james_w: I provided two debdiffs for bug 336344 - I think the one without zlib needs testing (I haven't tested the program of neither of them)
[23:41] <james_w> savvas: thanks, I'll try and get to it soon