[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/


[09:57] <amitk> zul: Do you want me to pull both commits since 0a7ecab0094bf5b59586eb8e2a2071c1740eba9a?
[10:09] <arooni__> zomg so many updates today for gutsy..... what changeD?
[03:16] <zul> oooh..
[03:16] <zul> you might want to change that
[03:16] <BenC> oops
[03:16] <amitk> :-D
[03:16] <zul> need more coffee BenC?
[03:17] <BenC> wonder where the extra 'e' after /m came from
[03:18] <BenC> glad I only use that password here :)
[03:18] <zul> hehe
[05:10] <evand> Can someone take a look at bug 139453?  mjg59 suspects it's a kernel issue, rather than usplash.
[05:10] <ubotu> Launchpad bug 139453 in usplash "colors are left on the screen after blanking with usplash enabled" [High,Triaged]  https://launchpad.net/bugs/139453
[10:20] <manchicken> Is power-management (e.g. battery levels and monitoring) a kernel issue or a user-land issue?
[10:21] <johanbr> Depends on exactly what the problem is.
[10:23] <manchicken> Problem is that both under KDE and GNOME I get the power management programs telling me that I'm switching onto or off of AC power incorrectly.
[10:23] <manchicken> Also, much of the time on battery power the program is either reporting no power on the battery incorrectly.
[10:24] <manchicken> Also, my machine doesn't seem to want to come back from suspend to RAM, so that's another problem.
[10:27] <manchicken> I'm guessing that since I'm running Gutsy that System76 isn't going to be all that interested in helping, so I'm trying to find someone who might be able to sort the problem out.  I'm guessing that the power-management problems may be in HAL or maybe dbus (not sure how the power-management programs fetch their data), but I'm pretty sure that the suspension issue is ACPI/kernel related.
[10:27] <manchicken> allee: What's going on?
[10:31] <allee> manchicken: hey! dadchecken.
[10:32] <manchicken> Howdy :)
[10:33] <manchicken> brb, gotta call the fire dept
[10:34] <allee> manchicken: oh :)
[10:34] <JanC> manchicken: I guess you can ask/inform the system76 guys, as I guess they _will_ be interested to have working equipment to sell, even after the gutsy release  :)
[10:34] <manchicken> Yeah
[10:36] <bdmurray> manchicken: so many questions. ;) You could look at /proc/acpi/battery/BAT0/[state|info]  to see what the kernel says about your battery
[10:37] <manchicken> True.  I'll get into more of that once I'm done dealing with this real-life fire.
[10:37] <manchicken> brb.
[11:02] <johanbr> manchicken: Try looking at the files in the /proc/acpi directory. If the information there is incorrect, it's a kernel issue.
[11:16] <manchicken> So that sucked.  Anyway, I'll take a look at /proc/acpi
[11:18] <manchicken> I am getting some weirdness.
[11:19] <manchicken> Sometimes it says charged but has "unknown" for present rate or remaining capacity.
[11:19] <manchicken> Now it says I'm charging, but the cord is most certainly disconnected.
[11:19] <manchicken> So that sounds like a kernel issue then?
[11:20] <manchicken> The temperature seems a bit off, too.  It's switching back and forth between 5 C and 48 C
[11:31] <JanC> 5 & 48 C you mean  ;)
[11:31] <JanC> but that sounds quite wrong indeed
[11:32] <JanC> I have seen some weird things underfeisty a couple of times, but couldn't reproduce it
[11:34] <manchicken> Yea
[11:34] <manchicken> I'm just putting what the file had in it :)
[11:35] <manchicken> The power management and suspension stuff is really impacting me negatively though.
[11:35] <manchicken> Right now it's telling me that it's going to take 27 hours to charge my battery, which I'm pretty sure is wrong.
[11:36] <manchicken> I'm guessing System76 doesn't have any IRC channels though.
[11:36] <bdmurray> manchicken: you'll want to submit a bug report regarding the kern then
[11:37] <bdmurray> kernel even
[11:37] <manchicken> Okie dokie.
[11:37] <bdmurray> and attach a tarball of /proc/acpi
[11:37] <bdmurray> in addition to the the kernel teams minimum bug requirements
[11:38] <manchicken> Where might I find those?
[11:38] <manchicken> (the minimum requirements that is)
[11:39] <bdmurray> http://wiki.ubuntu.com/KernelTeamBugPolicies or something close to that
[11:39] <manchicken> Much thanks.
[11:40] <manchicken> I'll try to either post to an existing report or post a new one.
[11:40] <bdmurray> No problem
[11:52] <manchicken> This is interesting.
[11:53] <manchicken> In syslog I get very unusual keycode error messages reported whenever I unplug or plug in the AC adapter.
[11:54] <bdmurray> I imagine your BIOS is up to date
[11:54] <manchicken> bdmurray: I'm unaware of how to change or check such a thing.  I'm guessing System76 would give me such an update over their repository.
[11:56] <manchicken> If my situation only somewhat resembles that of another bug, should I just add my addition to that bug report, or should I post a new bug report and cite that it is similar to another?
[11:58] <bdmurray> manchicken: Your bug sounds very hard specific and so the best idea is to submit a separate bug report
[11:58] <bdmurray> and mention that it is similar
[11:58] <bdmurray> s/hard/hardware/
[11:59] <manchicken> Righto.
[11:59] <manchicken> I'm also emailing System76 support.
[12:09] <manchicken> Bug #139701 reported.
[12:09] <ubotu> Launchpad bug 139701 in linux-source-2.6.22 "Under Gutsy on System76 Darter, battery state information is often incorrect." [Undecided,New]  https://launchpad.net/bugs/139701
[12:17] <bdmurray> manchicken: that bug report looks great - thanks
[12:19] <manchicken> Not a problem.  I hope it helps someone fix a problem :)


[19:13] <smoser> harlowja, i'm confused
[19:13] <smoser>  python -c 'import argparse; print(argparse)'
[19:13] <smoser> <module 'argparse' from '/usr/lib/python2.7/argparse.pyc'>
[19:13] <harlowja> ya, but pkg_resources is not finding it :-/
[19:13] <harlowja> and/or redhat didn't register it right or something
[19:13] <smoser> ah.
[19:13] <smoser> now i see.
[19:13] <smoser> python2.6
[19:14] <smoser> its new in 2.7
[19:14] <harlowja> ya
[19:14] <harlowja> i think redhat probably messed up there argparse package
[19:14] <harlowja> or forgot to register it with pkg_resources or something
[19:14] <smoser> ?
[19:15] <harlowja> https://bugs.launchpad.net/cloud-init/+bug/1603533
[19:16] <harlowja> seems like 'needed = self.resolve(parse_requirements(requirements)) ' wouldn't fail if argparse was registered
[19:16] <harlowja> but meh, also fixes it by just not listing it as a dep in 2.7+
[19:16] <harlowja> smoser other question
[19:16] <smoser> right.
[19:17] <harlowja> any opposition to https://gist.github.com/harlowja/50a66fb9bed6e0897f1691eae3107f01
[19:17] <harlowja> on cent7 there is like no content (at least in my cloudinit) in /var/log/cloud-init.log
[19:17] <harlowja> and journalctl doesn't have anything
[19:18] <smoser> so it actually fails to go to syslog ?
[19:18] <harlowja> think so
[19:19] <harlowja> now i did see the following in a redhat patch
[19:19] <harlowja> https://gist.github.com/harlowja/275e35b41cd268d869b7b503d7f654d7
[19:19] <harlowja> so that might fixs it
[19:19] <harlowja> don't think that one was upstreamed :(
[19:19] <harlowja> let me just try that fix; see what happens
[19:19] <smoser> hm.
[19:19] <harlowja> (gotta get these damn redhat folks to stop having secret patches, lol)
[19:20] <harlowja> bbiab though, lunch
[21:38] <harlowja> smoser whats weird though is that even if i use that patch (which does help) it still doesn't write debug stuff to that log file
[21:38] <harlowja> so then it makes me question the value of that syslog stuff in the first place
[21:38] <harlowja> or maybe the sysconfig stuff is just busted, lol
[21:38] <harlowja> *syslog i mean
[21:39] <harlowja> for example when working on my godaddy module, this is all the debug in the logs, lol
[21:39] <harlowja> https://gist.github.com/harlowja/56b2b5109bbbd4b3441cda43a5617107
[21:39] <harlowja> not so useful :-P
[21:40] <harlowja> i'd rather have old-janky file that actually works :-P
[21:46] <harlowja> soooo, if we defaulted to just the file stuff smoser would that be ok
[21:46] <harlowja> at least its dependable :-P
[21:47] <harlowja> i'll probably do that locally anyway, pita having this thing not show anything


