[00:00] <xnox> micahg: ah, catched up on my scroll back. Got the #-release now as well ;-)
[00:01] <micahg> xnox: unless you suddenly got a backports hat, that won't be possible :)
[00:06] <xnox> micahg: hmm... i am sure tumbleweed will resign my changes files...
[00:06] <xnox> tumbleweed: is in backports team, right?!
[00:08] <micahg> xnox: nope
[00:08] <xnox> hmmm....
[00:08] <micahg> xnox: but in that case, you're being sponsored
[00:08] <micahg> xnox: but I appreciate the sentiment
[00:09] <xnox> micahg: ah found it =) you! =)
[00:09] <xnox> ;-)
[00:20]  * Bluefoxicy tries to Ctrl+a to switch windows in gnome-shell
[00:20]  * Bluefoxicy dumb.
[00:42] <xnox> Bluefoxicy: It's M-x C-c C-c C-a   emacs people said it is consistent with frame, window and pointer navigation and does not conflict with GPS key bindings
[03:09] <smoser> anyone know or able to enable logging of #maas to http://irclogs.ubuntu.com/2012/08/08/ ?
[03:09] <smoser> s/know/know of how to/
[03:11] <micahg> smoser: file a ticket?
[03:12] <smoser> as in canonical rt?
[03:12] <micahg> either should be fine I think
[06:03] <wzssyqa> qemu-kvm depends ipxe (<< 1.0.0+git-20120202.f6840ba-2), while ipxe has version ipxe (<< 1.0.0+git-20120202.f6840ba-3)
[06:03] <wzssyqa> why qemu-kvm can still be installed?
[06:04] <wzssyqa> has version 1.0.0+git-20120202.f6840ba-3
[06:26] <leo_> hello
[06:27] <leo_> i have a problem with my tbuntu 12.10 alpha3 since yesterday after a update
[06:28] <micahg> leo_: support in #ubuntu+1
[06:28] <leo_> ok micahg
[06:28]  * leo_ thx
[06:53] <dholbach> good morning
[06:59] <didrocks> hey dholbach \o/ welcome back (not sure when your holidays ended)
[07:00] <dholbach> didrocks, today they ended - thanks :)
[07:00] <didrocks> dholbach: good luck with the email catchup then! (and nice photos ;))
[07:01] <dholbach> thanks :-)
[07:01]  * dholbach hugs didrocks
[07:01]  * didrocks hugs dholbach. Good to see you back! :)
[07:09] <sladen>  dholbach
[07:10] <sladen> morning dholbach
[08:29] <mpt> ev, https://bugs.launchpad.net/ubuntu/+source/apport/+bugs?field.tag=classification
[08:33] <seb128> ev, hey, I've some issues with errors.ubuntu.com, want to discuss it there or should I reply to your email for those?
[08:53] <ev> seb128: apols for the delayed reply. I've just seen your email. I'll work on getting those fixed today.
[08:53] <seb128> ev, I'm concerned that all detailed graphs have a 80% drop on 05/17/12, do you know what's up with that
[08:54] <ev> seb128: not sure offhand - I'm going to look into it
[08:54] <seb128> ev, thanks
[09:02] <ev> damn you unicode
[09:02] <ev> (that would be the month option not displaying)
[09:03] <seb128> oh
[09:03] <seb128> I though it would be timeouting ;-)
[09:04] <ev> nope, but it is taking longer than I would expect
[09:04] <ev> I have an open ticket to land some stuff I built around jmxtrans, so we can get graphite plotting cassandra usage
[09:04] <ev> right now we're stuck with either assembling a twisted maze of tunnels or running cassandra's nodetool manually
[09:05] <ev> and then when graphite lands, dormant code on errors.ubuntu.com will start plotting api calls too
[09:26] <gema> Diziet: pong
[09:44] <sladen> ScottK: did you work out a solution to your /opt ?
[09:44] <sladen> YokoZar: did you work out a solution to your /opt ?
[11:58] <seb128> ev, I can't select "12.10" in the version combo on errors.ubuntu.com as well ... I guess it's the same issue than selecting "for the month"?
[12:03] <ogra_> seb128, wrt your thunderbird complaints yesterday, did we consider shipping postler ? or does that add massive amounts of deps ?
[12:04] <seb128> is that the elementary stuff?
[12:04] <ogra_> yep, the mail app is pretty slick
[12:04] <seb128> I doubt anything gets close from tb in support, userbase, features, etc
[12:06] <ogra_> yeah, it only can do mail via pop, imap, and gmail , no nifty extra features
[12:08] <seb128> ogra_, it's also that tb brand,name is known, it's cross platform, and we can trust mozilla to deal with security issues and have a reliable schedule
[12:10] <ogra_> well, i know the pro args for tb :)
[12:42] <mpt> xnox, so ... Raid failures?
[12:43] <xnox> mpt: yeah...
[12:44] <xnox> mpt: there are three things about Raid:
[12:44] <xnox> * individual disk failures (same as all of them) e.g. bad blocks, failure to read/write, etc
[12:44] <xnox> * disk space warnings (as you already did)
[12:45] <xnox> * and the only one Raid specific is: RAID is healthy; out of sync / syncing; degraded; destroyed; metadata out of sync;
[12:45] <xnox> the first two will be done / sorted with other 'drive failures'
[12:46] <xnox> notifications.
[12:46] <xnox> the last one is special
[12:47] <xnox> if a drive failed: (i) raid array is now degraded (ii) a drive needs replacement. After (ii) is done, it will be out of sync, and it will need (iii) syncing at which point the RAID array will be healthy once again (iv)
[12:47] <xnox> for a very large array (e.g. 10TB) the sync can take day(s)
[12:48] <xnox> then periodically raids are checked for consistency
[12:48] <xnox> in this case the raid array can have: (i) healthy & clean (ii) dirty (iii) dirty and check in progress
[12:48] <xnox> and there is a cron job that does this.
[12:48] <xnox> (this, i.e. the checking)
[12:48] <mpt> ok
[12:49] <xnox> mpt: good, simples =) any questions? or can I run out for lunch ;-)
[12:50] <mpt> xnox, two questions
[12:50] <mpt> First, what do you mean by "degraded"?
[12:51] <mpt> if it doesn't mean a disk block/read/write problem, and it doesn't mean out of sync
[12:51] <xnox> mpt: the performance and reliability is now below, what is expected of the created RAID level. Hence the reality is less/degraded than the figures in the calculated table for example.
[12:51] <mpt> xnox, what might cause that?
[12:52] <mpt> and what can you do about it?
[12:52] <xnox> for example removing one of the two harddrives which are part of RAID1 array
[12:52] <xnox> or the harddrive silently failing to power-up
[12:52] <mpt> ok, "One of the drives is missing" is fairly major
[12:53] <xnox> well, not really =) it's just degraded =) you may have unplugged it on purpose
[12:53] <mpt> Second question: Is there, and if not should there be, a UI for inspecting a Raid array's status? Whether it's out of sync, or syncing, or being checked, etc
[12:53] <xnox> and if I have RAID1 with 2 drives + 1 spare (3 in total). I can unplug 2 drives from the running system and i am still fine.
[12:53] <mpt> and how much longer it's going to take to do that
[12:54] <xnox> mpt: yes there should be. I belive it should part of the current "Disks" utility
[12:54] <mpt> xnox, is that installed by default in Q?
[12:54] <xnox> which already does: disks, partitions, checking/restoring/wiping filesystems, doing S.M.A.R.T. checks, etc
[12:55] <xnox> yes, it is part of gnome and has been since natty (memory fuzzy, it is in precise and quantal for sure)
[12:55] <xnox> I do not know if it does RAID currently.
[12:55] <mpt> Is it called "Disks" in 12.04? I don't see it on my machine
[12:55] <xnox> If it doesn't, than it will be a spec/feature into that app.
[12:55] <xnox> mpt: try "Disk"
[12:55] <mpt> oh, "Disk Utility"
[12:56] <xnox> I belive in precise it's, yeah "Disk Utility" but in Quantal it's "Disks"
[12:56] <mpt> eww scrollbars
[12:56] <mpt> ok, thanks xnox
[12:58] <xnox> mpt: it has theming issues. It's uses white text on light gray background and similar low contrast combinations.
[12:58] <xnox> s/ It's / It /
[13:00] <xnox> oh one more question I missed. To come back to healthly from degraded mode: you need to (re-)add a harddrive & sync it.
[13:00] <mpt> sure
[13:00] <mpt> which is important but not urgent
[13:00] <xnox> correct
[13:01] <xnox> there are cases where "all is lost"
[13:01] <xnox> e.g. RAID10 and two drives failes
[13:01] <mpt> oh crikey
[13:01] <xnox> e.g. RAID10 and two drives failed
[13:01] <mpt> That error message will be fun to write
[13:01] <directhex> the wrong 2 drives
[13:01] <xnox> that means you lost 50% or less of your data
[13:01] <directhex> you can lose 2 disks in raid10
[13:01] <directhex> if they're the right 2
[13:03] <xnox> directhex: mpt: ok. If two drives fail in RAID10 there is 1/3 chance that "all is lost" =)
[13:05] <xnox> mpt: if 1 drive fails you are good to go, but you are half way to the game of Russian roulette =)
[13:05] <mpt> Clearly the icon for the alert box should be a pair of dice
[13:08] <xnox> mpt: to be honest the desktop may fail to show the alert if it is the "lucky" two drives =)
[13:08] <xnox> so you can assume we are still fine, e.g. degraded but no data lost just yet.
[13:09] <xnox> right, off to lunch
[13:24] <jibel> stgraber, networkless upgrade from lucid to precise is still failing with todays alternate (bug 1029531)
[13:25] <jibel> stgraber, the packages are the version from proposed excepted openoffice.org which is not on the CD and update-manager which is the version from precise-release
[13:26] <jibel> stgraber, similar error, upgrade is blocked by launchpad-integration
[13:34] <stgraber> jibel: that's expected, none of my uploads have been accepted to -proposed yet
[13:36] <xnox> stgraber: hmm?! slangasek accepted them ~7hours ago
[13:36] <xnox> or do I need an eye sight check =)
[13:37] <jibel> stgraber, the packages (launchpad-integration, nspr, and update-notifier) on the CD are from proposed excepted update-manager and openoffice
[13:37] <stgraber> oh ;)
[13:38] <stgraber> I'm still half way through my e-mails, so I probably didn't see the accepts yet :)
[13:38] <jibel> stgraber, update-mananager shouldn't make a difference in the resolver since it's a change in the blacklist
[13:40] <stgraber> jibel: looking at the logs, openoffice is still in new, so that's certainly a problem (+ I need to seed the right packages after that)
[13:40] <stgraber> jibel: without the new update-manager, the upgrader will still show a resolver issue but at least log it properly
[13:41] <stgraber> I'll refresh my VM here and run a test in the background during the 12.04.1 meeting
[13:48] <cjwatson> Anyone happen to have a recipe for referring to Fedora's equivalent of native packages in a watch file?
[13:48] <cjwatson> http://pkgs.fedoraproject.org/repo/pkgs/lorax/lorax-18.12.tar.gz/523ff86ccdf0931d65aa29a9b0b89740/lorax-18.12.tar.gz is an awkward thing to link to
[13:54] <jibel> stgraber, ack, I'll wait for openoffice
[13:59] <cjwatson> Never mind; as it happens I think it isn't going to be worth it.  There're only a few dozen lines of code in there that are actually tricky.
[14:01] <ogra_> @pilot in
[14:02] <stgraber> seb128: 12.04.1 meeting
[14:02] <seb128> stgraber, thanks, I somewhat lost calendar integration with quantal
[14:03]  * dholbach hugs ogra_
[14:05] <ogra_> :)
[14:17] <smoser> other people seeing broken dnsmasq or resolvconf?
[14:18] <smoser> all i'm getting in dnsmasq's reslv.conf (/run/dnsmasq/resolv.conf) is 127.0.0.1 via network manager.  even adding my name server there didn't work. i've resorted to putting it in /etc/resolv.conf
[14:21] <stgraber> smoser: IIRC resolvconf discards all other entries if one is 127.0.0.1
[14:22] <smoser> why would one be 127.0.0.1?
[14:22] <smoser> where would it be getting that. i'm 'certain my dhcp server is not saying 127.0.0.1
[14:23] <stgraber> well, 127.0.0.1 would be the dnsmasq server started by network-manager
[14:23] <smoser> ah. yeah. i gave the wrong file.
[14:23] <smoser>  /run/dnsmasq/resolv.conf had that
[14:24] <ion> I seem to have no such file. But i do have /run/nm-dns-dnsmasq.conf which refers dnsmasq to the right server.
[14:24] <smoser> i have no such file like that.
[14:24] <smoser> interesting.
[14:25] <ion> What are the parameters to the dnsmasq process that is running?
[14:25] <ion> 19914 /usr/sbin/dnsmasq --no-resolv --keep-in-foreground --no-hosts --bind-interfaces --pid-file=/var/run/sendsigs.omit.d/network-manager.dnsmasq.pid --listen-address=127.0.0.1 --conf-file=/var/run/nm-dns-dnsmasq.conf --cache-size=0 --proxy-dnssec
[14:25] <smoser> well, i have 3
[14:26] <mpt> huh
[14:26] <mpt> xnox, a colleague just ran low on disk space, and the error message that came up turned out to be one I'd designed four years ago: <https://live.gnome.org/LowDiskSpaceWarning>
[14:27] <smoser> i hit this too
[14:27] <smoser> mpt, ^ running quantal, yesterday. space was being eaten by something.
[14:27] <mpt> xnox, so why did you include it on your list? Are you planning to move the implementation somewhere else?
[14:28] <xnox> mpt: good. Just one? or many?
[14:28] <mpt> xnox, just one.
[14:28] <xnox> mpt: ok. but there was no terminal  / server notification, etc.
[14:29] <mpt> ok, that's a good reason
[14:29] <mpt> xnox, but do you include in your plan getting rid of the old one?
[14:29] <xnox> mpt: reusing as much as possible and/or improving.
[14:29] <mpt> ok
[14:29] <xnox> for example it does not come up if you run out of inodes.
[14:30] <mpt> Just as long as we don't end up with 2009-era-mpt and 2012-era-mpt alerts appearing simultaneously
[14:30] <smoser> mpt, i'm curious, was your colleague that saw that running quantal ?
[14:30] <mpt> smoser, 12.04
[14:30] <smoser> something ate 44G of space for me yesterday on quantal. after reboot i have 44G free, and i had maybe 1.5 free prior.
[14:30] <smoser> mpt, so unrelated.
[14:31] <mpt> (oops, 2009 was three years ago, not four)
[14:31] <xnox> mpt: are you sure the 2009-era-mpt is not the 2014-era-went-back-in-time-mpt ?
[14:31] <xnox> =)
[14:31] <smoser> ion, stgraber this is reproducible for me
[14:31] <smoser>  http://paste.ubuntu.com/1137879/
[14:31] <smoser> any ideas?
[14:32] <smoser> i honestly do not think i've changed anything in my resolvconf and dnsmasq on this system.
[14:33] <stgraber> smoser: well, why do you have "dnsmasq" installed to start with (instead of just "dnsmasq-base")?
[14:36] <smoser> stgraber, i probably installed some long time ago before dnsmasq-base was installed by desktop
[14:36] <smoser> and, silly me, i've probably done that other places too
[14:37] <stgraber> smoser: there's a known race between the dnsmasq init script in dnsmasq and the one spawned by network-manager that could explain what you're seeing
[14:37] <smoser> would it be 100% reproducible?
[14:37] <stgraber> "race", so no
[14:37] <smoser> i'm not restarting dnsmasq each time i disconnect from the wireless and reconnect
[14:37] <smoser> so i wouldn't have thought it would be in the picture
[14:38] <stgraber> NM ships a workaround for that bug in quantal and I believe it's somewhere in the SRU pipeline for 12.04 too
[14:38] <smoser> i am plugged in to a wired network and have known wireless available also. and NM is managing them both (its often buggy about that).
[14:38] <smoser> i'm on quantal
[14:38] <stgraber> hmm
[14:38] <smoser> updated this morning. rebooted. no dns
[14:38] <stgraber> cyphermox: ^
[14:40] <cyphermox> yeah, that's the system dnsmasq started, no?
[14:41] <cyphermox> NM's instance isn't started -- don't know why, or when it was tried; we'd need syslog
[14:42] <smoser> cyphermox, you want /var/log/syslog or dmesg?
[14:42] <cyphermox> syslog
[14:42] <smoser> http://paste.ubuntu.com/1137901/
[14:43] <smoser> kirkland, tyhicks . its a fun day on quantal.
[14:43] <smoser> http://paste.ubuntu.com/1137902/ <-- kirkland and tyhicks.  i started seeing those ecryptfs issues yesterday again.
[14:43] <smoser> they'd been away for quite some time.
[14:43] <kirkland> smoser: I saw some chatter in #ubuntu-kernel yesterday about uploading a new kernel with ecryptfs patches
[14:44] <smoser> joy.
[14:45] <kirkland> smoser: I don't see cking or rtg around now
[14:45] <kirkland> smoser: might be a little while before ogasawara comes online?
[14:45] <cyphermox> also check if you have /etc/dnsmasq.d/network-manager
[14:46] <smoser> yes.
[14:46] <smoser> http://paste.ubuntu.com/1137905/
[14:46] <kirkland> smoser: do you have a new kernel?
[14:46] <smoser> i updated quantal this morning and rebooted. but i had seen some of those messages yesterday.
[14:47] <smoser> but yesterday i was in low-disk-space scenario for some other bug. i'm not sure what bug it was that ate 44G of my home, but reboot gave it back.
[14:48] <smoser> cyphermox, i realize i inadvertantly pasted dmesg.
[14:48] <smoser> http://paste.ubuntu.com/1137909/ is syslog
[14:50] <cyphermox> thanks
[14:50] <cyphermox> smoser: your /etc/dnsmasq.conf probably contains enable-dbus?
[14:51] <cyphermox> or some other such config, maybe in /etc/dnsmasq.d?
[14:51] <smoser> GAH. and why do i hear a dog barking  every time i page down npaste the bottom of firefox, or hit tab in my gnome-terminal
[14:51] <cyphermox> haha
[14:51] <smoser> (the dog barking isn't the neighbors, its coming from my speakers)
[14:52] <smoser> cyphermox, that would be a yes.
[14:52] <cyphermox> awesome.
[14:52] <smoser> i've used that before
[14:52] <smoser> and likely i did add /etc/dnsmasq.d/enable-dbus
[14:52] <cyphermox> right
[14:53] <cyphermox> there's only one dbus name dnsmasq uses (for now)
[14:53] <cyphermox> so if there's another instance started with it NM gets confused
[14:53] <smoser> ok. thi smakes sense.
[14:53] <cyphermox> I was about to start writing a patch to support setting a different dbus name
[14:53] <smoser> also, i couldn't even get to the dnsmasq tha taws running on 127.0.0.1
[14:53] <cyphermox> guess it just got bumped up the priority list :)
[14:54] <smoser> (ie, 'host foo 127.0.0.1' would hang)
[14:54] <cyphermox> yeah, because there isn't one being started :)
[14:54] <smoser> well i have one running.
[14:54] <cyphermox> on 127.0.0.1?
[14:54] <smoser> i assumed the system one was.
[14:55] <smoser> 6844 ?        S      0:00 /usr/sbin/dnsmasq -x /var/run/dnsmasq/dnsmasq.pid -u dnsmasq -r /var/run/dnsmasq/resolv.conf -7 /etc/dnsmasq.d,.dpkg-dist,.dpkg-old,.dpkg-new
[14:55] <cyphermox> no, it can't be
[14:55] <cyphermox> because of /etc/dnsmassq.d/network-manager
[14:55] <cyphermox> (bind-interfaces / except-interface=lo)
[14:55] <smoser> ah. except-interfaces
[14:55] <smoser> ok.
[14:55] <smoser> ok. cyphermox yo uwant a bug opened?
[14:55] <cyphermox> sorry, I realise it gets crazy with so many instances now
[14:55] <cyphermox> smoser: yes, that would help a lot
[14:56] <cyphermox> or anyway, can't hurt, at least we can track progress
[14:56] <smoser> and i'm guessing the solution here is for me to remov ednsmasq (i'm not sure why I need it other than what NetworkManager's would provide)
[14:57] <cyphermox> smoser: if you just remove the enable-dbus from your dnsmasq.conf or file in /etc/dnsmasq.d, it would be sufficient for things to work
[14:57] <smoser> i'm guessing if i do that, then my 'enable-dbus' file is not going to be relevant.
[14:57] <cyphermox> (plus restart network-manager)
[14:57] <cyphermox> right
[14:57] <smoser> ok.
[14:57] <smoser> bug against ?
[14:57] <smoser> what package
[14:57] <cyphermox> network-manager
[14:57] <smoser> k.
[14:58] <cyphermox> I'll add a task to dnsmasq, but NM should start its instance on a custom bus name
[14:58] <smoser> gah. does nyone know about this barking dog?
[14:59] <smoser> i disabled terminal bell in gnome-terminal and that brought some sanity.
[14:59] <smoser> but now firefox is doing it to me.
[15:03] <mpt> xnox, so in summary, I think there are three kinds of Raid error to present: (1) missing component (2) non-dataloss component failure (3) dataloss component failure.
[15:04] <mpt> At least that's what I understand from what you said
[15:04] <cjwatson> smoser: System Settings -> Sound -> Sound Effects perhaps
[15:04] <cjwatson> there's a "Bark" alert sound as one of the choices there
[15:04] <cjwatson> (may be the default, not sure)
[15:05] <mpt> xnox, with low-disk and Smart errors being presented as they would for a non-Raid disk.
[15:05] <xnox> mpt: sounds good in theory. I wonder if I will be able to distinguish between them when implementing them =)
[15:06] <smoser> cjwatson, well... yeah, but i didn't change anything :)
[15:07] <smoser> maybe my low disk issues wreaked havoc
[15:10] <smoser> cyphermox, https://bugs.launchpad.net/ubuntu/+source/network-manager/+bug/1034946
[15:13] <smoser> ok. so its likely that i *did* change the sound to a bar.
[15:13] <smoser> bark.
[15:13] <smoser> but changing it back to "default" doesn't do anything. i'm guessing i have to log out and back in to have that take affect. and i probably changed it a week ago and just logged out and back in today.
[15:37] <xnox> i think i got caught in unfortunate wost case scenario waiting time for the ppa publisher....
[15:37]  * xnox fiddles thumbs
[15:38] <Laney> https://xkcd.com/303/ s/compiling/publishing/g
[15:39]  * xnox yeah! done
[15:40]  * xnox juju deploy!!!!
[15:46] <xnox> https://bugs.launchpad.net/ubuntu/precise/+source/python-boto/+bug/1034963
[15:46] <xnox> no longer affects:	 python-boto (Ubuntu Quantal)
[15:46] <xnox> no longer affects:	 python-boto (Ubuntu)
[15:46] <xnox> but still
[15:46] <xnox> affects precise series....
[15:47] <xnox> interesting UI
[16:13] <Laney> xnox: you know your buildd charm thing?
[16:13] <xnox> Laney: yes.
[16:13] <Laney> how easy would it be to turn it to mass no-change rebuilds?
[16:14] <xnox> Laney: well it's an sbuild charm + parallel-ssh package and you have your mass no-change rebuilder =)
[16:14] <Laney> like take list of packages, test, if build then rev revision and drop somewhere for signing
[16:14] <xnox> Laney: with an extra script, sure.
[16:14] <xnox> Laney: what for? =)
[16:15] <Laney> http://people.canonical.com/~ubuntu-archive/transitions/ghc.html
[16:15] <xnox> Laney: do you want it to run continiously as well?
[16:16] <Laney> the more automatable the better i suppose
[16:16] <Laney> but in the real world cloud burns cash
[16:16] <micahg> I think that might not be a good idea to run continuously (unless it's for testing purposes and not uploading)
[16:18] <xnox> Laney: let me finish full archive rebuild. and then ghc's will emerge from that
[16:19] <Laney> I already have a rebuild.sh
[16:19] <Laney> think I'll just put that on a 2xlarge :P
[16:19] <infinity> Laney: Am I old skool in that I just do it with a shell for loop? :P
[16:19] <Laney> I do it with parallel from moreutils
[16:19] <Laney> but I thought xnox's thing might be more the shiny
[16:20] <xnox> Laney: it may be shiny, but it still has no juice =)
[16:22] <Laney> euca-run-instances -k laney --user-data-file ~/.hpcloud/buildd.sh -t standard.2xlarge ami-0000269b
[16:22] <Laney> go go go
[16:22] <shadeslayer> hmmm
[16:22] <shadeslayer> cjwatson: I think I'll need a even newer live build package
[16:23] <shadeslayer> because the current lb package assumes the initrd is compressed with gzip, whereas it's actually compressed with gzip
[16:23] <shadeslayer> hacked around that by calling lzcat instead of zcat
[16:25] <cjwatson> Might be an outstanding bug in quantal
[16:27]  * dholbach hugs mterry
[16:27] <mterry> dholbach, is this a reminder to patch pilot?  :)
[16:27] <mterry> dholbach, ah this is for the UDW
[16:27] <dholbach> no, thanks a bunch for your UDW session :)
[16:28]  * mterry has learned to associate dholbach hugs with piloting
[16:28] <mterry> You've Pavloved me
[16:28] <dholbach> haha
[16:28]  * dholbach hugs mterry
[16:28]  * dholbach hugs mterry
[16:28]  * dholbach hugs mterry
[16:28] <mterry> heh
[16:28] <tyhicks> smoser: what kernel version are you running?
[16:28] <mterry> Am super busy today, but will either pilot later today or another day
[16:29] <shadeslayer> cjwatson: it is, it's fixed in debian
[16:30] <shadeslayer> debian bug 637979
[16:30] <xnox> dholbach: i missed my last piloting due to holiday, but i did do some sponsoring today, need to write a report about it =)
[16:30] <shadeslayer> cjwatson: the other issue being, when using lzcat it expects a initrd file that ends in .lzma
[16:30] <cjwatson> shadeslayer: Probably just apply that locally for now then
[16:30] <shadeslayer> cjwatson: already did
[16:30] <cjwatson> lzcat -S '' or some such IIRC
[16:31] <shadeslayer> ../binary/casper/initrd.img-3.5.0-8-generic:  unknown suffix -- unchanged
[16:31] <dholbach> xnox, feel free to move it to whatever day suits you and use the "@ pilot" thing
[16:31] <shadeslayer> hmm
[16:31]  * shadeslayer looks
[16:31] <cjwatson> I forget, read the manual :)
[16:31] <smoser> tyhicks, it probably says in my dmesg :)
[16:31] <cjwatson> You might need to pass it on stdin using a redirection rather than as a filename
[16:31] <smoser> $ dpkg -S /boot/vmlinuz-$(uname -r)
[16:31] <smoser> linux-image-3.5.0-8-generic: /boot/vmlinuz-3.5.0-8-generic
[16:32] <tyhicks> smoser: 3.5.0-9.9, which is in -proposed, has my fixes for handling empty lower files
[16:32] <smoser> tyhicks, thinks.
[16:32] <xnox> dholbach: cool.
[16:32] <smoser> thanks
[16:33] <smoser> i'll try that.
[16:34] <shadeslayer> lol
[16:35] <shadeslayer> cat pictures on Debian patch tracker
[16:36] <SpamapS> bdmurray: hey, I missed my SRU rotation yesterday with some other stuff. Lets try to coordinate so we don't stomp on eachother today
[16:41] <smoser> tyhicks, http://paste.ubuntu.com/1138071/
[16:43] <tyhicks> smoser: Sorry, not sure what's going on there. I just write the upstream patches. Don't really know anything about the Ubuntu kernel packaging.
[16:43] <SpamapS> Aug  9 09:43:52 clint-MacBookPro kernel: [114490.088106] unregister_netdevice: waiting for lo to become free. Usage count = 1
[16:44] <SpamapS> anybody ever see this on quantal?
[16:44] <SpamapS> every 10 seconds
[16:44] <smoser> tyhicks, the kernel is not in proposed
[16:45] <smoser> only the metapackage
[16:45] <tyhicks> smoser: This page says it is 2 hours old, so maybe it needs a little more time before everything shows up? https://launchpad.net/ubuntu/+source/linux
[16:46] <smoser> its still buiding some arch.
[16:46] <smoser> annoying that they'd put the metapackage up first.
[16:46] <smoser> but yeah, it seems like it will get there eventually
[17:01] <bdmurray> SpamapS: I was planning on this afternoon
[17:02] <SpamapS> bdmurray: ok I'll wrap mine up this morning then
[17:02] <ogra_> @pilot out
[17:09] <infinity> smoser: Firing and forgetting linux+linux-meta to proposed is fine, since we don't expect people to run proposed in dev releases anyway. :P
[17:13] <slangasek> rather, we insist that people not run proposed in -dev releases :-P
[18:10] <mhall119> slangasek: is there a URL or API where I can get a list of patches we currently apply to a package's original sourcecode?
[18:11] <mhall119> meaning, Ubuntu patches and Debian patches
[18:11] <mhall119> achuni told me there was something on Launchpad that would show me that
[18:15] <slangasek> mhall119: well, for any package, https://launchpad.net/ubuntu/+source/<src_pkg>/<ver>/ will include a download link to either the .diff.gz or the .debian.tar.gz
[18:16] <infinity> mhall119: Not all packages use the same (or any) patch system, so "list of patches" isn't gonna happen, but yes, the source is always available, as slangasek points out.
[18:17] <slangasek> right
[18:17] <Laney> Depending on what you want, there is http://ubuntudiff.debian.net and http://patches.ubuntu.com
[18:17] <slangasek> you get the monolithic delta against upstream, and this may be in a format that you can easily break out the list of patches from debian/patches/series
[18:17] <slangasek> but it may not
[18:17] <infinity> Laney: That's just deltas between Ubuntu and Debian, though.  Ish.
[18:18] <zumbi> doko_: ayt?
[18:18] <infinity> mhall119: Anyhow, anything that isn't the orig is, essentially, "the Debian and Ubuntu patches".  Except in cases where there are multiple upstream tarballs. ;)
[18:19] <Laney> yep. then combine with patch-tracker.debian.org :P
[18:19] <mhall119> is there any consistent way I could get this info?
[18:19] <Laney> oh, there is also the census stuff from pabs
[18:19] <mhall119> or are there a bunch of different ways and I'll have to detect which one to use
[18:19] <zumbi> doko_: just wondering if you saw gcc package split patch we talked about
[18:20] <slangasek> mhall119: the latter
[18:20] <mhall119> darn
[18:20] <slangasek> the majority of packages will have debian/patches/series
[18:20] <slangasek> but the corner cases are myriad and ugly
[18:21] <infinity> The "corner cases" are probably half the archive.
[18:21] <Laney> it's a big corner.
[18:21] <infinity> And there are plenty of people who prefer v1-style packaging (without any patch systems at all) because that's inherently more VCS-import-friendly.
[18:22] <slangasek> infinity: nah, http://upsilon.cc/~zack/stuff/dpkg-v3/ shows over half the archive is 3.0 (quilt)
[18:22]  * Laney heats up the BDs for a while
[18:22] <slangasek> 2/3 even
[18:22] <Laney> er, buildds
[18:22] <infinity> So, again.  Breaking it out into "individual patches" is a goal I think you'll just fall flat on.  But if you just want to know "what's our delta from upstream", that's easy.
[18:22] <infinity> slangasek: There's a shocking number of v3(quilt) that uses --single-debian-patch.
[18:22] <slangasek> hahaha
[18:22] <infinity> slangasek: And by "shocking number", I mean "more than one", which shocks me.
[18:23] <mhall119> infinity: I like easy ways, what is it?
[18:23] <slangasek> infinity: in which case, the list of patches has 1 element in it
[18:23] <Laney> there's more to 3.0 (quilt) than quilt
[18:23] <slangasek> mhall119: that's what I pointed you to already
[18:23] <slangasek> the debian.tar.gz or diff.gz for the package (whichever exists)
[18:23] <infinity> slangasek: Sure, but it's not quite what mhall119 was asking for, I suspect.   If he's happy to just know "the delta", rather than individual fixes, that's, like I said, much simpler.
[18:23]  * Laney feels slightly responsible for mono's use of it.
[18:24] <infinity> Laney: Bad.
[18:24] <shadeslayer> cjwatson: W: Bootloader on your architecture not yet supported by live-build.
[18:24] <shadeslayer> W: This will produce a most likely not bootable image (Continuing in 5 seconds).
[18:24] <shadeslayer> any ideas on how to fix that?
[18:24] <mhall119> infinity: I'd rather a list of patches,  but if a single large diff would be easier and more consistent across packages, I'd take that
[18:24] <infinity> mhall119: Basically, a source package is a .dsc that describes the source files.  It'll point to a .orig.tar.$compress, and a bunch of other files.
[18:24] <infinity> mhall119: In most cases, those other files (diff.gz, debian.tar.gz, etc) are "the delta".
[18:25] <infinity> mhall119: The rare corner case (see libreoffice) is where it references a ton of tarballs that are all part of the upstream source.
[18:25] <mhall119> ok
[18:25] <zumbi> is doko still in vacs?
[18:25] <infinity> zumbi: Nope.
[18:25] <infinity> zumbi: It is past the old man's bedtime, though.
[18:26] <shadeslayer> maybe because I'm building the i386 CD on a amd64 machine
[18:26] <zumbi> infinity: ok, thanks, we'll try to catch him tomorrow
[18:26] <Laney> mhall119: What's the goal here, out of interest?
[18:27] <mhall119> Laney: to be able to tell upstreams what exactly we have that is different from their source
[18:28] <infinity> Did the community team just volunteer to forward all my patches, so I don't have to?
[18:28] <infinity> This is how I prefer to read the above.
[18:28] <mhall119> A list of patches would be nice in that case, since they can choose which individual changes make sense to apply to their source
[18:28] <mhall119> infinity: nope :)
[18:29] <mhall119> infinity: but if the upstream wants to get their latest version into Ubuntu, we are working on a way to tell them what exactly we've done differently
[18:29] <infinity> mhall119: Well, in MOST cases, debian.tar.gz or diff.gz will really all just be packaging fluff anyway.
[18:30] <infinity> mhall119: While we do patch a lot of packages (and some quite heavily), most of the deltas are things upstreams shouldn't care about in the first place.
[18:30] <infinity> And when the delta is somehting that should be upstreamed, we're failing if we're not doing it through proper channels.
[18:31] <Laney> powerpc  2 41 jobs (9 hours 30 minutes) :(
[18:31] <infinity> (And the proper channel isn't a dump of "here's our changes, have a look")
[18:31] <infinity> Laney: It'll catch up.
[18:31] <infinity> Laney: Did you have something specific you were waiting on?
[18:31] <Laney> Haha. I don't doubt that.
[18:31] <Laney> Just haskell.
[18:32] <infinity> Oh.  Yeah, that can wait.
[18:32] <infinity> Sounds like weekend fun anyway.
[18:33]  * Laney pays tribute to sulfur
[18:33] <Laney> (also sulphur)
[18:34] <infinity> Laney: sulfur ain't coming back, unless someone does something heroic.  The photo I saw seems to imply that the OF image is wedged and needs fixing.
[18:34] <infinity> That said.  Hrm.  All my IBM PPC kit has a backup firmware switch.
[18:34] <infinity> Maybe I should walk IS through that.
[18:35]  * infinity completely forgot about that when he was shown the "hahaha, sux 2 b u lolz" photo of the console.
[18:36] <Laney> jcastro: Is there any limit to usage on this HP cloud trial?
[18:36] <Laney> ie can I leave this 2xlarge running because I'm too lazy to set it up again next time or even to script its setup?
[18:44]  * DebolazW is impressed at how little memory compiz is using nowadays.
[18:44] <DebolazW> It used to be an all-devouring beast.
[18:47] <mhall119> Laney: careful, if you let on that the setup can be scripted he'll want you to write a juju charm
[18:48] <Laney> the world's least charming charm
[18:48] <shadeslayer> hah
[19:10] <infinity> slomo: gstreamer1.0 seems to have universally hung on all 5 arches in quantal (while building just fine on all arches in experimental... fun)
[19:10] <infinity> slomo: Any interest in sorting out WTF?
[19:28] <dobey> oh noes. no barry
[19:28] <infinity> slomo: /build/buildd/gstreamer1.0-0.11.93/tests/check/libs/.libs/lt-gstnetclientclock appears to be the hanging culprit.
[19:31] <infinity> slomo: Based on the filename (I haven't looked at the actual test), could this relate to the fact that the Ubuntu buildds can't see the outside world?
[19:33] <slomo> infinity: can they communicate with 127.0.0.1 on port 1234 via udp?
[19:34] <infinity> slomo: Yes.
[19:35] <infinity> Nothing on 127.0.0.1 is restricted.
[19:35] <slomo> ok, then it must be something else :) i don't see much in that test that could cause it to hang *forever*
[19:35] <slomo> after some minutes it should just fail with a timeout from the test runner
[19:35] <infinity> You'd think, right? ;)
[19:35] <slomo> (some == 2 minutes iirc)
[19:35] <infinity> Defintely forever here, though.
[19:35] <infinity> On all 5 arches, no less.
[19:35] <infinity> Which is special.
[19:36] <infinity> But comforting that it's not arch-specific.
[19:36] <slomo> the test itself is forked from the test runner, and after the timeout it kills the process
[19:36] <slomo> so there must be something really weird going on here :)
[19:37] <infinity> slomo: Let me spin it up quickly in a quantal sbuild here and see if it reproduces.
[19:39] <infinity> slomo: In other news, that build doesn't fail when the testsuite fails. >:(
[19:39] <infinity> slomo: Had to do some heroic post-kill killing to stop it from completing blindly on two buildds after killing the hung test. :P
[19:40] <mterry> @pilot in
[19:42] <slomo> infinity: yes, that's intentional. the testsuite runs only for informational purposes and fixing things later, not to fail the build :) i'm looking at the build logs afterwards
[19:43] <infinity> slomo: Kay, reproduced locally, so it's nothing to do with the buildd's network setup.
[19:44] <infinity> [pid 16939] futex(0x2b10ec0015c0, FUTEX_WAIT_PRIVATE, 2, NULL <unfinished ...>
[19:44] <infinity> [pid 16938] futex(0x2b10eb4939d0, FUTEX_WAIT, 16939, NULL
[19:44] <slomo> infinity: ok, so it's something that is different between debian and ubuntu... yay
[19:44] <infinity> ^-- Just sitting there.
[19:47] <slomo> infinity: you don't have backtraces of both processes i guess?
[19:49] <infinity> I just killed them.  :P
[19:49]  * infinity redoes the build.
[20:01]  * xnox is recompressing the archive using none, gzip, bzip2, lzma, xz & xz-extreme
[20:01] <xnox> 19.56% done
[20:02] <micahg> I was thinking to see if there's an easy way to see on the ISO what's compressed with which algorithm
[20:02]  * micahg figures recompression might save xubuntu's ISOs from being oversized
[20:03] <xnox> alternative cd?
[20:03] <xnox> or live? or both?
[20:04] <micahg> well, ATM everything is oversized, the alternate less so, and the funny thing is, that's where compression will help the most
[20:04] <xnox> micahg: i happen to have a hadoop cluster optimised for this type of job =)
[20:04] <xnox> micahg: but my results are for each package, so we could compare it, once it's finished.
[20:05] <xnox> it is not analysing compression method at the moment
[20:05] <infinity> slomo: http://paste.ubuntu.com/1138419/  <-- Backtraces of the two processes.
[20:05] <xnox> and it is running against precise archives
[20:05] <micahg> xnox: right, that + a list of what's compressed with what on the ISOs would do it
[20:05] <xnox> ok.
[20:05] <xnox> so we are good =)
[20:06] <xnox> 23% in half an hour.
[20:07] <xnox> maybe i should have added more nodes =)
[20:07] <xnox> too late now
[20:07] <slomo> infinity: and the other threads, especially of the second process?
[20:07] <Laney> xnox: main+universe?
[20:08] <infinity> slomo: http://paste.ubuntu.com/1138429/
[20:08] <infinity> slomo: (It only has two threads)
[20:09] <xnox> Laney: 42813 binary debs, yes main+universe
[20:09] <slomo> infinity: thanks, i'll try to understand that tomorrow... doesn't make much sense right now how this can happen :)
[20:09] <Laney> nice
[20:09] <Laney> what is this cluster of which you speak?
[20:10] <xnox> Laney: hpclud - 54 instances: one juju minion, one master minion, and 52 worker minions
[20:11] <xnox> it's hadoop
[20:11] <xnox> with dumbo (python api, to write mappers & reducers in python ;-) )
[20:11] <Laney> oh ok
[20:11] <xnox> with settings tweaked and bugs solved until it works =)
[20:17] <shadeslayer> cjwatson: what's LB_BOOTLOADER for building the CD?
[20:17] <shadeslayer> grub? syslinux?
[20:22] <slangasek> jamespage: I just dropped a comment in bug #1014864; would like to see the latest fix from quantal included in the SRU
[20:38] <bdmurray> SpamapS: Did you get through all the pending-sru.html for precise?
[20:50] <jamespage> slangasek, sure - I did request it be rejected for that reason (only noticed that was an issue yesterday I think)
[20:50] <slangasek> jamespage: ok :)
[20:53] <jamespage> slangasek, fresh backport in the NEW queue....
[21:05] <Bluefoxicy> does fstrim ever do anything bad?
[21:05] <Bluefoxicy> I'm thinking it may be wise to have a cron job that runs fstrim every day
[21:06] <Bluefoxicy> but detecting trim-enabled disks is semi-reliable
[21:06] <Bluefoxicy> options are either detect trim-enabled disks and trim them OR just trim everything
[21:07] <Bluefoxicy> also it's good to see that a question about general UI design on the mailing list immediately turns into a long-running flamewar about whether Unity sucks or not.
[21:07] <Bluefoxicy> People got their priorities straight.
[21:07] <Bluefoxicy> Figuring out how to make things better should never come before bashing the things you like least.
[21:10] <mterry> @pilot out
[21:10] <mterry> will be back!
[21:50] <cjwatson> shadeslayer: I expect you need to pass the --bootloader option with some argument that isn't "none".  See 'man lb config'.
[21:51] <cjwatson> shadeslayer: We use syslinux for BIOS-booting our CDs at the moment.
[21:51] <shadeslayer> cjwatson: right, I know, I just wanted to confirm which bootloader does ubuntu use with the livefs, and I believe it wasa syslinux
[21:51] <shadeslayer> right
[21:51] <shadeslayer> that's what I'm using :)
[21:51] <shadeslayer> cjwatson: thanks for all the help
[21:51] <shadeslayer> cjwatson: I owe you a beer at UDS :P
[21:55] <cjwatson> ISO building - as opposed to plain squashfs building which is what we use in production - is a bit rough :-/
[21:56] <shadeslayer> right
[21:57] <UndiFineD> hmmm, how would that work in the near future, with uefi ? maintain both syslinux or grub on iso
[21:57] <shadeslayer> cjwatson: plus live build seems to lag behind the packages in debian
[21:57] <shadeslayer> which also causes issues
[22:31] <ScottK> Is there an easy way to remove all packages not needed for ubuntu-standard?