[00:18] <TheMuso> /c/c
[01:57] <twb> I'm trying to do some pinning for the first time in a few years; last time I tried it didn't work on Ubuntu because there were no release aliases (stable/testing/unstable).
[01:57] <twb> But this looks like it should work, and I can't see what I'm doing wrong: http://paste.debian.net/135875/
[01:57] <twb> Is there some gotcha I don't know about, like "pinning doesn't work at all in lucid" ?
[03:52] <pitti> Good morning
[03:52] <ScottK> Good morning.
[07:04] <dholbach> good morning
[08:55] <pitti> SpamapS, RAOF: did either of you accept postgresql-common into oneiric-proposed?
[08:55] <pitti> someone did, but didn't run sru-accept
[08:55] <pitti> anyway, running it now
[08:57] <RAOF> Nope, but I guess oneiric-proposed is now open for sru business, isn't it.  Time for me to start checking that queue.
[08:58] <pitti> RAOF: right, it is; we already accepted quite a number of SRUs, see the HTML report
[09:17] <tseliot> cjwatson, pitti: do you know what package sets up the admin group in ubuntu?
[09:18] <pitti> hm, it's not sudo
[09:18] <ogra_> isnt it base-files or some such ?
[09:18] <ogra_> some d-i component at least
[09:19] <pitti> it's nowhere in /var/lib/dpkg/info/*.postinst, so I guess it's in the installer
[09:22] <cjwatson> user-setup
[09:22] <ogra_> ah
[09:22]  * ogra_ knew it was something with a dash in the middle :)
[09:25] <tseliot> ok, thanks everyone
[11:42] <mdeslaur> pitti: the postgresql 8.4.9 update is failing to build on armel. The regression test fails horribly. Any ideas?
[11:44] <mdeslaur> pitti: ie: http://paste.ubuntu.com/706647/ , http://paste.ubuntu.com/706648/
[12:05] <pitti> mdeslaur: ugh, no; haven't see that one yet; that's a regression from .9, i. e. .8 worked in the same environment?
[12:05] <mdeslaur> pitti: yeah, .8 compiled fine on the armel builders
[12:06] <mdeslaur> pitti: unless something changed on the builders since .8 was compiled
[12:07] <pitti> mdeslaur: does it affect all releases? i. e. lucid/maverick/natty?
[12:07] <mdeslaur> pitti: yes
[12:08] <mdeslaur> pitti: 8.3 compiled fine on hardy armel though
[12:08] <pitti> ok, then it's very likely a regression in .9
[12:08] <pitti> built fine on sid, though (https://buildd.debian.org/status/fetch.php?pkg=postgresql-8.4&arch=armel&ver=8.4.9-1&stamp=1317049566)
[12:09] <pitti> mdeslaur: I'll try that in a porter chroot
[12:09] <mdeslaur> pitti: thanks
[12:10] <mdeslaur> pitti: the way it's failing could be a lack of resources on the builders
[12:11] <pitti> I wonder whether the shm settings changed
[12:11] <pitti> mdeslaur: oh, the buildds changed
[12:12] <pitti> mdeslaur: we now have panda board
[12:12] <pitti> s
[12:12] <pitti> previously (until a few weeks ago) we had another kind
[12:12] <pitti> mdeslaur: anyway, I'll try on the porter box
[12:13] <mdeslaur> oh!
[12:14] <mdeslaur> pitti: ok, let me know
[12:14] <pitti> mdeslaur: I think all the arm builders which are on "manual" are the old ones
[12:14] <pitti> mdeslaur: do you have the builds in a PPA or so, where you can retry them easily?
[12:14] <mdeslaur> pitti: is porter a panda board?
[12:15] <pitti> I wonder if we could temporarily set the panda boards on manual and reactivate one of the old ones to grab the build
[12:15] <pitti> to see whether that's the difference
[12:15] <mdeslaur> pitti: yes, there in the security PPA, I can retry them
[12:15] <pitti> mdeslaur: don't yet, need to ask lamont first
[12:16] <pitti> mdeslaur: no, kakadu (porter) is a babbage (MX51)
[12:16] <mdeslaur> lamont: although pandas are quite cute, it turns out they can be pretty mean
[12:17] <pitti> lamont: are the old babbage armel buildds really down, or just disabled to let the pandas build everything?
[12:17] <pitti> lamont: i. e. can I reactivate one of the babbages to let teh postgres update build?
[12:20] <pitti> also, do we have a panda porter box?
[12:22] <pitti> mdeslaur: 8.4.9 build running on kakadu now; will take a bit, though
[12:22] <mdeslaur> pitti: thanks
[13:01] <cjwatson> pitti: scheat
[13:02] <pitti> cjwatson: bisecting :) not sure whether we want to wait with the security update until postgres works on panda; I guess not?
[13:19] <lamont> pitti: infinity stuck all the non-pandas on manual so that pandas win
[13:19] <pitti> lamont: ah, but they still work
[13:19] <lamont> you could certainly stuff something on one of the ones listed as manual
[13:19] <pitti> lamont: thanks
[13:20] <pitti> mdeslaur: kakadu still building; shall we try this, to have some parallelism?
[13:20] <lamont> pitti: I've been failing to bring the bbg3 boards back when they fall over, since they're not suitable for a datacenter.  if they're not DISABLED in launchpad, they're live
[13:21] <pitti> lamont: cool, thanks; wanted to be sure I won't set anythign on fire by reenabling them
[13:21] <mdeslaur> lamont: is there a way I can force a PPA rebuild to a specific builder?
[13:21] <lamont> it was done entirely for build time minimization
[13:21] <pitti> mdeslaur: I'll do taht
[13:21] <lamont> mdeslaur: you get someone with buildd admin privs to encourage it
[13:21] <pitti> mdeslaur: if you can stand by with retrying (don't yet), I'll set up teh buildds accordingly
[13:21] <pitti> lamont: on it
[13:21] <mdeslaur> pitti: ok, let me know
[13:22]  * pitti looks for a suitable bait -- aah, this candy over here!
[13:22] <pitti> mdeslaur: ok, please retry the build now
[13:23] <pitti> should land on actinidiaceae
[13:23] <mdeslaur> pitti: ok, have retried lucid
[13:23] <mdeslaur> pitti: yep, it's on actinidiaceae
[13:23] <pitti> mdeslaur: ok, https://launchpad.net/builders/actinidiaceae now "building private source"
[13:24] <pitti> I reset the buildds
[13:24] <mdeslaur> pitti: ok, cool, now we wait
[13:24] <pitti> for some reason https://launchpad.net/builders just stopped working for me (I get "forbidden")
[13:25] <pitti> perhaps LP now forbids me seeing this as soon as there's a private build running?
[13:25] <mdeslaur> pitti: yeah, apparently when there's a security build going on that whole page gets forbidden
[13:25] <mdeslaur> pitti: I wasn't aware of the change, but someone mentioned it this week
[13:25] <pitti> that's new, though; I used to be able to see it
[13:25] <pitti> it's not that secrect, though, https://launchpad.net/builders/actinidiaceae still shows it
[13:25] <mdeslaur> it's not a very good change, it should still work, but simply not say what's building IMHO
[13:25] <pitti> also, "yes, we are building security updates" -- that's not exactly a secret?
[13:26] <pitti> mdeslaur: it never did
[13:26] <pitti> it just said "private build"
[13:26] <mdeslaur> so, it's broken
[13:26] <pitti> it's never really been an information leak
[13:26] <pitti> except that you coudl have timed it and thus make some guesses
[13:27] <mdeslaur> meh
[13:27] <pitti> but now I can still time the time that the page has "forbidden" for me :)
[13:27] <pitti> (imagine some less ridiculous word repetition there)
[13:27] <mdeslaur> right, not a big difference :)
[13:42] <frafu> Hi, could anybody please tell how I can submit a package to proposed as requested here: https://bugs.launchpad.net/ubuntu/+source/onboard/+bug/872374/comments/1
[13:49] <charlie-tca> frafu: probably better to ask in #ubuntu-motu or #ubuntu-devel, actually.
[13:50] <charlie-tca> ooops
[13:50] <charlie-tca> sorry, wrong channel
[13:51] <frafu> It is a package from main; should I nevertheless ask in MOTU?
[13:51] <tumbleweed> !sru | frafu
[13:51] <charlie-tca> no, here should be correct
[13:56] <frafu> What does 'Use Nominate for series' mean? It is in the procedure to get it into sru.
[13:58] <tumbleweed> frafu: already done on that bug, it adds a task for the series (oneiric task below the "onboard (Ubuntu)" yellow bar
[14:03] <frafu> tumbleweed: Has it also already been submitted to -proposed? (I suppose that it means release-proposed!?
[14:06] <tumbleweed> frafu: that would be an upload to oneiric-proposed, that someone will have to sponsor for you. Procedure is to subscribe ubuntu-sponsors and wait. But seeing as there's some urgency here, maybe a core-dev lurking here now can sponsor it (I'm not a core-dev)
[14:07]  * tumbleweed has been saying that a lot recently. Maybe I should apply... (but I don't touch main much...)
[14:07] <frafu> tumbleweed: Thanks for the explanation.
[14:14] <pitti> mdeslaur: build finished just fine on kakadu
[14:15] <pitti> mdeslaur: seems we need a panda porter box to figure this out then
[14:15] <mdeslaur> pitti: ok, let's see if actinidiaceae builds it
[14:16] <pitti> mdeslaur: fun, now I can see the /builders page again although it's still building
[14:16] <mdeslaur> how odd
[14:16] <mdeslaur> maybe it's not related to the security build
[14:42] <infinity> pitti: We have a panda porter box.
[14:42] <infinity> pitti: scheat.
[14:42] <pitti> ooh
[14:43] <pitti> I thought when cjwatson said this he meant "cheat", for trying to work around the FTBFS
[14:43] <slangasek> "scheat"?  are we now naming machines after Homestar Runner characters?
[14:43] <infinity> Ask Nafallo. :P
[14:46] <Nafallo> infinity: no, lamont.
[14:47] <Nafallo> slangasek: arabic stars currently
[14:47] <infinity> Nafallo: You didn't get to name these ones?
[14:47] <Nafallo> infinity: I choose not too.
[14:47] <Nafallo> infinity: I got to name Zavijava yesterday though, so I'm content
[14:47] <slangasek> Nafallo: where's omar-sharif then
[14:47] <Nafallo> slangasek: double name. likely vetoed :-)
[14:48] <slangasek> snerk
[14:48] <Nafallo> that compiz in -proposed btw. are there loads of bugs about it?
[14:48] <Nafallo> I just downgraded to confirm that was what kept stealing my windows and hiding them someplace else.
[14:49] <slangasek> Nafallo: do you mean to ask "where do I report that the -proposed compiz is broken"? :)
[14:50] <infinity> I think that's exactly what he meant.  It gets lost in translation from the original Swedish Chef.
[14:50] <Nafallo> slangasek: nope. more of a "have anyone seen this, or do I need to file a new bug"
[14:50] <Nafallo> infinity: b0rk bork b0rkie.
[14:50] <slangasek> no, you need to mark an *existing* bug as verification-failed so that the SRU team knows not to copy it to -updates
[14:51] <infinity> That assumes there's an SRU bug open forit.
[14:51] <slangasek> Nafallo: by taking https://bugs.launchpad.net/bugs/748840 for example, explaining the regression in the comments, replacing 'verification-needed' with 'verification-failed' in the tags, and linking to a bug report for the new behavior if you have one
[14:51] <slangasek> infinity: why would we accept something into -proposed without an SRU bug?
[14:52] <Nafallo> hopefully the bug is listed in the changelog then
[14:52] <slangasek> yes, that's how it works
[14:52] <infinity> slangasek: We really shouldn't.  Just sayin'. :P
[14:52] <slangasek> infinity: oh, btw
[14:52] <slangasek> Binary files i386/usr/share/man/man8/pam_shells.8.gz and amd64/usr/share/man/man8/pam_shells.8.gz differ
[14:52] <infinity> *^$!%
[14:52] <infinity> Also: fuck.
[14:53] <Nafallo> hrm. loads of bugs in the changelog, but none for the SRU itself I don't think.
[14:53] <slangasek> Nafallo: it doesn't matter, we don't *want* placeholder SRU bugs in the changelog
[14:53] <infinity> No, but each of those bugs will need verification, so pick one and fail it. :P
[14:53] <slangasek> yes
[14:54] <Nafallo> heh
[14:56] <infinity> slangasek: Here's a question, do the differing files match the differences from the last build?
[14:56] <slangasek> infinity: the good news is, armel and i386 are the same this time... so we're down to one random variation instead of two :P
[14:56] <slangasek> infinity: checking
[14:56] <infinity> slangasek: (ie: is this deterministic and repeatable, and we just don't know how to determine the repeatable steps yet?)
[14:57] <infinity> slangasek: The part where armel wasn't as broken as last time, while amd64 is, is a bit shaky already. :/
[14:57] <slangasek> infinity: yes, amd64's pam_shells.8.gz came out the same in both runs
[14:57] <infinity> Unless it relates to what machine it built on...
[14:57] <slangasek> but *different* than when I run gzip here
[14:57] <infinity> slangasek: Same machine for both amd64 builds?
[14:57] <infinity> (And different for both armel builds?)
[14:57] <slangasek> haven't looked; will look later
[14:57] <infinity> I can look.
[14:58] <bdmurray> why are duplicates of bug 870281 still coming in?
[14:59] <bdmurray> would it just be an out of date mirror?
[14:59] <bdmurray> http://nl.archive.ubuntu.com/ubuntu/ oneiric/multiverse flashplugin-downloader i386 10.3.183.10ubuntu5
[15:00] <charlie-tca> It still happens on some fresh installs
[15:00] <slangasek> bdmurray: yep, sounds like an out-of-date mirror then
[15:00] <infinity> slangasek: amd64 builds were both on allspice, armel builds were on a babbage (broken) and a panda (not broken).
[15:00] <slangasek> bdmurray: escalate to IS?
[15:01] <infinity> slangasek: I don't know what this means, but it might at least mean this wouldbe debuggable with hardware access.
[15:01] <bdmurray> slangasek: oh?
[15:08] <slangasek> bdmurray: current version of the package in the archive is 11.0.1.152ubuntu1, so nl mirror seems to be out of date; so that needs to get fixed, or the mirror taken out of the mirror list
[15:08] <bdmurray> slangasek: right, in #ubuntu-mirrors now
[15:08] <slangasek> ok
[15:10] <bdmurray> slangasek: I've found 3 so far that are out of date
[15:10] <slangasek> yuck
[15:16] <davmor2> mvo, pitti: hey guy I got an issue with jockey and ati (post-release updates) it won't install the driver paste.ubuntu.com/706773 is jockey log,  I'm assuming there is no driver and that is the issue but I expect it to install the current and then update to the latest if I select it.
[15:17] <didrocks> barry: hey, I tried your "from __future__ import unicode_literals", but I still get some "UnicodeEncodeError: 'ascii' codec can't encode character", I guess that's due to the launchpad results I get, any trick?
[15:18] <barry> didrocks: wow, sorry, i've forgotten the details of our previous chat ;)
[15:19] <didrocks> barry: well, notC related for this time, but I raised that we recently got random UnicodeEncodeError: in oneiric (since starting september I would say) in various python apps (software-properties, apport, oneconf…) without any code change
[15:20] <didrocks> barry: and there, I have one when trying to write to a file, the data comes from launchpad, I guess I need to decode in ascii with just ignoring unicode character, or is there a smarter way?
[15:20] <barry> didrocks: ah right.  i was also musing with mvo about this i think.  i wondered whether the default encoding for the file had changed.
[15:21] <barry> didrocks: i don't remember how the data comes from lp.  is it utf-8 text, latin1 or ascii text, bytes?
[15:21] <barry> i guess not ascii text though :)
[15:22] <didrocks> barry: it's utf-8 from what I remember (but it's not only with launchpad, the issue happened recently with loading translation for instance)
[15:22] <barry> didrocks: right, i'm remembering now
[15:25] <barry> didrocks: do you have an example that i can try to reproduce here locally?  i can recommend a hammer to keep you going (basically using errors='replace' or errors='ignore'), but since this is coming up in several cases, it might be better to dig in a little on what's going on
[15:25] <didrocks> barry: if you are not afraid by using a french locale, yeah :)
[15:26] <barry> didrocks: well, maybe in a vm :)
[15:26] <barry> didrocks: english locales already freak me out :)
[15:27] <didrocks> barry: ahah ;) just "bzr branch lp:oneconf", and apply this patch to remove my workaround: http://paste.ubuntu.com/706780/
[15:28] <didrocks> barry: then ./oneconf-query --help should badly fail
[15:28] <didrocks> (on french locale)
[15:29] <barry> didrocks: cool.  it'll take a little bit to get the vm fired up, and i need to run out for lunch.  let me get started on this and i'll ping you in a little while
[15:29] <didrocks> barry: sure! enjoy your lunch :)
[15:29] <barry> didrocks: thanks!  (not fun though, i have to get my car emissions inspected :)
[15:29] <barry> -- and i'm already a month late
[15:30] <didrocks> urgh :/
[15:30] <barry> yeah, when they threaten to suspend your registration, it's time to finally do it :)
[15:30] <barry> didrocks: anyway, is there a bug that i can comment on when i have some more information?
[15:31] <didrocks> barry: well, I closed it with the workaround, I'll open one and ping you back with it
[15:31] <barry> didrocks: perfect. feel free to subscribe me to it too
[15:31] <didrocks> will reference other recent issues we have as well
[15:31] <didrocks> sure
[15:37] <SpamapS> pitti: I didn't.
[15:47] <pitti> davmor2: this log shows that the fglrx-updates driver has been installed just fine
[15:47] <pitti> davmor2: what's wrong with it?
[15:48] <davmor2> pitti: Jockey exits and says check the log
[15:49] <davmor2> pitti: also the interface says that it isn't installed
[15:49] <pitti> davmor2: can you please file a bug with that log and a description what happened? (need to run out in about 10 mins)
[15:49] <pitti> davmor2: I see one error there, but I need to discuss that with tseliot first
[15:49] <davmor2> pitti: yeap no worries
[15:49] <pitti> davmor2: please let me know the number here
[15:50] <davmor2> pitti: will do
[15:50] <tseliot> here I am
[15:50] <pitti> thanks
[15:50] <pitti> davmor2: the driver package is installed, though
[15:50] <pitti> tseliot: it says
[15:50] <pitti> ERROR: xorg:fglrx_updates: get_alternative_by_name(fglrx-updates) returned nothing
[15:51] <tseliot> pitti: that should be correct if the package hasn't been installed yet
[15:51] <pitti> tseliot: so either it's calling the nvidia-common alternatives handling wrongly (i. e. returning None is valid), or some symlinks are broken on that box?
[15:51] <pitti> tseliot: but it was
[15:51] <pitti> dkms completed and all that
[15:52] <pitti> it's before calling set_alternative(), though
[15:52] <pitti> tseliot: it's in ./data/handlers/fglrx.py line 90 apparently
[15:52] <pitti> tseliot: i. e. XorgDriverHandler.enable(self) finished, which does all teh "install pacakge" stuff
[15:52] <pitti> so it aborts and doesn't call set_alternative
[15:53] <pitti> admittedly I'm not sure what that does
[15:53] <pitti> davmor2: does the driver actually work?
[15:54] <tseliot> pitti, davmor2: the output of "update-alternatives --display x86_64-linux-gnu_gl_conf" and of "update-alternatives --display i386-linux-gnu_gl_conf" might help
[15:54] <davmor2> pitti: unfortunately I need the system up and running so I installed the standard one after I got the logs for you so I'm not sure,  I have a spare ati box to my left I can try it again there and capture it all for you
[15:54] <pitti> ok, thanks
[15:54]  * pitti waves good night then
[15:57] <tseliot> ok, I guess I'll take off too then
[16:13] <Nafallo> slangasek: hey. I spoke to didrocks, and my bug is fixed already. he has a pending upload waiting to be accepted. just FYI etc :-)
[16:13] <Nafallo> infinity: ^--
[16:15] <infinity> Nafallo: Accepted to get people testing the new one.
[16:15] <Nafallo> infinity: \o/ ^-- didrocks :-)
[16:16] <didrocks> thanks infinity, Nafallo :)
[16:16] <didrocks> infinity: you need the new compiz and new compiz-plugins-main
[16:16] <infinity> didrocks: Yeah, I accepted both.
[16:16] <didrocks> thanks :)
[16:19] <mdeslaur> pitti: postgresql successfully built. Could you redirect the two other armel builds, so I can push the update while we investigate?
[16:28] <slangasek> Nafallo: ok - did you still mark the bug verification-failed? :P
[16:28] <Nafallo> slangasek: I did, but revert once it didn't fix the issue.
[16:28] <mdeslaur> lamont: looks like pitti is gone. Could you redirect my two postgresql builds to the old armel builders?
[16:29] <Nafallo> slangasek: it seems to be some combination bug with various compiz packages involved. I poked didrocks instead when I got confused enough :-)
[16:30] <didrocks> slangasek: there is a new bug covering this issue in the latest upload (it's a regression)
[16:30] <slangasek> didrocks: is it a regression between the version in the release pocket and the one in the proposed pocket?
[16:30] <didrocks> slangasek: right
[16:31] <infinity> mdeslaur: Did you two determine earlier that postgres fails on pandas?
[16:31] <slangasek> didrocks: then it is CRITICAL to document this on one of the SRU-linked bug reports from the previous upload with the verification-failed tag
[16:31] <infinity> mdeslaur: Any plan to debug that on scheat?
[16:31] <slangasek> otherwise, SRU team members who aren't sitting here in this conversation right now don't know not to publish it
[16:31] <mdeslaur> infinity: pitti was looking for a panda server he could play with to figure it out
[16:32] <cjwatson> (and might not remember even if they were in this conversation - I process SRUs to -updates mostly in robot mode)
[16:32] <infinity> mdeslaur: That would be scheat.
[16:32] <didrocks> slangasek: hum? the new upload in -proposed overwrite the previous version, ,isn't it?
[16:32] <infinity> mdeslaur: I told him about it too. :P
[16:32] <Daviey> uh?
[16:33] <mdeslaur> infinity: do you have the magic permissions required to redirect my two builds to the old builders for now?
[16:33] <Daviey> didrocks: re-using the same version string for a -proposed upload that was rejected?
[16:33] <infinity> mdeslaur: Where are these builds you needed bounced to specific machines?
[16:33] <cjwatson> oh, if there's a new version in -proposed already, that should be fine
[16:33] <didrocks> Daviey: no, a new upload with a new version as the version in -proposed has been published
[16:33] <Daviey> ahh. cool.
[16:33] <mdeslaur> infinity: they are in the security ppa, postgresql-8.4 on maverick and natty
[16:33] <didrocks> cjwatson: yeah, there is no chance the previous version to be published in -updates, right?
[16:34] <infinity> mdeslaur: I might not have access to your PPA.  But if you retry them, I'll make sure they land where they need to be.
[16:34] <mdeslaur> infinity: ok, hitting the retry button now
[16:34] <cjwatson> didrocks: no
[16:34] <didrocks> thanks cjwatson
[16:35] <mdeslaur> infinity: done
[16:35] <infinity> mdeslaur: And done.
[16:35] <infinity> mdeslaur: Just the two builds, right?
[16:35] <mdeslaur> infinity: one started on actinidiaceae, and the other on adoxaceae
[16:36] <mdeslaur> infinity: yeah, just those two. Thanks a bunch.
[16:36] <infinity> mdeslaur: I'm not in the security team anymore, so all I see is "Private Source". ;)
[16:36] <infinity> mdeslaur: But thanks for confirming.
[16:36] <mdeslaur> infinity: t0p s3cr3t
[16:39] <slangasek> didrocks: has the new upload to -proposed been accepted into -proposed yet?
[16:39] <cjwatson> slangasek: yes, it's in the publishinghistory
[16:42] <slangasek> cjwatson: ok then :)
[17:00] <slangasek> infinity: loving this bug now
[17:01] <slangasek> infinity: are there magic ssseeee2222 optimizations in zlib1g?
[17:01] <slangasek> (did I get enough esses in that?  I'm not sure)
[17:08] <infinity> slangasek: I really hope not.
[17:08] <infinity> slangasek: Also, I couldn't reproduce it on kakadu. :/
[17:08] <Nafallo> I tried out didrocks new binaries. They work for me. what do I need to do next? :-)
[17:08] <infinity> slangasek: So, my babbage versus panda theories are tenuous.
[17:09] <slangasek> You assume all babbages are broken the same way? ;)
[17:10] <infinity> slangasek: *headdesk*
[17:24] <Laney> bdmurray: your script seems to hit bugs multiple times, for example bug 871548
[17:25] <bdmurray> Laney: it doesn't check to see if the sponsors team has been removed yet
[17:26] <bdmurray> Laney: I'll see if I can squeeze that in today
[17:27] <Laney> awesome
[17:27] <Laney> :-)
[18:27] <bryceh> jml, are you still experiencing bug #849782?  seems our diagnostics aren't turning up anything useful so far, and I'm wondering about maybe forwarding it upstream if it still occurs.
[18:56] <davmor2> pitti: sorry for the delay work got in the way, doing the 64bit install on the spare box now I'll let you know once I file the bug the number
[20:11] <slangasek> seb128: 736153> oh, you assigned this to freetype?  freetype doesn't choose the glyphs, fwiw
[20:12] <seb128> slangasek, fontconfig does? ;-)
[20:12] <slangasek> no, pango
[20:12] <seb128> hum, k
[20:12] <seb128> I've not clue about fonts :p
[20:12] <slangasek> freetype just renders the glyph it's asked for :)
[20:12] <seb128> slangasek, feel free to reassign at the right place, g-c-c was just wrong ;-)
[20:12] <seb128> slangasek, thanks
[20:12] <slangasek> yep - reassigned already
[20:13] <slangasek> but it's fontconfig - picks which fonts to use; pango - picks which glyphs are needed for a string; freetype - turns those glyphs into graphics
[20:16] <davmor2> pitti: bug 873058 with recorded video, if there are any logs etc that you need I've not added the driver this time, so I can do any tests that you need doing
[21:01] <jml> bryceh: yes, I am.
[21:01] <jml> bryceh: whenever my system is under load or when I'm watching youtube videos
[21:13] <jdstrand> broder: hi! you have a work item from https://launchpad.net/ubuntu/+spec/security-o-catch-all: "[broder] write a script to report -backports packages that need an update due to -security"
[21:14] <jdstrand> broder: whatever happened to this?
[21:14] <jdstrand> broder: iirc, you weren't in the session, but ScottK said it was something you were already working on
[21:26] <bryceh> jml, great thanks
[21:27] <jml> bryceh: I can demonstrate in Orlando, if that will help
[21:28] <bryceh> jml, maybe...  I'm guessing that the issue is that the driver's not able to keep the gfx pipeline full 100% and when it isn't the monitor glitches
[21:29] <bryceh> but I'm not sure  how to prove or disprove that, so it's kind of a useless guess :-/
[21:29] <bryceh> jml, what I think I'll do is forward your bug upstream; maybe they can shed more light on it
[21:29] <jml> bryceh: ok. thanks.
[21:30] <bryceh> jml, oh one thing you could doublecheck... boot a natty livecd and just verify that you definitely aren't seeing the issue in natty
[21:31] <jml> bryceh: ok. I can do that. (although not tonight, I'll make a note.) I'll also try to reproduce on a clean oneiric live stick, as I don't think I have yet.
[21:31] <bryceh> that'll help eliminate any chance it's just hardware (e.g. degraded power supply), and firm up the known-good side of the regression
[21:31] <bryceh> jml, thanks
[21:32] <jml> bryceh: I'm guessing the fix won't be in the release anyway :)
[21:34] <bryceh> jml, nope
[21:34] <bryceh> jml, chance of an SRU though.  we'll see
[21:49] <barry> cr3: ping
[21:51] <cr3> barry: pong, what's up?
[21:51] <barry> cr3: did we talk recently about UnicodeEncodeErrors with i18n?
[21:52] <cr3> barry: that rings a bell but I wouldn't remember the specifics though
[21:55] <barry> cr3: okay, i was talking to didrocks earlier today about a similar problem, which i figured out.  i thought at the time maybe it was mvo i'd talked to, but now i think it was you.  anyway, i could forward you the message i sent to didrocks about it if you care, or you can just read my blog post about it when i publish it :)
[21:58] <cr3> barry: I haven't found a place for blogs in my life, so I'd be very interested in an email forward. thanks for following up!
[21:59] <barry> cr3: will send...
[22:19] <broder> jdstrand: yeah, sorry - didn't happen. should be postponed
[22:20] <broder> bah. it would be nice if do-release-upgrade would drop me to a shell or something to recover instead of just bailing when something went wrong
[22:22] <jdstrand> broder: ok
[22:26] <slangasek> bdmurray: hmm, does apturl work for you at all?
[22:27] <slangasek> fails for me with a missing-icon error
[22:30] <bdmurray> slangasek: yes it seems to work for me
[22:31] <slangasek> ok
[22:31] <slangasek> guess I should file a different bug :)
[22:47] <tumbleweed> broder: that is something that should be quite easy to do in a UDD query
[22:47] <broder> tumbleweed: hmm, i hadn't thought of that
[22:47] <broder> i was going to go do awful things with lplib
[22:47] <broder> but i still won't have time to implement it before tomorrow
[22:48]  * tumbleweed just tried a few ideas, but they are turning up 0 results. That could just mean that the backports team is on top of things... :P
[22:48] <broder> unlikely
[22:48] <broder> SpamapS: what's the deal with the network configuration thing? i thought i just needed to remove eth0 from /etc/network/interfaces and let NM deal...
[22:51] <tumbleweed> Laney: do you know anything about the ubuntu_sources UDD import? It only has the release pocket (and has some pretty unecessary columns)
[22:51] <broder> geez...i don't think i've ever broken my system this badly on an upgrade before...
[22:51] <Laney> no
[22:52] <SpamapS> broder: indeed, that should do it.
[22:52] <Laney> i only did the ubuntu_upload_history one
[22:52] <Laney> lucas: ^^^
[22:52] <broder> i think.../run isn't getting bind-mounted onto /var/run...
[22:52] <SpamapS> lrwxrwxrwx 1 root root 4 2011-10-08 19:20 /var/run -> /run
[22:52] <SpamapS> no, its a symlink
[22:53] <broder> mine isn't
[22:53] <SpamapS> I did upgrade a long time ago..
[22:54] <SpamapS> so its possible I missed one of those "hey everybody if you already upgraded do this" emails
[22:54] <broder> no, it looks like that's what the base-files postinst is supposed to do
[22:55] <broder> ...i wonder what would happen if i changed my sources.list entries back to natty and re-ran the upgrade
[22:55] <broder> nope
[22:56] <ajmitch> broder: how badly have you broken it?
[22:56] <broder> well, apparently the /var/run -> /run migration code didn't run, so i'm going to go with "badly"
[22:56] <slangasek> broder: is /etc/rc6.d a mess?
[22:56] <slangasek> do you have vmware packages installed?
[22:56] <broder> slangasek: i do!
[22:57] <broder> (rc6.d is not a mess)
[22:57] <slangasek> yeah, vmware has decided you don't need a shutdown "sequence", hth
[22:57] <slangasek> broder: are you sure it's not a mess? possibly with 'reboot' and 'umount' scripts running in parallel? :P
[22:57] <slangasek> is this a leading question?
[22:58] <slangasek> bug #858122
[22:58] <slangasek> hmm, except there was another bug that talked explicitly about the vmware problem
[22:59] <broder> oh good grief
[23:01] <broder> slangasek: so is there a reasonable way to clean this up, or do i have to settle for the unreasonable way of just fixing up /var/run and /var/lock by hand?
[23:02] <slangasek> broder: well, you can fix rc6.d by hand and then reboot... then /etc/rc6.d/S60umountroot will take care of it for you
[23:03] <slangasek> realistically you need to reboot afterwards anyway, so that might be simplest
[23:04] <slangasek> not finding the bug that explains vmware being at fault, hrm
[23:05] <broder> weird that this only happened on one of my machines - i upgraded another one with vmplayer installed and that was fine
[23:05] <broder> maybe it's workstation specific? i've only ever had that installed on this one, though i don't currently
[23:05] <slangasek> that sounds correct
[23:06] <broder> err, "don't have it installed currently"
[23:06] <slangasek> broder: you do have reboot with a link of something like S03reboot though, right?
[23:06] <slangasek> instead of S90 like it's meant to have?
[23:06] <broder> yeah
[23:06] <slangasek> yeah, that's the symptom
[23:06] <broder> the whole order is screwed up - almost all of htem are S03, except for urandom and casper which are S04
[23:07] <slangasek> heh
[23:07] <slangasek> been getting much disk corruption on reboot lately?
[23:07] <broder> wouldn't have noticed
[23:08] <broder> dbus wasn't starting because /var/run/dbus/pid was sticking around
[23:08] <broder> it goes downhill from there pretty quickly
[23:09] <broder> actually, i guess one of my disks got ejected from the raid 1...
[23:10] <slangasek> right, I mean corruption *prior* to upgrade... since the rc6 screwup probably happened some time in the past
[23:12] <slangasek> oh, here it is. https://bugs.launchpad.net/ubuntu/lucid/+source/sysvinit/+bug/616287
[23:12] <slangasek> https://bugs.launchpad.net/ubuntu/lucid/+source/sysvinit/+bug/616287/comments/93
[23:21] <bryceh> GrueMaster, here's your next airline cost-cutting move - http://www.huffingtonpost.com/2011/10/12/ryanair-removing-toilets-planes-seats_n_1006604.html
[23:23] <GrueMaster> NOOOOOOOO!!!!!!!!
[23:25] <bryceh> but if no loo, just do the Depardieu
[23:25] <slangasek> Ryanair, motto: "We love to fly on a different airline"
[23:26] <sladen> GrueMaster: I assume it's going to hit the same issue as the last time around: the airframe is certified for X seats, and that's the same X that Ryanair already have fitted.  There is a mandated ratio of X passengers to Y staff … and so would require an additional member of staff too
[23:39] <GrueMaster> I'd say charge extra for the toilets and consider them "Executive Class".