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