| === peterm-ubuntu is now known as Peter-wfh | ||
| knome | i can't seem to find the place where the information on opt-in for alphas/betas for flavors are listed. is there one? | 09:32 |
|---|---|---|
| === peterm-ubuntu is now known as Peter-wfh | ||
| xnox | infinity: do we still want armel-cross-toolchain-base considering that we no longer have libc6-dev:armel | 09:51 |
| infinity | $arch-cross-toolchain-base doesn't depend on libc6:$arch | 09:53 |
| === henrix_` is now known as henrix | ||
| infinity | xnox: If you're asking because of the britney snag, don't worry about that. Updating it is trivial, the reason I haven't is because all the cross stuff is in flux right now anyway and only builds depending on moon phase. | 09:53 |
| infinity | xnox: The argument for keeping it is mostly because of all the HOWTOs out there that tell people to install it. :P | 09:54 |
| infinity | I suppose we could install arm-linux-gnueabi-gcc as a small wrapper that calld arm-linux-gnueabihf-gcc with -mfloat-abi=soft, but that sounds vaguely sketchy. | 09:55 |
| infinity | s/calld/calls/ | 09:55 |
| xnox | ok. | 09:55 |
| infinity | Note that armhf-cross-toolchain-base is currently FTBFS too. | 09:57 |
| infinity | Once I land glibc 2.17, doko and/or I needs to fix all the cross stuff again and then stop touching it for a while. | 09:57 |
| infinity | knome: I'm not sure we have a wiki or anything that defines who's opted in. Last time, we just asked on the release list and got responses. | 09:59 |
| infinity | knome: I'm also trying to discourage flavours from participating in milestones that Ubuntu isn't, just to "try it out" and see how that goes, but it's obviously your call, not mine. | 09:59 |
| knome | infinity, sure. | 10:02 |
| knome | infinity, i just wondered if there was something i can point to | 10:02 |
| infinity | If there is, I didn't write it. But wikis being what they are, I wouldn't put it past someone else to have made such a page. :P | 10:03 |
| knome | well, i found a file-copy of the pad where that's written | 10:03 |
| infinity | I'm not sure it's meaningful information at any point except when we're actually spinning CDs, though, so the informal polling of flavour maintainers works. | 10:03 |
| knome | this was just a reference to our testers | 10:04 |
| knome | "since we aren't doing alphas per [URL], ..." | 10:04 |
| knome | just to point to some place where it's been defined | 10:04 |
| infinity | Ahh. | 10:04 |
| infinity | Well, yeah. It's up to each flavour to make that call, so if yours isn't doing alphas and you want a public/formal announcement of that, feel free to send it to your list. | 10:05 |
| infinity | And then you forever have a URL to refer to. :) | 10:05 |
| knome | yeah, i know... but i'm lazy ;) | 10:05 |
| knome | i might have done that already though, but i didn't find the mail when browsing the archives | 10:05 |
| knome | maybe i should retry | 10:05 |
| xnox | knome: well you could use the alpha1 thread on ubuntu-release mailing list. | 10:19 |
| xnox | which asked "who wants" and "edubuntu & kubuntu saying we do" and nobody else. | 10:20 |
| knome | xnox, i was looking for a complete list for all the milestones. :) | 10:21 |
| xnox | https://wiki.ubuntu.com/RaringRingtail/ReleaseSchedule on here, it is marked which milestones are opt-in (a1, a2, b1) and mandatory (final beta, rc, final) | 10:22 |
| xnox | knome: and we poll flavours as we are about to embarg on a milestone to give maximum dev time for the teams to decide whether or not they need/want a milestone. | 10:23 |
| knome | xnox, the information in uds was that flavors should decide if they opt-in for milestones within a week of uds ending. a list was gathered then, and that's what i was looking for. it's here: http://people.ubuntu.com/~alanbell/uds-r/uds-r-foundations-r-flavor-pm-mtg-latest.txt but i wondered if it was written out in a wiki or some other place | 10:24 |
| infinity | Ahh, yes, I was double-booked and couldn't attend that session. | 10:25 |
| infinity | Which annoyed me greatly. :/ | 10:25 |
| infinity | Anyhow, we could alter the release schedule to show who's participating in each milestone. Except that some of the responses from that meeting were a bit wishy-washy. :P | 10:27 |
| knome | i'm going by the information/knowledge that we're sticking with what we decided (and that's ok), and want to point our testers to the source of the information, not just say "we're not doing any alphas, btw" | 10:27 |
| xnox | knome: to be honest, so far there is no descepancy - since edubuntu is on the verge of having server product and hence participates in a2. | 10:27 |
| knome | yes... but that's not the point | 10:27 |
| knome | even if the information was incorrect, there still has been the discussion that led to xubuntu opting in to specific milestones | 10:27 |
| xnox | knome: but do take those notes with a pinch of salt, i see a lot of context missing from those notes and things that have moved on since that discussion. | 10:28 |
| knome | sure. i'm the xubuntu project lead, so i'd know if we'd change our plans | 10:28 |
| * xnox also was not in that session (double booked) | 10:28 | |
| knome | but i want to point to the process | 10:28 |
| infinity | knome: That text file is a dump of the UDS pad contents, I assume? | 10:29 |
| xnox | yeap. | 10:29 |
| knome | infinity, yup. | 10:29 |
| infinity | Right, then. Dumped it to https://blueprints.launchpad.net/ubuntu/+spec/foundations-r-flavor-pm-mtg, which is slightly less ephemeral than an etherpad. | 10:30 |
| knome | thanks! | 10:30 |
| xnox | knome: infinity: https://blueprints.launchpad.net/ubuntu/+spec/foundations-r-schedule in here there are notes of why/how ubuntu dropped freezes&milestone isos, and that in itself set up the opt-in option for flavours. | 10:33 |
| xnox | and thus in turn is basis for foundations-r-flavor-pm-mtg. | 10:33 |
| knome | i understand that background but that itself is already irrelevant for our testers, unless they want to dig deeper | 10:33 |
| xnox | true =/ | 10:35 |
| infinity | I don't think you really much need to explain the "why" to your testers, so much as just the current state of affairs. | 10:36 |
| knome | i just wanted something like "this is why we're doing milestones X, now get testing!" ;) | 10:36 |
| knome | sure. but i think it's nice to have some reference | 10:37 |
| knome | for archive purposes as well | 10:37 |
| infinity | "We're not doing milestones X, Y, and Z anymore, but it would be awesome if you'd spin up a CD every couple of weeks and report bugs, kthx". | 10:37 |
| knome | something like that. | 10:37 |
| knome | and i'll also dump a long list of things they should also test ;) | 10:37 |
| infinity | And I'm all for flavours doing impromptu "test this image now, please" mails to their testers that aren't part of the formal "milestone process". | 10:37 |
| infinity | Like, you land a huge new feature, ask people to test "any image >= 20130117" and report back. | 10:38 |
| infinity | No need for freezes and such to do that sort of thing. | 10:38 |
| knome | yes, that's exactly what i'm doing right now | 10:38 |
| knome | though we're not landing features, we're telling to download from git :P | 10:38 |
| infinity | Your users are clearly smarter than mine. | 10:39 |
| knome | i'm doing all the thinking for them... | 10:39 |
| === henrix_ is now known as henrix | ||
| === henrix_ is now known as henrix | ||
| === henrix is now known as henrix_ | ||
| === henrix_ is now known as henrix | ||
| xnox | infinity: so nagios-plugins-basic (main) got split into nagios-plugins-basic and nagios-plugins-common (universe), from the nagios-plugins src package (main) | 11:45 |
| xnox | infinity: can you please promote nagios-plugins-common into main? on the basis that it's a main package split. | 11:45 |
| xnox | or I shall still file a tiny MIR for archival / documentation purposes? | 11:46 |
| infinity | xnox: Oh, I NEWed it to main, you're seeing the britney migration bug. | 11:46 |
| xnox | infinity: ok, thanks. =) | 11:46 |
| xnox | infinity: ping - can you whack nagios-plugins-common again due to britney bug?! =))))))) | 11:46 |
| * infinity fixes dosfstools-udeb too. | 11:47 | |
| xnox | \o/ | 11:47 |
| === yofel_ is now known as yofel | ||
| === peterm-ubuntu is now known as Peter-lunch | ||
| === scott-work is now known as Guest94797 | ||
| xnox | infinity: new goffice is gtk3, yet it's rdep (gnucash) is gtk2, hence gnucash is uninstallable and cannot build against new goffice. | 12:54 |
| xnox | infinity: do you know if goffice can build a gtk2 variant as well? | 12:55 |
| === Peter-lunch is now known as Peter-wfh | ||
| xnox | infinity: or shall we just reintroduce goffice-0.80 to keep gnucash buildable?! | 12:55 |
| cjwatson | xnox: I already mailed the Debian goffice maintainer asking about that | 12:56 |
| cjwatson | No response yet | 12:56 |
| infinity | xnox: Neither, things are being ported, people are on the job, don't panic. | 12:56 |
| cjwatson | I don't think we should do anything precipitate in Ubuntu | 12:56 |
| infinity | (Though if things don't get ported eventually, yeah, a -0.80 might be an option) | 12:56 |
| xnox | cjwatson: i spoke to gnucash upstream they are working on gtk3 but it won't be finished soon. | 12:57 |
| xnox | ok. i'll ignore goffice saga. | 12:57 |
| cjwatson | I'm not necessarily saying you should ignore it, but major things like reintroducing a compat source package belong in Debian first | 12:58 |
| xnox | true. | 13:00 |
| infinity | cjwatson: ^-- There you go. | 14:15 |
| cjwatson | Ta. Next round :) | 14:16 |
| cjwatson | (Which is more completism, but people do still use netboot d-i, I expect ...) | 14:16 |
| * cjwatson respins raring server to get dosfstools-udeb into it | 14:19 | |
| infinity | cjwatson: I use netboot d-i an awful lot. | 14:36 |
| infinity | cjwatson: (And I'd imagine any large corporate users do, too...) | 14:36 |
| infinity | Though, why these hypothetical people would be using a non-LTS, I don't know. | 14:37 |
| cjwatson | pre-12.04.2, SB support | 14:38 |
| cjwatson | Not that that's easy with netboot so ... | 14:39 |
| infinity | I do sometimes think that our unwitten policy (I guess that's spelled "habit"?) of propagating all (or most) of our LTS fixes to all the interim releases is probably a whole lot of busy work for little gain. | 14:39 |
| cjwatson | Well, in this case I got an oem-priority/quantal task | 14:39 |
| cjwatson | So figured somebody actually cared | 14:39 |
| infinity | Yeahp. | 14:39 |
| cjwatson | Maybe they have that habit too, dunno | 14:39 |
| infinity | I still want to respin Q with the current SRU kernel anyway. | 14:40 |
| infinity | Just to stop bricking samsung laptops. | 14:40 |
| infinity | And I was pondering seeing if you'd be up for fixing that "uniquity removes kernel headers, oops" bug in the process. | 14:41 |
| infinity | ubiquity, too. | 14:41 |
| infinity | Typing hard. | 14:41 |
| cjwatson | Yeah, I was going to mention that actually | 14:41 |
| ogra_ | train on a nexus7 ;) | 14:41 |
| cjwatson | If you actually have time to do the point release (or near enough) work, that's the main hard part | 14:42 |
| infinity | Yeah. Well, it would be a cheater's point release, where I just cherry-pick what I want from updates. | 14:42 |
| infinity | But it still needs all the painful QA and such. | 14:42 |
| infinity | Seems worth it to stop breaking computers, though. :/ | 14:42 |
| cjwatson | Build-wise, it'd be easier to just take whatever's currently in -updates | 14:43 |
| cjwatson | If that breaks we have a problem anyway | 14:43 |
| infinity | Less concerned about it breaking, more concerned with potential size issues and other such faff. | 14:44 |
| infinity | But I guess we stopped caring about size a bit. | 14:44 |
| cjwatson | Yeah, that shouldn't be too bad in quantal | 14:44 |
| infinity | Though, the other reason to do the cherry-pick (which isn't rocket science, really) would be so we don't need a freeze. | 14:44 |
| infinity | cjwatson: My general thought was "install without pockets, enable final sources.list, apt-get install (bits we want upgraded)", ish. | 14:46 |
| infinity | cjwatson: Since all those steps already exists except the last, it's a minor tweak. | 14:47 |
| cjwatson | I guess, but be careful with install vs. live phases | 14:47 |
| infinity | Oh, true. Would have to undo and redo sources.list in between. | 14:47 |
| infinity | That does make it more painful. | 14:47 |
| cjwatson | Getting it actually right involves some juggling with live-build, since there are no arbitrary-code hooks between installing packages for the install phase and ditto for live | 14:47 |
| cjwatson | It mostly doesn't matter too much if versions differ, but if one of the new versions involves changed dependencies then you could be in trouble | 14:48 |
| infinity | Yeah, I know where that juggling happens. It's right around where I hacked in the linux-headers/apt-mark crap. | 14:48 |
| infinity | Meh. Well, I'll think about it anyway. Cherry-pick or full point release. Whichever. | 14:51 |
| infinity | But in either case, backporting that one ubiquity fix would shut up a reasonable set of bug reports. | 14:51 |
| infinity | (Well, except for all the poor saps who already installed and have no linux-generic now) | 14:52 |
| infinity | Does the release-upgrader ensure such things are in sane states? I wonder if it might be worth quirking 12.10->13.04 to check for linux-$flavour being installed and fix it if it's not. | 14:53 |
| infinity | Which will be the wrong thing to do for 0.1% of users who removed it intentionally, but the right thing for the other 99.9% | 14:54 |
| cjwatson | Not sure, but easy enough to quirk. | 14:54 |
| cjwatson | infinity: upstart in precise-proposed; I'm happy with the diff, but the .changes wasn't built with -v. However, James mentioned the same bug again, so it still has the same Launchpad-Bugs-Fixed. I think that's OK and I don't need to go back round and ask for a re-upload - do you agree? | 16:01 |
| cjwatson | (To tell you the truth I'm not absolutely sure what breaks when people forget -v; it's folk knowledge for me.) | 16:01 |
| infinity | cjwatson: The only thing that breaks without -v is sru-report, closures, and the -changes list. | 16:03 |
| infinity | Though, one or more of those may no longer be true. | 16:03 |
| cjwatson | I'm pretty sure that LP nowadays does a check on the previous ancestor version when you copy | 16:04 |
| infinity | And if the bug is re-mentioned, I'm not overly concerned. You could always grab the source and re-dpkg-genchanges -S though, if it bugs you. :P | 16:04 |
| cjwatson | for closures and -changes | 16:04 |
| cjwatson | I'm not sure about sru-report; that thing is a bit of a mystery to me | 16:04 |
| infinity | Yeah, actually, you're right. I just saw that behaviour today when I copied linux-meta-lowlatency, which I'd forgotten a -v on. | 16:04 |
| cjwatson | I'll just accept it, sounds OK | 16:04 |
| infinity | But the closures and -chanegs were fine. | 16:04 |
| infinity | So, it's probably only sru-report that barfs and, well, who cares? | 16:04 |
| cjwatson | Ancestry is sometimes a bit confused in LP, so I guess there could be corner cases there. | 16:04 |
| infinity | (In this case, who cares, since the bug is mentioned again) | 16:05 |
| infinity | I should probably sleep sometime today. | 16:06 |
| === henrix is now known as henrix_ | ||
| === henrix_ is now known as henrix | ||
| === henrix_ is now known as henrix | ||
| === henrix is now known as henrix_ | ||
| === henrix_ is now known as henrix | ||
| === henrix is now known as henrix_ | ||
| === Ursinha-afk is now known as Ursinha | ||
| === Ursinha is now known as Ursinha-afk | ||
| === Ursinha-afk is now known as Ursinha | ||
| shadeslayer | hi, could someone from the release team pass transmission from the precise and quantal queue's ? Ref bug : https://bugs.launchpad.net/ubuntu/+source/transmission/+bug/1093220 | 20:19 |
| ubot2 | Launchpad bug 1093220 in transmission (Ubuntu Quantal) "[SRU] Fix transmission-qt to open magnet links from a browser" [Undecided,Fix committed] | 20:19 |
| shadeslayer | It's been languishing in the queue for quite some time :( | 20:19 |
| slangasek | infinity: "but dpkg is never a fresh install" (bug #1093819) - it should be? debootstrap does call dpkg --unpack / dpkg --configure, and at that point the dpkg package database is empty so the maintainer script should be passed the right (empty) $2 | 20:21 |
| ubot2 | Launchpad bug 1093819 in Wubi "Wubi installed 12.10 amd64 without configuring i386" [Undecided,New] https://launchpad.net/bugs/1093819 | 20:21 |
| slangasek | shadeslayer: I'm looking at SRU processing this afternoon; but sad to say, there are some packages that have been languishing in that queue even longer | 20:22 |
| shadeslayer | :( | 20:22 |
| shadeslayer | how can I help speed this up? | 20:22 |
| slangasek | In the short term, not easily. In the long term, you could volunteer for the SRU team :) | 20:25 |
| shadeslayer | slangasek: sure, is there a wiki page saying how I can volunteer? | 20:28 |
| shadeslayer | s/saying/describing/ | 20:28 |
| slangasek | the page describing the SRU process also describes the duties: https://wiki.ubuntu.com/StableReleaseUpdates | 20:29 |
| slangasek | but it's by no means exhaustive, and we usually pair new volunteers with existing members to learn the ropes | 20:29 |
| shadeslayer | I see | 20:30 |
| slangasek | shadeslayer: if you're interested, can you drop me and cjwatson an email? | 20:30 |
| shadeslayer | I am indeed | 20:30 |
| shadeslayer | will do :) | 20:30 |
| shadeslayer | slangasek: sent | 20:36 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!