[08:54] -queuebot:#ubuntu-ci-eng- jamespage, https://bileto.ubuntu.com/#/ticket/3694 Ready to build
[15:35] -queuebot:#ubuntu-ci-eng- sil2100, https://bileto.ubuntu.com/#/ticket/3754 Ready to build (zesty/cargo, zesty/rustc). UNAPPROVED queue (xenial/cargo, xenial/rustc)
[15:54] -queuebot:#ubuntu-ci-eng- sil2100, https://bileto.ubuntu.com/#/ticket/3754 DONE queue (xenial/cargo, xenial/rustc). Ready to build (zesty/cargo, zesty/rustc)
[23:19] -queuebot:#ubuntu-ci-eng- xnox, https://bileto.ubuntu.com/#/ticket/3755 No packages are being considered! If you are preparing sources manually, please upload them to the PPA now
[23:36] -queuebot:#ubuntu-ci-eng- xnox, https://bileto.ubuntu.com/#/ticket/3755 Needs rebuild due to burned version number


[07:58] <zzarr> hello!
[08:57] <anpok_> tjaalton: hm I am trying your vulkan binaries..
[08:57] <anpok_> and I have a problem within X ..
[08:57] <anpok_> vkcube and other examples I pulled complain that there is no DRI3 support..
[08:57] <anpok_> but I actually rebuilt the most recent intel xorg video driver .. enableing dri2 in debian/rules..
[08:58] <anpok_> did I miss a step?
[08:58] <anpok_> dri3 of course..
[08:58] <anpok_> stuff runs fin on top of drm/kms though
[08:59] <anpok_> zzarr: any news form your endevaours?
[09:01] <zzarr> anpok_, it's hard to understand what parts of the kernel I need to make an Android container work/run
[09:01] <anpok_> .. write a detailed description when you figure that out..
[09:02] <anpok_> i want to try that too next time i get some more free time..
[09:03] <zzarr> right now it's more like if I figure it out
[09:03] <anpok_> :)
[09:04] <zzarr> is there a more detailed block diagram of the kernel/libhybris and all of it?
[09:08] <zzarr> anpok_, what would be the best approach? trying with the Android driver or wrap the freon driver?
[09:12] <zzarr> if the question is not clear by wrapping the freon driver I mean making a Mir-server that runs on top of freon
[09:15] <anpok_> zzarr: well you need to solve the problem of transfering a rendering result from a client to the server.. if the freon driver has capabilities to do that - then this will be the more intersting approach because you get to write some code..
[09:16] <tjaalton> anpok_: you missed reading the ppa description :)
[09:17] <anpok_> my (maybe outdated?) understanding of the chrome os rendering system is that they only have a single process doing the actual rendering with the gpu driver.. the other processes just use an inter process version of GLES/EGL and maybe some 2D drawing library
[09:18] <zzarr> anpok_, I think so too I would get a much deeper knowledge and it would work on any Chrome OS device (Intel/ARM alike)
[09:18] <anpok_> zzarr: but yeah that would also be an interesting integration task.. let USC do all the rendering..
[09:18] <anpok_> tjaalton: yeah I am good at that
[09:20] <zzarr> anpok_, I'm still not familiar with all the terms, what does USC stand for *feeling like I should know*
[09:20] <anpok_> unity-system-compositor the system compositor in the default ubuntu touch setup
[09:20] <anpok_> usually the thing that posts to screen
[09:21] <zzarr> anpok_, okey
[09:21] <anpok_> with kms/android drivers it just posts the buffer of the nested server to screen
[09:21] <anpok_> so it is a process that runs a mirserver
[09:22] <zzarr> anpok_, is that a good approach here too?
[09:23] <anpok_> what do you refer to:
[09:23] <anpok_> ?
[09:25] <anpok_> ah you mean having usc there too ..
[09:26] <anpok_> yes you need something with the necessary permissions to access the gpu.. and the screen.. and you want to allow as processes as possible
[09:26] <anpok_> thats actually even safer than with kms/android drivers..
[09:31] <zzarr> anpok_, good call
[09:32] <anpok_> *as few processes
[09:37] <zzarr> anpok_, could you help me figure out  where to start? (I'm still new to graphics in general)
[09:38] <anpok_> hm first I would try to figure out where and how chrome os sets up rendering with the drivers you have..
[09:38] <anpok_> then try to get that workin outside of chrome os..
[09:39] <anpok_> then take that as a basis for a mir graphics platform
[09:39] <zzarr> anpok_, Is the lack of console a problem or is that bypassed if I get freon running?
[09:40] <anpok_> hm no i do not think so..
[09:41] <anpok_> it might just make stuff harder to try out :)
[09:42] <zzarr> I have a kernel with console right now, so I don't think that would hinder anything
[09:51] <anpok_> i guess figuring those things out will keep you busy for a while ... then you have to look into getting the IPC services working..
[09:51] <anpok_> and after that you might have to make some changes to mir to get all of that working as a graphics platform
[09:51] <zzarr> IPC?
[09:51] <anpok_> interprocess communication
[09:52] <zzarr> okey, yes
[09:52] <anpok_> http://www.chromium.org/developers/design-documents/displaying-a-web-page-in-chrome
[09:52] <zzarr> thanks anpok_
[09:52] <anpok_> https://sites.google.com/a/chromium.org/dev/developers/design-documents/gpu-accelerated-compositing-in-chrome..
[09:53] <anpok_> oops
[09:53] <anpok_> strip the last two dots
[09:57] <zzarr> thanks again :-)
[09:58] <zzarr> anpok_, the second link is a bit outdated, (Chrome OS used X back then, and Freon as of Q3/Q4 last year)
[10:00] <anpok_> tjaalton: yay works..
[10:04] <anpok_> tjaalton: oh.. those demos at //github.com/SaschaWillems/Vulkan.git make the i915 reset the gpu in various ways..
[10:06] <zzarr> anpok_, it's hard to find any info about how freon works
[10:08] <zzarr> anpok_, this might be interesting https://sites.google.com/a/chromium.org/dev/developers/design-documents/ozone
[10:14] <zzarr> Vulkan looks nice
[10:16] <alan_g> alf_: I'd like your eyes on this (as you wrote the original). I tried reverting the associated changes and this appeared reproduce the original failure, but it was hardly a clean merge so I can't verify I've captured the intent: https://code.launchpad.net/~alan-griffiths/unity-system-compositor/rework-DeadlockLP1491566/+merge/286698
[10:18] <tjaalton> anpok_: which cpu?
[10:21] <alf_> alan_g: ack, I will take a look
[10:23] <anpok_> tjaalton: i7-4750HQ .. so haswell iris 5200
[10:24] <tjaalton> anpok_: hmm might be a known issue then
[10:25] <anpok_> there is an incomplete support warning on startup of each demo..
[10:26] <anpok_> zzarr: hm there was a mir port of that one once -- running ozone as a mir client -- not what you need as far as i can tell..
[10:27] <tjaalton> yeah, the driver is in flux and moving stuff around upstream, so i haven't bothered updating it yet
[10:58] <zzarr> anpok_, I guess that I could have a look at that but only to get a general feel
[12:17] <zzarr> anpok_, is there an picture or description how the components communicate in Mir?
[12:20] <zzarr> I have found this, what parts don't I need? http://i1-linux.softpedia-static.com/screenshots/Mir_1.png
[12:20] <zzarr> If I ported QtMir and QtUbuntu, would that be enough?
[12:21] <alan_g> zzarr: as it port them to something other than Mir?
[12:21] <zzarr> or is it everything below libhybris?
[12:22]  * alan_g should probably read backchat
[12:22] <zzarr> I guess I was thinking a bit wrong
[12:23] <zzarr> I should have the freon driver in the position where libhybris is now
[12:25] <anpok_> probably..
[12:26] <anpok_> there is no nice colorful picture that guides you through the source code
[12:26] <anpok_> you will have to provide an implementation of the mir::graphics::Platform interface
[12:28] <zzarr> anpok, the image I found as well as knowing that the interface mir::graphics::Platform is a colorful image ;-)
[12:29] <alan_g> zzarr: does this help? https://bazaar.launchpad.net/~mir-team/mir/development-branch/view/head:/design/Architecture.dia (You need dia to view it)
[12:33] <zzarr> I was about to install dia from the repository... but I could not... it says that it don't know about a package called "dia-gnome-gnome-gnome-gnome"... I suspect I know why
[12:41] <zzarr> alan_g, nice diagram


