[00:23] <chrisccoulson> hi rickspencer3!
[00:23] <micahg> hi rickspencer3
[00:23] <rickspencer3> hi chrisccoulson, micahg
[00:23] <mdeslaur> my servers seem to have language packs installed
[00:23] <micahg> so, spamaps says there's no lang packs on a server by default
[00:23] <micahg> so, our bug case is an exception
[00:23] <micahg> at least for the servers
[00:23] <chrisccoulson> so, my concern is with blocking the firefox upgrade is that we also need to block all of the language packs too
[00:24] <chrisccoulson> as the language pack upgrades depend on having the firefox language packs in the archive at the time of upgrade
[00:24] <chrisccoulson> else the user loses all of their firefox translations
[00:24] <micahg> hmm, I wonder if update-manager will install the langpack when it becomes available
[00:24] <chrisccoulson> i'm not sure what the process of blocking packages is (do we rm them, or chmod 0 them?), but pitti isn't around tomorrow (the only person who can respin language packs)
[00:25] <chrisccoulson> micahg, no
[00:25] <rickspencer3> hi SpamapS thanks for joining again
[00:25] <chrisccoulson> they will only get installed during the upgrade where the recommends is added
[00:25] <chrisccoulson> they definitely need to exist during this upgrade, or the user misses out entirely
[00:25] <micahg> mdeslaur: if the langpacks aren't on the server by default, do we have to worry about it?
[00:25] <chrisccoulson> that's what we need to establish, i guess
[00:26] <SpamapS> There are plenty of reasons to add a language pack to a server..
[00:26] <SpamapS> language-pack-es-base: /usr/share/locale-langpack/es/LC_MESSAGES/wget.mo
[00:26] <mdeslaur> micahg: I'm installing a new server now to see
[00:26] <mdeslaur> all my current servers have language packs installed that I don't remember manually installing
[00:26] <micahg> chrisccoulson: we can push the next round of updates as well
[00:27] <chrisccoulson> m'eh, if arm wasn't so slow, this wouldn't be such an issue
[00:27] <chrisccoulson> is anyone running arm servers?
[00:27] <chrisccoulson> can't we just publish the i386 and amd64 builds as soon as they are done, and just skip armel for this build entirely?
[00:27] <rickspencer3> let us assume for a moment that 100% of natty servers have a lang back isntalled
[00:27] <rickspencer3> in such a case, do we *still* need to block anything
[00:27] <rickspencer3> ?
[00:28] <micahg> well, mdeslaur is about to test this
[00:28] <rickspencer3> is this disruptive enough to users to bring down the system, or should we rather wait?
[00:28] <rickspencer3> micahg, what I'm saying is, we no that >0 server users have a lang pack installed
[00:28] <chrisccoulson> rickspencer3, if we could publish the new firefox build in the next couple of hours (ie, when the i386 and amd64 builds are finished), then i don't think we need to block anything
[00:28] <chrisccoulson> but if we wait the 19 hours for the armel build to finish, then it might be a different story
[00:29] <chrisccoulson> that's why i'm wondering if we can just skip waiting for armel entirely (assuming this is just a server issue)
[00:29] <rickspencer3> is there anyway that users will succumb to this issue if they don't specifically use apt-get distupgrade?
[00:29] <micahg> rickspencer3: unattended-upgrades possible
[00:30] <rickspencer3> ok, so who can verify if unattended-upgrades use distupgrade or just upgrade?
[00:30] <micahg> so, the amd64 and i386 should be done in less that 3 hours
[00:30] <rickspencer3> SpamapS, do you know?
[00:30] <chrisccoulson> micahg, did you turn off the test suite?
[00:30] <chrisccoulson> they should be less than 1.5 hours in that case
[00:30] <micahg> chrisccoulson: ah, no, kees said not to
[00:30] <chrisccoulson> oh :(
[00:30] <chrisccoulson> that's a pain
[00:30] <chrisccoulson> that doubles the build time
[00:30] <rickspencer3> I agree with kees though
[00:31] <SpamapS> rickspencer3: I don't, not versed in unattended
[00:31] <rickspencer3> I think adding risk on top of of risk is not a good idea atm
[00:31] <chrisccoulson> rickspencer3, well, we don't really do anything with the test-suite results yet ;)
[00:31] <SpamapS> cloud servers seem to not have language packs.. but servers installed via the installer do.
[00:31] <chrisccoulson> (which is why i suggested disabling it for this build)
[00:31] <rickspencer3> uh
[00:32] <rickspencer3> chrisccoulson, ok, that's good to know!
[00:32]  * rickspencer3 adds to list
[00:32] <rickspencer3> ;)
[00:32] <chrisccoulson> heh
[00:32] <chrisccoulson> so, can we agree on whether we need to wait the 19 hours for the armel build to finish, as that could be the dealbreaker?
[00:32] <micahg> ugh, I forgot about that...
[00:33] <micahg> I can reupload somewhere else
[00:33] <chrisccoulson> SpamapS, is anyone using armel server builds? ;)
[00:33] <SpamapS> chrisccoulson: I'm sure there is *a* user out there somewhere.
[00:34] <rickspencer3> right
[00:34] <chrisccoulson> SpamapS, sure. is *a* user enough to block an upgrade for the other 19,999,999 users though? ;)
[00:34] <rickspencer3> but that user would hae to run dist-upgrade ... not see that firefox will be isntsalled, and install nayway
[00:35] <rickspencer3> chrisccoulson, could we not let the update out asap for non-ARM users, and then release it to the ARM users when it's down building?
[00:35] <chrisccoulson> rickspencer3, we can do the former (publish amd64 and i386 when they are built)
[00:35] <chrisccoulson> the issue is that we don't have a mechanism for publishing the armel builds later on when they are finished
[00:36] <chrisccoulson> we would need to do another upload with a new version number
[00:36] <micahg> rickspencer3: ATM no, LP is working on fixing that in the future
[00:36] <rickspencer3> ok ...
[00:36] <chrisccoulson> i really think we should just publish i386 and amd64 as soon as they are finished, and we can worry about armel tomorrow
[00:37] <rickspencer3> chrisccoulson, why not just upload the bug fix (done) and then just let evertyhing build and propegate as normal?
[00:37] <rickspencer3> it's not clear to me that this requires that the update be released asap
[00:37] <chrisccoulson> rickspencer3, because they won't be published to -security until tomorrow night
[00:37] <mdeslaur> micahg: uhm...what version of language pack is affected?
[00:38] <chrisccoulson> i guess it depends on how serious we think the issue is
[00:38] <mdeslaur> ie: my newly installed natty server did a dist-upgrade and nothing happened
[00:38] <micahg> 1:11.04+20110607
[00:38] <rickspencer3> chrisccoulson, that's what I'm asking?
[00:38] <micahg> mdeslaur: ^^
[00:38] <chrisccoulson> mdeslaur, holds the key!
[00:39] <mdeslaur> I've got language-pack-en-base installed at 1:11.04+20110607
[00:39] <mdeslaur> and it didn't pull in any firefox packages
[00:39] <chrisccoulson> mdeslaur, how did you upgrade?
[00:39] <mdeslaur> chrisccoulson: apt-get dist-upgrade
[00:39] <chrisccoulson> oh
[00:39] <mdeslaur> chrisccoulson: is it a Recommends?
[00:40] <micahg> recommends on the firefox-locale package
[00:40] <chrisccoulson> mdeslaur, yeah. language-pack-en-base recommends firefox-locale-en, which depends on firefox
[00:40] <chrisccoulson> that should have pulled it in :/
[00:40] <mdeslaur> apt-get dist-upgrade should not be pulling in new recommends
[00:40] <chrisccoulson> mdeslaur, is the server pulling in recommends by default?
[00:40] <micahg> ah, right, SpamapS ^^
[00:40] <mdeslaur> chrisccoulson: yes, but that only happens on install, not on dist-upgrade
[00:40] <chrisccoulson> the desktop does, and apt-get dist-upgrade does the right thing there
[00:41] <SpamapS> yes
[00:41] <chrisccoulson> mdeslaur, apt-get distr-upgrade pulls in recommends on upgrade too :)
[00:41] <SpamapS> servers do pull in recommends by default
[00:41] <chrisccoulson> (apt-get upgrade doesn't)
[00:41] <chrisccoulson> ok
[00:41] <chrisccoulson> i'm confused now then
[00:41] <SpamapS> on install
[00:41] <rickspencer3> ah
[00:41] <micahg> SpamapS: but on upgrades, not?
[00:41] <chrisccoulson> SpamapS, only on install?
[00:42] <micahg> then how do we explain bug 800857?
[00:42] <ubot2> Launchpad bug 800857 in firefox "language packs pull in Firefox on upgrade" [High,In progress] https://launchpad.net/bugs/800857
[00:42] <SpamapS> "under no circumstances are currently installed packages removed, or packages not already installed retrieved and installed."
[00:42] <SpamapS> from man apt-get regarding 'upgrade'
[00:42] <mdeslaur> SpamapS: what about dist-upgrade
[00:42] <chrisccoulson> SpamapS, yeah, that's true for upgrade. but dist-upgrade is different
[00:43] <SpamapS> mdeslaur: I would expect dist-upgrade to pull in new things, yes
[00:43] <SpamapS> but its not as clear in the man page
[00:43] <kees> unattended upgrade will install new kernels, so I assume it's a dist-upgrade.
[00:43] <chrisccoulson> that's a good point
[00:43] <mdeslaur> kees: my dist-upgrade is not pulling in new recommends
[00:43] <mdeslaur> kees: I seem to recall it will only install recommends on "install", but not on "dist-upgrade"
[00:43] <kees> mdeslaur: correct, but I thought this was a Depend: not a Recommends:
[00:43] <SpamapS> Oh for recommends.. hmm.. yeah dist-upgrade may not pick those up
[00:43] <mdeslaur> kees: could that be accurate
[00:43] <mdeslaur> it's only a recommends
[00:44] <chrisccoulson> dist-upgrade should be picking up recommends though. we're depending on this behaviour for pulling in the new firefox translations on upgrade, and it's been tested extensively on the desktop :/
[00:44] <chrisccoulson> i'm not sure why it didn't work in mdeslaur's case :/
[00:45] <SpamapS> I would not expect apt to behave much differently on servers and desktops.. though I haven't verified my expectations.
[00:45] <kees> which package is it that is triggering the problem?
[00:45] <kees> (binary package)
[00:45] <mdeslaur> kees: language-pack-en-base IIRC
[00:46] <mdeslaur> kees: do you have a natty server?
[00:46] <chrisccoulson> kees, language-pack-xx-base now recommends firefox-locale-xx
[00:46] <chrisccoulson> (which depends on firefox)
[00:46] <kees> heh. I don't have that installed on my server. ;)
[00:46] <micahg> so, the server test should be, install the release version of language-pack-en-base, dist-upgrade and see what's offered
[00:46] <mdeslaur> kees: no? it's installed by default...
[00:47] <kees> $ apt-cache policy language-pack-en-base | grep Installed
[00:47] <kees>   Installed: (none)
[00:47]  * kees shrugs
[00:47] <mdeslaur> whoa! apt-get install language-pack-en wants to pull in all of X
[00:48] <micahg> right
[00:48] <mdeslaur> I did a dpkg -P language-pack-en language-pack-en-base
[00:48] <mdeslaur> ok, let me try to install the release, and do a dist-upgrade again
[00:49] <micahg> chrisccoulson: we still have the langpacks in proposed, we can copy them again
[00:49] <kees> mdeslaur: yeah, apt-get upgrade doesn't pull X. apt-get dist-upgrade does.
[00:49] <kees> (tested in natty chroot with   apt-get install language-pack-en-base=1:11.04+20110421 language-pack-en=1:11.04+20110421)
[00:49] <chrisccoulson> that makes sense
[00:49] <mdeslaur> ok, my dist-upgrade now tried to pull in X
[00:49] <mdeslaur> crap
[00:50] <micahg> mdeslaur: so, I guess we need to pull it?
[00:50] <mdeslaur> let me try and trigger unattended-updates
[00:50] <micahg> k
[00:52] <kees> setting up auto updates, and running /etc/cron.daily/apt manually seems to not do anything....
[00:53] <rickspencer3> perhaps we should simply use the release twitter account to tell server users not to dist-upgrade until tomorrow?
[00:53] <rickspencer3> micahg, hae you set up an incident report yet?
[00:54] <chrisccoulson> rickspencer3, yeah, we could do. who has access to that twitter account?
[00:54] <micahg> rickspencer3: no, not yet
[00:54] <rickspencer3> let me look
[00:55] <mdeslaur> kees: how are you setting it up? I can't seem to get it to run
[00:56] <kees> mdeslaur: hm, it seems to want dbus... one sec
[00:56] <kees> in /etc/apt/apt.conf.d/10periodic I added
[00:56] <kees> APT::Periodic::Verbose "1";
[00:57] <kees> and changed RandomSleep to "1" instead of 1800
[00:57] <kees> from https://help.ubuntu.com/community/AutomaticSecurityUpdates
[00:59] <kees> and I'm doing  rm /var/lib/apt/periodic/update-stamp /var/lib/apt/periodic/upgrade-stamp /var/lib/apt/periodic/download-upgradeable-stamp /var/lib/apt/periodic/autoclean-stamp
[00:59] <micahg> rickspencer3: did you find the twitter info, I have it
[00:59] <rickspencer3> micahg, I did not
[00:59] <rickspencer3> could you go ahead and use it
[01:00] <rickspencer3> I'll set up the incident report
[01:00] <kees> mdeslaur: now set Verbose to "3"...
[01:00] <mdeslaur> kees: ok, I managed to get it to run
[01:01] <kees> yeah, it's doing a dist-upgrade...
[01:01] <mdeslaur> I downgraded libxml2, and ran it, and it only updated libxml2, it didn't try and update the language pack
[01:01] <mdeslaur> kees: it is?
[01:01] <kees> Allowed origins are: ['o=Ubuntu,a=natty-security']
[01:01] <kees> Checking: language-pack-en-base (["<Origin component:'main' archive:'natty-security' origin:'Ubuntu' label:'Ubuntu' site:'security.ubuntu.com' isTrusted:True>"])
[01:01] <kees> pkg 'apt-xapian-index' not in allowed origin
[01:01] <kees> sanity check failed
[01:01]  * kees scratches his head
[01:02] <mdeslaur> kees: I don't have a 10periodic file, don,t know where you got that from
[01:02] <kees> mdeslaur: the docs from https://help.ubuntu.com/community/AutomaticSecurityUpdates
[01:02] <mdeslaur> yeah, those don't make sense to me
[01:02] <kees> but set 1800 to "1", and add Verbose
[01:02] <kees> ah-ha
[01:02] <kees> I think it's saying that it is refusing to do the upgrade because the new packages aren't in the -security pockey
[01:02] <kees> *pocket
[01:03] <SpamapS> thats how I read it
[01:03] <mdeslaur> kees: they should be though
[01:03] <micahg> well, is that if you have -updates + -security enabled or just -security
[01:04] <kees> micahg: right, I'm trying the most common auto-update config first (-security only)
[01:04] <micahg> orly?  why would you get a package not in -security then?
[01:04] <kees> micahg: because it would be a new depends
[01:05] <micahg> ah, but so are kernels, aren't they?
[01:05] <mdeslaur> oh! it's failing the sanity check because it's trying to pull in aspell, which isn't in the -security pocket in my case
[01:05] <kees> so, automatic updates will block the update if -updates is not included in /etc/apt/apt.conf.d/50unattended-upgrades
[01:05] <kees> mdeslaur: correct. it's checking every single package.
[01:06] <kees> and (for natty) if I add -updates to /etc/apt/apt.conf.d/50unattended-upgrades it will _still_ fail because some of the stuff from that X stack isn't in -updates _either_.
[01:07] <mdeslaur> yep, I fail the sanity check on aspell because it isn't in -updates
[01:07] <mdeslaur> ok, so we may be lucky with most users
[01:07] <rickspencer3> micahg, https://wiki.ubuntu.com/IncidentReports/2011-06-22-Dist-upgrade-pulls-firefox
[01:07] <kees> so there is no natty autoupdate configuration that will install this update
[01:07] <micahg> rickspencer3: thanks, will start filling out
[01:07] <mdeslaur> agreed
[01:08] <mdeslaur> thank $DEITY
[01:08] <chrisccoulson> ok, so i feel better than i did 15 minutes ago :)
[01:08] <micahg> kees: mdeslaur, so the consensus is not to pull it then?
[01:08] <mdeslaur> micahg: agreed
[01:09] <kees> micahg: that would be my opinion, yes. put a note on twitter about avoiding dist-upgrade for the next few hours, and that should be enough
[01:09] <micahg> ok, second point of business would then be, do we push i386/amd64 right away or wait for armel (16 hour delay)
[01:09] <kees> 16 hours.... *whistle*
[01:09] <mdeslaur> I think we should push i386/amd64 right away, IMHO
[01:10] <chrisccoulson> *nod*
[01:10] <kees> my first impulse is to push i386/amd64 ahead of armel too
[01:10] <micahg> so, do we forget about armel/powerpc then?
[01:10] <chrisccoulson> those should be ready in the next 1.5 - 2 hours
[01:10] <mdeslaur> we can launch a second rebuild, and push it out again for armel/powerpc
[01:11] <kees> into -updates?
[01:11] <kees> we double the update frequency if we do the double-build
[01:11] <mdeslaur> yep
[01:11] <mdeslaur> we can call it "firefox 6"
[01:11] <mdeslaur> :)
[01:11] <kees> haha
[01:11] <chrisccoulson> lol
[01:11] <chrisccoulson> mdeslaur, why not 5.0.1? ;)
[01:12] <micahg> k, and a USN for each update then?
[01:12] <chrisccoulson> or 5.1?
[01:12] <kees> micahg: I would do just the first with the regression fix notification.
[01:12] <kees> micahg: the second is effectively a no-change rebuild
[01:13] <micahg> ok, I can add that in the changelog for the .3 upoad
[01:13] <micahg> *upload
[01:13] <mdeslaur> 2 hours + 17 hours will give us ample time to think about it and decide what to do
[01:13] <rickspencer3> how does this look for the identi.ca note: dist-upgrade on Natty will pull in Firefox in some cases, fix is uploaded, watch this bug: http://pad.lv/800857
[01:13] <rickspencer3> ?
[01:13] <mdeslaur> rickspencer3: s/Natty/Natty server/
[01:14] <rickspencer3> mdeslaur, well, if you have desktop and don't have firefox installed, it will do the same thing
[01:14] <mdeslaur> oh, right
[01:14] <rickspencer3> though (even server)
[01:14] <rickspencer3> I should add that
[01:14] <kees> yeah, that's a good way to put it
[01:15] <kees> how about: "dist-upgrade on Natty (even server) will incorrectly install Firefox if not already installed. fix uploaded, see http://pad.lv/800857"
[01:15] <kees> is that 140 char? :P
[01:15] <rickspencer3> how about this
[01:15] <rickspencer3> dist-upgrade on Natty (even Server) will pull in Firefox in some cases.  fix is uploaded, upgrade works as expected http://pad.lv/800857
[01:16] <rickspencer3> dang. we can spend all night massagign this into 140 characters ;)
[01:16] <SpamapS> s/will pull in Firefox in some cases/may pull in Firefox/
[01:16] <SpamapS> shorter
[01:16] <chrisccoulson> the builds will be ready by the you've got it in to 140 characters ;)
[01:16] <chrisccoulson> **by the time
[01:16] <kees> hehe
[01:17] <mdeslaur> hehe
[01:17] <rickspencer3> lol
[01:17] <rickspencer3> just doing my job
[01:17] <chrisccoulson> heh :-)
[01:17] <rickspencer3> dist-upgrade on Natty (even Server) may install Firefox in some cases.  Fix uploaded, upgrade works fine http://pad.lv/800857
[01:17] <mdeslaur> someone should update the bug also
[01:17] <chrisccoulson> i think the buildd's need a turbo button
[01:18] <kees> s/in some cases//
[01:18] <kees> but yeah, looks fine
[01:18] <rickspencer3> apt-get dist-upgrade on Natty (even Server) may install Firefox.  Fix uploaded, apt-get upgrade works fine http://pad.lv/800857
[01:18] <rickspencer3> done and done
[01:19] <mdeslaur> I can add a comment to the bug if nobody's currently doing it
[01:20] <micahg> mdeslaur: please do
[01:21] <mdeslaur> done
[01:21] <rickspencer3> I'm not sure this really falls into the category of "very serious problem for a very large number of users"
[01:21] <rickspencer3> but I guess it's best to over communicate rather than under communicate
[01:22]  * mdeslaur wished launchpad had a "fix typos" button to edit comments after they're posted...
[01:23] <rickspencer3> mdeslaur, i need one of those for the whole internet
[01:23] <mdeslaur> rickspencer3: hehe :)
[01:24] <mdeslaur> micahg: is there anything I can do to help at this point, or is everything under control?
[01:25]  * kees was just going to ask the same. :) have to head to dinner. I will check back.
[01:25] <chrisccoulson> i think we're ok now aren't we? we just need to ensure that someone is around who can copy the new builds to security in a couple of hours, don't we?
[01:27]  * rickspencer3 eyes kees
[01:27] <mdeslaur> chrisccoulson: these are building in the mozilla PPA?
[01:30] <chrisccoulson> mdeslaur, yeah
[01:31] <chrisccoulson> sorry, went to look for some food
[01:31] <chrisccoulson> :-)
[01:31] <mdeslaur> hmm...yeah, I think an AA is required for that...micahg, is that accurate, or can we unembargo directly from the PPA now?
[01:37] <micahg> mdeslaur: we've been able to unembargo from the PPA for a while (overrides were missing, but I think that's been fixed as well now)
[01:38] <micahg> I just don't know if a partial copy will work, but I'll try it as soon as the binaries are ready
[01:38] <micahg> rickspencer3: is it worth modifying the /topic in -devel
[01:38] <mdeslaur> micahg: ok, cool...we need to update the wiki page, it's out of date
[01:38] <rickspencer3> micahg, I don't believe so, but, as you wish
[01:40] <chrisccoulson> right, time for some more thunderbird messaging menu hacking before i call it a night
[01:42] <micahg> ugh, just realized my changelog description sucked
[01:42]  * micahg adds info to the bug
[01:49] <kees> I don't have archive admin super-powers, unfortunately. we'll need jdstrand or slangasek as most timezone sane
[01:53] <micahg> kees: we shouldn't need it
[01:55] <micahg> chrisccoulson: BTW, on the commit to trunk to fix the issue, I think it should only break on a new upstream version
[01:55] <chrisccoulson> how come?
[01:55] <chrisccoulson> a new upstream version of firefox, or the language pack?
[01:55] <micahg> well, if we do packaging changes, that shouldn't affect the integration of the langpacks
[01:56] <micahg> new upstream of firefox
[01:56] <chrisccoulson> the breaks is designed to catch both (and it needs to)
[01:56] <micahg> why do we need to worry about packaging changes (i.e. ubuntu1 -> ubuntu2)?
[01:57] <chrisccoulson> micahg, we don't. the current versioning is to avoid this lintian error - http://lintian.debian.org/tags/not-binnmuable-all-depends-any.html
[01:57] <chrisccoulson> (although, that only triggers on a Depends, but the same issue would affect Breaks too)
[01:59] <micahg> chrisccoulson: right, so why not use ${upstream:Version} as that solves the issue with that tag (I think that's the right way to call it)
[02:00] <chrisccoulson> micahg, i'd rather they were tighter than that. what if i add a patch which introduces a new string, for example?
[02:02] <micahg> so, that string would be untranslated, is there any other side effect?
[02:02] <rickspencer3> chrisccoulson, micahg, I need to step away
[02:02] <rickspencer3> I'll have my cell phone with me if you guys need anything
[02:02] <rickspencer3> laters
[02:03] <chrisccoulson> micahg, no, the UI would break. the string has to be in every single language pack translated or not
[02:03] <chrisccoulson> else it breaks
[02:03] <micahg> rickspencer3: ok, thanks, I'm still working on the incident report
[02:03] <micahg> chrisccoulson: ugh, ok then :)
[02:22] <micahg> chrisccoulson: also, if we would have shipped the langpacks separately, we could've released much faster :)
[02:22] <chrisccoulson> micahg, that's not a reason to split them. they should be in the same source package, like with everything else in our archive ;)
[02:22] <chrisccoulson> they are completely tied to each other, so it makes no sense to have them in separate packages
[02:23] <chrisccoulson> and i need a firefox source tree to build them
[02:25] <micahg> yeah, it's one of those catch 22s
[02:40] <micahg> chrisccoulson: I have the globalmenu disappearing thing again, anything I can do to debug?
[02:51]  * jdstrand is here
[02:51] <jdstrand> can someone fill me on on what is happening-- I see bug #800857
[02:51] <ubot2> Launchpad bug 800857 in firefox "language packs pull in Firefox on upgrade" [High,In progress] https://launchpad.net/bugs/800857
[02:52] <jdstrand> micahg: ^
[02:54] <micahg> jdstrand: ure
[02:54] <micahg> *sure
[02:55] <micahg> jdstrand: https://wiki.ubuntu.com/IncidentReports/2011-06-22-Dist-upgrade-pulls-firefox, update building in security PPA, will push when i386/amd64 is ready
[02:56] <jdstrand> reading
[02:57] <jdstrand> btw, one could just run unattended-upgrades and see...
[02:57] <micahg> well, we ended up doing that in the end and it failed (luckily)
[02:58] <jdstrand> btw, I am not sure this is as crisis-y as it is being made out (esp with unattended-upgrades not being a factor)
[02:58] <micahg> jdstrand: right, well, that's why we didn't pull it
[02:58] <jdstrand> imho, it is the right choice to push i386/amd64
[02:58] <jdstrand> armel would be at least 12 hours later
[02:59] <jdstrand> (if not closer to 14)
[02:59] <micahg> so, I've got a watch on the upload checking every 5 minutes for publication, I'll smoke test the builds (and verify dist-upgrade no longer pulls in firefox) and push it out
[02:59] <micahg> then send out a USN
[03:00] <jdstrand> micahg: sounds fine. there seemed to be a need for an AA-- why is that? to disable the affected pacakges?
[03:00] <micahg> jdstrand: no, I don't think there is a need for an AA
[03:02] <jdstrand> micahg: so the issue is that firefox-locale-* Depends on firefox, and the new langpacks Recommends firefox-locale-*
[03:02] <micahg> right
[03:02] <jdstrand> neat
[03:02] <micahg> and no one caught it with a week in proposed
[03:02] <jdstrand> that was not intuitive
[03:02] <jdstrand> well, most server users aren't running with -proposed
[03:03] <micahg> right, but I would've expected a kubuntu user to test it
[03:03] <jdstrand> true
[03:08] <micahg> jdstrand: should I add about my original call for testing to the incident report?
[03:09] <jdstrand> micahg: yeah, but not in the timeline. maybe as 'Background' in the 'Incident Description'
[03:09] <micahg> jdstrand: k
[04:38] <micahg> k, amd64 is published, i386 just finished building
[04:39] <jdstrand> I'm pulling amd64 as we speak to do a full test run
[04:40] <jdstrand> well, I'll skip sun-java
[04:41] <micahg> \o/ woohoo, dist-upgrade seems to be fixed with the new upload
[04:46] <jdstrand> \o/
[04:49] <micahg> jdstrand: do I need to test the dist-upgrade on amd64 as well?
[04:51] <jdstrand> no
[04:51] <jdstrand> micahg: ^
[04:51] <micahg> k
[04:52] <jdstrand> I did that here for just regular users and it went fine
[04:52] <micahg> k, installing the QRT depends
[04:52] <jdstrand> we can assume the packaging changes went through (and I can verify they are there)
[04:54] <jdstrand> actually the lanpacks come from the i386 build anyway, so we can assume it is all good since the upgrade worked fine here
[04:58] <jdstrand> I don't know what all the fuss is about really. I mean server users would get a way better browser experience with firefox than w3m anyway
[05:02]  * micahg didn't know that firefox had a cli mode :P :)
[05:03] <jdstrand> new in 5.0
[05:03] <micahg> hooray for version bumps :)
[05:04] <micahg> er, that should be ncurses mode, but you know what I mean :)
[05:14] <jdstrand> micahg: amd64 is good to go
[05:14] <micahg> jdstrand: k, running through i386 now, should be done in 10-15 min
[05:15] <jdstrand> micahg: are you doing the full run?
[05:15] <micahg> jdstrand: yeah I figured why not
[05:15] <jdstrand> k
[05:15] <jdstrand> good cal
[05:15] <jdstrand> call
[05:15] <jdstrand> we have time before the next publisher run
[05:16] <jdstrand> micahg: so, at this point, I think I'm gonna had out
[05:16] <jdstrand> head
[05:16] <micahg> jdstrand: k, thanks, I'm hoping the script lets me copy, if not, I'll get someone else to do it
[05:17] <jdstrand> micahg: afaic, once you unembargo, you can wait til the morning for the USN
[05:17] <jdstrand> micahg: if you want
[05:17] <micahg> jdstrand: k, thanks
[05:18] <jdstrand> micahg: the unembargo script will copy from that ppa. the overrides won't be right, but I can adjust those in the morning
[05:18] <jdstrand> micahg: you'll have archive admins coming online soon too
[05:18] <micahg> jdstrand: k, yep
[05:18] <jdstrand> (other ones)
[05:18] <jdstrand> micahg: good night. sorry this all fell on you, but good job handling it
[05:19] <micahg> jdstrand: no problem, thanks, good night to you too, and thanks for helping with the testing
[05:19] <jdstrand> sure thing
[05:44] <kees> micahg: yeah, excellent work on this.
[05:44] <micahg> kees: thanks :)
[05:48] <micahg> kees: and thanks to you and mdeslaur for the server testing
[05:49] <kees> micahg: sure thing! I'm glad I got to learn more of the auto-update internals. :)
[13:36] <chrisccoulson> hmmm, chromebug time
[13:42] <fta2> uh?
[13:43] <fta2> you mean breakpad time? ;)
[13:50] <chrisccoulson> heh :)
[13:52] <chrisccoulson> lol, i see i've finally taken over nearly all of the i386 builders!
[14:04] <fta2> damn, i thought it was already christmas :P
[14:17] <chrisccoulson> m_conley, http://bazaar.launchpad.net/~chrisccoulson/messagingmenu-extension/me-fixes/revision/54 \o/
[14:17] <chrisccoulson> we can turn the indicator on and off now :)
[14:18] <m_conley> chrisccoulson: hooray!  Thanks! :)
[14:18] <m_conley> chrisccoulson: almost ready for that pull request?
[14:18] <chrisccoulson> m_conley, yeah, pretty much
[14:19] <chrisccoulson> i wanted to move the preferences in to the main pref window as well, but i guess that can wait for now
[15:21] <chrisccoulson> finally - https://launchpad.net/~mozillateam/+archive/firefox-stable/ \o/
[15:29] <chrisccoulson> m_conley, https://code.launchpad.net/~chrisccoulson/messagingmenu-extension/me-fixes/+merge/65678
[15:29] <chrisccoulson> there's quite a bit to review ;)
[15:41] <m_conley> chrisccoulson: i've had worse.  ;)
[15:41] <chrisccoulson> heh :)
[15:41] <m_conley> chrisccoulson: I like the logging business you did.  That's cool.  Will remember.
[15:41] <chrisccoulson> m_conley, i copied that from the AddonManager code ;)
[15:42] <chrisccoulson> it's quite useful
[15:42] <m_conley> chrisccoulson: no doubt
[15:42] <m_conley> chrisccoulson: no more dump statements for me. :)
[15:42] <chrisccoulson> heh
[15:42] <chrisccoulson> i think the AddonLogging code uses dump(), but it adds a prefix to the message as well
[15:43] <chrisccoulson> and you don't have to worry about log levels
[15:44]  * m_conley nods
[16:19] <chrisccoulson> micahg, so, the strict Breaks: doesn't have the desired effect btw
[16:19] <chrisccoulson> it *does* prevent you from installing incompatible language packs alongside firefox
[16:19] <chrisccoulson> but......
[16:20] <chrisccoulson> ....when we get version skew between arches, apt tries to deselect firefox to upgrade the language pack :/
[16:20] <chrisccoulson> which is not what we want on nightly builds, where that will happen frequently :)
[17:47] <fta> chrisccoulson, do you have a minute?
[17:48] <chrisccoulson> fta, yeah
[17:48] <fta> chrisccoulson, remember me project called flappy? a daemon running on desktops triggering actions for online->offline->online transitions
[17:48] <chrisccoulson> yeah
[17:48] <fta> it supports notifications, i want to add an app indicator, with a menu
[17:49] <fta> everything i read requires a gtk main loop
[17:49] <fta> (it's all in pure C)
[17:49] <fta> -me+my
[17:50] <fta> as it's a daemon, it runs in the background, auto-started with the destop, i can't easily have another main loop
[17:51] <fta> for the app indicator, i can an icon, changing color depending on the flappy status, and a menu providing some stats & actions
[17:51] <fta> not sure how to do that
[17:52] <chrisccoulson> fta - i think you'll at least need to run the glib event loop (as the dbus stuff uses that quite extensively)
[17:53] <fta> do you know of an example i can look at?
[17:54] <chrisccoulson> but if you don't actually want to run the event loop with gtk_main or g_main_loop_run, you could spin the event loop manually (using g_main_context_iteration)
[17:54] <chrisccoulson> i think that would work
[18:01] <fta> last time i developed with gtk was 10y+ ago :P
[18:06] <chrisccoulson> heh :)
[18:09] <fta> i'm not even sure i want to mess with my own event loop, it already pretty hairy
[18:09] <fta> +'s
[18:12] <fta> i should probably do that in a thread
[19:53] <chrisccoulson> woohoo, i've moved all my work mail and filters to tbird now
[19:53] <chrisccoulson> i don't have to have 2 e-mail clients open any more \o/