[01:44] <knome> skaet or somebody else with power: can you accept https://blueprints.launchpad.net/ubuntu/+spec/other-q-xubuntu-marketing for quantal? thanks!
[01:45] <knome> skaet, ^ also, can set that as medium :)
[02:27] <ScottK> The equivalent changes for ^^^ will have to go through -security for n/o/p.
[02:32] <stgraber> knome: done
[02:32] <knome> stgraber, ta :)
=== ara_ is now known as ara
[08:02] <diwic> Hi, I'm preparing an SRU for PulseAudio in 12.04. Would it be best to 1) upload as soon as possible to make sure it gets into 12.04.1 or 2) wait until 12.04.1 is released and after that upload? It's not critical.
[08:04] <jibel> slangasek, stgraber infinity unmet dep issue with nspr4 is bug 1036794
[08:04] <ubot2`> Launchpad bug 1036794 in update-manager "unmet dependencies during update of nspr4: libnspr4 : Breaks: evolution-plugins (< 3.2.0-0ubuntu2) but 2.32.2-0ubuntu7 is to be installed" [High,Triaged] https://launchpad.net/bugs/1036794
[08:05] <jibel> this occurs when there is an old version of evolution-plugins (2.32.2-0ubuntu7 from natty) installed on the system and the user upgrade to the latest version of nspr in Precise which breaks evolution-plugins
=== Riddelll is now known as Riddell
[08:31] <njin> hallo
[08:32] <njin> hallo
[08:32] <njin> today's build of amd64 server isn't updated on cdimage (still preent the one of yesterday)
[08:33] <njin> preent/present
[08:33] <xnox> njin: patience. has it been more than 24h since the last one?
[08:33] <xnox> even then the window between the two is 48h to call it "daily"
[08:34] <xnox> it should be there in 1.5h
[08:34] <njin> xnox, it is published in the iso tracker but not in the cdimage
[08:34] <xnox> as it's UTC time used
[08:34] <xnox> njin: now that is interesting.
[08:35] <njin> generally is a daily build and it cames up at 8.00 utc
[08:35] <njin> njin@quantic:~/Ubuntu$ zsync http://cdimage.ubuntu.com/ubuntu-server/daily/20120815/quantal-server-amd64.iso.zsync
[08:35] <njin> failed on url http://cdimage.ubuntu.com/ubuntu-server/daily/20120815/quantal-server-amd64.iso.zsync
[08:35] <njin> could not read control file from URL http://cdimage.ubuntu.com/ubuntu-server/daily/20120815/quantal-server-amd64.iso.zsync
[08:36] <xnox> njin: daily preinstalled are there http://cdimage.ubuntu.com/ubuntu-server/daily-preinstalled/20120815/
[08:36] <xnox> njin: but not daily
[08:36] <xnox> well for omap4 anyway
[08:36] <njin> xnox, that is the link that i copied from the iso tracker
[08:37] <xnox> sure. but you can predict the URLs ;-)
[08:37] <njin> yes, now i go to daily-preinstalled to see
[08:38] <xnox> well stgraber is the one who knows everything about the iso tracker.
[08:38] <xnox> i am not sure who is available and knows about cd publishing.
[08:38] <njin> could not read control file from URL http://cdimage.ubuntu.com/ubuntu-server/daily-preinstalled/20120815/quantal-server-amd64.iso.zsync
[08:39] <xnox> hmmm
[08:39] <xnox> njin: there is only this one published already http://cdimage.ubuntu.com/ubuntu-server/daily-preinstalled/20120815/quantal-preinstalled-server-armhf+omap4.img.gz.zsync
[08:39] <njin> xnox, ok let's wait
[08:40] <xnox> yeah, lets wait.
[08:40] <xnox> njin: to be honest, I wait for automated jenkins results before testing myself
[08:41] <njin> xnox, don't know how to use it
[08:42] <xnox> njin: https://jenkins.qa.ubuntu.com/view/Quantal/view/ISO%20Testing%20Dashboard/
[08:42] <xnox> this tells you per image pass/fail for daily images on i386 & amd64
[08:44] <njin> xnox, thanks, bookmarked this too
[08:59] <njin> ok, is on thanks
[09:34] <knome> can we get a SRU exception for #1001936 ?
[09:35] <tumbleweed> SRU exception?
[09:36] <knome> isn't there such a thing. isn't SRU stuff frozen at some point? :)
[09:36] <knome> micahg told we need one!
[09:36]  * knome hides
[09:36] <tumbleweed> oh, right point release
[09:36] <knome> yes :)
[09:36]  * tumbleweed has been a little out of it for the last couple of weeks
[10:04] <xnox> knome: bug #1001936 will make the bot print a link!
[10:04] <ubot2`> Launchpad bug 1001936 in xfwm4 "GTK3 Grab/Move Triggered on Mouse Click" [Undecided,Confirmed] https://launchpad.net/bugs/1001936
[10:04] <xnox> tadah! =)
[10:05] <xnox> knome: oh that one is funny =)
[10:07] <knome> xnox, i know
[10:19] <chrisccoulson> could someone please approve firefox in {natty,oneiric,precise}-proposed please? i've filled out the SRU template for the bug now....
[10:51] <smartboyhw> Question: What time does a Ubuntu Daily Build been regularly released?
[10:53] <Laney> look at the timestamps in (for example) http://cdimage.ubuntu.com/daily-live/current/ for an idea
[10:56] <xnox> smartboyhw: it takes time so depends on when it started and finished. They are published one by one for each flavour so times can vary a bit.
[10:56] <smartboyhw> Ok, thanks
[10:56] <smartboyhw> Waiting for a Ubuntu Studio daily build to test
[10:57] <smartboyhw> Laney and xnox: Do a new daily build release get announced here?
[10:58] <Laney> no
[10:58] <Laney> http://cdimage.ubuntu.com/ubuntustudio/dvd/current/
[10:58] <Laney> studio images come later in the day
[10:58] <Laney> are you waiting for a particular pressing issue?
[10:58] <smartboyhw> No, I'm responsible for 64-bit testing of Ubuntu Studio in the team
[11:00] <Laney> so, you can expect them around 18:45 UTC daily
[11:00] <smartboyhw> 18:45 UTC?
[11:00] <Laney> date -u
[11:03] <davmor2> smartboyhw: basically in the morning you are running a day behind in the current folder as long as everything built
[11:04] <smartboyhw> Oh
[11:05] <Laney> well, depends where in the world you are ;-)
[11:05] <smartboyhw> Hong Kong
[11:10] <davmor2> smartboyhw: so now is morning in the UK so now if you test you will be using yesterdays.   In 8+ hours time you will be using todays packages
[11:11] <davmor2> Laney: good point though :)
=== smartboyhw is now known as silly_cloudysunn
=== silly_cloudysunn is now known as smartboyhw
=== smartboyhw is now known as ubuntustudio-hw
=== ubuntustudio-hw is now known as smartboyhw
=== smartboyhw_ is now known as smartboyhw_us
[13:11] <stgraber> jibel: hmm, the "Holding Back evolution-plugins:i386 rather than change evolution:i386" part is quite weird... I'm wondering why apt is doing that.
[13:11] <smartboyhw> Hi stgraber
[13:28] <ScottK> diwic: It's too late to make sure anything gets into 12.04.1.  If you have a very targeted fix for a very severe bug, it might be considered.  Otherwise it'll go in post 12.04.1.  It does not hurt to upload it, it'll just stay in the unapproved queue.
[13:29] <diwic> ScottK, okay, thanks, I'll wait for 12.04.1 then.
[13:40] <knome> ScottK, re: your comment on severe stuff, do you think we could get bug #1001936 through?
[13:40] <ubot2`> Launchpad bug 1001936 in xfwm4 "GTK3 Grab/Move Triggered on Mouse Click" [Undecided,Confirmed] https://launchpad.net/bugs/1001936
[13:41] <ScottK> You'd have to ask stgraber  and only if there's a clearly low risk patch available in any case.
[13:48] <stgraber> can someone review ubuntu-sso-client? it's a frequent crasher and the diff looks reasonable so we might be able to get it in 12.04.1 if it's tested quickly
[13:49] <knome> stgraber, ^ :]
[13:51] <stgraber> knome: I don't see a debdiff in this bug so can't review it at this point
[13:54] <knome> the original commit-diff is at http://git.xfce.org/xfce/xfwm4/commit/?h=xfce-4.10&id=099614e3f045e06db7ab509e174510ea74857adb
[14:04] <stgraber> looks reasonable, if you can get it in -proposed in a couple of hours and have testers available to verify it, it might make it
[14:05] <knome> i'll look at it.
[14:23] <infinity> stgraber: That pkgProblemResolver output in #1036906 is kinda special.
[14:23] <smartboyhw> Bug #1036906
[14:23] <ubot2`> Launchpad bug 1036906 in nspr "libnspr4 bug report (unmet dependencies)" [Undecided,Confirmed] https://launchpad.net/bugs/1036906
[14:25] <slangasek> jibel: 1036794> great, thanks for catching that
[14:26] <stgraber> infinity: am I reading it wrong or is it language-support-translations-en creating a bit of a mess there?
[14:27] <infinity> stgraber: langpackish stuff may well be why evolution refuses to upgrade (which, in turn blocks the plugins, which then blocks nspr)
[14:42] <infinity> stgraber: I suppose we might need to build a bit of a dependency map here to see what's happening, but at least that output shows all the packages involved, so it should be vaguely reproducible.
=== bjf[afk] is now known as bjf
[15:34] <stgraber> infinity, slangasek: hmm, if I'm reading these logs right, it looks like a natty -> oneiric upgrade that held evolution and evolution-plugins, then the oneiric -> precise upgrade caused the failure... trying to reproduce
[15:35] <infinity> stgraber: That sounds about right, given the version(s) in play.
[15:37] <stgraber> the system was Edubuntu apparently, trying with a clean natty -> oneiric -> precise upgrade, will take a while though as Edubuntu is quite big and I don't have a local mirror of oneiric
[16:04] <stgraber> SpamapS: ping
[16:05] <stgraber> SpamapS: I believe it's your SRU day? If so, the following are ready to copy to updates: gnome-settings-daemon, telepathy-mission-control-5, nux, gcalctool, indicator-weather and sqlite3.
[16:06] <stgraber> SpamapS: we'll also probably get an early copy for a few others, but I'll get back to you after my meeting with skaet in a couple of hours
[16:07]  * skaet nods
[16:09] <stgraber> SpamapS: looking at unapproved, mesa seems to be a duplicate of what we have in -proposed but with a different version number. Can probably be dropped.
[16:09] <stgraber> SpamapS: ubuntu-sso-client and ubuntuone-installer should be considered for inclusion into -proposed as they are frequent crasher that we might want fixed for 12.04.1 (though not high priority)
[16:12] <skaet> stgraber,  SpamapS,   walinuxagent also appears to be verified, and should probably get copied over.
[16:13] <stgraber> skaet: right, didn't list it because it's only been there for 5 days, but as it's a new package, there's no risk of regression, so copying is fine indeed
[16:17] <knome> stgraber, ^ that
[16:21] <stgraber> knome: waiting for LP to generate the diff
[16:21] <knome> stgraber, ok. mr_pouit said he had to go now, but he will be back later today to reupload, IF we need something.
[16:25] <SpamapS> stgraber: ACK on all
[16:25] <SpamapS> skaet: ACK to you as well :)
[16:26] <skaet> :)
[16:52] <slangasek> chrisccoulson: firefox accepting
[17:09] <balloons> stgraber, do you feel this bug should be handled as an SRU? https://bugs.launchpad.net/ubuntu/+source/abiword/+bug/1019621
[17:09] <ubot2`> Ubuntu bug 1019621 in abiword "Precise abiword version needs to be reverted to stable release prior to 12.04.1" [Undecided,Confirmed]
[17:10] <stgraber> balloons: reverting would cause regression and upgrading would cause new features. We need an upstream fix cherrypick.
[17:10] <stgraber> balloons: and that certainly won't happen to 12.04.1
[17:11] <balloons> stgraber, no of course not.. But I was wondering how it needed to be handled
[17:11] <balloons> ok, so it's not an SRU.. it needs development attention
[17:11] <balloons> err.. well, it would still go through as an SRU then or no?
[17:11] <balloons> I mean, if I cherrypick fixes, the update is still an SRU, right?
[17:11] <stgraber> if someone can cherry-pick the fix without causing regression or feature change, yes
[17:12] <balloons> stgraber, well that should be the point.. it's unstable and needs a fix.. we don't want to simply rebase to a new or old version
[17:13] <balloons> ok.. but let's say a feature change and/or regression can't be avoided. For my learning sake, what would happen then?
[17:13] <stgraber> most likely and as bad as it sounds, nothing, we'd just wait until someone finds a way of doing it without these side effects
[17:15] <stgraber> FWIW, only Xubuntu is supporting abiword in 12.04, so I wouldn't count on the bug getting fixed real soon as they seem to be a bit short on resources
[17:27] <knome> what bug?
[17:27] <balloons> stgraber, ok.. in short when dealing with issues like this, you etheir meet the requirements for an SRU, or it doesn't get fixed?
[17:27] <knome> oh, that.
[17:27] <balloons> knome, yes.. speaking i reference.. but I'm trying to understand on a more general scale how this works
[17:27] <knome> yeah, sure
[17:28] <stgraber> balloons: pretty much, yes. There are some specific exceptions for new upstream releases as MRE, but they still should be bugfix only and regression free.
[17:28] <balloons> k, makes sense.. I think that clears it up for me
[17:28] <stgraber> balloons: the only exceptions I'm aware of for the bugfix only part of that is firefox and thunderbird
[17:53] <stgraber> SpamapS: add xfwm4 to the list of packages in Unapproved to review for inclusion in -proposed
[17:55] <SpamapS> stgraber: will do
[17:59] <marrusl> So SpamapS, RAOF... I'd still like to push out the dconf SRU early if possible.  It's not a huge difference (2 days), but it will still provide Customer Happiness.
[17:59] <marrusl> said customer could use some extra love right now.  :)
[18:00] <stgraber> marrusl: it's on the tracking list for 12.04.1 already
[18:00] <slangasek> stgraber: I believe he's asking for it to be released before the 7 day mark
[18:00] <SpamapS> stgraber: when do things have to hit -updates to be included in 12.04.1 ? Monday?
[18:00] <marrusl> indeed.
[18:01] <SpamapS> because it won't go to updaets on Friday, we don't do that. :)
[18:01] <stgraber> SpamapS: ideally, before tomorrow 21:00 UTC where we enter final freeze
[18:01] <stgraber> slangasek: yep, I know that, it's on my list of things that we will want to copy before the 7 days
[18:05] <SpamapS> marrusl: would that work for you then? Tomorrow instead of Friday?
[18:06] <marrusl> SpamapS, I think it does, surely.  So i can say "by tomorrow 21:00 UTC" ?
[18:09] <SpamapS> stgraber: ^^ yes?
[18:10] <stgraber> yep, I'm expecting everything for 12.04.1 to be accepted by then, after that we'll only copy in case of emergency
[18:17] <marrusl> I'm taking that as a yes.  :)  Thanks, folks!
[18:17] <SpamapS> marrusl: any time
[18:34] <stgraber> slangasek, skaet, infinity: http://pad.ubuntu.com/12-04-1-preparation
=== debfx_ is now known as debfx
[19:25] <ScottK> skaet: Is $SOMEONE going to update the common infrastructure parts of the release notes?
[19:25] <ScottK> stgraber: ^^^
[19:25] <skaet> ScottK,  yes,  have asked slangasek to take a pass
[19:30] <ScottK> OK.  Thanks.
[19:38] <slangasek> stgraber: hmm.  do you know why gnome-language-selector says I should install 'poppler-data' as part of the not-completely-installed language support?
[19:38] <slangasek> I'm not sure where this is coming from
=== knome_ is now known as knome
[19:41] <slangasek> n/m, figured it out
[19:54] <stgraber> slangasek: I'll let you poke at the nspr bug and will look at the chinese issues (as I had no luck trying to reproduce the evolution packages hold after a natty to oneiric upgrade)
[19:54] <slangasek> ok
[20:05] <stgraber> ok, sure enough the chinese media comes with /etc/default/locale containing en_US.UTF-8
[20:06] <stgraber> slangasek: hmm, ubuntu-defaults-zh-cn is missing on the media, I guess that'd explain the issue ;)
[20:07] <stgraber> hmm, that doesn't match the manifest... /me checks it's the right image
[20:09] <stgraber> gah, VM had an older version of the file opened... starting from scratch
[20:11] <slangasek> stgraber: ubuntu-defaults-zh-cn is not missing on the media, where do you see that it is?
[20:11] <slangasek> stgraber: it's definitely in the .manifest
[20:11] <stgraber> slangasek: as I said, VM was using a bad media... I overwrote another image with the same name and libvirt still had an open fd so it never used the real chinese image
[20:11] <slangasek> ah, ok :)
[20:12] <stgraber> booting the chinese image indeed has ubuntu-default-zh-cn and /etc/default/locale set to zh_CN.UTF-8
[20:12] <stgraber> the installer starts in chinese but the indicators are in english
[20:12]  * slangasek nods
[20:12] <stgraber> oh, might be as simple as sourcing /etc/default/locale in ubiquity-dm
[20:13] <slangasek> seems plausible
[20:15] <stgraber> oh, actually ubiquity-dm is the thing writing /etc/default/locale apparently and /etc/locale.gen and /etc/environment
[20:15] <stgraber> anyway, I think I know how to fix it while not making too many changes
[20:18] <skaet> thanks stgraber.
[20:21] <stgraber> slangasek: here's what ubiquity.conf contains and the reason why LANG and LANGUAGE are empty ;) http://paste.ubuntu.com/1149469/
[20:21] <slangasek> arrrgh
[20:22] <slangasek> well, we aren't going to be fixing that in pam for 12.04.1
[20:22] <stgraber> no, but dropping that code and replacing by "[ -r /etc/default/locale ] && . /etc/default/locale" + export should work
[20:23] <skaet> stgraber,  slangasek,   was talking with superm1, and it sounds like mythtv is pretty much as verified as it can be.   Last bug is going to need to have someone with that specific hardware.   Let it through?
[20:24] <stgraber> superm1: can you update the bugs? last I checked they were all still in verification-needed state
[20:24] <slangasek> and it would require a ubiquity change anyway
[20:24] <slangasek> can you just source /etc/default/locale?
[20:24] <superm1> stgraber: they got updated today earlier
[20:26] <stgraber> slangasek: just sourcing doesn't seem to be enough from the upstart job, trying source + export of LANG and LANGUAGE now (if set)
[20:27] <slangasek> stgraber: yes
[20:27] <slangasek> stgraber: fwiw the nspr fix may be to add a Breaks: evolution (<< $modern) as well
[20:27] <slangasek> stgraber: do you have an env where you can reproduce this bug?
[20:28] <stgraber> slangasek: nope, had no luck reproducing the same situation on Oneiric (apt holidng evolution from natty)
[20:29] <stgraber> well, I guess I could pin it, but I'm not sure it'd cause the same upgrade failure
[20:30] <slangasek> the debug log on the bug shows language-support-translations-en, which is obsolete
[20:31] <slangasek> pre-lucid
[20:32] <stgraber> slangasek: does that look sane to you? http://paste.ubuntu.com/1149486/
[20:33] <slangasek> stgraber: yep
[20:33] <stgraber> ok, pushing that one then
[20:39] <stgraber> slangasek: latest release to include language-support-translations-en was jaunty
[20:40] <stgraber> and it had: Depends: openoffice.org-help-en-us, openoffice.org-help-en-gb, openoffice.org-l10n-en-gb, openoffice.org-l10n-en-za, thunderbird-locale-en-gb, gimp-help-en, evolution-documentation-en
[20:40] <slangasek> yeah
[20:43] <slangasek> so I think we should add a Breaks: evolution-documentation-*
[20:43] <slangasek> but I don't know if that's sufficient; we may need other handling of language-support-translations-*
[21:01] <slangasek> infinity: the nspr in the precise-proposed queue is my educated shot in the dark
[21:03] <infinity> slangasek: That's not a comforting description.
[21:03] <slangasek> when have you known me to be comforting :)
[21:04]  * slangasek wonders if we should trim down some of the obsolete code in DistUpgrade/DistUpgradeQuirks.py
[21:08] <slangasek> the real question is if we can get a viable test case for it
[21:09] <slangasek> because step one is "make sure you have an obsolete package from 5 releases ago installeD"
[21:09] <stgraber> I've been trying to reproduce the upgrader's system by hand in a chroot but he has a lot of packages coming from out of distro repositories
[21:09] <stgraber> and a few that look like the result of alien...
[21:10] <stgraber> my chroot has apt sources for all releases since hardy (using old-releases), trying to get all of them to the right version ;)
[21:10] <stgraber> that's where apt-clone would be kind of useful...
[21:11] <slangasek> stgraber: I think only the language-support-en stack should be needed to reproduce
[21:12] <slangasek> I'd suggest starting there, and only if that fails try to reproduce the identical environment
[21:15] <stgraber> slangasek: yeah, that's what I tried first but that didn't seem to be enough
[21:15] <stgraber> I'd just have evolution be upgraded as evolution-common provides evolution-documentation-en
[21:17] <slangasek> oh, it does?
[21:17] <stgraber> well, not in precise, but it used to, yeah
[21:17] <slangasek> hmm
[21:18] <slangasek> well, getting evolution upgraded is certainly where we want to get to
[21:31] <stgraber> slangasek: and I can perfectly have language-support-translations-en, evolution, evolution-common and evolution-documentation-en installed on an oneiric system at the same time... time to retry that on natty I guess
[21:32] <jibel> slangasek, stgraber on the system affected evolution, is not installed, just evolution-plugins.
[21:32] <jibel> evolution-plugins always depends on evolution excepted in maverick and natty
[21:32] <stgraber> ah, interesting, will try that
[21:32] <jibel> so a test case would be to install language-support from jaunty, evolution-plugins from natty and upgrade
[21:38]  * xnox wonders how one managed to mix packages from jaunty & natty
[21:38] <stgraber> xnox: they just upgraded all the way from jaunty to oneiric
[21:39] <stgraber> or even before that
[21:39] <stgraber> by dist-upgrading at every release
[21:39] <xnox> stgraber: ok, so why wasn't language-support upgrade ( me jumping half way in to a conversation....)
[21:39] <xnox> maybe I should read context first before wasting your time =)
[21:40] <knome> stgraber, any progress on our little bug?
[21:40] <slangasek> xnox: the language-support-* packages no longer exist
[21:40] <xnox> slangasek: news to me =)))) /me doesn't pay attention to languages packages these days
[21:41] <xnox> i did went i had dual boot and constantly were purging them.
[21:41] <xnox> it's langpacks now with dictionaries isn't it.
[21:49] <stgraber> knome: it's been granted an exception, now you need an sru team member to review it and let it through
[21:52] <knome> stgraber, okay. who can do that? :)
[21:52] <knome> stgraber, i mean, is there a list somewhere, where should i ask etc...
[21:53] <micahg> knome: https://wiki.ubuntu.com/StableReleaseUpdates#Publishing
[21:53] <knome> to what should i point to, when i want them to process stuff?
[21:59] <stgraber> jibel: that's not enough, with these, evolution-plugins is still upgradable to the oneiric version and then to precise...
[22:10] <skaet> stgraber, Daviey, slangasek;   http://pad.ubuntu.com/ubuntu-release has been set up for 12.04.1 now.
[22:11] <stgraber> The following packages have been kept back:
[22:11] <stgraber>   evolution-common evolution-indicator evolution-plugins
[22:11] <stgraber> yay, looks like what we want!
[22:11] <slangasek> stgraber: what was the key?
[22:13] <stgraber> forced the natty version of these 3 and got language-support-translations-en from jaunty
[22:13] <stgraber> though that's not enough, update-manager still resolves the upgrade fine...
[22:13] <slangasek> man
[22:13] <slangasek> then how are so many people affected by this?
[22:15] <stgraber> they probably have another package installed that makes things even worse
[22:19] <stgraber> slangasek: found an apt-clone state tarball in one of the bugs!
[22:29] <stgraber> that guy had a lot of stuff installed on his system... will have to wait 40min to have the clone restored...
[22:38] <jibel> stgraber, here is the recipe
[22:38] <jibel> On Precise up to date, enable natty
[22:38] <jibel> apt-get install evolution-plugins/natty evolution-common/natty
[22:38] <jibel> this will downgrade libnspr4 to the version from natty
[22:39] <jibel> Install libnspr4 4.8.9-1ubuntu2 from precise-release
[22:39] <jibel> Download http://launchpadlibrarian.net/24623320/language-support-translations-en_9.04%2B20090401_all.deb
[22:39] <jibel> Install it and the required dependencies from Precise
[22:39] <jibel> apt-get dist-upgrade
[22:39] <jibel> tada !
[22:39] <stgraber> nice!
[22:39]  * stgraber stops fighting with oneiric and follows these
[22:40] <jibel> now, does it affect Oneiric to Precise ? I haven't tried
[22:52] <stgraber> jibel: right, reproduced with your instructions
[22:52] <stgraber> testing slangasek's fix now
[22:59] <stgraber> slangasek: your package doesn't seem to fix it
[23:00] <stgraber> slangasek: or at least, installing the new package on a broken system doesn't fix it
[23:00] <stgraber> oh, ignore me, wrong version
[23:01] <stgraber> rebuilding ubuntu2.2 now...
[23:01] <stgraber> The following packages will be REMOVED:
[23:01] <stgraber>   language-support-translations-en
[23:02] <stgraber> slangasek: looks like success ^
[23:02] <slangasek> is that the only removal?
[23:02] <stgraber> yep
[23:02] <slangasek> what about language-support-en?
[23:02] <slangasek> was that not in your test?
[23:02] <stgraber> nope, I followed jibel's instructions so didn't have language-support-en installed
[23:02] <slangasek> ok; I think we need to test that too
[23:02] <stgraber> let me grab it from natty too
[23:03] <slangasek> because every added layer of dependency affects apt's preference for removal vs. hold
[23:06] <stgraber> The following packages will be REMOVED:
[23:06] <stgraber>   language-support-en language-support-translations-en
[23:06] <stgraber> so that's leaving me with language-support-writing-en around but apparently not causing any problem
[23:09] <slangasek> ok
[23:10] <slangasek> sounds like it's at least suitable for precise-proposed, then?
[23:11] <slangasek> stgraber: do you mind updating the test case on the bug description to match what you've used?
[23:12] <slangasek> infinity: ^^ stgraber has shown that the nspr in the queue at least does something; do you mind reviewing?
[23:14] <stgraber> slangasek: testcase updated
[23:15] <stgraber> re-trying with that exact testcase as mine was mostly done with manually grabbing stuff from LP
[23:21] <stgraber> slangasek: right, works in a clean chroot with the instructions I put in the description
[23:52] <stgraber> SpamapS: the remaining unapproved entries to review are: nspr, ubiquity, xfwm4 and ubuntu-sso-client
[23:55] <SpamapS> stgraber: I got pulled into some other stuff today, but I'll take a look at them tonight after family time.
[23:55] <SpamapS> stgraber: should any be given priority?
[23:56] <micahg> SpamapS: if you have time after those, icedtea-web would be nice
[23:56] <stgraber> nspr is the highest priority one, the rest are all wanted for 12.04.1 too but aren't as urgent
[23:56] <stgraber> (nspr fixes an upgrade regression introduce by the previous one)
[23:57] <micahg> (icedtea-web is after all the 12.04.1 ones)
[23:58] <slangasek> SpamapS: nspr, it's iterating an upgrade issue