[00:02] <tormod> I am uploading an xorg-server to build against that mesa build now - reality check
[00:10] <pwnguin> does X autodetect work with only USB?
[00:13] <tjaalton> pwnguin: AIUI yes
[00:13] <pwnguin> tabletPCs commonly connect via tty, I had thought perhaps the X autodetect stuff might do away with the need for tabletPC =(
[00:13] <pwnguin> err
[00:14] <pwnguin> do away with xorg.conf for tabletPC
[00:14] <pwnguin> well, its good to know that at least it works for usb tablets
[00:15] <tjaalton> X only knows what hal knows
[00:16] <tjaalton> so if it can be set up so that hal knows about it before the server is started, it should work?
[00:16] <pwnguin> ok, so x does talk with hal
[00:16] <pwnguin> it's never worked for me =(
[00:17] <pwnguin> i'll bring it up with toshiba-tablet
[00:18] <tjaalton> it talks with hal to see if there are devices that match some keys
[00:18] <tjaalton> or something like that..
[00:18] <tjaalton> so you need to have fdi files to set up the values
[00:18] <pwnguin> right
[00:19] <pwnguin> one of the HAL maintainers works with suse
[00:19] <pwnguin> and tablets
[00:20] <pwnguin> I need to find some good resources on HAL -- nothing I've found quite hits everything I need to know
[00:20] <tormod> tjaalton: so mesa seemed to build fine once I added --disable-glut to the swx11 confs in debian/rules.
[00:21] <tjaalton> tormod: but that would mean that glut is not built at all
[00:21] <tormod> was it build before?
[00:21] <tjaalton> it builds here.. maybe it needs something else. or do you mean amd64
[00:22] <tormod> what builds? my ppa source which already had --disable-glut?
[00:22] <tormod> no I am not talking about the amd64 failure, I am clueless there
[00:22] <tjaalton> tormod: no the one from git, builds locally
[00:23] <tjaalton> what's the error wit glut?
[00:24] <tormod> first it needed libxmu-dev and libxi-dev to satisfy configure
[00:26] <tormod> then http://launchpadlibrarian.net/15797046/buildlog_ubuntu-hardy-i386.mesa_7.1.0~git20080703.b3e1f9bd-0ubuntu0tormod2_FAILEDTOBUILD.txt.gz - seems like missing XInput.h etc
[00:26] <tormod> all this was not needed before the autotools change
[00:29] <tormod> now xorg-server build fails because dri2 needs GL/internal/dri_sarea.h (wonder what "internal" means)
[00:29] <tjaalton> use --disable-dri2
[00:29] <tjaalton> no point in building that
[00:29] <tjaalton> since libdrm does not support ttm
[00:30] <tjaalton> 2.3.1 that is
[00:30] <tormod> libdrm git?
[00:30] <tormod> or I need a special branch
[00:30] <tjaalton> modesetting
[00:30] <tjaalton> yes
[00:30] <tormod> it built fine before (although it probably was useless)
[00:30] <tjaalton> don't know if the gem-branch would do
[00:31] <tjaalton> there should be checks now to disable dri2 if libdrm was too old
[00:31] <tormod> thanks, I'll wait for that to land on trunk
[00:31] <tjaalton> heh
[00:32] <tormod> yes I saw that xorg-server commit, didn't seem to kick in here
[00:32] <tjaalton> right, GLUT seems to need xmu and xi
[00:35] <tjaalton> and it was not built before
[00:37] <tormod> re that libdrm check, maybe my git libdrm declares itself as 2.3.2?
[00:37] <tjaalton> or 2.4.0
[00:39] <tormod> looking at the source (configure.ac) it's 2.3.1. strange
[00:40] <tormod> it's 2.3.1 in libdrm.pc
[00:41] <tjaalton> ok
[00:46] <tormod> I see that 2.3.2 check in both configure{,.ac} but the build log shows it passed
[00:56] <tormod> night
[01:14] <tjaalton> sigh, too tired to do anything useful.. night
[01:15] <bryce> night
[01:18] <pwnguin> is wacom-tools installed by default now?
[01:19] <pwnguin> im not sure how to query apt to figure this out
[01:28] <bryce> I'm not sure either
[01:32] <pwnguin> i'd rather not set up a chroot just to figure out whether ubuntu-desktop draws it in
[05:41] <tjaalton> the wacom driver is installed by input-all
[09:07] <tjaalton> ouch, alpha2 next thursday..
[09:42] <tjaalton> mesa uploaded to my ppa to make sure it builds
[09:42] <tjaalton> locally it does
[09:50] <tseliot> tjaalton: why is libgl1-mesa-dev automatically installed in Intrepid?
[09:55] <tseliot> tjaalton: I'm asking because nvidia-glx-<version>-dev will need to remove "libgl1-mesa-dev", together with "mesa-common-dev"
[09:56] <tjaalton> tseliot: it shouldn't be automatically installed
[09:57] <tjaalton> at least the reverse-depends don't show anything suspicious
[09:58] <tseliot> tjaalton: sorry, I meant the "Automatically installed: yes" when you do aptitude show package
[09:58] <tjaalton> tseliot: some package that you installed pulled it in
[09:58] <tseliot> Yes, I had figured that out, no problem then
[09:59] <tjaalton> funny that in hardy nvidia*dev _depend_ on libgl1-mesa-dev
[09:59] <tjaalton> are the packages going to be named nvidia-glx-VER?
[10:00] <tjaalton> I'm just confused about where we are at the moment :)
[10:00] <tjaalton> right, mesa build failed on amd64
[10:06] <tseliot> tjaalton: honestly I don't know why it depends on libgl1-mesa-dev in Hardy
[10:06] <tseliot> as regards the names, they will be nvidia-glx-177, nvidia-glx-173, etc.
[10:10] <tjaalton> ok
[10:11] <tseliot> I will show you the source as soon as the packages are finished
[10:14] <tjaalton> I don't think I have anything to add :)
[10:14] <tjaalton> since I've been away for a couple of weeks etc
[10:14] <tjaalton> you are so much ahead on this
[10:15] <tjaalton> I almost sent an email to the debian folks about how they are planning on resolving the issues, but didn't
[10:16] <tseliot> honestly, I don't know if we'll ever manage to have our changes integrated in debian
[10:16] <tjaalton> right
[10:16] <tjaalton> so it doesn't matter if we diverge
[10:16] <tjaalton> even further
[10:16] <tseliot> yes
[10:17] <tseliot> shall I still keep the unused files and folders?
[10:17] <tseliot> the ones from the merge, I mean
[10:20] <tjaalton> nah, feel free to clean it up as you see fit
[10:20] <tseliot> ok :-)
[10:21] <tjaalton> when do you expect to have them ready for upload?
[10:22] <tjaalton> for alpha2?
[10:23] <tseliot> Driver 177 is ready i.e. it installs, uninstalls, replaces the old packages with no problems. I'll have to install Intrepid (32 and 64bit) on a real machine so as to see if the driver loads. Currently I'm testing the packages in virtualbox
[10:23] <tseliot> I have to apply a few changes to driver 173, 96, 71
[10:23] <tseliot> and test them all
[10:24] <tseliot> when is alpha 2 due?
[10:24] <tjaalton> next thursday
[10:24] <tjaalton> so the packages should be ready by tuesday..
[10:25] <tseliot> even if the packages were ready by tuesday, the rest wouldn't be ready
[10:25] <tseliot> i.e. the kernel postinst.d hook, etc.
[10:25] <tseliot> I'm working on it ;)
[10:26] <tjaalton> ok, take your time
[10:50] <tjaalton> unexporting LDFLAGS seems to do the trick for mesa amd64 build
[11:17] <tjaalton> ok, will upload mesa no
[11:17] <tjaalton> *now
[11:55] <tjaalton> bryce: xorg-server uploaded too. when it's built we can start uploading drivers as -Xbuild1


