[00:07] <effie_jayx> hey all
[00:27] <keenken> hey anyone home?
[00:28] <azeem_> Cameron just moved into his new home
[00:29] <hyperair> i thought cameron was a pace
[00:29] <hyperair> place*
[00:30] <keenken> if i wanted to start helping patch, read bugs, etc, where do I go.
[00:38] <kklimonda> keenken: well, if you want to triage on bugs then #ubuntu-bugs is a nice place to start, if you'd rather fix them I guess this channel is a good place.
[00:38] <keenken> triage means?
[00:41] <kklimonda> housekeeping - checking if bugs are reported in a right place, if they have enough informations and if so if they have the right status. sending them upstream (or asking reporters to do it) etc.
[00:44] <kklimonda> slangasek: can we drop delta for quodlibet-plugins now that debian package recommends either brasero or k3b and lastfmsubmitd has been moved to Suggests?
[00:45] <keenken> if i wanted to fix bugs, what would I need to know?
[00:49] <kklimonda> well, first it's good to know a bit about programming - it's good to understand a patch you are applying (or even writing)
[00:51] <kklimonda> then you should know about packaging, bug triaging and how to work with debian and upstream projects
[00:53] <keenken> kklimonda, where could I get a definitive guide or something of that nature(that incoporates all of that)?
[00:53] <keenken> kklimonda, i know a bit of c++
[00:54] <keenken> the rest after that, kklimonda, i'm not sure about.
[00:55] <kklimonda> keenken: see https://wiki.ubuntu.com/ContributeToUbuntu#Contributing%20to%20the%20Universe%20Repository%20%28MOTU%29
=== nixternal is now known as nixternal_droid
=== nixternal_droid is now known as nixternal_htc
=== nixternal_htc is now known as nixternal
=== nobawk is now known as nobawk|away
=== nobawk|away is now known as nobawk
=== gospch_ is now known as gospch
[04:57] <lfaraone> lifeless: in bug 556968, you said that the bug was fixed in 0.5.0 upstream, yet you set the upstream but task to "confirmed". It is in fact fixed, no?
[04:57] <ubottu> Launchpad bug 556968 in bzr-git "bzr branch crashes with "exceptions.TypeError: expected string or buffer" when cloning a git repository (needs upstream cherrypick/backport)" [Critical,Confirmed] https://launchpad.net/bugs/556968
[05:00] <lfaraone> lifeless: re cherrypicking, it appears that the relevant fix is in http://bazaar.launchpad.net/~bzr/bzr-git/trunk/revision/743 if I'm reading the changlog properly.
[05:17] <lifeless> https://bugs.edge.launchpad.net/ubuntu/+source/bzr-git/+bug/556968/comments/3
[05:17] <ubottu> Launchpad bug 556968 in bzr-git "bzr branch crashes with "exceptions.TypeError: expected string or buffer" when cloning a git repository (needs upstream cherrypick/backport)" [Critical,Confirmed]
=== nobawk is now known as nobawk|away
[06:48] <bilalakhtar> Hi MOTUs! Call for sponsorship. Packages are liboauth (http://revu.ubuntuwire.com/p/liboauth ) , python-tweepy (http://revu.ubuntuwire.com/p/python-tweepy ) and gconjugo ( http://revu.ubuntuwire.com/p/gconjugo )
[06:49] <bilalakhtar> Ann of the above packages are lintian-free and test built in maverick chroot with no problem
=== nobawk|away is now known as nobawk
[06:50] <nigelbabu> bilalakhtar: have you thought about getting that to debian?
[06:51] <bilalakhtar> nigelbabu: nope, I put packages into debian after ubuntu
[06:51] <bilalakhtar> I go *the* *long* way
[06:51] <nigelbabu> bilalakhtar: well, if you put it into debian, its comes into ubuntu automatically
[06:51] <bilalakhtar> so that I get credit for both
[06:51] <bilalakhtar> nigelbabu: I know that
[06:52] <nigelbabu> bilalakhtar: actually you get credit for both anyway
[06:52] <nigelbabu> when packages are synced, its still your name that comes on it
[06:52] <bilalakhtar> nigelbabu: but I can't become a motu just by sync requests, can I?
[06:53] <nigelbabu> well, being a motu is not about maintaing a single package
[06:53] <nigelbabu> or 2 or 3 packages
[06:53] <nigelbabu> its about fixing whats broken in universe
[06:54] <nigelbabu> if you want to maintain stuff, its best done in debian and letting it flow downstream (just my take)
[06:54] <nigelbabu> if you want to be motu, you should be working on merges, fixing bugs, fixing rc bugs, etc
[06:54] <bilalakhtar> nigelbabu: thanks for your advice, but I prefer to ring both the bells at the same time and get packages everywhere!
[06:54] <bilalakhtar> I am fixing needs-packaging bugs right now.
[06:54] <nigelbabu> I still dont get it
[06:55] <nigelbabu> if you get your pckage into debian, they end up being everywhere
[06:55] <bilalakhtar> nigelbabu: I know that. Ok, now my question is a different one. Which kind of bugs should we fix? shouldn't the upstream devels fix the,?
[06:56] <bilalakhtar> nigelbabu: you mean we should update packages as soon as bug fixes are released?
[06:57] <nigelbabu> bilalakhtar: depends on the upstream cycle.  if the upstream is going to make a new release soon, you're better off getting the new release in
[06:57] <maco> working upstream is pretty strongly encouraged
[06:57] <nigelbabu> and after that you can backport individual bug fixes
[06:57] <maco> submitting a debdiff to both only really makes sense if it needs to be fixed urgently
[06:57] <bilalakhtar> so thats it. and what are merges? (the last question)
[06:58] <maco> merges are when there's a new version in debian and there are patches in ubuntu and you need to reconcile the differences
[06:58] <bilalakhtar> maco: ok
[06:59] <bilalakhtar> maco: so are you a motu? can you review my packages?
[06:59] <maco> so if theres a -1ubuntu3 and debian puts out a -2, youd merge whatever changes were made from -1 to -1ubuntu3 with the -1 to -2 changes to make -2ubuntu1
[06:59] <bilalakhtar> atleast one of them
[06:59] <bilalakhtar> maco: yeah, got it
[06:59] <maco> yes im a motu but no i cant do any reviews until at least sunday
[07:00] <bilalakhtar> maco: Fine. another question. Can a person become a motu by just merges, bug fixing, package updating and new packaging ?
[07:00] <maco> yes
[07:01] <bilalakhtar> ok, then, so long. bye,guys!
[07:01] <maco> bug fixing and package updating was the bulk of my stuff
[07:01] <maco> only did one new package and one merge before applyin
[07:01] <maco> bah
[07:01] <maco> wouldve also liked to point out that there are enough danged packages already, no need to go adding /more/ to the pile in universe
[07:08] <imbrandon> mornin all
[07:10] <nigelbabu> maco: I wanted to add that part
[07:11] <nigelbabu> maco: the 'fix-the-broken-stuff-before-you-add-more' thing
[07:11] <maco> righto
[07:12] <nigelbabu> well, thanks for joining in
[07:12] <maco> when i said to persia when i first started thinking about motu that i needed to do a few more from-scratch packages on revu, he was like "no! we dont need more work!"
[07:12] <nigelbabu> maco: yeah, he still says that
[07:12] <maco> yep
[07:12] <nigelbabu> and there's still more broken stuff
[07:12] <maco> thats why ive only ever submitted one package to revu :P
[07:12] <nigelbabu> I've never used it
[07:12] <nigelbabu> I've used mentors.debian.org though
[07:13] <maco> and now im co-maintaining it in debian! so thatll get fixed before hitting ubuntu from now on :)
[07:13] <nigelbabu> wow, zach was right.  the trend is for ubuntu devs to become DM/DD
[07:14] <nigelbabu> I need to start my work on gwibber in debian... being procrastinating
[07:17] <Laney> yes! do it!
[07:18] <Laney> there are lots of people offering help but none actually doing it afaics
[07:18] <AnAnt> Hello, is the UDS over yet ?
[07:18] <Laney> last day today
[07:20] <AnAnt> ok
[07:20] <nigelbabu> Laney: yep.  I'm just lazy to partition and install debian
[07:20] <nigelbabu> once I get to it, things will move fast
[07:20] <Laney> you can get very far with a debian chroot
[07:20] <Laney> and the whole way with a vm
[07:20] <nigelbabu> debian chroot isn't that hepful whn you want a dbus thingie I think
[07:21] <nigelbabu> the last time I tried, I didn't have much time to test + gwibber wasn't really rocking then
[07:21] <nigelbabu> so, in a week or so, I'll get back to it
[07:21] <bilalakhtar> nigelbabu: Back. Your nick seems indian. Are you one?
[07:22] <maco> bilalakhtar: i was going to point out when you disappeared that there's plenty of stuff in the archive already that needs fixing. adding *more* packages (and thus more work) isnt really necessary to become a motu
[07:22] <nigelbabu> bilalakhtar: that's a surprise, most of the time folks say my nick seems enlighs.  Yes, I'm indian
[07:22] <maco> nigelbabu: it's the "babu" that sounds indian
[07:23] <maco> i only ever put one package through revu, and that was one that was previously in debian and ubuntu but was removed and i was taking over shepherding it
[07:23] <nigelbabu> maco: oh yeah, I forgot I'm using this nick.  usually, I use the nigelb one.  I'll change after uds
[07:23] <bilalakhtar> maco: You definitely know Indian words. Well, so you mean I should work on merges?
[07:24] <maco> bilalakhtar: at this point in the release cycle, *definitely* merges need doing
[07:24] <bilalakhtar> maco: After merging, should I attach a debdiff?
[07:24] <bilalakhtar> I mean, to the bug? or should I upload the complete package to something like revu?
[07:24] <maco> bilalakhtar: attach the .diff.gz if its a new upstream version (ie the .orig changed)
[07:25] <maco> no, merges dont go to revu
[07:25] <maco> youll know thats the case if 2.3-2ubuntu3 goes to 2.4-1ubuntu1
[07:25] <maco> if the software version number (before the -) stays the same though, then sure, debdiff works
[07:26] <bilalakhtar> maco: What is the difference betweek a debdiff and a diff.gz ?
[07:26] <maco> but! don't forget to use -vFOO where FOO is the last ubuntu version in the debian/changelog, that way it diffs against far enough back
[07:26] <Laney> maco: only the uploader has to do that
[07:26] <Laney> it's for the .changes file
[07:27] <bilalakhtar> Got it. https://wiki.ubuntu.com/PackagingGuide/Recipes/Debdiff
[07:27] <maco> Laney: oh i thought the dsc would need too...
[07:27] <maco> ok
[07:27] <maco> debdiff is a patch of a package and you apply it after youve unpacked the orig.gz and diff.gz
[07:27] <Laney> and you never need to attach the diff.gz for a merge
[07:27] <maco> Laney: um ok i'll bow to you then
[07:27] <nigelbabu> maco: haha
[07:27] <Laney> just diff between the debian and ubuntu versions
[07:27] <maco> ive only ever had to have a sponsor on a merge once, and it was 6 months ago
[07:28] <Laney> :)
[07:28] <Laney> we ask for a .diff.gz when uploading new upstraem versions (ie 0ubuntu1)
[07:28] <Laney> of course there is always UDD these days…
[07:29] <maco> yeah UDD is how i did the last merge for which i lacked upload rights
[07:29] <nigelbabu> yeah, most of dev session went like this
[07:29] <maco> then bzr push lp:~kubuntu-members/amarok
[07:29] <nigelbabu> "we need to update docs" " we need to review patches" and "we need to use UDD more"
[07:29] <bilalakhtar> maco: Check whether I am right :- orig.tar.gz is the upstream tarball, .diff.gz is the debian/ directory diff (this one should be the debian one) and debdiff is the patches to be applied to make the package ubuntu-centric
[07:29] <nigelbabu> Almost all deve related sessions went into that mode at some point
[07:29] <maco> bilalakhtar: debdiff is the changes to be applied in *this specific revision*
[07:30] <maco> bilalakhtar: diff.gz contains all previous revisions as well
[07:30] <bilalakhtar> maco: S=ok
[07:30] <maco> (all kubuntu members can merge to the branches, then the ~kubuntu-dev folks check them and push to the buildds on occasion)
[07:31] <bilalakhtar> maco: In merges, diff.gz  and debdiff will be modified. orig won't be, diff will contain the debdiff changes also. am I right?
[07:31] <maco> depends
[07:32] <maco> if debian got a brand spankin' new version of the software, then ubuntu will need a new .orig.gz
[07:32] <bilalakhtar> maco: Can a merge have changes in the upstream part (outside debian folder) also? yeah, you answered it
[07:33] <Laney> it can, but you should use any patch system that is in place already
[07:33] <bilalakhtar> Laney: you mean quilt? yeah, I know how to use that. I have used it many times
[07:33] <bilalakhtar> QUESTION: Where can I find merges on which I should work?
[07:34] <bilalakhtar> I mean merge requests
[07:34] <maco> heh at uds barcelona i was asked a bunch of times "so when you going to apply to motu?" and my answer was "when i figure out quilt"
[07:34] <Laney> merges.ubuntu.com
[07:34] <maco> http://people.ubuntuwire.com/~lucas/merges.html
[07:35] <maco> bilalakhtar: by the way, see that touched-it-last column on the right of the page i linked? send an email to whomever is listed there letting them know you're doing that merge so they dont start trying to do it after youve already got it covered
[07:36] <bilalakhtar> maco: These are the lp ids of the people?
[07:36] <Laney> you can do any of mine without asking ;)
[07:36] <maco> bilalakhtar: yep
[07:37] <maco> ooh one of my TIL's is the package i'm co-maintaining in debian, and it can just be sync'd
[07:37] <maco> Laney: do i just file a sync request then?
[07:37] <Laney> I think I already did the haskell ones
[07:37] <Laney> maybe not -testpack
[07:37] <bilalakhtar> maco: I didn't understand what does "patch" mean in the third column in this page
[07:38] <bilalakhtar> Laney: What is merges.ubuntu.com for?
[07:38] <bilalakhtar> maco: I find all the patches there. nothing to work for.
[07:38] <Laney> same as that other page, showing outstanding merges
[07:39] <bilalakhtar> What is an "outstanding" merge?
[07:39] <maco> bilalakhtar: not-done-yet
[07:39] <bilalakhtar> maco: But what are the patches for, if the merge isn't done?
[07:39] <maco> bilalakhtar: and patch seems to be showing what's different between the two packages...ie, what you need to resolve
[07:39] <maco> its just a diff of the two
[07:40] <maco> by the way, i think the UDD way of merging works *really* well
[07:40] <maco> hmm
[07:40] <Laney> it looks like the ubuntu delta
[07:40] <maco> james_w: hey how do i get on the list of people who are willing to be spammed about merge requests?
[07:41] <bilalakhtar> maco: Yeah, same question. What does "last uploader" mean? the person who last uploaded the package in ubuntu?
[07:42] <maco> yes
[07:43] <bilalakhtar> maco: See if I am correct: The red merges on this page are packages who have a major version number change (part before -0ubuntu1 ) and white ones have a change after - .
[07:44] <maco> uhh dunno. i havent looked that closely. this is a fairly new page for this
[07:45] <bilalakhtar> maco: Last question: What does UDD mean?
[07:45] <maco> Ubuntu Distributed Development
[07:46] <maco> the new bzr way of making it easy to not-clash when 2 people work on the same package
[07:46] <maco> you can also just push stuff to launchpad and submit a merge request and someone will come along and do the uploady bits
[07:46] <maco> and bzr handles 3-way merges (upstream, debian, ubuntu) like you need for this /really/ well
[07:48] <bilalakhtar> maco: Do people use bazaar for pkg code hosting also? are all the packages having a branch in lp ?
[07:48] <maco> all but about 500 do
[07:49] <bilalakhtar> which are those 500?
[07:49] <maco> i dont have the list memorized ;-)
[07:49] <maco> i know some kde ones are on that list because they're so huge the import times out
[07:49] <bilalakhtar> maco: You could say "new packages", "universe old ones " etx
[07:49] <bilalakhtar> etc
[07:50] <maco> and yes the push is to use bzr for working on packages, but convincing 150 people to stop doing things they way they always have and learn something new is *hard*
[07:50] <maco> theyre fairly random
[07:50] <maco> its not *intentional* that 500 arent done
[07:50] <maco> its just that importing them has thus-far failed
=== nobawk is now known as nobawk|away
=== nobawk|away is now known as nobawk
[08:14] <carstenh> bilalakhtar: the ubuntu changes in topgit are also in debian, so this can be dropped.
=== baddog is now known as Guest37047
[08:30] <imbrandon> maco: heh lots more than 150 i would say
[08:35] <slangasek> kklimonda: I question whether an ORed recommends is correct, but there's no need to carry a delta for that
[08:37] <shadeslayer> are new versions of packages allowed in SRU?
[08:37] <imbrandon> in rare cases minor revisions are
[08:38] <shadeslayer> like kraft recently released a new version 0.4 from their last stable release 0.2,i packaged it in my PPA
[08:38] <imbrandon> sounds like a good -backport canidate not sru, 0.2 to 0.4 likely will be a big jump in code
[08:38] <imbrandon> but you/i would have to look to verify that
[08:39] <shadeslayer> imbrandon: ok,also debian has picked up my package as a base to package their version,so ill wait for it to go into debian,sync to maverick and then do a backport
[08:40] <shadeslayer> debian bug 580718
[08:40] <ubottu> Debian bug 580718 in wnpp "ITP: kraft -- small business-management application" [Wishlist,Open] http://bugs.debian.org/580718
[08:41] <imbrandon> shadeslayer: sounds like a good plan
[08:41] <shadeslayer> :)
[08:41] <shadeslayer> but this really depends on debian.. how long they take to upload it to their archives :P
=== shadeslayer is now known as shadeslayer_
=== shadeslayer_ is now known as shadeslayer
[09:03] <carstenh> bilalakhtar: the ubuntu changes in topgit are also in debian, so this can be dropped.
[09:07] <bilalakhtar> carstenh: yeah? what?
[09:08] <bilalakhtar> carstenh: When did I talk about that?
=== yofel_ is now known as yofel
[10:13] <jetienne> q. how can i recompile a given package ?
[11:08] <Laney> apt-get source foo; apt-get build-dep foo; cd foo-version; debuild
[12:03] <james_w> maco: join the ubuntu-reviews mailing list
=== nobawk is now known as nobawk|away
=== nobawk|away is now known as nobawk
[13:21] <Henk__> Hi guys; I have some questions with launchpad, bazaar and a project with subprojects (core, and large test files)
[13:21] <Henk__> Anybody here able to help me out?
[13:25] <shadeslayer> Henk__: try #launchpad
[13:26] <lfaraone> Currently, we have an application that foo that wraps the application bar, and takes a single argument, a path. We want to pass all excess arguments from foo to bar. Would the appropreate way be "foo PATHTOFILE -- ADDITIONAL_PARAMETERS"?
[13:27] <Henk__> the idea is to focus further development for ubuntu
[13:27] <Henk__> and setup the directories for this
[13:35] <carstenh> lfaraone: i really like this syntax for the necessary separation of arguments for the wrapper and the actual program, but if there is exactly one argument and this will not change there is no need for this explicit separation and it could be done easier: foo path bar_argument_1 bar_argument_2 ...
[13:37] <carstenh> Henk__: you should be more specific if you want anybody to answer. if it is to complex to subsume in a few lines a mailing list might be a better way to communicate and it would also reach more people
[13:37] <lfaraone> carstenh: on further review, it looks like there could be two arguments.
[13:37] <lfaraone> carstenh: and the first argument may be optional.
[13:38] <carstenh> lfaraone: an optional argument sounds like -- might be a sane choice :)
[13:39] <Henk__> carstenh: I am already stuck for a couple of days; reading more docs/wikis/pdfs on the subject brings me not any further; I think I am missing some vital point
[13:40] <carstenh> lfaraone: on the other side, dpkg chooses a different approach and it works quite well, but for this it is required that all options can be unambiguous assigned to one command
[13:43] <lfaraone> Anybody have time to do some straightforward SRU verification on bug 578841?
[13:43] <ubottu> Launchpad bug 578841 in unetbootin "unetbootin should contain the 10.04 LTS as an install option" [Wishlist,Confirmed] https://launchpad.net/bugs/578841
[13:44] <carstenh> Henk__: nobody can help you if you don't ask your question ...
[13:48] <Henk__> I am still puzzling about the directory structures... it is the combination of a group project in launchpad+bazaar (the basis for future inclusion in ubuntu) and a core package and optional large data/test packages to test/checkout the numerics
[13:49] <Henk__> how to set up the local tree? where to init bzr and how about packaging?
[13:50] <Henk__> you do not want to create an .orig.tgz of a 50 MB test data set
[13:52] <Henk__> the way I normally work is to extract a code into a user directory and extract everything there; however following standard guidelines the 3 codes should go to /usr/bin, the doc to /usr/share/somting, where should the test files go?
[13:54] <Henk__> so one should think of the following packages/lauchpad entries => code_x.y.z-all.deb, test_x.y-any.deb, doctex_x.y-any.deb
[13:59] <Henk__> the tests produce files which are included in a (large checkout) pdf with proof of error free code
[14:00] <Henk__> not evrybody will want to do that; but the doc shoul be included in the deb
[14:12] <Henk__> or is there any package which has a similar setup; then I would be able to apt-get the sources...
[14:12] <Henk__> preferable ubuntu native
[14:13] <azeem> Henk__: why is code Arch: all and test Arch: any?
[14:14] <Henk__> code wil be compiled; the tests contain ascii data sets; should work on any arch (incl windows)
[14:14] <azeem> then you got it backwards
[14:15] <Henk__> sorry; please read backwards then azeem :)
[14:15] <azeem> *shrug*
[14:15] <Henk__> pardon me?
[14:16] <Henk__> (just a sec; something urgently to do)
[14:25] <Henk__> (back again)
[14:26] <carstenh> Henk__: -doc packages are commonly named packagename-doc, separation of verification tool and the actualy program seems to be fine
[14:27] <carstenh> Henk__: native packages are debian/ubuntu-specific programs that are not useful on another system, unless you are a debian developer for at least 10 years, those can package their software however they like ;)
[14:27] <Henk__> how do you accomplish that they go into the same packagename directory where tests are under "testdir" and the doc under "docdir"?
[14:28] <azeem> what do you mean with "packagename directory"
[14:28] <Henk__> well I meant by I am developing under ubuntu; so there is no upstream origin
[14:28] <azeem> that has nothing to do with packaging
[14:29] <Henk__> some tarball which comes from a distant source
[14:30] <Henk__> the 3 subpackages will have to be packaged otherwise apt-get will not work
[14:30] <carstenh> there are enough examples of non-native packages where the maintainer is also upstream
[14:30] <Henk__> I am not upstream, I have some ubuntu machines myself
[14:31] <carstenh> Henk__: /usr/share/debhelper/examples (or similar) has an example how to create multiple binary packages from one source package
[14:31] <Henk__> I will peek into it; sec
[14:32] <carstenh> Henk__: and if you are not sure which directories should your files go to you should first try to find the answer by reading the FHS (filesystem hierarchy standard)
[14:33] <Henk__> no I meant my own develpoing file structure needed for launchpad/bazaar
[14:34] <Henk__> the 3 codes can go into /usr/bin
[14:35] <Henk__> the pdfs can go into /usr/share/doc/packagename
[14:35] <carstenh> Henk__: you can change the layout later if you want and you don't need to publish your repository in early stages
[14:35] <azeem> Henk__: what does launchpad/bzr have to do with /usr/bin?
[14:36] <carstenh> so I wouldn't try to find the perfect directory layout before you even start the project
[14:36] <Henk__> I want to start using launchpad/bzr
[14:36] <Henk__> the code is up and running for a couple of years now
[14:36] <Henk__> published with tarballs
[14:37] <Henk__> now is the time to finally start with bazaar
[14:37] <Henk__> and thus with launchpad as well
[14:37] <carstenh> | Bug #337209 in bzr-builddeb: “import-dsc doesn't work against ...
[14:37] <ubottu> Launchpad bug 337209 in bzr-builddeb "import-dsc doesn't work against launchpad URLs" [Medium,Fix released] https://launchpad.net/bugs/337209
[14:37] <carstenh> looks like bzr can import debian source packages
[14:37] <Henk__> when that is all in place then part of std universe is an optiom
[14:39] <carstenh> any reason why packaging it without bzr and then import it using this tool and let the tool developed by experienced bzr users decide which layout to choose?
[14:39] <Henk__> it is not yet debian or any distro format; only tarball with an apache license (which by the way is not suportted by dh_make)
[14:40] <Henk__> I am the developer, and I want start to use bazaar
[14:40] <carstenh> dh_make just creates templates not ready to use packages
[14:40] <Henk__> I know
[14:41] <Henk__> but how to package the test files?
[14:41] <carstenh> how can anything not beeing supported by a bunch of file templates and a tools that copies these around?
[14:41] <Henk__> you do not want to copy them; the package will double to 100 MB for the test files only
[14:42] <carstenh> are these files created during package building or are the distributed by upstream? if so, are they distributed in a different tarball?
[14:42] <Henk__> they will be split
[14:42] <Henk__> the test files are not distributed now
[14:43] <carstenh> and they will be distributed how?
[14:43] <Breaking_Pitt> guys I can't continue and i don't know what to do...can someone provide me some help in tus problem? http://pastie.org/960216
[14:43] <Henk__> but are available on request
[14:43] <carstenh> Henk__: so not in the upstream tarball ... create a different source package
[14:44] <Henk__> they will be now; my ADSL line doesnt like webcrawlers to crawl such big tarballs
[14:45] <Henk__> yes carstenh I concluded that; the way to go for the test files; but how about the optional (large) docs? they can go into .usr/share/doc or local
[14:47] <carstenh> Henk__: i wouldn't split doc and binary into two source packages but into two binary packages
[14:48] <carstenh> Breaking_Pitt: looks like a bug in debhelper or the upstream makefile unless you told it in your rules file tthat it should use the target distclean
[14:49] <carstenh> Breaking_Pitt: let someone check your rules files or try to overwrite the clean target
[14:50] <Breaking_Pitt> my rules file it's a default rules file
[14:50] <Breaking_Pitt> can i pastie it?
[14:50] <carstenh> not in a channel, there are paste sites ...
[14:50] <carstenh> google after override_dh_clean should point you into the right direction
[14:51] <Breaking_Pitt> here is my rules http://pastie.org/960282
[14:51] <Breaking_Pitt> and here is my makefile
[14:52] <Breaking_Pitt> http://pastie.org/960285
[14:54] <carstenh> i don't know why dh runs the distclean target, both look ok.  try asking google what override_dh_clean is and does. i have to go now
[14:54] <carstenh> i hope you can fix your problem :)
[14:55] <Breaking_Pitt> can by setup.py the problem carstenh ?
[14:59] <carstenh> Breaking_Pitt: | If there is a setup.py or Build.PL, it is run to clean the package.
[14:59] <Breaking_Pitt> I have a setup.py
[14:59] <carstenh> Breaking_Pitt: this says the manpage, so yes, it could :)
[14:59] <Henk__> (away for 15 min)
[15:00] <carstenh> Breaking_Pitt: man dh_auto_clean suggests the same solution i told you
[15:01] <Breaking_Pitt> let me see
[15:03] <Breaking_Pitt> I have to use this? override_dh_auto_clean: $(MAKE) packageclean
[15:19] <Breaking_Pitt> carstenh, maybe this can be caused by my debhelper version?
[15:19] <Breaking_Pitt> i have tested the same in the ubuntu vm an dit works correctly
[15:23] <kklimonda> can we update all gnome projects to the newer micro release version (instead of backporting fixes) or is it only for packages in main?
[15:28] <kklimonda> jdong: ^ :)
[15:29] <ari-tczew> kklimonda: do you mean about lucid right?
[15:30] <kklimonda> ari-tczew: lucid and karmic
[15:31] <jdong> kklimonda: depends on how hairy the debdiffs look :)
[15:33] <Henk__> (back again)
[15:34] <Henk__> (still stuck)
[15:35] <Henk__> thnaks for the help; bye
[15:36] <kklimonda> jdong: the one for lucid looks harmless.. the karmic one is bigger (as there were two micro releases) and it touches parts of interface
[15:38] <jdong> lucid one sounds okay then, but the Karmic one might need a closer look
[15:38]  * kklimonda thinks that we should give it a go anyway as the upstream author asked to do that
[15:39] <jdong> if upstream asks to do it, we can certainly evaluate it a bit more closely
[15:39] <kklimonda> he's apparently getting bug reports from ubuntu users :)
[15:39] <kklimonda> mhm, I have diffs ready so I'll upload them to the bug report and give you a link
[15:40] <jdong> ok
[15:40] <jdong> I'll be in and out today, but when you link them I'll certainly give em a look
[15:47] <kklimonda> jdong: lucid patch uploaded at bug 580522
[15:47] <ubottu> Launchpad bug 580522 in hamster-applet "pack bugfix versions of hamster" [Undecided,New] https://launchpad.net/bugs/580522
[15:47] <kklimonda> hmm, maybe I should just attach branch?
=== evilshadeslayer is now known as evilshadeslayer_
[17:20] <carstenh> Breaking_Pitt: the debhelper version is not the problem
[17:20] <Breaking_Pitt> what cause that in ubuntu works and in debian no?
[17:21] <carstenh> Breaking_Pitt: oh, then it is the debhelper version, though the same could happen with the debhelper from debian and another build system
[17:22] <Breaking_Pitt> I think that it's the main reason
[17:22] <Breaking_Pitt> i have tested with unstable in debian
[17:22] <Breaking_Pitt> and it create the package in a correct way
[17:24] <carstenh> this part ofdebhelper is not considered to be working with all upstream build systems, at least according to the man page, but in your case a versioned dependency on debhelper instead of overwriting the clean target is another way to make your package build
[17:24] <Breaking_Pitt> ;) thanks for all
[17:24] <Breaking_Pitt> but still have a lot of doubts
[17:24] <Breaking_Pitt> :(
[17:25] <carstenh> Breaking_Pitt: could also be some python issue, i don't know how setup.py works. which debhelper version do you use under ubuntu?
[17:26] <Breaking_Pitt> 7.4.15
[17:27] <carstenh> Breaking_Pitt: changelog does not look like the different debhelper version could cause this
[17:27] <Breaking_Pitt> i don't know
[17:28] <carstenh> writing a clean target in debian/rules could avoid a lot of headache ;)
[17:28] <carstenh> or you could install the newer debhelper on ubuntu and try ...
[17:30] <Breaking_Pitt> in ubuntu works correctly... in debian no
[17:32] <carstenh> so it fails with the newer debhelpre version. i would really just copy and adapt a clean target from /usr/share/doc/debhelper/examples/
[17:46] <Breaking_Pitt> ok let me see
=== nobawk is now known as nobawk|away
[20:05] <kklimonda> jdong: do you, as a member of sru team, prefer working with branches linked to sru-able bugs or rather with patches attached to bugs?
[20:06] <jdong> kklimonda: I don't have a preference either way :)
[20:07] <kklimonda> jdong: and what is the "right" place to push branches to LP for packages to? lp:~<login>/<distro>/<serie>/<package>/<pocket> looks good?
[20:07] <jdong> kklimonda: that I don't know :)
[20:08] <kklimonda> jdong: I've also pushed branch for karmic part of bug 580522 lp:~kklimonda/hamster-applet/karmic-proposed
[20:08] <ubottu> Launchpad bug 580522 in hamster-applet "pack bugfix versions of hamster" [Undecided,New] https://launchpad.net/bugs/580522
[21:38] <kklimonda> btw, who can verify sru in universe and who can do it in main?
=== apachelogger is now known as electrolysis
=== electrolysis is now known as PyObjectPtr
=== yofel_ is now known as yofel
=== nobawk|away is now known as nobawk