[00:01] <mwhudson> so still getting occasional freezes in natty then :( (sandy bridge)
[00:02] <mwhudson> RAOF: good morning :)
[00:21] <RAOF> mwhudson: Yo :)
[00:21] <mwhudson> RAOF: is there any way i can debug random occasional system hangs
[00:21] <mwhudson> ?
[00:22] <RAOF> mwhudson: If it's a GPU hang then /sys/kernel/debug/dri/0/i915_error_state should contain a fine haul of GPU state that will be incomprehensible to mortals but very useful for people who've actually internalised the i915 developer docs.
[00:23] <mwhudson> sadly it says "/sys/kernel/debug/dri/0/i915_error_state"
[00:23] <mwhudson> how do i tell if it's a GPU hang?
[00:23] <mwhudson> i was assuming it was but maybe not
[00:23] <RAOF> If you ssh in then everything but the display should work.
[00:23] <mwhudson> (looking at that file after rebooting obviously...)
[00:23] <mwhudson> ah ok
[00:23] <RAOF> Yeah, that file's only good while the kernel's up.
[00:24] <mwhudson> it feels 'more hung' than that
[00:24] <mwhudson> but haven't actually tried ssh for a while
[00:24] <RAOF> If you turn on apport it should pick up on a gpu hang and record that data for you.
[00:24] <mwhudson> how do i do that? :)
[00:25] <RAOF> Twiddle the knob in /etc/default/apport
[00:26] <mwhudson> so twiddled
[00:27] <mwhudson> which will presumably prevent all hangs for at least a month
[00:31] <RAOF> That's the way it rolls :)
[00:31] <mwhudson> (i should say this situation would be good in some ways :p)
[00:41] <RAOF> mwhudson: In case you're interested, oneiric now is doing well by this (particularly troublesome) SandyBridge.
[00:42] <mwhudson> RAOF: right, i was somewhat assuming that the real answer is "upgrade to o"
[00:42] <RAOF> Well, it shouldn't be.  :/
[00:42] <RAOF> It might be the easiest answer, though.
[04:18] <pitti> Good morning
[04:18] <madnick> morning
[05:45] <didrocks> good morning
[06:14] <BigWhale> Where would I go to ask something about Vala and GTK3 and positioning of widgets? :)
[08:55] <astraljava> Thanks infinity and slangasek! I'm filing that bug then, soon.
[09:17] <jamespage> doko_: around?  have a bit of a maven2/antrun-plugin pickle caused by a sync last week that I could do with an opinion on
[09:22] <doko_> jamespage, yes, online
[09:23] <jamespage> doko_: OK - so there was a sync of maven-antrun-plugin last week which upped the version from 1.3->1.6
[09:24] <jamespage> doko_: unfortunately this breaks anything using the antrun-plugin without an explicit version as 1.3 is declared in the global maven2 POM - I hit this is Debian when the change happened there
[09:25] <jamespage> doko_: it needs a sync of maven2-core and maven2 to update to 1.6 - but that also pulls in two other package version upgrades - maven-plugin-tools and jtidy
[09:26] <jamespage> doko_: I could either go for FFE's on those two packages (but there is a possibility of further impact that we are not aware of) or I could delta maven2-core and maven2 in Ubuntu to fix this specific issue
[09:26] <jamespage> doko_: I raised the syncs and then had second thoughts - hence the ping
[09:26] <jamespage> doko_: whats your opinion
[09:26] <jamespage> ?
[09:38] <doko_> jamespage, ouch. I wouldn't worry much about maven-plugin-tools, I'll have a look at jtidy
[09:39] <jamespage> doko_: thanks
[09:39] <jamespage> doko_: so we should go with the syncs/upgrades if possible then?
[09:40] <doko_> urgh, jtidy update from 2007 to 2011 ...
[09:43] <doko_> jamespage, jtidy hasn't many rdepends, and just jmeter is out of sync
[09:52] <doko_> jamespage, well, I would aim for the syncs. it doesn't look too bad
[10:18] <jamespage> doko_: ack - on it now
[11:38] <OdyX> tkamppeter: could you please retry pxljr from the git repository; I fixed the repacking that threw too much stuff out and now the test command doesn't fail anymore here. Still have to try a real print, but linking + test-command works.
[11:49] <agateau> bdrung: hi, I have been told you maintain lp-project-upload. It stopped working here. Do you have a few minutes?
[12:31] <tkamppeter> OdyX, will do.
[12:32] <OdyX> tkamppeter: (the issue what that I stripped more than needed of the jpeg convenience copy and then broke something. Restoring those files make the printing work here (tested over internet to my father's printer :-) )
[12:50] <bdrung> agateau: i co-maintain ubuntu-dev-tools, but i didn't wrote lp-project-upload. looking at the source code, i found Martin Pitt (pitti) and Dustin Kirkland (kirkland).
[12:51] <agateau> bdrung: oh ok, will ping one of them then, thanks
[12:52]  * agateau picks a name at random
[12:54] <agateau> pitti: hi, do you have a few minutes to look into an lp-project-upload problem?
[12:55] <pitti> agateau: what's the problem?
[12:56] <agateau> pitti: it fails to upload, telling me something like this: "Could not connect to Launchpad: File contains parsing errors: <???>"
[12:56] <agateau> pitti: and then two other lines of <???>
[12:56] <pitti> that sounds like a launchpad lib problem -- can you try moving ~/.launchpadlib away ?
[12:56] <agateau> pitti: sure
[12:57] <agateau> pitti: same error :/
[12:59] <pitti> agateau: do you get the same with lp-shell ?
[12:59] <agateau> pitti: never used lp-shell, let me try
[12:59] <agateau> pitti: yes, with a backtrace
[13:00] <agateau> pitti: http://pastebin.com/hzAqkWfj
[13:01] <pitti> apparently something is wrong with your credentials file
[13:02] <pitti> but I'm not sure where lplib takes that from; I had assumed ~/.launchpadlib/
[13:02] <pitti>     def do_load(self, unique_key):
[13:02] <pitti>         """Retrieve credentials from the keyring."""
[13:02] <pitti> oh
[13:02] <pitti> gnome-keyring
[13:03] <pitti> so it somehow needs to be removed there, or better yet, the launchpad guys should have a look why the broken one got in in the first place
[13:03] <pitti> I don't see an obvious one in seahorse
[13:04] <agateau> could it be related to me running kde?
[13:04] <pitti> and I really have no idea how lplib handles credentials since the natty version, I'm afraid; that made everything utterly complicated
[13:04] <pitti> agateau: could be; it might try the KDE equivalent of the keyring
[13:05] <agateau> pitti: so next step would be to ping the launchpad guy then, right?
[13:05] <agateau> s/guy/devs/
[13:05] <pitti> yeah; I'm afraid I have no knowledge about its current key handling :/
[13:07] <agateau> pitti: no problem, thanks for pointing me in the right direction
[13:09] <debfx> agateau: are you using natty or oneiric?
[13:09] <agateau> debfx: oneiric
[13:11] <debfx> I remember having similar issues with python-keyring in natty
[13:12] <agateau> debfx: did you find a workaround?
[13:13] <debfx> agateau: you could try to remove the launchpadlib entries from kwallet, maybe that helps
[13:14]  * agateau tries
[13:19] <agateau> debfx: it fixes in once: I get to authorize lp-shell from launchpad again, lp-shell works correctly, but if I start it again it fails
[13:20] <agateau> debfx: there is probably something wrong with the way credential are stored
[13:20] <tkamppeter> OdyX, the ijs_pxljr executable in your package is now built correctly. I can actually print in all three quality modes.
[13:21] <OdyX> tkamppeter: yay, great. Then if you don't have more comments, I'll prepare the (secret) changelog and upload to Debian (where it will spend some time in NEW anyway).
[13:22] <debfx> agateau: ah now I remember, I came up with this workaround: http://pastebin.com/raw.php?i=T0YiYKz6
[13:23]  * agateau tries
[13:24] <agateau> debfx: it works! thanks!
[13:24] <agateau> debfx: did you file a bug for that?
[13:26] <debfx> agateau: no, I'm not sure if it's a bug in launchpadlib oder python-keyring
[13:27] <tkamppeter> OdyX, OK.
[13:27] <agateau> debfx: I have no idea either, but I assume the launchpadlib devs would know
[13:27] <debfx> s/oder/or/ ^^
[13:27]  * agateau knows a bit of german :)
[13:27] <OdyX> tkamppeter: cool, thanks for the review and test !
[13:31] <tkamppeter> OdyX, I want to replace/update the upstream snapshot of foomatic-db in the foomatic-db package GIT. How do I proceed?
[13:32] <OdyX> tkamppeter: uscan --verbose downloads the latest; then git-import-orig
[13:32] <OdyX> tkamppeter: actually; git-import-orig --pristine-tar
[13:32] <OdyX> tkamppeter: make sure to have a big enough TMPDIR (/tmp) or override it with TMPDIR=~/
[13:38] <tkamppeter> I am in the foomatic-db directory cloned from GIT and I am in the master branch. There I have entered the command "uscan --verbose" and after some time the download into the parent directory  (..)  happened.
[13:38] <tkamppeter> OdyX, ^^ Then I ran, staying in foomatic-db/, "git-import-orig --pristine-tar ../foomatic-db_20110831.orig.tar.gz" and get
[13:38] <tkamppeter> gbp:error:
[13:38] <tkamppeter> Repository does not have branch 'upstream' for upstream sources. If there is none see
[13:38] <tkamppeter> file:///usr/share/doc/git-buildpackage/manual-html/gbp.import.html#GBP.IMPORT.CONVERT
[13:38] <tkamppeter> on howto create it otherwise use --upstream-branch to specify it.
[13:39] <tkamppeter> OdyX ^^
[13:39] <OdyX> tkamppeter: git checkout upstream
[13:40] <OdyX> tkamppeter: this creates a "--track" branch from the upstream branch on the remote repository
[13:40] <OdyX> you could checkout pristine-tar too
[13:40] <OdyX> and then checkout master again before runninf the git-import-orig
[13:42] <OdyX> ah tkamppeter: did pxljr compile with the B-D on libjpeg-dev or do you need a libjpeg-dev | libjpeg8-dev ?
[13:45] <debfx> agateau: there you are: bug #838108
[13:46] <agateau> debfx: thanks, marked it as affecting me
[14:05] <sladen> pitti: cjwatson: https://bugs.launchpad.net/ubuntu/+source/indicator-session/+bug/835161  is this the timestamp file being created by packages too early---not entirely where to send it as presumably the fix to to have the menu back-off until it sees that the upgrade process has actually happened, beforing the reboot-required?
[14:07] <cjwatson> the timestamp file can't be created later without decoupling it from packages, which is bad for maintainability reasons
[14:07] <cjwatson> so I think it'd be better for the menu to back off, yes
[14:07] <tkamppeter> OdyX, for pxljr I did not need to modify debian/control. So the B-D on libjpeg-dev worked out for me, building the package with libjpeg62.
[14:08] <tkamppeter> OdyX, import of new foomatic-db source worked for me now. Thanks.
[14:14] <OdyX> tkamppeter: great²
[14:15] <tkamppeter> OdyX, is it enough to "git commit -a", "git push", and "git push --tags" in master or do I have to do this sequence in all master, upstream, and pristine-tar?
[14:16] <OdyX> tkamppeter: it depends on your configuration. I usually "git add" only what I want in the commits, then commit, then git push <remote> <branches,tags,..>, explicitely specifying what I want to push.
[14:16] <OdyX> in your case that would be git push origin master upstream pristine-tar upstream/20110831 ubuntu/20110831-0ubuntu1 e.g.
[14:45] <janimo> Sweetshark, can we close the 'enable binfilter on ARM' as wontfix?
[14:53] <tkamppeter> Can it be that LP is down currently?
[14:56] <sladen> tkamppeter: it was, I went and made drinks
[14:57] <nigelb> sladen: Could use of time
[14:57] <Sweetshark> janimo: yes, binfilter will be killed upstream anyway rather sooner than later (god riddance)
[14:59] <janimo> tkamppeter, LP gave me some timeouts a few minutes ago too
[15:03] <tkamppeter> It came back again.
[16:00] <hallyn> slangasek: woudl you (as last submitter :) accept a merge of systemtap from sid for oneiric still?
[16:00] <hallyn> bc without a commit from jun 21, it seems unusable
[16:00] <hallyn> http://comments.gmane.org/gmane.linux.systemtap/17948 in particular
[16:01] <slangasek> hallyn: it should go through the FFe process; of course if it's currently unusable, the barrier is lower, but we should still weigh the advantages of a full update vs. a cherry-pick
[16:02] <hallyn> makes sense.  thanks.
[16:02]  * hallyn starts by filing lp bug ...
[16:13] <ScottK> jelmer: I see bzr 2.4.0-3ubuntu1 in the unapproved queue, so I'm going to reject 2ubuntu1.
[16:18] <bdmurray> slangasek: this is a plymouth bug right? http://imgur.com/85iDX
[16:21] <slangasek> bdmurray: what's the complaint?  That's the plymouth text screen; is the complaint that it's not graphical?
[16:21] <bdmurray> slangasek: no the cursor at the end of the .....
[16:21] <slangasek> bdmurray: ah - is that persistent? I wondered if it was caught mid-flight
[16:22] <slangasek> would be a plymouth bug anyway, yes
[16:22] <bdmurray> slangasek: it showed up close to the end and blinks
[16:23]  * hallyn curses the warn-on-set-but-not-used busywork
[16:24] <cjwatson> if you feel it's too much busywork, drop -Werror
[16:25] <cjwatson> (which is a constant pain in the rear at a distribution scale anyway)
[16:25] <hallyn> i'm not adding -Werror though...  i thought that was being auto-added now?
[16:26] <cjwatson> no
[16:26] <cjwatson> that would be insane
[16:26] <hallyn> yeah...
[16:26] <hallyn> eh, I think I see it, thanks
[16:29] <bdmurray> slangasek: bug 838218
[16:30] <slangasek> bdmurray: ta
[16:32] <cr3> pitti: how could I tell what might be the impact of adding a dependency to the size of the desktop image?
[16:33] <cr3> hm, that actually sounds like a job for germinate which I endup having to relearn every six months :(
[16:38] <infinity> Am I missing some critical package to make GTK3 applications get properly themed in Xubuntu, or are they just doomed to be ugly?
[16:38] <pitti> cr3: try to apt-get install it in a live session
[16:40] <superm1> infinity, you need to pick a GTK theme in the xfce4-appearance-properties that contains a GTK3 option
[16:40] <superm1> just fixed it for mythbuntu by creating a copy of Ambiance's gtk3 theme and Dust's gtk2 theme in a single "Mythbuntu" theme
[16:40] <infinity> superm1: Ahh, oh.  Is there a way to tell that from the UI, or do I just need to dig through the filesystem?
[16:40] <lynxman> Hey everyone, I'm trying to solve bug 818177
[16:41] <micahg> infinity: please file a bug if we're not seeding something, I think our first GTK3 theme just got in
[16:41] <superm1> infinity, don't beleive there is any way to tell from the UI.  The only themes that I know of in the archive right now are Ambiance and Radiance
[16:41] <lynxman> jhunt_: Daviey: you around here?
[16:41] <Daviey> lynxman: urgh, that strace is horrible.
[16:41] <mr_pouit> infinity: you can try the latest greybird, there's a gtk3 theme (using the unico engine)
[16:41] <lynxman> Daviey: it's on a serial link through a VPN through a java interface, I do apologise for its lameness
[16:41] <ogra_> infinity, uglyness is the new bling ;)
[16:41] <pitti> superm1: and gnome-theme-standard, which provides Adwaita (upstream GNOME default)
[16:42] <superm1> pitti, ah cool, wasn't aware of that
[16:42] <cr3> pitti: nice and simple, thanks!
[16:43] <Daviey> lynxman: mountall --debug > mountall.log 2>&1 ?
[16:43] <lynxman> Daviey: I still have no way to recover any file from the system :)
[16:43] <Daviey> lynxman: does it have net access, allowing you to throw the output as txt somewhere?
[16:43] <lynxman> Daviey: it does but the bnx2 module is also broken
[16:43] <Daviey> *sigh*
[16:43] <lynxman> Daviey: so no network for me
[16:44] <Daviey> lynxman: ok.. just mountall --debug then.
[16:45] <lynxman> Daviey: posted in bug
[16:48] <Daviey> lynxman: does it block there, or repeat?
[16:48] <lynxman> Daviey: block
[16:54] <apw> lynxman, so that is a whole new UUID ?  from what was previously noted as mounted as slas
[16:54] <apw> root
[16:54] <lynxman> apw: whole new uuid indeed
[16:55] <apw> lynxman, if you do a cat /proc/mounts where is / is it that a394 (ending) UUID ?
[16:55] <lynxman> apw: no, just a regular "rootfs / rootfw rw 0 0"
[16:55] <lynxman> apw: no, just a regular "rootfs / rootfs rw 0 0"
[16:56] <Daviey> apw: wait *394 is swap
[16:56] <lynxman> Daviey: still the uuid from mountall != uuid from df -h
[16:56] <apw> lynxman, there are two lines for / in /proc/mounts, the seconf one has the UUID
[16:57] <lynxman> *doh* true
[16:57] <apw> lynxman, and yes it is likely trying to instantiate swap ... do a blk-id on your swap device
[16:57] <hrw> superm1: bug 833884 got debdiff
[16:57] <lynxman> apw: second line has the uuid and it's the same shown by df -h
[16:57] <apw> lynxman, and blkid /dev/<swap disk>
[16:58] <superm1> thanks hrw!
[16:58] <superm1> do you need a sponsor?
[16:58] <lynxman> apw: no swap definitions in /proc/mounts
[16:58] <hrw> superm1: yes, otherwise I would not add but would upload
[16:58] <Daviey> superm1: Shouldn't that go into bzr?
[16:58] <lynxman> df -ha
[16:58] <superm1> hrw, ok.  Daviey will put it in bzr and upload then
[16:59] <apw> lynxman, no they are in /etc/fstab
[16:59] <apw> lynxman, what does blkid on your swap device say, presumably you know where that is as you created it recenty
[16:59]  * apw is suspicious you have lost your swap id
[16:59] <lynxman> apw: it's there yes :)
[17:00] <lynxman> apw: and it fits with what mountall tries as well
[17:00] <apw> lynxman, ok so ... blkid will tell us if the real disk has a swap marker on it, and therefore any UUID at all
[17:01] <Daviey> superm1: argh
[17:01] <hrw> superm1: bug 833901 has same solution
[17:02] <lynxman> apw: /dev/.blkid.tab does not exist, the soft link from /etc/blkid.tab is broken :/
[17:03] <apw> lynxman, you can just trun blkid on /dev/cciss<xxx> whatever the partition you added as your swap
[17:04] <lynxman> apw: tried that before, returns empty, I tried it again now
[17:04] <lynxman> apw: same for the / partition
[17:04] <hrw> superm1: bug 833892 is probably also yours
[17:06] <apw> lynxman, so /dec/cciss/c0d0p1 is / ?  and c0d0p5 is swap ?
[17:06] <lynxman> apw: yes, exactly
[17:06] <apw> lynxman, and blkid /dev/cciss/c0d0p1 and blkid /dev/cciss/c0d05 both return nothing ?
[17:06] <lynxman> apw: correct
[17:07] <apw> that is unexpected, how did it find / if that is the case
[17:07] <lynxman> apw: good question
[17:07] <apw> so if swapon -s shows no swap and you are sure p5 is your swap you could try re-adding the swap record
[17:08] <apw> mkswap /dev/cciss/c0d0p5
[17:08] <apw> and see what blkid says on it then
[17:08] <hallyn> smoser: you around and have a minute?
[17:08] <lynxman> apw: yeah, no swap, reswapping that
[17:08] <lynxman> hah
[17:08] <lynxman> apw: /dev/cciss/c0d0p5 : No such file or directory
[17:09] <apw> lynxman, erm perhaps looks see what they are really called then
[17:09] <apw> and go back to the blkid phase
[17:10] <smoser> hallyn, here.
[17:10] <hallyn> smoser: well here is what is happening,
[17:10] <lynxman> apw: /dev is almost empty, no sd* no disk, just fd, core, ram, pts, std(err|in|out), shm
[17:11] <hallyn> udev looks at /dev/ptmx, and if it is not the same device type, ownership and perms as expected, then it replaces it
[17:11] <hallyn> this is fine for lxc, bc it creates the device and bind-mounts it from /dev/pts/ptmx.  So it is the right dev ice type, and udev doesn't replace it
[17:11] <hallyn> libvirt-lxc creates a symlink, so udev replaces that
[17:11] <lynxman> apw: /proc/mounts shows udev mounted at /dev properly
[17:11] <smoser> replaces it as in "re-mounts" ?
[17:11] <apw> lynxman, so you have no devices in /dev
[17:12] <hallyn> no, creates /dev/ptmx.udev-tmp, then does mv /dev/ptmx.udev-tmp /dev/ptmx
[17:12] <smoser> and then why is udev's replacement no good ?
[17:12] <hallyn> It does this in a pretty generic piece of code, which I'm not sure we should complicate for this
[17:12] <lynxman> apw: no devices in /dev/
[17:12] <hallyn> smoser: bc a simple /dev/ptmx device is wrong inthe container
[17:13] <hallyn> you must use /dev/pts/ptmx
[17:13] <hallyn> that is why /dev/ptmx must be either a symlink or a bind mount to that
[17:13] <smoser> ok.
[17:13] <apw> lynxman, so its like udevd didn't do its thing correctly
[17:13] <apw> lynxman, is udevd running ?
[17:13] <hallyn> so...  hm, i suppose this means lxcguest could just create it the right way, rather than libvirt doing it
[17:13]  * hallyn tries
[17:14] <lynxman> apw: it's running, parent process with 2 children
[17:14] <lynxman> apw: also upstart-udev-bridge is started
[17:14] <smoser> hallyn, how will you make it not racy
[17:14] <hallyn> yeah that works
[17:15] <hallyn> because lxcguest starts on startup
[17:15] <smoser> right.
[17:15] <smoser> wel...
[17:15] <smoser> that could potentially happen in parallel to udev though
[17:15] <smoser> right?
[17:15] <apw> lynxman, does udevadm trigger --action=add
[17:15] <apw> do anything
[17:15] <hallyn> smoser: i suppose lxcguest would have to start on starting startup?  if that's possible
[17:15] <hallyn> or just on starting udev
[17:16] <lynxman> apw: it tries to create devices and fails on all of them "failed: Read-only file system"
[17:16] <smoser> hallyn, well, i think we're ok.
[17:16] <apw> lynxman, ok so try touch /dev/X
[17:16] <smoser> udev starts on virtual-filesystems
[17:16] <hallyn> smoser: while i've found the generic code doing this, what kills me is i still haven't found the list where it finds ptmx as one of the devices to check
[17:17] <lynxman> apw: yeah same, Read-only file system
[17:17] <apw> ok that is not right
[17:17] <hallyn> smoser: right, but 'start on startup' doesn't give enough guarantee
[17:17] <apw> what does the /dev line look like in /proc/mounts
[17:18] <lynxman> apw: udev /dev devtmpfs rw,relatime,size=2018084k,nr_inodes=504521,mode=755 0 0
[17:18] <apw> what does df /dev say
[17:19] <lynxman> apw: none   30846908 1466844 27813088 6% /dev
[17:19] <lynxman> apw: Filesystem 1K-blocks Used Available Use% Mounted on
[17:19] <smoser> hallyn, lxcmount.cofn already starts on starting mountall
[17:19] <smoser> oh..
[17:19] <smoser> but its udev
[17:19] <smoser> for petes sake
[17:20] <apw> lynxman, but ... it says udev in /proc/mounts, so its not the same place
[17:20] <lynxman> apw: its type udev mounted in /dev
[17:21]  * Daviey has a udev overload.
[17:21] <lynxman> Daviey: udev!
[17:21] <apw> lynxman, is there more than one line for /dev in /proc/mounts
[17:21] <hallyn> smoser: yeah...
[17:22] <hallyn> Daviey: are you missing devfs?
[17:22] <apw> lynxman, as i have the same line in /p/mounts and yet df on my /dev says udev not none in the first column
[17:22] <lynxman> apw: as a matter of fact... /dev returns same used space and free space as /
[17:22] <cjwatson> udev udev udev udev udev udev udev udev MUSHROOM MUSHROOM
[17:22] <hrw> bug 835768 got debdiff - sponsor anyone?
[17:22] <apw> lynxman, cat /proc/mounts | grep /dev
[17:22] <lynxman> cjwatson: ktraceee ktraceee oooh it's a ktraceeeee
[17:22] <apw> i think you have a bind mount on there too
[17:23] <lynxman> apw: I also have devpts, no other lines for /dev
[17:23] <apw> lynxman, ok lets try unmount /dev
[17:23] <apw> and see what it does
[17:23] <apw> then df /dev
[17:23] <micahg> hrw: sorry, was supposed to be piloting today, but had to reschedule will get to it next week unless someone else does it first
[17:23] <lynxman> apw: okay!
[17:24] <lynxman> apw: says /dev not mounted, hah
[17:24] <lynxman> apw: if I do mount /dev now all the devices show up
[17:24] <hrw> micahg: no problem
[17:24] <lynxman> apw: so it looks like it can't mount /dev?
[17:25] <hrw> bug 835765 also got sponsors subscribed
[17:25] <apw> lynxman, though /dev is mounted as we come out of the kernel and gets mount --move'd i think into real /
[17:25] <Daviey> hrw: Yeah, no problem for micahg.. superm1 kindly assigned them to me.
[17:25] <apw> so we need to try and trace why that failed ...
[17:26] <hrw> Daviey: so far my way of going though bugs is: check, fix, upload debdiff, subscribe sponsors (unless bug got someone assigned in meantime)
[17:26] <hrw> Daviey: one day I will try to find out all those bugs, make a list and apply for motu to make this road shorter
[17:26] <lynxman> apw: so... suggestions on how to get that traced?
[17:27] <Daviey> hrw: sounds like a good work flow.. The only thing that would make it more streamlined for the sponsor is to propose it for merging into the bzr branch (as listed in debian/control)
[17:27] <Daviey> hrw: sounds wonderful!
[17:28] <hrw> Daviey: I do not have too much sympathy to bzr (trying to be politicaly correct)
[17:28] <micahg> Daviey: I still prefer debdiffs to bzr branches :)
[17:29] <Daviey> micahg: Yeah, that is great.... unless the package is maintained in bzr. :)
[17:30] <micahg> Daviey: sure, but most aren't at this point
[17:30] <Daviey> yeah
[17:35] <smoser> hallyn, you need my instance ?
[17:37] <hrw> bug 835763 this time
[17:45] <hallyn> smoser: no, i'm using my own, thanks.
[17:45] <hallyn> (you'd replaced the container so iw as afraid of stepping on your toes)
[17:45] <smoser> i just run that lxc-libvirt-whatever script
[17:45] <smoser> and it kills it and starts over
[17:46] <smoser> and i'd jjust rsynce'd from dist.
[17:46] <smoser> btw, hallyn, thank you for your work on this.
[17:48] <hallyn> smoser: np.  this one was a doozy :)  I'm pinging #virt to get their opinion right now.
[18:02] <tgm4883> jdstrand, Daviey said to ping you over here regarding a reply to the mythbuntu-bare rejection email?
[18:03] <jdstrand> tgm4883: yes, I plan to repsond today. sorry for the delay, the email got misfiled
[18:03] <tgm4883> ok, i'll look for it then a little later
[18:03] <Daviey> misfiled in Junk. :)
[18:04] <tgm4883> I blame Daviey, it had to be some British metric system conversion issue
[18:07] <Daviey> most likely.
[18:39] <mterry> zul, so you uploaded a new python-dingus with dh_python2 support, and it's just waiting on archive-admin approval?
[18:40] <zul> mterry: right
[18:40] <mterry> zul, cool
[20:03] <bdmurray> what package that uses dkms can I install and have it fail to build because I don't have the right hardware or something?
[20:04] <kees> hmm zaptel?
[20:04] <kees> bdmurray: I haven't looked in a while, but the zaptel drivers might fail
[20:08] <stgraber> is zaptel still in the archive? I thought it got replaced by dahdi
[20:08] <kees> stgraber: that very well could be. like I said, it's been a while since I had my asterisk server running
[20:12] <bdmurray> well regardless dahdi-linux built okay
[20:12] <bdmurray> bug 790478 seems rather unnecessary
[20:17] <slangasek> I'm not sure why any module would fail to build due to lack of hardware
[20:18] <bdrung> tumbleweed: merged and bug #838361 opened
[20:19] <tumbleweed> oh right
[20:19]  * tumbleweed forgot about that
[20:20] <bdmurray> I was thinking about something lik bug 711397
[21:27] <hallyn> hm,
[21:27] <hallyn> E: Invalid Release signature (key id 40976EAF437D05B5)
[21:27] <hallyn> debootstrapping natty
[21:27] <hallyn> uh, oneiric
[21:28] <jtaylor> is it using the correct keyring?
[21:29] <jtaylor> there were some Release signing issues the last few days, probably your mirror is not yet updated
[21:29] <cjwatson> as far as I know there is nothing wrong with the master archive in this regard
[21:30] <hallyn> ok, thanks.
[21:30] <cjwatson> a mirroring problem is a lot more likely
[21:30] <hallyn> i'd believe it
[21:30] <cjwatson> (I saw problems on gb.archive but not archive)
[21:30] <jtaylor> I saw problems on master archvie yesterday
[21:31] <cjwatson> are you 100% sure there is not a transparent web proxy between you and the archive?
[21:31] <cjwatson> ISPs often pull this kind of stsunt
[21:31] <cjwatson> *stunt
[21:31] <jtaylor> thats possible
[21:31] <cjwatson> $ gpg --verify Release.gpg Release
[21:31] <cjwatson> gpg: Signature made Wed Aug 31 21:18:32 2011 UTC using DSA key ID 437D05B5
[21:31] <cjwatson> gpg: Good signature from "Ubuntu Archive Automatic Signing Key <ftpmaster@ubuntu.com>"
[21:31] <jtaylor> didn't really checked, was working again an hour later
[21:31] <cjwatson> sorry, that's in cjwatson@cocoplum:~/ubuntu/dists/oneiric
[21:31] <cjwatson> (i.e. true master)
[21:32] <ScottK> cjwatson: Not sure if it might be related, but I've been trying to run ./update in kubuntu-meta for the last hour and getting errors like W: http://archive.ubuntu.com/ubuntu/dists/oneiric/main/binary-i386/Packages.bz2 was corrupt
[21:33] <cjwatson> it's possible there's some problem on the central mirrors
[21:33] <cjwatson> might be worth letting #ubuntu-mirrors know
[21:33] <ScottK> OK.
[21:34] <cjwatson> (for clarification, though I think ScottK knows this already - archive.ubuntu.com is a mirror too, the archive is a hidden master arrangement)
[21:34] <ScottK> Yep.
[21:57] <ScottK> jtaylor: As I'm looking at your debian/changelog entry in http://launchpadlibrarian.net/78520283/libindicate_0.5.91-0ubuntu3_source.changes trying to decide if it's important for Oneiric Beta 1 or not, I'm finding what you wrote not very helpful.  It's better to be a little more verbose and describe the actual problems that are fixed (at least briefly).
[21:59] <jtaylor> hm yes they were described better in the merge proposal
[21:59] <jtaylor> the patches were seemingly accidentally dropped in an older revision
[22:00] <jtaylor> causing build failures and memory leaks
[22:01] <jtaylor> the patches were dropped in 0.5.90-0ubuntu1 whih had some rules refactoring
[22:02] <jpds> cjwatson: Which problems?
[22:06] <cjwatson> jpds: same as what ScottK reported above - Release and Packages out of sync while trying to update metapackages
[22:06] <cjwatson> except on gb.archive in my case rather than archive
[22:43] <bdmurray> superm1: could you look at / incorporate my patch in bug 766160?
[23:13] <robert_ancell> @pilot in
[23:25] <ion> @pilot in
[23:26] <ion> Wow. I didn’t expect that to work for anyone.
[23:26] <ion> Sorry for the noise.
[23:26] <ion> @pilot out
[23:32] <micahg> ion: anyone can be a pilot :)
[23:53] <lynxman> hah