[19:38] <valorie> hmmm, I can't login to the website
[19:38] <valorie> need to get that article into News, but can't login
[19:40] <valorie> @sick_rimmit @rikmills @ahoneybun anyone know what's up?
 what are you trying to do?
 kubuntu.org/admin
 Hmmm, am afk at present can take a look in about an hour
[19:46] <valorie> perfect, that worked
[19:46] <valorie> thank you @ahoneybun
[19:46] <valorie> I need to put the testing article online
[19:47] <valorie> https://docs.google.com/document/d/1PVui1kB1JijGCoBPdkrg4P94LS4DozLtEJ37GKWga2E <-- written in conjunction with the other flavors
 \o/
[19:52] <valorie> https://kubuntu.org/?p=4384&preview=true
[19:52] <valorie> anyone available to fix the links?
[19:52] <valorie> I don't even see the editing tools
[19:52] <valorie> gosh, using chrome, no idea what's missing today
[20:05] <mparillo> There used to be a login link at the bottom of https://kubuntu.org/ so you could log in to Wordpress. Did it disappear in some of the website beautification?
[20:09] <mparillo> Oh, got it...you need the magic URL supplied above. And the page is locked right now.
[20:11] <valorie> I forgot to logout
[20:11] <valorie> have done so now
[20:11] <valorie> this pandemic tension is getting to me
[20:18] <valorie> mparillo: were you able to get in now?
[20:18] <mparillo> The link to the iso.qa.ubuntu.com points to the daily builds, but the Beta build test milestone is not up yet. The other link to the daily ISO is good.
[20:18] <valorie> might be fun to embed that video but in WP that is quite beyond me
[20:19] <valorie> imo there is no more "beta"
[20:19] <valorie> it's all dailies
[20:19] <valorie> we just call it beta test week because there used to be an actual beta
[20:19] <valorie> maybe they will do one this time because LTS
[20:19] <valorie> but I've not heard that
[20:20] <valorie> @RikMills might know more
[20:20] <mparillo> Ahh, in the past there was a separate testing series. In that case, both URLs look good.
[20:20] <valorie> have to say that my kubuntu work has not been top prio lately
[20:20] <valorie> you're right, but I guess if there is we can go in and change the URL?
[20:21] <valorie> I'd like people to get their VMs set up, etc.
[20:21] <mparillo> As does the youtube link
[20:21] <valorie> \o/
[20:21] <valorie> thank you for your magick, mparillo
[20:22] <valorie> how are you doing in this strange new world we all now inhabit?
[20:22]  * valorie is getting cabin fever
[20:22] <jphilips> if you need any help valorie, i'd be glad to help embed the video into the page for you
[20:23] <mparillo> All I did was verify the links. They are bare URLs which some might say are ugly, but they have the advantage of being easy to inspect. jphilips go for it, I have exited.
[20:23] <valorie> jphilips: thank you!
[20:23] <valorie> jphilips: do you have the permissions?
[20:23] <jphilips> valorie: i would need access of course :D
[20:23] <valorie> I don't know how to grant access
[20:23] <valorie> @ahoneybun do you know?
[20:24] <valorie> wp is just sucky to me, and ours is like last century
[20:25] <jphilips> i presume it would be https://launchpad.net/~kubuntu-website-administrators
[20:25] <jphilips> thats how it was for xubuntu
[20:25] <jphilips> but if @ahoneybun is around, i presume he would know how to fix it up
[20:26] <jphilips> i've request to join the kubuntu website admins
[20:26] <jphilips> alot of admins are there - https://launchpad.net/~kubuntu-website-administrators/+members
[20:26] <jphilips> RikMills: got time to help with posting the announcement?
[20:28] <valorie> gosh
[20:28] <valorie> done
[20:28] <valorie> <--- DUH
[20:37] <valorie> jphilips: feel free to publish if it looks ready
[20:37] <valorie> I'll write to the lists and tweet
[20:37] <valorie> maybe put it on FB....(ugh)
[20:38] <valorie> mparillo: unless you want to do the social things and I write to the lists?
 That is how you can login to the site valorie
[20:42] <valorie> right, thus my DUH
[20:43] <valorie> how are you, Aaron?
[20:56] <jphilips> valorie: dont have access to do so, so you'll have to do it :D
[20:56] <valorie> ok
[20:56] <valorie> so it's ready to go?
[20:57] <valorie> I see no embedded video
[20:58] <valorie> and the links are not clickable
[21:01] <valorie> nevermind, making the links clickable and people will just have to click on it
[21:05] <valorie> done
[21:05] <valorie> https://kubuntu.org/news/testing-for-the-beta-help-needed/
[21:05] <valorie> please spread and report back here where you have shared
[21:11] <jphilips> let me know when its tweeted out so i can retweet it
[21:12] <valorie> devel and user done
[21:13] <jphilips> you should likely make the #ubuntu-quality clickable
[21:14] <jphilips> here's the link - https://webchat.freenode.net/#ubuntu-quality?nick=kbuntu-tester?w
[21:14] <jphilips> sorry - https://webchat.freenode.net/#ubuntu-quality?nick=kubuntu-tester?w
[21:15] <valorie> dunno how to do that, jphilips
[21:15] <valorie> I can barely manage to make bare links clickable
 @valorie, I'm good just working from home.
