=== Zhenech_ is now known as Zhenech
[07:28] <gaurava> hey all ..I created my first patch for the ubuntu and uploaded the same @ <https://bugs.launchpad.net/ubuntu/+source/cgal/+bug/675204>
[07:29] <gaurava> Now, I got some feedback from the reviewer... but some of the things are still not clear to me
[07:29] <gaurava> so can any one help me out in figuring out those points ?
[07:29] <ebroder> gaurava: Which ones are you confused about?
[07:30] <gaurava> hey ebroader, reviewer told me to upload the package to the current ubuntu development ..
[07:30] <gaurava> but I am not sue ...whether I have the permission for the same or not?
[07:31] <ebroder> gaurava: What he means is that in the first line of your changelog, it said "maverick", but it needs to have the current development release
[07:31] <gaurava> oh ok
[07:32] <gaurava> secondly about forwarding the patch to debian using submittodebian ..
[07:33] <ebroder> gaurava: Yeah? What's not clear to you?
[07:33] <gaurava> when I run the same command, I got the diff containing the changes (excluding changelog file), but it still displays the changes of control file..
[07:34] <gaurava> but I guess that is not needed .. am I right?
[07:35] <ebroder> Yes, that's right. You shouldn't include the debian/control changes
[07:35] <ebroder> I'm not sure I see any way to keep submittodebian from including that
[07:35] <ebroder> You could file a bug against ubuntu-dev-tools about that. But in the mean time, I'd probably just undo the change by hand
[07:36] <gaurava> ok ..
[07:36] <gaurava> now, once I saved the diff-file .. submittodebian is prompting me this :
[07:36] <micahg> ebroder: if it specifically excluded maintainer changes in d/control that might work
[07:36] <gaurava> Outstanding bugs -- Wishlist items; Will Not Fix (1 bug)
[07:36] <gaurava>   1) #466284  Adding documentation
[07:36] <gaurava> (1-1/1) Is the bug you found listed above [y|N|b|m|r|q|s|f|?]?
[07:37] <gaurava> may be .. i will give it(submittodebian) a try ..
[07:37] <ebroder> micahg: Right, you'd have to have some intelligence
[07:37]  * micahg tries too  :)
[07:38] <gaurava> now .. back to the submittodebian prompt..
[07:38] <gaurava> this bug is not the same , so I opted for the N option ..
[07:43] <gaurava> now after putting the bug subject and the mentioning the severity, it opens  a file containing all the information in the mail format..
[07:43] <gaurava> so is this it .. to do i need to do anything else also?
[07:46] <gaurava> ny 1 here?
[07:47] <micahg> gaurava: if it looks good, go ahead and send it
[07:47] <gaurava> ok .. thanks ..
[07:47] <micahg> gaurava: the email view is a chance for you to look it over
[07:48] <gaurava> now some of the feedback that I have w.r.t my first experience .
[07:48] <micahg> gaurava: go for it
[07:49] <gaurava> just a min
[07:51] <gaurava> downloading the source, creating a patch file is well documented ..
[07:51] <gaurava> but I dont find uploading procedure smooth ..
[07:52] <gaurava> like what tag to apply, to whom to subscribe after applying the patch .. what different tag means in the bug report
[07:53] <gaurava> may be I am missing any wiki page link over here. .
[07:53] <gaurava> but support from this channel is really good .. so that makes it up I guess
[07:54] <micahg> gaurava: https://wiki.ubuntu.com/Bugs/Tags https://wiki.ubuntu.com/SponsorshipProcess
[07:57] <gaurava> ok these links provides some of the information, that I was looking for when uploading a patch ..
[07:58] <gaurava> Also, I found that there are two approaches given in the wiki webpages w.r.t creating a patch and applying it over ..
[07:59] <gaurava> one by using the apt-get source, modifying the source code and then creating the diff using debdiff (traditional approach, I guess) and other is to use bzr for doing the same
[07:59] <micahg> gaurava: yes, development is moving towards bzr, but we're not there yet with all the source packages
[08:00] <gaurava> Can a newbie use the bzr mechanism ? What I mean ..is can a newbie upload and commit the changes from his/her account ?
[08:01] <micahg> gaurava: no, but you can propose a merge
[08:01] <micahg> gaurava: https://wiki.ubuntu.com/DistributedDevelopment
=== Nigel is now known as G
[08:02] <gaurava> ok .. I will go through this link ..
[08:03] <gaurava> Now, third step(in some cases) is to send your changes to the Debian/Upstream team ..
[08:04] <gaurava> sendtodebian is really a nice tool that makes this task very easy .. but currently it is not resolving the dependency automatically
[08:05] <gaurava> I dont have the reporttubug and sendmail installed on my system ..
[08:05] <gaurava> reportbug is indicated by the tool initially .. so its fine
[08:06] <gaurava> but sendmail comes into the picture at the last moment... so I guess it is better, to put these packets into sendtodebian dependency list
[08:07] <gaurava> this way, one dont need to install these packages independently as per the apt-get norms :)
[08:07]  * micahg thought u-d-t referenced an mta somwhere
[08:07] <ebroder> gaurava: The ubuntu-dev-tools package has a *lot* of tools with a *lot* of dependencies. Since you probably will never use all of the tools, the decision was made to not depend on all of the dependencies of all of the tools
[08:08] <ebroder> But instead they should check at startup-time for the dependencies they need
[08:08] <micahg> oh, it's through devscripts (Recommends: bsd-mailx | mailx)
=== hannesw_ is now known as hannesw
[08:13] <gaurava> ok .. i can see, its not submittodebian that is using the MTA functionality but its reportbug
[08:14] <gaurava> and AFAIR, it didn't check for the MTA dependency in the starting ..
=== bilalakhtar is now known as bilal_
=== bilal_ is now known as bilalakhtar
[11:08] <c2tarun> hey i was reading packaging guide on wiki.ubuntu. i m stuck at few things. first thing in that tutorial they told us about various available tools for packaging. but there internal working and working of package is not clearly mentioned. second they are not asking us to take a look at the source code, is it possible to pack an application without knowing its coding???
[11:09] <c2tarun> please help
[11:09] <ulysses> You have to know only if it compiles:)
[11:12] <c2tarun> what exactly we mean by packaging, in packaging tutorial we just created debian directory by dh_make command then edited few files. then debuild them and further more... is this complete packaging??? :( i thought packaging was about create setup of various applications by there source code...?? please correct me if i m wrong
[11:17] <c2tarun> please reply
[11:19] <ulysses> something like
[11:20] <c2tarun> what exactly will be our contribution via packaging.
[11:21] <ari-tczew> c2tarun: e.g. merging from Debian
[11:22] <ari-tczew> you don't need to pack from scratch new package to start contribution
[11:23] <c2tarun> sorry not getting exactly :(  is it that people are going to create source code of various applications and give that to us so that we can package and upload??? if possible can anyone please give me one example of his/her contribution via packaging.
[11:24] <ulysses> https://launchpad.net/~ulysses/+related-software
[11:25] <ari-tczew> c2tarun: packages which you install day-to-day are .deb files. these are called binaries.
[11:25] <ari-tczew> but binaries have been build from source
[11:25] <ari-tczew> we manage source files
[11:25] <ari-tczew> we use tools like debuild, pbuilder and other
[11:30] <c2tarun> please reply
[11:32] <c2tarun> aro-tczew: ya exactly thats something i wanted to ask, what managing you all do.. is it making appropriate changes to the source code and alter its functioning in a better way??
[11:33] <c2tarun> ari-tczew: ya exactly thats something i wanted to ask, what managing you all do.. is it making appropriate changes to the source code and alter its functioning in a better way??
[11:35] <kklimonda> c2tarun: no, we just take what upstrem developers write and put it into nice packages we deliver to our users.
[11:35] <c2tarun> ok, from where do u get developers write??
[11:36] <kklimonda> almost every project have a site when source code is put on
[11:37] <ari-tczew> we take source tarball from upstream website and pack it with Ubuntu policy
[11:37] <c2tarun> ok
[11:39] <c2tarun> it means a open source code project has its website, this website has project's source code. you take source code from there and pack them according to ubuntu policy and deliver them to ubuntu users. it means packaging is different for different operating systems. its just what we call it for ubuntu???
[11:43] <kklimonda> more or less
[11:44] <c2tarun> sorry... please correct me if i m wrong
[11:47] <kklimonda> c2tarun: other operating systems are out of scope, but if by that you meant other distributions then you are right. I don't know what "its just what we call it for ubuntu???" mean.
[11:49] <c2tarun> ok thanks a lot... thats what i needed for now :)
[11:52] <c2tarun> i was going through this tutorial https://wiki.ubuntu.com/PackagingGuide/Recipes/PackageUpdate  and at step six of method i got this error http://paste.ubuntu.com/534858/
[11:52] <c2tarun> can anybody tell why i m getting this error :(
[11:53] <kklimonda> you didn't do step 4
[11:53] <ari-tczew> c2tarun: sudo apt-get install debhelper cdbs
[11:54] <gaurava> can anyone tell me what is the usecase of debian/control.in file
[11:55] <kklimonda> gaurava: it's a file that is being preprocessed (during the clean phase) to generate final debian/control
[11:56] <kklimonda> gaurava: it's used by some debian teams to, for example, keep Uploaders field up to date.
[11:59] <gaurava> ok .. actually I am looking at the nvidea package content and it contains both control.in and control file
[12:00] <kklimonda> yes, they are both shipped and you edit control.in
[12:02] <gaurava> ok is this like a configure.in file .. i just need to the change the XXXX.in file, during processing of the packet, other(resultant) file will automatically gets the changes
[12:03] <kklimonda> it will most likely get updated when you run debuild -S (or similar command that results in the new source package)
[12:03] <gaurava> ok thanks alot .. will give it a try
=== yofel_ is now known as yofel
[14:03] <c2tarun> hi .. i was going to the recipes on this page.  https://wiki.ubuntu.com/PackagingGuide/Recipes/PackageUpdate   in step 7 on the place of brasero_0.6.1-0ubuntu1.dsc   i m getting this    brasero_0.5.2-0ubuntu2.dsc  why so??
[14:07] <c2tarun> hi .. i was going to the recipes on this page.  https://wiki.ubuntu.com/PackagingGuide/Recipes/PackageUpdate   in step 7 of methods on the place of brasero_0.6.1-0ubuntu1.dsc   i m getting this    brasero_0.5.2-0ubuntu2.dsc  why so??
[14:09] <kklimonda> c2tarun: you don't have to repeat yourself.
[14:10] <c2tarun> sorry i forgot to mention i was on step 7 of which process :(
[14:10] <kklimonda> also, don't ask the same questions on multiple channels at the same time.
[14:10] <c2tarun> i m sorry again, i posted there by mistake
[14:11] <kklimonda> patience is a virtue, especially on weekends.
[14:11] <c2tarun> sorry :(
[14:18] <bdrung> geser: will you fix more u-d-t bugs?
[14:19] <geser> bdrung: why?
[14:20] <bdrung> geser: i may upload u-d-t
[14:21] <geser> bdrung: then go, I don't have any commits planned for u-d-t
[14:24] <coolbhavi> How much time does it take to receive acknowledgement mail when we forward via submittodebian?
[14:25] <coolbhavi> I am using gmail
[14:25] <kklimonda> coolbhavi: depends - give it at least quater of the hour
[14:26] <bdrung> BlackZ: around?
[14:26] <coolbhavi> kklimonda, Its almost a hour and I didnt see any notification yet so asked
[14:27] <kklimonda> coolbhavi: that's why it's a good idea to CC emails to yourself :)
[14:27] <kklimonda> otherwise you will be wondering whether it was sent or did you break something :)
[14:27] <coolbhavi> haha okay :)
[14:27] <kklimonda> coolbhavi: an hour seems excessive but I do remember at least one situation when it took longer than that.
[14:27] <ari-tczew> coolbhavi: do you like using submittodebian? for me this script has got too many questions.
[14:28] <BlackZ> hi bdrung, yes
[14:28] <bdrung> BlackZ: can you give me an updated list of sponsored bugs?
[14:29] <coolbhavi> ari-tczew, I better use the mail system itself then .. but I'll wait n see
[14:29] <BlackZ> bdrung: will send you an e-mail in ~10 minutes
[14:29] <bdrung> thanks
[14:29] <bdrung> BlackZ: or you can paste it somewhere
[14:30] <ari-tczew> coolbhavi: I also use mail instead script
[14:30] <coolbhavi> hmm
[14:30] <ari-tczew> coolbhavi: for me I usually got answer from BTS 5 minutes from request
[14:30] <coolbhavi> okay
[14:32] <coolbhavi> hey BlackZ all the best mate for your application :)
[14:32] <kklimonda> ari-tczew: you can create ~/.reportbugrc and disable some of those questions (like, for example, querying bts)
[14:32] <BlackZ> bdrung: done
[14:32] <BlackZ> coolbhavi: thanks
[14:32] <ari-tczew> kklimonda: not needed. I'm get used to mail.
[14:33] <bdrung> BlackZ: paste somewhere, but not in irc ;)
[14:33] <bdrung> but thanks
[14:33] <ari-tczew> coolbhavi: are you going to update your merges in main?
[14:33] <ari-tczew> some cases are commented like "please don't touch"
[14:33] <bilalakhtar> BlackZ: All the best for becoming a core-dev!
[14:33] <coolbhavi> ari-tczew, yes on them now :)
[14:33] <BlackZ> bdrung: huh, I'm sure you received that list btw :)
[14:34] <coolbhavi> and kklimonda isn't the default script functionality enough?
[14:34] <BlackZ> thanks bilalakhtar
[14:35] <kklimonda> coolbhavi: it's even too much - ari-tczew don't want to query bts because it takes too much time.
[14:36] <ari-tczew> kklimonda, coolbhavi: I send mail from evolution with following template: http://paste.ubuntu.com/534898/
[14:37] <ari-tczew> including patch as attachment
[14:37] <ari-tczew> work done in 2-3 minutes instead answering to submittodebian 15 minutes and milion questions
[14:38] <coolbhavi> ari-tczew, kklimonda hmm thanks for your views :)
[14:48] <mdeslaur> ari-tczew: you should add this to your email template: "Usertags: origin-ubuntu natty ubuntu-patch"
[14:49] <mdeslaur> ari-tczew: that's how debian and ubuntu track which patches came from ubuntu
[14:49] <mdeslaur> (it's what submittodebian does)
[15:09] <bdrung> BlackZ: you have my endorsement now
[15:11] <BlackZ> bdrung: thanks!
[15:26] <ari-tczew> mdeslaur: added.
[18:58] <micahg> shouldn't fakesync versions be DEBIAN_VERSIONfakesyncX?
[18:59] <ari-tczew> micahg: -1fakesync1
[18:59] <ari-tczew> what's your case?
[19:00] <micahg> not my case, just watching the changes (exo)
[19:05] <hyperair> micahg: is it necessary to bump the version?
[19:05] <hyperair> micahg: sometimes i fakesync without bumping the version, as long as i'm sure the package is identical.
[19:06] <ari-tczew> Rhonda: to be clear: I'm only asking for curiosity. I won't cry if I'll be banished.
[19:07] <Rhonda> It never was about you getting banished. It was about getting you to understand that the CoC isn't arbitrary and the amount of contributions aren't a reason to excuse ignorance in that respect.
[19:07] <micahg> hyperair: well, this was a new upstream version, so I'm not sure what the issue was
[19:07]  * micahg will send an e-mail to -devel ML about it
[19:07] <mr_pouit> micahg: no change from debian, but not uploaded to debian yet…
[19:08] <hyperair> mr_pouit: then use 0ubuntu1.
[19:08] <hyperair> mr_pouit: if you really can't wait.
[19:08] <Rhonda> And actually abusing this channel for testing, especially when several people told you that it's not the best idea to do it in here, isn't very friendly neither.
[19:08] <micahg> mr_pouit: right, so it should either be 0ubuntu1 or -1 if the same tarball as Debian
[19:08] <mr_pouit> hyperair: I can't wait, it won't be uploaded before the release, and needs to go through new
[19:09] <hyperair> micahg: not quite correct. the tarball should always be the same as Debian, what matters is that the source package uploaded to debian and ubuntu are identical if they have the same version number.
[19:09] <mr_pouit> (and I already use -0ubuntu1 for the ones that have ubuntu changes)
[19:09] <micahg> mr_pouit: there's experimental for new upstreams in Debian and if there's a VCS tag to base the release from, people will upload simultenously to Ubuntu and Debian
[19:09] <hyperair> mr_pouit: yeah, so if it can't wait, use 0ubuntu1. it's used for things like this.
[19:09] <micahg> hyperair: yeah, I realized I didn't finish the thought, sorry
=== hanska is now known as dapal
[19:10] <hyperair> micahg: mind if i pm you for a bit?
[19:10] <micahg> hyperair: sure
[19:10] <micahg> hyperair: or rather, I don't mind :)
[19:10] <hyperair> =)
[19:11] <ScottK> hyperair: It's not just that the packages are identical.
[19:11] <ebroder> micahg: I'm a little confused about the error you posted on bug #671358. Are you, you know, sure you had the orig tarball unpacked?
[19:11] <ubottu> Launchpad bug 671358 in mame (Ubuntu) "[upgrade] New upstream release 0.140" [Wishlist,Confirmed] https://launchpad.net/bugs/671358
[19:11] <mr_pouit> micahg: why would people upload simulatenously?
[19:11] <mr_pouit> micahg: as soon as squeeze is released, everything will be synced
[19:11] <ebroder> micahg: Because it doesn't use autogoo or anything, so there's just a makefile in the top-level, with a hard-coded clean target
[19:11] <micahg> ebroder: that might be where I messed up, but if that's the case, the rules file should be fixed to take care of that I would think
[19:11] <hyperair> ScottK: the tarball has to be identical, the debian.tar.gz/diff.gz should be identical, and the dsc should also be identical, where identical = same checksum.
[19:12] <hyperair> ScottK: that enough for you? =p
[19:12] <ScottK> hyperair: No.
[19:12] <micahg> mr_pouit: because they want to stay in sync with Debian
[19:12] <ScottK> You also want a .changes that indicates origin in Debian.
[19:12] <hyperair> ah
[19:12] <micahg> mr_pouit: then they don't have to worry about clearning NEW
[19:12] <ScottK> The syncpackage script will do this.
[19:12] <hyperair> ScottK: i didn't know that, i just used syncpackage.
[19:12] <ScottK> That's what syncpackage does.
[19:13] <mr_pouit> micahg: no, if they want to stay in sync with debian, they sync =]
[19:13] <ebroder> micahg: debuild will run if you only have a debian/ directory and no source, but I don't think the rules file needs to detect if you've done that
[19:13] <mr_pouit> (they don't upload both)
[19:13] <ScottK> It might be instructive to diff a .changes made with dpkg-buildpackage and one made with syncpackage.
[19:13] <micahg> mr_pouit: squeeze might not release for another 3 months, people don't want to wait, so they'll upload to experimental and Ubuntu off the same tag
[19:13] <hyperair> ScottK: hmm yeah you're right.
[19:13] <micahg> mr_pouit: ask bdrung
[19:13] <hyperair> ScottK: i just viewed the source of the old syncpackage from pitti.
[19:13] <ebroder> micahg: Unless you're saying that the get-orig-source target should unpack as well, which I could almost see
[19:14] <mr_pouit> micahg: I'm also a member of the debian pkg-xfce team, so I know they won't upload soon…
[19:14] <micahg> ebroder: I believe the source was in teh right place, I'll check again
[19:14] <ebroder> OOC, I saw that there's a syncSource request in the LP API. Is it just not hooked up?
[19:14] <hyperair> ebroder: the policy manual stated that get-orig-source should only create a tarball and dump it into the current directory though.
[19:14] <ebroder> mr_pouit: Could you ask them to upload to experimental?
[19:15] <micahg> mr_pouit: right, so 0ubuntu1 might be better in this case, you might want to consider having and ubuntu branch in the pkg-xfce git tree, pkg-multimedia does this
[19:15] <mr_pouit> micahg: svn =)
[19:15] <mr_pouit> otherwise I would have done that a long ago :p
[19:16] <micahg> mr_pouit: oh, ok, so yeah, 0ubuntu1 is probably better if Debian won't release any time soon
[19:16] <micahg> and experimental is not an option
[19:17] <mr_pouit> it's an option, but after squeeze (because the dd is currently busy with other squeeze-related things, such as desktop-base and the artwork)
[19:17] <micahg> mr_pouit: ok
[19:31] <ari-tczew> mr_pouit: could you sponsor something for me @main?
[19:36] <mr_pouit> ari-tczew: if it's not under the umbrella of a team (-desktop, -server, etc.), yeah, why not
[19:36] <ari-tczew> mr_pouit: then not, because it's desktop team's related
[19:39] <mr_pouit> I don't use gnome at all, so I prefer not to touch :P
[19:41] <Rhonda> ari-tczew: Just out of curiosity, did you read my two messages? No need to comment on it, I just want to be sure you've seen them.
[19:41] <ari-tczew> Rhonda: [20:08] <Rhonda> And actually abusing this channel for testing,   this one?
[19:44] <Rhonda> And the one before, yes.
[20:14] <ScottK> Rhonda: I've had disagreements with ari-tczew about how he behaves here (and continue to not be very happy about some things), but I haven't complained to the CC about him.
[20:15] <Rhonda> I never did say so. I just know that you were waiting for a chat with him which to my understanding never happened.
[20:15] <ScottK> I see.
[20:16] <ScottK> I generally don't make a habit of announcing negative feedback I give people.  So I'm not sure exactly what that refers to.
[20:16] <ari-tczew> very interesting, yes
[20:17] <ari-tczew> Rhonda: dholbach got in touch with me some time ago
[20:22] <mr_pouit> hyperair: micahg: okay, I put -0ubuntu1 for the next upload, so it should be fine (but if a random motu decides to merge it instead of syncing it, without checking, I'm going to regret =))
[20:22] <hyperair> mr_pouit: any responsible motu who attempts to merge it will spot that there is no delta.
[20:22] <ScottK> mr_pouit: If a random MOTU is touching XFCE packages without checking with you, then I think we should give them cause to regret.
[20:22] <hyperair> mr_pouit: so i don't think that would be a problem, right?
[20:26] <mr_pouit> ScottK: well, it happened recently (but as most of the packages are going to be rebuilt/updated for xfce 4.8, I'm afraid they only wasted their time, which is probably worse, they could have done something useful instead :/)
[20:26] <mr_pouit> hyperair: I hope so :)
[20:27] <hyperair> mr_pouit: you could also include a note in merges.ubuntu.com, i believe there's a space there you can add a comment.
[20:28] <ScottK> mr_pouit: Well if they learn something from the experience (which might be as little as "check with mr_pouit before messing with XFCE", then it's not without value.
[20:30] <ari-tczew> how to fix apt-file search? I did upgrade to natty and 'apt-file search
[20:30] <ari-tczew> doesn't work. output is clear
[20:48] <ebroder> apt-file update?
=== Amaranth__ is now known as Amaranth
[22:59] <ari-tczew> ebroder: it works, thanks