[02:53] A reminder email about Debian Import Freeze being in effect might be helpful :) [03:04] nhandler: I guess it wouldn't hurt, though it's not like there's any action required on the developers' part for that specific freeze [03:05] stgraber: Nope, but it has traditionally been sent in the past iirc. It might also save some developers a few moments of wondering why their packages are taking forever to sync from Debian (before remembering DIF) [07:43] hmm, the arm livefs builder produces random gzip errors during package unpacking [09:29] urgh, the problem with rewriting kernel-overrides is that I have to understand its morass of sed first [09:52] I might be able to get away with no longer having to specify the old ABI, though [11:06] cjwatson: What is the status of squashfs for server.. is there anything i can take on? [11:10] hi all, any reason for not having a desktop image today? [11:11] oh, they seem to be there [11:12] but appeared late [11:12] ok, I will have another go at running the tests on today's images [11:16] Daviey: roughly the right squashfs and iso contents now, but need to figure out a sensible way to convince the cdimage scripts to build an image containing both a livefs and the necessary d-i initrd [11:19] cjwatson: Is this best left with you, or do you want me to poke stuff? [11:20] probably best left with me [11:20] though I want to get it to the point where you can JFDI without bothering me :) [11:25] cjwatson: That would be nice. :) [12:01] Please nobody process the kernels in NEW; I'm working on a kernel-overrides script and want the test case === rsalveti` is now known as rsalveti === Ursinha` is now known as Ursinha [13:08] skaet, wrt java: https://blueprints.launchpad.net/ubuntu/+spec/foundations-q-java7 [13:50] ogra_ thanks, the work items and release notes hadn't mentioned ARM so I thought it was just generic x86. Read closer. Will follow up with james on the specific questions then. :) [14:37] skaet, can you ack desrt membership on https://launchpad.net/~ubuntu-community-contributors/+members ? [14:38] skaet, hey btw, thanks for the reply to my email ;-) [14:42] seb128, desrt's approved. :) give it an hour or so, and the tracking should start. [14:42] skaet, thanks ;-) [14:43] skaet, i wonder if that team is open for teams [14:43] knome, teams can just get added directly. [14:43] aha :) [14:44] no need to go through that path. Just let me or cjohnston know. [14:44] skaet, at least xubuntu-art and xubuntu-team would make sense, we've assigned a lot of items for those [14:44] skaet, thanks :) [14:45] skaet, hmm, xubuntu-team exists in the teams page, but clicking that on the xubuntu burndown page doesn't open that page (of course...) [14:45] skaet, but otoh, that's different anyway [14:48] knome, just looks like xubuntu-art is missing, the others are already there. [14:49] knome, I'm working on some other things right now, but remind me in the meeting on Friday if I haven't added it by then. [14:49] skaet, yeah, but what i'm after is that on the "teams" page, xubuntu-team means anybody on the team, and it will show all the items [14:49] skaet, but we have assigned items to *xubuntu-team*, and it would be nice to track those items only, not everything for everybody in the team [14:50] knome, that's what the topics are for... :) http://status.ubuntu.com/ubuntu-quantal/group/topic-quantal-flavor-xubuntu.html [14:50] you control which blueprints are tracked in it. [14:51] skaet, i was thinking if it was possible to have a page ala http://status.ubuntu.com/ubuntu-quantal/u/knome.html for xubuntu-team [14:51] skaet, where only any items assigned to *exactly* xubuntu-team (not anybody in the team) are shown [14:52] skaet, if you look at http://status.ubuntu.com/ubuntu-quantal/group/topic-quantal-flavor-xubuntu.html, you can see that the xubuntu-team has literally 22 items assigned [14:52] skaet, eg. [xubuntu-team] ... :) [14:53] skaet, that's not what http://status.ubuntu.com/ubuntu-quantal/xubuntu-team.html, or the topics track [14:54] knome, it is [14:54] knome, your team is the light orange color [14:54] seb128, yes, the team as in everybody that is part of the team [14:54] well, that should be the difference between (team) and (foreign) [14:55] knome, probably a good request to bring up at the next UDS session on the work item tracker. [14:56] skaet, ok :) or i'll just poke stgraber meanwhile ;] [14:56] * skaet figures its going to take some work, and a bit of design. [14:57] depends how the system is built :) [14:58] it's not the most important thing ever, but it would help in reassigning the items to actual people, and to track what collectively has to be done (in addition to/apart from the items that have a single assigneE) [15:06] * cjwatson declares victory over kernel-overrides [15:07] :) [15:08] committed to lp:ubuntu-archive-tools, removing the version on cocoplum [15:09] * cjwatson wonders if anyone needs new-remove-duplicates any more [15:10] I think I'll remove that because it used to be much more of an issue for mass syncs, and that's no longer a problem in practice; and for duplicate manual uploads, it's better to check by hand and pick the best, rather than arbitrarily rejecting the oldest [15:15] * skaet nods [15:48] when an archive admin has a moment, could I get the linux-3.5.0-4.4 and linux-meta-3.5.0.4.4 kernel packages copied out of quantal-proposed and into the release pocket [15:49] ogasawara: done [15:49] cjwatson: thanks [15:50] though for the record you can probably do that yourself [15:51] 'sru-release -r quantal linux linux-meta' from lp:ubuntu-archive-tools [15:51] (won't work for stable releases, but since you can upload directly to quantal you should also be able to copy to it) [15:52] ah cool, i'll have to try that next time [15:54] cjwatson: I thought we said we don't want regular people copying from -proposed to the release pocket [15:54] no reason why it should be a problem in this particular case [15:54] sure, just pointing out the general policy though :) [15:55] anyway that's basically superstition until such time as there's any kind of effective gatewaying on the release pocket [15:55] so I see no point in enforcing it [16:03] micahg: Enforcing such a rule on the development release would probably encourage people to upload straight to the release pocket when perhaps it might be better not to. [16:04] ScottK: ooh, deja vu :), well, the problem is that people not realize all the transitions in progess in -proposed at the moment, so the task was left to the AAs [16:04] I'm not saying everyone should copy stuff around without thought, but it's perfectly obvious that linux/linux-meta isn't part of a transition. [16:05] Except its own self-contained one which the kernel team are well aware of. [16:05] granted [16:05] There's no point applying policy when it doesn't make sense. [16:06] I was thinking more about the stuff that breaks things due to archive skew. [16:06] Those don't need to be in proposed very long. [16:06] ScottK: right, but if they use something in transition with changed symbols, copying it prematurely will break worse than the archive skew :) [16:07] Yes. So they shouldn't do that. [16:08] s/will/could/ :) [16:10] as we don't have any automated process in place at the moment I usually pocket-copy my own stuff from the proposed to release pocket, but I tend to be aware of what transitions are going on and obviously won't copy something that'd break the archive. Having to wait for/poke an AA everytime sounds like a bit of a waste of time for everyone and would certainly make me consider pushing to release pocket + playing with build score as an alter [16:11] and unless that changed recently, it's not totally obvious how to do the pocket copy (no script in ubuntu-dev-tools or web UI), so it's unlikely that someone would do it by mistake :) [16:13] right, you need stuff from u-a-t I think, or to know the API well enough to do it yourself [16:16] yeah, I usually just call copyPackage directly from lp-shell [16:17] stgraber: I know too well that is what you do :) [17:54] Whoever just sync'ed compiz, there was whining about a regression in one of the bugs. [17:55] Bug 929989 [17:55] Launchpad bug 929989 in compiz-core "compiz (decor) - Warn: failed to bind pixmap to texture" [Medium,Fix committed] https://launchpad.net/bugs/929989 [17:56] bdmurray: ^^ [17:56] ScottK: hunh, the pending SRU report had it as green [17:56] Yes. Yes it did. See the comments in the bug. [17:56] (it refers to another bug) [17:57] so what now? [17:57] bdmurray: I'd recommend moving it back to -proposed until that's resolved. [17:57] 6 minutes until the publisher run. [17:57] cjwatson or infinity: Can you help? [17:57] ScottK: How can I fix this? [17:58] inifinity managed to move a package back to proposed on Friday. Not quite sure how. [17:58] was it deleted from -proposed yet? (does sru-release do that?) [17:58] Just removing compiz from updates doesn't fix it as there was already a previous SRU there. [18:01] skaet: It seems like -proposed regressions reported in a new bug and not noticed is a bit of a recurring theme. Might be a good topic for the SRU team meeting. [18:02] Dear LP, please get version tracking. [18:02] The regression is discussed in Bug #993608 too. [18:02] Launchpad bug 993608 in compiz "CMake Error at FindCompiz.cmake:84 (include): include could not find load file: CompizDefaults" [Critical,Fix committed] https://launchpad.net/bugs/993608 [18:02] hrm, can someone stop the publisher? [18:03] Someone can, but not me. [18:03] cjwatson, jdstrand: ^ [18:03] gah, looks like it's too late [18:06] Someone should upload a .2 ASAP that reverts this change and then it should get smoke tested and pushed to updates. [18:07] Too late. Copy it back to -proposed and remove-package it from -updates. [18:07] It's about to be dinnertime but let me see if I can do that quickly. [18:07] that will re-publish the previous -updates package? [18:07] cjwatson: thanks [18:08] Laney: No [18:08] Can't do that [18:08] ho hum [18:08] That's why I was proposing a new upload. [18:08] If you need that, then yeah, your best bet is a fresh upload. [18:08] * ScottK looks around for an Ubuntu Desktop person. [18:08] * cjwatson wanders off then. [18:08] Oh. Laney. \o/ [18:08] who did the original upload? [18:08] ScottK: Laney seems to be around ;) [18:09] stgraber: I was getting to that. [18:09] since I have nothing to do with it … [18:09] grab it from LP, bump the version number and upload. [18:09] FWIW we need to stop assuming that we can stop the publisher anyway - that ability is going away [18:10] cjwatson: can we get a safe haven pocket to copy stuff to then? :) [18:10] And in any case that was always a ridiculously crude measure [18:10] micahg: No [18:10] seb128: popey: ^^^ [18:10] popey, ^ [18:10] hah [18:10] It won't help. You'd just find out about stuff when you copied out of the safe haven. [18:10] It's like adding more confirmation dialog boxes to things. [18:10] Eventually it's safe havens all the way down. [18:10] cjwatson: well, in this case, we could've copied -updates to the safe haven or something like that [18:11] Err [18:11] One of us is confused [18:11] He's looking for a place to stow the previous update in case a revert is needed. [18:11] * micahg was tempted to copy to -security temporarily [18:11] Being able to copy things out of -updates wasn't the problem. [18:11] i consider precise-updates to be a safe haven, where i won't get a regressed system from :) [18:11] cjwatson: the issue was that the -proposed copy overwrote a previous update [18:12] You know you can copy from any publication even if it isn't current, right? [18:12] But that doesn't help, because you can't wind -updates backwards. [18:12] Regardless of whether you try it by an upload or a copy [18:12] cjwatson: oh really?, that's nice [18:12] In an case, Laney or seb128: Is someone working up loading a revert? [18:13] ScottK, popey's team is maintaining compiz and unity packages, I need to run but I will have a look at the backlog later [18:13] cjwatson: but, I guess it doesn't help since we can't go backwards :( [18:13] check with popey [18:13] ola [18:13] micahg: Exactly. [18:13] I can't upload it. [18:13] my guys are end of day :S [18:13] but if you do it, I am on board with that. [18:13] For an -updates regression, company policy is that we get people out of bed :-P [18:14] popey: I do all this for free, so "my guys are end of day" isn't very impressive. [18:14] understood.. i was merely pointing out a fact [18:14] Particularly for an SRU regression. [18:14] I'm happy to take the old compiz, bump the version and upload if that helps people resolve the who-does-what problem? [18:14] Lets just work out that needs doing, shall we? [18:14] clearly that's what needs to happen at this point and I can't see how it could make things any worse [18:14] stgraber: Just making a package. [18:15] you can sponsor it for me :-) [18:15] Laney: ok [18:15] we have a plan! [18:15] * micahg wonders why laney needs a dch -i sponsorship at this point :) [18:15] silly boards can't get quorum :P [18:15] Laney: not what I meant :) [18:15] * ScottK glares at micahg. [18:16] * micahg shows up for meetings :P [18:16] which bug is the regression in? [18:17] stgraber: micahg is right though, you might as well just dch -i it yourself [18:17] bug 929989 is marked verification failed [18:17] Launchpad bug 929989 in compiz-core "compiz (decor) - Warn: failed to bind pixmap to texture" [Medium,Fix committed] https://launchpad.net/bugs/929989 [18:17] * Laney is test building [18:17] and links to bug 1019337 [18:17] Launchpad bug 1019337 in compiz-core "gtk-window-decorator crashes with an X Window System error" [Undecided,New] https://launchpad.net/bugs/1019337 [18:17] which I'll open an ubuntu task for [18:17] Laney: yeah, I'm preparing a revert here [18:20] do you want me to aim that at -updates or -proposed? [18:21] proposed. 0 day smoke test. updates. [18:21] stgraber: in lieu of ScottK responding, i'd say -proposed.. then binaries can be copied over [18:21] ok [18:21] from last known good SRU: http://paste.ubuntu.com/1084931/ [18:21] from the bad SRU: http://paste.ubuntu.com/1084932/ [18:22] ScottK, agree, worth a discussion. [18:22] uploaded [18:23] your first diff should include the reverted changes? [18:23] oh, you included the changelog [18:23] i get it [18:23] Laney: right, first one is just to proove I didn't add anything on top of the currently working version, just kept the changelog entry from the broken SRU. Second contains the full code revert. [18:25] * ScottK is reviewing to accept it. [18:26] builds, fwiw [18:26] Daviey: yeah, only advantage of -updates is the number of publisher runs, you basically save 30min if you push directly to -updates [18:26] not that i'd expect that to have regressed [18:27] Laney: does it need some rescoring for weirder archs? [18:27] it should be rescored /anyway/ [18:27] I bumped powerpc [18:27] seems to be building [18:27] apart from ppc [18:28] ETA is 2 hours for PPC [18:28] can't see what's building there, something big? [18:28] hrm, mildly [18:28] stgraber: Are you a buildd admin? [18:28] can't see either, apparently buildd admin isn't enough to know what's going on. I'm assuming it's one of micahg's stuff building [18:28] ScottK: yeah [18:29] micahg: You got anything powerpc going on? [18:29] hrm, will be ~3 more hours [18:29] stgraber: You have the power to kill builds, don't you? [18:29] ScottK: not for these I can't see [18:29] you can ask in #-ops I believe, if warranted [18:29] ScottK: micahg might be able to kill his builds though, not sure (it's a non-virt PPA) [18:30] I'm looking into it, give me a minute [18:30] Good point. [18:30] thanks. [18:31] we really need more ppc hardware... [18:31] and having sulfur offline really doesn't help [18:31] * stgraber looks at the status of that RT ticket [18:33] not hopeful. [18:35] yeah, looks like hardware/firmware issue (based on screenshot it's stuck somewhere in the firmware). And no news since end of June... [18:38] ok, we're getting you a powerpc buildd [18:39] thanks [18:52] there we go [18:53] die.ppc.die.die.die [18:54] infinity: if I send you $50 to buy a better computer, ca we stop building for ppc? :) [18:54] won't make it by the next publisher run, so we'll only be able to copy with the one after that [18:56] so the reverted version should land in -updates in an hour [18:56] gives someone time to smoke test [18:57] mdeslaur: FWIW, from a build perspective, powerpc is in better shape than i386 ATM :) [18:57] for +1 that is [18:58] micahg: I'm sure all 4 powerpc users are happy about that [18:58] Spend the $50 on another powerpc buildd. [18:59] Of course if that was Canadian $, you need 51. [18:59] ;-) [18:59] hehe [19:04] You people and your PPC hatred. :) [19:04] But yeah, we'll buy more buildds with your 50 bucks, please donate. [19:07] Prelude System.Info Text.Printf> printf "Hello from ghci on %s\n" arch [19:07] Hello from ghci on arm [19:07] oh well done [19:07] i can't really claim any credit :P [19:07] but good news nonetheless [19:07] * Laney ships it. [19:09] * Laney checks 1000 times that it's going to experimental and not unstable [19:11] infinity: If I didn't spend every week waiting for PPC to finish building so I can release security updates, I wouldn't hate it as much :) [19:12] mdeslaur: if that's all, we just need sulfur back, the queue was pretty caught up with all three going :) [19:16] sulfur seems to be very confused about its lot in life. It may not come back. [19:16] But we'll replace it. Honest. [19:27] * Laney considers these haskell uploads [19:29] infinity: what kind of hardware are the ppc builders? [19:29] mdeslaur: The ones that are alive are Apple Xserves. Junk, essentially. :P [19:29] mdeslaur: The one that's dead is an IBM 510. [19:30] mdeslaur: The plan is to replace and/or supplement with newer IBM 710s, or similar. [19:30] infinity: so I should stop searching for $50 xserves on ebay? :P [19:31] If you find an old Xserve for 50 bucks, it's more than worth that. [19:31] No matter how much I personally dislike them. :P [19:34] ScottK, would you like me to smoke test this when it hits -updates? [19:34] er, -proposed :D [19:34] Yes. Please. [19:35] ok, no problem. can I get a ping when it's ready and I'll jump on it. [19:36] popey: everything's built [19:37] I would grab the debs from Launchpad if I were you, to avoid mirror lag. We ideally want this before the next publisher. [19:37] Wow. A guy just walked past who looks exactly like James Page [19:37] jamespage: was it you?! [19:38] Laney, url? [19:38] we just missed another publisher run [19:38] popey: https://launchpad.net/ubuntu/+source/compiz/1:0.9.7.8-0ubuntu1.2 [19:38] popey: https://launchpad.net/ubuntu/+source/compiz/1:0.9.7.8-0ubuntu1.2 [19:38] ta [19:39] click your architecture, then look at "built files" [19:39] thanks [19:46] session is fine.. would you like me to try to reproduce the specific issue in the bug? with intellij? [19:50] popey: Give it a try quickly. [19:50] ~13 minutes left [19:50] i have intellij installed, cant seem to trigger the issue [19:50] stuck at #2 searching for a class :S [19:51] I cant trigger it [19:51] no matter what i bash in intellij [19:51] ok [19:52] bdmurray: want to push this? [19:53] or ScottK [19:53] I can. [19:53] thanks ScottK [19:54] thanks ScottK [19:54] So where was the problem here? [19:54] Do you mean why did I approve it? [19:54] That the report wasn't updated with v-failed? That the copy was done without checking all bug reports one more time? That there is no way of flagging additional bug reports up? [19:54] bdmurray: yeah. [19:55] Yes, the report wasn't current and I didn't check all the bug reports one more time. [19:55] Done. [19:56] Possibly also one thing that may have helped if the reporter of that regression bug had opened it against the ubuntu package of compiz and tagged it regression-proposed. [19:56] At least some of the SRU team is subscribed to that tag and regression-updates. [19:57] one of the dx guys screwed up as well by not knowing the process [19:57] the bug was tagged verification-failed by an user [19:58] but Daniel went "this specific issue is fixed, please open a new bug for the regression" and tagged the bug back verification-done [19:58] Oh, I think I was thinking about tagging bugs via a bot if the package is from -proposed but that wouldn't have helped since the regression bug wasn't reported via apport. [19:58] Daniel = Daniel Van Vugt, one of the compiz guys [19:58] Laney, I dropped an email to jasoncwarner and didrocks with a summary for the situation and the things that failed, which includes: [19:59] - nobody from the people who did the SRU watched for the comments [19:59] - nobody in #ps noticed the bug opened about the regression [19:59] thank you seb128 [19:59] - the distro process was misunderstood which did lead to revert the verification-failed tag [20:00] popey, yw [20:00] cheers [20:01] popey, I think we will have a discussion with some extra people Cced about those issues and how we prevent them to happen again, but I didn't want to turn the incident in another ranting or anything like that so I just bounced to Jason for status update with some ideas tonight [20:01] heh, appreciated [20:01] popey, Didier or I will probably start an email discussion with the unity team and you guys later to see how we can improve our process so we don't overlook those next times [20:01] popey, yw ;-) [20:01] excellent. [20:02] duflu should've know better about the tags as a bug control member [20:02] Laney, bdmurray, cjwatson, micahg, stgraber: thanks for handling the issue [20:02] and ScottK [20:02] seb128: There's an SRU team meeting next monday. That might be a good time to discuss it. [20:02] yw :-) [20:02] ScottK, thanks as well [20:02] np [20:02] You're welcome. [20:03] ScottK, well, I think the failure was not so much on the SRU team side, we really got unlucky that all the bugs got green flagged with a known regression [20:03] it's a bit unfortunate that we raced between the tag update and the pocket copy [20:03] Does anybody know how often the sru report is generated? [20:04] maybe an e-mail to bugcontrol/bugsquad/ubuntu-devel about the SRU tags, what they mean, and what it takes to change them? [20:11] Laney: pretty sure it was my evil twin [20:11] he did have a certain glint [20:12] lol [20:38] bdmurray: half-hourly [20:38] it's on the archive cycle [20:39] cjwatson: thanks that seems regularly enough [20:41] infinity: could somebody from canonical-partner-dev hoover up bug 990761? friend of mine's asking, and AFAICS it's a one-line fix [20:41] Launchpad bug 990761 in acroread "acroread 9.5.1 is not installable on Ubuntu Precise amd64 system" [Undecided,Confirmed] https://launchpad.net/bugs/990761 [20:44] cjwatson: If by "someone", you mean me, I suppose I could make that happen this afternoovening. [20:45] You're here :-) [20:45] chrisccoulson is touched-it-last but I guess it doesn't really matter who fixes it ;) [20:45] ah, I didn't check, correct [20:45] er s/correct/sorry/ leakage from talking IRL [20:46] acroread probably should be made arch=i386 then instead of building on both i386 and amd64 and failing on amd64 as is currently the case [20:46] yeah, but he's not available ATM either :) [20:46] stgraber: it is [20:46] er, oh, didn't notice the failure. only successfully built on i386, yeah [20:46] yeah it tries to build-dep on ia32-libs [20:48] Yeah, it should just be multi-archy. [20:48] But that sounds like more than a 1-line change. [20:48] Potentially TWO OR THREE. [20:49] doesn't it ship a firefox plugin too? [20:50] if so you'll need quite a few hacks to make it work [20:50] Oh, is it not multiarchy right now? [20:50] I dunno. This is more knowledge of acroread than I want to have. [20:50] There's a more extensive patch in bug 998837 [20:50] Launchpad bug 998837 in acroread "acroread fails to install on amd64 (dup-of: 990761)" [Undecided,Confirmed] https://launchpad.net/bugs/998837 [20:50] Launchpad bug 990761 in acroread "acroread 9.5.1 is not installable on Ubuntu Precise amd64 system" [Undecided,Confirmed] https://launchpad.net/bugs/990761 [20:50] if it ships a mozilla plugin poke me, I have already done that work for a not-yet-released partner package [20:51] So not a one-liner then, but still just a control file change [20:51] Though I'm not sure the Architecture change to acroread-common in that bug is correct ... [20:52] Dear god, this is a 267MB source package. [20:52] looking at the branch for that other package, making the firefox plugin should be trivial though (if it indeed bundles it), you just need to always depend on nspluginwrapper and call it even on i386, it DTRT for you [20:52] This could take a few hours of Nicaragua bandwidth. [20:52] (sure nspluginwrapper is pointless on i386 but it doesn't harm AFAICT) [21:25] if [ `uname -m | cut -c 1` = "i" ]; then [21:25] * infinity dies a little inside. [21:28] infinity: what's wrong with that? they obviously wanted to check if the machine you're running on is ia64! [21:28] highvoltage: :P [21:28] I clearly need more wine before working on this package. [21:34] hmm, people are talking about trying to revert Abiword to 2.8.6 for Precise in bug 1019621 [21:34] Launchpad bug 1019621 in abiword "Precise abiword version needs to be reverted to stable release prior to 12.04.1" [Undecided,Confirmed] https://launchpad.net/bugs/1019621 [21:35] jbicha: it's too bad no one complained before release about these bugs :( [21:35] if we can confirm ABI compatibility with the latest snapshot, I"m going to push for an SRU of it [21:36] downgrading post-release isn't really an option [21:37] urgh [21:41] there was discussion on the Abiword mailing list last month about releasing 2.9.3 or 2.9.4 but it looks like those releases weren't official yet [21:41] no, Debian has a snapshot from june though [21:42] yeah, that's in quantal too [21:42] micahg: Downgrading's an option, if it doesn't blow up user settings. [21:42] micahg: But forward is probably the saner way to go, assuming upstream is fixing this visual issues. [21:43] infinity: well, 2.8.x is GTK2, 2.9.x is GTK3 and the settings might blow up [21:43] micahg: GTK2 vs GTK3 doesn't matter, we ship both everywhere that wants Abiword anyway. But yeah, if setting could explode, that would be the obvious blocker. [21:45] the lack of confidence from the abiword developers (and the lack of a release schedule) is annoying [21:47] indeed [21:59] cjwatson: So, uhm. You say you have a friend being bitten by this acroread not installing on amd64 thing? Cause it Just Works here... [22:00] infinity: He had the oneiric version installed, and apt refused to upgrade it [22:00] apt-show-versions acroread said "acroread/precise *manually* upgradeable from 9.5.1-1oneiric1 to 9.5.1-1precise1" [22:00] apparently [22:00] Ahh. I could see it, perhaps, having upgrade issues, yeah. [22:01] Anyway, I'd forgotten you were at debconf, so don't feel obliged to spend lots of time on it right now :) [22:01] Well, I'm poking at it idly. [22:02] But yeah, not panicking about it. :P [22:36] is anyone tracking libevolution / gtkhtml transition? And has it been staged into proposed?