[00:06] <ajmitch> lfaraone: I see you mentioned the RC bugs stuff in the DMB meeting, what were you using to do that?
[00:06] <lfaraone> ajmitch: http://qa.ubuntuwire.org/bugs/rcbugs/maverick/ and http://qa.ubuntuwire.org/bugs/rcbugs/lucid/
[00:06] <ajmitch> OK, you have any suggestions for improving those?
[00:07]  * ajmitch wrote & maintains that lot
[00:07] <ajmitch> I see you mentioned AJAX in there, something that's been on my TODO list, especially as I've been doing a lot of that at work lately :)
[00:12] <ajmitch> lfaraone: nothing to change then? :)
[00:14] <lfaraone> ajmitch: it has no deficencies as it currently is. What would be nice is a page that would allow us to tell at a glance what the delta is, in terms of changelogs. Pie in the sky feature request:a full diff, which we might be able to extract from bzr or manually.
[00:14] <ajmitch> no reason why that can't be cached & calculated
[00:15] <ajmitch> I'll see what I can do
[00:15] <lfaraone> ajmitch: awesome, thanks!
[00:15] <ajmitch> there are a few other things I'd like, such as giving some information on the bug without having to click through everywhere
[00:15] <ajmitch> it's currently generated through cron, and doesn't change that rapidly
[00:33] <Rhonda> Can someone explain these two things to me? https://bugs.launchpad.net/bugs/6556 and https://bugs.launchpad.net/bugs/6477
[00:33] <ubottu> Launchpad bug 6556 in wesnoth "wesnoth: merge new debian version" [Medium,Fix released]
[00:34] <ajmitch> somehow/somewhen the bug was assigned to that time & it was getting set back
[00:35] <ajmitch> registry administrators is a launchpad team that sort of ends up as a default owner for stuff, I think
[00:47] <Rhonda> ajmitch: Ah, confusion on my part anyway. But still awkward a bit for 4 year closed bugs. %-)
[00:59] <ajmitch> yeah, it looks rather strange, I wonder why it was done
[01:03] <Rhonda> ajmitch: Just received a third mail about Bug 5606 :)
[01:03] <ubottu> Launchpad bug 5606 in wesnoth "wesnoth: merge new debian version" [Medium,Fix released] https://launchpad.net/bugs/5606
[01:04] <Rhonda> Seems like someone is doing historical cleanup
[01:19] <pabelanger_> I was hoping somebody could help me and see if I have completed Bug #579045 properly?  I'm trying to get a package from Debian merged into Ubuntu
[01:19] <ubottu> Launchpad bug 579045 in asterisk "[needs-packaging] openr2 -- MFC/R2 call setup library" [Undecided,Confirmed] https://launchpad.net/bugs/579045
[01:21] <Rhonda> pabelanger_: I would expect the package should automatically get synced into maverick once that job works again.
[01:22] <pabelanger_> Rhonda: Where can I learn more about the sync process between Debian and Ubuntu
[01:25] <Rhonda> pabelanger_: https://wiki.ubuntu.com/SyncRequestProcess - but like said, that's only needed after DIF.
[01:28] <pabelanger_> Rhonda: ok, thanks for the information.
=== funkyHat_ is now known as funkyHat
=== nobawk is now known as nobawk|away
=== nobawk|away is now known as nobawk
[03:05] <lfaraone> I prepaired a security upload a while back. I don't think I can upload to that queue, but nobody has taken a look at the bug.
[03:06] <lfaraone> (rather, no actionhas been taken on it)
[03:08] <nigelbabu> lfaraone: poke kees if you can catch him or ask in #ubuntu-hardened
[03:08] <nigelbabu> someone should reply
[03:09] <lfaraone> nigelbabu: thanks.
[03:09] <nigelbabu> :)
[03:10]  * ajmitch suspects that most of the people who could upload it will be at UDS right now
[03:10]  * nigelbabu is pretty sure
[03:10] <nigelbabu> but they can assign it to themselves and take care fo it later
[03:10] <lfaraone> ajmitch: mk. the bug is about two months old, and the embargo ended 1.8 months ago :)
[03:11] <ajmitch> yeah, I can see that, hopefully someone will see it when they get online in the morning
[03:39] <lfaraone> ajmitch: are fake syncs frowned upon? I remember some discussion earlier in this channel about them.
[03:40] <ajmitch> generally yes, why do you need to do one?
[03:40] <lfaraone> ajmitch: just wondering, I don't.
=== gospch_ is now known as gospch
[04:10] <bcurtiswx3> http://paste.ubuntu.com/432007/ anyone know what i need to do?
[04:16] <lfaraone> Hm. I'm having trouble determing the utility of the patch in https://edge.launchpad.net/ubuntu/+source/sablotron/1.0.3-1ubuntu1. Does anybody have an idea what exactly it does? (it touches a bunch of files, but I don't see the utility of it)
[04:17]  * bcurtiswx3 waves to luke
[04:22] <lfaraone> hey bcurtiswx3, let me take a look.
[04:23] <lfaraone> bcurtiswx3: well, the package requires that the version of telepathy-logger be *exactly* 0.1.1. If that is a real (insofar as the newer version does not work) dependency you are screwed, otherwise you may be able to change it to a >= without problems.
[04:23] <lfaraone> bcurtiswx3: I'm not sure where that's expressed in the package code, esp since I don't know the package this comes from :)
[04:24] <bcurtiswx3> telepathy-logger
[04:24] <bcurtiswx3> its simple actually
[04:24] <bcurtiswx3> maybe i can find it
[04:25] <lfaraone> bcurtiswx3: no, I mean what are you trying to build?
[04:25] <bcurtiswx3> empathy
[04:28] <lfaraone> bcurtiswx3: from the source in ubuntu, or some odd version?
[04:28] <bcurtiswx3> source in freedesktop
[04:32] <lfaraone> ajmitch: oh, it'd be nice to add comments to RCbugs marked as unimportant. I just did some research on syncing "lash" over, but I'll have to remove it from unimportant before commenting.
[04:33] <ajmitch> lfaraone: that should be trivial enough
[04:35] <MTecknology> Is it possible to uncompress a .deb and see the debian/ directory? Or is that completely separate?
[04:37] <lfaraone> MTecknology: there is no longer a "debian" directory. There is "DEBIAN", but it's not the same.
[04:39] <MTecknology> lfaraone: oh.. is it possible to reconstruct it or is it more of a binary form?
[04:39] <lfaraone> MTecknology: I'm not sure, I try not to touch it :)
[04:40] <MTecknology> lfaraone: alrighty- I'll try to find another way to get the stuff I'm looking for :P - thanks
[04:40] <lfaraone> Why is it that running "rmadison -u qa libtinyxml-dev" gives me results while "requestsync -n --lp libtinyxml-dev" says it's not in sid?
[04:40] <lifeless> rmadison hits a debian website; requestsync hits ubuntus mirror of sid
[04:41] <ajmitch> ubuntu's mirror of sid is not being updated properly, mostly due to files not being generated properly on ftp.debian.org
[04:42] <ajmitch> alsmot, requestsync probably requires the source package (tinyxml)
[04:46]  * ajmitch is hoping that someone is able to fix it there soon
[04:46] <ajmitch> it's a little annoying trying to do merges for maverick & having the branches on LP be out of date, which I suspect is related to this
[04:48] <lifeless> yes
[04:49] <lifeless> the debian branches are driven by the info about debian that lp holds
=== nobawk is now known as nobawk|away
=== nobawk|away is now known as nobawk
[04:56] <lfaraone> ajmitch: just for clarification, what I was talking about earlier was http://people.canonical.com/~pitti/scripts/syncpackage.
[04:59] <ajmitch> right, fake syncs are something different
[04:59] <lfaraone> ajmitch: okay, bug syncpackage is kosher, though? I guess I misunderstood.
[05:00] <ajmitch> I think it's ok, I know that some people have been changing that script around though, and will put it in ubuntu-dev-tools
[05:01] <ajmitch> apart from that, I don't know the current status of it
[05:04] <lfaraone> Mk. Long term there will be a LP button to do the same, so I understand.
[05:48] <carstenh> lfaraone: utility of the patch? like cdbs' simple patch system?
[06:02] <MTecknology> how can I uncompress a .deb?
[06:03] <tsimpson> ar x file.deb
[06:03] <ajmitch> dpkg-deb -x package.deb /path
[06:03] <tsimpson> bah, that's just the long version
[06:04] <carstenh> | dpkg-repack - puts an unpacked .deb file back together
[06:04] <ajmitch> while you'll see the generated control file, maintainer scripts, etc, you won't h ave debian/rules & the other important biuts for reconstructing the package from source
[06:06] <MTecknology> thanks
[07:34] <wrapster> if i have pre built libraries.. and i use lets say i build a pkg around these libs to put them into respecitve locations.. would it make a differnce if i just copied these prebuilt libs than actually using the 'install' cmd?
=== kirkland` is now known as kirkland
[08:16] <slytherin> is there any nice howto on using sbuild in lucid? Last time I tried it in karmic it wasn't as easy to setup as pbuilder.
[08:18] <Rhonda> slytherin: It never is "as easy to setup as pbuilder". It's different and more powerful after all.
[08:18] <slytherin> Rhonda: more powerful does not necessarily have to be complex to setup.
[08:19] <Rhonda> Depends. More things to know about and consider. :)
[08:25] <Rhonda> slytherin: Did you read sbuild-setup(7)? Are there specific issues? That manpage is mentioned in the README.Debian doc file.
[08:26] <slytherin> Rhonda: I am still installing packages. Will check manpage after that.
[08:27] <Rhonda> Regularly enough packages do come with documentation included. :P
=== baddog is now known as Guest93265
=== Guest93265 is now known as baddog
[08:49] <slytherin> siretart: is there any plan on working on mplayer in lucid-backports once updated version lands in maverick?
[08:52] <siretart> slytherin: the problem is that a newer mplayer will not work with lucid's ffmpeg
[08:52] <slytherin> :-(
[08:53] <siretart> slytherin: I intend to create packaging scripts for a package called 'mplayer-snapshot', which will a) be in upstream's svn, and b) use the internal copy of ffmpeg
[08:53] <siretart> and autoupload it daily or biweekly or something
[08:53] <slytherin> that will be nice.
[08:54] <siretart> that package will always be up-to-date but not really a candidate for a distro release
[10:32] <ari-tczew> why http://qa.ubuntu.com/reports/bug-fixing/ maverick-fixes-report doesn't exist?
=== rbelem_ is now known as rbelem
=== nobawk is now known as nobawk|away
[12:33] <mirsal> hey there :)
=== nobawk|away is now known as nobawk
[13:34] <bilalakhtar> Hi people, can anyone review my package gnome-media-player? its here http://revu.ubuntuwire.com/p/gnome-media-player and needs-packaging bug #551702
[13:34] <ubottu> Launchpad bug 551702 in ubuntu "[needs-packaging] gnome-media-player" [Wishlist,In progress] https://launchpad.net/bugs/551702
[13:35]  * slytherin hopes moovida gets faster UI in new version. :-(
[13:37] <nickbnf_> Hi, quick question for you guys: does REVU supports the new 3.0 (quilt) format?
[13:37] <slytherin> nickbnf_: don't think so
[13:37] <bilalakhtar> nickbnf_: no. see bug #500753
[13:37] <ubottu> Launchpad bug 500753 in revu "Cannot unpack 3.0 (quilt) packages" [Medium,Confirmed] https://launchpad.net/bugs/500753
[13:37] <nickbnf_> aaw... now my package is "This package could not be extracted; there's no browsable directory for it on REVU."
[13:37] <nickbnf_> ok, thanks!
[13:39] <nickbnf_> So do you think it's better for me to re-add the quilt boilerplate in debian/rules and builddeps just so that my package displays nicely in REVU?
[13:41] <bilalakhtar> nickbnf_: As you can see my package on http://revu.ubuntuwire.com/p/gnome-media-player , I have left it like that, and a motu has advocated. no need to do that
[13:42] <bilalakhtar> sponsors don't care, they simply dget and dpkg-source
[13:42] <nickbnf_> bilalakhtar: ok thanks!
[13:44] <lfaraone> carstenh: no, like what it actually does.
[13:45] <ari-tczew> bdrung: what about comment "ACKed." in syncpackage script? not necessary?
[13:46] <azeem>  /W 36
[13:46] <azeem> oops
[13:46] <ari-tczew> near change importance to wishlist
[13:48] <bilalakhtar> Hi people, can anyone review my package gnome-media-player? its here http://revu.ubuntuwire.com/p/gnome-media-player . Its lintian clean and a motu has already advocated it
[13:53] <BlackZ> bilalakhtar: I suggest you to subscribe ubuntu-sponsors for your bug
[13:54] <bilalakhtar> BlackZ: After I do that, will a message go to ubuntu-sponsors?
[13:55] <BlackZ> bilalakhtar: Yes. But please, keep in mind you're in a queque.
[13:55] <bdrung> ari-tczew: why should there be an "ACKed." comment?
[13:55] <nickbnf_> BlackZ: a queque?
[13:56]  * bilalakhtar asks the same question as nickbnf_ 
[13:56] <bdrung> bilalakhtar: are you the guy who filed the ITP in debian?
[13:56] <BlackZ> s/queque/queue
[13:56] <astraljava> nickbnf_: bilalakhtar: a queue
[13:57] <bilalakhtar> bdrung: yeah
[13:57] <nickbnf_> BlackZ: :-)
[13:57] <bdrung> bilalakhtar: i can have a look at the package later this day
[13:57] <bilalakhtar> bdrung: But I have to maintain different versions in both distros, because of libgstreamermm missing in debian unstable. no problems so far for ubuntu
[13:58] <nickbnf_> bilalakhtar: how is your pkg progressing on debian side?
[13:58] <ari-tczew> bdrung: because you as sponsor give ACK for sync approv
[13:58] <bilalakhtar> nickbnf_: Have to disable a feature in debian, as debian unstable doesn't include libgstreamermm (yet)
[13:58] <bdrung> ari-tczew: instead of acknowledging the sync, i am doing the sync. you can see that the upload was sponsored by me.
[13:58] <BlackZ> bilalakhtar: So you could package it :)
[13:59] <bilalakhtar> BlackZ: I am one of the upstream authors as well
[13:59] <BlackZ> bilalakhtar: Another reason for do that.
[14:00] <bilalakhtar> yeah
[14:00]  * bilalakhtar and BlackZ think the same
[14:01] <ari-tczew> bdrung: ok. I'm thinking about link a branch to sync bug request. does will be done automatically, or your script can handle linking a branches?
[14:03] <bdrung> ari-tczew: linking a branch?
[14:04] <ari-tczew> bdrung: lp:ubuntu/current-development/package
[14:06] <bdrung> ari-tczew: i doubt that this will work in the script, because the branch needs some time to pick up the uploaded package
[14:06] <ari-tczew> bdrung: just only link to branch, not handling code in bzr
[14:08] <bilalakhtar> bdrung: Thanks for your interest. I hope you look at the package whenever you are free.
[14:19] <carstenh> lfaraone: the patch in debian did fix/prevent ftbfs bugs ages ago by re`libtool'izing. jbailey removed useless stuff from this patch when 1.0.2 was the current version (you see that it is based on 1.0.2 when you look at the filenames in the patch). the patch from jbailey is mentioned in the debian changelog version 1.0.2-4 and was included in debian until (including) version 1.0.2-5.2, whilst packaging the new upstream in debian the patch ...
[14:19] <carstenh> ... has been recreated without the care a gnu maintainer like jbailey takes when doing such things.
[14:19] <lfaraone> carstenh: okay, so can it be dropped?
[14:20] <carstenh> lfaraone: debian did drop it when 1.0.3 was released and it did not break anything since then ;)
[14:22] <bilalakhtar> People, can anyone over here review my (second) package for Ubuntu? Its liboauth,found at http://revu.ubuntuwire.com/p/liboauth
[14:22] <carstenh> lfaraone: i would drop it, it might be cleaner when less files are patched but i consider having the packages in sync and avoiding such discussions twice a year more important than a "clean and minimal patch"
[14:26] <lfaraone> What should we do about packages depending on a virtual package? (libmagickcore-extra
[14:26] <lfaraone> What should we do about packages depending on a virtual package? (libmagickcore-extra is depended on by xpad, but only libmagickcore2-extra exists)
[14:28] <carstenh> lfaraone: in debian sid it's libmagickcore3-extra.
[14:28] <bilalakhtar> Sorry, people, had a connection problem
[14:30] <bilalakhtar> People, can anyone over here review my (second) package for Ubuntu? Its liboauth,found at http://revu.ubuntuwire.com/p/liboauth . I have run a test build using pbuilder, no problem with build-depends
[14:35] <lfaraone> bilalakhtar: "the MIT license" is ambiguous, quote the entire license text.
[14:36] <bilalakhtar> lfaraone: But isn;t this much obvious?
[14:37] <bilalakhtar> lfaraone: Can I give an internet address to the license ?
[14:37] <lfaraone> bilalakhtar: "Several variants of the MIT license exist: (1) the standard version with three paragraphs (blanket permission, keep this notice, NO WARRANTY), (2) a version with a no-endorsement clause, and (3) other versions with slight wording differences."
[14:37] <lfaraone> bilalakhtar: No.
[14:38] <bilalakhtar> lfaraone: This is the 1st one
[14:39] <lfaraone> bilalakhtar: by the way, your debian/copyright MUST declare the authorship and copyright of xmalloc.c, which it currently does not.
[14:40] <bilalakhtar> lfaraone: Whenever I have been asked to correct a mistake in a package, it has always been a copyright error
[14:41] <lfaraone> bilalakhtar: hehe, it's hard to get right.
[14:41] <bilalakhtar> lfaraone: you are a motu, right?
[14:42] <lfaraone> bilalakhtar: yes, I am. I'm currently checking other parts of your package.
[14:48] <lfaraone> bilalakhtar: also, you need to reference /usr/share/common-licenses/LGPL-2 rather than /usr/share/common-licenses/LGPL. Use © instead of (C). The first line of your package's description MUST not exceed 80 characters. Lintain also reports "spelling-error-in-manpage usr/share/man/man3/oauth.3.gz recieve receive" as well as "liboauth-dev: spelling-error-in-manpage usr/share/man/man3/oauth.3.gz paramater parameter".
[14:49] <lfaraone> bilalakhtar: let me know if you'd rather I post these comments on REVU, poke me when you update the package.
[14:50] <bilalakhtar> lfaraone: ok, put the comments up on revu, in the meantime, I had updated the package on revu twice, since you began. check the lastest version for errors
[14:54] <ari-tczew> in the shop
[14:57] <bilalakhtar> lfaraone: I have made all these changes. uploading now. changes should be visible soon
[14:59] <bilalakhtar> looks like lfaraone has gone away
[15:02] <bilalakhtar> I am also going away, incase you come back, please be patient. shall be back in 20 minutes.
[15:11] <bilalakhtar> lfaraone, the new upload is visible now. When you come back, please see 'em. If you find them to be ok, please advocate. else, comment
=== hannesw_ is now known as hannesw
[15:21] <lfaraone> If someone else has advocated a package, can I be the second advocate *and* uploader?
[15:25] <bilalakhtar> lfaraone: see the package now. http://revu.ubuntuwire.com/p/liboauth
[15:26] <lfaraone> bilalakhtar: building now.
[15:31] <lfaraone> bilalakhtar: looks good. you might want to consider using a patch system rather than modifying the upstream source directly, but what you have is fine.
[15:31] <bilalakhtar> lfaraone: so should I change it to 3.0 (quilt) or leave it like this?
[15:32] <geser> I've seen that the software has also a test suite. I would be good to run it after build
[15:33] <lfaraone> Hm. For some reason REVU does not realize I'm a MOTU, or I don't realize how to work it properly :)
[15:33] <geser> and you can remove the commented out dh_* calls that you don't need
[15:34] <bilalakhtar> lfaraone: yeah, I noticed that earlier. Are you a member of motu team in lp? then it should recognise you
[15:34] <lfaraone> bilalakhtar: Yes, as of yesterday.
[15:34] <geser> lfaraone: I'm not sure if REVU recognizes it itself or if you need to poke an REVU admin
[15:34] <lfaraone> bilalakhtar: By the way, have you noticed http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=496737 ?
[15:34] <ubottu> Debian bug 496737 in wnpp "RFP: liboauth -- secure authentication for desktop and web applications" [Wishlist,Open]
[15:35] <bilalakhtar> lfaraone: oops, no
[15:35] <lfaraone> bilalakhtar: your preference. I personally like using a patch system since it makes uploading new upstream versions easy.
[15:35] <bilalakhtar> lfaraone: let this one go by, I will use quilt in the future
[15:35] <lfaraone> bilalakhtar: no worries. that was opened upstream by the author, and is a "Request for Package", so don't worry, your work is not for naught.
[15:36] <lfaraone> bilalakhtar: you might want to consider uploading the package to Debian rather than Ubuntu. In Debian, it will automatically be synced to Ubuntu. And maybe you can find a MOTU who's also a DD who will upload it for oyu...
[15:37] <lfaraone> geser: where would I find such a creature?
[15:37] <bilalakhtar> lfaraone: Fine, I will upload it to debian afterwards. Let this one go by
[15:38] <bilalakhtar> lfaraone: you became a motu yesterday? wow
[15:42] <bilalakhtar> lfaraone: I am going away. If you find it fit, and are able to (revu is the roadblock right now) then please advocate.
[15:43] <bilalakhtar> thanks for your help and interest!
[15:43] <lfaraone> bfiller: no problem.
[15:43] <geser> lfaraone: usually in this channel, but I don't remember who is an REVU admin
[15:46] <Laney> REVU says, doesn't it?
[15:48] <lfaraone> Laney: hm?
[15:48] <sebner> geser: RainCT persia ?
[15:49] <RainCT> What's up?
[15:49] <RainCT> ok
[15:50] <RainCT> lfaraone: done
[15:51] <Laney> http://revu.ubuntuwire.com/stats
[15:51] <Laney> down there
[15:54] <lfaraone> RainCT: thanks :)
[15:56] <RainCT> no problem :)
[16:21] <ari-tczew> on lucas merges red colorized packages seems to got a new upstream release?
[16:23] <lucas> ari-tczew: yes
[16:23] <ari-tczew> thanks lucas
[16:24] <lfaraone> RainCT: speaking of REVU, if one other MOTU has advocated a package, and I want to advocate it as well, can I go ahead and upload, or does another MOTU have to do the upload after I sign off?
[16:28] <RainCT> lfaraone: Usually the second MOTU to advocate uploads the package (so you) :)
[16:33] <kklimonda> hey guys, do you have a working watch file for projects hosted on google code ?
[16:34] <lfaraone> kklimonda: Yes, one moment please.
[16:35] <lfaraone> kklimonda: http://svn.debian.org/wsvn/python-apps/packages/autokey/trunk/debian/watch
[16:35] <kklimonda> lfaraone: thanks
[16:41] <ari-tczew> zul: I saw that you did sponsor on bug 578729 you can sync package using script syncpackage
[16:41] <ubottu> Launchpad bug 578729 in augeas "Sync augeas 0.7.1-2 (main) from Debian unstable (main)" [Wishlist,New] https://launchpad.net/bugs/578729
[16:41] <ari-tczew> and where is confirmed status if ACKed?
[16:42] <zul> ari-tczew: no i didnt request the sync
[16:43] <ari-tczew> zul: I know, I wrote: you did sponsor (ack comment)
[16:47] <kklimonda> lfaraone: unfortunately it doesn't work anymore :/
[16:57] <kklimonda> didrocks: can we sync vala now that debian has 0.8.1 ?
[16:57] <kklimonda> or do they still have tests disabled?
[17:10] <bilalakhtar> lfaraone: Hi. I saw your comment. do I need to remove the extra lines? is it important?
[17:10] <bilalakhtar> lfaraone: I am currently installing the built deb and testing
[17:12] <kklimonda> hmm, tests are enabled but they fail because buildd has no dbus running..
[17:12] <lfaraone> bilalakhtar: well, it makes for a more readable rules file.
[17:13] <lfaraone> bilalakhtar: but running the test suite is *definitely* a Good Idea™.
[17:13] <bilalakhtar> lfaraone: I am running the test suite right now
[17:13] <bilalakhtar> lfaraone: My question is about the rules file
[17:14] <lfaraone> bilalakhtar: what geser means is that you should call the test suite in the rules file to verify the build worked as expected.
[17:15] <bilalakhtar> ohk
=== yofel_ is now known as yofel
[17:16] <bilalakhtar> lfaraone: how do I do that? fakeroot debian/rules (what should be here) ?
[17:18] <kklimonda> how stupid is launching dbus server at build time to make unittests pass? should I rather just comment out all tests related to dbus?
[17:19] <lfaraone> kklimonda: as long as it doesn't require root, it's fine.
[17:19] <bilalakhtar> lfaraone: how do I run the test suite? fakeroot debian/rules (what should be here) ?
[17:20] <kklimonda> check
[17:20] <lfaraone> kklimonda: he'd add it to the build-stamp rule, right?
[17:20] <BlackZ> lfaraone: when you upload a package, you should set the status of the bug in "fix committed"
[17:22] <lfaraone> BlackZ: In Debian, uploading a package which goes to NEW automatically sets the bug "pending", I'd expect Ubuntu to have something similar, but I could be mistaken.
[17:22] <bilalakhtar> kklimonda: not working. `No rule to make target `check`. Stop.1
[17:22] <kklimonda> lfaraone: hmm.. I'd add check-stamp to install-stamp as you can build package but not be interested in running unit tests..
[17:23] <lfaraone> kklimonda: well, dh_auto_test honors "nocheck" in DEB_BUILD_OPTIONS
[17:24] <kklimonda> lfaraone: shouldn't dh_auto_test be called automatically anyway if you don't override too much?
[17:24] <bilalakhtar> lfaraone: I ran build-stamp. Is that what we need?
[17:24] <lfaraone> kklimonda: he's using the old-style debhelper rules.
[17:24] <BlackZ> lfaraone: nope, when you have uploaded the package and it's in the NEW queue, you should set the status of the bug in "Fix Committed", check that here: https://wiki.ubuntu.com/UbuntuDevelopment/NewPackages
[17:24] <bilalakhtar> yeah, guys, I am not using dh7
[17:24] <BlackZ> "Once the approved package is uploaded, the uploading MOTU will set the bug status to Fix Committed."
[17:25] <lfaraone> bilalakhtar: you neeed to add "dh_auto_test" as a command to the "build-stamp" rule.
[17:26] <lfaraone> BlackZ: If you'd rather, I can get an Archive Admin to cancel the upload so we can solve this policy inconsistency. Or, you can change the flag in the bug yourself, I don't have it on hand.
[17:26] <BlackZ> lfaraone: you can set the status now: https://bugs.launchpad.net/ubuntu/+bug/503436
[17:26] <BlackZ> :)
[17:26] <ubottu> Launchpad bug 503436 in ubuntu "[needs-packaging] autotrash" [Wishlist,In progress]
[17:27] <lfaraone> bilalakhtar: does that make sense?
[17:28] <bilalakhtar> lfaraone: yeah, done, no probs, removing the bummy commented lines now
[17:31] <BlackZ> lfaraone: however I have few packages which needs review/advocation: http://revu.ubuntuwire.com/p/anomos and http://revu.ubuntuwire.com/p/ppa-purge - I'd be glad if you can help me ;)
[17:31] <bilalakhtar> lfaraone: uploading now. should be available soon on revu
[17:32] <kklimonda> hmm, ppa-purge is worth advocation
[17:34] <bilalakhtar> I hate revu for one thing: It never extracts 3.0 (quilt) packages
[17:34] <bilalakhtar> lfaraone: upload available on revu now. just dget http://revu.ubuntuwire.com/revu1-incoming/liboauth-1005121833/liboauth_0.6.0-0ubuntu1.dsc
[17:36] <bilalakhtar> people, will come back after some time (30 minutes) advocate if you find it fit
[17:36] <BlackZ> bilalakhtar: dget -xu is more comfortable
[17:56] <bilalakhtar> lfaraone: Hi there! I m back. Did you see the recent changes?
[18:00] <DeeJay1> hi. Can someone point me to a reasonable guide how to make daily builds if the debian directory for a package is in bzr on launchpad?
[18:02] <bilalakhtar> DeeJay1 I didn't completely understand it. Do you want every push to the branch to be pushed to the ppa also? or you want to build someone else-s branch?
[18:04] <DeeJay1> no, I want a make a script running from cron which would pull the sources from launchpad, build it then push to a ppa
[18:05] <DeeJay1> seems like I should use bzr-builder but Google doesn't return any serious results for me
[18:05] <bilalakhtar> DeeJay1: ohk, thats somewhat long. ask someone else.
[18:06] <DeeJay1> hehe, ok :)
=== nobawk is now known as nobawk|away
[18:27] <bilalakhtar> lfaraone: Are you there?
[19:09] <RainCT> sebner: btw you were right that Java is better than C++, this thing sucks balls :P
[19:10] <sebner> RainCT: hahaha, I told you :D
[19:25] <stevecrozz> I've already built a package in my PPA for karmic, now I want to update it for lucid
[19:26] <stevecrozz> I tried grabbing the source for the karmic package and doing debuild -S again using my new lucid install, but it was rejected
[19:26] <stevecrozz> "File nginx_0.7.65-0ubuntu1~stevecrozz~ppa0.diff.gz already exists in stevecrozz, but uploaded version has different contents"
[19:27] <ari-tczew> stevecrozz: change version to ~ppa1
[19:28] <stevecrozz> ari-tczew: thanks, ill do that
[19:30] <stevecrozz> ari-tczew: is there a better way to maintain current packages for multiple versions of ubuntu?
[19:32] <ari-tczew> stevecrozz: on ppa? I don't think so. You can upload a head package to latest development or stable release, then backporting to older releases versioning ~backport~karmic1 ~backport~jaunty1 etc.
[19:53] <wfaulk> what's the proper way to suggest a piece of software to be included in Ubuntu?
[19:54] <jpds> File a needs-packaging bug.
[19:55] <wfaulk> cool.  thanks.
=== CieD is now known as Ciemon
=== nobawk|away is now known as nobawk