[01:57] <c2tarun> this is a changelog i created http://paste.ubuntu.com/561217/   there is was no debian folder in the tarball, so i created one by dh_make.
[01:58] <micahg> c2tarun: where do you intend this package to go?  The version needs a little tweaking
[01:59] <c2tarun> micahg: in archives of kubuntu
[01:59] <micahg> c2tarun: ok, you should target to natty, and the version should be 1.4-0ubuntu1
[02:00] <c2tarun> micahg: but i don't have natty installed on my system. even the pbuilder I created is of maverick. still is it possible to target natty?
[02:00] <micahg> c2tarun: check out pbuilder-dist in ubuntu-dev-tools
[02:01] <c2tarun> micahg: i m not getting, please explain a bit. what to check out?
[02:01] <micahg> c2tarun: sorry, take a look at = check out in this case
[02:03] <c2tarun> micahg: actually where are u saying to look is not clear to me. i just looked into /usr/bin/ and there is file pbuilder-dist?
[02:04] <micahg> c2tarun: there's a package ubuntu-dev-tools with a program called pbuilder-dist
[02:06] <c2tarun> on running pbuilder-dist i got insufficient number of arguments :(
[02:06] <micahg> c2tarun: take a look at the man page
[02:11] <c2tarun> micahg: pbuilder-dist is the program that creates the pbuilder chroot env?
[02:11] <micahg> c2tarun: yes, it can create one for natty for you
[02:11] <c2tarun> micahg: ok, but I already have a chroot for maverick, will it not be a problem?
[02:12] <micahg> c2tarun: chroot != pbuilder
[02:12] <c2tarun> micahg: sorry  i created a maverick env by pbuilder.
[02:12] <micahg> c2tarun: no, it shouldn't clobber it
[02:13] <c2tarun> micahg: or i should update my mav to natty?
[02:13] <micahg> c2tarun: probably better to create a clean pbuilder env with pbuilder-dist
[02:15] <c2tarun> micahg: sure, it will take some time. meanwhile can u please explain me the problem with version name
[02:15] <c2tarun> ?
[02:15] <micahg> c2tarun: new packages in the archive not coming from Debian use the version UPSTREAM_VER-0ubuntu1
[02:16] <c2tarun> micahg: got it
[02:16] <c2tarun> micahg: 0 is for new and its first so ubuntu'1'
[02:16] <broder> c2tarun: the 0 actually means that it didn't come from debian originally
[02:16] <micahg> c2tarun: 0 is in place of the Debian revision, so if Debian gets the package, we can sync/merge from them
[02:18] <c2tarun> micahg: ok check this now.
[02:18] <c2tarun> http://paste.ubuntu.com/561221/
[02:19] <micahg> c2tarun: looks, good, is there a needs packaging bug?  it should be closed in the initial release changelog
[02:21] <c2tarun> micahg: ya i checked in some other packages changelog and there mentioned a (close#****) what is its?
[02:21] <micahg> c2tarun: (Closes: #XXXXXX) is Debian's close syntax, we use (LP: #XXXXXX)
[02:23] <c2tarun> micahg: ok, what does it mean actually, why we put it?
[02:23] <micahg> c2tarun: it allows Launchpad to close the bug when the package is uploaded to the archive
[02:24] <c2tarun> micahg: ok, so I should put there a bug number, but for that I need a bug number. do I have to file a bug for it?
[02:27] <micahg> c2tarun: RFP in Debian is debian 610911
[02:31] <c2tarun> micahg: i thought we have to report in LP
[02:32] <micahg> c2tarun: yep, I'm looking for one of those as well, maybe you can get it into Debian as well
[02:34] <c2tarun> micahg: sure, but how did u filed the bug. I mean u did a great job, but whta is wnpp and how did u get those informations?
[02:34] <micahg> c2tarun: I didn't file it, I found it on the wnpp list
[02:34] <micahg> http://www.debian.org/devel/wnpp/prospective
[02:35] <c2tarun> micahg: ok that explains a lot :) so what should I do now?
[02:36] <micahg> c2tarun: well, I was trying to see if there was a needs-packaging bug on Launchpad, but it's not behaving ATM
[02:36] <micahg> c2tarun: upload to revu, we can add a bug # later
[02:36] <c2tarun> micahg: but revu accepts the package (i think)
[02:36] <micahg> c2tarun: not into the archive
[02:37] <c2tarun> micahg: and i didn't created a package yet.
[02:40] <c2tarun> micahg: u there?
[02:41] <micahg> c2tarun: yep, so, I guess the next step is to finish making the package, then upload to revu for review
[02:41] <c2tarun> micahg: since my pbuilder is stil not ready, i should create a .dsc first?
[02:42] <c2tarun> micahg: one more thing, what else should i add in changelog?
[02:42] <micahg> c2tarun: yep, you'll need it to test build
[02:42] <micahg> c2tarun: normally any packaging changes are mentioned, but for an initial release, there's nothing more really
[02:43] <c2tarun> micahg: what about that LP(#XXXXX)?
[02:43] <micahg> c2tarun: yes, should be added once you have a bug #
[02:43] <c2tarun> micahg: but right now i dont have any? so i should leave it?
[02:44] <micahg> c2tarun: yeah, just leave it out for now
[02:45] <c2tarun> micahg: done, dsc is ready. what else now?
[02:46] <micahg> c2tarun: did you follow the packaging guide?
[02:47] <c2tarun> micahg: yup, but in that packaging guide they didn't used pbuilder. but yesterday i created a package by pbuilder.
[02:47] <psusi> I can never get my head around the difference between target to milestone, and tracked in release.  I notice that the link cjwatson posted of bugs that still need fixed for alpha 2 only lists ones that are tracked in natty, not just milestoned to alpha 2, but I thought it was assumed to be the development version if you don't track it in a specific release?
[02:48] <micahg> psusi: a release can have multiple milestones
[02:50] <psusi> micahg, yes, but when is it appropriate to track a bug in the development release?
[02:50] <psusi> instead of, or in addition to targeting it to a milestone?
[02:51] <micahg> psusi: when it should be fixed in the devel release (either a regression or something that needs to be fixed before release)
[02:51] <psusi> hrm... ok... I guess I'll nominate this then and see what happens.
[02:52] <micahg> psusi: you need something looked at? I can accept something in universe
[02:52] <psusi> nope, it's in main... #711616
[02:52] <psusi> parted
[02:53] <micahg> psusi: yeah, let's leave that for cj watson in the morning :)
[02:54] <psusi> yea.. just was making sure I had crossed all of the ts and dotted all of the is on the bug report, branch, and merge request... and I noticed that it isn't showing when I click the link in his email even though I targeted it to alpha-2 milestone
[02:55] <c2tarun> micahg: I think i did a mistake. I forgot to copy the previous base tarball of maverick pbuilder.
[02:55] <micahg> psusi: that page might be cached
[02:55] <micahg> c2tarun: pbuilder-dist generates a new base for maverick
[02:55] <micahg> oops, natty
[02:56] <c2tarun> micahg: actually just now i generated a base for natty, do u think this new one has replaced my old one?
[02:56] <c2tarun> micahg: old one is of mav
[02:57] <micahg> c2tarun: not if you used pbuilder-dist, I believe it appends the release name to the tarball
[02:57] <c2tarun> micahg: how can i check it?
[02:57] <micahg> c2tarun: take a look in ~/pbuilder
[02:59] <c2tarun> micahg: ya got it :) new base is in home folder, prev one was in /usr/share....  thanks :) but i don't know that if i executed pbuilder build *.dsc which one will  be used?
[02:59] <micahg> c2tarun: you use pbuilder-dist to build the new one
[03:00] <c2tarun> micahg: grt :)
[03:00] <c2tarun> micahg: i am getting an error 'unknow distribution build' y so ?
[03:01] <micahg> c2tarun: can you pastebin?
[03:02] <c2tarun> micahg: http://paste.ubuntu.com/561232/   sorry its a warning,
[03:03] <micahg> c2tarun: you need to pass the release name to pbuilder-dist when building
[03:16] <c2tarun> micahg: something happened http://paste.ubuntu.com/561234/ please take a look
[03:16] <micahg> c2tarun: you need to add the build-depends to debian/control
[03:18] <c2tarun> micahg: how?
[03:19] <c2tarun> micahg: i dont know what build-depends are? should i ask the one who created that package.
[03:19] <micahg> c2tarun: you list the packages that are needed to build your package, https://wiki.ubuntu.com/PackagingGuide/Complete#control
[03:21] <micahg> c2tarun: upstream usually list requirements in a readme  or on their website
[03:34] <c2tarun> micahg: I cant find any info about the build-depends except that it requires KDE>4.0. any suggestions?
[03:37] <Bachstelze> c2tarun: compile the package "manually", and when you see that you need a package, add it to your build-depends
[03:38] <c2tarun> Bachstelze: what is i have all the dependencies installed, then it will report nothing.
[03:38] <Bachstelze> (assuming you don't have the packages installed alteady, of course, if you do, use a chroot or pbuilder)
[03:38] <c2tarun> Bachstelze: got it :)
[03:40] <c2tarun> Bachstelze: another problem, how can i access the files on my system from a pbuilder environment?
[03:40] <Bachstelze> c2tarun: you can't, pbuilder runs in a chroot
[03:40] <Bachstelze> there ia sa way to add files to the pbuilder chroot, but it's probably not what you want to do
[03:40] <c2tarun> Bachstelze: anything like mounting any flder inside?
[03:41] <Bachstelze> why would you want to do that ?
[03:41] <Bachstelze> the point of pbuilder is that it mimics the build machines environment
[03:41] <Bachstelze> adding stuff to it defeats tha tpoint
[03:41] <c2tarun> actually i have the source code in my home folder. but after logging into pbuilder I cannot access it, so without accessing those how can i install manually?
[03:42] <Bachstelze> you don't need to, just try building your package as usual
[03:42] <Bachstelze> you will get the same error messages
[03:42] <c2tarun> Bachstelze: sorry its my first time, can u please tell me how?
[03:42] <Bachstelze> how did you get that pastebin output ?
[03:43] <c2tarun> by running pbuilder-dist natty *.dsc
[03:43] <Bachstelze> okay
[03:43] <Bachstelze> then you got an error messae
[03:43] <Bachstelze> telling you that cmake couldn't find kde4-config
[03:43] <c2tarun> ya.
[03:43] <Bachstelze> kde4-config is in package kdelibs-bin
[03:43] <Bachstelze> so add kdelibs-bin to your build-depends, and try again
[03:44] <c2tarun> ok, so i have to run pbuilder-dist every time i encounters an error. I there a way to save the complete message in one file and grep all the errors?
[03:45] <Bachstelze> you can use script, but can't you just scroll back in your terminal?
[03:45] <Bachstelze> you will probably get only one at a time anyway
[03:45] <Bachstelze> (at least rearding missing dependencies)
[03:46] <c2tarun> ya i can :) still greping is easier. anyway i'll start with one and move on for others :) if i get stuck i'll ping here.
[03:47] <c2tarun> Bachstelze: hey how do we check that Kde4-config is in which package?
[03:47] <Bachstelze> you can use packages.ubuntu.com
[03:48] <c2tarun> Bachstelze: and what should i write in section of control file?
[03:48] <Bachstelze> just kdelibs-bin should be enough
[03:49] <c2tarun> nothing else? because i just saw there is a format for control file in packaging guide.
[03:49] <Bachstelze> maybe also (>= 4.0) if you're paranoid
[03:50] <c2tarun> Bachstelze: nothing else? because i just saw there is a format for control file in packaging guide.
[03:51] <Bachstelze> it says
[03:51] <Bachstelze> Build-Depends: One of the most important fields and often the source of bugs, this line lists the binary packages (with versions if necessary) that need to be installed in order to create the binary package(s) from the source package. Packages that are essential are required by build-essential and do not need to be included in the Build-Depends line. The list of build-essential packages can be found at /usr/share/doc/build-essential/list.
[03:51] <Bachstelze> so
[03:51] <Bachstelze> you shouldn't need anything else
[03:51] <c2tarun> Bachstelze: ok thanks :)
[03:59] <c2tarun> Bachstelze: I updated control file with kdelibs-bin but still I am getting the same error.
[04:03] <c2tarun> Bachstelze: ping
[04:11] <c2tarun> Bachstelze: got it :) I created .dsc again , and now pbuilder-dist downloading few new packages :)
[04:18] <Bachstelze> c2tarun: :)
[04:18] <Bachstelze> (sorry, I'm kinda busy too)
[04:19] <c2tarun> Bachstelze: ok please reply when u have few minutes spare time, coz i am stuck again with an error.
[04:20] <Bachstelze> c2tarun: I am here now ;)
[04:20] <Bachstelze> it's just that when I'm away, I don't see irssi blinking
[04:20] <c2tarun> Bachstelze: http://paste.ubuntu.com/561254/ look at this error? which package do i need now.
[04:21] <c2tarun> Bachstelze: is it cmake?
[04:21] <Bachstelze> no
[04:21] <Bachstelze> you want the file FindKDE4Internal.cmake
[04:22] <c2tarun> Bachstelze: ok let me search on package.ubuntu
[04:22] <c2tarun> Bachstelze: got it kdelibs5-dev :) thanks
[04:22] <Bachstelze> yup
[04:22] <Bachstelze> also
[04:23] <Bachstelze> kdelibs5-dev depends on kdelibs-bin
[04:23] <Bachstelze> so you can remove kdelibs-bin from your build-depends, it wil get installes with kdelibs5-dev
[04:24] <c2tarun> Bachstelze: ok, right now u told me this, but how can i check this myself that which packages to remove from list?
[04:25] <Bachstelze> you don't have to, it just helps limit clutter
[04:25] <c2tarun> Bachstelze: ok thaks :)
[04:26] <Bachstelze> you can see on p.u.c that kdelibs5-dev depends on kdelibs-bin, so you don't have to install kdelibs-bin explicitly, it will get pulled as a dependency
[04:46] <c2tarun> Bachstelze: hey i got the .deb file :))))  what to do now ( I mean I want it into kubuntu archives)?
[05:03] <micahg> c2tarun: you might want to work with the guy trying to get it in Debian, 1.3 is already on mentors.debian.net
[05:03] <micahg> also see bug 408964
[05:10] <c2tarun> micahg: where can i find a guy who is trying to get it in Debian?
[05:13] <micahg> c2tarun: it's the person who filed the Launchpad and Debian bugs
[05:16] <c2tarun> micahg: ok :) I talked to him in morning. I'll contact him again thanks :)
[05:19] <micahg> c2tarun: np, by the way, it's generally a good idea to check launchpad needs-packaging/debian wnpp/revu/mentors.debian.net before starting to package something
[05:20] <c2tarun> micahg: yup, packaging is fun :) , can i find more bugs like this, that needs just packaging?
[05:21] <micahg> c2tarun: yes, there are about 2k needs-packaging tagged bugs in Launchpad and about 600 wnpp in Debian
[05:21] <c2tarun> micahg: whats an wnpp
[05:21] <micahg> c2tarun: work-needing and prospective packages
[05:22] <c2tarun> micahg: ok thanks :)
[05:30] <mase_wk> hi guys, i am having trouble with pbuilder and dovecot 2.0.9. I am getting the following error :
[05:30] <mase_wk> The following packages are BROKEN:  pbuilder-satisfydepends-dummy
[05:30] <mase_wk> but i'm not really sure howto resolve it
[05:31] <mase_wk> it says remove the following a packages, pbuilder-satisfy-depends but i don't know how to do that  from pbuilder
[05:34] <achiang> mase_wk: please pastebin the full build log; the real error is earlier in the log somewhere else
[05:38] <mase_wk> ok 10 secs
[05:39] <Rhonda> cjwatson: Yep, had a chat with pitti anyway because of pg9.0, so asked him right ahead. :)
[05:39] <mase_wk> achiang: http://pastebin.com/bk3rGJHD
[05:40] <achiang> mase_wk: lines 76--89 are the real problem
[05:40] <achiang> mase_wk: well, i mean, they're telling you what the issues are
[05:41] <mase_wk> achiang: so how I get it to grab and install those packages ?
[05:42] <achiang> mase_wk: my guess is that your pbuilder isn't setup correctly. is your /etc/apt/sources.list setup correctly in your chroot?
[05:44] <mase_wk> achiang: i  don't really know...if i go into the pbuilder directory i get .tgz file
[05:44] <mase_wk> lucid-i386.tgz which i guess it created for me
[05:44] <mase_wk> i can just blow it away and start again
[05:45] <achiang> mase_wk: one sec
[05:45] <micahg> ScottK: ping?
[05:45] <achiang> mase_wk: how did you create your pbuilder?
[05:46] <mase_wk> pbuilder-dist lucid i386 create --mirror http://mirror.internode.on.net/pub/ubuntu/ubuntu
[05:47] <achiang> mase_wk: try pbuilder --login lucid
[05:47] <achiang> mase_wk: that should unpack the tarball, and log you into the chroot
[05:48] <achiang> mase_wk: from there, you can poke around, check out /etc/apt/sources.list, and manually try something like, "apt-get install debhelper"
[05:50] <mase_wk> doesn't that defeat the purpose of pbuilder ? I
[05:50] <achiang> mase_wk: it will help you debug what is wrong with your pbuilder; once you fix it, then you will be able to pbuild packages
[05:51] <achiang> mase_wk: if you're in your pbuilder chroot and cannot do a simple apt-get update; apt-get install debhelper, then you need to fix that before you can pbuild packages
[05:52] <mase_wk> ok, i get that, but why would a fresh pbuilder instance have that issue ?
[05:52] <mase_wk> would /should
[05:53] <achiang> mase_wk: it's not fresh ; it should unpack the pbuilder tarball you created previously
[05:53] <mase_wk> why isn't it fresh, i only just ran the command like 10 minutes ago. i've never built a lucid package on this machine before
[05:55] <achiang> mase_wk: well, clearly the chroot you created is broken. i don't know why, but the step i described above will help us figure it out.
[05:56] <mase_wk> ok. fair enough.
[05:56] <achiang> fwiw, i never use pbuilder-dist; i have a hideous looking pbuilder line that i use
[05:56]  * achiang wonders where mterry is; he really needs to publicize his pbuilder wrappers
[05:56] <mase_wk> what do you use ? i swear every person in this channel has a different method of packaging
[05:57]  * micahg is wondering whether or not to file a metabug to resolve gcc-4.3 rdepends
[05:58] <achiang> mase_wk: well, i use pbuilder, but i use some wrappers that make it super nice. unfortunately, i didn't write the code, so i don't know if i can share it with you. but i will follow up with mterry tomorrow and see if there's any reason that they're still "secret"
[05:58] <achiang> mase_wk: in the meantime, we can try debugging; although fair warning, it's close to 23:00 here, so i'm getting ready for bed
[05:59] <mase_wk> np. i'll unpack it and work out what's wrong. I guess i just thought being a brand new VM and only my second packge , my first lucid package that it should be easy
[06:00] <mase_wk> but alas nothing ever is
[06:00] <achiang> mase_wk: i would think that "pbuilder --login" would automatically unpack it and chroot into it. does that not work?
[06:01] <mase_wk> erm yeh that works , wasn't aware of that
[06:02] <achiang> mase_wk: ok, now pastebin the contents of /etc/apt/sources.list
[06:03] <mase_wk> achiang: looks like there was something wrong with the mirror i was using . I created a new pbuilder build directory using the std ubuntu mirrors and that one seems to be building
[06:04] <achiang> mase_wk: cool, i was going to suggest that if i couldn't figure out what was wrong with your sources.list. :)
[06:04] <mase_wk> yeh sources.list looks fine.
[06:04] <mase_wk> it's the same mirror i use for my actual machine so i am unsure in what way it's broken but apparently it is
[06:05] <mase_wk> thanks for your help
[06:05] <achiang> np
[06:13] <c2tarun> micahg: how can i look for needs-packaging bugs on LP. I searched in it but all i am getting is list of packages already packed, and advanced search option is also not there.
[06:14] <micahg> c2tarun: either click on needs-packaging on the tag cloud or search for +needs-packaging
[06:15] <c2tarun> micahg: searching is not working, whats a tag cloud?
[06:15] <micahg> c2tarun: you can also click the advanced search and add a tag
[06:15] <micahg> c2tarun: tag cloud is on teh right side of the Ubuntu distro bugs home page
[06:16] <c2tarun> micahg: got it :) thanks
[06:41] <c2tarun> micahg: can u look at this changelog please http://paste.ubuntu.com/561284/
[06:42] <micahg> c2tarun: that should be (LP: #XXXXXX)
[06:45] <c2tarun> micahg: no numbers?
[06:45] <micahg> c2tarun: numbers replace XXXX :)
[06:45] <c2tarun> oh sorry LP
[06:46] <c2tarun> micahg: this means while working on any needs-packaging bug on LP we'll always write LP
[06:47] <micahg> c2tarun: any LP bug you close should use that syntax LP: #XXXXXX
[06:47] <c2tarun> micahg: what if I found the compile error?
[06:47] <micahg> c2tarun: file a bug, add a debdiff, and close it in the changelog :)
[06:48] <c2tarun> micahg: ok, thanks :)
[06:48] <c2tarun> micahg: I didn't added any build-depends in control file, still I got the .deb file without error. :( how come?
[06:49] <micahg> c2tarun: you might have them installed already?
[06:49] <c2tarun> micahg: i was using pbuilder-distro i guess nothing is installed there and it pulls from cache only if it is mentioned in control file?
[06:50] <micahg> c2tarun: yep, I guess, that's a little weird though
[06:50] <micahg> err, not necessarily weird, depends on what the package is
[06:51] <c2tarun> micahg: hmm..... not getting, can u please explain a bit.
[06:52] <micahg> c2tarun: some packages  have minimal build-deps, but need binary-deps added
[06:53] <c2tarun> micahg: build-depends includes debhelper
[06:56] <c2tarun> micahg: ??
[06:56] <micahg> c2tarun: /me doesn't know what to say, try running it :)(
[06:57] <micahg> c2tarun: err, try in a chroot/vm or build on maverick and try locally
[06:57] <c2tarun> micahg: sure :) thanks
[08:35] <dholbach> good morning
[08:36] <hrw> hi
[08:36] <hrw> what do I have to install to be able to build pkgsym ddebs?
[08:39] <hrw> ok, found - pkg-create-dbgsym
[08:44] <ScottK> micahg: pong.  I'll be away most of the next 24 to 30 hours.
[08:45] <micahg> ScottK: it's ok, I was going to ask about some python rebuild requests, but I think tumbleweed might be taking care of it
[08:45] <micahg> oops, python-numpy rdepend
[08:56] <tumbleweed> micahg: yeah smorar was on holiday in new zealand while his numpy upload got sponsored. I'll help him with getting stuff done
[08:57] <tumbleweed> anyone else is obviously welcome to help :P
[09:00] <dapal> tumbleweed: ACKed in utnubu :) -- however, the project hasn't really re-started yet, real life is keeping me busy (sai com'è, università, laurea a luglio...)
[09:00] <dapal> tumbleweed: (oops, this isn't #debian-ubuntu. Nevermind :D)
[09:00] <tumbleweed> dapal: thanks, yeah I know it's still dormant :P
[09:01] <micahg> tumbleweed: my main question was whether or not all those rebuilds are warranted
[09:02] <tumbleweed> micahg: yeah I don't think thye all are
[09:04] <tumbleweed> dapal: yeah blackz was wanting to do a big push on it, I offered to help but only got sidetracked so far
[09:05] <dapal> tumbleweed: and I wanted to setup some scripts to do automated analysis/statistics, but so far I've only had time to setup an ikiwiki :D
[09:05] <dapal> tumbleweed: (with two pages which sould be auto-generated, but I haven't checked)
[09:21] <geser> good morning
[10:34] <iulian> Morning.
[11:13] <diwic> Hi, is there a guide for how to work with packaging maintained in bazaar?
[11:14] <diwic> I'm currently very stuck: I did bzr branch to get the packaging, now I want to add a patch, but "quilt push -a" fails as it doesn't have a source tree, only the debian directory?
[11:22] <Bachstelze> diwic: adding a atch without having the source tree doesn't look like a wise idea
[11:22] <Bachstelze> how will you know it applies cleanly?
[11:22] <diwic> Bachstelze, exactly, so what command do I use to grab the source tree
[11:22] <diwic> ?
[11:23] <diwic> and unpack it
[11:23] <Bachstelze> depends on where the package is
[11:23] <Bachstelze> if it's in the repos, apt-get source
[11:24] <tumbleweed> this sounds like a merge-mode branch
[11:24] <tumbleweed> bzr bd-do?
[11:25] <diwic> tumbleweed, aha, this seems interesting *reading*
[11:26] <diwic> Bachstelze, it's in a bzr branch
[11:27] <diwic> tumbleweed, btw, how does bzr-buildpackage know the name and location of the orig tarball?
[11:27] <tumbleweed> diwic: what's in th ebranch? everything or just debian
[11:27] <diwic> tumbleweed, just debian
[11:28] <tumbleweed> diwic: right, that's merge mode (you tell bzr that by creating a .bzr-builddeb/default.conf file containing [BUILDDEB]\nmerge = True
[11:28] <tumbleweed> it finds the tarball in the parent directory, with the name determined by the most recent changelog entry
[11:28] <tumbleweed> if it doesn't find it, it grabs it with apt / uscan / get-orig-source
[11:31] <diwic> tumbleweed, right, I saw something like that. So assume that I don't want to add a patch but update the package to a new upstream version, i e a new orig.tar.gz. How should I push it so that the next person trying to package will get the orig source?
[11:31] <diwic> tumbleweed, btw, you're making my day, many thanks for helping out :-)
[11:32] <tumbleweed> diwic: bzr will download the orig source for them, using uscan (or a get-orig-source rule)
[11:32] <tumbleweed> so you don't have to do anything special
[11:32] <tumbleweed> if you add a patch, that goes in debian/patches, not in the orig source
[11:34] <diwic> tumbleweed, right, so if this was a properly released upstream version, we would find it through debian/watch. In this case however I want to base it off an git upstream snapshot
[11:36] <tumbleweed> diwic: if you add a get-orig-source rule to debian/rules then bzr will run that
[11:37] <tumbleweed> of course everyone will end up with different tarballs (with the same contents) so remember to delete it after someone else uploads the package
[11:41] <diwic> tumbleweed, hmm, so I ran bzr-buildpackage -S to what it would do, and it downloaded it from apt as the current snapshot is currently in the archive for Natty
[11:41] <diwic> tumbleweed, btw, there is no get-orig-source rule in this package
[11:43] <diwic> tumbleweed, also bzr bd-do fails because it can't find the upstream tarball
[11:43] <diwic> Maybe I should ask the one who uploaded the previous snapshot
[11:43] <diwic> If there's something wrong here
[11:44] <tumbleweed> diwic: bzr bd (bzr-buildpackage) and bzr bd-do should behave the same here
[11:44] <tumbleweed> they will get the orig source of the most recent version in the changelog. preferably from apt
[11:44] <tumbleweed> if you have no get-orig-source, you'll have to create it by hand
[11:46] <diwic> tumbleweed, so in /tmp/build-area I have pulseaudio_0.9.22+stable-queue-18-geb966.orig.tar.gz, whereas bd-do fails looking for pulseaudio_0.9.22+stable-queue-18.orig.tar.gz
[11:47] <tumbleweed> diwic: it gets that version from dpkg-parsechangelog
[11:47] <diwic> debian/changelog says 1:0.9.22+stable-queue-18-geb966-0ubuntu2
[11:48] <tumbleweed> hmm, that could be a bug. multiple -s are not recommended, though
[11:48] <diwic> tumbleweed, I'll dist-upgrade natty to see if that helps
[11:49] <tumbleweed> diwic: I'll have a proper look in a few minutes, on the phone...
[12:44] <tumbleweed> diwic: filed bug 711826
[12:54] <diwic> tumbleweed, thanks! I was able to work around it by copying one tarball to the filename bd-do was looking for
[14:00] <c2tarun> if i created a package and want to check its installation and uninstallation correctly into pbuilder chroot, how can we do that?
[14:01] <Rhonda> pbuilder --login --bindmounts `pwd`
[14:01] <Rhonda> And then manually with dpkg directly.
[14:01] <c2tarun> what is pwd ( the folder containing the deb file?)
[14:02] <c2tarun> Rhonda ^
[14:02] <cjwatson> pwd is a command that prints the current directory
[14:02] <cjwatson> `pwd` substitutes the output of that command
[14:03] <cjwatson> (it's worth learning shell scripting if you're packaging; you'll find yourself spending an awful lot of time lost if you don't)
[14:03] <c2tarun> oh.. got it. I have a doubt with control file as well. please look at bug 710347
[14:04] <c2tarun> in this there is no link for the home page of the application, all the links somehow direct to LP only.
[14:04] <cjwatson> what's wrong with "Homepage: https://launchpad.net/schedio"?
[14:04] <cjwatson> looks like that *is* essentially their home page
[14:04] <c2tarun> cjwatson: I was not about that, sorry :) i'll put this in control file
[14:06] <c2tarun> cjwatson: can you please take a look at the control file?
[14:06] <c2tarun> http://paste.ubuntu.com/561401/
[14:07] <cjwatson> well, you should figure out an appropriate Section, and you have one too many spaces of indentation in the Description field
[14:07] <cjwatson> and "Management Scripts" is much too generic IMO
[14:08] <cjwatson> "extinguishing a plugin set"?
[14:08] <ari-tczew> udienz: I'll sponsor your package in the evening. Now should be OK.
[14:08] <cjwatson> I'd suggest using the description from https://launchpad.net/schedio, but that's not very good or clear English either, unfortunately :-/
[14:09] <cjwatson> however, I need to go out for a bit ...
[14:09] <Rhonda> c2tarun: Also, you want just *one* space of indentation in the long description, otherwise it will be considered to be preformated.
[14:10] <Rhonda> And Standards-Version 3.8.4 is pretty ancient, you should rather use 3.9.1 instead (and check the difference between the two if you have gone with that version)
[14:11] <Rhonda> Also, if it's just a bunch of scripts, are you sure that Architecture: any is correct? Shouldn't it be rather all?
[14:11] <c2tarun> Rhonda: ok i'll reduce the number of spaces, and sorry but what is the difference b/w any and all :(
[14:12] <Rhonda> Arch: any means that the package gets built for every architecture. Arch: all means that the content is architecture independent and can be used right ahead on all architectures (will get built only once)
[14:14] <c2tarun> Rhonda: hmm.... Ok i'll look into description and indentation section, about Standard-versions I need some help, and about architecture I am not sure i'll contact to the one who created this application.
[14:15] <Bachstelze> c2tarun: any  means that a different package will be built for each architecture, all means that a single package will be built
[14:15] <Bachstelze> c2tarun: so you use all for architecture-independent stuff, like images or other data
[14:16] <Bachstelze> and any for compiled binaries
[14:18] <c2tarun> Rhonda: what do the Standard-version signify actually, I tried to read the Debian Policy manual but its very very large. Can u please tell me in short.
[14:19] <Rhonda> The Standards-Version defines to which policy version your package conforms. You always should use the latest version.
[14:19] <c2tarun> Bachstelze: actually I am not the one who created this application, I downloaded it from the bug page :( so i don't know about its arch, the description is also provided from there side.
[14:19] <c2tarun> Rhonda: what is the latest version? 3.9.1?
[14:20] <Rhonda> That's what I said, yes. :)  You can check with going to http://packages.ubuntu.com/debian-policy
[14:21]  * Rhonda . o O ( Did I mention lately that I'm very grateful that I'm finally able to update that site and keep it current.  \o/ )
[14:22] <Bachstelze> c2tarun: does it compile something ? if it does, you should probably use "any"
[14:22] <Rhonda> If it would compile something I would expect Build-Depends, to be honest.
[14:23] <c2tarun> Rhonda: actually I created its debian once with just debhelper in Build-
[14:23] <c2tarun> *Build-Depends section
[14:25] <c2tarun> Rhonda: ping
[14:25] <Rhonda> I'm here.
[14:25] <Rhonda> But sorry, I am busy and can't help you with basic level mentoring right now
[14:26] <c2tarun> Rhonda: ok, Thanks so far :)
[14:27] <Bachstelze> c2tarun: it's schedio you are working on?
[14:30] <c2tarun> Bachstelze: ya
[14:30] <c2tarun> Bachstelze: https://launchpad.net/bugs/710347
[14:30] <Bachstelze> there's a PPA for it
[14:31] <Bachstelze> so you should probably contact the people who maintain it
[14:31] <c2tarun> ppa means?
[14:31] <Bachstelze> !ppa
[14:31] <Bachstelze> basically, it's a place to put your own packages for others to download
[14:32] <c2tarun> Bachstelze: got it. :) googled it
[14:34] <udienz> ari-tczew, thanks!
[14:50] <c2tarun> Bachstelze: hey, on the ppa page there are diff versions for amd64, i386 and one is normal. I think Arch section should contain any not all.
[14:59] <Bachstelze> c2tarun: which page are you looking at?
[15:04] <c2tarun> Bachstelze: https://launchpad.net/ubuntu/+ppas?name_filter=schedio there are three diff ppa's for every version.
[15:15] <Bachstelze> c2tarun: indded, and they are maintained by the same people...
[15:15] <Bachstelze> so either thhey don't understand how PPAs work , or there is something very peculiar about this package
[15:21] <bdrung> how do i get debug symbols for universe package. i enabled the ddebs, but they seem to cover only main
[15:23] <c2tarun> Bachstelze: may be, I mailed them on LP and asked them about arch and some description. I can proceed only after their reply. anyway till then can u suggest me some simple needs-packaging bugs to work on
[15:27] <Bachstelze> c2tarun: nope, sorry, I don't work on these
[15:27] <Bachstelze> as you can see, packaging a program requires some knowledge of its internals
[15:28] <Bachstelze> at least when making the original package
[15:29] <c2tarun> Bachstelze: hmm....
[15:29] <c2tarun> Bachstelze: anyway thanks :)
[16:15] <tumbleweed> bdrung: I didn't know ddebs were main-only. Rebuild locally with DEB_BUILD_OPTIONS=nostrip? (if the package supports it)
[18:02] <micahg> is there someone very familiar with DEP-3 that could tell me if this patch comment qualifies: http://bazaar.launchpad.net/~mathieu-tl/ubuntu/natty/evolution-rss/688776.stan+debfixes/revision/22
[18:05] <tumbleweed> git foramtted diffs aren't DEP-3 compliant (AFAIK), but they do the job of documenting patches well enough
[18:06] <micahg> tumbleweed: I was concerned about the comment with the patch blob that was removed commented out in the patch
[18:09] <tumbleweed> micahg: I was saying it probably wasn't DEP-3 compliant to begin with. But yeah I've never seen a commented-out patch hunk before :(
[18:09] <tumbleweed> :)
[18:11] <debfx> tumbleweed: patches generated with git format-patch are dep-3 compliant
[18:12] <highvoltage> tumbleweed: showard314 made a new upload if you have some time again to review: http://revu.ubuntuwire.com/details.py?upid=8924
[18:16] <tumbleweed> debfx: aah, I see any trailing text is considered to be part of the description. Yeah, they are valid then.
[18:17] <tumbleweed> highvoltage: sure will do
[18:17] <micahg> tumbleweed: debfx, ok but this isn't git formatted, this has a patch hunk added
[18:17] <micahg> as a comment
[18:18] <tumbleweed> micahg: oh I assumed from th Date field (not a DEP3 field) that it was a git-formatted patch. Looks like it'd be considered part of the description and therefore valid
[18:18] <micahg> tumbleweed: it originally was when I suggested that it be edited with the info of what was removed, it appears I was taken very literally :)
[18:22] <tumbleweed> yeah "backported from trunk" would probably do the trick :)
[18:24] <micahg> tumbleweed: no, the "backported" patch was edited
[18:24] <tumbleweed> aah
[18:24] <micahg> so, it's part of that revision
[20:51] <micahg> bdrung: it seems that if an upstream tarball is in the archive somewhere you don't need to upload it to a PPA, so maybe the default for backportpackage should be -ud?
[20:52] <micahg> oops, -sd
[20:54] <bdrung> micahg: no. -sa will work in all cases, -sd can lead to problems if no tarball is available. backportpackage should check if the tarball is available and set -sd when yes
[21:02] <grunthus> Hello, I'm trying to set up testdrive to run Natty. Testdrive keeps deleting the installed image...
[21:02] <grunthus> after reboot.
[21:02] <grunthus> CLEAN_IMG = False
[21:03] <grunthus> ^ got that in my /etc/testdriverc
[21:03] <grunthus> Bit of a pest, as I'd like to get going with a patching tutorial
[21:09] <micahg> grunthus: maybe asking in #ubuntu-testing would be better as they're probably heavier users of testdrive
[21:09] <micahg> grunthus: or #ubuntu
[21:10] <grunthus> Sure, thanks. I thought I read that it was recommended to use testdrive for package maintenance