| cjwatson | Please to be NEWing update-manager awesomeness. | 00:36 |
|---|---|---|
| slangasek | reviewinating | 00:39 |
| slangasek | accepted | 00:42 |
| stgraber | infinity: thanks | 01:29 |
| === scott_ is now known as Guest46365 | ||
| cjwatson | jdstrand: Are you OK with the permissions change proposed in https://lists.ubuntu.com/archives/technical-board/2012-June/001312.html ? | 12:03 |
| jdstrand | cjwatson: so iiuc, anyone in these teams can upload to their respective pocket, but they still need to be approved via LP? the situation now is what, an upload to -security is outright rejected? | 12:06 |
| cjwatson | -security is actually somewhat special beyond this, because there's a special hardcoded thing that stops you uploading directly to -security at all rather than going via a staging PPA. | 12:14 |
| cjwatson | But an attempt to copy a package in main to -security is I believe outright rejected right now if you aren't in -core-dev, yes. | 12:14 |
| cjwatson | I'm sort of pretending your specialised unembargoing tools don't exist for now because ultimately I want to be able to support it all through Archive.copyPackage. | 12:15 |
| cjwatson | This is one step. | 12:15 |
| cjwatson | For -backports, which doesn't have any of this extra complexity - yes, right now a backporter has to be able to upload the package in general or else they get outright rejected | 12:16 |
| jdstrand | ok, let's pretend (just for a moment, I know it's hard ;) that I don't know exactly what is changing in your commit, or all the special LP stuff. your change allows someone in these groups to upload to their pocket without being rejected from the start. your change allows that initial step to pass for later checks to be performed. is that accurate? | 12:17 |
| cjwatson | That's correct. | 12:19 |
| jdstrand | ok, I think the permissions changes are fine then at least for -security. I can't really comment on -backports because I wasn't part of that conversation, but based on your recap, they sound fine too | 12:20 |
| jdstrand | cjwatson: do you need me to comment in the bug? | 12:21 |
| cjwatson | No, that's fine, I just wanted to double-check with you before messing about with -security | 12:21 |
| cjwatson | The LP change is being rolled out either way, since it's harmless by itself | 12:21 |
| jdstrand | thanks. it doesn't open it up anymore afaics, so it looks good to me | 12:22 |
| jdstrand | s/anymore/any more/ | 12:22 |
| cjwatson | It would make things a bit easier for micahg, potentially. | 12:22 |
| cjwatson | Oh, except that he's -core-dev now. | 12:22 |
| * cjwatson <- paying attention honest | 12:22 | |
| cjwatson | But, you know, future security team members who aren't yet -core-dev. | 12:23 |
| jdstrand | we still have two | 12:23 |
| jdstrand | actually 3 | 12:23 |
| cjwatson | Tyler and John? | 12:23 |
| cjwatson | Oh wow, I didn't know Steve wasn't -core-dev yet. | 12:24 |
| jdstrand | cjwatson: so with this change, we can use copyPackage to unembargo, then go to the LP unapproved queue to accept them? | 12:24 |
| cjwatson | Well. | 12:24 |
| jdstrand | cjwatson: sbeattie too, but we are desperately trying to fix that | 12:24 |
| * jdstrand pokes sbeattie | 12:24 | |
| jdstrand | :) | 12:24 |
| cjwatson | In principle I'd like to say yes, but there's funny stuff around making sure stuff gets copied from the restricted librarian to the public one and I don't know if copyPackage handles that yet. | 12:24 |
| jdstrand | I see | 12:24 |
| jdstrand | well, it is a step any way, and I appreciate that :) | 12:25 |
| jdstrand | we added a --copy argument to our unemgardo tool to use copyPackage, so it should be easy enough to test | 12:25 |
| jdstrand | cjwatson: I've subscribed the team to the bug. when the change is committed, we'll have someone do a copyPackage and see how it goes | 12:26 |
| jdstrand | err | 12:26 |
| jdstrand | change is live | 12:26 |
| cjwatson | Hm, I think I'd kind of like to try it out in the LP test suite (or satisfy myself that it's already there) before trying it on real data :-) | 12:29 |
| cjwatson | I could add a permission on staging or something and you could try it there, though | 12:29 |
| cjwatson | That'd be better than production for this | 12:30 |
| Laney | I'm having a hard time reconciling queue admin and copying permission | 12:39 |
| cjwatson | Do expand | 12:41 |
| Laney | I'm not sure entirely, but it feels like the wrong model. Perhaps it's because copying to me is tied to uploading. | 12:44 |
| cjwatson | It is a bit of a conflation. The reason I think it makes sense is that copying stuff around within Ubuntu is a bit more of an administrative operation. | 12:44 |
| cjwatson | Copying stuff from outside Ubuntu, I agree. | 12:44 |
| cjwatson | (Anyway, I wasn't suggesting making uploaders be unable to copy.) | 12:44 |
| Laney | I know, but you were suggesting making queue admins always able to copy | 12:45 |
| cjwatson | Copying stuff from -proposed to -updates and then having to separately go to approve it just seems kind of mad. | 12:45 |
| cjwatson | Well, that's the other bug, I guess. | 12:45 |
| Laney | yes, so I'd like bug #1006871 fixed for that | 12:45 |
| ubot2 | Launchpad bug 1006871 in launchpad "Copying packages to -updates always goes through unapproved queue, even when copying user is privileged" [Low,Triaged] https://launchpad.net/bugs/1006871 | 12:45 |
| Laney | and then the SRU team given permissions to manage their queues | 12:45 |
| Laney | and also to upload to them, which is what I was suggesting | 12:46 |
| cjwatson | Most of my motivation for queue admins always being able to copy is for automating auto-syncs. | 12:46 |
| Laney | I guess I don't see the need for this conflation | 12:46 |
| Laney | the auto-sync account could just be made a core-dev | 12:46 |
| cjwatson | It could. It makes me jittery for some reason. | 12:46 |
| Laney | perhaps that is too much permission though | 12:46 |
| cjwatson | I know that the package-import account is a core-dev. | 12:46 |
| Laney | wait. | 12:47 |
| cjwatson | Slightly less permission would be to give it a separate blanket upload ArchivePermission. | 12:47 |
| Laney | yes, that | 12:47 |
| cjwatson | That way it at least wouldn't be able to write to core-dev branches, say. | 12:47 |
| Laney | to the release pocket in the dev release | 12:47 |
| Laney | can we express that? | 12:47 |
| cjwatson | But it's still a root-everything account :-) | 12:47 |
| cjwatson | Can't do pocket & other stuff, but it can be series-specific, yes. | 12:47 |
| cjwatson | Would be a bit of a hassle to have to roll it over every series, but nothing too horrible. | 12:48 |
| cjwatson | Oh, wait. Better check my assumptionss. | 12:49 |
| cjwatson | Bah. Packageset permissions are per-series, but component permissions aren't. | 12:49 |
| Laney | hmm | 12:54 |
| cjwatson | Another way I think about it is: | 12:55 |
| cjwatson | * you can fairly easily upload stuff to a component you aren't supposed to have access to by accident | 12:55 |
| cjwatson | * working around it by uploading to a PPA and then copying, to me, implies more chance of malice | 12:56 |
| cjwatson | So they're sort of technically equivalent in security terms but the safety-catch nature is different | 12:56 |
| cjwatson | It's not a massively high priority for me though: fully automating auto-syncs would be nice, but we've got along for eight years without, so meh. | 12:58 |
| Laney | I see the potential for abuse, but if we're just talking about the one bot account for auto-syncing then I'm not really very concerned. It would be easy enough to keep it fairly locked down. | 13:03 |
| Laney | Also, I thought that one of the benefits of moving to this new API is that we /wouldn't/ need a bot account for auto-syncing? | 13:04 |
| Laney | Archive admins just run the script on their own machine. | 13:04 |
| cjwatson | Well, yes and no | 13:05 |
| cjwatson | It means we *can* run it on our own machines, it means we don't have to run it as a user with direct Launchpad database access, it means we don't have to have a crazy scheme involving downloading source packages and pushing them through a special back door designed just for it, and it means it's a lot easier for us to improve our own tools | 13:07 |
| Laney | I see you might want to cron it, in which case this would be required | 13:07 |
| cjwatson | But it'd still be nice to be able to cron it. I don't think that should depend on any particular archive admin, and I don't want to grant access to my Launchpad account to a cron job. | 13:07 |
| cjwatson | Maybe just going with blanket upload AP entries would indeed be the right answer. I'll meditate some more, I guess. | 13:08 |
| Laney | So I'd a) Make a new ubuntu-autosync-bot user, b) Give it upload permissions to release (soon to be proposed), c) Give it queue admin to NEW, d) Add API to allow certain copying operations to bypass queues | 13:08 |
| cjwatson | a) is done, ubuntu-archive-robot | 13:09 |
| Laney | NEW/devel series, depending on how that goes | 13:09 |
| cjwatson | Actually, for c), I'd prefer NEW not to be automatic | 13:09 |
| cjwatson | We do wave through new auto-syncs fairly liberally, but I catch things that I don't want to auto-sync (and blacklist them or whatever) moderately frequently | 13:10 |
| cjwatson | If we had auto-sync --batch cronned, I'd want to be able to catch stupidity at the NEW queue admin level | 13:10 |
| cjwatson | Not full review or anything, just an "oh boy that package name looks kind of familiar" sort of thing | 13:10 |
| Laney | so you wouldn't even need it to be able to queue admin — that's even simpler, surely? | 13:11 |
| cjwatson | Perhaps I should remove it from ~ubuntu-archive. | 13:11 |
| cjwatson | I'm not sure it'll never want queue admin for something else in future. | 13:11 |
| cjwatson | Not for auto-syncs, but there's other stuff I want to cron. | 13:12 |
| cjwatson | copy-report is the most obvious one. | 13:12 |
| cjwatson | (Copy stuff from -security to -updates, without going through unapproved.) | 13:12 |
| cjwatson | But I suppose it could have queue admin AP on -updates. | 13:13 |
| Laney | maybe you'd want multiple users then, for protection | 13:13 |
| cjwatson | Possibly. | 13:13 |
| cjwatson | I don't think any changes set anything much in stone. | 13:13 |
| hggdh | skaet: shouldn't bug 949641 be re-milestoned? | 14:32 |
| ubot2 | Launchpad bug 949641 in fglrx-installer "Installing both fglrx and fglrx-updates results in: error exit status 1 -"/etc/init.d/atieventsd exists during rc.d purge"" [Critical,Triaged] https://launchpad.net/bugs/949641 | 14:32 |
| skaet | hggdh, yes, done now. | 14:33 |
| * skaet will dig into how that one got overlooked later today. | 14:34 | |
| hggdh | skaet: I could have done it, but I would rather ask | 14:34 |
| Laney | ScottK: I think you were referring to bug #648611 (as was discussed elsewhere in the thread, and in here) | 14:41 |
| ubot2 | Launchpad bug 648611 in launchpad "ubuntu-sru either have too much or too little permission as queue admins" [High,Triaged] https://launchpad.net/bugs/648611 | 14:41 |
| ScottK | Laney: That's the one. | 14:41 |
| Laney | But the description is weird, and it doesn't talk about distroseries granularity which you requested | 14:41 |
| cjwatson | I don't understand why that description wants per-upload-status granularity. Personally I'd like to avoid that. | 14:42 |
| cjwatson | Per-series is a bit nasty but I can understand it and it's not that far out of line with packagesets. | 14:42 |
| cjwatson | Although I suspect it would require a DB constraint change :-( | 14:42 |
| ScottK | cjwatson: I think it's reasonable to say that only ~ubuntu-archive can process New. | 14:43 |
| cjwatson | Is the converse also reasonable, though? | 14:43 |
| Laney | you probably want backporters to be able to do NEW backports | 14:43 |
| ScottK | True. | 14:43 |
| ScottK | cjwatson: I think it is. Since I'm not (yet) in ubuntu-sru, I've go no business accepting stuff to precise-proposed except to work around the current issues where I may do it on behalf of an ~ubuntu-sru member that can't. | 14:44 |
| cjwatson | Hm, maybe I was unclear | 14:45 |
| === med_ is now known as medberry | ||
| cjwatson | I mean, I agree that it's reasonable to say that only ~ubuntu-archive can process New; but would it also be reasonable to say that anyone with queue admin privileges to some intersection of pocket/series/whatever can process New as well as Unapproved? | 14:46 |
| === medberry is now known as med__ | ||
| === med__ is now known as med_ | ||
| cjwatson | I care because the latter is, I think, rather easier to implement. | 14:46 |
| cjwatson | I could probably do the former if I must. | 14:46 |
| cjwatson | Anyhow, this is all about future work on queue admin privileges, not about the upload changes that just landed, so let me go and add the latter permissions now | 14:47 |
| Laney | Personally I think pocket & series would be fine. | 14:47 |
| cjwatson | Looks like I was wrong that pocket & series would require a DB constraint change. | 14:48 |
| cjwatson | ALTER TABLE ArchivePermission ADD CONSTRAINT one_target CHECK ((null_count(ARRAY[packageset, component, sourcepackagename, pocket]) = 3)); | 14:48 |
| cjwatson | (Bizarre way of writing "you get only one of these".) | 14:49 |
| cjwatson | parser.add_option("-p", "--person", dest="person", action="append") | 14:50 |
| cjwatson | parser.add_option("-P", "--packageset", dest="packageset", action="append") | 14:50 |
| * cjwatson gives up on a short option for --pocket | 14:50 | |
| xnox | cjwatson: - p̂ | 14:51 |
| xnox | we have unicode ;-) | 14:52 |
| Laney | ρ | 14:54 |
| ScottK | cjwatson: I don't think I understand what you mean by "some intersection of pocket/series/whatever". Can you give an example (no rush - as you say, this is about future work) | 14:54 |
| xnox | Laney: p-hat is visually different from -p -P | 14:56 |
| === med_ is now known as med_out | ||
| === med_out is now known as med_away | ||
| === med_away is now known as med_ | ||
| Laney | so's rho! | 14:57 |
| cjwatson | ScottK: Pocket plus zero or more intersected constraints. Let's say, as an example, if we gave ~ubuntu-sru queue admin on -proposed, would it be reasonable to say that they could process NEW there (e.g. kernel ABI changes)? | 14:58 |
| ScottK | cjwatson: Yes. I think it is. | 14:59 |
| cjwatson | You said the contrapositive, that it would be reasonable to say that only ~ubuntu-archive can process NEW, but you didn't say you thought the opposite was unreasonable; so I'm trying to explore that. | 14:59 |
| ScottK | I didn't think about that case. | 14:59 |
| cjwatson | If you see what I mean. | 14:59 |
| ScottK | Yes. | 14:59 |
| ScottK | Equally, I think new backports should be OK for backporters. | 14:59 |
| cjwatson | 'cos that way I don't have to invent some way of embedding the upload status into an archive permission. | 14:59 |
| cjwatson | Excellent. I think we are in agreement on that part at least, then. :-) | 15:00 |
| ScottK | Ideally though in the case of backporters it would only be new for that release, not new to the archive as they aren't supposed to do that. | 15:00 |
| ScottK | That probably pushes things back into hard though. | 15:01 |
| cjwatson | I see what you mean. Hmm. | 15:01 |
| Laney | We'd get that if it were pocket & series, though? | 15:02 |
| cjwatson | No. | 15:02 |
| cjwatson | There isn't sufficient distinction between new to precise-backports because it was backported from quantal and not previously in precise(-backports), and new to precise-backports because it wasn't previously in Ubuntu at all. | 15:03 |
| cjwatson | Which I think is what ScottK means. | 15:03 |
| Laney | I don't think NEW captures that at all. | 15:04 |
| cjwatson | It doesn't. | 15:04 |
| Laney | That's part of the trust that you grant when you delegate queue admin | 15:05 |
| Laney | Maybe NEW would also be interesting if we manage to get backports pre-release off the ground | 15:07 |
| ScottK | Sure, but I'd like to make the technical capability and the policy constrains match as closely as possible. | 15:08 |
| ScottK | Laney: Even in that case, it would still need an archive admin review. | 15:08 |
| ScottK | While I'm dreaming, I'd like a secondary LP login that would be the only one that has queue access. | 15:09 |
| ScottK | Then I could log into that only when actually processing the queue. | 15:09 |
| Laney | How so (if permissions are just pocket/series)? | 15:09 |
| cjwatson | $ ./edit_acl.py -p laney -s coreutils -S precise --pocket backports check | 15:09 |
| cjwatson | Iain Lane (laney) cannot upload coreutils to Precise/Backports | 15:09 |
| cjwatson | $ ./edit_acl.py -p ubuntu-backporters --pocket backports add | 15:09 |
| cjwatson | Added: | 15:09 |
| cjwatson | Archive Upload Rights for ubuntu-backporters: archive 'primary', pocket 'Backports' | 15:09 |
| cjwatson | $ ./edit_acl.py -p laney -s coreutils -S precise --pocket backports check | 15:10 |
| cjwatson | Iain Lane (laney) can upload coreutils to Precise/Backports | 15:10 |
| bdmurray | SpamapS: how far through the precise queue did you get? | 15:10 |
| * Laney gets to it | 15:10 | |
| cjwatson | You were a handy example from sorted(set(p.name for p in lp.people['ubuntu-backporters'].members) - set(p.name for p in lp.people['ubuntu-core-dev'].members)) :-) | 15:10 |
| cjwatson | $ ./edit_acl.py -p ubuntu-security --pocket security add | 15:11 |
| cjwatson | Added: | 15:11 |
| cjwatson | Archive Upload Rights for ubuntu-security: archive 'primary', pocket 'Security' | 15:11 |
| Laney | ah, there's a handy main backport ready | 15:13 |
| cjwatson | I've committed the corresponding edit_acl.py changes now. | 15:13 |
| xnox | cjwatson: Laney is up with a core-dev application though =))))) | 15:14 |
| cjwatson | There are two other examples ;-) | 15:15 |
| * ScottK wonders if Laney's core-dev application should be rejected on the grounds of it being very late. | 15:17 | |
| cjwatson | DENIED: slacker | 15:17 |
| Laney | I didn't want to deny core-devs the warm internal glow that sponsorship provides :-) | 15:18 |
| Laney | cjwatson: ^ it works! | 15:22 |
| ScottK | Where does the sync blacklist live these days? | 15:22 |
| cjwatson | ScottK: lp:~ubuntu-archive/+junk/sync-blacklist | 15:22 |
| cjwatson | Laney: yay | 15:22 |
| ScottK | Thanks. | 15:22 |
| cjwatson | (Now where's that review-backport tool?) | 15:22 |
| Laney | /part | 15:23 |
| cjwatson | haha | 15:23 |
| ScottK | cjwatson: If an entry is obsolete, can I just remove it and push (blacklist)? | 15:24 |
| cjwatson | Sure | 15:25 |
| ScottK | Thanks. | 15:26 |
| Riddell | cjwatson: are you planning on moving kubuntu bits to universe any time soon? | 15:34 |
| cjwatson | Oh, er, yeah could do, let me get a BIG coffee | 15:34 |
| phillw | hi good people, has http://pad.ubuntu.com/ubuntu-release been retired? I see respins, but no reasons for them, thanks. | 15:53 |
| Riddell | phillw: there's no current release candidates going on | 15:54 |
| Riddell | cjwatson: if you happen to be in a channel with sabdfl can you remind him there's a kubuntu meeting in #kubuntu-devel in 5 mins? | 15:55 |
| cjwatson | You're seeing routine daily builds, not manual respins | 15:55 |
| phillw | Riddell: thanks, is there any 'pulling together' what is in each respin being logged? | 15:55 |
| cjwatson | Riddell: He's not on e.g. #canonical | 15:56 |
| phillw | thanks, cjwatson et all :) | 15:56 |
| Riddell | ah well | 15:56 |
| cjwatson | phillw: These are totally automatic builds. | 15:56 |
| phillw | thanks :) | 15:56 |
| cjwatson | phillw: So no. You can use things like the quantal-changes mailing list to see all changes in the archive. | 15:56 |
| phillw | I don't think I have the skills to decode that :) | 15:56 |
| cjwatson | Nor does the cron job running the daily builds. ;-) | 15:57 |
| phillw | lol | 15:57 |
| phillw | tochee :D | 15:57 |
| cjwatson | Riddell: Do either of us need to follow up to https://lists.ubuntu.com/archives/kubuntu-devel/2012-June/006135.html | 15:58 |
| cjwatson | ? | 15:58 |
| Riddell | cjwatson: I've not thought it much but my feeling is if someone want to upload a package they should check their changes get into the relevent packaging branch | 15:59 |
| Riddell | and anyone who doesn't isn't doing the task properly | 15:59 |
| Riddell | ~kubuntu- | 16:00 |
| Riddell | packagers | 16:00 |
| Riddell | is easy to add people to | 16:00 |
| Riddell | no approvals needed | 16:00 |
| cjwatson | So you're happy with a sort of post-merge review on any changes that turn up in Kubuntu | 16:00 |
| cjwatson | TBH the problem probably existed occasionally in main too | 16:01 |
| Riddell | cjwatson: happy enough | 16:06 |
| Riddell | generally I'd prefer they discuss it with the kubuntu developers if practical | 16:06 |
| cjwatson | Right, I mean as a recovery-from-error process rather than advertised process IYSWIM | 16:07 |
| cjwatson | I just want to make sure that I'm not going to do this and then have some set of people shout at me that I need to move gigabytes of data *back* :-) | 16:07 |
| Riddell | cjwatson: yeah it's fine | 16:08 |
| cjwatson | ('cos mirrors are probably going to notice this ...) | 16:08 |
| * infinity notes it's yet another "branches out of sync with archive" complaint, and wishes people would stop pretending branches are authoritative. | 16:08 | |
| cjwatson | Mind you I suppose it won't be anywhere near, say, a release | 16:08 |
| SpamapS | bdmurray: I got to June 9 | 16:09 |
| Laney | Why don't you just add motu to the team with the branches? | 16:09 |
| infinity | Laney: I'm sure they could, that doesn't mean the branches will be up to date. :P | 16:09 |
| Laney | It makes it slightly more likely | 16:10 |
| * infinity goes to push his change to the calligra branch, so it doesn't get dropped... | 16:10 | |
| skaet | phillw, have gone in and cleaned it up. ;) thanks for flagging | 16:10 |
| Laney | and quite a lot less irritating for someone who tries to do things the right way | 16:10 |
| infinity | Laney: I disagree that the "right way" is to create more busy work for someone doing a drive-by fix, but hey. ;) | 16:11 |
| SpamapS | bdmurray: its probably worth re-checking the ones we've nagged for testcase/regression potential quite regularly. I'm wondering if we should start rejecting things quicker.. like.. 1 week after the nag | 16:11 |
| Laney | One team's right way … :P | 16:11 |
| infinity | As long as source packages are authoritative (and they currently are), it will continue to irk me when people don't check the current state of the archive before uploading. | 16:12 |
| bdmurray | SpamapS: I found myself looking at ones you'd just commented on yesterday though | 16:13 |
| micahg | infinity: even with authoritative source packages we seem to get collisions (see ubuntu-meta earlier this morning) | 16:13 |
| SpamapS | bdmurray: shouldn't be too hard to just move to the next... but yeah | 16:14 |
| SpamapS | bdmurray: need some way to communicate "skip these" | 16:14 |
| bdmurray | SpamapS: well its the 20 tabs open that need to get closed which takes some time | 16:14 |
| infinity | micahg: That's the same error, really. Not checking a debdiff against the previous version before uploading. | 16:16 |
| infinity | micahg: Though, in the meta case, just hilarious, not damaging. | 16:16 |
| micahg | heh | 16:16 |
| infinity | micahg: The problem with people (mistakenly) considering branches authoritative is that they think "bzr diff" is enough to see what changes they've introduced. | 16:17 |
| micahg | Riddell: IMHO, it's worth a mail when the switch happens to remind people to check the Vcs-* fields when uploading | 16:17 |
| infinity | micahg: Which isn't even true if they're not reverting something someone else did. :P | 16:17 |
| cjwatson | bdmurray: I think your recent sru-accept.py change is a much better fix to my "Advertise pending-sru.html in sru-accept comment?" work item than the work item itself proposes. Can I reassign that WI to you and mark it done? | 16:17 |
| micahg | infinity: heh, yeah, I've given up on trusting bzr diff on random branches | 16:18 |
| SpamapS | bdmurray: I isolate my SRU work in a single browser window for that reason. :-P | 16:18 |
| bdmurray | cjwatson: sure, didn't know about that | 16:18 |
| cjwatson | (https://blueprints.launchpad.net/ubuntu/+spec/foundations-q-more-agile-sru-process) | 16:18 |
| cjwatson | all yours | 16:19 |
| cjwatson | thanks :) | 16:19 |
| infinity | micahg: I sort of treat them as two entirely different entities. bzr diff, of course, has its place when I'm actually working in bzr (as I do for some codebases), but I *always* debdiff my final upload against the previous version to cruft-and-reversion-check. | 16:19 |
| bdmurray | cjwatson: do you have any plans for that last work item? | 16:20 |
| cjwatson | bdmurray: sorry, which one? | 16:20 |
| bdmurray | [tb] patch sru-accept to link to .debs for -proposed in comment or the page of the binary package build in launchpad which has all the deb links from the librarian (as the security team does): TODO | 16:20 |
| cjwatson | oh, the one we hopefully assigned to tb | 16:20 |
| cjwatson | he suggested it so we voluntold him | 16:21 |
| cjwatson | I somehow doubt he'll have time to do it | 16:21 |
| cjwatson | no plans myself though it doesn't sound horribly difficult | 16:21 |
| bdmurray | right, I might just do it then | 16:21 |
| infinity | FWIW, I much prefer linking to the build(s) rather than the .debs. | 16:21 |
| cjwatson | agreed | 16:21 |
| cjwatson | possibly marginally easier anyway | 16:21 |
| micahg | I think that was the outcome of the session anyways | 16:22 |
| cjwatson | though you'll need one per arch of course | 16:22 |
| infinity | micahg: Yeah, the work item proposes both options. | 16:22 |
| cjwatson | bdmurray: be my guest | 16:22 |
| infinity | micahg: So, I thought I'd voice an opinion. ;) | 16:22 |
| micahg | infinity: just affirming support for you based on historical precedent :) | 16:22 |
| infinity | I assume the security team has cargo-cultable code here. | 16:22 |
| bdmurray | infinity: sssh, don't give away how I will do it | 16:23 |
| infinity | ;) | 16:23 |
| infinity | bdmurray: When you're done with that, would you like some of my work items too? | 16:24 |
| cjwatson | I've got more. | 16:25 |
| bdmurray | infinity: I'll get back to you on that ;-) | 16:26 |
| infinity | cjwatson: Oh, if you're resurrecting dsync-flist use in the publisher, remind me to resurrect my local project to actually make the code build on a modern OS and get it into the archive. | 16:26 |
| infinity | cjwatson: Cause, one of these days, elmo's hand-built binary from 1987 will explode. :P | 16:27 |
| cjwatson | It's not hopelessly slow if it's being run, like, ever. | 16:27 |
| cjwatson | It took two and a half hours to run generate on a year's worth of changes. | 16:27 |
| cjwatson | But a no-op run takes 9s. | 16:27 |
| infinity | Yeah, it's pretty quick when it's being run. | 16:27 |
| cjwatson | Do you think we could make it emit ls-lR somehow? | 16:28 |
| infinity | That said, it SHOULD be rolled into apt-ftparchive, IMO, and it could be really fast. | 16:28 |
| cjwatson | Seems like it should have most of the data. | 16:28 |
| cjwatson | I'd be totally happy to keep that if it were blindingly fast. | 16:28 |
| cjwatson | I mean, it can lie about some of the fields or something. | 16:28 |
| infinity | Hrm, yeah. If we could make ls-lR not suck, we could keep it. | 16:28 |
| * xnox adam and colin are discussing archive's black magic again | 16:29 | |
| cjwatson | It can't be that much harder than md5sums. | 16:29 |
| cjwatson | That's what we do. | 16:29 |
| infinity | And drink. | 16:29 |
| cjwatson | And drink. | 16:29 |
| infinity | But it's a bit early for that. | 16:29 |
| cjwatson | Sun's well over the yard-arm here. | 16:29 |
| infinity | cjwatson: Let me dig up the actual dsync source. It's on some laptop somewhere here. | 16:30 |
| cjwatson | I've got it if you don't. | 16:30 |
| cjwatson | -rw-r--r-- 1 cjwatson cjwatson 131189 Oct 26 2006 dsync_0.0-0.1.tar.gz | 16:30 |
| cjwatson | fresh | 16:30 |
| elmo | infinity: it's not hand built; I have sources! | 16:30 |
| elmo | there, see | 16:30 |
| cjwatson | (I suspect that's the time I downloaded it, though | 16:30 |
| cjwatson | ) | 16:30 |
| infinity | elmo: Sources that don't build anymore. ;) | 16:30 |
| cjwatson | drwxr-xr-x 9 cjwatson cjwatson 4096 May 16 2005 dsync-0.0 | 16:30 |
| elmo | these filthy accusations shall not stand | 16:30 |
| infinity | elmo: Hahaha. | 16:30 |
| cjwatson | dsync (0.0-0.1) experimental; urgency=low | 16:30 |
| cjwatson | * Make it build using g++-3.3. | 16:30 |
| cjwatson | -- Kurt Roeckx <kurt@roeckx.be> Mon, 16 May 2005 16:04:58 +0200 | 16:30 |
| cjwatson | That must be good enough, right? | 16:31 |
| elmo | WFM | 16:31 |
| infinity | Close enough. | 16:31 |
| * xnox adores cjwatson idioms http://en.wikipedia.org/wiki/Yard_(sailing)#.22Sun_over_the_yardarm.22 | 16:31 | |
| * micahg thought we added gcc 3.3 back to the archive | 16:35 | |
| cjwatson | Oh, that's all right then. :-P | 16:35 |
| cjwatson | It's only libstdc++5, not the compilers. | 16:36 |
| cjwatson | Anyone want to comment on anything in http://paste.ubuntu.com/1041070/ ? | 16:36 |
| cjwatson | That's what moving Kubuntu to universe would change. | 16:37 |
| * micahg wonders if the libjpeg stuff is worth seeding or not | 16:39 | |
| * micahg also wonders why a bunch of -dbg packages are now showing up | 16:39 | |
| cjwatson | -progs? Dunno. That's only a binary movement so easy enough to revert. | 16:39 |
| cjwatson | Probably because of different Extra-{Ex,In}cludes between the Ubuntu and Kubuntu supported seeds. | 16:40 |
| cjwatson | Some of those are probably a mite spurious. | 16:40 |
| * micahg guesses xscreensaver isn't worth keeping in main either | 16:40 | |
| cjwatson | bzr-doc is odd, what's up there | 16:41 |
| ScottK | Kubuntu has a development seed that is 'overbroad'. | 16:41 |
| ScottK | Some of that stuff comes from there. | 16:41 |
| cjwatson | Right, but bzr should be seeded in Ubuntu and its Extra-Includes should grab bzr-doc. | 16:41 |
| micahg | libzip is another one that looks like it might be worth keeping | 16:42 |
| xnox | cjwatson: speech-dispatcher-festival is interesting cause I thought orca works better with that | 16:42 |
| cjwatson | Mostly I'd rather people investigate what's going on and fix seeds rather than telling me :-) | 16:42 |
| * micahg isn't sure if these things are actually worthwhile or would do the commits | 16:43 | |
| cjwatson | Ah, some of this is seed madness | 16:43 |
| cjwatson | supported fails to inherit from server-ship | 16:43 |
| * cjwatson goes to try to rectify | 16:44 | |
| xnox | myspell going away, we still have something else in main, right? like hunspell? | 16:44 |
| * xnox doesn't now | 16:44 | |
| xnox | since emacs is in main please keep auctex | 16:45 |
| * xnox the world will be a better place with more emacs stuff | 16:45 | |
| cjwatson | It doesn't vanish because it's in universe | 16:45 |
| micahg | xnox: yes, although I thought some dictionaries didn't have hunspeel equivalents, maybe we don't have those languages? | 16:45 |
| cjwatson | I don't think we can necessarily sanely keep every add-on for everything | 16:45 |
| cjwatson | Right, I've fixed ubuntu.quantal/STRUCTURE; I'll generate a new version of that diff in a bit which will probably be rather substantially different | 16:47 |
| xnox | micahg: still seems strange, why so *little* of them moved. I'm suspicious. | 16:47 |
| cjwatson | Should be possible to investigate this by comparing germinate output on people.c.c | 16:48 |
| micahg | xnox: right, most likely, we'll need to seed those I think (myspell-he is one example) | 16:49 |
| * micahg fixes | 16:49 | |
| micahg | hrm, not sure where though | 16:50 |
| micahg | cjwatson: for any languages we don't ship on the live image, should I add the dictionary to the supported seed? | 16:51 |
| cjwatson | Are they regexable? You could put them next to the /^hunspell-[^-]*$/ regex entry. | 16:52 |
| cjwatson | Which is in supported, yes. | 16:52 |
| micahg | cjwatson: well, I think we just want the myspell ones when we don't have hunspell equivalents, right (or they are the hunspell equivalents) | 16:52 |
| cjwatson | micahg: Well, feel free to seed them individually there | 16:54 |
| micahg | cjwatson: thanks | 16:54 |
| cjwatson | infinity: dsync-flist md5sums takes 19s or thereabouts | 16:55 |
| cjwatson | Very tempting to just shove this back into ubuntu-archive-publishing by fiat. | 16:55 |
| infinity | cjwatson: Kay. I do wonder if this could be even faster if it could be taught to re-use apt-ftparchive's cache. | 16:55 |
| infinity | cjwatson: (Given that dsync is a mess of cargo-culted code from apt anyway...) | 16:55 |
| cjwatson | Except I have enough to do today. But something like http://paste.ubuntu.com/1041084/ | 16:56 |
| cjwatson | (Which roughly corresponds to the last version of that code before it was removed from Launchpad.) | 16:56 |
| infinity | I also wonder how that can be so fast, when ls-lR is doing less, and takes much longer... | 16:56 |
| cjwatson | It uses Packages and Sources, right? | 16:57 |
| cjwatson | Hmm. No. | 16:57 |
| infinity | Neither one does. | 16:57 |
| cjwatson | I guess it can use getdents and doesn't have to stat everything individually if it's in its cache. | 16:58 |
| infinity | dsync just walks the tree you give it. How that's faster than a recursive ls is a mystery. :P | 16:58 |
| * cjwatson straces | 16:58 | |
| cjwatson | ls -lR has to stat everything. | 16:58 |
| infinity | Fair point. | 16:58 |
| infinity | Makes a good argument for figuring out how to make dsync generate a fake ls-lR, if we want to keep it. | 16:59 |
| infinity | It should have all the appropriate info (except permissions, but who cares?) in its cache. | 17:00 |
| cjwatson | It actually does seem to do lots of lstats. | 17:02 |
| cjwatson | Not sure how it's so fast. Maybe I got lucky with caching and it wouldn't be fast if run after a publisher run? | 17:03 |
| infinity | Possibly. | 17:03 |
| cjwatson | It's bloody slow under strace. :-) | 17:04 |
| infinity | gdb the strace process, that'll speed it right up. | 17:06 |
| infinity | And then valgrind the gdb. | 17:06 |
| * cjwatson wonders if dsync is ctrl-c safe, and isn't sure he wants to experiment | 17:08 | |
| xnox | cjwatson: heartbeat move to universe is a bad idea. Expect to break a lot of servers. Ideally this should be under server's team control. | 17:11 |
| xnox | as many servers use only main. | 17:12 |
| cjwatson | xnox: Then it should be in a server seed somewhere. | 17:12 |
| xnox | and it's the only way to do high-availability. | 17:12 |
| xnox | hmmm how do I request / do that? | 17:12 |
| cjwatson | The point of the seed system is that I don't have to work it all out myself. :-) | 17:12 |
| * xnox is off to wiki about archive development | 17:12 | |
| cjwatson | MP into lp:~ubuntu-core-dev/ubuntu-seeds/ubuntu.quantal | 17:13 |
| cjwatson | heartbeat isn't explicitly seeded anywhere right now | 17:13 |
| xnox | hmmm so how come it ended up in main? | 17:13 |
| xnox | just because of kubuntu? | 17:14 |
| cjwatson | build-dep of pacemaker | 17:14 |
| xnox | yeah, is pacemaker moving as well?! | 17:14 |
| cjwatson | Which is in Ubuntu, so actually I'm pretty sure this is due to the problem I fixed above | 17:14 |
| cjwatson | So no need for an MP | 17:14 |
| cjwatson | You probably might as well stop investigating until I refresh the list | 17:14 |
| cjwatson | It's wrong | 17:14 |
| cjwatson | 17:47 <cjwatson> Right, I've fixed ubuntu.quantal/STRUCTURE; I'll generate a new version of that diff in a bit which will probably be rather substantially different | 17:15 |
| xnox | ok. | 17:15 |
| * xnox can't find neither pacemaker nor heartbeat in the seeds | 17:15 | |
| cjwatson | Build-dep of ocfs2-tools. | 17:16 |
| cjwatson | http://people.canonical.com/~ubuntu-archive/germinate-output/ubuntu.quantal/rdepends/ALL/heartbeat | 17:16 |
| cjwatson | (Which unfortunately doesn't say why ocfs2-tools is there; minor germinate bug I guess - but it's in the server-ship seed.) | 17:17 |
| cjwatson | But, you know, if it's that vital, maybe it ought to be explicit. | 17:18 |
| xnox | well I wonder why ocfs2-tools got added, cause pacemaker by itself should be explicit just in case IMHO. | 17:18 |
| xnox | pacemaker/hearbeat stuff has more usage than ocfs2-tools thingy | 17:19 |
| xnox | hmm seems ok | 17:19 |
| xnox | it looks like the server seed is explicit under cluster sections of everything you ever need to run any time of cluster stuff | 17:20 |
| * xnox doing merge proposal just in case | 17:20 | |
| * xnox done | 17:24 | |
| cjwatson | I'm sure that dsync-flist could be very much faster by assuming that files in the pool never change contents once created. | 17:25 |
| cjwatson | Which it doesn't seem to, so I've no idea how it was so fast earlier. | 17:25 |
| cjwatson | In fact it seems to predate package pools. | 17:25 |
| infinity | Well, it's format-agnostic. | 17:26 |
| cjwatson | Yeah, but what do I care. | 17:26 |
| infinity | I use it on random collections of mp3s and movies. :P | 17:26 |
| cjwatson | Freak | 17:26 |
| cjwatson | So maybe it would be faster to shove it in apt-ftparchive. It'd have to be run later rather than as part of the main a-f run though. | 17:26 |
| cjwatson | And that would kind of suck if the LP team ever finished getting rid of a-f. | 17:27 |
| infinity | I'm unconvinced that NMAF will actually work on large archives, personally. | 17:27 |
| cjwatson | And it would have to deal with the random files on the mirror. | 17:27 |
| infinity | It drops the local cache in favour of assuming the DB is insanely fast. | 17:27 |
| cjwatson | The general NMAF approach absolutely blew on dogfood, but then dogfood is horrible | 17:27 |
| cjwatson | And it's possible my queries were awful too | 17:27 |
| infinity | The a-f cache is a godsend on any sufficiently large archive. | 17:27 |
| cjwatson | (I'd been hoping to do germinate-from-db, but it seemed to be impractical) | 17:28 |
| cjwatson | https://code.launchpad.net/~cjwatson/launchpad/germinate-from-db | 17:28 |
| cjwatson | I don't think I knew about bulk loading then, so that would make a fairly enormous difference. | 17:28 |
| micahg | ok, dictionaries fixed | 17:35 |
| micahg | s/fixed/added to supported/ | 17:35 |
| skaet | infinity, ogra_ - any clue yet why we still don't have arm desktop dailies? | 17:39 |
| infinity | skaet: Oh, I pinged IS about doing some remote-hands debugging of celbalrai, and I think I must have cause webops on a shift change or something. | 17:40 |
| infinity | skaet: And then got busy with something else. :P | 17:40 |
| infinity | skaet: I'll poke harder. | 17:40 |
| skaet | thanks infinity | 17:40 |
| ScottK | infinity: You caused a shift change? | 17:41 |
| infinity | ScottK: caught. My fingers and brain aren't agreeing. | 17:42 |
| infinity | The classic case of typing "cau" and having your fingers go "HOLY CRAP, I KNOW THAT WORD" and filling in the rest with nonsense. | 17:43 |
| ScottK | Right, but it was funnier my way. | 17:43 |
| cjwatson | http://paste.ubuntu.com/1041164/ - better list of movements to universe due to Kubuntu | 17:57 |
| ScottK | Some of the binary only demotions seem odd, but it's definitely better. | 17:59 |
| cjwatson | supported-network-client (at least) still isn't inherited by supported. | 17:59 |
| cjwatson | Which causes e.g. irssi-dev. | 18:00 |
| * infinity wonders why lbdb was seeded in Kubuntu... | 18:00 | |
| infinity | Or was that also due to the above? | 18:00 |
| ScottK | No, it's on the DVD. | 18:00 |
| cjwatson | I wonder why supported-common fell out. That was what it was for. | 18:00 |
| ScottK | Probably the ambitious Kubuntu development seed. | 18:01 |
| ScottK | No, it's directly seeded in the Kubuntu DVD seed. No idea why. | 18:01 |
| cjwatson | Maybe dates from the original Ubuntu supported seed. | 18:01 |
| ScottK | That or the fact that Riddell is known to use Mutt. | 18:02 |
| xnox | This move to universe boggles me: | 18:02 |
| xnox | + o exim4-daemon-heavy-dbg exim4-daemon-light-dbg exim4-dbg exim4-dev eximon4{exim4} | 18:02 |
| cjwatson | Same cause, missing supported-common in supported's inheritance list. | 18:02 |
| cjwatson | Will be fixed in the next list. | 18:02 |
| cjwatson | ScottK: r89 in breezy, so probably just got blindly merged. | 18:03 |
| xnox | Moving this to universe is strange: | 18:03 |
| xnox | + o nagios3-dbg {nagios3} | 18:03 |
| cjwatson | xnox: Same cause. | 18:03 |
| xnox | not sure about: | 18:04 |
| xnox | + o libreiser4-dev {reiser4progs} | 18:04 |
| === yofel_ is now known as yofel | ||
| infinity | xnox: Might be worth giving up on reviewing the list until there's a new one. :P | 18:04 |
| bdmurray | our criteria regarding test case for SRU says 'These should allow someone who is not familiar with the affected package to reproduce the bug and verify that the updated package fixes the problem. | 18:04 |
| cjwatson | xnox: Same cause. | 18:04 |
| bdmurray | with the possibility of uploader verification is that still the case? | 18:04 |
| * ScottK would think so. | 18:05 | |
| micahg | bdmurray: as I recall from the session, yes, as it helps crystalize the issue in the mind of the person doing the SRU | 18:05 |
| xnox | Also concerned about all the speech-dispatcher and festival stuff, it basically will make ubuntu mute | 18:05 |
| infinity | bdmurray: I think that's a fair statement still for test cases, with an addition that "sometimes, this is very difficult or, indeed, next to impossible to satisfy, so a test-case that can be understood by the uploader or another person familiar with the package is acceptable if the verification will also be done by same". | 18:05 |
| ScottK | If you can't write it down, then you haven't thought it through. | 18:06 |
| infinity | ScottK: There are some test cases that I can perfectly reasonably write down, but someone "unfamiliar with the package" will not realistically be able to reproduce. | 18:06 |
| bdmurray | here's an example https://bugs.launchpad.net/nova/+bug/968843/comments/6 | 18:06 |
| ubot2 | Ubuntu bug 968843 in nova "[SRU] connection leak in rpc connection pool" [Undecided,In progress] | 18:06 |
| infinity | (Or, not without hours/days of learning and setup time) | 18:06 |
| * xnox prepares e2fsprogs testcase: take a block device larger than 16TB and run fsck against it..... then do this..... | 18:07 | |
| bdmurray | I've no idea where to set small pool size | 18:07 |
| ScottK | infinity: True. | 18:07 |
| bdmurray | nor how to cause an rpc response timeout | 18:07 |
| bdmurray | So I'd consider that insufficient | 18:07 |
| cjwatson | xnox: Er, that clearly can't be true since that's stuff that isn't in main right now. | 18:07 |
| cjwatson | xnox: Can we please tone down the hyperbole about how awful everything is going to be? :-) | 18:08 |
| infinity | bdmurray: That would one could, indeed, be better, but I'd be just as happy with that test case and a commitment that it will be tested by someone who understands it. | 18:08 |
| infinity | bdmurray: What I don't want is crappy (or no) testcases and an assumption that "Someone Else" will verify it. | 18:08 |
| xnox | cjwatson: your diff starts with no heading. What's the first heading/diff lines correspond to? | 18:09 |
| cjwatson | festival is genuinely unseeded in Ubuntu right now (as opposed to Kubuntu, where it was recently depended on by something), and not in main. | 18:09 |
| bdmurray | infinity: so stuff like "Test Case … None" would concern you? | 18:09 |
| cjwatson | xnox: it's against http://people.canonical.com/~ubuntu-archive/component-mismatches.txt | 18:09 |
| xnox | cjwatson: ok. | 18:09 |
| infinity | bdmurray: s/That would one could/Than one could/ ... No idea what's with my brain->finger interconnect today. | 18:09 |
| cjwatson | The first is "Source and binary movements to main" | 18:09 |
| xnox | cjwatson: makes sence =) | 18:10 |
| * xnox stay calm and carry on | 18:10 | |
| cjwatson | I can't regenerate a diff awfully quickly because this relies on the archive's germinate run. | 18:10 |
| infinity | bdmurray: No test case at all concerns me unless the "test case" is itself the bug (ie: "bug: package fails to ship copyright file, fix: patch that ships copyright file", in that case, "testcase: look at your filesystem" is pointless) | 18:10 |
| cjwatson | Which I can't really do while the publisher's running. | 18:11 |
| infinity | bdmurray: But quality of testcases is entirely dependant on who the tester(s) will be. I just want to know that testcase and test audience seem to be a matched set. :P | 18:11 |
| infinity | bdmurray: (I certainly have some glibc SRUs coming up where writing "idiot-proof" testcases will be a phenomenal waste of time) | 18:11 |
| * micahg wasn't under the impression they needed to be idiot proof, just clear enough that someone not intricately involved could decipher | 18:12 | |
| infinity | micahg: The problem is how one draws lines around what defines "not familiar with the package". | 18:13 |
| infinity | micahg: And a testcase that boils down to having someone just examine output of some commands doesn't mean they're testing that you've fixed the bug, they're testing that you've written the testcase to match the output. ;) | 18:14 |
| infinity | micahg: (As in, I'd argue that there are bugs where the tester has to understand the problem, period) | 18:14 |
| ScottK | Fundamentally, the SRU rules are the standard case. They aren't a suicide pact. I think the SRU team can use some judgment about what's appropriate on a case by case basis. | 18:17 |
| infinity | ScottK: Ed Zachary. | 18:17 |
| ScottK | ? | 18:17 |
| infinity | ScottK: Sorry. More formally, "I agree". | 18:17 |
| * infinity does enjoy that when he uses "Ed Zachary" in online conversation and people don't get it, the first hit on Google is less than flattering. | 18:18 | |
| ScottK | Yes. Yes it is (first hit on IxQuick anyway) | 18:19 |
| cjwatson | ooh ooh ooh | 18:20 |
| * cjwatson consigns type-handling to the flames^W^Wuniverse | 18:20 | |
| cjwatson | Now that gdb's been fixed | 18:20 |
| cjwatson | Is reverse-depends giving 403 for anyone else? | 18:23 |
| cjwatson | Oh sod it, it's quitting time. /me -> pub | 18:24 |
| hggdh | I just tried a 'do-release-upgrade -d' to quantal -- it fails on 404s from extras.ubuntu.com. Is this expected? | 19:59 |
| stgraber | no | 20:05 |
| stgraber | I thought I fixed that one... | 20:06 |
| stgraber | oh, and I did :) though it looks like the mirroring script IS is running doesn't sync quantal... | 20:06 |
| stgraber | hggdh: fixed | 20:21 |
| hggdh | stgraber: you are my hero :-) | 20:22 |
| micahg | did someone do a giveback of FTBFS in stable releases again? | 22:20 |
| * micahg is just wondering why chromium in oneiric is building | 22:21 | |
| infinity | micahg: Hrm? | 22:44 |
| infinity | micahg: Are you sure it wasn't something that failed in one pocket, then got copied? Or similar? | 22:44 |
| micahg | infinity: hrm, idk, I thought it was already in -updates and -security | 22:48 |
| infinity | Dunno. I never give back things in non-development releases except explicitly. | 22:50 |
| infinity | And if anyone else does, I'm not aware of it. And I wish they'd stop. :P | 22:50 |
| * micahg had some stuff rebuilt last night when he copied some packages to another PPA as a backup | 22:53 | |
| micahg | but that only used 1hr of useful build time | 22:53 |
| herton | hi, can some AA copy linux-ti-omap4: 3.0.0-1211.23 to -updates (bug 1005455)? | 23:29 |
| ubot2 | Launchpad bug 1005455 in linux-ti-omap4 "linux-ti-omap4: 3.0.0-1211.23 -proposed tracker" [Medium,In progress] https://launchpad.net/bugs/1005455 | 23:29 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!