[02:12] <micahg> cjwatson: for gnash, youtube worked, some other sites don't but I think this is the same with the current version, so I'm uploading the patch you gave me
[02:17] <micahg> cjwatson: I'm subscribed and will keep an eye  out for any issues
[06:31] <kovid> whois kovid
[07:07] <dholbach> good morning
[09:11] <thelinuxer> hi guys, I have a question about version numbering (that version we put in the change log) when I am building from a mercurial repo. How should it be written ?
[09:14] <geser> is the mercurial revision number monotonic incrementing?
[09:14] <thelinuxer> geser: can u know from here ? http://hg.atheme.org/users/desowin/gdigi/
[09:15] <thelinuxer> i have little knowledge of mercurial
[09:16] <chrisccoulson> thelinuxer, look at the version number i use for firefox nightlies (which come from mercurial) ;)
[09:17] <thelinuxer> chrisccoulson: ok will check it out
[09:17] <thelinuxer> i just want to know if there is some kind of standard when building packages from repos in general
[09:18] <jtaylor> it depends on the repo, e.g. with git one uses dates as the hash is random
[09:18] <jtaylor> with svn the revision number is fine
[09:19] <jtaylor> bzr too I think
[09:19] <thelinuxer> chrisccoulson: jtaylor and with hg it date + revision number from what I see ...
[09:19] <chrisccoulson> thelinuxer, eg, for "194:dec7a1546064", the "194" is the revision, which is monotonic
[09:19] <geser> thelinuxer: the only requirement is the version string has always to increase
[09:20] <chrisccoulson> so, for that revision, i would add "~hg20110829r194" (with the date coming from http://hg.atheme.org/users/desowin/gdigi/rev/dec7a1546064)
[09:21] <thelinuxer> chrisccoulson: without -ubuntu1 at the end ?
[09:21] <jtaylor> I'd add the hash to the changelog to keep the version short
[09:21] <thelinuxer> r there any tools to pull this from the repo and add the version number automatically ?
[09:22] <geser> so you can either use 0.2.0+hg20110829r194 or 0.2.1~hg20110829r194. assuming 0.2.0 is current and 0.2.1 will be next (0.2.0+hg sorts after 0.2.0; 0.2.1~hg sorts before 0.2.1)
[09:23] <geser> that's for the upstream version, append the usual -0ubuntu1 as revision
[09:23] <thelinuxer> jtaylor: geser chrisccoulson that's gr8 thanx a lot guys
[09:46] <tumbleweed> for mercurial, it's generally safe to use the "revision" number (commit count), if the source is managed in a central repo (svn-style)
[09:46] <cjwatson> micahg: *nod* fair enough, thanks
[11:06] <thelinuxer> I read here https://wiki.ubuntu.com/MOTU/Packages/REVU that uploading my new package to debian mentors is the way to go
[11:06] <thelinuxer> I find here http://mentors.debian.net/package/gdigi that the name of the uploader isn't me :D
[11:06] <thelinuxer> is this normal ?
[11:08] <Laney> someone else had already uploaded it to mentors
[11:08] <Laney> you should coordinate with that person
[11:08] <Laney> and certainly fix all of the lintian problems reported
[11:10] <thelinuxer> Laney: ok i guess it uploaded some of my stuff to this page
[11:10] <thelinuxer> currently when i use dput it says that the package is already uploaded
[11:10] <Laney> use dput -f if you have made changes
[11:11] <thelinuxer> ok will try that, thanx
[11:12] <Laney> but email the other guy and find out what he's doing
[11:12] <thelinuxer> ok will do so , thanks again
[12:33] <tumbleweed> Laney, bdrung: Should we turn launchpad DSD blacklisting into non-fatal errors in syncpackage for now? (bug 841372)
[12:35] <bdrung> tumbleweed: i think no as long as we have a way to force the sync.
[12:35] <tumbleweed> we don't. We only allow force overriding when fakesyncing
[12:36] <bdrung> hm
[12:36] <bdrung> i don't like adding workarounds
[12:37] <tumbleweed> I don't know how many packages are incorrectly blacklisted, but only archive-admins can un-blacklist them again
[12:37] <Laney> what's an auto blacklist?
[12:38] <tumbleweed> Laney: launchpad automatically blacklists syncs when the version in Ubuntu is newer than Debian, but it appears to be buggy
[12:39] <tumbleweed> http://bazaar.launchpad.net/~launchpad-pqm/launchpad/devel/view/head:/lib/lp/registry/model/distroseriesdifference.py#L760
[12:41] <Laney> how could you sync when the target has a newer version anyway?
[12:41] <tumbleweed> I think it does it to get it off the front page of +localpackagediffs
[12:42] <Laney> are we more interested in Blacklisted always?
[12:42] <tumbleweed> I haven't tried syncing a package that was ignored (DSD blacklisted) from the web interface, but it doesn't look like it'd stop me
[12:43] <Laney> always seems like it should be fatal and current a warning (require overriding)?
[12:43] <tumbleweed> yeah, maybe blacklisted always should be a hard-error, and blacklisted current should be a warning
[12:43] <tumbleweed> ^5
[12:44] <tumbleweed> ah, no the checkbox on the web interface *is* greyed out when it's blacklisted current
[12:44]  * tumbleweed wonders if it'll even let us do the sync...
[12:45] <Laney> you mean your link from the bug?
[12:45] <Laney> not greyed out here
[12:46] <tumbleweed> Laney: ah, but many are here https://launchpad.net/ubuntu/oneiric/+localpackagediffs?field.name_filter=&field.package_type=all&field.package_type-empty-marker=1
[12:47]  * Laney wonders what "Upgrade Packages" does
[12:47]  * tumbleweed too
[12:49] <Laney> the greyed ones there are all > debian AFAICS
[12:49] <Laney> I wonder why the ones that are = debian aren't greyed...
[12:49] <Laney> is this implemented by blacklisting current?
[12:51] <tumbleweed> that's a question for bigjools
[12:52] <Laney> I guess I don't care about the implementation, but versions that are the same shouldn't be available for syncing
[12:52] <Laney> wonder what happens if I do one
[12:52] <tumbleweed> I've found some of the answers to things like that by reading https://dev.launchpad.net/HelpOnActions?action=fullsearch&context=180&value=derivative+distributions
[12:52]  * Laney gets scared
[12:56] <Laney> hah, it got rejected thankfully
[12:57] <tumbleweed> I added a note about that to the bug
[12:57] <Laney> nice
[12:58] <tumbleweed> urgh, turning BLACKLISTED_CURRENT into an overrideable warning requires some refactoring
[13:41] <tumbleweed> Laney: ok, launchpad allowed me to override the BLACKLISTED_CURRENT. Committing
[13:41] <Laney> nice
[13:41] <Laney> does always work properly?
[13:42] <tumbleweed> you mean does launchpad block the sync? I don't want to test that :P
[13:44] <Laney> no, i mean clientside
[13:44] <tumbleweed> yes
[13:44] <Laney> happy days
[13:44] <Laney> so we can import sync-blacklist.txt?
[13:44] <tumbleweed> hrm, DSD comments hang around post sync
[13:45] <tumbleweed> https://launchpad.net/ubuntu/oneiric/+localpackagediffs?field.name_filter=libsdl-sound1.2&field.package_type=all
[13:45] <tumbleweed> Laney: I don't think that's worth doing until all syncing is done through syncpackage
[13:45] <tumbleweed> but yes, blacklist() is available in the API
[13:46] <Laney> i'd like to see the text file be generated from launchpad
[13:47] <tumbleweed> that's something to take up with the archive admins
[13:48] <Laney> well indeed, blacklisting is their domain
[13:48] <Laney> I am just saying that we should move things into LP as far as possible to make the syncpackage workflow go
[13:51] <cjwatson> if somebody wants to write a script that generates a suitable text file from Launchpad, I'd be happy to move the existing stuff into LP and deploy that script
[13:51] <cjwatson> I'd like to make sure that there's essentially no period of time without a blacklist though
[13:52] <Laney> do you get an interface on the website to manage blacklisting?
[13:52] <cjwatson> I think so
[13:52] <Laney> ok, that makes the tool easier
[13:52] <cjwatson> I have an "Add comment" AJAX thing
[13:52] <cjwatson> do you?
[13:53] <wgrant> Everyone gets "Add comment"
[13:53] <wgrant> Only archive admins get the three radio buttons above that.
[13:53] <cjwatson> oh yes, I was looking at the wrong bit
[13:53] <wgrant> (at least they used to be above that, but it was a while ago)
[13:53] <cjwatson> I have "Ignored: ( ) No ( ) All versions ( ) These versions"
[13:54] <wgrant> Right, that's the blacklist status.
[13:54] <cjwatson> sorry, that's ago)
[13:54] <Laney> sounds adequate
[13:54] <cjwatson> sorry, that's "Ignored: (o) No ( ) All versions ( ) These versions" but hopefully YKWIM
[13:54] <Laney> so we just need to generate sync-blacklist.txt from the blacklisted_always entries for the transitional period
[13:55] <cjwatson> I think we should probably not transfer the blacklist entries that are just because of orig mismatches
[13:55] <cjwatson> I would rather have the new auto-sync.py (which I've started, though only barely) figure that out for itself
[13:55] <cjwatson> they were always a pain to manage anyway
[13:55] <wgrant> Please file bugs for any API inadequacies you run into.
[13:56] <wgrant> eg. difficulties getting hashes and stuff.
[13:56] <tumbleweed> yeah, we all see the radio boxes, they are just read-only for non-AAs
[13:56] <cjwatson> I should be using copyPackages rather than copyPackage for mass sync, yes?
[13:57] <cjwatson> "If any of the requested copies cannot be performed, the whole operation will fail. There will be no partial changes of the destination archive." possibly slightly odd decision there
[13:57] <wgrant> cjwatson: Yes. Fewer requests, same result.
[13:57] <wgrant> Erm. It still says that?
[13:57] <wgrant> That hasn't been the case for months :(
[13:57] <cjwatson> yes.  https://launchpad.net/+apidoc/devel.html
[13:58] <wgrant> It creates a separate job for each copy now. The only checks performed up-front are permissions.
[13:58] <cjwatson> OK, good - that would be a recipe for irritation
[13:58] <wgrant> Atomicity is useful sometimes.
[13:58] <wgrant> But not for autosyncs.
[13:58] <cjwatson> quite.
[13:58] <tumbleweed> cjwatson: how do you plan to handle sync-request bug closing? the only way to tell if the sync was successful is to wait for the mail
[13:59] <cjwatson> tumbleweed: that seems not much worse than bugs being closed on source upload before we know if it built
[13:59] <wgrant> We'll be processing copies much more frequently in the next week or so.
[13:59] <wgrant> Currently they're done every 5 minutes along with lots of other jobs. I think that may be moving up to minutely.
[14:00] <tumbleweed> cjwatson: ah, suppose so
[14:00] <cjwatson> I think what I'd like to see is a bugs parameter on copyPackage so that LP can close those bugs if the copy succeeds
[14:00] <cjwatson> for autosyncs I don't care
[14:00] <wgrant> That sounds reasonable.
[14:00] <wgrant> cjwatson: You've not filed the copyPackages documentation issue?
[14:01] <cjwatson> no, can do now
[14:01]  * wgrant is already there.
[14:01] <cjwatson> OK.  I'll file one for copyPackage bugs
[14:01] <wgrant> Thanks.
[14:02] <wgrant> Changelog bug closing just needs one last fix. And announcement emails should already be fixed... no more issues there?
[14:03] <wgrant> Bug #841842
[14:05] <tumbleweed> wgrant: attribution for sponsorship, and came across a problem with the auto-blacklisting on the weekend,
[14:05] <wgrant> Yeah, I saw those. I mean with announcements.
[14:05] <wgrant> Since there have been a few issues there :)
[14:06] <tumbleweed> I think NEW didn't generate announcemets (there's a bug filed)
[14:06] <wgrant> Indeed.
[14:08] <thelinuxer> a quick questin. should i add a project on launchpad for the package I am builing ? as I doing some changes to it too...
[14:08] <Laney> tumbleweed: What was that bug you filed about the DSD API?
[14:08] <Laney> I don't see a way to get the source package name from a dsd object
[14:08] <Laney> thelinuxer: no need to do that
[14:09] <tumbleweed> Laney: that querying blacklisting was needlesly hard (had to separatly query for CURRENT and ALWAYS and comments)
[14:09] <Laney> ah
[14:09] <cjwatson> wgrant: bug 841849 - hope that's clear enough
[14:09] <thelinuxer> Laney: i need some place for my code, at least until they accept my patch upstream. am i right ?
[14:10] <cjwatson> thelinuxer: for small changes, just putting them in a debian/patches/ file in the source package is often enough
[14:10] <cjwatson> I wouldn't bother with creating a project unless I were making fairly extensive changes
[14:10] <wgrant> Laney: sourcepackagename and status are exported in trunk, but not quite deployed yet.
[14:10] <wgrant> Laney: Hopefully tomorrow.
[14:10] <thelinuxer> cjwatson: ok cool
[14:11] <Laney> wgrant: oh, sweet. /me stops filing a bug then
[14:11] <wgrant> Laney: Bug #833080
[14:11] <Laney> hah
[14:12]  * Laney awaits that fix then
[14:12] <wgrant> Could have deployed it today, but I forgot. :(
[21:07] <tumbleweed> ScottK: any thoughts on sbte's closing of all the old emesene bugs and telling people to install a new version from his ppa?
[21:07] <tumbleweed> it seems pragmatically sound, but not really how things are supposed to work
[21:09] <ScottK> Fixed in the development release is the normal standard for fixed, so that's correct.
[21:09] <tumbleweed> I suppose that's reasonable
[21:10] <ScottK> I'd rather it be dealt with through backports, but if no one is willing to do the testing for that, PPA is not an unreasonable way to go.
[21:10] <tumbleweed> yeah, it sounds like there's quite a lot to be backported
[21:10] <tumbleweed> blackz used to care about that package, but he isn't around any more
[22:19] <jtaylor> hm requestsync complains about possible duplicate sync when the sync is complains about is a duplicated of a fixed bug
[22:19] <jtaylor> I assume thats a bug?
[22:20] <jtaylor> requestsync --lp f-spot brings up Bug #618981
[22:23] <tumbleweed> jtaylor: yeah, although that's possibly a bug in launchpad
[22:33] <jtaylor> lp.bugs[618981].bug_tasks[0].is_complete should be True when its a dup of a fixed bug?
[22:36] <micahg> jtaylor: are you sure about that?  shouldn't it just make sure it's not a dupe?
[22:36] <tumbleweed> micahg: that's what jtaylor is asking too
[22:36] <jtaylor> I have no idea
[22:37] <tumbleweed> fixed bugs aren't searched by default, so it would make sense to not search dups of fixed bugs either
[22:37] <tumbleweed> dups are a pain, you need to account for them everywhere
[22:38] <tumbleweed> jtaylor: I'd say fix requestsync here, but it's worth asking launchpad people if they think that's an lp bug
[22:42] <jtaylor> is there an attribute to check if all bug_tasks of a bug a fixed?
[22:42] <jtaylor> instead of looping over it
[22:42]  * tumbleweed points jtaylor at https://launchpad.net/+apidoc/1.0.html
[22:43] <jtaylor> hm so no
[22:44] <jtaylor> to bad all takes no lambda ._.
[22:44] <tumbleweed> hrm, searchTasks has an omit_duplicates parameter
[22:44] <tumbleweed> there we go
[22:53] <jtaylor> yup that seems to work
[22:53] <jtaylor> thx
[23:17] <jtaylor> merge proposed
[23:23] <tumbleweed> jtaylor: is limiting the status such a good idea
[23:24] <tumbleweed> sync bugs are often incomplete / in progress when there's some back-and-forth with the sponsor
[23:24] <jtaylor> it checks for is_complete later anyway which should be the same
[23:24] <jtaylor> just with maybe less load on lp
[23:25] <tumbleweed> I mean there are other non-terminal statuses
[23:25] <tumbleweed> it could also search on the tag sync, but not everybody sets that...
[23:25] <jtaylor> hm yes incomplete is missing
[23:26] <jtaylor> and in progress ._.
[23:28] <jtaylor> I guess its safer to remove it, but then it loops over 1100 bugs instead of 300 for f-spot
[23:30] <tumbleweed> I'd say specifiy all the non-terminal statuses then
[23:31] <tumbleweed> I wouldn't be entirely against using tags='sync' either
[23:31] <tumbleweed> or may be search_text="Sync"
[23:35] <jtaylor> yould have to be Sync and sync
[23:35] <jtaylor> does this work?
[23:36] <jtaylor> ync does not work as lp does no substring matching
[23:36]  * tumbleweed doesn't know, I'd have to experiment (staging / qastaging / dogfood is great for experimentation)
[23:42] <jtaylor> non-terminal status will do for now
[23:45]  * jtaylor is off to bed