[00:00] <wgrant> I think there's just lots of bugs.
[00:00] <Laney> *sigh*
[00:00] <Laney> this is not a well-managed transition
[00:00] <wgrant> Hm, I guess I'd best file a FFe exemption bug before I upload...
[00:00] <wgrant> It is not a managed transition at all.
[00:01] <Laney> but why did this happen?
[00:01] <wgrant> Why did what happen?
[00:02] <ScottK> wgrant: If it's just bugfix then it doesn't need FFe.
[00:02] <wgrant> ScottK: It still needs a bug.
[00:02] <ScottK> wgrant: It has one.  Just mark something in that.
[00:02] <Laney> an unmanaged transition
[00:02] <wgrant> ScottK: Thanks.
[00:02] <Laney> Although "Please assign bug reports caused by build failures to me." if doko is offering to fix the world...
[00:03] <ScottK> When I've gotten stuck and asked, he's been good about making suggestions.
[00:06] <Laney> While that is commendable, it's separate to managing the transition. Ideally we'd have had a bug report or (preferably) a wiki page listing what needs to be done
[00:06] <Laney> maybe I've been spoiled by the mono transition though
[00:06] <Laney> directhex: <3
[00:06] <directhex> Laney, launchpad blueprint!
[00:07] <Laney> yessum, there was a spec
[00:08] <wgrant> Do we even have a list of everything that is broken?
[00:08] <wgrant> Is that even possible?
[00:08] <Laney> Depends: python (<< 2.6)?
[00:10] <wgrant> That was my initial guess, but I doubt that covers everything.
[00:37] <Laney> Someone who knows python: are these deps right for an application which is incompatible with 2.6? http://pastebin.com/f399506d4
[00:37] <Laney> repeating python2.5-x, python-x seems weird to me
[00:39] <ScottK> Looking
[00:40] <ScottK> That seems wrong to me.  I think it should be just the -2.5 one.
[00:41] <Laney> They're not even real packages
[00:41]  * Laney spins round in circles
[00:43]  * ajmitch wonders when sid will switch to 2.6
[00:44] <directhex> when someone on the python team negotiates a breaking transition slot?
[00:44] <directhex> from debian-release
[00:45] <Laney> guhhhhh
[00:46] <Laney> ScottK: Would it be a problem for a 2.5 app to use 2.6 libs?
[00:46]  * Laney is so bad at python packaging
[00:46] <ScottK> Yes
[00:47] <Laney> but if libs have been transitioned, what happens then?
[00:48] <ajmitch> is 2.5 still in main & packages build for 2.5 & 2.6?
[00:54] <Laney> well, I removed the 2.5 ones and it works
[00:54] <Laney> I wouldn't even be able to get on the web interface if cherrypy was incompatible
[00:54]  * Laney is reasonably happy with that
[00:57] <ScottK> Most modules should build for both.
[00:59] <Laney> Would I see a failure anywhere if they weren't?
[01:02] <ScottK> If you start python2.5 and import foo works, then foo is built for 2.5.
[01:04] <Laney> OK, they all seem to work
[01:04] <Laney> that's good enough for me
[01:04] <Laney> thanks for your help
[01:04] <ScottK> YW
[01:08]  * ajmitch should not read ubuntu-sounder, too much uninformed ranting at the moment
[01:08] <ScottK> ajmitch: Worse than ubuntu-devel even?
[01:09] <ajmitch> the threads aren't nearly as long as notification bikeshedding
[01:09] <ajmitch> or fonts vs DPI
[01:14] <ScottK> Don't forget update icons.
[02:17] <savvas> bug 339554 patched!
[02:20] <savvas> 3 hours of banging my head against the wall due to sed and escaping characters finally paid off :P
[02:25] <ScottK> Ah.  A "learning experience".
[02:26] <savvas> yes :)
[03:03] <savvas> ScottK: Can you find someone to test-drive python-zsi merge for bug 237674 ? I removed the python-xml, but I don't know how to properly test it: http://ppa.launchpad.net/medigeek/ppa/ubuntu/pool/main/z/zsi/python-zsi_2.1~a1-2ubuntu1~ppajaunty3_all.deb
[03:04] <savvas> I mean I removed the python-xml dependency, the rest was done upstream heh :)
[03:04] <ScottK> savvas: If upstream says python-xml is no longer required, I think it's reasonbly safe to assume not dropping it was a maintainer oversite.
[03:04] <savvas> aaah I see
[03:04] <ScottK> Isn't the Debian maintainer bzed?
[03:05] <savvas> it's registered to debian python modules team
[03:05] <savvas> I've left a comment on the debian bug: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=468622#10
[03:06] <ScottK> savvas: I think bzed is usually the uploader.
[03:07] <ScottK> I saw the bug (I get all the DPMT bugmail) but going to #debian-python and asking might work better.
[03:07] <savvas> ok :)
[03:08] <savvas> thanks!
[03:08] <ScottK> savvas: Most of the people who'd know are European, so this isn't the best time of day.
[03:11] <savvas> ScottK: I know, I'm from Europe too - I'll try later in the afternoon, I have to go :)
[03:12] <ScottK> OK.  Well you're up late then.
[03:12] <savvas> 4am heh
[03:13] <savvas> I love silence, helps me focus on my studying :)
[03:13] <savvas> but I'll get back on my old time schedule as soon as the university starts again heh
[03:14] <savvas> see ya!
[04:10] <ripps> Hmmm... I'm trying to backport a program from jaunty to hardy, but I keep getting libtool errors. Is there something I'm missing? I know there's a libtool package in hardy.
[04:14] <ScottK> It's a very different version and some of the options supported are different.
[04:14] <ScottK> Depending on the error it may take some reasonably expert assistance (not me) to sort it out.
[04:15] <ripps> http://launchpadlibrarian.net/23623109/buildlog_ubuntu-hardy-i386.libmpd_0.18.0%7Egit090305-0ubuntu3%7Erippsh_FAILEDTOBUILD.txt.gz
[04:18] <ripps> Huh, I think I know what the problem is, I ran autogen.sh locally to setup the build environment, but this associates it with my jaunty version of libtool. How do I get my debian/rules to run the autogen.sh, instead of me. I'm using cdbs to manage my rules file.
[04:28] <ripps> Does anybody know to run autogen.sh within rules? I can't figure it out.
[04:41] <fabrice_sp> ripps, something like that: post-patches:: debian/stamp-autotools-maintregen-arch
[04:41] <fabrice_sp> debian/stamp-autotools-maintregen-arch:
[04:41] <fabrice_sp> 		build-tree/*/autogen.sh
[04:43] <ripps> fabrice_sp: there isn't a cdbs class/rule that handles this already?
[04:44] <fabrice_sp> ripps, I'm not an expert of cdbs, but that's what I've found in several packages
[04:45] <ripps> fabrice_sp: Okay, I'll try adding it
[04:52] <ripps> fabrice_sp: debian/rules:9: *** missing separator.  Stop.
[04:52] <ripps> I'm not quite sure what you did, so I'm not sure how to fix it.
[04:53] <ScottK> ripps: What's on line 9 of debian/rules?
[04:53] <ripps> ScottK:    build-tree/*/autogen.sh
[04:54] <ScottK> Try a 2nd ":" on the line before.
[04:55] <ripps> ScottK: didn't fix it. Here's the debian/rules: http://paste.ubuntu.com/128612/
[04:57] <ScottK> I'm tired and not tracking very well, but how about a tab before the text on line 9.
[04:58] <ripps> ScottK: omg, that was it.
[04:59] <ScottK> ripps: You're welcome.
[04:59] <ripps> Figures, I'd screw up on the most basic level
[05:01] <ripps> well, let's see if pbuilder will run autogen.sh
[05:01] <ScottK> I don't know much about that part.
[05:02] <ripps> make: *** [debian/stamp-autotools-maintregen-arch] Error 127
[05:02] <ripps> /bin/sh: build-tree/*/autogen.sh: not found
[05:10] <fabrice_sp> ripps, try with just autogen.sh, without  build-tree/*
[05:10] <ripps> fabrcie_sp: actually I'm trying "sh ./autogen" right now
[05:10] <fabrice_sp> ok
[05:12] <ripps> Aha! I think it's working
[05:20] <fabrice_sp> great! :-)
[05:44] <ripps> The only problem now, is that I have to re-pull all the directories from git that I already ran ./autogen.sh locally, because it changed and  created so many files that a simple make distclean doesn't do the job.
[06:05] <dholbach> good morning
[06:07] <fabrice_sp> Good morning dholbach
[06:08] <dholbach> hiya fabrice_sp
[06:52]  * nixternal hugs dholbach 
[06:52]  * dholbach hugs nixternal back :)
[06:53] <nixternal> how is your day so far sir?
[06:53] <dholbach> very good very good, I'm slowly waking up ;-)
[06:53] <dholbach> how are you doing over there?
[06:53] <nixternal> hehe
[06:54] <nixternal> flushing out some unicode boogs in my new country script for geo and django
[06:54] <dholbach> gotta love Unicode{En,De}coreError :)
[06:55] <nixternal> ya, think I finally got my fingers on the one issue....str(foo) to the rescue
[09:18] <Toadstool> g'morning
[09:40] <savvas> Is it possible that a .mk file doesn't work because there is another rule in debian/rules that processes the same file?
[09:57] <hyperair> savvas: i don't think so.
[09:57] <hyperair> savvas: if you look at the cdbs stuff, many of them require the same files
[09:59] <savvas> hyperair: https://bugs.edge.launchpad.net/ubuntu/+source/gedit-plugins/+bug/339554/comments/6
[10:01] <savvas> here's the uploaders.mk file: http://paste.ubuntu.com/128673/
[10:03]  * hyperair groans
[10:03] <hyperair> that's a lot of symbols
[10:04] <savvas> :P
[10:05] <hyperair> ...that's one very lazy maintainer.
[10:05] <hyperair> s/very/extremely/
[10:05] <hyperair> to automatically generate a list of Uploaders in debian/control
[10:05] <hyperair> what is this
[10:05]  * hyperair headdesks
[10:06] <savvas> well.. I tried to clear it up a bit :)
[10:06] <hyperair> heh
[10:07] <hyperair> wait, is this file in CDBS?
[10:07] <hyperair> as in, is it one of them cdbs includes?
[10:07] <hyperair> no wait, it doesn't exist
[10:08] <savvas> https://launchpadlibrarian.net/23156369/gedit-plugins_2.25.3-0ubuntu1.diff.gz
[10:08] <savvas> it has a build dep for cdbs, if that's what you mean
[10:09] <hyperair> no, that's not what i meant
[10:09] <hyperair> this whatever.mk file
[10:09] <hyperair> where did you get it from?
[10:09] <savvas> aaah no, I don't think so :) it's from gnome-pkg-tools
[10:11] <hyperair> interesting
[10:11] <hyperair> i see
[10:11] <hyperair> and DISABLE_UPDATE_UPLOADERS is set
[10:12] <hyperair> now, what's the problem?
[10:12] <hyperair> if it's the plugin description.... changing the find line in debian/rules should do the trick
[10:13] <savvas> comment out and DISABLE_UPDATE_UPLOADERS and remove -e "s#@GNOME_TEAM@#$(UPLOADERS)#g", uploaders.mk doesn't change @GNOME_TEAM@
[10:14] <hyperair> wait, why are you commenting that out?
[10:14] <hyperair> if we don't want to change the uploaders, then we should leave it there right?
[10:14] <savvas> no, we want to change it! uploaders.mk is supposed to do that, isn't it? :)
[10:15] <savvas> @GNOME_TEAM@ should be replaced by the makefile rule in uploaders.mk
[10:15] <hyperair> yes.... but there are cases where you might want to change it manually?
[10:16] <savvas> so this is one of those cases?
[10:16] <hyperair> i have no idea
[10:18] <savvas> I'm asking because Daniel asked why the sed command replaces the @GNOME_TEAM@, when there is already a rule in uploaders.mk to do that :)
[10:18] <hyperair> good point
[10:18] <hyperair> but shouldn't you change as little as possible from debian?
[10:19] <hyperair> if what debian has works, then leave it i say =p
[10:19] <savvas> well, I'll send back to debian if it gets approved :)
[10:19] <hyperair> aah
[10:19] <hyperair> i see
[10:19] <hyperair> in that case, by all means, clean it up
[10:19] <hyperair> =p
[10:19] <savvas> :P
[10:19] <savvas> ok
[10:20] <hyperair> savvas: oho.
[10:20] <hyperair> savvas: there is a reason why debian/rules looks like that
[10:20] <savvas> "* Drop superfluous uploaders include." ? :)
[10:20] <hyperair> savvas: notice that debian/rules has a sed command which has two -e's
[10:21] <hyperair> if you let the uploaders.mk do its job, then do your stuff after that, you're going to clobber
[10:21] <hyperair> note: sed blah blah blah control.in > control
[10:21] <hyperair> that's how the uploaders.mk handles it first.
[10:22] <hyperair> if you do sed -e "custom rule" control.in > control a second time you'll clobber the stuff done by uploaders.mk
[10:22] <savvas> you mean I should try without -e ?
[10:22] <hyperair> noooooooooooo
[10:22] <hyperair> i'm saying just leave the debian/rules as it is
[10:22] <hyperair> include /usr/share/gnome-pkg-tools/1/rules/uploaders.mk is needed because debian/rules needs some vars which are specified inside it
[10:23] <hyperair> DISABLE_UPDATE_UPLOADERS := 1 <-- this is needed so that uploaders.mk does NOT touch debian/control _yet_
[10:23] <hyperair> sed \
[10:23] <hyperair>                         -e "s#@GNOME_TEAM@#$(UPLOADERS)#g" \
[10:23] <hyperair>                         -e "$$plugins_desc_script" \
[10:23] <hyperair>                         debian/control.in > debian/control
[10:23] <hyperair> and this...
[10:23] <hyperair> handles everything all at once in one sed command
[10:23] <hyperair> because handling it in multiple will only have the last change.
[10:24] <hyperair> well of course there's the whole option of just using sed -i -e "$$plugin_desc_script" debian/control
[10:24] <hyperair> considering that the clean rule from uploaders.mk would have generated a partially complete debian/control already
[10:26] <savvas> ah..
[10:26] <savvas> now I see!!
[10:26]  * hyperair nods
[10:27] <savvas> but I think it's better to leave it this way, gives the maintainer more power over control.in changes :P
[10:27] <directhex> hm. anyone on motu-release about?
[10:28] <hyperair> yes that's my point
[10:28] <hyperair> leave it that way
[10:28] <savvas> hyperair: thanks for the clarification, you've been a big help! :)
[10:28] <hyperair> np
[10:30] <directhex> DktrKranz, poke?
[10:31] <eMerzh> I'm looking for an MOTU's review of my package at http://revu.ubuntuwire.com/details.py?package=sqliteman ... thanks for your help :)
[10:34] <hyperair> eMerzh: i'd wait for karmic if i were you ;)
[10:34] <DktrKranz> directhex: pike
[10:36] <directhex> DktrKranz, what are the chances on a FFe for "blam" going to be? I was going to avoid asking for one (as the 0.0.1 upstream bump contains a fundamental change), but something's cropped up..... a binary-only dll in ubuntu's orig which the ubuntu version needs
[10:36] <eMerzh> hyperair, yes... but if it could be validated, i would not say no :)
[10:36] <directhex> DktrKranz, it's an RSS reader. the major change, other than removing the non-free component, is dropping gecko in favour of webkit
[10:37] <directhex> DktrKranz, and no, i don't know how feasible backporting the replacement rss lib would be
[10:40] <DktrKranz> directhex: mmmh, wasn't that already processed?
[10:40] <hyperair> eMerzh: ah i see
[10:40] <DktrKranz> I've seen something on -changes, was it Debian?
[10:42] <directhex> DktrKranz, well, it's been updated for the mono 2.0 transition in jaunty, but not "fully"... i was researching why, and it seems the 1.0 dependencies come from the binary dll
[10:42] <directhex> DktrKranz, it's fixed in sid, but it's a major change to switch rendering engine, so definitely needs a FFe
[10:42] <DktrKranz> directhex: so it needs an upgrade due to mono 2.0
[10:44] <directhex> DktrKranz, it *needs* an upgrade due to binary in orig. as it stands, it builds fine on jaunty (as someone, probably you, updated it) - it just sucks & pulls in all of the 1.0 corlib
[10:46] <DktrKranz> directhex: sounds good for a pretty straightforward FFe
[10:46] <directhex> i'll test it in a VM, to be certain that there are no obvious regressions
[10:48] <DktrKranz> it's a standalone app, isn't it?
[10:49] <directhex> yes
[10:50] <DktrKranz> so it's good
[10:50] <DktrKranz> it won't be more broken than now
[10:54] <directhex> DktrKranz, seems to work okay. right, do i file the FFe and the merge patch on the same bug? i forget things in my old age...
[10:55] <persia_> directhex, One bug is best, as it preserves bug numbers (and the supply is limited).
[10:56] <DktrKranz> directhex: yes please
[10:56] <DktrKranz> old age? :)
[10:57] <DktrKranz> directhex: how was your NEW processing like? Any REJECT(tm)?
[10:58] <directhex> DktrKranz, open the NEW page. look at the item right at the top. the pariah of the queue, the elephant in the room.
[11:00] <savvas> you need a license for the elephant
[11:00] <savvas> :)
[11:00] <DktrKranz> directhex: heh. I was lucky, my two went in without issues \o/
[11:01] <directhex> DktrKranz, alright for some ¬_¬
[11:01] <directhex> DktrKranz, 150 or so packages processed, yet they mysteriously ignore package #4 on the list :(
[11:07] <directhex> okay, there we go, bug #339863 filed
[11:09] <DktrKranz> directhex: too hard to review?
[11:09] <directhex> hm?
[12:19] <iulian> DktrKranz: Are you taking care of blam or should I subscribe the uus?
[12:19] <iulian> (exception granted)
[12:23] <directhex> woo
[12:26] <directhex> iulian, have you seen the sexy, sexy progress on the 2.0 transition? Saving precious, precious megabytes from peoples' installations...
[12:26] <khashayar_> nhandler: Just leaving a note here: I've addressed your comments for pencil (http://revu.ubuntuwire.com/details.py?upid=5335). Thanks for taking a look at it after FF and all.
[12:36] <iulian> directhex: Hmm, no, unfortunately.  I've forgotten to join -mono on OFTC and haven't looked at that wiki page :-(
[12:37] <directhex> iulian, http://wiki.debian.org/Teams/DebianMonoGroup/Mono20TransitionTODO
[12:37] <iulian> directhex: I see that meebey uploaded giver to Sid.  I'm wondering why lintian thinks that the package was NMUed.  Isn't meebey a member of the Debian CLI Applications Team on Alioth?  I put myself as an Uploader in the previous upload.
[12:37] <iulian> Ouh, that's nice.
[12:43] <directhex> once all remaining smerge bugs are closed, then ubuntu is done!
[12:44] <persia> Um, no.  There might be bugs during the testing period :)
[12:45] <Pici> bug 100000
[12:45] <Pici> :(
[12:46] <directhex> persia, i meant for the mono 2.0 transition ;)
[12:47] <directhex> persia, was i correct in hearing word that java 7 might become more monoish and actually be splittable into smaller libs in a rational manner?
[12:47] <persia> directhex, I can't speak for the former.  I believe that much of the base JDK will be broken into separable libraries, but haven't heard too many details.
[12:48] <persia> Despite the JCP, I still basically wait to hear what Sun is planning.
[12:48] <directhex> it would be nice if a java app could have a <100 meg footprint including framework
[12:50] <persia> Yeah, although the work on -headless seems to be making that possible for server stuff.
[12:50] <persia> We'll see how far it goes.  As much as anything, it's the app authors who tend to use all the little bits just because they are there.
[12:50] <directhex> well, your target is about 35-40 meg for tomboy w/ mono, i think ;)
[12:51] <persia> Well, kinda.  Part of the issue is that the perception of "Java Works" is related to applets working, and that requires *lots* of libraries for graphics, animation, sound, etc.
[12:52] <directhex> ehm... true
[12:52] <directhex> which is nicer, the rock or the hard place?
[12:53] <wgrant> ... not Java, perhaps.
[13:03] <DktrKranz> iulian: I can manage it this evening, if directhex don't find another sponsor before
[13:23] <iulian> DktrKranz: OK.
[14:06] <bddebian> Heya gang
[14:13] <geser> Hi bddebian
[14:15] <bddebian> Heya geser
[15:01] <iulian> Heya bddebian.
[15:03] <bddebian> Hi iulian
[15:07] <dholbach> anybody know a package that uses python's distutils and debhelper7?
[15:07] <dholbach> maybe python-support too? :)
[15:07] <ScottK> dholbach: stepic
[15:07] <dholbach> I'm trying to figure out what python-django-lint (only in Debian) FTBFS in Ubuntu
[15:07] <dholbach> ScottK: thanks - I'll check it out
[15:08] <ScottK> dholbach: If it's like some other django stuff it's becuase it uses ez_setup.
[15:08]  * ScottK didn't look at that one specifically though
[15:08] <dholbach> it seems to install what's in setup.py's scripts' list into usr/local and dh_usrlocal explodes
[15:08] <ScottK> You need to patch around the ez_install stuff.
[15:09] <dholbach> it does not use ez_install AFAICS
[15:09] <ScottK> Oh.  OK.
[15:09] <ScottK> Nevermindthen.
[15:09] <dholbach> just the regular distutils..core
[15:09] <dholbach> ok - I'll have a poke at it
[15:09] <dholbach> seems like a useful tool
[15:09] <ScottK> dholbach: Then it probaby needs the install layout=deb magic
[15:09] <dholbach> ah!
[15:09] <ScottK> I'll look up the exact syntax
[15:09]  * dholbach will try it
[15:10] <ScottK> dholbach: setup.py install --install-layout=deb
[15:10] <ScottK> Adding the --install-layout=deb is likely the missing bit.
[15:10] <dholbach> gracias, now I'll see how to marry that with debhelper7 :)
[15:14] <geser> patch debhelper so other python packages benefit from it too
[15:15] <dholbach> geser: I'd rather leave that to somebody who's a bit cleverer than I am... like doko
[15:15] <dholbach> ... and understands the bigger python picture than I do
[15:16] <geser> cdbs was patched to include --install-layout=deb by default when calling setup.py install but apparently not debhelper
[16:08] <ara> dholbach: does it makes sense to have circular dependencies? because debian ldtp package just introduced one
[16:08] <ScottK> ara: They matter a lot less for Debian (due to doing binary uploads) than to Ubuntu. We want to avoid those.
[16:09] <dholbach> ara: why is it necessary there?
[16:10] <ara> dholbach: the reason is that the packaging is done badly. ldtprunner is part of ldtp package, but should be part of python-ldtp
[16:10] <ara> dholbach: they have just make ldtp depend on python-ldtp. but python-ldtp was already depending on ldtp
[16:10] <dholbach> ara: could it be easily moved to the other package (with added conflicts/replaces to the old version)?
[16:11] <dholbach> hum.... as far as I can tell the new ldtp does not depends on python-ldtp? (1.5.0-1 in Debian)
[16:12] <ara> dholbach: I guess so, I will talk with the debian maintainer about it. I don't think it ldtp is going to publish any necessary fixes for jaunty, so I will try to have it sorted out before karmic auto-sync
[16:12] <ara> dholbach: yes, it is in debian only
[16:12] <ara> dholbach: ldtp (1.5.0-2) unstable; urgency=low
[16:12] <ara>  .
[16:12] <ara>    * debian/control:
[16:12] <ara>      + ldtp now depends on python-ldtp package,
[16:12] <ara>        Thanks to Ben Pfaff <blp@cs.stanford.edu> (Closes: #518902)
[16:12] <dholbach> ah, ok
[16:13] <ara> dholbach: but it will be in karmic, eventually ;-)
[16:15] <dholbach> it'd be nice if the circular dependency could be avoided :-/
[16:18] <ara> dholbach: OK. I will put it on my to do list. I will try to get debian fixed before auto-sync
[16:19] <dholbach> ara: if the ubuntu package has an "ubuntu" in the version number, it won't be auto-synced, but sure... it's great if it's fixed beforehand
[16:19] <ara> dholbach: cool, I didn't know that one ;-)
[16:20] <dholbach> yeah, it makes life a bit easier for us :)
[16:22] <dholbach> c_korn, thekorn: heya - this is something I wanted to ask for a long time already... are you guys related? :)
[16:22] <c_korn> dholbach: not that I knew
[16:23] <dholbach> anyway... great having two Korns here who are doing a good job :)
[16:23] <imbrandon> heh
[16:23]  * ScottK hands some ksh to dholbach for completeness.
[16:24] <dholbach> ScottK: ksh?
[16:24] <dholbach> ahh ok
[16:24] <ScottK> Korn Shell.
[16:24]  * dholbach is getting a bit slow already :)
[16:24] <dholbach> 6:00 maybe was too early :)
[16:26] <c_korn> dholbach: well, I am not even a MOTU, but thanks
[16:27] <dholbach> c_korn: still... when your name turned up somewhere in the sponsoring queue I thought "maybe he's related to Markus... I *need* to ask him!" :-)
[16:27] <dholbach> keep up the good work
[16:27] <DktrKranz> dholbach: or your coffee wasn't strong enough. I'll borrow you my "moka" :)
[16:28] <dholbach> DktrKranz: thanks a bunch :)
[16:29] <ScottK> DktrKranz: You pinged me about something the other day and weren't around when I got the ping.  Do you remember what it was and if it's still important?
[16:34] <DktrKranz> ScottK: I asked you if build-depend on boost1.37 is good enough or boost1.35 is preferred, libtorrent-rasterbar overwrote your change, so I wanted to be sure everything is fine.
[16:34] <ScottK> DktrKranz: Right.  That was it.
[16:34]  * DktrKranz didn't follow boost stuff
[16:35] <ScottK> DktrKranz: Pretty much everthing is sync'ed up on 1.35 for Jaunty.  IIRC 1.37 and 1.35 are not co-installable, so it could be problematic.  I'd check if they are co-installable and if they are and it built, I think it's fine.
[16:36] <ScottK> Or if the package doesn't carry a runtime dependency, then it's fine too.
[16:36] <savvas> ScottK: I think only the -dev packages aren't co-installable
[16:36] <savvas> as far as I can remember that is :P
[16:36] <ScottK> savvas: OK.  That'd make sense.
[16:36] <DktrKranz> I'll check with some rdependencies once binaries come out NEW, thanks.
[16:38] <savvas> e.g. http://packages.ubuntu.com/jaunty/i386/libboost-filesystem1.35.0/filelist http://packages.ubuntu.com/jaunty/i386/libboost-filesystem1.37.0/filelist
[16:38] <ScottK> savvas: I suspect you are correct.
[16:40] <thekorn> dholbach, hi, good question ;)
[16:40] <Laney> DktrKranz: IIRC I tried it out before I uploaded
[16:41] <DktrKranz> Laney: I asked because my boss is waiting for deluge :)
[16:41] <Laney> heh
[16:41]  * Laney is waiting for miro
[16:42]  * DktrKranz can't use internet, my boss can P2P, weird...
[16:42] <Laney> no internet at work? :O
[16:42] <DktrKranz> no browsing
[16:43] <DktrKranz> we're behind a strong NAT, only ssh is allowed
[16:43] <Laney> heh
[16:43] <Laney> ssh -L...
[16:43] <DktrKranz> and P2P for his machine
[16:43]  * DktrKranz has two choices: bribing him to have deluge working again or find a new boss (and a new job as well)
[16:43] <Laney> good for downloading Linux ISOs right
[16:43] <ScottK> DktrKranz: Tunnel over DNS.
[16:44] <DktrKranz> I'm something like a IT manager, so I can setup a tunnel
[16:44] <DktrKranz> but I need to connect to Belgium to do so, and it can be problematic sometimes
[16:47] <Laney> ScottK: Could you give libtorrent some AA love? No real urgency but it blocks some stuff, notably miro's py2.6 transition
[16:48] <Laney> actually, I'll need an FFe for that anyway
[16:50] <soren> 7win 21
[16:50] <soren> Doh
[16:50] <Laney> your / is near 7?!
[16:50] <Laney> crazy layout
[16:50] <soren> Not just near it. On it.
[16:50] <Nafallo> it is 7 IIRC
[16:50] <Nafallo> :-)
[16:57] <jdong> lol what crazy devices do all y'all use?
[16:57] <soren> Keyboards?
[16:57] <soren> They're all the rage these days.
[17:00] <jdong> ah nvm I see now :)
[17:00] <jdong> excuse my American every-keyboard-is-like-ours mentality :D
[17:16] <savvas> Laney: are you working on miro?
[17:25] <Laney> savvas: yes, see the bug
[17:27] <savvas> ok :)
[17:33] <cristi> i have read some of the motu contributing and packaging documentation/wiki or whatever and i'd like to help out. What should i do? Note that i am in highschool so i have only standard knowledge of cpp and still learning object oriented programming.
[17:43] <cristi> nevermind, i found something
[17:43] <ScottK> cristi: We have several valuable contributors who are high school age, so don't feel that's a barrier.
[17:44] <ScottK> cristi: Generally I advise people to follow their interests and try to work on things that relate to that.
[17:47] <cristi> ScottK: i am applying for computer science this summer so i'm interested in everything computer related
[17:48] <ScottK> Well we have plenty of that.
[17:53] <cristi> ScottK: anyway, since i am only just starting, i am a bit confused. Can you advice me on how to begin doing something useful?
[17:53] <ScottK> I can try.
[17:53] <ScottK> What do you use?  Ubuntu, Kubuntu, Xubuntu, Ubuntu Server ....
[17:53] <ScottK> cristi: ^^
[17:54] <cristi> ScottK: i am using ubuntu 8.04
[17:54] <cristi> ScottK on a laptop
[17:54] <ScottK> OK.  What I'd suggest is look in Launchpad for bugs tagged bitesize that relate to packages you use/are familiar with.
[17:55] <ScottK> That'd give you perhaps some easy targets to start learning with.
[17:55]  * ScottK uses Kubuntu, so I can't help with specifics.
[17:58] <cristi> ScottK: i see, uhm, how do i sort bugs by tags? i simply search 'bitesize' at bug tracking?
[17:58] <ScottK> Yes.
[17:58] <ScottK> Search by tags in advanced search
[17:58] <savvas> bug 340059 patched for python 2.6
[18:02] <geser> savvas: looks good, do you need a sponsor or is somebody else already sponsoring it?
[18:04] <savvas> geser: needs a sponsor :)
[18:04] <savvas> I'm advertising it in here kind of :P
[18:06]  * savvas bbl
[18:10] <geser> savvas: [ubuntu/jaunty] eikazo 0.5.2-4ubuntu1 (Accepted)
[18:19] <cristi> ScottK: if the bug is assigned to someone i guess there is no point in trying to fix it
[18:19] <ScottK> It depends.  I think bugsquad will assign themselves bugs for triage work, so it's not for sure.
[18:20] <ScottK> Also if it's been assigned for a long time, maybe the person has lost interest.
[18:21] <cristi> ScottK: but if i see for status fix released?
[18:21] <ScottK> Then it's fixed and don't worry about it.
[18:40] <LaserJock> is python 2.5 going to still be around for Jaunty?
[18:43] <fabrice_sp_> LaserJock, I think so, but python 2.6 will be the default
[18:43] <LaserJock> but for Universe it should be OK to make an app 2.5-only
[18:44] <RainCT> LaserJock: yep, shouldn't be a problem
[18:47] <lfaraone> What's the chance I could get this in jaunty+1? http://www.vergenet.net/~conrad/scripts/pants.html
[18:47] <lfaraone> (made me burst into laughter)
[19:10] <emgent> hallo
[19:10] <RainCT> tach
[19:37] <TickTockClock> what does copy the packing over into the new source tree mean?
[19:37] <TickTockClock> here:
[19:37] <TickTockClock> https://wiki.ubuntu.com/PackagingGuide/Recipes/PackageUpdate
[19:37] <TickTockClock> packaging
[19:38] <TickTockClock> I used apt-get source.. <package>
[19:38] <TickTockClock> where is it?
[19:38] <RainCT> TickTockClock: the debian/ directory, probably
[19:39] <directhex> copy the debian/ folder from foo-1.0/ to foo-1.2/
[19:39] <TickTockClock> where is that?
[19:39] <RainCT> TickTockClock: inside the directory   apt-get source  gave you
[19:42] <TickTockClock> extract the .gz file?
[19:44] <RainCT> TickTockClock: apt-get source should have done that. If not, run  dpkg-source -x *dsc
[19:45] <TickTockClock> ok
[19:45] <RainCT> TickTockClock: (*that = not extracting the .gz, but extracting the .orig.tar.gz and applying the .diff.gz upon it)
[19:53] <torkel> siretart: can you please extend my membership in the FAI team? It is about to expire
[19:54] <TickTockClock> what if I get the error unrepresentable changes to source?
[19:54] <TickTockClock> is that common
[19:54] <TickTockClock> after running
[19:54] <TickTockClock> debuild -S -sa
[19:55] <maxb> TickTockClock: How serious that is depends on what the unrepresentable change is
[19:56] <TickTockClock> error exit status 1
[19:56] <TickTockClock> umm...
[19:57] <TickTockClock> well, some files were deleted and it took note of some permission changes
[19:57] <blueyed> I want to add a apport hook to virtualbox-ose, to get the output of "dpkg -l | grep virtualbox". How would I pass that to apport.hookutils.command_output (which takes an array for the command)?
[19:58] <maxb> TickTockClock: you need to give more details about what you're trying to do and what errors you're seeing, to enable people to help. What package, what versions, and a pastebin of the exact commands run and output seen
[19:59] <TickTockClock> http://www.pastebin.ca/1356754
[19:59] <TickTockClock> stellarium 10.0->10.1
[20:00] <maxb> You've not updated the debian/changelog. Thus, it's trying to build the source package against the wrong .orig.tar.gz
[20:03] <maxb> blueyed: See the implementation of apport.hookutils.attach_dmesg for an example.
[20:03] <TickTockClock> thanks
[20:03] <TickTockClock> I think I've got it now
[20:06] <blueyed> maxb: thanks.. "['sh', '-c', 'foo | bar']" does the trick.
[20:23] <bdmurray> siretart: as near as I can figure bug 64501 is Fix Released considering ScottK's upload of 0.4.1-3 is that right?
[20:35] <TickTockClock> I have followed the instructions but I keep getting the error secret key not available
[20:35] <TickTockClock> seahorse detects my key
[20:35] <TickTockClock> instructions from here: https://help.ubuntu.com/community/GnuPrivacyGuardHowto
[20:37] <cristi> savvas: hy, uhm i want to help with the python 2.6 packages update, what should i do. (note that i am just a beginner)
[20:38] <TickTockClock> gpg: [stdin]: clearsign failed: secret key not available
[20:40] <directhex> TickTockClock, the most recent entry in debian/changelog is for your exact key?
[20:43] <TickTockClock> my name is the same as the name in the keyring
[20:43] <TickTockClock> and the email
[20:43] <TickTockClock> if that's what you're asking
[20:51] <maxb> TickTockClock: run gpg --list-secret-keys. Check it displays the exact same identity as the debian/changelog
[20:53] <TickTockClock> I had to run sudo gpg --list-secret-keys, but yes
[20:53] <TickTockClock> it lists the same identity
[20:53] <TickTockClock> I had to run sudo because in order to generate the keys I needed root
[21:08] <maxb> TickTockClock: then you're doing it wrong - your keys MOST EMPHATICALLY should be in your user's keyring, not root's
[21:08] <maxb> And that'll be why it can't find the key, I reckon
[21:13] <TickTockClock> ok thanks
[21:13] <TickTockClock> I'll try to fix that
[21:13] <TickTockClock> later
[21:13] <TickTockClock> brb
[21:55] <andol> I have a question about submitting bugs/patches to Debian. Read the wikipage Debian/Bugs and still isn't sure.
[21:56] <andol> Before you submit the bug/patch, do you have to have it confirmed on your own system of Debian unstable, or is a qualifed guess "good enough"?
[21:56] <andol> (In this case I'm thinking of bug #315136 by the way)
[22:03] <nixternal> safe to do python uploads today? need to fix gdal in jaunty and fabrice_sp_ has been nice enough to provide a patch that I am testing now...need this gdal app asap so I can finish some geodjango code and testing :)
[22:10] <siretart> bdmurray: I fail to find any builds of openhackware. as soon as we have binaries in the archive, I'd agree, but I fail to spot them
[22:11] <siretart> torkel: done!
[22:14] <ScottK> bdmurray: I don't see where it ever got built?
[22:15] <ScottK> IIRC it needs manual bootstrapping that no one has ever done.
[22:17] <bdmurray> Wow, so on https://edge.launchpad.net/ubuntu/+source/openhackware/+publishinghistory if the builds portlet is missing that means it hasn't been built?
[22:17] <bdmurray> I mean on the https://edge.launchpad.net/ubuntu/jaunty/+source/openhackware/0.4.1-4 page
[22:33] <siretart> ScottK: last time I asked adam to bootstrap it he refused to do so
[22:34] <ScottK> siretart: I remember.
[22:34] <siretart> ScottK: IIRC lamont suggested to ship a precompiled version uuencoded in the package, which is then installed in the 'clean' target.
[22:34] <siretart> and basically that's what's the bug is about
[22:34] <ScottK> Interesting idea.
[22:34] <soren> I've been mening to do that for a loong time.
[22:34] <soren> siretart: If you do it, I'll send you a great, big hug :)
[22:34] <siretart> it is the approach taken with the palo package
[22:34]  * ScottK leaves it for soren and siretart.
[22:35] <soren> Oh, I just distribute the hugs. :)
[22:36] <siretart> :)
[22:36] <ScottK> siretart: fpc might benifit from some similar thing too.  There's a quite a number of universe packages depwait on fpc getting built.
[22:36] <directhex> isn't uuencoding a terrible workaround?
[22:36] <ScottK> Just in case you were looking for practice.
[22:36] <ScottK> directhex: What would be better?
[22:37] <siretart> ScottK: well, I don't have access to ppc hardware, so I would have to grab the binary from the debian package
[22:37]  * nixternal steps on his eyeball to stop the twitching
[22:37] <directhex> ScottK, if you need a bootstrap binary, why not ship it & document it in README.source?
[22:37] <ScottK> fpc is a problem on all archs, so even doing i386 and amd64 would be a win
[22:37] <siretart> I could possibly even test it using qemu, but I don't have a warm feeling about that
[22:38] <ScottK> siretart: If you upload it and it doesn't work there's no downside risk.
[22:38] <siretart> hm. granted
[22:38] <siretart> I'll think about it, but now need some sleep. good night -see you tomrrow!
[22:38] <ajmitch> night siretart
[22:53] <imbrandon> gnight siretart
[22:54] <imbrandon> hrm precompiled binaries uuencoded and installed on clean, interesting way to bootstrap
[22:54] <imbrandon> :)
[22:55] <directhex> imbrandon, i just don't see how it's better than bootstrap-only binaries in orig :/
[23:03] <directhex> welcome to #ubuntu-motu, please enjoy your stay
[23:04] <bertolo> i am portuguese, 20 years old, student and low level coder (mainly C). how can i contribute ?
[23:39] <mrooney> bertolo: you might want to look at https://wiki.ubuntu.com/ContributeToUbuntu, or some of the links in the topic as well!
[23:40] <bertolo> mrooney, thks
[23:40] <bertolo> i decided to contribute to ubuntu or gnome lol, i only have time for one of them...
[23:40] <bertolo> gnome is the front of the race
[23:41] <bertolo> lol
[23:44] <persia> bertolo, Work done in GNOME will also be seen in Ubuntu, and it's better to do what you like.  If you end up with questions about packaging, or have patches for bugs in older versions of GNOME, we'd be happy to answer any questions.
[23:49] <bertolo> persia my main problem that i am facing is that i am not familiarized with the community.
[23:50] <bertolo> i would like to join a develop team
[23:53] <bertolo> and i love ubuntu so much <3 lol