[21:15] <jphilips> RikMills, @ahoneybun: can either of you guys add the link
[21:16] <valorie> @ahoneybun stay safe and happy
[21:17] <valorie> @ubuntu @Xubuntu, @UbuntuStudio, @LubuntuOfficial, @Ubuntu_Kylin, @Ubuntu_MATE, @UbuntuBudgie <-- did I leave anyone's twitter out?
[21:19] <valorie> https://twitter.com/kubuntu/status/1243286387366846464 done
 It looks like someone pushed it.
[21:26] <jphilips> retweeted
[21:27] <jphilips> you can retweet the ubuntu studio tweet if a few hours - https://twitter.com/ubuntustudio/status/1243218023898472449
[21:27] <jphilips> tweet in* a few
[21:31] <valorie> I usually logout from kubuntu and then retweet some from my personal
[21:32] <valorie> which I'm doing now
[21:36] <mparillo> Facebook and https://www.reddit.com/r/Kubuntu/comments/fpk6u1/testing_for_the_2004_beta_help_needed/
[21:36] <valorie> \o/
[21:36] <valorie> mparillo: <3
[21:37] <mparillo> Looks as if nobody has done Twitter from the Kubuntu account, right?
[21:37] <valorie> commented and upvoted
[21:37] <valorie> yes I did twitter
[21:37] <valorie> https://twitter.com/kubuntu/status/1243286387366846464
[21:38] <valorie> and RT'd all the other flavs I saw
[21:38] <valorie> masto?
[21:39] <valorie> hmm, which FB did you do?
[21:39] <valorie> there are like three
[21:39] <valorie> which is unfortunate
[21:39] <mparillo> Strange. I can follow your link, but when I look at the Kubuntu Tweets in a list I cannot see it.
[21:39] <valorie> I'll post on https://www.facebook.com/linuxkubuntu/
[21:40] <valorie> hmmm
[21:40] <mparillo> I think I saved them somewhere on phab
[21:40] <valorie> well, it was a half hour ago
[21:42] <valorie> ah, a "visitor post"
[21:42] <valorie> gosh fb sucks
[21:43] <mparillo> According to this (https://phabricator.kde.org/w/kubuntu/social-media/) I must have posted to the kubuntu.org FB account
[21:44] <valorie> cool
[21:44] <valorie> well, commented on two pages and one group
[21:45] <valorie> now I feel all dirty
[21:45] <valorie> lol
[21:45] <mparillo> I use a live USB, and probably have not been on FB since 19.10
[21:46] <valorie> well I use it for some genealogy groups and to see photos of my grandson
[21:46] <valorie> twitter is better
[21:46] <jphilips> might want to remove google+ from that page :D
[21:47] <valorie> even that gets me down after 20 minutes
[21:47] <valorie> what page, jphilips?
[21:47] <valorie> I thought we purged that everywhere
[21:47] <jphilips> phabricator page
[21:47] <valorie> ah
[21:47] <valorie> hm
[21:48] <jphilips> would be good to post also on the kubuntu forums
[21:48] <valorie> done, thanks
[21:49] <valorie> hmmm, I wonder if they fixed my login yet
[21:49] <valorie> and why isn't that in our phab
[21:49] <valorie> sheesh
[21:51] <mparillo> In general, we were using that phab page for semi-official accounts, not personal ones. Or is there a semi-official Kubuntu account on KFN?
[21:53] <valorie> true that
[21:53] <valorie> nope
[21:53] <valorie> but my personal one - I couldn't login for awhile even though I paid
[21:55] <jphilips> got the link to the forum post, as i cant find it
[22:03] <RikMills> sorry. a little distracted today
[22:03] <RikMills> hope things are sorted
[22:07] <jphilips> the IRC link on the page still needs to be added
[22:10] <valorie> sheesh, finally able to login to kubuntuforums
[22:11] <mparillo> I think they had a spam problem a few years ago, and they fought back, making the site just too difficult for me afterwards.
[22:20] <valorie> ok, posted
[22:20] <valorie> gosh, lots of hoops to jump through there
[22:26] <jphilips> guess you guys dont do this that often :D
[22:29] <valorie> well, not a full-court press
[22:29] <valorie> twice every six months I guess
[22:30] <valorie> and I dunno about you, but to me every day now seems like a week
[22:30] <valorie> every week like a month
[22:30] <valorie> and I can hardly remember "normal"
[22:30] <valorie> and like SEEING PEOPLE
[22:31] <jphilips> well you have gsoc students to deal with, so definitely it must be stressful
[22:31] <jphilips> have a good night all and stay safe
[22:34] <valorie> I just heard we have new proposals, so yeah
[22:34] <valorie> my fun stuff keeps getting shoved to around midnight
[22:34] <valorie> not very good for my sleep!


[05:26] <zequence> Thanks. Yes, it was nighty nighty time for me yesterday :)
[09:11] <dbarth> hiya
[09:11] <dbarth> sil2100: and i have a problem with some packages stuck in a silo not flowing in the archive because of the recent freeze i guess
[09:12] <dbarth> namely: unity-webapps, webbrowser-app, libunity-webapps
[09:17] <sil2100> Hi release team! Yes, it's
[09:17] <sil2100> I mean...
[09:17] <sil2100> Yes, it's something that is required for touch development, and we would be grateful if those could be pushed forward :)
[09:20] <Laney> They're being held becuse they are on other seeds than just touch, and there's a beta being prepared currently.
[09:21] <seb128> hey
[09:21] <seb128> what's the right place to start a discussion about "blocking things in unapproved vs blocking things in proposed"
[09:21] <dbarth> ah ok
[09:21] <seb128> the unapproved queue is creating issues for CI train (basically it means no silo/ppa can be cleaned, given back)
[09:22] <dbarth> is there a way i can just free the silo for now, while the freeze is in effect?
[09:23] <sil2100> dbarth: not right now sadly... not without hacking around the whole process
[09:23] <dbarth> how long are we talking for the freeze?
[09:23] <dbarth> depending on the timeframe
[09:24] <dbarth> maybe i should continue with the same silo but add more stuff
[09:24] <Laney> Beta is on Thursday
[09:24] <dbarth> Laney: ok
[09:24] <dbarth> so unfreeze friday or so
[09:24] <seb128> shrug
[09:24] <dbarth> then i think i'll try to keep that silo open and work in there
[09:24] <seb128> that ridiculous
[09:24] <dbarth> sil2100: works?
[09:25] <Laney> There's no unfreeze, but stuff ought not to be held
[09:25] <seb128> Laney, why can't those uploads just go to proposed if they are blocke there?
[09:26] <Laney> They aren't blocked there
[09:26] <seb128> ok, it just happens that people only review/let beta fixes through?
[09:27] <Laney> I think the idea is to have release team eyeballs on stuff before it enters the archive
[09:27] <Laney> This is what we did last cycle too, IIRC
[09:29] <sil2100> dbarth: we can do something else, let's move it to another channel
[09:29] <dbarth> sil2100: ah ok :)
[09:32] <seb128> Laney, right, that worked fine when we did have silos, now every unapproved upload coming from CI train locks a silo and we have only a limited number
[09:57] <jibel> cjwatson, there are 2 critical bugs in ubiquity bug 1297312 and bug 1296697
[09:57] <ubot2> Launchpad bug 1297312 in ubiquity (Ubuntu Trusty) "ubiquity-dm fails with: FileNotFoundError: [Errno 2] No such file or directory: '/usr/lib/x86_64-linux-gnu/indicator-application-service'" [Critical,Triaged] https://launchpad.net/bugs/1297312
[09:57] <ubot2> Launchpad bug 1296697 in ubiquity (Ubuntu Trusty) "Trusty Desktop installer crashed with "Encrypted Home" set" [Critical,Confirmed] https://launchpad.net/bugs/1296697
[09:58] <jibel> fix for 1297312 is obvious and someone proposed a patch
[09:59] <jibel> I am not sure about 1296697 because there is no swap after installation but there was none before the change to ecryptfs-utils either
[11:09] <davmor2> jibel: hey dude I've just run my update iso script and i386 and amd64 both had updates but mac version didn't is that correct?
[11:15] <jibel> davmor2, it is incorrect. latest images are 20140325.1, and there are imags for amd64+mac in http://cdimage.ubuntu.com/daily-live/current/
[11:16] <davmor2> jibel: right I'll check the checksums maybe I hit it yesterday and only the mac image had finished updating.
[11:19] <davmor2> jibel: nevermind just me I must of updated it yesterday and the other 2 not get pulled in phew :)
[11:19] <jibel> davmor2, you should really consider using dl-ubuntu-test-iso from ubunqu-qa-tools, it does all this already
[11:20] <davmor2> hi ho, hi ho, hi ho, hi ho, it's iso testing we go.....
[11:21] <jibel> davmor2, can you test uefi+sb to make sure it's covered? I don't have hw to do this.
[11:22] <davmor2> jibel: I'm just gonna hit everything so it'll confirm everything works :)   but yeah my plan was to do all the amd64 tests against my uefi+sb laptop as well as a standard box
[11:27] <davmor2> jibel: oh I can do a side by side with windows too. now I'm assuming I can get macos back on this mac to so could potentially test side by side there too I guess but I'll save that till last :)
[11:46] <davmor2> jibel: Huston we have a problem.  On my non-uefi laptop and the mac I'm greeted by a black screen rather than the ubiquity session screen this didn't happen on the image before 25.1
[11:47] <davmor2> jibel: that is i386 and amd64+mac just firing up amd64 see if it is the same
[11:47] <davmor2> jibel: and it is
[11:51] <jibel> davmor2, possibly bug 1297312
[11:51] <ubot2> Launchpad bug 1297312 in ubiquity (Ubuntu Trusty) "ubiquity-dm fails with: FileNotFoundError: [Errno 2] No such file or directory: '/usr/lib/x86_64-linux-gnu/indicator-application-service'" [Critical,Triaged] https://launchpad.net/bugs/1297312
[11:52] <jibel> davmor2, does it happen if you press shift on the boot screen and select "try ubuntu"
[11:52] <jibel> ?
[11:52] <davmor2> jibel: I shall try
[11:57] <davmor2> jibel: okay so live desktop is good so it is most likely that issue.
[11:58] <davmor2> jibel: although it's happening on i386 too so not just /usr/lib/x86_64 I guess
[12:02] <jibel> davmor2, on i386 the path would be .../i386-linux-gnu/.. but it's the same problem
[12:02] <davmor2> jibel: confirmed the lack of ubiquity across the board
[12:03] <cjwatson> jibel: right, looking
[12:04]  * davmor2 goes back to testing phone in the meantime.
[12:04] <cjwatson> infinity: we're going to need a respin for ubiquity anyway; do you think I could have my dee and geoclue uploads let through the queue at the same time?  they're fairly trivial multiarch fixes, not beta-critical or anything, but I have a really deep stack there in order to get to the point of being able to do "apt-get install ubuntu-sdk-libs-dev:armhf" in "click chroot" and it would help to be able to make progress
[12:09] <jibel> davmor2, it would be nice if you could verify uefi+sb instead, so we do not discover it is broken after next respin. just skip ubiquity-dm and boot directly to a live session.
[12:10] <davmor2> jibel: and just do an install from the live session you mean?
[12:11] <jibel> davmor2, yes
[12:11] <davmor2> jibel: no worries I'll set that up now
[12:12] <davmor2> ah nice bug
[12:15] <davmor2> jibel: on the new lock screen hit system indicator and then hit restart and watch it restart the computer even though your user is still logged in :)
[12:17] <seb128> davmor2, that has always been the case on e.g the greeter
[12:17] <davmor2> seb128: yes on the greeter when no one is logged in.  This is the lock screen though, it used to warn that a user was locked in
[12:18] <seb128> ?
[12:18] <davmor2> logged in even
[12:18] <seb128> on the greeter even when people are logged in
[12:18] <seb128> use precise or saucy, do switch user, your session is still open and you are on the greeter, shutdown
[12:18] <seb128> the box shutdowns with your user session open
[12:19] <davmor2> seb128: oh okay
[12:19] <davmor2> seb128: just not used to it happening from the lock screen, you had to login to get to the option before I guess
[12:19] <seb128> right
[12:19] <seb128> or to go the greeter
[12:20] <seb128> by clicking on the button that was on the lockscreen
[12:20] <seb128> bug #1281058 btw
[12:20] <ubot2> Launchpad bug 1281058 in unity-greeter (Ubuntu) "The system shutdowns when multiple accounts are open" [Medium,Triaged] https://launchpad.net/bugs/1281058
[12:20] <davmor2> seb128: nice thanks
[12:20] <seb128> yw
[12:22] <davmor2> jibel: so the uefi menu works, live session seems to work, install about to be triggered so far so good :)
[12:59] <zyga> hey, I'd like to ask for a few things to land before the beta is out: https://bugs.launchpad.net/ubuntu/+source/checkbox-ng/+bug/1297665 and the two merge requests to ubuntu source branchs (both tiny though), this should hopefully fix https://bugs.launchpad.net/ubuntu/+source/checkbox-ng/+bug/1297118
[12:59] <ubot2> Launchpad bug 1297665 in checkbox-ng (Ubuntu) "Sync checkbox-ng 0.2.2-1 (main) from Debian unstable (main)" [Wishlist,New]
[12:59] <ubot2> Launchpad bug 1297118 in checkbox-ng (Ubuntu) "checkbox crashed with TypeError in emit_signal(): Don't know which D-Bus type to use to encode type "NoneType"" [High,Confirmed]
[14:18] <infinity> cjwatson: If ubiquity has to happen anyway, yeah, go ahead with other safe-looking accepts.
[14:18]  * infinity grumbles about being awake.
[14:23] <cjwatson> infinity: Just waiting for a test now ...
[14:23] <cjwatson> (hopefully)
[14:41] <zul> can an archive admin have a look at python-oslotest, its a new dependency of python-oslo.messaging which is needed by a newer cinder
[14:44] <dbarth> sil2100: just a quick update: we're adjusting branches in a stack (merging some conflicts in the process) for the oxide silo
[14:44] <dbarth> sil2100: should be ready soon now
[14:52] <seb128> Laney, zyga: ^
[14:55] <Laney> ty
[14:55] <Laney> looking in a sec
[14:56] <zyga> looking
[14:56] <zyga> Laney: nice, I'll do a test run to check if those work now
[15:06] <Laney> zyga: You guys should include a NEWS file or similar ;-)
[15:07] <zyga> Laney: we will, good idea
[15:09] <zyga> Laney: we have a changelog for plainbox that's pretty detailed
[15:09] <zyga> Laney: but not for the rest of the components yet
[15:09] <Laney> *nod*
[15:11] <zyga> Laney: http://plainbox.readthedocs.org/en/latest/changelog.html <- not old fashioned NEWS but we're working on making stuff more discoverable
[15:11] <Laney> zyga: OK, it all looks alright to me - the only thing I can see is that there might not be anything preventing people installing the new providers with old checkbox-ng; I assume that wouldn't work
[15:12] <zyga> Laney: it would mostly work but one use case would break
[15:13] <Laney> OK, if you think that's acceptable then it's fine by me
[15:13] <Laney> Ready to go after you let me know your testing works out
[15:14] <zyga> Laney: from what I understand, nobody will install the broken set anymore, as those packages will now be in 14.04 at the right version
[15:14] <zyga> Laney: right?
[15:14] <zyga> Laney: I'm just looking but I cannot see them in -proposed yet
[15:15] <Laney> New people won't be able to, but you could just update one or the other
[15:15] <Laney> zyga: They need to be accepted from the queue
[15:15] <Laney> I thought you said you were doing a test run so was going to wait for that
[15:16] <zyga> Laney: update one? I mean the final image *should* be correct, those are now packages so nobody could get those earlier
[15:16] <cjwatson> infinity: well, I uploaded dee and geoclue so I probably shouldn't accept them, technically :)
[15:16] <zyga> Laney: yeah give me a moment then
[15:16]  * cjwatson uploads ubiquity
[15:20] <zyga> Laney: I'm not seeing checkbox-ng in -proposed yet either, is that still pending?
[15:20] <Laney> Yup
[15:20] <Laney> https://launchpad.net/ubuntu/trusty/+queue?queue_state=1
[15:20] <zyga> ok
[15:20] <zyga> I'll just build all locally
[15:26] <stgraber> cjwatson: I take it we want this ubiquiti in ASAP? (sorry, still catching up with backlogs from various channels)
[15:26] <stgraber> *ubiquity
[15:27] <cjwatson> stgraber: two critical bugs, so yeah
[15:27] <stgraber> ok, accepting then
[15:27] <cjwatson> stgraber: I asked infinity if we could have dee and geoclue in the same run, and he was OK with that
[15:28] <infinity> Sorry, yeah, I'm multitasking very poorly right now.
[15:28] <cjwatson> I'm kind of failing to multitask.  Maybe a chairnap would help ...
[15:29] <stgraber> ok, geoclue is just a multiarch change apparently, accepted
[15:29] <stgraber> dee is a sync from a silo so I'll need to track it down...
[15:29] <infinity> https://launchpadlibrarian.net/170578019/dee_1.2.7%2B13.10.20130924.1-0ubuntu2_1.2.7%2B14.04.20140324-0ubuntu1.diff.gz
[15:29] <infinity> Looks fine to me.
[15:30] <stgraber> yep
[15:30] <infinity> Does all this new checkbox-related stuff need to be on images?
[15:31] <cjwatson> Thanks.  I'll check whether ubuntu-sdk-libs-dev:armhf works in an hour or so then ...
[15:31] <zyga> infinity: not really (IMHO) but ask ara please
[15:31] <infinity> Oh, also, indicator-china-weather was intended to land on kylin beta, accepting that.
[15:31] <zyga> ara: ^^
[15:32] <ara> infinity, not really
[15:33] <infinity> Kay, cool.
[15:35] <infinity> Hrm, how did sssd not get auto-accepted?
[15:35] <stgraber> because it's seeded by edubuntu
[15:35] <infinity> edubuntu dvd.  I see that, yeah.
[15:35] <infinity> Shame the queue doesn't.
[15:36] <stgraber> but since edubuntu-server won't be shipping on media, I'm now dropping it from our seeds and updating edubuntu-meta real quick
[15:38] <infinity> stgraber: Good thing we're not doing a beta release tomorrow or anything.
[15:43] <stgraber> infinity: well, since we'll be respinning anyway, I figured I may as well save us a few dozen MBs :)
[15:44] <infinity> :)
[15:44] <infinity> stgraber: Be quick, so I can kick off $world (cause, yay, ubiquity).
[15:44] <infinity> I think we need to come up with an OS that doesn't have an installer.
[15:44] <infinity> That would be novel.
[15:45] <stgraber> :)
[15:45] <cjwatson> the front panel and a load of toggles are all you need
[15:46] <stgraber> infinity: we could replace our installer by a long wiki page and call that Ubuntoo?
[15:49] <zyga> Laney: I think it's safe to sync
[15:49] <Laney> zyga: okely dokely
[15:49] <zyga> Laney: we found a bug but it's not clear if that's our testing environment or something else
[15:49] <zyga> Laney: and it's not related to this at all
[15:49] <zyga> Laney: looks like an existing upstream bug
[15:49] <infinity> cjwatson: Have you been drinking Kool-Aid with a large blue 3-letter logo on the bottle?
[15:49] <zyga> Laney: and this upload will fix a log of known bugs so let's do it
[15:49] <Laney> zyga: ok, good luck fixing then
[15:52] <cjwatson> infinity: No :-)
[15:53] <infinity> cjwatson: Was just having flashbacks to me, Anton, and pinky trying to decipher http://www-01.ibm.com/support/docview.wss?uid=isg3T1010983 yesterday.
[15:53] <cjwatson> *shiver*
[15:58] <infinity> When the primary interface to your hardware appears to be a first-gen GameBoy, you're probably going to end up with more questions than you started with.
[15:58] <infinity> That was our conclusion.
[16:05] <smoser> can someone nak my simplestreams upload ? its not been ack'd yet, and i found a bug to fix.
[16:05] <smoser> unless its preferred for me to upload a new version, thats possible too
[16:06] <Laney> sure can
[16:07] <Laney> voilà
[16:22] <smoser> gracias.
[16:27] <stgraber> infinity: ^ (turned out not to contain what I thought but probably still worth getting in anyway)
[16:59] <infinity> ScottK / Riddell: Whoever triggered that kubuntu rebuild missed the ubiquity update.
[17:00] <Riddell> infinity: oh didn't know there was one, was looking at our own stuff
[17:01] <Riddell> infinity: we want ubiquity 2.17.10?
[17:01] <cjwatson> I think the encrypted-home bug should affect you?
[17:01] <Riddell> sounds likely
[17:04] <Riddell> infinity: so you'll rebuild all desktopy images?
[17:04] <infinity> Riddell: That was my plan.
[17:05] <Riddell> I'll be holding my breath for that :)
[17:05] <infinity> Heh.
[17:08] <infinity> Riddell: Alright, resping of $world triggering now.
[17:08] <infinity> respin, too...
[17:09] <infinity> Riddell: Rearranged to throw you at the front of the list.  Cheers.
[17:11] <Riddell> aww thanks :)
[17:34] <infinity> Riddell: ^ There you go.
[17:34] <Riddell> yay!
[18:03] <boiko> hi guys, so I had some stuff in the CI train, and one of the packages (account-plugins) was marked there as UNAPPROVED because of the freeze
[18:04] <boiko> I just want to know what exactly should I do once we are past the freeze to get those changes landed
[18:05] <zequence> infinity: Are you 'bout to rebuild ours too?
[18:05] <zequence> infinity: I just found I had not fully fixed the bug in our installer. Fixed now. We need to get that uploaded and a rebuild again :P
[18:05] <Laney> boiko: It'll get reviewed at some point, no need to worry
[18:06] <Laney> boiko: Maybe not before the beta tomorrow, mind
[18:06] <infinity> zequence: Whee.  Yours is in my current build pipe.  Maybe if we land your thing in a hurry, it'll make it. :P
[18:06] <infinity> zequence: Point me at what you need reviewed/sponsored.
[18:07] <boiko> Laney: that's fine, thanks
[18:07] <zequence> infinity: lp:ubuntustudio-live
[18:07] <zequence> bug 1297219
[18:07] <ubot2> Launchpad bug 1297219 in ubuntustudio-live (Ubuntu) "package selection plugin crashes when deselecting a meta without recommends" [Critical,Fix committed] https://launchpad.net/bugs/1297219
[18:07] <infinity> Handy, I still have that checked out.
[18:11] <infinity> zequence: Done.  Let's see if it beats the clock.
[18:11] <infinity> zequence: If not, we can respin your respin. :P
[18:11] <zequence> infinity: unapproved?
[18:12] <infinity> zequence: queuebot was just catching up with reality.
[18:12] <zequence> infinity: Thanks :)
[19:14] <infinity> zequence: Looks like that made it into the release pocket before your ISO rebuild slot came up, so we win.
[19:14] <infinity> zequence: (You're right after ubuntu-server, which is in progress right now)
[19:15] <zequence> infinity: ooh!!
[20:10] <jibel> davmor2, something's wrong with latest image. During a live session, I'm connected to the network through a wired connection and I can wget content on the outside, but ubiquity thinks there is no network. Do you see this behavior too? this is with 20140326
[20:12] <davmor2> jibel: well mac got no connection due to 3rd party driver needed I think so I just finished burning an amd 64 so let me restart my laptop and I'll let you know from there
[20:19] <jibel> davmor2, hm, it's working now.
[21:39] <stgraber> edubuntu-artwork is incoming, fixing our currently missing wallpaper (used to be a symlink to a file from ubuntu-wallpapers which got removed between beta1 and beta2...)
[21:43] <stgraber> there it is ^
[21:44] <stgraber> least useful diff ever as it can't diff the actual extra file being added and doesn't list symlinks changing :)
[21:44] <infinity> stgraber: Checking.
[21:44] <infinity> stgraber: Want to review kio-enslave as pennance?
[21:45] <infinity> Err, whatever it is.
[21:45] <infinity> zerconf-ioslave.  That.
[21:45] <stgraber> so you are trading a 5s unapproved review for a new source package? why do I feel like I'm on the loosing end of that deal? :)
[21:46] <infinity> stgraber: Because you are. :)
[21:46] <Laney> Unfortunately I already did it. :P
[21:46] <infinity> That was quick.  I was still downloading.
[21:46] <infinity> Since the diff is useless.
[21:47] <Laney> Yeah, I have quite a good connection to the DC
[21:47] <infinity> I normally do.  My ISP hates me today.
[21:47] <infinity> My usual 10MB/s from github has been 50kB/s today.
[21:47] <infinity> Not happy.
[21:48] <Laney> EXTREMELY ANGRY
[21:55] <stgraber> infinity: what's the general opinion about new sources coming with a length debian/changelog for things that probably only ever existed in a PPA? I tend to be of the opinion that this is confusing and should be reduced to a single entry for the initial upload (unless it ever existed in Ubuntu or Debian or was renamed)
[21:55] <infinity> stgraber: I have no issues with it.  "Initial packaging" or "First upload" are the most uninformative things ever.
[21:56] <infinity> stgraber: Some history on how the packaging got the way it is never hurts.
[21:56] <stgraber> well, this time around it's 10 "New upstream bugfix release" which isn't a whole lot more useful :)
[21:56] <infinity> Heh.  Fair enough, but also not a bug.


