| ScottK | doko_: ^^^ has bug fixes we should have in at the open. | 07:00 |
|---|---|---|
| obounaim | Good morning everybody | 07:22 |
| Daviey | cjwatson / ScottK: Please could you accept the maas SRU? | 08:08 |
| === henrix_ is now known as henrix | ||
| === doko_ is now known as doko | ||
| cjwatson | ... I can't say I would have accepted those before general opening, personally | 10:03 |
| cjwatson | They aren't important for building other packages | 10:03 |
| infinity | cjwatson: I find the lack of syntax hilighting while preparing other uploads wildly annoying, but YMMV. | 10:15 |
| infinity | cjwatson: Working on eglibc and base-files right now, which are, admittedly, a bit more crucial. | 10:16 |
| cjwatson | I'm happy to edit that locally temporarily. | 10:16 |
| cjwatson | Since usually I continue running stable for a while (although this release may be different). | 10:16 |
| infinity | I'm looking forward to britney making this the first release I'm not scared poopless about running from day 1 on my laptop. | 10:17 |
| * infinity crosses his fingers. | 10:17 | |
| cjwatson | Yeah. I'm starting in on the LP changes now. | 10:17 |
| infinity | Hrm. If you apply the rewrite magic universally to all releases, I wonder if I should make the emacs-el bits match Debian (which only allows/hilights $release and $release-security, due to their auto-rewriting for -proposed-updates) | 10:19 |
| cjwatson | I was going to make it a per-DS flag. | 10:19 |
| infinity | Would make sense to just do it universally anyway, but will take some time to socialise it. | 10:19 |
| cjwatson | Dunno, maybe it should be on Distribution. | 10:19 |
| infinity | And I assume it won't attempt to rewrite -proposed, to people using the old method will still get the desired results. | 10:20 |
| infinity | s/to people/so people/ | 10:20 |
| cjwatson | Indeed. | 10:20 |
| infinity | My fingers need tea. | 10:20 |
| cjwatson | I guess Distribution already has a substantial assortment of random columns. | 10:20 |
| infinity | I can't see any reason why this would be a per-series flag. | 10:20 |
| infinity | Just confused to have it DTRT for some series and not all. | 10:21 |
| infinity | s/confused/confusing/ # see above, WRT tea for fingers... BRB. | 10:21 |
| cjwatson | I was sort of thinking of the old state of Ubuntu, where we might have liked to have it auto-rewrite for everything but the dev series. | 10:21 |
| cjwatson | But whatever. | 10:21 |
| cjwatson | wgrant: ^- any opinions? | 10:21 |
| infinity | Oh, there's that possibility, yes. Could still be a Distribution thing, but have a toggle for "don't do this for non-stable series". | 10:22 |
| infinity | Then it won't need to be twiddled as we release/open old/new series. | 10:22 |
| infinity | But rather, just be a question of setting a policy that DTRT. | 10:22 |
| cjwatson | It's certainly a reasonable point that we don't want to add more steps to NewReleaseCycleProcess. | 10:22 |
| wgrant | Mmm | 10:23 |
| wgrant | My opinion is that the whole thing is terrible :P | 10:23 |
| wgrant | But | 10:23 |
| infinity | cjwatson: I think it makes more sense as a policy thing than a per-series thing. If we want stable/supported rewritten, but not devel, we don't want that to always be true, not just when we remember to set it. :) | 10:24 |
| infinity | cjwatson: (Not that I think we want that, but I see that we may in the future decide to go back that direction, or that some other mystical LP-using distro may want it that way) | 10:25 |
| infinity | It's certainly what Debian would want if they used Soyuz. | 10:25 |
| wgrant | If any other distro wanted to use LP we'd have to rework the whole suite system anyway | 10:25 |
| infinity | Yeah, I guess so. Certainly in the Debian case, where there are technically two suites in development at all times. | 10:26 |
| * infinity wonders idly why we unsplit the glibc docs, rather than just pulling in the non-free package and having a dependency, and goes about reducing that massive delta. | 10:30 | |
| wgrant | Do we really want to rewrite post-release release to proposed? | 10:31 |
| wgrant | I guess it's OK since it'll end up in Unapproved anyway | 10:31 |
| infinity | wgrant: I'm failing to see why we wouldn't? | 10:31 |
| wgrant | Well | 10:31 |
| infinity | wgrant: It how I do all my uploads anyway (precise in the changelog, precise-proposed in the .changes) | 10:31 |
| wgrant | LP has always done what you told it to in this respect | 10:31 |
| infinity | s/It/It's/ | 10:31 |
| cjwatson | Where one of the options is "fail and make you reupload" and the other is "do what you meant" | 10:32 |
| wgrant | Right, and it's not so bad since it always requires approval, I suppose | 10:32 |
| cjwatson | Indeed. There've been basically no complaints about Debian auto-rewriting stable to proposed-updates, which has been the case for years | 10:33 |
| cjwatson | Hm, I'd been going with .forbid_release, but now that I come to write help strings and such I think it should be .redirect_release_uploads | 10:34 |
| wgrant | Yeah, forbid_release is a bit wrong | 10:34 |
| wgrant | Also, depending on where you do the rewrite you might need to think about how it impacts binary uploads | 10:35 |
| wgrant | And what about copies? | 10:35 |
| cjwatson | Definitely must not redirect copies, because that's how we're going to do promotion from -proposed. | 10:36 |
| cjwatson | Might at some point consider allowing copies only to queue admin. | 10:36 |
| wgrant | Right, but this sort of inconsistency has the potential to bite people | 10:36 |
| cjwatson | Well, syncpackage, true. | 10:37 |
| wgrant | "oh I want to upload to raring... but let me go via a ppa... oh whoops copies don't redirect" | 10:37 |
| wgrant | dak doesn't really have this problem since the only way mortals interact with it is via dput | 10:37 |
| cjwatson | I think a possibility I suggested in passing last week was to have copies redirect unless you're a queue admin and use auto_approved=True (thereby signalling that you're acting as a queue admin) | 10:38 |
| wgrant | That seems even more magic | 10:38 |
| cjwatson | So I agree a lot of this is a fair bit of magic; I'm open to suggestions that don't involve having to re-educate every Ubuntu uploader | 10:39 |
| infinity | Well, I think most of this, if done as written above, only requires educating archive admins. Since the average uploader will just have the Right Thing happen, no? | 10:41 |
| wgrant | infinity: Not for copies | 10:41 |
| cjwatson | Where "as written above" includes my more-magic suggestion, I think | 10:42 |
| infinity | wgrant: I was including Colin's... Yeah. | 10:42 |
| wgrant | The auto_approved=True thing is far too magic | 10:42 |
| cjwatson | Alternative proposal which probably isn't too hard: redirect=False (or similar) | 10:42 |
| wgrant | It *might* be acceptable for it to reject if auto_approved=False, but not redirect | 10:42 |
| wgrant | Right | 10:43 |
| cjwatson | Not redirecting for normal uploaders means we have all the hassle of changing syncpackage in stable series | 10:43 |
| wgrant | But all the sanity of having one less opaque boobytrap in Launchpad. | 10:44 |
| wgrant | Which is then encoded in tools for years/forever | 10:44 |
| wgrant | And impossible to change without disastrous consequences | 10:44 |
| cjwatson | So you'd actually prefer copies to behave differently from uploads? | 10:45 |
| cjwatson | That's kind of a boobytrap too, just a different one | 10:45 |
| wgrant | It's not a boobytrap if the copy API tells you to go away when you try :) | 10:45 |
| cjwatson | I suppose copies are more explicit about a bunch of things | 10:45 |
| cjwatson | True | 10:45 |
| wgrant | Right, that too | 10:45 |
| infinity | Copies rejecting and suggesting you might have wanted -proposed would be an alright compromise, but as stated, we'd need to SRU all the old releases to sync to proposed. | 10:46 |
| * infinity glares at pidgin-libnotify landing after Q released. | 10:47 | |
| cjwatson | I guess people can use -r raring-proposed in the meantime. | 10:47 |
| cjwatson | Assuming that works. | 10:47 |
| cjwatson | Yeah, it does. | 10:48 |
| infinity | Oh, wait, that notification bubbles, not indicator integration. | 10:48 |
| wgrant | The fact that you have to SRU any API change is an excellent argument for making the API not be full of boobytraps. | 10:48 |
| Laney | yeah | 10:48 |
| wgrant | Because if they prove to be a problem then we can't change them later | 10:48 |
| Laney | someone is working on a patch for the indicator stuff | 10:48 |
| infinity | Laney: Good. I'm wildly miffed that when I upgraded my main machine to Q, I lost the only two consumers of the messaging menu that I care about (pidgin and gm-notify) | 10:49 |
| cjwatson | wgrant: Mm. True. | 10:50 |
| wgrant | The reasons given for wanting the upload redirect are a) retraining developers, and b) ugly changelogs | 10:51 |
| wgrant | I hardly think a) is particularly valid at all :) | 10:51 |
| wgrant | And b) doesn't apply to copies | 10:51 |
| infinity | Well, we could fix (b) with end-user tools doing the rewrite, though I don't really want that hack in dpkg-genchanges. :P | 10:52 |
| infinity | Mostly, I just felt the redirect was the right DWIM thing, but that's years of Debian redirects that have trained me to expect that. | 10:53 |
| wgrant | Sure, it is the right DWIM thing. | 10:53 |
| infinity | And, if the counter-proposal is just to hard reject all uploads to $series, don't we still need to consider how that affects copies, and when? | 10:53 |
| wgrant | But there's a tradeoff there | 10:53 |
| infinity | The rewriting seems orthogonal to the "no uploads to $series except for copies from $series-proposed in a devel release" thing. | 10:54 |
| wgrant | infinity: Indeed, that would probably need to be made explicit (or it could be folded into auto_approve; I don't have a problem with auto_approve approving extra stuff, it just must not affect a redirect) | 10:54 |
| infinity | wgrant: Well, a redirect=False on copies would work then, right? Allowing us to attempt a copy to $series, and check if we have the right perms to do so, etc? | 10:57 |
| cjwatson | I'm inclined to suggest that build uploads should never be redirected. | 10:58 |
| wgrant | Build uploads must never be directed, indeed | 10:58 |
| wgrant | That would destroy ~everything | 10:58 |
| wgrant | It's possible that you can just hack the insecure policy to do it | 10:59 |
| wgrant | I'm not sure if that's reasonable | 10:59 |
| cjwatson | Probably better than doing it in the upload processor + nascentupload (which mysteriously both construct policies independently). | 11:01 |
| wgrant | Hee hee | 11:01 |
| wgrant | Yeah | 11:01 |
| wgrant | That code has some terrible demons lurking | 11:01 |
| wgrant | With not insignificant chunks ripped straight from dak... | 11:01 |
| infinity | Build uploads wouldn't need to bypass the redirect. | 11:01 |
| infinity | They always upload to the right series. | 11:01 |
| cjwatson | (And why does soyuz_process_upload live under lp/soyuz anyway?) | 11:02 |
| infinity | Oh, except if it's a retry after it's been promoted, then it would build in $series, but a redirection would try to rewrite that. | 11:03 |
| infinity | Otherwise, though, buildds don't get the upload series from the changelog, but from sbuild (which gets it from buildd-master), so it should be correct. | 11:03 |
| wgrant | infinity: Hmm? | 11:04 |
| infinity | wgrant: Was just talking myself through why buildds need an exception here. :P | 11:04 |
| wgrant | uploadprocessor doesn't get it from the changelog either | 11:04 |
| wgrant | It's normally from the Distribution field in the .changes | 11:04 |
| infinity | wgrant: uploadprocessor gets it from the changes, I assme? Or is that different for binary uploads for some reason? | 11:04 |
| infinity | wgrant: Yes, exactly. | 11:04 |
| wgrant | But depending on the layer that cjwatson rewrites at... | 11:04 |
| wgrant | We hopefully ignore the .changes Distribution for buildd uploads | 11:05 |
| wgrant | Given that we know the build it's coming into | 11:05 |
| infinity | And by "ignore", you mean "don't rewrite". | 11:05 |
| wgrant | There's a sanity check that various .changes metadata matches the build, but I forget if that's part of it | 11:05 |
| infinity | Cause binary .changes is always what we want it to be. | 11:05 |
| wgrant | It should always match, indeed | 11:05 |
| wgrant | But Launchpad already knows where the build is meant to go | 11:06 |
| wgrant | It doesn't need to read the .changes | 11:06 |
| wgrant | This isn't Debian :) | 11:06 |
| infinity | True, given that the .changes contains exactly what LP told us. | 11:06 |
| infinity | Though, that's true in Debian as well. :P | 11:06 |
| cjwatson | The insecure policy seems like an OK place to do this, which makes the question moot. | 11:06 |
| wgrant | So we *probably* ignore the .changes Distribution, but depending on where cjwatson overrides it could impact the build-derived target suite too | 11:07 |
| wgrant | But if you do it in insecure, it's fine as you say | 11:07 |
| infinity | Actually, wait. | 11:08 |
| wgrant | infinity: Is that really true in Debian now? | 11:08 |
| infinity | We absolutely ignore .changes | 11:08 |
| wgrant | infinity: I thought Debian buildds still just uploaded signed binaries into whatever suite and dak believed them | 11:08 |
| wgrant | infinity: Why do we absolutely ignore .changes? | 11:09 |
| infinity | wgrant: Well, yes, but the buildds are getting the suite from wanna-build. So, not much different from buildd-master telling us what to build for. | 11:09 |
| wgrant | Sure, but the thing in question here is how the upload processor chooses the target suite | 11:09 |
| wgrant | In dak it will respect what the buildd tells it | 11:10 |
| wgrant | In LP it probably won't | 11:10 |
| cjwatson | Do we want a log message telling the uploader about the redirect (as Debian does)? | 11:10 |
| infinity | wgrant: Oh, nevermind. I was thinking something relating to Daniel's stellar design decision to pass -dautobuild to sbuild, but I fixed that years ago. Some part of my brain is living in the past. | 11:10 |
| wgrant | infinity: Heh | 11:11 |
| wgrant | cjwatson: Please | 11:11 |
| wgrant | cjwatson: Even better if that ends up in a convenient place in the Accepted mail somewhere | 11:11 |
| cjwatson | That's what I was thinking | 11:11 |
| wgrant | Although I forget if the new format has a logical place for that | 11:11 |
| cjwatson | Not that upload policies currently have a logger, but ... | 11:11 |
| infinity | It should end up in the Accept/Hold mail anyway. | 11:11 |
| infinity | Since an upload to $foo should end up saying "Accepted in $foo-proposed" | 11:12 |
| wgrant | cjwatson: there's probably a well-known logger name, like there is in buildd-manager | 11:12 |
| cjwatson | It can go somewhere near "Announcing to ..." | 11:12 |
| wgrant | Subjects say something like [ubuntu/raring-proposed] already, don't they? | 11:12 |
| wgrant | But I'd prefer an explicit log line | 11:12 |
| wgrant | As the subject is easy to miss | 11:12 |
| infinity | Yeah, both are fine. | 11:12 |
| cjwatson | wgrant: Did I just catch you assuming logic from LP? | 11:12 |
| cjwatson | (AFAICT archiveuploader just passes through an explicit logger everywhere.) | 11:13 |
| wgrant | Heh | 11:13 |
| wgrant | Well | 11:13 |
| wgrant | It's an open question which of those is more logical | 11:13 |
| cjwatson | Oh, bah, the notification mails are just constructed from a great big static template | 11:14 |
| wgrant | PPA acceptance emails have something fairly free-form at the top | 11:15 |
| wgrant | I can't remember how dissimilar the PPA template is | 11:16 |
| cjwatson | I could shove %(SUMMARY)s into the distro one, I suppose | 11:16 |
| cjwatson | But I think it fits better down below in the new format | 11:17 |
| wgrant | Yeah | 11:17 |
| cjwatson | Since IIRC the intention was for the top bit to still be vaguely parseable, in principle | 11:17 |
| wgrant | Indeed, although that matters more for announcement than acceptance | 11:21 |
| cjwatson | Announcements don't really need to be terribly explicit about redirects. | 11:22 |
| wgrant | Exactly | 11:22 |
| wgrant | It's not important for the announcement at all | 11:22 |
| wgrant | And it's the announcement that was intended to be parseable | 11:22 |
| wgrant | I suppose I should actually look at an acceptance mail to see just how parseable they are today | 11:23 |
| wgrant | Ah | 11:24 |
| cjwatson | Would it be OK for this to go in an "Upload Warnings:" section? archiveuploader constructs once of those, although it doesn't currently go in distro acceptance messages. | 11:24 |
| wgrant | They are more similar than I remembered. | 11:24 |
| wgrant | Yeah, that sounds reasonable | 11:24 |
| wgrant | Upload warnings don't spam us | 11:24 |
| wgrant | I forget the full set of current warnings, though | 11:25 |
| wgrant | All I can remember is the one about the lack of debian/copyright | 11:25 |
| wgrant | I think that may, in fact, be the only one | 11:26 |
| wgrant | Ah, PPA quota too | 11:27 |
| wgrant | So yeah, seems like a reasonable place | 11:27 |
| cjwatson | Also urgency overrides | 11:28 |
| wgrant | Hmm | 11:29 |
| wgrant | But we get cronspam about those | 11:29 |
| wgrant | Oh | 11:29 |
| wgrant | priority overrides cronspam, urgency overrides end up in Upload Warnings | 11:29 |
| wgrant | Right | 11:29 |
| wgrant | Makes sense :/ | 11:30 |
| henrix | infinity: it looks like we have a small prob with the lts-quantal | 12:59 |
| henrix | infinity: we're not able to create the tracking bug because the package has never been uploaded | 12:59 |
| henrix | any chances of getting it back? :) | 12:59 |
| henrix | herton: bjf: ^^ | 13:00 |
| rtg | which was _why_ I uploaded last Friday. | 13:00 |
| bjf | i agree and why i said an 18 would be coming soon | 13:00 |
| rtg | all stable activity is predicated on the existence of the source code package | 13:00 |
| bjf | henrix, if necessary, just upload an 18 without a tracking bug | 13:01 |
| henrix | rtg: right, and makes sense. i didn't realised that we wouldn't get a tracking bug. | 13:01 |
| bjf | henrix, the other thing you can do is just create a bug by hand which will become the tracking bug for the package you upload | 13:04 |
| bjf | henrix, once it hits -proposed you can then just fix it up by hand | 13:04 |
| rtg | create it using 'linux' as the source package name, then just change it later. | 13:05 |
| henrix | bjf: hmm, ok. i guess that could be done. thanks | 13:05 |
| bjf | ack | 13:05 |
| infinity | henrix: Ahh, yeah, can't file bugs against something that doesn't exist. Not world-ending. | 13:07 |
| infinity | (Not worth QAing a -17- upload just to be able to file bugs against it, mind you, which was why I rejected it if -18- was happening today) | 13:08 |
| infinity | I could accept -17- to proposed just to make your life easier, I suppose. | 13:08 |
| bjf | infinity, it isn't going to be QA'd if we mark the tasks invalid, we just need something in the archive | 13:08 |
| infinity | bjf: Well, "need" being a bit strong. The copy will still work if the target doesn't exist. | 13:09 |
| infinity | bjf: But if you'd prefer it this way to make the bot less grumpy, it's not like burning buildd time right now will hurt. | 13:09 |
| infinity | bjf: I can accept Tim's uploads right now. | 13:09 |
| bjf | infinity, just accept rtg's upload please | 13:09 |
| henrix | bjf: infinity: ok, so i'll wait for -17 to get accepted | 13:10 |
| infinity | Sure, just give me a moment to do the NEW review. | 13:10 |
| henrix | infinity: sorry for the mess. i should have thought about that before ;) | 13:11 |
| infinity | henrix: Well, just having it in the PPA without the tracking bug (until after I copy) would have worked just fine too. | 13:11 |
| infinity | But I need to review this at one point or another anyway. | 13:12 |
| infinity | So. May as well do it now. | 13:12 |
| infinity | henrix: BTW, for my peace of mind, do you intend to generate lts-quantal using an exact copy of the .orig.tar.gz from quantal? | 13:16 |
| infinity | henrix: (Cause Tim's was built natively, which makes it a fair chunk different from Q) | 13:17 |
| henrix | infinity: we use a script debian.quantal/etc/update-from-quantal-master, which rebases the lts branch against the release repo | 13:21 |
| infinity | henrix: Branch rebasing isn't building the debian source package. I mean when you build the source package, have a linux-lts-quantal_3.5.0.orig.tar.gz in .. that is an exact copy of linux_3.5.0.orig.tar.gz from quantal. | 13:22 |
| infinity | henrix: Saves space for mirrors that use hardlinks, and also makes the two source packages much easier to audit as being related to each other. | 13:22 |
| henrix | infinity: ah, ok. we do that for the linux packages, but not for the lts | 13:23 |
| infinity | henrix: Might be nice if you started. ;) | 13:24 |
| infinity | henrix: Given that, other than some bits in Debian, they're pretty much identical and all. | 13:24 |
| henrix | infinity: ack | 13:25 |
| infinity | henrix: Just make sure the orig is an exact copy, or it'll kinda defeat the purpose. Cause if it's identical, you just saved ~100MB (per source package) for every mirror that isn't silly. And a lot more, once you factor in version bumps. | 13:27 |
| rtg | infinity, is the orig tarball name a function of the source package name ? in which case we're gonna end up with a 2nd tarball anyways, but we can still save a shitload of space for subsequent uploads. | 13:32 |
| rtg | s/is/isn't/ | 13:32 |
| cjwatson | rtg: Yes. | 13:33 |
| cjwatson | (Although a few mirrors know how to hardlink identical files.) | 13:34 |
| infinity | rtg: Yes, I specifically mentioned the hardlinking above for that reasons. | 13:35 |
| infinity | s/reasons/reason/ | 13:35 |
| infinity | rtg: Either way, as you note, it saves space in subsequent uploads, even for less bright mirrors. | 13:35 |
| rtg | ah, missed that | 13:35 |
| infinity | henrix: Oh, and if I missed mentioning it, I accepted Tim's uploads, so shankbot should be happy about creating bugs. | 13:37 |
| henrix | infinity: ack, thanks | 13:38 |
| cjwatson | abcde is a test case I'm running for -proposed migration | 15:06 |
| xnox | the name of the package is too generic, testme-please-ignore1 would be better.... oh wait it's a real package called "abcde" and it has nothing to do with teaching alphabet.... *sigh* abcde: A Better CD Encoder | 15:09 |
| * highvoltage always liked the name of that program | 15:10 | |
| cjwatson | http://people.canonical.com/~ubuntu-archive/proposed-migration/ - most boring possible output :-) | 15:10 |
| highvoltage | you can do a lot worse, like there's an educational flashcard program called "iGNUit!" (urgh) | 15:10 |
| cjwatson | all I needed was something that wasn't compiled and so wasn't involved in any toolchain work; abcde happened to be first in the list from auto-sync output | 15:11 |
| xnox | I am suspecting ben the transition tracker is still pointing to quantal instead of raring http://people.canonical.com/~ubuntu-archive/transitions/ | 15:51 |
| xnox | http://people.canonical.com/~ubuntu-archive/transitions/python3.3.html has lxml at 2.3.5-1 yet it is 3.0.1-1 in raring | 15:51 |
| cjwatson | xnox: fixed for next run | 15:53 |
| cjwatson | though you could have done that yourself I think - it's ubuntu/download/archive{,_ports}.ben | 15:53 |
| Laney | yeah | 15:53 |
| Laney | I don't think it's encoded in the script that runs it | 15:53 |
| cjwatson | it's not | 15:53 |
| cjwatson | http://paste.ubuntu.com/1297805/ | 15:54 |
| Laney | we need to be making this learn about proposed | 15:54 |
| cjwatson | Laney: do you have access to the chroot this runs in nowadays? | 15:54 |
| Laney | no | 15:54 |
| cjwatson | we should get you into ~ubuntu-archive so that you do | 15:54 |
| cjwatson | then you can sort out the new tracker code so I don't have to :-) | 15:55 |
| Laney | I wouldn't complain | 15:55 |
| cjwatson | since I'm obviously failing to | 15:55 |
| Laney | there's already an RT to get ben installed on that box | 15:55 |
| Laney | I suspect it won't happen until someone pushes at it though | 15:55 |
| cjwatson | https://launchpad.net/ubuntu/+source/abcde/+publishinghistory - looks moderately sane | 15:58 |
| cjwatson | ubuntu-archive-robot will end up being blamed for a lot of stuff :) | 15:59 |
| Laney | heh | 15:59 |
| xnox | cjwatson: thanks... doh =) should have done myself. | 15:59 |
| Laney | will there be a hinting mechanism for our britney? | 15:59 |
| cjwatson | It shouldn't affect anything processing *-changes lists | 15:59 |
| * xnox wants new tracker =)))) | 15:59 | |
| cjwatson | But if there are things that try to assign blame by processing the publishing history, they'll probably need to be adjusted | 15:59 |
| cjwatson | Laney: the code's there, and I expect we'll need it occasionally, but I was going to cross that bridge when we came to it | 16:00 |
| xnox | Laney: well manual copies are still possible to bypass britney =) | 16:01 |
| Laney | mmm | 16:01 |
| * Laney is aware of what we do to Debian's RT with Haskell. | 16:01 | |
| cjwatson | xnox: that's not a given | 16:01 |
| xnox | cjwatson: ?! /me doesn't get it. | 16:02 |
| cjwatson | xnox: manual copies to bypass britney will probably not remain possible | 16:02 |
| * xnox :`( | 16:02 | |
| xnox | oh well. Better be good with my uploads then. | 16:02 |
| cjwatson | otherwise everyone using syncpackage would bypass it | 16:02 |
| cjwatson | (until we modify it, but even then ...) | 16:03 |
| xnox | hmm... mk-sbuild should add -proposed to sources by default. And quantal ppa's as well?! | 16:16 |
| cjwatson | No! | 16:16 |
| cjwatson | Absolutely not! | 16:16 |
| cjwatson | *Don't* encourage actual users to use -proposed | 16:17 |
| cjwatson | A lot of people use sbuild chroots for non-buildy things ... | 16:17 |
| xnox | but buildd will build against -proposed, while locally it will build against release. | 16:17 |
| cjwatson | (Sorry, maybe my exclamations were a bit OTT) | 16:18 |
| xnox | well, you have a point =) | 16:18 |
| cjwatson | Why talk about quantal PPAs then? | 16:18 |
| cjwatson | buildds won't build against those ... | 16:18 |
| xnox | s/quantal/raring/ | 16:18 |
| cjwatson | buildds won't build against raring PPAs either | 16:18 |
| xnox | yeah, agree. Forget I ever mentioned PPAs. | 16:19 |
| xnox | but pbuilder-dist & mk-sbuild - should or shouldn't add -proposed? | 16:19 |
| cjwatson | OK, maybe that confused me | 16:19 |
| cjwatson | Arguably | 16:19 |
| xnox | for raring, while it's development release. | 16:19 |
| xnox | well always.... as it becomes SRU staging archive. | 16:20 |
| cjwatson | I guess at least with an option | 16:20 |
| cjwatson | (like --skip-updates) | 16:20 |
| xnox | opt-in then. | 16:20 |
| cjwatson | I could see it either way; it kind of depends on the target audience | 16:20 |
| cjwatson | Builds in raring PPAs probably won't use -proposed by default | 16:21 |
| cjwatson | Builds aimed at the primary archive might well want to be tested against -proposed | 16:21 |
| Laney | Then you get into the situation where people end up enabling -proposed on their machines to satisfy dependencies | 16:21 |
| xnox | ack. And if a developer is caught in a transition, they should know & learn about it. | 16:22 |
| cjwatson | We're still going to have to put effort into keeping transitions as brutally short as possible | 16:22 |
| cjwatson | So, yeah, disregard my "No!" above - I was out of line | 16:23 |
| cjwatson | I'm being a bit hair-trigger on the risk that people might start widely using -proposed | 16:23 |
| cjwatson | Because if they do it kind of makes a lot of this work pointless | 16:23 |
| xnox | server & X where building against -proposed this cycle. Did we have any "support" issues with enabling -proposed for those devs...? (I am guessing kernel & X developers are fairly sophisticated and do not require the #ubuntu-motu style hand-holding) | 16:23 |
| cjwatson | Not really, but there was so little in -proposed at any one time that it hardly mattered; they mostly had the pocket to themselves | 16:24 |
| cjwatson | The support issue was keeping track of when things were ready to be promoted | 16:24 |
| cjwatson | And being aware that we were going to start doing auto-promotion was why we were repeatedly discouraging people from doing manual testing there | 16:25 |
| xnox | which mostly funnelled down to all of them pinging infinity =) | 16:25 |
| xnox | is Raring Ringtail a proper name, and hence capitalised. Or is it a common noun and hence should be lower-cased. | 16:39 |
| xnox | ? | 16:39 |
| cjwatson | When written in full like that, it should be in title-case as you have it | 16:42 |
| cjwatson | For just the adjective, opinions evidently vary. I tend to capitalise it when I'm using it as an abbreviation for Raring Ringtail / Ubuntu 13.04 / whatever, and lower-case when I'm referring to the technical identifier (the Launchpad series, upload targets, whatever) | 16:43 |
| cjwatson | But that's probably just me. | 16:44 |
| slangasek | I think I agree | 16:46 |
| slangasek | even though my usage tends not to be so consistent :) | 16:46 |
| cjwatson | I'm sure mine isn't unless I'm thinking about it. | 16:46 |
| xnox | I am debating weather /etc/lsb-release DISTRIB_CODENAME is human readable or machine parsable. Since I am afraid things may break if the codename is suddently capitalised. | 16:52 |
| infinity | Does someone want to give a quick review to that base-files in the queue? It's a reasonably beefy merge, so wouldn't mind a second set of eyes rather than self-accepting. | 16:52 |
| infinity | xnox: It's meant for computers, not people, IMO. If you're referring to the bug I just closed. | 16:53 |
| xnox | by the loooks of things openSUSE capitalize their codenames in lsb-release, debian doesn't. Checking fedora now. | 16:53 |
| xnox | infinity: yeah. it is about the bug you closed. | 16:53 |
| xnox | I like os-release it has a pretty and machine names. | 16:54 |
| xnox | let's see what you crafted for raring =) | 16:54 |
| infinity | xnox: raring is the same as every release previous. | 16:55 |
| slangasek | there certainly may be software that assumes the codename field is directly usable for apt and the like | 16:55 |
| cjwatson | Oh, goodness, yes, don't change the capitalisation in DISTRIB_CODENAME. | 16:56 |
| cjwatson | No excuse or reason for doing that. | 16:56 |
| infinity | Hrm, wait. This can't be about CODENAME anyway. | 16:56 |
| cjwatson | That sort of thing doesn't need to obey the normal rules of English grammar. | 16:57 |
| infinity | xnox: Which string is this? | 16:57 |
| slangasek | ah, oh right, it's about DISTRIB_DESCRIPTION | 16:57 |
| slangasek | which lowercases the codename prior to release | 16:57 |
| infinity | With an added s/\(.*// ? | 16:58 |
| slangasek | and /that/ it would be reasonable to uppercase | 16:58 |
| infinity | Cause I wouldn't be against.. Yeah. | 16:58 |
| xnox | well the os-prober fetches it, and then ubiquity parses it further and we end up in Ubiquity with a string:"You have Ubuntu quantal installed on this computer. What would you like to do?" | 16:58 |
| cjwatson | Agreed, that doesn't matter. | 16:58 |
| xnox | during development. | 16:58 |
| infinity | xnox: Right, I'm just trying to nail down precisely (raringly?) where that comes from. | 16:58 |
| infinity | xnox: If it's lsb_release -d | sed 's/\(.*//' (or so), then yeah, we could uppercase that one. | 16:59 |
| cjwatson | /usr/lib/os-probes/mounted/40lsb | 16:59 |
| cjwatson | Basically DISTRIB_DESCRIPTION | 16:59 |
| infinity | cjwatson: Minus the " (development branch)" bit, I assume. | 17:00 |
| cjwatson | I guess. I haven't followed the twisty maze. | 17:00 |
| xnox | well ubiquity strips (development branch) | 17:00 |
| xnox | but it is there. | 17:00 |
| xnox | http://paste.ubuntu.com/1297966/ | 17:00 |
| infinity | Ahh. | 17:00 |
| infinity | Check. | 17:00 |
| xnox | this is paste of raw os-prober results against some of my chroots. | 17:00 |
| infinity | If ubiquity's already post-processing it, you could tr the first character of the name too. :P | 17:00 |
| * xnox wants to remove all of the logic out of ubiquity | 17:01 | |
| xnox | so I rather Base-Files to be Capitalised =) | 17:01 |
| infinity | But I think I can see a valid argument for the bits in DISTRIB_DESCRIPTION, PRETTY_NAME, and /etc/issue* to have an uppercase R. | 17:01 |
| slangasek | xnox: ITYM BasE-FIleS | 17:02 |
| infinity | I shall reject my upload and do that now, if there are no objections. | 17:02 |
| xnox | "We’ll make something… wonderful, and call it the Raring Ringtail." and "However, for the sake of sanity, it’s not a raring ringtail raccoon, just a raring ringtail." As per http://www.markshuttleworth.com/archives/1195 | 17:02 |
| xnox | slangasek: I am not from east london. | 17:03 |
| infinity | RFC: http://paste.ubuntu.com/1297969/ | 17:05 |
| cjwatson | I have a "that looks wrong" reaction which I think is just unfamiliarity. | 17:05 |
| cjwatson | I think it would be fine. | 17:06 |
| infinity | Yeah, I think it looks wrong to Capitalize It Without The Ringtail. | 17:06 |
| xnox | I wonder how many things will break, and why is it "Ubuntu Raring" and not "Ubuntu Raring Ringtail" everywhere. | 17:06 |
| infinity | Maybe we should add the animal too. | 17:06 |
| infinity | And totally break with tradition. | 17:06 |
| xnox | =)))))) | 17:06 |
| cjwatson | I'd be a bit worried about increasing the length causing some strings to wrap and ... | 17:07 |
| infinity | xnox: Nothing should break, since those fields all change regularly anyway. | 17:07 |
| xnox | we are really raring this time around =) | 17:07 |
| cjwatson | But I suppose it's reasonable to try it now | 17:07 |
| infinity | cjwatson: Yeah, I was thinking about wrapping issues too. Especially in installers. | 17:07 |
| cjwatson | As long as we don't attempt to SRU it | 17:07 |
| infinity | What the heck, let's get all animally. | 17:07 |
| cjwatson | I'm pretty sure that at one point "Ubuntu quantal" etc. was displayed in some contexts that didn't have a lot of horizontal space. | 17:07 |
| cjwatson | Like the horizontal partition display we had at one point. | 17:08 |
| infinity | Actually, yeah. I'll change it in issue/issue.net, I won't change it in lsb/os-release. | 17:08 |
| infinity | Well. Wait. People using those already cut out the (devel release) garbage. | 17:08 |
| xnox | but then ubiquity will say: "You have Ubuntu Raring installed. What do you want to do?" | 17:08 |
| infinity | They can cut the animal too if it's really an issue. | 17:08 |
| cjwatson | I do, FWIW, think it's perfectly fine to talk about raring or Raring; it's not like it's *wrong* without Ringtail. We've been abbreviating it ever since warty. | 17:08 |
| infinity | Bah. | 17:09 |
| infinity | Screw it. I'm done having opinions. | 17:09 |
| infinity | Everyone gets ringtails. It's a new world oder. | 17:09 |
| infinity | Also, an order. | 17:09 |
| xnox | =))))) | 17:09 |
| infinity | And I just typed "Raring Ringtails"... | 17:09 |
| infinity | Stupid brain. | 17:09 |
| infinity | http://paste.ubuntu.com/1297985/ | 17:10 |
| infinity | And uploading. | 17:10 |
| cjwatson | (As in, I have a mail from 2004-04-09 talking about all of "warty", "Warty", and "Warty Warthog" essentially interchangeably.) | 17:10 |
| infinity | Yeah. Well, this feels more correct for /etc/issue* anyway. | 17:11 |
| infinity | We'll see if the world explodes due to lsb-release. | 17:11 |
| infinity | And it bloody better not be an issue for os-release, which has no consumers yet. :P | 17:11 |
| * xnox ponders what would happen if we include some UTF-8 characters as well =) | 17:12 | |
| infinity | But, I figure all lsb_release -d consumers who cared about screen space were already chopping off the last bit, so they can just chop harder. | 17:12 |
| infinity | (Or, more correctly, just keep the first two fields, which may be what some already do) | 17:12 |
| xnox | infinity: about chopping https://www.youtube.com/watch?feature=player_detailpage&v=h8FomrtvCIY#t=17s | 17:16 |
| infinity | Alright. If someone wants to give THAT base-files upload a quick once-over and accept it, that would be lovely. | 17:21 |
| * infinity wanders off to find a bit of liquid food. | 17:22 | |
| ScottK | doko: ^^^ | 17:31 |
| === Ursinha-afk is now known as Ursinha | ||
| slangasek | bdmurray, jibel, gema: does anyone know where http://reports.qa.ubuntu.com/reports/rls-mgr/rls-q-tracking-bug-tasks.html has disappeared to? | 19:11 |
| micahg | slangasek: http://reqorts.qa.ubuntu.com/reports/rls-mgr/rls-q-tracking-bug-tasks.html (same thing happened to the sponsorship page) | 19:14 |
| slangasek | "reqorts"? | 19:14 |
| slangasek | what in the world | 19:14 |
| micahg | slangasek: machine move :) | 19:14 |
| slangasek | micahg: is that going to be fixed to a more sensible name in the future? | 19:17 |
| micahg | slangasek: no idea, I just found out myself due to backscroll in one the channels | 19:18 |
| slangasek | ok, thanks | 19:18 |
| * skaet *blinks* | 19:19 | |
| skaet | yeah, an email about the location changes would have been nice. | 19:21 |
| bdmurray | slangasek: no, I don't what we should be using to get to them now | 19:24 |
| slangasek | bdmurray: see micahg's comment above, apparently there's "reqorts" now | 19:24 |
| bdmurray | slangasek: oh, I missed the q | 19:25 |
| bdmurray | wtf | 19:25 |
| skaet | I'm asking if there could be an email explaining the change/transition in locations. | 19:26 |
| Laney | slangasek: huh, I talked with IS about that earlier | 19:27 |
| Laney | ChrisS was supposed to have set up a redirect | 19:27 |
| Laney | uh, it's gone away, the sponsoring report worked earlier | 19:27 |
| Laney | speak to the vanguard ... | 19:28 |
| slangasek | Laney: a redirect from where? | 19:28 |
| Laney | from reports to reqorts | 19:28 |
| slangasek | for which subtrees? | 19:29 |
| Laney | /reports/ | 19:29 |
| slangasek | ok | 19:29 |
| Laney | anyway, it seems to have gone away | 19:29 |
| ScottK | Any objections to an Ubuntu specific debootstrap upload to make it aware of raring? | 19:30 |
| === ChanServ changed the topic of #ubuntu-release to: Ubuntu 12.10 (Quantal Quetzal) released! | Archive: Frozen | http://pad.ubuntu.com/ubuntu-release | Raring Ringtail Release Coordination. Please don't upload things during freezes where you shouldn't, or be prepared to apologise to the release team | we accept payment in cash, check or beer | melior malum quod cognoscis | ||
| === henrix is now known as henrix_ | ||
| === rsalveti_ is now known as rsalveti | ||
| cjwatson | ScottK: not really, although I was going to do it in Debian soonish. If you could upload one to raring-proposed it'd be another handy test of britney. | 22:56 |
| ScottK | OK. | 22:56 |
| cjwatson | (as long as people can restrain themselves from copying it to raring manually) | 22:56 |
| cjwatson | I don't have britney fully automated yet - will run it by hand tomorrow morning | 22:57 |
| ScottK | cjwatson: Uploaded. | 22:57 |
| cjwatson | ta | 22:57 |
| cjwatson | mostly I want to check that announcement mails come out sane | 22:57 |
| ScottK | I already added the symlink by hand locally, so I'm not rushed. | 22:57 |
| cjwatson | you might get an extra mail when it's copied - haven't worked out how/whether to suppress that yet | 22:58 |
| cjwatson | I figure people can always filter so it's not a *huge* deal | 22:58 |
| xnox | I like receiving emails upon accepts in the queue & upon copies (SRUs from lp, or sftp Debian uploads) Plus it will give a clear idea of how long the delay is or whether there are problems (Oh, there was no second email, why is it not transitioning). | 23:05 |
| cjwatson | xnox: Yes, I expect some people will feel that way and others will complain about the duplication :-) | 23:08 |
| cjwatson | Something like grep-excuses in a cron job is a better way of keeping track of transition delays in Debian | 23:09 |
| xnox | whoever complaints should start getting katie's email =) | 23:09 |
| cjwatson | But it may not work well for Ubuntu unless we make it show maintainers a bit differently | 23:09 |
| xnox | well *I* care about _my_ package transitioning, not the rest of the world ;-) | 23:10 |
| cjwatson | I expect I will have to start filtering ubuntu-archive-robot's mail shortly | 23:10 |
| xnox | heh.... =) | 23:10 |
| cjwatson | (katie itself doesn't tend to get mail) | 23:10 |
| cjwatson | (not that I'd see it if it did) | 23:10 |
| xnox | lucky her =) | 23:11 |
| cjwatson | ScottK: That was apparently to raring (release). Would you mind reuploading to raring-proposed. | 23:32 |
| cjwatson | ? | 23:32 |
| ScottK | cjwatson: Not at all (it was) | 23:32 |
| ScottK | Done | 23:33 |
| cjwatson | Ta | 23:33 |
| phillw | hi guys, any idea why I'm getting bug 986967 in quantal on alternate install? | 23:49 |
| ubot2 | Launchpad bug 986967 in unity-greeter (Ubuntu Precise) "unable to log in - hangs on 'logging in' msg" [High,Fix released] https://launchpad.net/bugs/986967 | 23:49 |
| xnox | phillw: there is no alternate install for quantal.... so what are you doing? did you mean precise? | 23:50 |
| phillw | well that sort of issue? | 23:50 |
| phillw | xnox, there is alternate for both server installs and lubuntu. | 23:50 |
| xnox | ack. | 23:50 |
| phillw | along with netboot, of course. | 23:51 |
| phillw | I do have a full set of logs, as it is on my other hard drive. So, if you guys let me know what ones you want, I'd be more than happy to furnish them. | 23:52 |
| xnox | phillw: comment on the bug or open a new one. I don't it's something #-release can solve easily. | 23:52 |
| xnox | I don't "think" (missing from above) | 23:53 |
| phillw | As it is Q bug, I guess I should open a new one. It's obviously NOT unity greeter! | 23:55 |
| phillw | the repeated error is unable to open pam_gnome_keyring.so Does that help in what I should bug it against? | 23:57 |
| phillw | in fact the line all have pam / PAM in, but I'm not knowledgeable enough to understand them :/ | 23:58 |
| xnox | duplicate pam module configured by any chance?! | 23:58 |
| phillw | xnox: give me a couple of mins and I'll paste up the auth.log - hopefully you can tell me what to bug report it against. | 23:59 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!