| lifeless | mars: http://code.google.com/webtoolkit/speedtracer/get-started.html | 00:33 |
|---|---|---|
| mars | lifeless, yep, took it for a spin. Didn't help me diagnose anything. It doesn't tell you what is going on, just "Your page is slow right about... here!" | 00:33 |
| lifeless | mars: oh ;( | 00:34 |
| lifeless | the web page showed pretty graphs | 00:34 |
| lifeless | so I thought it might be usefuk | 00:34 |
| mars | lifeless, it is nice to see exactly that "a script block at line 224 is slow", but I would like if it told me things such as "when was DOMContentReady fired?" | 00:34 |
| mars | lifeless, thanks for sending the link though. someone just beat you to it :) | 00:35 |
| lifeless | no worries, I'll console myself with a croissant & a sapporo | 00:37 |
| mars | lifeless, we'll have to wait and see if this prods the Firefox team into adding proper profiling hooks to the Gecko engine. | 00:37 |
| mars | IE got it right the first time, Google spent money to make Webkit right, now Firefox has to catch up. | 00:38 |
| thumper | clucking bell | 00:39 |
| * thumper wishes for a date_last_modified on merge proposals | 00:40 | |
| mars | thumper, isn't there an activity log for them? | 00:40 |
| mars | like on bugs? | 00:40 |
| thumper | mars: no | 00:40 |
| thumper | mars: I have a db patch, but I'm not happy with it | 00:40 |
| thumper | mars: for the activity log that is | 00:41 |
| wgrant | Can someone please copy (with binaries) launchpad-dependencies 0.60 from https://launchpad.net/~wgrant/+archive/launchpad to hardy, karmic and lucid in the ~launchpad PPA? | 00:58 |
| jml | wgrant, I don't know how to do that | 01:35 |
| jml | wgrant, but if you tell me how, I'll try. | 01:35 |
| jml | wgrant, also, do you know whether or not the "Rebuild testing in Launchpad" on https://dev.launchpad.net/Ubuntu/InfrastructureNeeds is done? | 01:40 |
| * jml -> lunch | 01:44 | |
| * thumper does a little dance | 01:44 | |
| wgrant | jml: Go to https://edge.launchpad.net/~wgrant/+archive/launchpad/+copy-packages?field.name_filter=launchpad-dependencies&field.status_filter=published&field.series_filter=karmic, select the package, select 'Copy binaries', select 'PPA for Launchpad Engineering', select Hardy. Repeat the process but select Karmic and then Lucid | 01:53 |
| wgrant | jml: It's sort of done. | 01:55 |
| wgrant | But it's not exactly a complete implementation. | 01:55 |
| wgrant | jml: The status given on that page (with the URL involving my nick) remains current. | 01:56 |
| fungalicious | jml: ping | 02:08 |
| === thumper is now known as eric-the-viking | ||
| === fungalicious is now known as eric-the-half-a- | ||
| === eric-the-half-a- is now known as fungalicious | ||
| === eric-the-viking is now known as thumper | ||
| jml | hmm. | 04:26 |
| jml | I wonder who fungalicious was | 04:26 |
| wgrant | I've seen him around here before. | 04:26 |
| wgrant | I think. | 04:27 |
| thumper | jml: it was kfogel at a friends place | 04:28 |
| jml | thumper, ahh ok. | 04:28 |
| wgrant | jml: Can you please copy those packages? | 04:37 |
| jml | wgrant, I'll load the page & see what I can do. | 04:46 |
| jml | wgrant, "PPA for Launchpad engineering"? | 04:46 |
| jml | wgrant, "copy", not "rebuild", right? | 04:47 |
| wgrant | jml: Yes, 'Copy existing binaries'. | 04:47 |
| jml | wgrant, I'm on it like a leper messiah | 04:48 |
| wgrant | Aha, it worked. | 04:49 |
| jml | for hardy... | 04:50 |
| jml | The following source cannot be copied: | 04:50 |
| jml | launchpad-dependencies 0.60 in karmic (same version has unpublished binaries in the destination archive for Karmic, please wait for them to be published before copying) | 04:50 |
| wgrant | What if you copy from the ~launchpad PPA to itself/ | 04:51 |
| wgrant | Otherwise try again now, and it will work. | 04:51 |
| wgrant | (the binaries would have been publishing right as you pasted that error) | 04:52 |
| jml | done | 04:54 |
| jml | great success | 04:54 |
| jml | wgrant, now, I would like you to answer a million questions about https://dev.launchpad.net/Ubuntu/InfrastructureNeeds :) | 04:55 |
| wgrant | jml: Thanks! | 04:55 |
| wgrant | Ask away. | 04:55 |
| jml | There's one called "Rebuild testing in Launchpad" | 04:55 |
| jml | wgrant, Is it still current? | 04:56 |
| wgrant | jml: The comment there about the lack of publishing is current. | 04:56 |
| wgrant | So, yes. | 04:56 |
| jml | wgrant, ok. that's good. I'll chase up that RT then. | 04:56 |
| jml | wgrant, do you know the best person, in general, to talk to about this page? | 04:57 |
| wgrant | jml: What *is* that RT? The code isn't there yet. | 04:57 |
| jml | wgrant, the text of the wiki page makes it sound like the code is there :( | 04:58 |
| wgrant | jml: It does, but it is wrong. | 04:58 |
| wgrant | Odd. | 04:58 |
| wgrant | It certainly requires significant sysadmin intervention too, though. | 04:58 |
| wgrant | spm: So, feel like building a buildbot image? | 04:59 |
| wgrant | I think all the pieces are together now. | 04:59 |
| jml | wgrant, it's mostly just this conversation: http://paste.ubuntu.com/338470/ | 04:59 |
| wgrant | Ah, yes, that one. | 05:00 |
| spm | wgrant: sure; but not today; probably not tomorrow. monday is more likely/possible. | 05:01 |
| wgrant | Argh, OK. | 05:01 |
| wgrant | Is the release the usual time? | 05:02 |
| spm | 2200 next week? ~9am here? I assume so. haven't hear otherwise so far. | 05:04 |
| * wgrant must somehow arrange testing of the v3 branch on dogfood tonight, since it's not going to be merged long before release :/ | 05:06 | |
| jml | wgrant, anyway, I want to start linking up that page: make sure there next action on each item is clear, and probably have a contact person for each thing (or just for the page as a whole) | 05:25 |
| wgrant | jml: Sounds good. | 05:26 |
| wgrant | "The current activity log in the Launchpad bug tracking system does not capture milestone changes." <- that is false | 05:26 |
| wgrant | Unless source packages are special. | 05:26 |
| wgrant | It certainly works for products. | 05:27 |
| jml | wgrant, so, for the rebuild thing | 05:31 |
| jml | wgrant, do you know of anything that needs to happen other than the RT? | 05:31 |
| wgrant | jml: Besides all the sysadminy stuff, it probably just needs a rebuild archive mode to be added to process-accepted.py, publish-distro.py, etc. | 05:37 |
| wgrant | There's little additional code required, now I think about it. | 05:38 |
| jml | wgrant, could you please file a bug for it -- I wouldn't be able to describe what's needed as well as you could. | 05:42 |
| wgrant | jml: Sure. | 05:42 |
| jml | thanks | 05:42 |
| wgrant | jml: Are you going to BFB/LCA? | 05:43 |
| jml | indeed. | 05:44 |
| jml | wgrant, are you confirmed to go? | 06:44 |
| wgrant | jml: Waiting on flight confirmation from the travel agent. | 06:46 |
| cody-somerville | What is BFB/LCA? | 06:48 |
| wgrant | cody-somerville: BFB == build-from-branch sprint in January | 06:49 |
| wgrant | LCA == linux.conf.au | 06:49 |
| cody-somerville | Is it intentional that you can target a bug task to a milestone that doesn't belong to the series the bug task is targeted to? | 06:57 |
| wgrant | I'm not sure that anybody knows how series targets are meant to work. | 06:59 |
| danilos | cody-somerville, wgrant: the problem with series is that you can't untarget it, at least not that I know off | 07:08 |
| jml | internet sucks. | 07:11 |
| jml | danilos, hello | 07:11 |
| wgrant | danilos: Correct, you cannot. | 07:11 |
| danilos | jml, good morning | 07:13 |
| danilos | jml, perhaps now is a good time to talk about https://dev.launchpad.net/VersionFourDotO/Roadmap | 07:14 |
| jml | danilos, that's exactly what I was thinking. | 07:14 |
| lifeless | danilos: yuou can decline, but not delete the record. | 07:17 |
| danilos | lifeless, but if you accepted it (for mistakenly thinking you can deal with it in the series), there's no way to decline it | 07:50 |
| danilos | lifeless, in those cases, I just mark them as 'won't fix' for the series, though it still is ugly | 07:50 |
| * jml gone | 07:51 | |
| adeuring | good morning | 08:23 |
| wgrant | bigjools: Morning. | 09:12 |
| mrevell | Guten morgen! | 09:13 |
| bigjools | moin all | 09:13 |
| wgrant | bigjools: How close is dogfood to v3-ready? It looks like I'll finally be able to get the branch merged on Monday (once a LOSA updates the buildbot AMI), but it would be nice to test this week. | 09:15 |
| bigjools | wgrant: it's ready now | 09:15 |
| bigjools | I threw a load of old style stuff at it yesterday and it seemed ok | 09:16 |
| wgrant | bigjools: Even with the branch merged? | 09:16 |
| wgrant | Excellent. | 09:16 |
| bigjools | ah there's one more to merge isn;'t there? | 09:16 |
| wgrant | Right. distroseries-source-format-selection, which cannot be merged until buildbot has dpkg >= 1.15.4 | 09:16 |
| bigjools | I'll merge that now | 09:17 |
| wgrant | Thanks. | 09:17 |
| bigjools | on DF I mean :) | 09:17 |
| wgrant | Right. | 09:17 |
| wgrant | While you're there, can you enable 3.0 (native) and 3.0 (quilt) for Lucid? | 09:17 |
| bigjools | ok | 09:17 |
| wgrant | Then I'll try to upload stuff to my PPA, if that's possible from out here. | 09:17 |
| bigjools | wgrant: I'm not sure if lamont updated the builders yet though | 09:21 |
| wgrant | bigjools: Ah, that could be a little inconvenient, although it would still allow all the Soyuz code to be tested. | 09:22 |
| bigjools | yep | 09:23 |
| bigjools | wgrant: ok it's ready | 09:28 |
| bigjools | buildd-manager is not running but poppy is | 09:28 |
| * wgrant tries to remember the host from the PPA beta days. | 09:28 | |
| wgrant | Hm, I guess it's all mawson anyway. | 09:28 |
| bigjools | I'll run process-upload on demand | 09:29 |
| bigjools | yes ppa.df.l.n | 09:29 |
| wgrant | bigjools: There should be an upload sitting there. I believe it should be accepted. | 09:33 |
| bigjools | wgrant: ok gimme 10m | 09:33 |
| bigjools | OTP | 09:33 |
| wgrant | bigjools: Sure. | 09:35 |
| bigjools | wgrant: you might want to use an upload path that works :) | 09:55 |
| wgrant | bigjools: Oh, right, I copied my lpdev stanza. | 09:56 |
| wgrant | bigjools: That should work a bit better. | 09:56 |
| bigjools | wgrant: it worked | 09:57 |
| wgrant | bigjools: There's now a Karmic upload, which should be rejected for being an unsupported format. | 09:58 |
| * bigjools runs p-u | 09:58 | |
| bigjools | rejected, yup | 09:59 |
| bigjools | "ftplib_3.1-1-8~wgrant1.dsc: format '3.0 (quilt)' is not permitted in karmic. | 09:59 |
| wgrant | bigjools: Perfect. | 09:59 |
| bigjools | so we just need to beat up lamont now | 09:59 |
| wgrant | I'll find something 3.0 (native) and another with some component origs in a sec. But yes, then we need a lamont. | 10:00 |
| wgrant | bigjools: Two more uploads for you. | 10:09 |
| bigjools | ok | 10:09 |
| bigjools | both ok | 10:09 |
| wgrant | Indeed. Thanks. | 10:10 |
| wgrant | And one more to test component orig sharing. I think that's it. | 10:12 |
| bigjools | it went in ok | 10:12 |
| wgrant | Also, do you have the appropriate stuff for testing syncs there? | 10:13 |
| wgrant | Would be good to be sure about that. | 10:13 |
| bigjools | hmmm not entirely sure | 10:13 |
| wgrant | Or archive admins will break down my door and lynch me. | 10:13 |
| wgrant | Although I guess most of the sync-related scripts are owned by ~ubuntu-archive, so they can always be hacked post-release. | 10:14 |
| wgrant | I know that sync-source.py itself works. | 10:14 |
| bigjools | ok | 10:15 |
| bigjools | that's the only thing I know about | 10:15 |
| wgrant | They have a whole set of secret scripts that will probably break in obscure ways, but we'll find out on Thursday... | 10:15 |
| wgrant | This is new. Reporting Mandriva bugs against launchpad. | 10:28 |
| deryck | Morning, all. | 10:59 |
| === matsubara-afk is now known as matsubara | ||
| wgrant | bigjools: You suggested last week that I move getBinaryPackageFormat from c.l.helpers to lp.soyuz.scripts.gina.handlers. But the only tests for that function are doctests in the docstring, and l.s.s.gina.handlers doesn't have anything looking for doctests in it. I suppose I could add a test module that just adds a DocTestSuite over that module -- does that sound OK? | 12:24 |
| bigjools | wgrant: if you feel sufficiently motivated, yep! | 12:29 |
| wgrant | bigjools: There's also an unused getBinaryPackageExtension there which uses the same constant, so I'll remove that... | 12:30 |
| bigjools | ok | 12:30 |
| === henninge is now known as henninge-lunch | ||
| bigjools | wgrant: lamont has installed the dpkg on ferraz so we can punt some 3.0 builds through it | 12:33 |
| wgrant | bigjools: Awesome. | 12:34 |
| wgrant | Except for the big queue which will have to be eliminated. | 12:34 |
| bigjools | I'll make you a buildd admin | 12:35 |
| bigjools | then you can rescore as you wish | 12:35 |
| wgrant | Ah, that would be handy. Thanks. | 12:35 |
| bigjools | wgrant: done | 12:38 |
| wgrant | bigjools: Thanks. | 12:38 |
| wgrant | bigjools: Since ferraz seems non-virtual, can you non-virtualise my PPA? | 12:42 |
| bigjools | wgrant: or I can make ferraz virtual | 12:43 |
| bigjools | in fact you can do that :) | 12:43 |
| wgrant | bigjools: As long as it's a no-op reset trigger, I guess. | 12:43 |
| * wgrant tries. | 12:43 | |
| wgrant | bigjools: Is buildd-manager running? | 12:45 |
| bigjools | wgrant: no... I'll start it | 12:50 |
| wgrant | bigjools: Ah, that would do it. Thanks. | 12:50 |
| bigjools | wgrant: ok it's off and running | 12:51 |
| === mrevell is now known as mrevell-lunch | ||
| wgrant | bigjools: buildd-manager is quite happy to deactivate ferraz due to an architecture mismatch, but won't start a build when the architecture is correct. | 12:57 |
| bigjools | missing chroot probably | 12:58 |
| wgrant | Ah, possibly :( | 12:58 |
| bigjools | I'm checking | 12:58 |
| wgrant | Thanks. | 12:59 |
| bigjools | wgrant: you're building lucid right? | 12:59 |
| wgrant | bigjools: Yes. lucid i386, since ferraz thinks it's i386 ATM. | 13:00 |
| bigjools | ok will sort it shortly | 13:00 |
| bigjools | it's actually amd64, it's getting fixed | 13:02 |
| wgrant | Ah. | 13:03 |
| bigjools | wgrant: ok I'm running queue-builder, we'll get your build dispatched soon ish | 13:36 |
| wgrant | bigjools: Why do you need queue-builder? | 13:37 |
| bigjools | wgrant: your source upload won't have had a build created for lucid without the chroot | 13:41 |
| wgrant | bigjools: The chroot exists, but the librarian file does not (I suspect). | 13:43 |
| wgrant | The builds are very much there. | 13:43 |
| bigjools | oh right, fair enough, I thought the lot was missing | 13:43 |
| bigjools | so why isn't it dispatching :/ | 13:44 |
| bigjools | ah I see | 13:44 |
| bigjools | ok off itgoes | 13:45 |
| wgrant | What was wrong with it? | 13:45 |
| bigjools | when you flip to virtual you need to set the vm_host | 13:45 |
| wgrant | Oh. | 13:45 |
| wgrant | Oops. | 13:46 |
| bigjools | which is the same as the real host since it's not a virtual machine | 13:46 |
| wgrant | Right. | 13:46 |
| === mrevell-lunch is now known as mrevell | ||
| * bigjools goes to lunch whiile it builds | 13:47 | |
| wgrant | Should I flip it to manual so it doesn't start trying to build stuff that doesn't exist in the dogfood librarian? | 13:47 |
| wgrant | Argh fuck. | 13:49 |
| wgrant | post-Karmic dpkg + unpatched lp-buildd == fail | 13:49 |
| wgrant | (https://bugs.edge.launchpad.net/launchpad-buildd/+bug/476036/comments/1) | 13:51 |
| mup | Bug #476036: sbuild needs to run dpkg-source inside the chroot <Launchpad Auto Build System:Triaged> <https://launchpad.net/bugs/476036> | 13:51 |
| sinzui | Chex: ping | 14:12 |
| === danilos is now known as danilo[home] | ||
| Chex | sinzui: hello | 14:16 |
| sinzui | Chex: Can you merge lp:~sinzui/launchpad/false-packages on staging so that I can verify it fixes a performance bug? | 14:17 |
| Chex | sinzui: yes sure, let me take a look | 14:17 |
| Chex | sinzui: All changes applied successfully. | 14:22 |
| * sinzui eagerly awaits the restart | 14:23 | |
| bigjools | wgrant: gah, pqm will be closed on monday for the release, so we could do with these AMIs getting updated quicker | 14:23 |
| wgrant | bigjools: That's what I thought. But the new launchpad-soyuz-dependencies requirement delayed things a bit. | 14:24 |
| wgrant | But that's all done now. It just needs the AMI to be upgraded. | 14:25 |
| bigjools | wgrant: what exactly does it need, just the dpkg change or just a rebuild with the new meta-package update? | 14:25 |
| wgrant | bigjools: All it actually needs is the new dpkg(-dev). But I was told it should really have the metapackage too. | 14:26 |
| bigjools | yeah that's what I think | 14:26 |
| bigjools | so if the l-d-d meta package is updated it should all be ready? | 14:27 |
| wgrant | bigjools: It's all there and in the ~launchpad PPA. | 14:27 |
| * bigjools files an RT | 14:28 | |
| Chex | sinzui: staging restarted for you now. | 14:28 |
| wgrant | (launchpad-soyuz-dependencies 0.60 is sufficient) | 14:28 |
| sinzui | Chex: thanks | 14:28 |
| bigjools | wgrant: l-d-d depends on that though right? so updating l-d-d should DTRT | 14:28 |
| wgrant | bigjools: Right. | 14:29 |
| bigjools | parfait | 14:29 |
| wgrant | bigjools: Although I'm not sure what apt sources the AMIs use. | 14:29 |
| bigjools | me neither | 14:29 |
| wgrant | But the relevant dpkg is in both the PPA and somewhere in CAT, and l-d-d won't upgrade without it, so it should be fairly obvious to anybody who knows how to upgrade them. | 14:30 |
| flacoste | morning launchpadders | 14:30 |
| bigjools | flacoste! | 14:30 |
| sinzui | bac: Bug #495051 [UnboundLocalError editing proposed team membership] | 14:39 |
| mup | Bug #495051: UnboundLocalError editing proposed team membership <oops> <Launchpad Registry:Triaged> <https://launchpad.net/bugs/495051> | 14:39 |
| === salgado is now known as salgado-lunch | ||
| === matsubara is now known as matsubara-lunch | ||
| sinzui | EdwinGrubbs: ping | 15:20 |
| EdwinGrubbs | sinzui: pong | 15:21 |
| sinzui | EdwinGrubbs: As you can see on https://staging.launchpad.net/ubuntu/lucid/+source/grub2, grub2 has been published 2 times in lucid, and the DistroSeriespackageCache has three entries. That is why +packaging lists the entry more than once. I think bac's suggestion of using DISTINCT is the correct fix. | 15:22 |
| EdwinGrubbs | sinzui: that shouldn't cause any problems | 15:25 |
| wgrant | sinzui: I'm confused about bug #495084. You say that hwtest is shown as not being in Lucid, and then cite a release of checkbox as evidence to the contrary. But those are different packages. | 15:35 |
| mup | Bug #495084: source package +index says there is no current release <package-link> <Launchpad Registry:Triaged> <https://launchpad.net/bugs/495084> | 15:35 |
| sinzui | wgrant: https://staging.launchpad.net/ubuntu/lucid/+search?text=hwtest lists the packages that are in lucid | 15:37 |
| wgrant | sinzui: Those are binaries. | 15:37 |
| sinzui | Yes, and https://staging.launchpad.net/ubuntu/lucid/+source/hwtest | 15:39 |
| sinzui | says there is not source (wrong I think since the source came from karmic) and the Releases in Ubuntu look wrong because of this | 15:39 |
| wgrant | sinzui: There is no source. | 15:39 |
| wgrant | There are just binaries from the new (checkbox) source with the same name as the old source. | 15:40 |
| wgrant | hwtest hasn't existed as a source package since early Jaunty. | 15:40 |
| sinzui | wgrant I think the warning message is misleading. It is often pointed to in bugs as an indication that the package is not in the series. | 15:42 |
| wgrant | sinzui: But the package is not in the series, so pointing to it as an indication of that is perfectly valid. | 15:43 |
| wgrant | bigjools: Do you think an AMI rebuild will be possible in time? | 15:48 |
| henninge | sinzui: Hi! | 15:48 |
| bigjools | wgrant: it's on the losas radar, I'm trying | 15:48 |
| sinzui | wgrant: I agree with the points of your argument, but I am still dissatisfied. I think the message on the +source The source *must* be in lucid because I cannot rebuild lucid without it | 15:48 |
| sinzui | hi henninge | 15:49 |
| wgrant | sinzui: What do you mean "I cannot rebuild lucid without it"? | 15:49 |
| wgrant | bigjools: Thanks. | 15:49 |
| henninge | sinzui: I'd call bug 165146 fixed, isn't it? | 15:50 |
| sinzui | wgrant: I think this works in lucid: | 15:50 |
| sinzui | apt-get source hwtest | 15:50 |
| mup | Bug #165146: lp admins cannot deactivate accounts <Launchpad Registry:Triaged> <https://launchpad.net/bugs/165146> | 15:50 |
| wgrant | sinzui: Because 'apt-get source' looks up binaries if a matching source cannot be found. | 15:50 |
| sinzui | oh, I may have fixed that when I exposed accounts to LOSA | 15:51 |
| wgrant | sinzui: Note that 'apt-get source hwtest' will download a source package named 'checkbox' | 15:51 |
| sinzui | henninge: maybe not. I think you need to ask a LOSA. They can deactivate the account, but I am not certain they can deactivate the profile (which will be renamed ~name-deactivated) | 15:52 |
| henninge | sinzui: I was about to ask who the account - profile split comes into play. | 15:52 |
| henninge | sinzui: so this is not bug 49676? | 15:52 |
| henninge | mup: bug 49676 | 15:53 |
| wgrant | It's private. | 15:53 |
| henninge | ah, right | 15:53 |
| henninge | "Administratively disable account" | 15:53 |
| sinzui | henninge: accounts are official SSO now. The foundations teams still works with them. The registry team manages the Launchpad profile . The admin in this case only want to deactivate the profile. | 15:54 |
| sinzui | Yes, that bug is private. It has user info that should not be public | 15:55 |
| henninge | sinzui: so when a LOSA goes to IPerson:+review and deactivates the user, what happens? | 15:55 |
| === matsubara-lunch is now known as matsubara | ||
| === beuno is now known as beuno-lunch | ||
| sinzui | The status of the account is changed | 15:55 |
| henninge | sinzui: what is the rationale for only letting LOSAs do that? | 15:56 |
| sinzui | Deactivating a profile renames the profile and unlinks the Person from many object | 15:56 |
| sinzui | henninge: SUSPEND | 15:56 |
| matsubara | Chex, gary_poster, rockstar, bigjools, danilos, sinzui, allenap: LP production meeting in 4 @ #launchpad-meeting | 15:56 |
| gary_poster | thx | 15:56 |
| henninge | sinzui: ? | 15:57 |
| bigjools | ok | 15:57 |
| sinzui | henninge: a suspended account can be reactivated if we are in error or the user proves he will not do bad things again | 15:57 |
| henninge | sinzui: and that is what's happening on +review, right? | 15:57 |
| henninge | and we don't have a UI to completely deactivate a profile, right? | 15:58 |
| * sinzui starts dev and looks | 15:59 | |
| sinzui | henninge: +review allows a LOSA to change the user name and standing | 16:00 |
| wgrant | sinzui: anyway, the hwtest source has never existed in Lucid. https://edge.launchpad.net/ubuntu/+source/hwtest/+publishinghistory shows that. | 16:00 |
| gmb | Anyone: What's the quickest way to the the URL of the current rootsite (i.e. bugs.launchpad.net blueprint.launchpad.net, etc.?) | 16:00 |
| henninge | sinzui: my core question is: why is that a LOSA task? | 16:00 |
| wgrant | And it is 3am, so I should sleep. | 16:00 |
| sinzui | henninge: +reviewaccount allows the LOSA to set the account status and passowrd | 16:00 |
| henninge | wgrant: good night, thanks for all your help | 16:01 |
| sinzui | henninge: it is NOT a losa task. | 16:01 |
| sinzui | henninge: The bug points out that the user does not know how to find the link | 16:01 |
| henninge | sinzui: sorry, LP admin | 16:01 |
| sinzui | henninge: do you know where the link is? | 16:01 |
| henninge | sinzui: it is at the bottom of "Edit details" | 16:02 |
| henninge | that is were the user can deactivate his own account | 16:02 |
| sinzui | correct. many users do not want to change their details, they want them removed. | 16:02 |
| sinzui | henninge: And the core bug is still open. Foo Bar cannot deactivate a profile....403 is raised | 16:03 |
| henninge | sinzui: huh? I can select "Deactivated account" on +reviewaccount and the user is deactivated. | 16:04 |
| henninge | sinzui: that is what spm does when you ask him to deactivate a user. | 16:05 |
| sinzui | account is NOT profile | 16:05 |
| sinzui | profile = Person, account =Account | 16:05 |
| henninge | sinzui: ok, so my question is "Why does it take a LOSA to deactivate an Account?" | 16:05 |
| sinzui | to stop spammer | 16:06 |
| sinzui | henninge: I think you have a fundmental misunderstanding. | 16:06 |
| henninge | sinzui: Exactly! | 16:06 |
| henninge | sinzui: no, we are right were I was on Monday ;-) | 16:06 |
| sinzui | henninge: We adding this feature so that admins could see the SSO data and address spammers. | 16:07 |
| henninge | sinzui: I had 10 spam accounts and had to wait for spm's shift to get them deactivated. | 16:07 |
| sinzui | henninge: The feature needs to move to SSO | 16:07 |
| henninge | sinzui: again, what is the ratinale for having *only* admins to be able to do that? | 16:08 |
| sinzui | henninge: escalate it to another LOSA. That is what I do when I see spam | 16:08 |
| sinzui | henninge: THIS IS FUCKING SSO. THIS IS UBUNTU | 16:09 |
| henninge | sinzui: Quoting tom "spm is handling LP requests this week." | 16:09 |
| sinzui | henninge: we do not own this data | 16:09 |
| henninge | sinzui: ok, so for spam accounts, I'd be happy if I could just remove homepage_content. | 16:10 |
| sinzui | henninge: I know *you* want to fix this, but *you* are not thinking of the consequences of other systems and their owners | 16:10 |
| henninge | sinzui: I get it, the account is not really Launchpad data. | 16:10 |
| henninge | but the homepage_conent is. | 16:11 |
| sinzui | true | 16:11 |
| sinzui | the issue here is that answers is really for user requests. This is OUR request, and it needs prompt attention. check, or mthaddon can addresses | 16:12 |
| henninge | sinzui: maybe it would be easiest to just rotate the current CHR into Launchpad Admins so that he can remove spam more easily. | 16:12 |
| henninge | sinzui: so you know about the close-account.py script? | 16:13 |
| sinzui | I know it, not its contents | 16:14 |
| henninge | It does some sql magic to completely remove a profile (and an account). | 16:14 |
| henninge | stub agreed, though, that it might fail on more complex data but luckily that is not the case for spam accounts. | 16:15 |
| sinzui | henninge: I think we just want a safe and easy what to mark an account suspended. The profile and account can be restored if we were is error | 16:16 |
| henninge | sinzui: and isn't +reviewaccount such a way? | 16:16 |
| sinzui | henninge: and to be clear, we have unsuspended user accounts after the user verified their machines were disaffected | 16:16 |
| sinzui | henninge: +reviewaccount is the only *correct* way | 16:17 |
| henninge | sinzui: so could we not open it up to the CHR in some way? That would make processing quicker and save LOSA time. | 16:17 |
| sinzui | henninge: you and I do not have the rights to see the openid | 16:17 |
| sinzui | or the password | 16:17 |
| henninge | its not in clear text, is it? | 16:18 |
| henninge | another great feature would be "Resend registration mail." | 16:18 |
| sinzui | henninge: The form needs to select the available field and info based on ~admin or ~somethingelse that is not all ~launchpad | 16:19 |
| henninge | ~registry | 16:19 |
| sinzui | henninge: the password is not ever shown, but the password can be changed | 16:19 |
| sinzui | ~registry is traditionally project, not person. | 16:20 |
| henninge | ok, so we create a new team? | 16:20 |
| sinzui | henninge: we are forbidden to create new teams/permission types without going before flacoste and his tribunal of standard bearers | 16:22 |
| henninge | lol | 16:22 |
| henninge | sinzui: so, the whole IPerson code is in registry, why not just use ~registry? | 16:23 |
| sinzui | That may be right, I ponder what will happen with teams which are also IPerson | 16:24 |
| henninge | sinzui: they don't have an account, so they are not affected by changes to +reviewaccount, are they? | 16:25 |
| sinzui | They do not have an account, but the permission change may give me other powers, like merge! | 16:28 |
| * sinzui may want merge powers | 16:28 | |
| henninge | sinzui: great, one thing less to delegate to the LOSAs | 16:29 |
| sinzui | henninge: The reason we have not exposes team merging id because it often fails with timeouts | 16:29 |
| sinzui | henninge: it often fails with profiles that have been used... | 16:29 |
| henninge | sinzui: you see, I always thought we were delegating tasks to LOSAs because they required SQL magic. | 16:30 |
| sinzui | henninge: barry's profile will take 22+ efforts to complete a merge | 16:30 |
| henninge | sinzui: but for stuff that has a UI, why do the LOSAs have to do the clicking? | 16:30 |
| sinzui | dude! | 16:30 |
| henninge | sinzui: document it on the CHR wiki ... ;) | 16:30 |
| sinzui | You've seen my list of stuff my team has to do, and surely you know that 1/3 of my work is personal contributions, and that I have landed more CHR features than anyone! | 16:31 |
| sinzui | merging is really hard | 16:31 |
| henninge | sinzui: wonderful, I am not critizing you! | 16:31 |
| henninge | or am I? | 16:31 |
| sinzui | read the blueprint https://blueprints.edge.launchpad.net/launchpad-registry/+spec/cleansing-deactivated-accounts | 16:32 |
| gary_poster | bigjools: replied to your question about buildbot. summary: ignore, proceed with what you and muharem were already doing | 16:34 |
| sinzui | henninge: merging truly sucks. The feature was designed for unclaimed profiles. But users are using it for active profiles. You and all CHR users are welcome to work on this. | 16:34 |
| sinzui | henninge: It really is hard. | 16:34 |
| henninge | sinzui: I understand. | 16:35 |
| sinzui | henninge: My rule is to let users do anything needed to correct their mistakes. I do not put CHR/LOSA barriers in the way. But features created 5 years ago still have those barriers. | 16:35 |
| bigjools | gary_poster: ah I missed the sourcecode pull fail, thanks | 16:36 |
| henninge | I see. | 16:36 |
| gary_poster | cool, np | 16:36 |
| henninge | sinzui: so, originally we did not talk about merging, we talked about deactivation. As a quick and easy way to get rid of spam accounts. | 16:37 |
| === salgado-lunch is now known as salgado | ||
| henninge | sinzui: You are saying, that exposing this might also expose the merge functionality of teams, right? | 16:37 |
| sinzui | henninge: We do not deactivate bad accounts because they can be reactivated by the user. we SUSPEND bad accounts | 16:37 |
| henninge | sorry, suspend ;) | 16:38 |
| === danilos is now known as danilo-bblot | ||
| henninge | sinzui: could we not do as you suggested and make +reviewaccount select data to display and make the reduced version available for ~registry? | 16:39 |
| sinzui | henninge: Since we are not adding new levels of permission to security.py, the implementation implies that ~registry is being added to IPerson launchpad.Admin. That gives you a lot of power over people and teams | 16:39 |
| henninge | right | 16:40 |
| sinzui | henninge: as I said, adding celebrity teams or levels requires approval from others | 16:40 |
| henninge | yeah, got that ... | 16:41 |
| flacoste | sinzui: could we use launchpad.Moderate instead of launchpad.Admin for suspending an account? | 16:42 |
| flacoste | sinzui: and give ~registry launchpad.Moderate permission | 16:42 |
| henninge | flacoste: I was just about to suggest that. | 16:43 |
| sinzui | flacoste: henninge The checker is ReviewByRegistryExpertsOrAdmins | 16:43 |
| henninge | or rename launchpad.ProjectReview to launchpad.Review and use that. | 16:43 |
| flacoste | sinzui: checkers for launchpad.Moderate or launchpad.Admin? | 16:43 |
| sinzui | We use that for launchpad.ProjectReview because launchpad.moderate is taken by something else | 16:44 |
| === beuno-lunch is now known as beuno | ||
| henninge | I think that is for ProjectReview | 16:44 |
| flacoste | iirc, there was a technical difficulty in merging ProjectReview and Review | 16:44 |
| henninge | flacoste: I don't see an existing launchpad.Review | 16:45 |
| henninge | My itention was to broaden the scope of lp.ProjectReview | 16:45 |
| sinzui | henninge: in security.py add | 16:49 |
| sinzui | class ModeratePerson(ReviewByRegistryExpertsOrAdmins): | 16:49 |
| sinzui | permission = 'launchpad.moderate' | 16:49 |
| sinzui | usedfor = IPerson | 16:49 |
| sinzui | then change EditAccount to | 16:49 |
| sinzui | class EditAccount(ModeratePerson): | 16:49 |
| sinzui | henninge: I am mistaken I think. The user needs access to his account (to deactivate it) so the permission may need to remain launchpad.Edit | 16:50 |
| sinzui | henninge: lp.ProjectReview is correct. There is a conflict with FAQ moderate that blocks us from using the permission | 16:51 |
| henninge | sinzui: yes, so the XXX says. | 16:55 |
| henninge | sinzui: remain lp.Edit for EditAccount? | 16:55 |
| henninge | ok, I'll put that in a bug. | 16:56 |
| sinzui | henninge: I think so | 16:56 |
| sinzui | henninge: I think the code needs to look like this: http://pastebin.ubuntu.com/338783/ | 16:58 |
| sinzui | wgrant: beuno: bigjools:I am have a very difficult time fixing +packaging because of the special case where we know exactly what is published in Ubuntu. The problem is that users are creating packaging links for packages in PPAs, not the primary archive. | 17:16 |
| adiroiban | can I use YUI3 event-keys for Launchpad ? | 17:16 |
| bigjools | sinzui: do you need to know the publishing state of PPA packages as well? | 17:17 |
| beuno | sinzui, sinzui if you give me a little bit more context, I can try to help out | 17:17 |
| sinzui | wgrant: beuno: bigjools: I am very tempted to add Ubuntu validation rules that prevent users from creating such links. I could then purge the PPA links from the DB, and remove the filter used in +packaging that ensure we only make links to published packages | 17:17 |
| * bigjools has to go in 5 minutes | 17:17 | |
| sinzui | bigjools: I really do not care about the publishing state. I want to avoid an ubuntu contributor seeing a link from lucid/+packaging to a lucid/+source that is not really in lucid | 17:19 |
| bigjools | sinzui: ok, so simply using Ubuntu state will suffice, no? | 17:19 |
| sinzui | bigjools: I pushed the filtering into model, but it breaks tests that are very hard to reconstruct knowing that we hide packaging links | 17:20 |
| beuno | sinzui, you will not get an opposition from me to get ubuntu-specific rules in Launchpad | 17:20 |
| beuno | in reality, there are no other distros really using Launchpad | 17:21 |
| sinzui | beuno: I am also tempted to remove debian and all the other distros from the packaging form | 17:21 |
| bigjools | sinzui: you could make it generic actually, if you look for something published in an archive with a purpose in (main_archive_purposes) | 17:21 |
| sinzui | making the feature Ubuntu specific is not project friendly, but to be clear, the only use for it is Ubunut | 17:22 |
| bigjools | if you use my suggestion you're guaranteeing that we only link to packages in distros that Soyuz publishes | 17:23 |
| sinzui | bigjools: I use that in the filter. I would reuse it for validation if we decide packaging links are not for ppas or other archive in cyberspace | 17:23 |
| bigjools | sinzui: I have to run now, but perhaps I can take a longer look at this tomorrow | 17:24 |
| bigjools | and see if I can offer more help | 17:24 |
| sinzui | beuno: look at the Packages by distribution section of https://staging.launchpad.net/bzr-gtk/+packages | 17:26 |
| beuno | sinzui, yes... | 17:26 |
| sinzui | By making packaging links Ubuntu specific, we will remove about 100 links to Debian and other distros | 17:27 |
| beuno | sinzui, how did those links get created? | 17:27 |
| sinzui | Project create the links from this same page to communicate to users that their software has packages for distributions | 17:28 |
| beuno | sinzui, one thing to do there, I think, would be to not have empty sections for the unlinked | 17:29 |
| sinzui | beuno: click (+) Link package under a series | 17:29 |
| sinzui | beuno: but we need the section to allow someone to create a link | 17:30 |
| beuno | sinzui, yes, we can try and solve that in a different way | 17:30 |
| beuno | sinzui, you could show Ubuntu by default | 17:30 |
| sinzui | beuno: we talks about that. | 17:30 |
| beuno | and offer "Other distributions" separately | 17:30 |
| sinzui | beuno: We agreed it should should the current series by default | 17:30 |
| beuno | in the +addpackage I mean | 17:31 |
| beuno | sinzui, ok, then we need to fix the UI | 17:31 |
| beuno | make it a one liner | 17:31 |
| beuno | probably drop the "No packages..." | 17:31 |
| sinzui | beuno: Yes, that is what we talked about in August. The challenge is to remove/hide the complexity of the package, and to show the Ubuntu packaging history.... | 17:31 |
| sinzui | beuno: ... so that we merge the common form with the special ubuntu form: https://staging.launchpad.net/bzr-gtk/0.93/+ubuntupkg | 17:32 |
| beuno | sinzui, in the +addpackage? | 17:34 |
| sinzui | beuno: To be clear, there are two form, one to link ubuntu and one for everyone else. User do not link the ubuntu one because they want to create links to show historical information | 17:34 |
| sinzui | beuno: so we discussed merging the forms last August to do the right thing by default, but allow users to record historical/other-distro info if they want to | 17:35 |
| beuno | sinzui, right. And the problem you are trying to solve now is...? | 17:36 |
| sinzui | beuno: but we did not realise at the time that users are using this to indicate that packages are available in PPAs, not in the default distro release | 17:36 |
| beuno | aha | 17:36 |
| beuno | sinzui, and how do they say in which PPA? | 17:36 |
| sinzui | and we can only verify Ubuntu, so we must have two rules, or desupport other distros | 17:37 |
| sinzui | about 1/3 of lucid packaging links are for PPAs, not primary+partner | 17:38 |
| sinzui | beuno: the user does not say it is a PPA. We do not let projects indicate when ppas they are packaged in | 17:38 |
| beuno | sinzui, ah, ok, I'm starting to understand then | 17:39 |
| beuno | so, links to PPAs is something people really really super want | 17:39 |
| sinzui | beuno: and the project pages talk about packages, not packages that are default in distros | 17:39 |
| sinzui | a link would be super | 17:39 |
| beuno | so we either make the linking to PPAs something we support (ie, let them say where) | 17:40 |
| beuno | or not support that use case | 17:40 |
| beuno | and bump the linkage feature :) | 17:40 |
| sinzui | beuno: This is a great example of a feature we designed for Ubuntu, that is co-opted by projects to do something else. | 17:40 |
| sinzui | I favour making this feature only about Ubuntu. Then allow projects to indicate their PPAs, which already list the supported distros | 17:42 |
| sinzui | beuno: also, Ubuntu only cares about primary packaging. If we only support Ubuntu, we can remove the nasty part of the form | 17:45 |
| beuno | sinzui, I'm a bit uneasy about dropping support for debian specifically | 17:47 |
| sinzui | beuno: this is what will be dropped: https://staging.launchpad.net/debian/sid/+packaging | 17:47 |
| beuno | sinzui, ok, kill it | 17:48 |
| beuno | if we find a sensible use case for it, we can always bring it back in better shape | 17:48 |
| sinzui | Yes, if we want other distros to use it, it needs a different feature set | 17:51 |
| mrevell | night all | 18:06 |
| bac | sinzui: ping | 18:12 |
| sinzui | hi bac | 18:13 |
| === deryck is now known as deryck[lunch] | ||
| bac | sinzui: call soonish? | 18:14 |
| sinzui | I am ready now | 18:14 |
| bac | me2 | 18:14 |
| sinzui | bac: I am looking at https://bugs.edge.launchpad.net/launchpad-registry | 18:33 |
| sinzui | bac: https://bugs.edge.launchpad.net/launchpad-registry/+bug/296927 | 18:34 |
| mup | Bug #296927: checking menu links <feature> <tech-debt> <Launchpad Registry:Triaged> <https://launchpad.net/bugs/296927> | 18:34 |
| === deryck[lunch] is now known as deryck | ||
| sinzui | https://edge.launchpad.net/launchpad-registry/+milestone/series-3.1 | 19:25 |
| thumper | morning | 20:04 |
| === salgado is now known as salgado-afk | ||
| adiroiban | when creating a MP, is there a way to link it to a bug so that the bug will be updated to fix-commited on merge, and fix release later. | 20:18 |
| adiroiban | the branch is already linked to the bug | 20:18 |
| sinzui | adiroiban: no, the important link is between the bug and the branch | 20:18 |
| adiroiban | sinzui: ok. so I have to manually update the bug status? | 20:19 |
| sinzui | adiroiban: The bug subscribers will be notified with the bug is merged. There is no automatic status change because the branch may only partially fix a bug | 20:20 |
| adiroiban | sinzui: thanks for the info. yep I was notified when the branch was landed | 20:21 |
| sinzui | adiroiban: I am contemplating a rule to automatically mark bugs that are fix-committed to fix-released when when a milestone is released...but I need to hack bug karma to make sure the bug assignee get the credit | 20:21 |
| adiroiban | sinzui: :) I don't care about karma, but it would be nice to have some magic help at updating bug status | 20:22 |
| adiroiban | like bzr --fixes | 20:23 |
| sinzui | The karma rule is what is stopping me from doing this. it is important to some people. I stopped marking bugs fix-released when we do released because it steals karma | 20:23 |
| adiroiban | :( | 20:24 |
| adiroiban | well... life suck :) | 20:24 |
| adiroiban | sinzui: no problem. many thanks for the support. I can live with it | 20:25 |
| === matsubara is now known as matsubara-afk | ||
| wgrant | sinzui: Do you now understand what I was explaining last night? | 20:31 |
| sinzui | No not really. I am certain the SP must be in the distro when we copy from the parent | 20:32 |
| wgrant | lamont: Hi. Do you have an lp-buildd with https://bugs.edge.launchpad.net/launchpad-buildd/+bug/476036/comments/1 fixed? | 20:32 |
| mup | Bug #476036: sbuild needs to run dpkg-source inside the chroot <Launchpad Auto Build System:Triaged> <https://launchpad.net/bugs/476036> | 20:32 |
| wgrant | sinzui: What tells you that? | 20:33 |
| sinzui | apt-get source | 20:33 |
| sinzui | disregard the example of hwtest | 20:34 |
| wgrant | Have you another example? | 20:34 |
| sinzui | bzr apparently was not published in edgy or fiesty. yet apt-get source will get it. | 20:34 |
| * sinzui looks for karmic example | 20:35 | |
| wgrant | sinzui: It *was*, but is no longer. | 20:35 |
| sinzui | why rewrite History? that sounds like a bug | 20:35 |
| wgrant | sinzui: Edgy and Feisty are no longer supported, so they were copied to old-releases.ubuntu.com, then all their publishings were removed from LP to save disk space on mirrors and the archive machine. | 20:35 |
| wgrant | History hasn't been rewritten; the publishing records are just now set to Obsolete. | 20:36 |
| sinzui | The page says it wasn't ever published though | 20:36 |
| wgrant | Right, that's not ideal. | 20:36 |
| wgrant | Although the message is true. | 20:37 |
| sinzui | https://edge.launchpad.net/ubuntu/edgy/+source/bzr | 20:38 |
| sinzui | ^ That does not look right. There is a bug and am not certain what it is | 20:38 |
| wgrant | It's true. | 20:39 |
| wgrant | Edgy has no packages left. | 20:39 |
| wgrant | Edgy is obsolete, so its packages have been removed. | 20:39 |
| wgrant | However that message could make that more obvious. | 20:39 |
| lamont | $dir = $1 if /^dpkg-source: (?:info: )?extracting \S+ in (\S+)/; | 20:39 |
| sinzui | maybe we should not show that message at all for obsolete series | 20:39 |
| lamont | wgrant: ^^ that change in 2 places | 20:39 |
| wgrant | Obsolete isn't like Superseded and Deleted (the two more normal removal states). | 20:39 |
| lamont | but no, not quite packaged yet, will have it on dogfood for testing sometime tonight or tomorrow | 20:40 |
| wgrant | lamont: Right, I know the diff, but ferraz doesn't have it. | 20:40 |
| wgrant | lamont: Ah, great, thanks. | 20:40 |
| lamont | right | 20:40 |
| lamont | wgrant: is it blocking you? | 20:40 |
| wgrant | lamont: Not really. As long as it happens in the next day or two it's fine. | 20:41 |
| lamont | if so, I can smash it onto ferraz in a couple of hours, otherwise it'll just come as part of things on prolly monday (I want to test over the weekend) | 20:41 |
| wgrant | The Soyuz code works, so that's no longer blocked on testing. | 20:41 |
| lamont | cool | 20:41 |
| wgrant | OK, sure. | 20:41 |
| lamont | oh hey - if you're done with dogfood, could you toss a no-change binutils upload at it? | 20:42 |
| lamont | with ddeb exporting turned off | 20:42 |
| wgrant | I can't upload to main. | 20:42 |
| lamont | even on dogfood? how rude | 20:42 |
| bigjools | I can fix that | 20:42 |
| lamont | ta - I need to go afk for about an hour or so, then I get to put in another long night | 20:43 |
| lamont | bigjools: the intention is to make sure that the pkgmanglebinary in the tarball I gave you earlier won't break production lp when binutils (e.g.) builds | 20:43 |
| bigjools | which would be nice | 20:43 |
| lamont | yeah - there have been complaints about time served and all that | 20:44 |
| lamont | must run | 20:44 |
| bigjools | wgrant: you're now in core-dev on DF | 20:44 |
| wgrant | bigjools: Thanks. | 20:44 |
| sinzui | wgrant: I think this page is bong I think the reason is that zope3 existed for a short time in karmic: https://edge.launchpad.net/ubuntu/karmic/+source/zope3 | 20:48 |
| sinzui | wgrant: in which case we should state the package is was discontinued and we do not need an alert because this is not extraordinary | 20:49 |
| wgrant | sinzui: Right. | 20:50 |
| === EdwinGrubbs_ is now known as EdwinGrubbs | ||
| bac | hi sinzui | 22:44 |
| sinzui | Hi bac. Do you need me to break something? | 22:44 |
| bac | sinzui: no, but can you look at a query and run it on staging? | 22:45 |
| bac | http://paste.ubuntu.com/338974/ | 22:46 |
| * sinzui does | 22:46 | |
| bac | sinzui: ah, wait. i need to look for .tar.bz2 also | 22:47 |
| bac | hmm, i wonder if my branch handles those... | 22:47 |
| sinzui | bac: http://paste.ubuntu.com/338987/ | 22:49 |
| bac | sinzui: run this one instead http://paste.ubuntu.com/338986/ | 22:49 |
| sinzui | yes master | 22:49 |
| bac | just the select, not the update | 22:49 |
| bac | thanks | 22:50 |
| sinzui | I worked that out after getting nasty errors when blind pasted it into the terminal | 22:50 |
| sinzui | pgsql hates that query | 22:51 |
| bac | really? | 22:51 |
| bac | hmm | 22:51 |
| sinzui | wow that is a very large response | 22:51 |
| bac | my sql fu is limited | 22:51 |
| sinzui | 4713 rows | 22:52 |
| sinzui | bac: i'm getting a full report. pastbin hates me | 22:56 |
| sinzui | bac: I sent the report by mail because it killed FF when I tried to pastebin it | 22:58 |
| bac | sinzui: ok, thanks | 22:58 |
| sinzui | about 1/3 are plain/text | 22:59 |
| bac | sinzui: could you do it again with a 'mimetypes = 'text/plain' ? those are really the ones we're interested in. | 23:02 |
| sinzui | okay | 23:03 |
| bac | i hate stumbling around via you as a proxy | 23:03 |
| sinzui | bac: http://paste.ubuntu.com/338993/ | 23:07 |
| sinzui | doesn't look like anyone is using lp to distribute porn | 23:07 |
| bac | whee | 23:09 |
| bac | sinzui: i think the update at http://paste.ubuntu.com/338986/ is ready to run on staging. | 23:09 |
| bac | i'll see if i can get chex to do it | 23:09 |
| sinzui | spm: certainly can, he's got mad skilz | 23:10 |
| bac | oh, i forgot spm was about | 23:10 |
| bac | except he isn't | 23:11 |
| sinzui | he's mysterious like that | 23:11 |
| sinzui | hmm | 23:12 |
| thumper | where is spm today? | 23:12 |
| sinzui | looks like packaging-views.txt is predicated of the current behaviour that projects link to source packages that are not published. This may require a total rewrite. | 23:13 |
| wgrant | Yay for unrealistic tests. | 23:14 |
| sinzui | it is very realistic. I want to change reality. Link to Ubuntu or get stuffed | 23:15 |
| sinzui | I doubt this will make this release. Maybe a pot of coffee will help me fix this | 23:17 |
| sinzui | wgrant: do you care about packaging links between projects and debian? | 23:18 |
| wgrant | sinzui: Not particularly, no. Packaging links aren't useful for much. | 23:18 |
| wgrant | The only thing we use them for is defaulting to the correct upstream project when we click 'Also affects project' | 23:18 |
| sinzui | they should be | 23:18 |
| wgrant | And we don't do that for Debian. | 23:18 |
| wgrant | sinzui: Why do you ask? | 23:19 |
| wgrant | I think, ideally, we would say that our upstream is the Debian package, and Debian would say that their upstream is the project, and the relationship would be transitive. | 23:20 |
| wgrant | But that sounds hard. | 23:20 |
| sinzui | wgrant: +ubuntupkg only permits users to link to the current Ubuntu development series. Project seem to prefer +addpackage because it lets them record that their project is packaged in an older Ubuntu series, and in a rare case Debian | 23:20 |
| wgrant | sinzui: Ah, you're dealing with the multiple view madness? | 23:21 |
| sinzui | I do not think debian is ideaa because they will not fix the bug or sync the translations. We want the links so that users and tools can send bugs and translations upstream, and for Ubuntu to have upstreams tip. | 23:21 |
| sinzui | wgrant: It is madness, because I think users co-opted the feature to report that they made a PPA. | 23:22 |
| wgrant | sinzui: Debian does fix bugs. Lots of them. | 23:23 |
| wgrant | sinzui: But yes, the PPA situation is a bit stupid. | 23:23 |
| wgrant | That needs a fix, but I'm not sure how. | 23:23 |
| sinzui | Letting projects link to ppas would help. | 23:23 |
| wgrant | It would, but it's not perfect. | 23:24 |
| wgrant | I'm not sure that forbidding creation of packaging links to unpublished sources is a good idea. Sure, do not display them, but it might be useful for eventually providing an automatic list of PPAs for a project, much like https://launchpad.net/ubuntu/+source/dpkg does now. | 23:26 |
| sinzui | exactly what I have been think! | 23:26 |
| sinzui | yet the work of preventing links to unpublished packages in a series is process intensive | 23:27 |
| wgrant | Yes :( | 23:27 |
| wgrant | I think somebody needs to go through all the use cases before much more can be done. | 23:28 |
| wgrant | At the moment packaging links are pretty pointless, but they have the potentially to be very very handy. | 23:28 |
| sinzui | wgrant: If we had some process to guide a user from making a PPA, to getting it into universe, it would make more sense to allow the links to be made first | 23:28 |
| sinzui | All the canonical launchpad developers are focused on making those links useful. My first problem is that users are not using them as we intended them. | 23:30 |
| wgrant | sinzui: But has work been done to work out what they mean? What they should mean? | 23:30 |
| wgrant | It seems nobody is sure how they are going to be changed to be more useful. | 23:31 |
| wgrant | And I think it would be handy to know that before an attempt is made. | 23:31 |
| sinzui | wgrant: That is something I need solved by the end of January | 23:31 |
| sinzui | wgrant: A link is only useful of the launchpad knows the project's bug-tracker, development branch, and is setup for translation syncing. We need a message that explain why this import. Projects and packages need to state what is missing. We can suggest links too because in most cases, the project and source package have similar names | 23:34 |
| sinzui | s/of launchpad/if launchpad/ | 23:34 |
| wgrant | sinzui: But packaging links should be useful the other way too. | 23:35 |
| sinzui | I have not found may compelling reasons for the other way. | 23:35 |
| wgrant | sinzui: If I go to a project page, it should tell me where I can packages. | 23:35 |
| wgrant | +get | 23:35 |
| sinzui | well | 23:36 |
| wgrant | If I click on a release, it should tell me where I can get packages of that particular release. | 23:36 |
| sinzui | I suggested that we should emphasise that downloads is overrated. My argument is not favoured | 23:36 |
| sinzui | I suggested that we should emphasise that. Downloads is overrated. My argument is not favoured | 23:37 |
| wgrant | Has the community been asked for ideas on how to improve things? | 23:38 |
| sinzui | I do not think so | 23:39 |
| wgrant | That seems like a bad thing. | 23:39 |
| sinzui | The registry is working the the other teams this series. code, translations, and bugs need the links. They do not care how they get there, they just need to links in place to enable their systems | 23:40 |
| wgrant | But you need to consider all the possible uses before you make a potentially short-sighted model change. | 23:41 |
| sinzui | indeed. I have not made model changes because I have not talks to anyone | 23:41 |
| sinzui | All these features I am discussing already exist. the issues are user experience, and the fundamental question should they exist? | 23:42 |
| * thumper lunching | 23:48 | |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!