[00:00] I think there's just lots of bugs. [00:00] *sigh* [00:00] this is not a well-managed transition [00:00] Hm, I guess I'd best file a FFe exemption bug before I upload... [00:00] It is not a managed transition at all. [00:01] but why did this happen? [00:01] Why did what happen? [00:02] wgrant: If it's just bugfix then it doesn't need FFe. [00:02] ScottK: It still needs a bug. [00:02] wgrant: It has one. Just mark something in that. [00:02] an unmanaged transition [00:02] ScottK: Thanks. [00:02] Although "Please assign bug reports caused by build failures to me." if doko is offering to fix the world... [00:03] When I've gotten stuck and asked, he's been good about making suggestions. [00:06] 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] maybe I've been spoiled by the mono transition though [00:06] directhex: <3 [00:06] Laney, launchpad blueprint! [00:07] yessum, there was a spec [00:08] Do we even have a list of everything that is broken? [00:08] Is that even possible? [00:08] Depends: python (<< 2.6)? [00:10] That was my initial guess, but I doubt that covers everything. === rgreening_ is now known as rgreening [00:37] Someone who knows python: are these deps right for an application which is incompatible with 2.6? http://pastebin.com/f399506d4 [00:37] repeating python2.5-x, python-x seems weird to me [00:39] Looking [00:40] That seems wrong to me. I think it should be just the -2.5 one. [00:41] 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] when someone on the python team negotiates a breaking transition slot? [00:44] from debian-release [00:45] guhhhhh [00:46] 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] Yes [00:47] but if libs have been transitioned, what happens then? [00:48] is 2.5 still in main & packages build for 2.5 & 2.6? [00:54] well, I removed the 2.5 ones and it works [00:54] 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] Most modules should build for both. [00:59] Would I see a failure anywhere if they weren't? [01:02] If you start python2.5 and import foo works, then foo is built for 2.5. [01:04] OK, they all seem to work [01:04] that's good enough for me [01:04] thanks for your help [01:04] YW [01:08] * ajmitch should not read ubuntu-sounder, too much uninformed ranting at the moment [01:08] ajmitch: Worse than ubuntu-devel even? [01:09] the threads aren't nearly as long as notification bikeshedding [01:09] or fonts vs DPI [01:14] Don't forget update icons. === bdefreese2 is now known as bddebian [02:17] bug 339554 patched! [02:17] Launchpad bug 339554 in gedit-plugins "debian/control: Description shows duplicate lines" [Low,In progress] https://launchpad.net/bugs/339554 [02:20] 3 hours of banging my head against the wall due to sed and escaping characters finally paid off :P [02:25] Ah. A "learning experience". === ember_ is now known as ember [02:26] yes :) [03:03] 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:03] Launchpad bug 237674 in zsi "Please merge python-zsi (2.1~a1-2) (universe) from Debian unstable (main)." [Wishlist,Confirmed] https://launchpad.net/bugs/237674 [03:04] I mean I removed the python-xml dependency, the rest was done upstream heh :) [03:04] 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] aaah I see [03:04] Isn't the Debian maintainer bzed? [03:05] it's registered to debian python modules team [03:05] I've left a comment on the debian bug: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=468622#10 [03:05] Debian bug 468622 in zsi "python-xml removal: please drop/replace (build) dependencies" [Important,Open] [03:06] savvas: I think bzed is usually the uploader. [03:07] I saw the bug (I get all the DPMT bugmail) but going to #debian-python and asking might work better. [03:07] ok :) [03:08] thanks! [03:08] savvas: Most of the people who'd know are European, so this isn't the best time of day. [03:11] ScottK: I know, I'm from Europe too - I'll try later in the afternoon, I have to go :) [03:12] OK. Well you're up late then. [03:12] 4am heh [03:13] I love silence, helps me focus on my studying :) [03:13] but I'll get back on my old time schedule as soon as the university starts again heh [03:14] see ya! [04:10] 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] It's a very different version and some of the options supported are different. [04:14] Depending on the error it may take some reasonably expert assistance (not me) to sort it out. [04:15] http://launchpadlibrarian.net/23623109/buildlog_ubuntu-hardy-i386.libmpd_0.18.0%7Egit090305-0ubuntu3%7Erippsh_FAILEDTOBUILD.txt.gz [04:18] 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. === fabrice_sp__ is now known as fabrice_sp [04:28] Does anybody know to run autogen.sh within rules? I can't figure it out. [04:41] ripps, something like that: post-patches:: debian/stamp-autotools-maintregen-arch [04:41] debian/stamp-autotools-maintregen-arch: [04:41] build-tree/*/autogen.sh [04:43] fabrice_sp: there isn't a cdbs class/rule that handles this already? [04:44] ripps, I'm not an expert of cdbs, but that's what I've found in several packages [04:45] fabrice_sp: Okay, I'll try adding it [04:52] fabrice_sp: debian/rules:9: *** missing separator. Stop. [04:52] I'm not quite sure what you did, so I'm not sure how to fix it. [04:53] ripps: What's on line 9 of debian/rules? [04:53] ScottK: build-tree/*/autogen.sh [04:54] Try a 2nd ":" on the line before. [04:55] ScottK: didn't fix it. Here's the debian/rules: http://paste.ubuntu.com/128612/ [04:57] I'm tired and not tracking very well, but how about a tab before the text on line 9. [04:58] ScottK: omg, that was it. [04:59] ripps: You're welcome. [04:59] Figures, I'd screw up on the most basic level [05:01] well, let's see if pbuilder will run autogen.sh [05:01] I don't know much about that part. [05:02] make: *** [debian/stamp-autotools-maintregen-arch] Error 127 [05:02] /bin/sh: build-tree/*/autogen.sh: not found [05:10] ripps, try with just autogen.sh, without build-tree/* [05:10] fabrcie_sp: actually I'm trying "sh ./autogen" right now [05:10] ok [05:12] Aha! I think it's working [05:20] great! :-) [05:44] 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. === asac_ is now known as asac [06:05] good morning [06:07] Good morning dholbach [06:08] hiya fabrice_sp [06:52] * nixternal hugs dholbach [06:52] * dholbach hugs nixternal back :) [06:53] how is your day so far sir? [06:53] very good very good, I'm slowly waking up ;-) [06:53] how are you doing over there? [06:53] hehe [06:54] flushing out some unicode boogs in my new country script for geo and django [06:54] gotta love Unicode{En,De}coreError :) [06:55] ya, think I finally got my fingers on the one issue....str(foo) to the rescue === azeem_ is now known as azeem [09:18] g'morning [09:40] 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] savvas: i don't think so. [09:57] savvas: if you look at the cdbs stuff, many of them require the same files [09:59] hyperair: https://bugs.edge.launchpad.net/ubuntu/+source/gedit-plugins/+bug/339554/comments/6 [09:59] Ubuntu bug 339554 in gedit-plugins "debian/control: Description shows duplicate lines" [Low,In progress] [10:01] here's the uploaders.mk file: http://paste.ubuntu.com/128673/ [10:03] * hyperair groans [10:03] that's a lot of symbols [10:04] :P [10:05] ...that's one very lazy maintainer. [10:05] s/very/extremely/ [10:05] to automatically generate a list of Uploaders in debian/control [10:05] what is this [10:05] * hyperair headdesks [10:06] well.. I tried to clear it up a bit :) [10:06] heh [10:07] wait, is this file in CDBS? [10:07] as in, is it one of them cdbs includes? [10:07] no wait, it doesn't exist [10:08] https://launchpadlibrarian.net/23156369/gedit-plugins_2.25.3-0ubuntu1.diff.gz [10:08] it has a build dep for cdbs, if that's what you mean [10:09] no, that's not what i meant [10:09] this whatever.mk file [10:09] where did you get it from? [10:09] aaah no, I don't think so :) it's from gnome-pkg-tools [10:11] interesting [10:11] i see [10:11] and DISABLE_UPDATE_UPLOADERS is set [10:12] now, what's the problem? [10:12] if it's the plugin description.... changing the find line in debian/rules should do the trick [10:13] comment out and DISABLE_UPDATE_UPLOADERS and remove -e "s#@GNOME_TEAM@#$(UPLOADERS)#g", uploaders.mk doesn't change @GNOME_TEAM@ [10:14] wait, why are you commenting that out? [10:14] if we don't want to change the uploaders, then we should leave it there right? [10:14] no, we want to change it! uploaders.mk is supposed to do that, isn't it? :) [10:15] @GNOME_TEAM@ should be replaced by the makefile rule in uploaders.mk [10:15] yes.... but there are cases where you might want to change it manually? [10:16] so this is one of those cases? [10:16] i have no idea === bastiao_ is now known as k0p [10:18] 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] good point [10:18] but shouldn't you change as little as possible from debian? [10:19] if what debian has works, then leave it i say =p [10:19] well, I'll send back to debian if it gets approved :) [10:19] aah [10:19] i see [10:19] in that case, by all means, clean it up [10:19] =p [10:19] :P [10:19] ok [10:20] savvas: oho. [10:20] savvas: there is a reason why debian/rules looks like that [10:20] "* Drop superfluous uploaders include." ? :) [10:20] savvas: notice that debian/rules has a sed command which has two -e's [10:21] if you let the uploaders.mk do its job, then do your stuff after that, you're going to clobber [10:21] note: sed blah blah blah control.in > control [10:21] that's how the uploaders.mk handles it first. [10:22] if you do sed -e "custom rule" control.in > control a second time you'll clobber the stuff done by uploaders.mk [10:22] you mean I should try without -e ? [10:22] noooooooooooo [10:22] i'm saying just leave the debian/rules as it is [10:22] 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] DISABLE_UPDATE_UPLOADERS := 1 <-- this is needed so that uploaders.mk does NOT touch debian/control _yet_ [10:23] sed \ [10:23] -e "s#@GNOME_TEAM@#$(UPLOADERS)#g" \ [10:23] -e "$$plugins_desc_script" \ [10:23] debian/control.in > debian/control [10:23] and this... [10:23] handles everything all at once in one sed command [10:23] because handling it in multiple will only have the last change. [10:24] well of course there's the whole option of just using sed -i -e "$$plugin_desc_script" debian/control [10:24] considering that the clean rule from uploaders.mk would have generated a partially complete debian/control already [10:26] ah.. [10:26] now I see!! [10:26] * hyperair nods [10:27] but I think it's better to leave it this way, gives the maintainer more power over control.in changes :P [10:27] hm. anyone on motu-release about? [10:28] yes that's my point [10:28] leave it that way [10:28] hyperair: thanks for the clarification, you've been a big help! :) [10:28] np === _Nicke_ is now known as Nicke [10:30] DktrKranz, poke? [10:31] 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] eMerzh: i'd wait for karmic if i were you ;) [10:34] directhex: pike [10:36] 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] hyperair, yes... but if it could be validated, i would not say no :) [10:36] 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] DktrKranz, and no, i don't know how feasible backporting the replacement rss lib would be [10:40] directhex: mmmh, wasn't that already processed? [10:40] eMerzh: ah i see [10:40] I've seen something on -changes, was it Debian? [10:42] 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] DktrKranz, it's fixed in sid, but it's a major change to switch rendering engine, so definitely needs a FFe [10:42] directhex: so it needs an upgrade due to mono 2.0 [10:44] 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] directhex: sounds good for a pretty straightforward FFe [10:46] i'll test it in a VM, to be certain that there are no obvious regressions [10:48] it's a standalone app, isn't it? [10:49] yes [10:50] so it's good [10:50] it won't be more broken than now [10:54] 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] directhex, One bug is best, as it preserves bug numbers (and the supply is limited). [10:56] directhex: yes please [10:56] old age? :) [10:57] directhex: how was your NEW processing like? Any REJECT(tm)? [10:58] 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] you need a license for the elephant [11:00] :) [11:00] directhex: heh. I was lucky, my two went in without issues \o/ [11:01] DktrKranz, alright for some ¬_¬ [11:01] DktrKranz, 150 or so packages processed, yet they mysteriously ignore package #4 on the list :( [11:07] okay, there we go, bug #339863 filed [11:07] Launchpad bug 339863 in blam "[FFe] Please merge Blam 1.8.6 from Debian Unstable" [Undecided,New] https://launchpad.net/bugs/339863 [11:09] directhex: too hard to review? [11:09] hm? === persia_ is now known as persia === korn_ is now known as c_korn === harrisony is now known as hsny === hsny is now known as harrisony [12:19] DktrKranz: Are you taking care of blam or should I subscribe the uus? [12:19] (exception granted) [12:23] woo [12:26] iulian, have you seen the sexy, sexy progress on the 2.0 transition? Saving precious, precious megabytes from peoples' installations... [12:26] 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] directhex: Hmm, no, unfortunately. I've forgotten to join -mono on OFTC and haven't looked at that wiki page :-( [12:37] iulian, http://wiki.debian.org/Teams/DebianMonoGroup/Mono20TransitionTODO [12:37] 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] Ouh, that's nice. [12:43] once all remaining smerge bugs are closed, then ubuntu is done! [12:44] Um, no. There might be bugs during the testing period :) [12:45] bug 100000 [12:45] Launchpad bug 100000 in malone "There are still too many bug reports" [Undecided,Invalid] https://launchpad.net/bugs/100000 [12:45] :( [12:46] persia, i meant for the mono 2.0 transition ;) [12:47] 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] 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] Despite the JCP, I still basically wait to hear what Sun is planning. [12:48] it would be nice if a java app could have a <100 meg footprint including framework [12:50] Yeah, although the work on -headless seems to be making that possible for server stuff. [12:50] 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] well, your target is about 35-40 meg for tomboy w/ mono, i think ;) [12:51] 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] ehm... true [12:52] which is nicer, the rock or the hard place? [12:53] ... not Java, perhaps. [13:03] iulian: I can manage it this evening, if directhex don't find another sponsor before === Amaranth_ is now known as Amaranth [13:23] DktrKranz: OK. === cr3_ is now known as cr3 [14:06] Heya gang [14:13] Hi bddebian [14:15] Heya geser === thunderstruck is now known as gnomefreak [15:01] Heya bddebian. [15:03] Hi iulian [15:07] anybody know a package that uses python's distutils and debhelper7? [15:07] maybe python-support too? :) [15:07] dholbach: stepic [15:07] I'm trying to figure out what python-django-lint (only in Debian) FTBFS in Ubuntu [15:07] ScottK: thanks - I'll check it out [15:08] 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] it seems to install what's in setup.py's scripts' list into usr/local and dh_usrlocal explodes [15:08] You need to patch around the ez_install stuff. [15:09] it does not use ez_install AFAICS [15:09] Oh. OK. [15:09] Nevermindthen. [15:09] just the regular distutils..core [15:09] ok - I'll have a poke at it [15:09] seems like a useful tool [15:09] dholbach: Then it probaby needs the install layout=deb magic [15:09] ah! [15:09] I'll look up the exact syntax [15:09] * dholbach will try it [15:10] dholbach: setup.py install --install-layout=deb [15:10] Adding the --install-layout=deb is likely the missing bit. [15:10] gracias, now I'll see how to marry that with debhelper7 :) [15:14] patch debhelper so other python packages benefit from it too [15:15] geser: I'd rather leave that to somebody who's a bit cleverer than I am... like doko [15:15] ... and understands the bigger python picture than I do [15:16] cdbs was patched to include --install-layout=deb by default when calling setup.py install but apparently not debhelper [16:08] dholbach: does it makes sense to have circular dependencies? because debian ldtp package just introduced one [16:08] ara: They matter a lot less for Debian (due to doing binary uploads) than to Ubuntu. We want to avoid those. [16:09] ara: why is it necessary there? [16:10] 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] dholbach: they have just make ldtp depend on python-ldtp. but python-ldtp was already depending on ldtp [16:10] ara: could it be easily moved to the other package (with added conflicts/replaces to the old version)? [16:11] hum.... as far as I can tell the new ldtp does not depends on python-ldtp? (1.5.0-1 in Debian) [16:12] 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] dholbach: yes, it is in debian only [16:12] dholbach: ldtp (1.5.0-2) unstable; urgency=low [16:12] . [16:12] * debian/control: [16:12] + ldtp now depends on python-ldtp package, [16:12] Thanks to Ben Pfaff (Closes: #518902) [16:12] ah, ok [16:13] dholbach: but it will be in karmic, eventually ;-) [16:15] it'd be nice if the circular dependency could be avoided :-/ [16:18] dholbach: OK. I will put it on my to do list. I will try to get debian fixed before auto-sync [16:19] 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] dholbach: cool, I didn't know that one ;-) [16:20] yeah, it makes life a bit easier for us :) [16:22] c_korn, thekorn: heya - this is something I wanted to ask for a long time already... are you guys related? :) [16:22] dholbach: not that I knew [16:23] anyway... great having two Korns here who are doing a good job :) [16:23] heh [16:23] * ScottK hands some ksh to dholbach for completeness. [16:24] ScottK: ksh? [16:24] ahh ok [16:24] Korn Shell. [16:24] * dholbach is getting a bit slow already :) [16:24] 6:00 maybe was too early :) [16:26] dholbach: well, I am not even a MOTU, but thanks [16:27] 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] keep up the good work [16:27] dholbach: or your coffee wasn't strong enough. I'll borrow you my "moka" :) [16:28] DktrKranz: thanks a bunch :) [16:29] 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? === dholbach_ is now known as dholbach [16:34] 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] DktrKranz: Right. That was it. [16:34] * DktrKranz didn't follow boost stuff [16:35] 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] Or if the package doesn't carry a runtime dependency, then it's fine too. [16:36] ScottK: I think only the -dev packages aren't co-installable [16:36] as far as I can remember that is :P [16:36] savvas: OK. That'd make sense. [16:36] I'll check with some rdependencies once binaries come out NEW, thanks. [16:38] 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] savvas: I suspect you are correct. [16:40] dholbach, hi, good question ;) [16:40] DktrKranz: IIRC I tried it out before I uploaded [16:41] Laney: I asked because my boss is waiting for deluge :) [16:41] heh [16:41] * Laney is waiting for miro [16:42] * DktrKranz can't use internet, my boss can P2P, weird... [16:42] no internet at work? :O [16:42] no browsing [16:43] we're behind a strong NAT, only ssh is allowed [16:43] heh [16:43] ssh -L... [16:43] 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] good for downloading Linux ISOs right [16:43] DktrKranz: Tunnel over DNS. [16:44] I'm something like a IT manager, so I can setup a tunnel [16:44] but I need to connect to Belgium to do so, and it can be problematic sometimes [16:47] ScottK: Could you give libtorrent some AA love? No real urgency but it blocks some stuff, notably miro's py2.6 transition [16:48] actually, I'll need an FFe for that anyway [16:50] 7win 21 [16:50] Doh [16:50] your / is near 7?! [16:50] crazy layout [16:50] Not just near it. On it. [16:50] it is 7 IIRC [16:50] :-) [16:57] lol what crazy devices do all y'all use? [16:57] Keyboards? [16:57] They're all the rage these days. [17:00] ah nvm I see now :) [17:00] excuse my American every-keyboard-is-like-ours mentality :D [17:16] Laney: are you working on miro? === bdrung_ is now known as bdrung [17:25] savvas: yes, see the bug [17:27] ok :) [17:33] 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] nevermind, i found something [17:43] cristi: We have several valuable contributors who are high school age, so don't feel that's a barrier. [17:44] cristi: Generally I advise people to follow their interests and try to work on things that relate to that. [17:47] ScottK: i am applying for computer science this summer so i'm interested in everything computer related [17:48] Well we have plenty of that. [17:53] 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] I can try. [17:53] What do you use? Ubuntu, Kubuntu, Xubuntu, Ubuntu Server .... [17:53] cristi: ^^ [17:54] ScottK: i am using ubuntu 8.04 [17:54] ScottK on a laptop [17:54] OK. What I'd suggest is look in Launchpad for bugs tagged bitesize that relate to packages you use/are familiar with. [17:55] That'd give you perhaps some easy targets to start learning with. [17:55] * ScottK uses Kubuntu, so I can't help with specifics. === x-spec-t is now known as Spec [17:58] ScottK: i see, uhm, how do i sort bugs by tags? i simply search 'bitesize' at bug tracking? [17:58] Yes. [17:58] Search by tags in advanced search [17:58] bug 340059 patched for python 2.6 [17:58] Launchpad bug 340059 in eikazo "eikazo: Depends: python (< 2.6) but 2.6.1-0ubuntu3 is to be installed" [Undecided,In progress] https://launchpad.net/bugs/340059 [18:02] savvas: looks good, do you need a sponsor or is somebody else already sponsoring it? [18:04] geser: needs a sponsor :) [18:04] I'm advertising it in here kind of :P [18:06] * savvas bbl [18:10] savvas: [ubuntu/jaunty] eikazo 0.5.2-4ubuntu1 (Accepted) [18:19] ScottK: if the bug is assigned to someone i guess there is no point in trying to fix it [18:19] It depends. I think bugsquad will assign themselves bugs for triage work, so it's not for sure. [18:20] Also if it's been assigned for a long time, maybe the person has lost interest. [18:21] ScottK: but if i see for status fix released? [18:21] Then it's fixed and don't worry about it. [18:40] is python 2.5 going to still be around for Jaunty? [18:43] LaserJock, I think so, but python 2.6 will be the default [18:43] but for Universe it should be OK to make an app 2.5-only [18:44] LaserJock: yep, shouldn't be a problem === Mez_ is now known as Mez [18:47] What's the chance I could get this in jaunty+1? http://www.vergenet.net/~conrad/scripts/pants.html [18:47] (made me burst into laughter) === fta_ is now known as fta === Zarel__ is now known as Zarel === erhesrhsrtb54vyh is now known as Elbrus [19:10] hallo [19:10] tach [19:37] what does copy the packing over into the new source tree mean? [19:37]