bdrung | tumbleweed: r894: you need to adjust backportpackage | 00:00 |
---|---|---|
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:01 |
micahg | udienz: I think that has 2 of the patches | 00:02 |
tumbleweed | bdrung: thanks, pushed. BTW please use --author when landing branches | 00:03 |
tumbleweed | oh, I suppose that was debcommit | 00:03 |
bdrung | tumbleweed: yes (debcommit) | 00:04 |
bdrung | tumbleweed: "debcommit --author"? | 00:04 |
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:05 |
udienz | micahg: hm.. i think it can be used if we proposed SRU.. okay tahs i'll remove it | 00:06 |
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:08 |
udienz | micahg: ok thanks | 00:11 |
bdrung | tumbleweed: merged | 00:18 |
tumbleweed | bdrung: thanks. Just noticed I forgot to remove the requestsync import. fixed. | 00:20 |
bdrung | tumbleweed: now you can work on all packages integrating config.py ;) | 00:21 |
tumbleweed | yeah, hopefully not too many hurdles on the way... (and I don't run out of steam) | 00:22 |
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:23 |
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:24 |
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:25 |
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:27 |
tumbleweed | bdrung: in that case, it should be automatically generated (to have any hope of maintainability), which means we need to help licencecheck | 00:28 |
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:29 |
bdrung | tumbleweed: the problem of the current d/copyright: according to it i have a copyright on ubuntutools/test/* | 00:30 |
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:31 |
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:32 |
bdrung | tumbleweed: interesting point | 00:33 |
tumbleweed | anyway, I'm still here, /me goes | 00:34 |
bdrung | tumbleweed: we should extent wrap-and-sort to support dep5 d/copyright files | 00:36 |
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 | 00:40 |
udienz | MTecknology: hi, sorry for delay reply | 01:08 |
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:02 |
dnivra | ebroder, okay. well the upstream fixes a bug in ubuntu. so i just can mention it as a sub-point? | 06:03 |
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:04 |
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:05 |
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:06 |
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:07 |
dnivra | one more question there wouldn't be any problems if i just copy debian/control from old version to new version right? | 06:09 |
micahg | dnivra: you should generally just copy the whole debian dir or just use uscan and uupdate if there's a watch file | 06:10 |
dnivra | and i am packaging subversion so that is a single binary right? | 06:11 |
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:13 |
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:14 |
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:15 |
micahg | dnivra: are you packaging 1.6.15? | 06:16 |
dnivra | micahg, no i am packaging 1.6.13 now. i thought i'll start making a patch to the security issue. | 06:17 |
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:18 |
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:19 |
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:20 |
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:21 |
dnivra | micahg, yeah i went through the above link. | 06:22 |
dnivra | micahg, guess i didn't notice the "make only minimal changes" part :). | 06:23 |
micahg | :) | 06:23 |
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:25 |
udienz | dnivra: i user grab-merge from ubuntu-dev-tools | 06:26 |
udienz | dnivra: and i don't need to latest branch | 06:26 |
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:27 |
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:28 |
dnivra | micahg, oh okay! i don't remember clearly :). was all sleepy when i checked on this today morning at about 5:30 :) | 06:29 |
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:30 |
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:31 |
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:35 |
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:36 |
micahg | evaluate: PPA packaging help is in #ubuntu-packaging unless you're staging for the archive | 06:37 |
evaluate | micahg, ok :-) | 06:37 |
dholbach | good morning! | 07:17 |
=== hannesw__ is now known as hannesw | ||
geser | dholbach: is it a bug on https://wiki.ubuntu.com/UbuntuDevelopers that MOTUs don't have any voting rights? | 09:12 |
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 | 09:13 |
=== 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 | ||
udienz | dholbach: thanks for review my merge branch and merge packages. both merge already submit again | 13:48 |
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:49 |
udienz | dholbach: :) right. i spend more time this week. okay i'll ask ubuntu-desktop | 13:51 |
dholbach | excellent, thanks a lot | 13:52 |
highvoltage | good morning | 13:53 |
udienz | morning highvoltage | 13:53 |
akoskm | RAOF, I managed to build it with pbuilder, thank you for your suggestions | 14:45 |
udienz | brung: around? | 15:16 |
udienz | rrr | 15:19 |
udienz | bdrung: around? | 15:19 |
udienz | typos | 15:19 |
geser | udienz: use tab-completion | 15:20 |
geser | if your irc client supports it | 15:20 |
udienz | geser: hehe, i use pidgin | 15:20 |
geser | pidgin doesn't support it for irc? | 15:22 |
udienz | geser: supported, but wow i don't know this feature. new knowledge | 15:23 |
udienz | geser: i write a changelog at here http://paste.ubuntu.com/546289/, it's coreect? | 15:24 |
udienz | rr correct? | 15:25 |
geser | I don't know the current delta, but it looks ok so far | 15:26 |
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:30 |
udienz | BlackZ: not all, sudo hint not apllied at Debian | 15:31 |
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:32 |
udienz | BlackZ: hm.. i think it is capable, but its better when it sync | 15:34 |
BlackZ | udienz: it doesn't mean we have to drop _all_ of our currently Ubuntu delta | 15:36 |
BlackZ | udienz: I'd wait for a new upstream release and/or a new Debian package revision containing importat change(s) | 15:38 |
udienz | BlackZ: hm.... whats the mean "important?" | 15:40 |
udienz | bug? | 15:40 |
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:41 |
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 | 15:42 |
geser | v3 src package? | 16:03 |
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:18 |
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:19 |
tumbleweed | geser: or normalize the URLS / query where we are connected to before comparing resource_type | 16:20 |
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:24 |
geser | tumbleweed: should I prepare a commit with this change so you can merge it into your branch? | 16:25 |
tumbleweed | I can land the requestsync changes in trunk anytime, although bdrung will probably want to look at them first | 16:26 |
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:29 |
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:30 |
geser | tumbleweed: no, where? | 16:31 |
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:35 |
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:38 |
bdrung | tumbleweed: for every bug that is reported, we should create a testcase if possible | 16:54 |
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:55 |
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:56 |
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 | 16:58 |
hakermania | Hey... | 17:17 |
geser | bdrung: what's the minimum supported python version for u-d-t? | 17:19 |
bdrung | geser: >= 2.5 | 17:19 |
geser | ok, so no usage of str.format() | 17:20 |
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:26 |
geser | so after the next Debian release? | 17:27 |
bdrung | geser: probably | 17:31 |
=== txwikinger2 is now known as txwikinger | ||
=== Guest43017 is now known as Lutin | ||
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:16 |
bdrung | tumbleweed: you broke sponsor-patch. now i have to migrate it to use config.py | 19:17 |
tumbleweed | bdrung: yay :/ | 19:18 |
tumbleweed | bdrung: broken in trunk? | 19:19 |
bdrung | tumbleweed: yes | 19:19 |
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:20 |
tumbleweed | s/option/argument/ | 19:21 |
bdrung | tumbleweed: don't worry. i will fix it. | 19:21 |
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:22 |
tumbleweed | ebroder: your script, any opinion? | 19:23 |
bdrung | tumbleweed: it had -l | 19:24 |
tumbleweed | bdrung: ack-sync has a -l that means something else | 19:25 |
bdrung | tumbleweed: ack-sync doesn't count, because it's not installed by default (should become part of sponsor-patch) | 19:26 |
tumbleweed | is that lvm root directory option not something we are going to want elsewhere? | 19:27 |
bdrung | tumbleweed: alternative -i | 19:28 |
tumbleweed | bdrung: sure. I can do that | 19:31 |
bdrung | tumbleweed: but i would prefer -l | 19:32 |
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:33 |
ebroder | bdrung: Sorry, what's going on? This is -l vs. just --lpinstance? | 19:35 |
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:36 |
bdrung | ebroder: --lpinstance is a better name than --launchpad, because requestsync uses --lp whit a different meaning | 19:37 |
ebroder | bdrung: Ok, sure | 19:37 |
tumbleweed | I also dropped -l, but bdrung wants it back. | 19:38 |
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:39 |
tumbleweed | good point | 19:40 |
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 | 19:41 |
bdrung | tumbleweed: pushed my fix. please review it | 20:46 |
tumbleweed | bdrung: nice. missed a comma in SEE ALSO in the manpage :) | 20:56 |
tumbleweed | btw, done ack-sync and grab-attachments in my branch | 20:57 |
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 | 20:59 |
tumbleweed | heh | 21:00 |
bdrung | tumbleweed: ack-sync isn't work getting config support (it should be merged into sponsor-patch) | 21:01 |
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:02 |
bdrung | tumbleweed: that makes reviewing easier | 21:03 |
tumbleweed | bdrung: I can, I was just being lazy. | 21:03 |
bdrung | tumbleweed: is your branch ready for the merge? | 21:04 |
tumbleweed | sure | 21:04 |
=== hanska is now known as dapal | ||
=== s1aden is now known as sladen |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!