[00:00] <bdrung> tumbleweed: r894: you need to adjust backportpackage
[00:01] <udienz> micahg: ok, he ask me to wait at bug 692087
[00:01] <ubottu> Launchpad bug 692087 in nginx (Ubuntu) "Sync nginx 0.8.53-2 (universe) from Debian unstable (main)" [Wishlist,Fix released] https://launchpad.net/bugs/692087
[00:02] <micahg> udienz: I think that has 2 of the patches
[00:03] <tumbleweed> bdrung: thanks, pushed. BTW please use --author when landing branches
[00:03] <tumbleweed> oh, I suppose that was debcommit
[00:04] <bdrung> tumbleweed: yes (debcommit)
[00:04] <bdrung> tumbleweed: "debcommit --author"?
[00:05] <tumbleweed> no, it doesn't support that, although I remember requesting it at soem point :)
[00:05] <micahg> udienz: he suggests waiting for 0.8.54-1 which should have all the patches
[00:05] <micahg> udienz: also, why are you adding the regression-proposed tag?  That means that package in -proposed regressed functionality
[00:06] <udienz> micahg: hm.. i think it can be used if we proposed SRU.. okay tahs i'll remove it
[00:08] <micahg> udienz: an SRU is proposed by clicking Nominate for Release (if you still can), adding a debdiff and subscribing -sponsors, or proposing a merge into an lp:ubuntu/ branch and being clear about which release it targets
[00:11] <udienz> micahg: ok thanks
[00:18] <bdrung> tumbleweed: merged
[00:20] <tumbleweed> bdrung: thanks. Just noticed I forgot to remove the requestsync import. fixed.
[00:21] <bdrung> tumbleweed: now you can work on all packages integrating config.py ;)
[00:22] <tumbleweed> yeah, hopefully not too many hurdles on the way... (and I don't run out of steam)
[00:23] <bdrung> tumbleweed: i have these things on the todo list:
[00:23] <bdrung> improve debian/copyright
[00:23] <bdrung> backportpackage{,.1}: sort command line args alphabetical
[00:23] <bdrung> support BACKPORTPACKAGE_UPLOAD
[00:23] <bdrung> sponsor-patch: support config.py and add UPDATE_BUILDER and LPINSTANCE support
[00:23] <bdrung> syncpackage: use ubu_email()
[00:24] <ebroder> bdrung: The sorting order on backportpackage's arguments was very deliberate
[00:24] <tumbleweed> yeah, I tend to go for logical orderings, too.
[00:25] <ebroder> And BACKPORTPACKAGE_UPLOAD is difficult because I still dont' think that setting it should result in always automatically uploading - I think uploading should be an opt-in operation
[00:25] <tumbleweed> copyright improvements probably needs tweaks in many files headers
[00:25] <ebroder> (I will grant that using optparse's option groups in backportpackage could help)
[00:25] <bdrung> ebroder: yeah, group them to make the logical order obvious
[00:27] <MTecknology> udienz: hm?
[00:27]  * tumbleweed heads to bed
[00:27] <bdrung> tumbleweed: copyright improvements means that d/copyright needs to be more detailed
[00:28] <tumbleweed> bdrung: in that case, it should be automatically generated (to have any hope of maintainability), which means we need to help licencecheck
[00:29] <bdrung> tumbleweed: this screams for writing a helping tool placed in ubuntu-dev-tools ;)
[00:29] <MTecknology> udienz: oh- nvm
[00:29] <bdrung> tumbleweed: there are probably scripts floating around
[00:30] <bdrung> tumbleweed: the problem of the current d/copyright: according to it i have a copyright on ubuntutools/test/*
[00:31] <tumbleweed> yeah, I've seen some around. I wrote one (that generated most of the current file), but accidently lost it in the bzr mess you witnessed :)
[00:32] <tumbleweed> bdrung: I don't really have a problem with that. it's more descriptive than it was. When I package things I tend to have the copyright as "The $name authors", except for the files they obviously got from outside the project
[00:32] <tumbleweed> otherwise debian/copyright becomes a disaster zone
[00:33] <bdrung> tumbleweed: interesting point
[00:34] <tumbleweed> anyway, I'm still here, /me goes
[00:36] <bdrung> tumbleweed: we should extent wrap-and-sort to support dep5 d/copyright files
[00:40] <bdrung> tumbleweed: bug #692809
[00:40] <ubottu> Launchpad bug 692809 in ubuntu-dev-tools (Ubuntu) "[wrap-and-sort] support debian/copyright in DEP-5 format" [Wishlist,Triaged] https://launchpad.net/bugs/692809
[01:08] <udienz> MTecknology: hi, sorry for delay reply
[06:02] <dnivra> hello. i am trying to package a new upstream version and would like to know should the entire upstream change log be included in debian/changelog ?
[06:02] <ebroder> dnivra: No, the upstream changelog is for upstream changes. debian/changelog is just for changes within the packaging
[06:03] <dnivra> ebroder, okay. well the upstream fixes a bug in ubuntu. so i just can mention it as a sub-point?
[06:04] <ebroder> dnivra: Yeah, that's basically the exception to not putting upstream changes in debian/changelog :)
[06:04] <ebroder> I was just about to get to that
[06:04] <dnivra> ebroder, does this look okay http://paste.ubuntu.com/546175/ ?
[06:05] <dnivra> that's just what I am adding. i have copied the changelog from the previous version and adding it to that.
[06:05] <ebroder> dnivra: Doesn't seem particularly problematic. Although I would mention that Ubuntu doesn't use priority in the changelog
[06:06] <ebroder> Oh wait - is that supposed to be a Debian BTS bug closer or a Launchpad bug closer?
[06:06] <micahg> ebroder: also, it should be LP: #XXXXXX to close a bug in launchpad, Closes: #XXXXX is for Debian
[06:06] <micahg> oops
[06:06] <micahg> dnivra: ^^
[06:06] <dnivra> launchpad closer.
[06:07] <dnivra> thanks for that! did that.
[06:07] <dnivra> well dch -i gave me a standard template with the urgency and so edited it :). will revert to the default.
[06:09] <dnivra> one more question there wouldn't be any problems if i just copy debian/control from old version to new version right?
[06:10] <micahg> dnivra: you should generally just copy the whole debian dir or just use uscan and uupdate if there's a watch file
[06:11] <dnivra> and i am packaging subversion so that is a single binary right?
[06:13] <dnivra> micahg, okay. copied the entire debian directory.
[06:13] <micahg> dnivra: you don't need to close that bug for natty since it was already fix in natty with 1.6.12dfsg-2
[06:14] <dnivra> micahg, the bug wasn't opened for natty at all i think.
[06:14] <micahg> dnivra: the Fix Released task is for the development release (natty in this case)
[06:14] <dnivra> micahg, so should i retain 1.6.12 as version number since natty hasn't incremented the version number?
[06:15] <micahg> dnivra: no, the version should reflect the upstream version, but the upstream tarball needs to be cleaned
[06:15] <dnivra> micahg, cleaned? in the sense?
[06:15] <micahg> dnivra: made dfsg compliant or at least ufsg compliant
[06:16] <micahg> dnivra: are you packaging 1.6.15?
[06:17] <dnivra> micahg, no i am packaging 1.6.13 now. i thought i'll start making a patch to the security issue.
[06:18] <micahg> dnivra: well, 1.6.15 is out according to Debian's watch file, the security debdiffs are probably more important than a new upstream version right now in any case
[06:18] <micahg> dnivra: also, the version in natty already has the security patch for 1.6.12
[06:19] <dnivra> micahg, yeah i did check the upstream version. i did comment on the launchpad bug page too. thought i shouldn't waste time if it is a security bug.
[06:19] <dnivra> micahg, so you think maybe i should just backport it from 1.6.12 in natty?
[06:19] <micahg> dnivra: that's the only way :)
[06:19] <dnivra> micahg, only way? sorry didn't get you? why not package the latest source?
[06:20] <micahg> dnivra: we generally don't take new versions in stable releases unless it's in -backports
[06:20] <dnivra> micahg, ubuntu policy eh :). not very familiar with that. i know a bit about development release cycle; that's about it.
[06:21] <micahg> !sru | dnivra
[06:21] <ubottu> dnivra: Stable Release Update information is at http://wiki.ubuntu.com/StableReleaseUpdates
[06:21] <micahg> dnivra: although, you're actually looking for this: https://wiki.ubuntu.com/SecurityTeam/UpdatePreparation
[06:22] <dnivra> micahg, yeah i went through the above link.
[06:23] <dnivra> micahg, guess i didn't notice the "make only minimal changes" part :).
[06:23] <micahg> :)
[06:25] <dnivra> isn't it enough to download the orig.tar.gz, diff.gz and .dsc file from lauchpad. or should i download the latest bzr branch?
[06:25] <micahg> dnivra: up to you which tools  you work better with
[06:26] <udienz> dnivra: i user grab-merge from ubuntu-dev-tools
[06:26] <udienz> dnivra: and i don't need to latest branch
[06:27] <micahg> dnivra: take a look at pull-lp-source in ubuntu-dev-tools, you can get the natty and maverick builds
[06:27] <dnivra> udienz, grab-merge will automatically download the natty packages?
[06:27] <dnivra> micahg, will do. thanks!
[06:27] <micahg> dnivra: no, grab-merge is for merging from Debian
[06:28] <dnivra> oh okay. don't think debian is patching this one. let me check once more.
[06:28] <micahg> dnivra: Debian patched it already, that's why it's fixed in natty :)
[06:28] <udienz> dnivra: ow.. sorry if you want to packaging SRU
[06:29] <dnivra> micahg, oh okay! i don't remember clearly :). was all sleepy when i checked on this today morning at about 5:30 :)
[06:30] <dnivra> udienz, knowledge never hurt. i never knew you could do that. thanks!
[06:30] <dnivra> one question does grab-merge download the latest development version? or latest stable version?
[06:31] <micahg> dnivra: grab-merge grabs from devel release and debian unstable
[06:31] <evaluate> hello
[06:31] <udienz> dnivra: grab-merge downloaded latest debian and latest ubuntu
[06:31] <evaluate> any tip on how I could solve a "could not read symbols" error in natty? http://launchpadlibrarian.net/60988724/buildlog_ubuntu-natty-i386.clipit_1.3.9-1ppa1natty1_FAILEDTOBUILD.txt.gz
[06:31] <dnivra> udienz, micahg okay. thanks a lot!
[06:35] <evaluate> is it the order in which I pass the flags? I can't really explain this... :-\
[06:35] <udienz> evaluate: what's package?
[06:35] <udienz> fbfs?
[06:35] <evaluate> udienz, ^^
[06:36] <evaluate> no, it's a PPA I have un launchpad, I pasted the link to the buildlog in my previous reply
[06:36] <evaluate> s/un/on/
[06:37] <micahg> evaluate: PPA packaging help is in #ubuntu-packaging unless you're staging for the archive
[06:37] <evaluate> micahg, ok :-)
[07:17] <dholbach> good morning!
=== hannesw__ is now known as hannesw
[09:12] <geser> dholbach: is it a bug on https://wiki.ubuntu.com/UbuntuDevelopers that MOTUs don't have any voting rights?
[09:13] <dholbach> geser, yes
[09:13] <dholbach> geser, I think we should simplify this document a lot - there's too much repetition in there - instead it could talk about "this is what ~ubuntu-dev people are" and then just explain differences
=== nhandler_ is now known as nhandler
=== lifeless_ is now known as lifeless
=== evilvish is now known as group
=== group is now known as evilvish
=== evilvish is now known as whois
=== whois is now known as vish
=== Philip6 is now known as Philip5
=== duanedes1gn is now known as duanedesign
=== yofel_ is now known as yofel
=== jussi01 is now known as jussi
=== apachelogger_ is now known as apachelogger
[13:48] <udienz> dholbach: thanks for review my merge branch and merge packages. both merge already submit again
[13:49] <dholbach> udienz, you could try to ask for another review in #ubuntu-desktop - I was merely stating the obvious, they know much better to review gtkrc changes :)
[13:49] <dholbach> thanks a lot for your hard work - I noticed you've been doing a lot of stuff in the last time
[13:51] <udienz> dholbach: :) right. i spend more time this week. okay i'll ask ubuntu-desktop
[13:52] <dholbach> excellent, thanks a lot
[13:53] <highvoltage> good morning
[13:53] <udienz> morning highvoltage
[14:45] <akoskm> RAOF, I managed to build it with pbuilder, thank you for your suggestions
[15:16] <udienz> brung: around?
[15:19] <udienz> rrr
[15:19] <udienz> bdrung: around?
[15:19] <udienz> typos
[15:20] <geser> udienz: use tab-completion
[15:20] <geser> if your irc client supports it
[15:20] <udienz> geser: hehe, i use pidgin
[15:22] <geser> pidgin doesn't support it for irc?
[15:23] <udienz> geser: supported, but wow i don't know this feature. new knowledge
[15:24] <udienz> geser: i write a changelog at here http://paste.ubuntu.com/546289/, it's coreect?
[15:25] <udienz> rr correct?
[15:26] <geser> I don't know the current delta, but it looks ok so far
[15:30] <BlackZ> udienz: is it worth merging bash? currently most of the changes in the latest package in Debian unstable are already applied in our last Ubuntu version..
[15:31] <udienz> BlackZ: not all, sudo hint not apllied at Debian
[15:32] <tumbleweed> geser: [u-d-t] lpapicache's metaclass approach makes it tricky to use staging, as it needs the lp server name at import time. I'm doing this hack: http://bazaar.launchpad.net/~stefanor/ubuntu-dev-tools/config-681693/revision/904 (requestsync:78)
[15:32] <BlackZ> udienz: I mean: is it worth merging a new version from Debian unstable? currently our last version of the package in Ubuntu already has most of the changes applied to the last version of the package in Debian
[15:34] <udienz> BlackZ: hm.. i think it is capable, but its better when it sync
[15:36] <BlackZ> udienz: it doesn't mean we have to drop _all_ of our currently Ubuntu delta
[15:38] <BlackZ> udienz: I'd wait for a new upstream release and/or a new Debian package revision containing importat change(s)
[15:40] <udienz> BlackZ: hm.... whats the mean "important?"
[15:40] <udienz> bug?
[15:41] <udienz> BlackZ: sorry, if i ask about "important" but i'm really not understant with "important" criteria
[15:41] <BlackZ> udienz: yes, a bug fixed is an example
[15:42] <TeTeT> how can I tell a package to use the debian/patches before building? In karmic and beyond it works automagically, but hardy's package has had no such directory
[16:03] <geser> v3 src package?
[16:18] <geser> tumbleweed: set ubuntutools.lp.service='staging' before you import the lpapicache module (http://paste.ubuntu.com/546304/)
[16:18] <tumbleweed> geser: that's what I'm doing
[16:18] <tumbleweed> it gets messy, but I can't think of a better fix
[16:19] <bdrung> udienz: now
[16:19] <geser> the other option would be to remove the resource_type checking and trust the dev to pass the right object but IMHO that's worse
[16:19] <udienz> bdrung: yup
[16:20] <tumbleweed> geser: or normalize the URLS / query where we are connected to before comparing resource_type
[16:24] <geser> tumbleweed: right, one could use 'resource_type_link' from the Launchpad object to deduce the service-root and use this and build the resource type during runtime
[16:25] <geser> tumbleweed: should I prepare a commit with this change so you can merge it into your branch?
[16:26] <tumbleweed> I can land the requestsync changes in trunk anytime, although bdrung will probably want to look at them first
[16:29] <geser> tumbleweed: what do you think of using the launchpadlib.Launchpad() class directly in lpapicache and let it set-up the token if necessary?
[16:30] <geser> that would also have the benefit that all tokens are stored in the same location (currently manage-credentials stores them in a different location)
[16:30] <tumbleweed> geser: did you see the bugs about the launchpadlib 1.8.0 api breakage? login api changes are afoot
[16:31] <geser> tumbleweed: no, where?
[16:35] <tumbleweed> bug 686690. Sorry must run. chat later.
[16:35] <ubottu> Launchpad bug 686690 in launchpadlib "1.8.0 breaks login_with() API compat with existing credentials files, and forces keyrings" [High,Triaged] https://launchpad.net/bugs/686690
[16:38] <bdrung> tumbleweed: you can push things directly to trunk if you won't introduce regression (trunk should be always usable/releasable). big changes or new features should use merge requests.
[16:38] <bdrung> tumbleweed: i will review the changes in both cases
[16:54] <bdrung> tumbleweed: for every bug that is reported, we should create a testcase if possible
[16:55] <bdrung> tumbleweed: can we add a basic test for every script that runs "script --help" or similar to check there are grave bugs in the option parsing
[16:55] <bdrung> ?
[16:56] <geser> bdrung: how would a possible test-case for bug 693060 look like?
[16:56] <ubottu> Launchpad bug 693060 in ubuntu-dev-tools (Ubuntu) "lpapicache metaclasses make using staging messy" [Undecided,Triaged] https://launchpad.net/bugs/693060
[16:58] <bdrung> geser: we need two types of testcases: one that is run on the build and one that needs to be run manually with online access
[16:58] <bdrung> geser: we could use staging for doing the second type of tests
[17:17] <hakermania> Hey...
[17:19] <geser> bdrung: what's the minimum supported python version for u-d-t?
[17:19] <bdrung> geser: >= 2.5
[17:20] <geser> ok, so no usage of str.format()
[17:26] <geser> bdrung: when do you except that we can bump it to >= 2.6?
[17:26] <bdrung> geser: once 2.6 is the default in unstable
[17:27] <geser> so after the next Debian release?
[17:31] <bdrung> geser: probably
=== txwikinger2 is now known as txwikinger
=== Guest43017 is now known as Lutin
[19:16] <tumbleweed> geser: thanks
[19:16] <tumbleweed> sorry, I got caught with some nasty packet loss on my DSL line 15 minutes before I had to go out to dinner.
[19:17] <bdrung> tumbleweed: you broke sponsor-patch. now i have to migrate it to use config.py
[19:18] <tumbleweed> bdrung: yay :/
[19:19] <tumbleweed> bdrung: broken in trunk?
[19:19] <bdrung> tumbleweed: yes
[19:20] <bdrung> sponsor-patch: Error: Unsupported builder specified: None. Only pbuilder, pbuilder-dist and sbuild are supported.
[19:20] <tumbleweed> oh, I saw it was passing an option, I didn't check if that option could be None
[19:21] <tumbleweed> s/option/argument/
[19:21] <bdrung> tumbleweed: don't worry. i will fix it.
[19:22] <bdrung> tumbleweed: shouldn't --lpinstance have an short option, too?
[19:22] <tumbleweed> I removed th eshort option, because it's really not some thing people are going to use much
[19:22] <bdrung> tumbleweed: except for testcases
[19:22] <tumbleweed> (but I'm overjoyed to have it, testing was a pain in the past)
[19:23] <tumbleweed> ebroder: your script, any opinion?
[19:24] <bdrung> tumbleweed: it had -l
[19:25] <tumbleweed> bdrung: ack-sync has a -l that means something else
[19:26] <bdrung> tumbleweed: ack-sync doesn't count, because it's not installed by default (should become part of sponsor-patch)
[19:27] <tumbleweed> is that lvm root directory option not something we are going to want elsewhere?
[19:28] <bdrung> tumbleweed: alternative -i
[19:31] <tumbleweed> bdrung: sure. I can do that
[19:32] <bdrung> tumbleweed: but i would prefer -l
[19:33] <bdrung> tumbleweed: looking at the --lvm option, i am not sure if we really want that option (can't we determine that directly?)
[19:33] <tumbleweed> ok, I've made my case and I'm happy to restore it. re --lvm, yeah one would assume so
[19:35] <ebroder> bdrung: Sorry, what's going on? This is -l vs. just --lpinstance?
[19:36] <tumbleweed> ebroder: I renamed --launchpad to --lpinstance to match the variables we are using
[19:36] <ebroder> tumbleweed: Ok, I guess. Is that consistent with other scripts that have that sort of option?
[19:37] <bdrung> ebroder: --lpinstance is a better name than --launchpad, because requestsync uses --lp whit a different meaning
[19:37] <ebroder> bdrung: Ok, sure
[19:38] <tumbleweed> I also dropped -l, but bdrung wants it back.
[19:39] <tumbleweed> grr, my DSL modem is handling this summer heat worse than I am
[19:39] <bdrung> tumbleweed: and i tried to build an igloo today :)
[19:39] <ebroder> Yeah, I've got no strong opinions on that one. I'm honestly not entirely sure that having a --lpinstance option for backportpackage makes sense. Can you even make interesting soyuz changes on staging?
[19:40] <tumbleweed> good point
[19:41] <ebroder> I probably added it because the last script I wrote was backport-helper for u-archive-tools, which makes malone queries. So it was useful to use staging for testing
[20:46] <bdrung> tumbleweed: pushed my fix. please review it
[20:56] <tumbleweed> bdrung: nice. missed a comma in SEE ALSO in the manpage :)
[20:57] <tumbleweed> btw, done ack-sync and grab-attachments in my branch
[20:59] <bdrung> tumbleweed: pushed comma
[20:59] <hakermania> Hey,,,,, anybody willing to review: http://revu.ubuntuwire.com/p/wallch ? Thx :))
[20:59] <bdrung> tumbleweed: now i know who stole my comma ^. :D
[21:00] <tumbleweed> heh
[21:01] <bdrung> tumbleweed: ack-sync isn't work getting config support (it should be merged into sponsor-patch)
[21:02] <tumbleweed> bdrung: I know, which is why I didn't spend much time on it.
[21:02] <bdrung> tumbleweed: can't you create one branch per updated script?
[21:03] <bdrung> tumbleweed: that makes reviewing easier
[21:03] <tumbleweed> bdrung: I can, I was just being lazy.
[21:04] <bdrung> tumbleweed: is your branch ready for the merge?
[21:04] <tumbleweed> sure
=== hanska is now known as dapal
=== s1aden is now known as sladen