| === vddlogger is now known as parislogger | ||
| === slicer_ is now known as slicer | ||
| 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:12 |
|---|---|---|
| micahg | cjwatson: I'm subscribed and will keep an eye out for any issues | 02:17 |
| kovid | whois kovid | 06:31 |
| dholbach | good morning | 07:07 |
| === almaisan-away is now known as al-maisan | ||
| === hannesw_ is now known as hannesw | ||
| === Quintasan_ is now known as Quintasan | ||
| 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:11 |
| 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:14 |
| thelinuxer | i have little knowledge of mercurial | 09:15 |
| chrisccoulson | thelinuxer, look at the version number i use for firefox nightlies (which come from mercurial) ;) | 09:16 |
| 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:17 |
| 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:18 |
| 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:19 |
| chrisccoulson | so, for that revision, i would add "~hg20110829r194" (with the date coming from http://hg.atheme.org/users/desowin/gdigi/rev/dec7a1546064) | 09:20 |
| 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:21 |
| 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:22 |
| 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:23 |
| 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 | 09:46 |
| === dutchie_ is now known as dutchie | ||
| 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:06 |
| 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:08 |
| 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:10 |
| thelinuxer | ok will try that, thanx | 11:11 |
| Laney | but email the other guy and find out what he's doing | 11:12 |
| thelinuxer | ok will do so , thanks again | 11:12 |
| === chrisccoulson_ is now known as chrisccoulson | ||
| tumbleweed | Laney, bdrung: Should we turn launchpad DSD blacklisting into non-fatal errors in syncpackage for now? (bug 841372) | 12:33 |
| ubottu | Launchpad bug 841372 in Launchpad itself "Incorrect auto-blacklisting in DSD?" [Low,Triaged] https://launchpad.net/bugs/841372 | 12:33 |
| 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:35 |
| bdrung | hm | 12:36 |
| === al-maisan is now known as almaisan-away | ||
| bdrung | i don't like adding workarounds | 12:36 |
| 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:37 |
| tumbleweed | Laney: launchpad automatically blacklists syncs when the version in Ubuntu is newer than Debian, but it appears to be buggy | 12:38 |
| tumbleweed | http://bazaar.launchpad.net/~launchpad-pqm/launchpad/devel/view/head:/lib/lp/registry/model/distroseriesdifference.py#L760 | 12:39 |
| 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:41 |
| 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:42 |
| 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:43 |
| 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:44 | |
| Laney | you mean your link from the bug? | 12:45 |
| Laney | not greyed out here | 12:45 |
| 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:46 |
| * Laney wonders what "Upgrade Packages" does | 12:47 | |
| * tumbleweed too | 12:47 | |
| 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:49 |
| tumbleweed | that's a question for bigjools | 12:51 |
| 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:52 | |
| Laney | hah, it got rejected thankfully | 12:56 |
| tumbleweed | I added a note about that to the bug | 12:57 |
| Laney | nice | 12:57 |
| tumbleweed | urgh, turning BLACKLISTED_CURRENT into an overrideable warning requires some refactoring | 12:58 |
| === _ruben_ is now known as _ruben | ||
| tumbleweed | Laney: ok, launchpad allowed me to override the BLACKLISTED_CURRENT. Committing | 13:41 |
| Laney | nice | 13:41 |
| Laney | does always work properly? | 13:41 |
| tumbleweed | you mean does launchpad block the sync? I don't want to test that :P | 13:42 |
| 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:44 |
| 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:45 |
| Laney | i'd like to see the text file be generated from launchpad | 13:46 |
| tumbleweed | that's something to take up with the archive admins | 13:47 |
| 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:48 |
| 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:51 |
| Laney | do you get an interface on the website to manage blacklisting? | 13:52 |
| cjwatson | I think so | 13:52 |
| === vivi`d is now known as vivid | ||
| Laney | ok, that makes the tool easier | 13:52 |
| cjwatson | I have an "Add comment" AJAX thing | 13:52 |
| cjwatson | do you? | 13:52 |
| 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:53 |
| 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:54 |
| 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 |
| === almaisan-away is now known as al-maisan | ||
| cjwatson | they were always a pain to manage anyway | 13:55 |
| wgrant | Please file bugs for any API inadequacies you run into. | 13:55 |
| 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:56 |
| 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:57 |
| 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:58 |
| 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. | 13:59 |
| 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:00 |
| 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:01 |
| wgrant | Changelog bug closing just needs one last fix. And announcement emails should already be fixed... no more issues there? | 14:02 |
| wgrant | Bug #841842 | 14:03 |
| ubottu | 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:03 |
| 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:05 |
| tumbleweed | I think NEW didn't generate announcemets (there's a bug filed) | 14:06 |
| wgrant | Indeed. | 14:06 |
| 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:08 |
| 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 |
| ubottu | Launchpad bug 841849 in Launchpad itself "add a way to close bugs on copyPackage completion" [Undecided,New] https://launchpad.net/bugs/841849 | 14:09 |
| thelinuxer | Laney: i need some place for my code, at least until they accept my patch upstream. am i right ? | 14:09 |
| 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:10 |
| Laney | wgrant: oh, sweet. /me stops filing a bug then | 14:11 |
| wgrant | Laney: Bug #833080 | 14:11 |
| ubottu | 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 |
| Laney | hah | 14:11 |
| * Laney awaits that fix then | 14:12 | |
| wgrant | Could have deployed it today, but I forgot. :( | 14:12 |
| === 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 | ||
| 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:07 |
| 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:09 |
| 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 | 21:10 |
| === al-maisan is now known as almaisan-away | ||
| 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:19 |
| jtaylor | requestsync --lp f-spot brings up Bug #618981 | 22:20 |
| ubottu | 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:20 |
| tumbleweed | jtaylor: yeah, although that's possibly a bug in launchpad | 22:23 |
| jtaylor | lp.bugs[618981].bug_tasks[0].is_complete should be True when its a dup of a fixed bug? | 22:33 |
| 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:36 |
| 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:37 |
| tumbleweed | jtaylor: I'd say fix requestsync here, but it's worth asking launchpad people if they think that's an lp bug | 22:38 |
| 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:42 | |
| jtaylor | hm so no | 22:43 |
| jtaylor | to bad all takes no lambda ._. | 22:44 |
| tumbleweed | hrm, searchTasks has an omit_duplicates parameter | 22:44 |
| tumbleweed | there we go | 22:44 |
| jtaylor | yup that seems to work | 22:53 |
| jtaylor | thx | 22:53 |
| jtaylor | merge proposed | 23:17 |
| tumbleweed | jtaylor: is limiting the status such a good idea | 23:23 |
| 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:24 |
| 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:25 |
| jtaylor | and in progress ._. | 23:26 |
| jtaylor | I guess its safer to remove it, but then it loops over 1100 bugs instead of 300 for f-spot | 23:28 |
| tumbleweed | I'd say specifiy all the non-terminal statuses then | 23:30 |
| tumbleweed | I wouldn't be entirely against using tags='sync' either | 23:31 |
| tumbleweed | or may be search_text="Sync" | 23:31 |
| jtaylor | yould have to be Sync and sync | 23:35 |
| jtaylor | does this work? | 23:35 |
| 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:36 | |
| jtaylor | non-terminal status will do for now | 23:42 |
| * jtaylor is off to bed | 23:45 | |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!