| infinity | stgraber: Where'd queuebot run off to? | 01:16 |
|---|---|---|
| skaet | slangasek, https://wiki.ubuntu.com/PrecisePangolin/ReleaseNotes/CommonInfrastructure | 01:23 |
| skaet | can you take a pass and add any other key feature changes that the foundations team has added this release? | 01:23 |
| skaet | ogasawara, ^ I've put the kernel in the CommonInfrastructure too, and pulled together the bits from the other release notes. Edit/improve as necessary | 01:25 |
| skaet | :) | 01:25 |
| infinity | skaet: I'm not sure we need to mention armhf linker changes in the release notes, given that there was no oneiric armhf release. | 01:29 |
| skaet | infinity, we do need to mention that armhf is now supported, and the default for arm ports though, this is one way. | 01:30 |
| cjwatson | skaet: upstart => James Hunt, not James Page | 01:31 |
| skaet | but if the specific linker issue isn't worth mentioning in your judgement, am fine with that. | 01:31 |
| skaet | oops | 01:31 |
| skaet | thanks cjwatson, fixed. | 01:32 |
| * micahg thought aufs was reenabled, did that not happen? | 01:34 | |
| cjwatson | It did. Bug 943119 | 01:35 |
| ubot2 | Launchpad bug 943119 in linux "aufs.ko missing from the Precise kernels" [Medium,Fix released] https://launchpad.net/bugs/943119 | 01:35 |
| cjwatson | People should still migrate though | 01:35 |
| micahg | right, but shouldn't the release notes reflect reality though :) | 01:36 |
| micahg | AUFS has been disabled, anyone needing AUFS is encouraged to migrate to overlayfs. | 01:36 |
| cjwatson | Oh I agree | 01:36 |
| cjwatson | Just saying | 01:36 |
| micahg | I agree with what you're saying as well :) | 01:36 |
| cjwatson | (Also, the above is a run-on sentence, which we should avoid) | 01:36 |
| cjwatson | But it's >2:30am here, so bed | 01:36 |
| micahg | skaet: ^^ | 01:37 |
| skaet | cjwatson, sleep well. | 01:39 |
| micahg | skaet: this should probably also be mentioned under the kernel: https://lists.ubuntu.com/archives/ubuntu-devel/2012-March/034969.html | 01:41 |
| skaet | micahg, good point. added. Will let leann wordsmith a bit more. ;) | 01:44 |
| micahg | skaet: did you see the note about aufs above as well? | 01:44 |
| skaet | yup, just deleted the AUFS has been disabled, part. | 01:44 |
| micahg | skaet: you might want to add that it will be disappear in future LTS backport kernels per https://lists.ubuntu.com/archives/ubuntu-devel/2012-March/034880.html | 01:46 |
| skaet | michag, will let ogasawara decide if we want to point out future plans, or leave it alone. Thanks for bringing it up. | 01:47 |
| skaet | ogasawara, ^ your call. | 01:48 |
| micahg | sounds good | 01:49 |
| slangasek | skaet: I'm puzzled by the overall structure of this page... this is far more technical detail than we've gone into for release notes in the past, is there guidance on who the audience is and the context in which this is going to viewed? | 02:31 |
| slangasek | skaet: if it's really supposed to serve the same function as release notes in the past, I would cut everything about gcc/python/upstart, none of which rises to the level of warranting top billing in the release notes | 02:32 |
| slangasek | (upstart logging is great, but users will discover that when debugging; until then they don't need it :) | 02:32 |
| skaet | slangasek, have broken it up to a per-product, and the kernel and foundations bits are in the common section. Thought here is to give users an overview as to what's in the release and structure it in a way we can extend for the .1, .2, etc. release. | 02:33 |
| skaet | slangasek, guidance is to give a more general feature overview for the users. If something is too detailed, strike it. | 02:34 |
| skaet | :) | 02:34 |
| skaet | I was just merging technical overview information from the prior releases as a starting point. | 02:34 |
| slangasek | right | 02:35 |
| slangasek | fwiw in the past we've scratched the technical overview info and started from scratch when doing the final release notes, because there's such a big disparity in the level of technical detail we want to give alpha/beta testers vs. users who are going to see links to these notes in the installer/upgrader | 02:36 |
| skaet | slangasek, https://bugs.launchpad.net/ubuntu/+source/update-manager/+bug/982859 - is update-manager appropriate, or should this get directed to desktop/skype? | 02:37 |
| ubot2 | Launchpad bug 982859 in update-manager "Upgrade to 12.04 breaks if skype is installed" [High,Confirmed] | 02:37 |
| slangasek | how is breaking this up by product going to work in practice? | 02:37 |
| slangasek | because there's a single release note URL that's passed in the installer... is that going to only point to the desktop bits now? | 02:37 |
| skaet | https://wiki.ubuntu.com/PrecisePangolin/ReleaseNotes/UbuntuDesktop | 02:37 |
| skaet | is the Desktop one.... | 02:37 |
| skaet | working on the server one. | 02:37 |
| skaet | want the installation requirements, instructions, etc. broken down per image. | 02:38 |
| slangasek | looking at the skype bug | 02:38 |
| skaet | then our point releases can be linked off of the pages that have LTS. | 02:38 |
| skaet | skype is priority. more on this tomorrow. ;) | 02:38 |
| slangasek | this looks like not-a-bug | 02:39 |
| slangasek | OTOH, most reports of skype causing upgrade problems look like not-a-bug to me, so let me be sure | 02:40 |
| skaet | slangasek, Ursinha is still around if you want more details. | 02:40 |
| slangasek | Ursinha: can you please file a separate bug report with upgrade logs for your skype upgrade issue? ^^ 10.04->12.04 vs 11.10->12.04 are going to need entirely separate debugging | 02:41 |
| slangasek | Ursinha: and I expect that any analysis I do on the original submitter's logs is not going to apply to your case (non-multiarch vs multiarch, etc) | 02:41 |
| Ursinha | I'll do | 02:43 |
| infinity | Oh, since queubot's being unhelpful. | 02:44 |
| infinity | slangasek: There's a compiz-plugins-extra upload in the queue that could use someone !me approving. | 02:45 |
| slangasek | Ursinha: taking a stab in the dark, though, I would guess that: 1) you installed skype from the skype.com website; 2) you selected the .deb listed as "64-bit" on the skype website; and possibly 3) you don't have the partner repository enabled | 02:45 |
| infinity | Actually, wait. When does universe freeze? | 02:45 |
| slangasek | infinity: "later" | 02:45 |
| infinity | Maybe it doesn't need approval, it's a bug fix. :P | 02:45 |
| slangasek | yeah | 02:45 |
| Ursinha | slangasek, my skype was skype:i386 | 02:45 |
| slangasek | oh, interesting | 02:45 |
| slangasek | I definitely want to see the logs then :) | 02:46 |
| Ursinha | sure, will find them | 02:46 |
| slangasek | it's also possible this was caused by another annoying instance of temporary multiarch uninstallability and that it'll be a non-issue for release... but we'd better make sure | 02:46 |
| infinity | Most M-A upgrade bugs amount to that. | 02:47 |
| infinity | Which is annoying, when trying to find the real bugs in the haystack. :/ | 02:47 |
| slangasek | well, the timing of this one is odd, because I thought everything of substance went through -proposed | 02:47 |
| slangasek | in the past 24h | 02:47 |
| slangasek | skype:amd64 Depends on skype-bin [ amd64 ] < none > ( none ) can't be satisfied! | 02:48 |
| slangasek | that's the original submitter's issue | 02:48 |
| slangasek | and is specific to 10.04->12.04 | 02:48 |
| infinity | What was the default compiler in oneiric? | 02:48 |
| slangasek | gcc-4.6 | 02:48 |
| slangasek | (.1) | 02:48 |
| infinity | Oh, kay. | 02:49 |
| infinity | Then I won't blame my gcc-4.5 upload for breaking Ursinha's upgrade. | 02:49 |
| infinity | (gcc-*-base being MA:same and all...) | 02:49 |
| slangasek | hmm | 02:49 |
| slangasek | I think we might just need to un-blacklist skype | 02:49 |
| slangasek | because new skype:amd64 wants an i386 dependency; old skype:amd64 wants ia32-libs; new ia32-libs wants an i386 dependency; old ia32-libs wants lib32v4l-0 which I may have killed with fire | 02:51 |
| slangasek | sigh; unintended consequences | 02:53 |
| Ursinha | hm, I guess one of the uninstallable packages today was lib32v4l-0... will check again | 02:53 |
| slangasek | yeah, can't hold the stack back because it needs lib32v4l-0, which Depends: libv4l-0 (= 0.6.4-1ubuntu1), and we kinda don't want to hold that back | 02:53 |
| slangasek | Ursinha: lib32v4l-0 is gone from the archive | 02:54 |
| slangasek | it went away in oneiric | 02:54 |
| slangasek | so that should not have been implicated in an oneiric->precise upgrade at all | 02:54 |
| slangasek | although, libv4l-0's shlibs haven't changed since 0.5.0 | 02:57 |
| slangasek | if we held that back on lucid upgrades, it should dtrt... there'd just be a handful of packages left to upgrade once multiarch got applied | 02:57 |
| slangasek | (handfull == skype+ia32-libs+libv4l-0) | 02:57 |
| slangasek | +wine | 02:58 |
| * infinity thinks it might be time to call it quits for the day. | 03:05 | |
| * ScottK thinks infinity must be getting old and weak. | 03:06 | |
| infinity | I won't disagree with that. | 03:07 |
| infinity | But you forgot fat. | 03:07 |
| ScottK | I haven't seen you in person in awhile. | 03:08 |
| micahg | ScottK: lua-lgi synd | 03:09 |
| micahg | *syncd | 03:09 |
| ScottK | OK. | 03:09 |
| ScottK | Did someone else accept it already? | 03:13 |
| infinity | o/ | 03:14 |
| infinity | The fat man got there first. | 03:14 |
| ScottK | OK. Good for you. | 03:14 |
| ScottK | All the armhf symlink farming didn't entirely rot your brain. | 03:14 |
| infinity | Close. | 03:15 |
| infinity | Best bug report ever: "Don't know what happened! I was browsing Launchpad through Chromium browser." | 03:18 |
| * skaet pondering where to group Netboot images.... | 03:23 | |
| infinity | In what sense? | 03:23 |
| Sarvatt | infinity: someone typed something there.. are you saying you dont get bugs with "..." as the summary? want some? :) | 03:27 |
| skaet | infinity, group them with Server or Core or ...? | 03:28 |
| skaet | own page | 03:28 |
| infinity | Sarvatt: Heh. | 03:29 |
| infinity | skaet: From the POV of release notes, I'm not sure they really need mentioning at all. | 03:29 |
| skaet | infinity, we put links into where they get downloaded from | 03:29 |
| skaet | need to find a home for that | 03:29 |
| infinity | I suppose. Using netinst images is a pretty wildly technical thing, just pointing people at the installer-$arch directories doesn't help much. | 03:31 |
| infinity | People who know they need them probably know where to get them. | 03:32 |
| Ursinha | slangasek, odd enough I can't find any evidences that skype is the culprit right now looking at the logs | 03:34 |
| slangasek | Ursinha: can you post them to a bug so I can have a look too (or post me the bug number if it's already filed)? | 03:35 |
| Ursinha | slangasek, I haven't file a bug yet, am trying to find a clue of what happened so I can look for duplicates; I've uploaded the /var/log/dist-upgrade folder here so you can look: http://people.canonical.com/~ursula/dist-upgrade.tar.bz2 | 03:38 |
| Ursinha | *filed | 03:38 |
| infinity | Oh, dangit, I forgot all the no-change rebuilds of cross-compilers. | 03:39 |
| infinity | Do dee doo... | 03:39 |
| slangasek | Ursinha: yours is bug #902603 | 03:40 |
| ubot2 | Launchpad bug 902603 in taglib "When installing Multi-Arch: same (meta-)package for two architectures, dpkg considers one arch as completely disappeared" [High,Fix released] https://launchpad.net/bugs/902603 | 03:40 |
| Ursinha | oh, it's fix released? | 03:41 |
| slangasek | apt-term.log: (Noting disappearance of libjpeg8, which has been completely replaced.) | 03:41 |
| slangasek | it's fixed /in precise/; needs backporting to oneiric in SRU | 03:41 |
| skaet | slangasek, mark it for release note? | 03:42 |
| infinity | It really should be fixed in oneiric before we release. | 03:43 |
| slangasek | skaet: even though it's intended to be published as an SRU before the release? | 03:43 |
| skaet | if SRU for oneiric goes out before release, then guess not. :) | 03:43 |
| slangasek | until it's SRUed, I wouldn't be able to write a useful release note anyway. | 03:44 |
| slangasek | "sometimes your upgrade might fail. If it does, turn it over, shake it, and try again." | 03:44 |
| skaet | lol | 03:44 |
| skaet | yeah, not ideal. | 03:45 |
| Ursinha | slangasek, do you have a safe workaround for that? I almost had to reinstall everything in order to fix the mess | 03:45 |
| * skaet --> zzz | 03:46 | |
| slangasek | Ursinha: dpkg -i /var/cache/apt/archives/dpkg_*.deb; dpkg -i /var/cache/apt/archives/libjpeg8_*.deb; apt-get -f install | 03:46 |
| Ursinha | skaet, good night :) | 03:46 |
| Ursinha | cool, adding that to release notes might do it for now | 03:47 |
| Ursinha | and to the bug (if not there) | 03:47 |
| skaet | Thanks Ursinha. :) | 03:47 |
| slangasek | Ursinha: feel free to do so... in the meantime I'm going to get that SRU going :) | 03:47 |
| Ursinha | great :) | 03:48 |
| Ursinha | done | 03:50 |
| Ursinha | and thanks sladen | 03:50 |
| Ursinha | oops | 03:50 |
| Ursinha | slangasek, even | 03:50 |
| slangasek | ok, dpkg sru uploading | 03:55 |
| infinity | Hrm, I should get added to ~ubuntu-sru so I can officially review and approve that for you. :P | 04:11 |
| Ursinha | night all | 04:34 |
| infinity | Ursinha: 'Night. | 04:36 |
| pitti | Good morning | 05:51 |
| infinity | pitti: o/ | 06:00 |
| pitti | hey infinity, how are you? | 06:00 |
| pitti | rejecting vte3, asking for reupload to -proposed | 06:01 |
| infinity | I'm alrightish. Kinda hoping I sleep tonight. :P | 06:01 |
| infinity | powerpc should recover from my compiler uploading pain in ~7h | 06:07 |
| infinity | Really wish we had that 3rd buildd already. :/ | 06:07 |
| pitti | yeah, just noticed | 06:09 |
| pitti | https://launchpad.net/ubuntu/precise/+builds?build_text=&build_state=pending | 06:09 |
| pitti | still four compilers to go | 06:09 |
| pitti | there are 3 or 4 remaining gnome 3.4.1 tarballs to do, doing now | 06:11 |
| infinity | gdc-4.6 will fail in the first 30 seconds. | 06:11 |
| infinity | And the others are all fairly quick builds, compared to gcc. | 06:11 |
| infinity | (Or the evil gcc-snapshot...) | 06:11 |
| pitti | -snapshot does the full fun of triple-bootstrapping and test suite, I guess | 06:16 |
| infinity | And builds every compiler in the suite. | 06:17 |
| infinity | That's the painful part. | 06:18 |
| pitti | queuebot is AWOL? | 06:20 |
| infinity | Yeah. | 06:20 |
| infinity | stgraber: Seems to have discovered life outside of IRC and hasn't noticed. ;) | 06:20 |
| pitti | queuebot: you'll get ice cream when you come back, promised! | 06:21 |
| infinity | Err, 's/: S/ s/' | 06:21 |
| pitti | <fake queuebot> cheese packaging is kindly waiting for a hug | 06:40 |
| pitti | s/packaging/package/ | 06:41 |
| infinity | Hahaha. | 06:46 |
| infinity | Accepted, and going to bed. :) | 06:47 |
| pitti | infinity: sleep well | 06:48 |
| === doko_ is now known as doko | ||
| cjwatson | skaet: if you're breaking the release notes up, please make sure that the web team knows about it for the table of release note URLs by product/release/architecture maintained on www.ubuntu.com, so that the installer will link to them properly | 09:15 |
| stgraber | infinity: and it's back ;) with some basic reconnection code now, hopefully that'll help | 09:19 |
| pitti | didrocks: ^ accepting, FYI | 09:58 |
| didrocks | pitti: ah thans, the queue page is still not loaded here | 09:58 |
| didrocks | pitti: tried to refresh 3 times… | 09:58 |
| didrocks | thanks* | 09:58 |
| mvo | I have a updated app-install-data upload, should that go to -proposed at this point or can/could it still go to the main repo? | 10:01 |
| pitti | mvo: can go to precise, it's arch:all | 10:18 |
| mvo | ta | 10:18 |
| pitti | mvo: http://launchpadlibrarian.net/102317906/synaptic_0.75.9_0.75.9ubuntu1.diff.gz | 10:31 |
| pitti | mvo: why does that add a 00list? | 10:31 |
| mvo | pitti: it will use a different set of patches on ubuntu and debian (well, none on debian, some on ubuntu to set eg. changelog location). this is a side-effect of that its not a sync anymore | 11:32 |
| === greyback is now known as greyback|lunch | ||
| cjwatson | Does the fix for bug 982883 require a UIFe? | 12:24 |
| ubot2 | Launchpad bug 982883 in ubiquity "Wrong color of top panel in ubiquity-dm" [High,Triaged] https://launchpad.net/bugs/982883 | 12:24 |
| cjwatson | It's a regression from 11.10 and looks fairly awful, so I'd like to get it fixed | 12:24 |
| pitti | I consider it a bug | 12:25 |
| pitti | but terminology aside, I'd also approve it as an UIFE | 12:25 |
| cjwatson | I suppose I should tell ubuntu-doc@ | 12:25 |
| cjwatson | posted to -doc and subscribed ubuntu-release for the exception request | 12:28 |
| stgraber | cjwatson: the panel was fine 2-3 weeks ago, so it's a very recent regression, don't think we need a UIFe for that | 12:29 |
| stgraber | cjwatson: I spent a day doing bugfixes on the panel during the installer sprint and it was definitely black at that point :) | 12:29 |
| cjwatson | ah, well, better safe than sorry | 12:30 |
| stgraber | cjwatson: according to bzr, panel.png was dropped last thursday (12th) | 12:32 |
| cjwatson | ha | 12:32 |
| stgraber | probably part of "Remove the need for gtk2-engines-pixbuf in the gtk2 theme, save some CD space" | 12:32 |
| cjwatson | rejected apt from oneiric-proposed per discussion on #ubuntu-devel | 12:59 |
| ScottK | kdevelop was me. | 13:09 |
| === greyback|lunch is now known as greyback | ||
| skaet | cjwatson, re: release notes, told web team about it last month, they were fine with approach. I'll be double checking the linkage as soon as they have the staging site up. | 14:19 |
| skaet | pitti, https://bugs.launchpad.net/unity/+bug/965323 seems to have a fix ready to go, and fixes a nasty regression. Any issues from your point of view (bad interactions) with other fixes already approved? | 14:20 |
| ubot2 | Launchpad bug 965323 in unity "Panel is transparent when Dash is open; no blur no average BG color" [Medium,In progress] | 14:20 |
| Cimi | pitti, here I am for a discussion | 14:23 |
| skaet | pitti, affected are netbooks in particular. | 14:24 |
| Cimi | all hardware not capable of opengl 2.x | 14:25 |
| Cimi | so all netbooks and not recent laptops | 14:25 |
| Cimi | was a regression introduced in unity 5.8.0 by a wrong commit, I basically reverted the commit so we can consider this patch safe and tested (it's the codebase of unity 11.10 and tested till 5.6.0, doesn't have any issue) | 14:27 |
| pitti | hm, I have a deja-vu about this; wasn't this recently discussed already: | 14:27 |
| pitti | ? | 14:27 |
| Cimi | pitti, not that I am aare | 14:28 |
| Cimi | *aware | 14:28 |
| Cimi | pitti, well, maybe it was, but I fixed it safely so I'd like to see if we can ship 12.04 with that fix | 14:28 |
| pitti | so, no objection from me | 14:29 |
| Cimi | ubuntu is installed on lots of netbooks, and many people don't even run upgrade, having such a broken experience at first glance it a bit embarassing :\ | 14:29 |
| Cimi | great | 14:29 |
| skaet | thanks pitti, Cimi. | 14:30 |
| Cimi | pitti, could you pls add your ack in the bug? | 14:30 |
| pitti | done | 14:32 |
| skaet | pitti, will you upload the translations before end of day? would like to get them included, and make any last minute size adjustment to the images for tomorrow, so we're ready with release candidates on Thursday. | 14:47 |
| skaet | https://wiki.ubuntu.com/PrecisePangolin/ReleaseSchedule (LanguagePackTranslationDeadline) is today. | 14:48 |
| skaet | https://docs.google.com/a/canonical.com/spreadsheet/ccc?key=0AgtV30nnv18edFRBS1NNREM5bWdYTGM3eEVwRFdyX1E#gid=0 | 14:56 |
| stgraber | skaet: preparing the ubiquity-slideshow-ubuntu upload now, should be in the queue in ~10 min (depending on how quickly LP exports the translations) | 14:58 |
| skaet | Thanks stgraber! :) | 14:58 |
| deej | I'm going to be doing a release upgrade on kapok and disabling builds on there while I'm doing it | 15:06 |
| deej | Scream now if this is a terrible idea | 15:07 |
| skaet | deej, how long out of commission for? | 15:10 |
| deej | skaet: Probably an hour or so | 15:10 |
| deej | Hopefully less, but one never knows | 15:10 |
| deej | hard -> lucid is a bit of a dance | 15:10 |
| deej | *hardy | 15:10 |
| skaet | deej, not aware of anything critical in that period. (a day would be different ;) ) no screams from me. | 15:11 |
| deej | Sweet | 15:11 |
| deej | I'll let you know when I start and finish | 15:11 |
| deej | Cardamom will be next once I've done kapok and ensured nothing went horribly awry | 15:12 |
| didrocks | pitti: skaet: so you really want that we pushes this. this code path has not been tested for few weeks. I fell unconfortable pushing that | 15:12 |
| didrocks | pitti: skaet: meaning, if it crashes on some various netbook as it did in the past, you agree to take the chance? | 15:13 |
| skaet | didrocks, screen shots from netbook look seriously wedged without it. do you have the bug numbers of the prior crashes? | 15:13 |
| didrocks | skaet: we had some crashes on gboolean vs bool usage on amd64 | 15:14 |
| didrocks | and this changes that | 15:14 |
| didrocks | you can look at debian/changelog for some crashes with it | 15:14 |
| didrocks | skaet: and we released oneiric with worst top panel effect, I'm really unsure why you want this now and not in the first SRU | 15:15 |
| didrocks | but anyway, if you feel confident, I'll push it. I just don't want to be guilty if there are side-effects | 15:15 |
| skaet | didrocks, warning appreciated. We'll regress it out if side-effects occur. | 15:16 |
| skaet | Cimi, ^ | 15:17 |
| didrocks | ok, I'm pushing the change | 15:17 |
| didrocks | merging the patch, let's see how it goes | 15:17 |
| cjwatson | grub2: tested successfully by manjo, isolated to EFI paths | 15:17 |
| cjwatson | fixes abject boot failure | 15:17 |
| Cimi | didrocks, gboolean vs bool is different | 15:17 |
| didrocks | Cimi: is it | 15:17 |
| didrocks | Cimi: doesn't seem in that case | 15:17 |
| Cimi | didrocks, nux returns bool | 15:18 |
| Cimi | didrocks, it was wrongly using FALSE | 15:18 |
| Cimi | which requires an extra compiler instruction to translate FALSE into false | 15:18 |
| Cimi | it is just saving one instruction, but the value is the same | 15:18 |
| Cimi | I can use FALSE, but it is wrong | 15:18 |
| didrocks | I still don't agree that's something that should get fixed now, it seems it didn't annoy anyone for the past 4 weeks (since 5;8) | 15:19 |
| didrocks | but if you prefer it, ok, meanwhile, we still have wrong matching application on the launcher… | 15:19 |
| didrocks | Cimi: please propose a packaging branch I'll sponsor you | 15:20 |
| Cimi | didrocks, fine | 15:20 |
| Cimi | didrocks, remember that each of us do a different job: I take care of those bugs, other take care of bamf or crashers | 15:20 |
| Cimi | didrocks, it's not my fault if nobody is proposing fixes for the launcher | 15:21 |
| didrocks | Cimi: I do but we keep having small UI changes and changes of changes for the past 4 months because "last visual change was bad" | 15:21 |
| Cimi | didrocks, unfortunately visuals are affected to regressions like other changes. | 15:22 |
| Cimi | didrocks, we need to add a strong framework for reftests | 15:22 |
| didrocks | well most of the time it's presented for "harmless visual though" :) | 15:22 |
| Cimi | but it's another story, and I will propose a talk at the ps sprint | 15:22 |
| didrocks | Cimi: ready once you propose the branch | 15:23 |
| Cimi | didrocks, I am of the opinion that we should not make a fuss on visuals | 15:23 |
| Cimi | ok | 15:23 |
| Cimi | will do | 15:23 |
| Cimi | didrocks, what shall I do, cherry pick the diff? | 15:23 |
| Cimi | didrocks, and propose with ~ubuntuX | 15:23 |
| didrocks | Cimi: create a changelog and bzr merge the commit from trunk | 15:23 |
| Cimi | ok | 15:23 |
| Cimi | cool | 15:23 |
| Cimi | didrocks, shall I wait for my branch to be merged to trunk? | 15:29 |
| Cimi | I might need an UNBLOCK :) https://code.launchpad.net/~unity-team/unity/unity.fix-965323/+merge/102278 | 15:30 |
| didrocks | Cimi: yeah, that tests passed and such | 15:30 |
| didrocks | Cimi: no, we are not in freeze, so it will get merged at next run | 15:30 |
| didrocks | let me look | 15:30 |
| didrocks | Cimi: it's needs review still | 15:30 |
| didrocks | Cimi: nobody approved the merge status itself | 15:30 |
| Cimi | didrocks, I did | 15:30 |
| didrocks | Cimi: next run is at 35, then 30 minutes for building and make check | 15:32 |
| Cimi | ok | 15:32 |
| Cimi | thx | 15:32 |
| didrocks | yw | 15:34 |
| didrocks | pitti: do you want to go with precise-proposed for that one as well? ^ | 15:34 |
| pitti | didrocks: if it's not too much trouble, yes | 15:36 |
| didrocks | Cimi: please target precise-proposed in the changelog instead of precise FYI | 15:37 |
| Cimi | ok | 15:37 |
| Cimi | thx | 15:37 |
| didrocks | hum, no Cimi? ok, doing the cherry-pick then | 16:05 |
| didrocks | [Errno 111] Connection refused ? | 16:06 |
| didrocks | am I the only one getting it? | 16:07 |
| didrocks | ah, fine now | 16:08 |
| skaet | doko, I've rejected gcc 4.6, neither bugs listed appears to be release critical, feel free to educate me if I'm overlooking something. | 16:11 |
| didrocks | skaet: pitti: unity uploaded ^ | 16:14 |
| skaet | didrocks, waiting on diff. thanks. | 16:14 |
| pitti | skaet: apport/kerneloops uploaded now | 16:16 |
| skaet | thanks pitti | 16:16 |
| skaet | pitti, can you review the unity upload? | 16:16 |
| pitti | sure | 16:17 |
| pitti | skaet: I think we should queue at least apport for a while, and upload it at the last minute only | 16:18 |
| pitti | especially while we are still getting new unity releases, etc. | 16:18 |
| pitti | we don't want to miss crashes from those | 16:18 |
| skaet | pitti, fair enough, will mark it as such on the pad | 16:18 |
| skaet | oh, speaking of which... | 16:18 |
| pitti | kerneloops is probalby fine, we won't get a newer kernel now | 16:18 |
| pitti | yeah, I think we need to fix those pads by UDS | 16:18 |
| skaet | given our lovely timeout behaviours | 16:19 |
| pitti | they didn't use to be so unstable | 16:19 |
| pitti | and we are so going to need them for UDS | 16:19 |
| skaet | do folks want me to switch to tracking on a WIKI instead | 16:19 |
| skaet | at UDS, we usually open and close, rather than come back to periodically, so probably won't be such an issue for there. | 16:19 |
| pitti | skaet: TBH, I'd rather reconnect every once in a while than always having to do the wiki overhead, but I don't have a strong opinion | 16:19 |
| skaet | slangasek, cjwatson, ScottK, infinity, (and other release team members who are using it ;) ) any strong preferences? | 16:20 |
| skaet | on pad vs. wiki? | 16:20 |
| ScottK | I'd prefer Gobby. | 16:20 |
| Riddell | what's the downside of the pad? | 16:20 |
| cjwatson | the pad is treacherous: it looks like it's up to date but half the time it fails | 16:21 |
| cjwatson | I find it completely awful in nearly every way | 16:21 |
| ScottK | Have to reconnect all the time and can't tell if what you have is up to date. | 16:21 |
| Riddell | hmm I've never noticed that with etherpad, maybe notes.kde.org is more reliable :) | 16:21 |
| ScottK | With Gobby you know if you're connected or not and there's not all the overhead of the wiki. | 16:21 |
| ScottK | Riddell: I don't think it requires relogin like the Ubuntu one does. | 16:21 |
| Riddell | Google docs is another option | 16:21 |
| * infinity goes bouncing builds that failed due to ftpmaster being rebooted. :/ | 16:21 | |
| Riddell | ScottK: right there's no login | 16:22 |
| cjwatson | I don't really care whether it's dynamic or you have to reload | 16:22 |
| cjwatson | half way in between is the worst of both worlds | 16:22 |
| skaet | ScottK, Gobby sounds interesting indeed. Is there an instance set up somewhere we can use? | 16:22 |
| cjwatson | gobby.ubuntu.com | 16:22 |
| ScottK | Recall, the Ubuntu one is run by the same people that decided a pastebin that requires a login to download text would be a good idea. | 16:22 |
| cjwatson | ScottK: which to be fair was due to widespread abuse | 16:23 |
| skaet | thanks cjwatson, google search didn't show it. :) | 16:23 |
| cjwatson | (AIUI) | 16:23 |
| ScottK | Dunno. Other pastebins seem to manage without it. | 16:23 |
| pitti | Riddell: right, and the pad didn't use to do that either | 16:23 |
| pitti | seems like a recent regression | 16:23 |
| pitti | in pad.u.c., not in etherpad in general I mean | 16:23 |
| cjwatson | other pastebins expire much more aggressively, which seems like a different tradeoff | 16:23 |
| Riddell | skaet: use notes.kde.org! | 16:24 |
| cjwatson | also pastebin.com is notorious for hosting some fairly malevolent stuff that I'm not surprised ubuntu.com doesn't want to host | 16:24 |
| ScottK | gobby.ubuntu.com isn't around anymore. | 16:24 |
| cjwatson | oh, ok | 16:24 |
| skaet | yeah, was just there trying.... :( | 16:24 |
| Laney | are other etherpad instances as bad? titanpad / pad.ubuntu-uk.rg | 16:25 |
| Laney | org* | 16:25 |
| skaet | Laney, pad.ubuntu-uk.org had a nasty habbit of timeing out on me, and not letting me access it at the end of my day.... just when I wanted to do some updates. | 16:26 |
| ScottK | I can probably provide a gobby server. Give me a minute. | 16:26 |
| doko | skaet, slangasek: now please could you coordinate your actions? | 16:28 |
| doko | <doko> slangasek, infinity: now that gcc-4.6 is in precise, I assume it is ok to upload the two linaro regressions fixes to precise-proposed? | 16:29 |
| doko | <slangasek> doko: should be, yes | 16:29 |
| infinity | Doesn't Daviey have an etherpad that doesn't require login? | 16:29 |
| infinity | I'd prefer not to have to run gobby just to do this. | 16:29 |
| infinity | Ahh, yes pad.ubuntu-uk.rg. Laney already mentioned it. | 16:29 |
| Laney | We should get a Twitter account :P | 16:29 |
| infinity | doko: I'll just accept it from rejected. | 16:30 |
| slangasek | doko: if you want the release team to pre-coordinate, get the release team to comment on the bug instead of just on IRC :) | 16:30 |
| skaet | infinity, would like some discussion first. | 16:30 |
| slangasek | infinity: they should only be accepted as candidates for an SRU | 16:30 |
| ScottK | skaet: mailout02.controlledmail.com port 6522 for Gobby. I'll invent and easier hostname in a minute. | 16:30 |
| infinity | skaet: The bugs should be fixed. Neither is RC, as you note, but this is being staged for -updates. | 16:30 |
| slangasek | which means a) the SRU team should be who accepts it, not the release team, b) it should be documented on the pad (or whatever replaces the pad) | 16:31 |
| slangasek | documented that it's not for -release | 16:31 |
| doko | thanks | 16:31 |
| infinity | slangasek: Oh, fair point on the SRU team. But you're on it. :P | 16:31 |
| skaet | slangasek, infinity - please note on the pad its purpose so we don't loose track. | 16:31 |
| infinity | slangasek: And you already implied it was okay from your POV. | 16:31 |
| slangasek | infinity: yep | 16:32 |
| * infinity lets vorlon deal with it. | 16:32 | |
| skaet | slangasek, they python patch there too, same story? or release critical? | 16:32 |
| slangasek | skaet: that was discussed on #ubuntu-devel, I've been on the phone though so haven't followed the thread just yet - ScottK has commented though | 16:33 |
| ScottK | It's not release critical, but doko would prefer it in. I understand why he prefers it and since we're going via proposed, we can't break the archive like we did last time we tried it. | 16:34 |
| doko | skaet, I don't care, as long as it get's into 12.04.01 | 16:35 |
| infinity | The only thing that breaks is if all arches don't build together. | 16:35 |
| infinity | We can fix this. | 16:35 |
| infinity | Though it means me offlining a PPC buildd to make it happen. | 16:35 |
| skaet | ScottK, is there a compelling reason we can't just get it in as an SRU at this point? | 16:35 |
| ScottK | Ask doko | 16:36 |
| skaet | doko, would like more testing and ease it in as SRU if possible. 10.04.1 should be ok. | 16:36 |
| doko | sure, we can do this. but then again, we'll have the parallel build issue, and that with hundreds of packages in sync | 16:37 |
| * ScottK hands skaet at 12. | 16:37 | |
| doko | away now until midnight | 16:38 |
| infinity | There's nothing (afaict) dangerous about the change, the danger is all in the build. | 16:38 |
| * skaet isn't seeing a good option here. | 16:38 | |
| infinity | And we should have fixed that instead of reverting and forgetting about it, IMO. | 16:38 |
| infinity | But oh well. | 16:38 |
| skaet | infinity, can we do this in proposed, after the current set clears out? | 16:40 |
| ScottK | skaet: gobby.kitterman.com exists now if you want to use it. | 16:40 |
| ScottK | I copied the current pad over if you want to look and see. | 16:40 |
| infinity | skaet: We can do it any time, but let me block off a PPC buildd for it. | 16:40 |
| infinity | skaet: It doesn't break builds while it's building, what breaks builds is if one arch lags and they skew. | 16:41 |
| skaet | Thanks ScottK. :) Lets try it out, and see if we can reduce the coordination frustration factor. | 16:41 |
| infinity | skaet: So, we accept at :04 (ie: right after a publisher run starts), and make sure all 5 arches build in the same 30 minute window, done. | 16:41 |
| skaet | ScottK, hmm...The server at gobby.kitterman.com is taking too long to respond. | 16:42 |
| infinity | I'll have a PPC buildd for us to steal in ~23 minutes. | 16:42 |
| ScottK | Odd | 16:42 |
| infinity | So, we could do the python-defaults accept then. | 16:43 |
| skaet | infinity, go ahead and accept. If you think we can pull this off. | 16:43 |
| ScottK | skaet: What port number are you using? Should be 6522. | 16:44 |
| infinity | skaet: I will accept when we're ready, then. | 16:44 |
| * infinity goes back to fixing *&$! linker issues for now. | 16:44 | |
| skaet | ScottK, was just entering it as path http://gobby.kitterman.com | 16:44 |
| ScottK | skaet: Gobby needs you to use the gobby client. You have to install the package and use that. | 16:45 |
| ScottK | It's not a web service. | 16:45 |
| skaet | ScottK, sorry, didn't realize that. | 16:46 |
| ScottK | Sorry I didn't mention it. Since we used to use it for UDS, I assumed everyone knew. | 16:46 |
| * skaet had forgot | 16:46 | |
| skaet | ScottK, still seeing connection timed out from inside the Gobby client. | 16:51 |
| skaet | probably user error still on my part. | 16:51 |
| skaet | anyone else able to access? | 16:51 |
| ScottK | What version do you have? | 16:52 |
| skaet | Gobby 0.4.93 on this system | 16:53 |
| ScottK | Looks like you installed gobby-infinote (which is too new). You need just plain gobby. | 16:54 |
| ScottK | Should be 0.4.12-2ubuntu1. | 16:54 |
| infinity | Works for me. | 16:56 |
| ScottK | And I see skaet made it. | 16:58 |
| skaet | yup. had wrong version of the client | 16:58 |
| ScottK | The server side for the newer version isn't packaged, AFAICT. | 16:59 |
| skaet | is there a history mechanism with this? | 16:59 |
| skaet | so we can see what's changing over time? | 16:59 |
| infinity | Nope. | 17:00 |
| ScottK | But, if you're connected and can see the document, you can be sure you're seeing the latest state. | 17:00 |
| skaet | Hmm... history is useful. If we could agree that things don't get deleted until the 1600 rendezvous time, it could be made to work (ie. snapshot off). But that might be a bit more complicated than folks want. | 17:06 |
| skaet | slangasek, cjwatson, pitti, Laney, Riddell - that reasonable ^ or just stick with pad? | 17:06 |
| slangasek | I'm not thrilled with gobby as a solution for this | 17:07 |
| slangasek | what was the problem with using a wiki page? | 17:08 |
| cjwatson | Either gobby or wiki is fine with me | 17:08 |
| skaet | slangasek, overhead of waiting for it and refreshing. | 17:08 |
| skaet | pitti's comments ^ earlier. | 17:09 |
| cjwatson | which is strictly less than the overhead of reauthing to the pad | 17:09 |
| cjwatson | certainly for me since it means I have to fish out two-factor-auth | 17:09 |
| slangasek | heh | 17:09 |
| skaet | yuck | 17:09 |
| slangasek | I would still prefer the wiki as a solution, since it doesn't require me having to remember to launch another client | 17:10 |
| slangasek | but if the consensus is for gobby, I'll cope | 17:10 |
| infinity | Yeah, I'm not wildly fond of gobby as a solution. | 17:10 |
| infinity | A stable (and not authed) pad would be fine too. | 17:10 |
| slangasek | the pad is javascript-heavy and annoys me (and my CPU) for that reason alone | 17:11 |
| cjwatson | GrueMaster just noticed that the linux-ti-omap4 udebs don't include ext2 despite it being modular in that kernel configuration, so effectively you can't do anything sensible with ext2 filesystems without horrible confusiong | 17:11 |
| cjwatson | -g | 17:11 |
| slangasek | hmm | 17:12 |
| cjwatson | He's filing a bug, but thoughts on this being RC? I'm not terribly happy about releasing that way | 17:12 |
| slangasek | seems RC to me | 17:13 |
| skaet | cjwatson, we don't have much arm testing yet, and if its pretty much unusable without, yeah, possible RC. | 17:13 |
| skaet | GrueMaster, thanks for finding. bug number please when you've got it filed. | 17:16 |
| infinity | ARM is remarkably close to unusable and untestable until I fix initramfs-tools and d-i too. :P | 17:17 |
| infinity | (Working on that right now. | 17:17 |
| infinity | ) | 17:17 |
| cjwatson | so that needs linux-ti-omap4 upload (only affects arm) plus debian-installer upload when that's done (affects all arches) | 17:17 |
| slangasek | "pretty much unusable" is an overstatement; it's only ext2 (not ext3 or ext4) that's affected | 17:17 |
| GrueMaster | skaet: cjwatson: bug 984180 | 17:17 |
| slangasek | what exactly is the impact? | 17:17 |
| ubot2 | Launchpad bug 984180 in linux-ti-omap4 "ext2 module missing from fs-core-modules udeb." [High,New] https://launchpad.net/bugs/984180 | 17:17 |
| slangasek | since we need FAT for the bootloader partition, not ext2 | 17:18 |
| GrueMaster | Verifying that it does/doesn't affect armadaxp as well. | 17:18 |
| cjwatson | GrueMaster found it while trying to create an ext2 /boot | 17:18 |
| GrueMaster | Actually, doing a manual netboot install with "Guided - Use entire drive". | 17:19 |
| slangasek | right | 17:19 |
| infinity | ^--- Doing co-ordinated build of python-defaults. | 17:19 |
| slangasek | doesn't rise to the level of "pretty much unusable", but is something that's very easy to fix | 17:19 |
| cjwatson | Ah yes, the default recipe uses ext2 for /boot | 17:19 |
| cjwatson | We could change the recipe, but honestly, I'd rather see the kernel packaging fixed | 17:20 |
| skaet | infinity, ack. | 17:20 |
| slangasek | ext2 for boot is still sensible. We don't need journals. | 17:20 |
| cjwatson | Wow, gobby now makes the launcher pop up a wobbly icon whenever somebody joins or leaves. | 17:24 |
| infinity | And python-defaults all built. | 17:25 |
| infinity | cjwatson: Yeah, that seems like a really silly use of urgent window hints. / | 17:25 |
| infinity | :/ | 17:25 |
| GrueMaster | My bad on the armadaxp. I had thought they had seen it as well, due to the firestorm of issues this morning. | 17:26 |
| cjwatson | Oh, could somebody review the UIFe in bug 982883 and ack/nack it? ubuntu-doc@ seems fine with it. | 17:29 |
| ubot2 | Launchpad bug 982883 in ubiquity "[UIFe] Wrong color of top panel in ubiquity-dm" [High,Confirmed] https://launchpad.net/bugs/982883 | 17:29 |
| cjwatson | (stgraber has checked the concern Dylan raised there.) | 17:29 |
| slangasek | so which is the authoritative page now? Gobby or etherpad? | 17:30 |
| * ScottK looks at skaet. | 17:30 | |
| stgraber | cjwatson: done | 17:31 |
| cjwatson | thanks | 17:31 |
| * ScottK wonders if the ubuntu-docs upload should be allowed in since it by definition affects documentation. | 17:31 | |
| cjwatson | I'll get that uploaded later, want to check bug 946663 first | 17:32 |
| ScottK | ;-) | 17:32 |
| ubot2 | Launchpad bug 946663 in ubiquity "Installer stuck at "Removing conflicting operating system files..."" [High,Triaged] https://launchpad.net/bugs/946663 | 17:32 |
| skaet | slangasek, based on your comments and cjwatson's I was setting up a WIKI, will point the pad to it. Need the history feature, and timeout feature on pad is causing too many problems. | 17:32 |
| cjwatson | (dinner now) | 17:32 |
| slangasek | ok | 17:32 |
| ScottK | skaet: Should I shut down the Gobby then to avoid confusion? | 17:32 |
| skaet | ScottK, yes. Thank you for setting it up to let us try. | 17:32 |
| ScottK | OK. | 17:33 |
| ScottK | It's gone. | 17:35 |
| skaet | slangasek, cjwatson, ScottK, pitti, Riddell, Laney, infinity, https://wiki.ubuntu.com/PrecisePangolin/FrozenArchiveStatus is up. Have redirected the pad to it. | 17:40 |
| pitti | skaet: ack, thanks | 17:41 |
| slangasek | ScottK, doko, infinity: are we thinking python-defaults for -release then? | 17:45 |
| slangasek | with the PEP394 fix | 17:45 |
| * ScottK is not thinking about it. | 17:45 | |
| ScottK | It's clearly nothing RC about the changes (also nothing SRU worthy), but if someone wants them in, I don't object. | 17:46 |
| infinity | slangasek: I think a few of us should test upgrades with -proposed on !i386 and make sure nothing went goofy before we discuss it. :P | 17:46 |
| slangasek | I'm asking whether, in principle, we're considering it for -release | 17:46 |
| slangasek | if *not*, I was going to mark it on the pad | 17:47 |
| infinity | I think that was the kinda sorta consensus that led to me doing the build. | 17:47 |
| slangasek | I didn't think the multiarch stuff needed to be .0; didn't know if folks had a different feeling on the python2 stuff | 17:47 |
| slangasek | ok | 17:47 |
| slangasek | pitti: ^^ accepting the sync | 17:50 |
| pitti | thanks | 17:50 |
| infinity | That initramfs-tools is more armhf linker fallout. | 17:51 |
| ogra_ | yeah, why would it be initramfs-tools, it didnt change | 17:52 |
| infinity | http://paste.ubuntu.com/934301/ <-- Diff for the impatient. | 17:52 |
| * pitti waves good night | 17:53 | |
| micahg | quick question, I forgot a bug in the changelog for the thunderbird stable release migration in natty, but the packages are already built (there are 2 other packages with it with the bug number), do you want me to respin (multi-hour builds) or can we copy them? | 17:56 |
| infinity | micahg: I'm sure people can live without the bug ref. | 17:57 |
| micahg | ScottK: ^^ | 17:57 |
| ScottK | Thanks. | 17:57 |
| infinity | micahg: You can go all revisionist history and fix the old changelog entry in the next upload. :P | 17:58 |
| micahg | infinity: indeed :) | 17:58 |
| infinity | (And obviously close the bug task by hand this time around) | 17:58 |
| infinity | Can someone review and (hopefully) accept that initramfs-tools upload? It's blocks some testers from doing testy things. | 17:59 |
| infinity | s/blocks/blocking/ | 17:59 |
| ogra_ | infinity, it looks sane to me from your paste | 17:59 |
| infinity | Thank god my shell is better than my English. | 18:00 |
| ogra_ | shouldnt it also cover arlem though ? | 18:00 |
| ogra_ | err | 18:00 |
| ogra_ | armel | 18:00 |
| ogra_ | .oO(how did i mess that up) | 18:00 |
| infinity | ogra_: We didn't change the linker on armel. | 18:00 |
| ogra_ | ah, k | 18:00 |
| ogra_ | well, i'd say go for it and upload | 18:00 |
| infinity | It's uploaded, I'm being a good boy and waiting for $another_archive_admin to accept it. | 18:01 |
| ogra_ | i have forwarded it to two guys in #ac100 that had the issue but havent heard back yet ... with luck we'll get some testing even before it is published | 18:01 |
| infinity | ogra_: Patching mkinitramfs and running "update-initramfs -u" should fix them up. But how they boot in the first place is another question. :/ | 18:02 |
| infinity | ogra_: I guess if their recovery is sane, they can boot recovery and chroot in. | 18:02 |
| ogra_ | they both have sosboot installed | 18:02 |
| infinity | I tihnk I might have hosed recovery on my ac100... | 18:03 |
| ogra_ | (took me half my sunday to help them with that) | 18:03 |
| ogra_ | we should hack up the ac100-tarball-installer to just blantly dump sosboot.img into the recovery partition :) | 18:04 |
| infinity | As for d-i (which will suffer exactly the same problem), it won't break until it's rebuilt, so I'll stage the change in bzr until we need an upload for another reason (which looks like it'll be an omap4 kernel bump). | 18:04 |
| bdmurray | I'm pretty sure I have an upload of update-manager in oneiric-proposed that needs approval which affects upgrades from O to P. | 18:08 |
| * infinity lunches for a bit before hacking d-i's Makefile. | 18:18 | |
| infinity | slangasek: Would love a review/accept of initramfs-tools when you get a chance. It's tested locally to DTRT. | 18:18 |
| ScottK | pitti: Why are we reintroduing postresql-8.4 for precise? | 18:19 |
| ScottK | ...introducing... | 18:19 |
| infinity | slangasek: If there's concern over "what if those things are symlinks" or similar, keep in mind that they got there via copy_exec, which does cp -pL | 18:19 |
| infinity | ScottK: To be able to upgrade databases. | 18:19 |
| ScottK | OK. Makes sense. | 18:19 |
| infinity | ScottK: Need the tools from 8.4 to dump, so 9.1 can reload. | 18:20 |
| deej | skaet and any others who may be concerned by it, I wanted to make sure it was clear I was taking kapok/cardamom from hardy to lucid and make sure everyone was okay with doing that this close to release | 18:20 |
| skaet | infinity, slangasek, ScottK ^ any issues on holding off? | 18:21 |
| ScottK | On? | 18:21 |
| infinity | deej: Was that my livefs builder ticket? | 18:21 |
| deej | infinity: Why yes! | 18:21 |
| skaet | s/on/to indicate we should/ | 18:21 |
| slangasek | skaet: for which? the builder upgrade? | 18:22 |
| skaet | slangasek, builder upgrade | 18:22 |
| infinity | deej: We might be getting too late to take advantage of that, though I'd really like to. | 18:22 |
| slangasek | skaet: I think we should get it done | 18:22 |
| infinity | Kay, let's do it, then. | 18:22 |
| infinity | slangasek: Does this mean I get to switch wubi to ext4 too? :P | 18:22 |
| slangasek | having the builder env closer to what everyone's using for development can only benefit us | 18:22 |
| skaet | deej, thanks for letting us know. | 18:23 |
| slangasek | infinity: FFe bug and talk to ev? | 18:23 |
| deej | I have been told there's no pressure but that I shouldn't fuck it up | 18:23 |
| deej | So | 18:23 |
| deej | You know | 18:23 |
| deej | I'm sure it'll be fiiiiiiiiiiiiiiiiiine | 18:23 |
| skaet | :) | 18:23 |
| infinity | slangasek: ev and I already confirmed wubi will DTRT, I just need to un-revert the livecd-rootfs and cdimage changes I made earlier. | 18:23 |
| slangasek | infinity: "already" in the recent past? :) | 18:23 |
| slangasek | i.e., is he happy for this change to be made 2 weeks before release? | 18:23 |
| infinity | slangasek: Oh, yeah, we haven't discussed doing it 1.5 weeks before release, no. I'll re-discuss after lunch. ;) | 18:24 |
| slangasek | ok ;) | 18:24 |
| infinity | But, IMO, there's value in having wubi installs using the same default FS, and exercising the same codepaths. | 18:24 |
| infinity | Since it's the only ext3 consumer right now. | 18:24 |
| slangasek | yes, I agree | 18:26 |
| deej | infinity: Sooooo, quick question, the ticket (51116) mentions i386 builders, but kapok is x86_64, do you care/does it matter? | 18:33 |
| infinity | deej: The ticket says "x86". | 18:45 |
| infinity | deej: One is amd64, the other is i386. | 18:45 |
| deej | infinity: So it does, apologies, I thought I'd read i386 the first time through | 18:46 |
| deej | Right on | 18:46 |
| pitti | ScottK: see bug 905454, I left an explanation there | 18:46 |
| ubot2 | Launchpad bug 905454 in postgresql-8.4 "'postgresql-plperl-8.4' is marked for removal but it is in the removal blacklist" [High,Fix released] https://launchpad.net/bugs/905454 | 18:46 |
| infinity | deej: Heh, I had to go check to make sure I wasn't lying. ;) | 18:47 |
| stgraber | infinity: looking at initramfs-tools, isn't it possible for someone to have lib/arm-linux-gnueabihf/ld-linux.so.3 in the initramfs but not /lib/ld-linux-armhf.so.3 outside of it? | 18:52 |
| cjwatson | infinity: would it make sense for a d-i upload to wait until linux-ti-omap4 is in and built? | 18:52 |
| stgraber | infinity: if initramfs-tools gets upgraded before eglibc | 18:53 |
| infinity | cjwatson: Yeah, d-i won't break until it's rebuilt anyway. | 18:54 |
| infinity | stgraber: Oh, perhaps it needs to depend on the latest eglibc, nice catch. | 18:54 |
| deej | Alright, the upgrade is running on kapok and I've locked out the buildd user for the time being | 18:55 |
| deej | Lest anything get started mid-upgrade | 18:55 |
| infinity | cjwatson: So, I'll figure out how to fix it, and stage it in bzr for the next rebuild. | 18:55 |
| infinity | stgraber: Wait, no, it'll already have that dep. | 18:56 |
| ev | could someone please reject that apport upload | 18:56 |
| infinity | stgraber: initramfs-tools (all) depends initramfs-tools-bin (any) depends libc6 (>= good_version) | 18:56 |
| ev | I definitely sent it to the wrong place :) | 18:57 |
| infinity | ev: Gone. | 18:57 |
| ev | thanks | 18:57 |
| ev | and thank goodness for frozen archives | 18:57 |
| infinity | stgraber: The libc6 shlibs take care of that. | 18:57 |
| infinity | ev: Since you're here... | 18:58 |
| ev | wuh oh | 18:58 |
| infinity | ev: deej is upgrading cardamon and kapok to lucid, which means we can finally switch wubi to ext4. Are you comfy with me un-reverting my previous changes and making that happen? | 18:58 |
| ev | absolutely | 18:58 |
| infinity | \o/ | 18:58 |
| ev | mostly because on your head be it :-P | 18:58 |
| slangasek | heh | 18:58 |
| infinity | Hah. | 18:58 |
| ev | but equally because it looks sensible | 18:59 |
| ev | and as we already discussed, it should be fine | 18:59 |
| ev | right, gone | 18:59 |
| stgraber | infinity: oh, good. Then feel free to accept, that's the only potential issue I spoted. | 18:59 |
| infinity | stgraber: Danke. | 19:00 |
| slangasek | infinity: how do any shlibs take care of this? | 19:00 |
| infinity | stgraber: (And I totally missed that implication, so thanks for making me trace it through to discover it was a non-issue) ;) | 19:00 |
| slangasek | oh | 19:00 |
| slangasek | n/m, read scrollback | 19:00 |
| slangasek | infinity: why is it not sufficient to test for [ -e "${DESTDIR}/lib/ld-linux-armhf.so.3" ]? | 19:01 |
| slangasek | likewise, why do you have to remove that and recreate it? | 19:01 |
| infinity | slangasek: Oh sure, ask questions after I accept. | 19:02 |
| slangasek | well you're a little quick on the trigger :P | 19:02 |
| infinity | slangasek: stgraber told me to! | 19:02 |
| slangasek | who ya gonna listen to! | 19:02 |
| slangasek | anyway, accepted or not, I'd like to understand better what the actual issue is that it's fixing | 19:03 |
| infinity | slangasek: If I think it through a bit more, perhaps you're right, that /lib/ld-linux-armhf.so.3 will always be there on new initrds. I'd have to look more closely at the library reduction logic. | 19:03 |
| slangasek | ok | 19:03 |
| slangasek | then I think the check there is overbroad but not dangerous; I just wanted to make sure it wasn't needed for some other scenario I hadn't understood yet | 19:04 |
| infinity | slangasek: The issue is fairly obvious (binaries wanting two linkers, but only one present), the fix might be a bit carpet-bombish, cause I was more interested in having it work than having it be elegant. | 19:04 |
| infinity | slangasek: But yeah, you might be right that in a two-linker scenario, it'll always get reduced to only /lib/ld-linux-armhf.so.3, and I just need to link that. | 19:05 |
| infinity | (This carpet bomb approach works for now, though) | 19:05 |
| slangasek | yep | 19:05 |
| ScottK | pitti: Thanks. Makes complete sense. | 19:06 |
| infinity | slangasek: I think I was thinking of a case where something actually checks the ELF headers for the PI, where things might end up feeling a bit non-deterministic, depending on the binaries included, and in what order. | 19:07 |
| slangasek | fair enough | 19:07 |
| infinity | slangasek: But copy_exec is dumber than that, it just checks ldd output, and on a two-linker system, ldd says "/lib/triplet/ld-linux.so.3 => /lib/ld-linux-armhf.so.3", which should always reduce to the new linker. | 19:08 |
| * slangasek nods | 19:08 | |
| slangasek | s/dumber/saner/ :) | 19:08 |
| infinity | slangasek: d-i/mklibs, on the other hand, try to be more clever, so I'll stick to the carpet bomb there to avoid an aneurysm. :P | 19:08 |
| slangasek | ack | 19:08 |
| ogasawara | we received a fix for bug 984180, is it okay to upload linux-ti-omap4 to precise-proposed? | 19:09 |
| ubot2 | Launchpad bug 984180 in linux-ti-omap4 "ext2 module missing from fs-core-modules udeb." [High,Fix committed] https://launchpad.net/bugs/984180 | 19:09 |
| infinity | ogasawara: Pretty please, mit sugar on top. | 19:10 |
| ogasawara | infinity: thanks, uploaded | 19:10 |
| * skaet --> lunch, biab | 19:11 | |
| infinity | Oh, classy. The one time I use gobby in the last 3 years, and it crashes on exit. | 19:13 |
| infinity | Dear apport, tell me all about it. | 19:13 |
| pitti | ScottK: I don't particularly like it, but it's IMHO much better than causing data loss and frustration for upgraders | 19:15 |
| infinity | pitti: Do they then end up with two versions of postgres installed? | 19:16 |
| ScottK | Agreed. | 19:18 |
| * infinity wonders if https://bugs.launchpad.net/ubuntu/+source/gnutls26/+bug/972208 really is a GnuTLS bug, or just gobby being gobby. | 19:19 | |
| slangasek | reviewing that kernel | 19:19 |
| ubot2 | Launchpad bug 972208 in gnutls26 "gobby crashed with SIGABRT in __libc_message()" [Undecided,Confirmed] | 19:19 |
| ScottK | There is also Bug 984206 that I filed today. | 19:21 |
| ubot2 | Launchpad bug 984206 in gobby "gobby crashed with SIGSEGV in gtk_rc_style_finalize()" [Medium,New] https://launchpad.net/bugs/984206 | 19:21 |
| ScottK | Actually that's a different one. | 19:21 |
| ScottK | Nevermind. | 19:21 |
| === scott-work_ is now known as scott-work | ||
| cjwatson | linux-ti-omap4 looks good to me; accepted | 19:33 |
| stgraber | cjwatson: ubiquity diff looks good | 19:42 |
| slangasek | accepting update-manager | 19:55 |
| pitti | infinity: yes, inevitably; that's how it has worked for the past 10 years or so | 19:59 |
| pitti | infinity: there's a debconf note and docs how to do the upgrade, as there is really no solid way to do it in-place during dist-upgrade | 19:59 |
| * pitti -> really off for the night now | 19:59 | |
| deej | infinity: kapok is back up if you guys want to give it a once over before I start in on cardamom | 20:09 |
| infinity | deej: I'll poke it in a sec, I'm multitasking a bit too much right now. :) | 20:11 |
| deej | Right on, no hurry | 20:11 |
| slangasek | did these comments about apport/kerneloops on the wiki get added to the wrong section? | 20:14 |
| slangasek | I don't see either of these packages in -proposed, but they're in unaccepted for -release | 20:15 |
| slangasek | skaet: ^^ looks like this is your edit? | 20:15 |
| skaet | slangasek, yeah, my bad. Thought they were going in proposed. At any rate, hold off on accepting based on timing in there. Will fix. | 21:12 |
| balloons | hello all.. continuing a conversation on non-pae kernel support here. it appears we are not shipping a non-pae kernel on our iso images for today.. | 21:26 |
| balloons | according to a few kernel members, the non-pae kernel support was kept, but it's not on the installer | 21:27 |
| balloons | is this intended behavior or a bug? | 21:27 |
| slangasek | balloons: intended behavior | 21:27 |
| slangasek | it's available for upgrades only | 21:27 |
| hggdh | slangasek: what happens if someone tries to install precise on a non-pae machine? | 21:28 |
| hggdh | ah | 21:28 |
| balloons | slangasek, why upgrades only? | 21:28 |
| GrueMaster | hggdh: Failure. | 21:28 |
| ScottK | slangasek: I thought it was meant to be different for Lubuntu? | 21:28 |
| balloons | I'm not trying to stir up dirt here :-).. my apologies if I am.. I can simply take the answer | 21:29 |
| hggdh | actually, seems to be worse, installation preceeds to end, and then fails on reboot | 21:29 |
| slangasek | ScottK: Lubuntu may be using the non-pae kernel, I don't know | 21:30 |
| slangasek | balloons: because supporting it for installs means taking up a very scarce resource - space on the CD | 21:30 |
| balloons | slangasek, ScottK lubuntu is afaik.. I'm having the tester in question use it instead.. no negative feedback thus far, so I'm assuming it's working :-) | 21:31 |
| balloons | slangasek, thanks for explaining | 21:32 |
| sbeattie | hggdh: wait, what? we're shipping the non-pae kernel in the live cd but booting into a pae kernel? I don't think that's accurate... | 21:32 |
| sbeattie | s/booting/after installation completes booting/ | 21:32 |
| infinity | hggdh: That seems unlikely, since the CD also uses the pae kernel. | 21:33 |
| hggdh | balloons: ^ | 21:33 |
| slangasek | hggdh, sbeattie: we are certainly not shipping a non-pae kernel on the Ubuntu CD in precise | 21:33 |
| slangasek | that was changed early in the cycle | 21:34 |
| sbeattie | slangasek: right, but then I'd assume the livecd would fail to boot, not have a failure upon rebooting after the installation has completed. | 21:34 |
| GrueMaster | I highly recommend release noting this at the very least, as a lot of system recyclers will be very displeased to learn they can't recycle older systems due to this issue. | 21:35 |
| balloons | right.. I took that as the cd has pae kernel only.. archive has non-pae kernel | 21:35 |
| slangasek | sbeattie: correct. The CD will fail to boot. | 21:35 |
| sbeattie | (hence my boggling at hggdh's failure description) | 21:35 |
| GrueMaster | sbeattie: That is the behavior I am seeing here in VirtualBox with PAE/NX disabled. Total boot failure on the cd. | 21:35 |
| hggdh | sbeattie: heh. I was just the messenger | 21:36 |
| sbeattie | ah, okay, I'll stop shooting bogglement bullets in your direction. :-) | 21:36 |
| doko | slangasek, I'm fine with python-defaults as a sru | 21:54 |
| slangasek | doko: ok | 21:54 |
| Laney | ScottK: ^^^ | 21:56 |
| micahg | can someone take a look at the flashplugin-nonfree upload ^^ | 22:31 |
| ScottK | infinity: Is it you putting buildds on manual again? | 22:39 |
| infinity | ScottK: Yep. | 22:39 |
| ScottK | infinity: Would you please let haskell-bloomfilter go before you grab powerpc. It's s quick build and getting it done will let me do another sync. | 22:40 |
| infinity | ScottK: I have no intention of angering powerpc. | 22:40 |
| ScottK | OK. | 22:40 |
| ScottK | Excellent. | 22:40 |
| infinity | ScottK: The only stuff on manual (other than two broken Pandas) are "old x86 builders", so we can give the new ones a workout. | 22:41 |
| micahg | infinity: can you review flash? | 22:45 |
| infinity | Did I break it? | 22:46 |
| micahg | infinity: well, not upgrade is closer than break :) | 22:47 |
| infinity | Huh. I grepped. | 22:47 |
| infinity | Let me guess, the SHA256 in the post-download-hook doesn't have the same variable name? :/ | 22:47 |
| micahg | infinity: sbeattie added a README.Debian to make it easier in teh future | 22:48 |
| micahg | infinity: correct | 22:48 |
| * infinity sighs. | 22:48 | |
| micahg | infinity: 'rgrep -i sha256 *' should've caught it | 22:48 |
| infinity | Simple fix, s/SHA256SUM/Sha256/ in the other scripts, so it matches the hook, and an rgrep works. | 22:48 |
| infinity | I didn't think to grep insensitively. :P | 22:49 |
| infinity | Oh well. | 22:49 |
| micahg | well, there's documentation now to help the next victim^Wvolunteer to look at updating flash | 22:49 |
| sbeattie | as I've said elsewhere, the real fix is to only specify the version and sha256sum in one location, not three. | 22:50 |
| infinity | Honestly, if you find the SHA256 in two places, you won't read a README to find out there's a third. | 22:50 |
| micahg | yeah, that too :) | 22:50 |
| infinity | You'll just think you're clever for having found two. | 22:50 |
| micahg | there's a note above each telling you what else to update | 22:50 |
| === yofel_ is now known as yofel | ||
| micahg | won't help if you're using sed though | 22:50 |
| infinity | Oh, that's vaguely helpful. ;) | 22:50 |
| * infinity needs food. | 22:56 | |
| skaet | is it my impression or is the wiki ...crawling.... | 23:05 |
| slangasek | I had a server-side error a little bit ago | 23:05 |
| skaet | ack.. | 23:05 |
| skaet | slangasek, yes, seeing Error reading from remote server now as well. :P | 23:10 |
| Laney | doomed to not communicate | 23:10 |
| Laney | also, the topic could do with updating | 23:10 |
| skaet | Laney, yup. meant to earlier | 23:11 |
| * skaet handles that at least while she can't update WIKIs... :P | 23:11 | |
| === ChanServ changed the topic of #ubuntu-release to: Archive: frozen | https://wiki.ubuntu.com/PrecisePangolin/FrozenArchiveStatus | Precise Pangolin 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 chocolate covered ants | melior malum quod cognoscis | ||
| skaet | Laney, done. | 23:14 |
| Laney | excellent work | 23:15 |
| skaet | we strive to communicate.... and yes, had to get the link from the pad. *sigh* | 23:16 |
| Laney | You should entertain my idea for a Twitter account. We could come up with an efficient set of hashtags :P | 23:17 |
| ScottK | I'm not sure how the wiki is better than the pad was. | 23:20 |
| ScottK | You still have to refresh it to get current data. | 23:20 |
| skaet | ScottK, don't have to sign in to see it, was the hope. but with the current behaviour.... | 23:21 |
| Laney | at least you know you have to refresh it | 23:21 |
| ScottK | True. | 23:22 |
| micahg | skaet: just use Daviey's pad if you don't want to have to sign in | 23:23 |
| ScottK | Although I knew that by now about the pad. | 23:23 |
| ScottK | micahg: Daviey's pad was deemed insuffiently reliable. | 23:23 |
| ScottK | ..c.. | 23:23 |
| skaet | wiki appears to be working again... | 23:26 |
| infinity | I never had issues with Daviey's pad, FWIW. | 23:30 |
| infinity | But whatever. We can stop caring again in 1.5 weeks. :P | 23:30 |
| ScottK | Right. That wasn't my assessment. | 23:32 |
| slangasek | sbeattie: fyi, the problem in bug #983559 is by design; see bug #979477 for the unfortunate anti-bug | 23:39 |
| ubot2 | Launchpad bug 983559 in update-notifier "package-data-downloader utility does not honor apt http proxy settings" [Medium,Triaged] https://launchpad.net/bugs/983559 | 23:39 |
| ubot2 | Launchpad bug 979477 in update-notifier "ttf-mscorefonts-installer installation popup and probable failure" [High,Fix released] https://launchpad.net/bugs/979477 | 23:39 |
| sbeattie | slangasek: except that the flashplugin-installer *is* pulling from a valid apt archive. | 23:41 |
| sbeattie | where ttf-mscorefonts-installer was not. | 23:42 |
| sbeattie | this suggests an inflexibility on configuration of package-data-downloader plugins | 23:42 |
| slangasek | sbeattie: the fact that it's an apt archive is a curious implementation detail; it's not *using* it as an apt archive, it's not even downloading a .deb, and I don't expect the users who are affected by bug #979477 to have an apt proxy that knows about partner | 23:42 |
| ubot2 | Launchpad bug 979477 in update-notifier "ttf-mscorefonts-installer installation popup and probable failure" [High,Fix released] https://launchpad.net/bugs/979477 | 23:42 |
| slangasek | the real bug behind 983559 is not having the proxy configured for *non*-apt software, and flashplugin failures are just a symptom; probably bug #982684 | 23:43 |
| ubot2 | Launchpad bug 982684 in sudo "sudo doesn't apply global environment settings from /etc/environment" [Medium,Triaged] https://launchpad.net/bugs/982684 | 23:43 |
| slangasek | (filed in direct response to this issue, and being worked on) | 23:44 |
| sbeattie | slangasek: well, I have to admit that I wish the flashplugin-installer did use it as a correct apt archive, so that it would pick it up from my local (non-distributed) mirror of the partner archive. | 23:47 |
| slangasek | sure... I can't see any way to make that work in the general case though | 23:48 |
| slangasek | except that flashplugin-installer does support debconf preseeding to point at a local file | 23:49 |
| slangasek | (but not a local mirror) | 23:49 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!