[03:56] <astraljava> knome: FeatureFreeze is a little over month ahead, still. I'd like to keep it for a little while, still.
[04:49] <astraljava> knome: Oh, and the display thingie is missing the position calculations, the UI part is done.
[21:28] <pleia2> xubuntu was mentioned when I received the award, and is here: http://www.oscon.com/oscon2012/public/schedule/detail/25039
[21:29] <Unit193> Now I will say congrats.   Congrats pleia2!
[21:29] <pleia2> thank you :)


[21:27] <jrwren> groovy gorilla?!?
[21:28] <cmaloney> Is that the next release name?
[21:30] <jrwren> yup
[21:31] <cmaloney> https://webkinznewz.ganzworld.com/kinzapedia/groovy-gorilla/


[12:04] <slyon> ubuntu-qa: I'm seeing plenty of "Traceback: The read operation timed out" when trying to queue autopkgtests. Is there anything we can do about it?
[12:06] <slyon> seems to be flaky
[12:29] <schopin> I think the HL is qa-help
[12:38] <paride> yup. andersson1234 ^^ is that something you are already aware of?
[12:40] <Skia> I'm taking a look
[12:42] <Skia> okay, rabbitmq was restarted by our magical watchdog "maybe-restart-rabbitmq" about 10 minutes ago, that could explain the flakyness if it was almost dead
[13:04] <Skia> slyon: I don't see errors anymore, do you confirm that it's working on your side too?
[13:05] <slyon> Skia: seems to be working again for me
[13:05] <Skia> great
[16:38] <andersson1234> mattermost is down, so let's co-ordinate here if any fires need fighting :)
[16:52] <andersson1234> bdmurray: How often does update_excuses update?
[16:53] <bdmurray> andersson1234: hours
[16:54] <andersson1234> okay. noted
[16:54] <bdmurray> https://ubuntu-archive-team.ubuntu.com/proposed-migration/log/noble/2024-04-04/
[16:54] <bdmurray> yeah, looks like its avergaing 2 or 2.5 hours
[16:55] <Skia> just so you know the current state, bos03 armhf workers 04 and 06 have been redeployed, but are still missing some LXD images. They both at least have noble, but can be taken down by other releases if bad scheduling happens. At least it's only a matter of restart, not redeploy.
[16:55] <Skia> missing images are in the process of being rebuilt, I'll keep monitoring that
[16:56] <bdmurray> Copy that. Thanks.
[16:58] <Skia> also, `~/juju-config/autopkgtest-lxd-worker_lxd-remotes.yaml` has up-to-date config, but not the service bundle yet, I'll push a commit soon with that
[16:58] <Skia> the advantage of the juju config file is that it has comments on the current status of remotes
[17:05] <andersson1234> we could make a script which produces yaml files for each juju config option, then our workflow could be: modify service bundle -> use script to produce the yaml files -> update config option with a juju config call
[17:05] <andersson1234> then we'd avoid having the yaml files and service bundle out of sync
[17:06] <bdmurray> I do really wonder if we can just use the service-bundle but with the right juju config options
[17:08] <Skia> 6 is all good, 4 is missing focal and mantic, in an retry loop for building; I've pushed the current config in the service-bundle on master, and now I'm dropping off; EOW o7
[17:08] <Skia> forgot that: expect worker count at 29
[17:09] <Skia> and the reported one in error in the KPI is a remain that didn't get cleaned up by `juju config`, but shouldn't exist anymore
[17:25] <andersson1234> `eod` see you tomorrow, and you on monday skia :)