[04:54] <pitti> Good morning
[04:57] <infinity> Good night
[07:04] <dholbach> good morning
[07:20] <dholbach> hey mvo
[07:31] <infinity> mvo: Are you planning to upload your FTBFS fixes for command-not-found soon?
[07:32] <infinity> mvo: I was going to just release your current bzr head, but wasn't sure if maybe you were waiting to fix something else first.
[07:37] <mvo> hey dholbach
[07:38] <mvo> infinity: sorry, got distracted by various things, the ubuntu branch is close, but not quite there I think, the amount of fiddling needed to build py3 is higher than I expected (in my little naive ways)
[07:42] <infinity> mvo: Ahh, kay.  I'll leave you to it, then.
[07:42] <infinity> mvo: Or you can always punt to barry in his morning. ;)
[07:59] <mvo> infinity: yeah, thanks, I have a look in a bit though
[08:45] <cjwatson> mvo: I'm having a look now
[08:47] <vibhav> Is there any place where there are applications which have to be transitioned to gcc 4.7 ?
[08:48] <cjwatson> vibhav: http://bugs.debian.org/cgi-bin/pkgreport.cgi?tag=ftbfs-gcc-4.7;users=debian-gcc@lists.debian.org
[08:49] <vibhav> cjwatson: Any Ubuntu specific page?
[08:53] <cjwatson> vibhav: Not that I know of; it would probably be harmful to diverge effort on this kind of thing
[08:54] <vibhav> cjwatson: ah
[08:54] <vibhav> anyways, thanks
[08:55] <mvo> cjwatson: great, thanks
[08:56] <cjwatson> mvo: (almost done, just test-sbuilding)
[08:56] <mvo> \o/
[09:05] <cjwatson> mvo: Try r169?
[09:12] <mvo> cjwatson: looks good, but running it for real on the installed system fails because bash needs a update (it hardcodes /usr/bin/python) I will fix that next
[09:12] <cjwatson> Oh seriousy
[09:12] <cjwatson> I thought I'd fixed that
[09:12] <mvo> maybe I didn't update recently, let me double check
[09:12] <cjwatson> Yeah, I did
[09:13] <cjwatson> You didn't just copy the new binary into place or something?
[09:13] <cjwatson> Upstream r151.2.21
[09:13] <cjwatson> Unless there's something lurking somewhere else
[09:13] <mvo> cjwatson: grep -A15 command_not_found_handle /etc/bash.bashrc
[09:13] <mvo> cjwatson: you use zsh, I assume?
[09:14] <cjwatson> Argh!  Why is there another copy of that?
[09:14] <mvo> cjwatson: I don't know
[09:14] <cjwatson> No, I use bash, but I foolishly assumed that bash_command_not_found in the command-not-found source might be canonical :-P
[09:14] <cjwatson> How about I go and fix bash
[09:14] <mvo> sounds good to me!
[09:14] <cjwatson> No excuse for hardcoding the interpreter there
[09:14] <cjwatson> Do we need a Breaks then or something?
[09:15] <cjwatson> Also this means that we might need to expect that old conffiles will stick around
[09:16] <cjwatson> Should we check for Python 2 and re-exec with Python 3, or something?  At least if 'import apt' fails?
[09:16] <mvo> cjwatson: its a bit odd, bash_command_not_found seems to not get installed, maybe worth checking with doko_ why its put into the bash package instead of via profiles.d
[09:16] <cjwatson> Packages aren't permitted to rely on profiles.d
[09:16] <cjwatson> That was a condition of adding that directory
[09:17] <mvo> cjwatson: I see, its used by some stuff currently (byobu for example)
[09:17] <cjwatson> Non-policy-compliant :)
[09:17] <mvo> :)
[09:17] <cjwatson> LC_BYOBU‽
[09:17] <cjwatson> For crying out loud
[09:17] <cjwatson> $ sudo apt-get purge byobu
[09:18] <mvo> isn't it in our default install?
[09:18] <cjwatson> Maybe, I wouldn't have installed it manually
[09:19] <mvo> cjwatson: re reexec> that is probably a good idea
[09:19] <cjwatson> Hm, python-apt is only imported way down the stack
[09:20] <cjwatson> I kind of feel uncomfortable about completely forcing python3, but maybe I should get over it
[09:20] <Daviey> it shouldn't be default in desktop, or server.. it is in server-ship.. and installed by default on cloud images.
[09:20] <cjwatson> It was default at one point
[09:20] <Daviey> Hmm.. it was a recommends of screen for a while.
[09:26] <cjwatson> mvo: How about http://paste.ubuntu.com/1065724/ ?
[09:27] <mvo> cjwatson: yeah, that looks reasonable
[09:31] <mvo> cjwatson: shall I merge/upload or are you on it already?
[09:31] <cjwatson> mvo: Please go ahead, I'd blocked out some time to catch up on Debian TC stuff and I'm already half an hour late :)
[09:31] <jml> hallyn: hello. I came across http://permalink.gmane.org/gmane.linux.kernel.containers.lxc.general/3724 recently (bug in initscripts.postinst preventing dist-upgrade inside lxc containers). Was just wondering if there's a LP bug for it?
[09:32] <mvo> cjwatson: sure, thanks a lot for your help!
[09:32] <jml> hallyn: I've found https://bugs.launchpad.net/ubuntu/+source/sysvinit/+bug/891045, but that seems to run counter to stgraber's suggestion that you were working on it.
[09:33] <mvo> cjwatson: I will also ensure that we have a fresh data extraction now that I no longer reply on rookery for the generation
[09:38] <cjwatson> mvo: Right, I noticed, thanks
[09:44] <xnox> is it just me or did dch stop updating maintainer trailer line?
[09:45] <tumbleweed> it did, DEBCHANGE_RELEASE_HEURISTIC=changelog is now the default
[09:45] <tumbleweed> see your nearest NEWS.Debian.gz
[09:50] <pitti> tumbleweed: ooh, is it? niiiiiice!
[09:50] <pitti> DEBCHANGE_MULTIMAINT_MERGE=yes as well by any chance?
[09:51] <tumbleweed> if only :)
[10:01] <xnox> tumbleweed: but it's just wrong....
[10:02] <xnox> http://paste.ubuntu.com/1065763/
[10:03] <tumbleweed> xnox: throw a -r in
[10:03] <xnox> notice how it creates a *new* changelog entry with *not my name*
[10:03] <xnox> tumbleweed: Only one of -a, -i, -e, -r, -v, -d, -n/--nmu, --bin-nmu, -q/--qa, -R/--rebuild, -s/--security, --team, --bpo, -l/--local is allowed;
[10:03] <tumbleweed> ah
[10:04] <xnox> i almost "sponsored" some packages
[10:05] <seb128> xnox, sponsoring is good, it makes dholbach happy ;-)
[10:05] <Sweetshark> cjwatson: http://paste.ubuntu.com/1062452/plain/ gives me "Not enabled for copying to PPAs yet."
[10:05] <cjwatson> Sweetshark: Oh, bah, I forgot about that
[10:05] <dholbach> xnox, go go go go go!
[10:05] <xnox> infinity: why did you break dch?  `dch -R --distribution quantal -m 'No change rebuild'` produces a maintainer line on the new changelog.... same as the TIL person instead of me.
[10:05]  * dholbach hugs seb128 and xnox
[10:06] <seb128> xnox, btw can you run the command I pointed on bug #1018021 ?
[10:06]  * seb128 hugs dholbach back
[10:06]  * xnox gigles
[10:06] <tumbleweed> xnox: it works just fine for me on Debian
[10:06] <xnox> tumbleweed: =(
[10:06] <cjwatson> Sweetshark: That might actually be fixable because I don't think the reason that was disabled is valid any more, but I'll need to do some testing
[10:07] <cjwatson>             # We have no way of giving feedback about failed jobs yet,
[10:07] <cjwatson>             # so this is disabled for now.
[10:07] <cjwatson> But I think we actually do now
[10:07] <xnox> seb128: i think I do have a few non-policy compliant non-free packages installed....
[10:07] <tumbleweed> xnox: err, no that was due to my configuration. but it did use my name+email
[10:07] <xnox> tumbleweed: name+email or DEB_* name & email?
[10:08] <tumbleweed> xnox: don't follow
[10:08] <seb128> xnox, right, is one of those messing up with the conffile? in which case I will happily NOTMYISSUE your bug ;-)
[10:10] <xnox> seb128: not now, but how would I know? I have installed and purged acroread in between. Deffo mark it as invalid due to a bug in non-ubuntu package
[10:10] <seb128> xnox, acroread is known as having this bug so yes I will close as invalid, thanks
[10:11] <xnox> seb128: thank you for looking after the bug, and pinging me.
[10:11] <xnox> and sorry for the noise ;-)
[10:11] <seb128> xnox, yw ;-)
[10:11] <seb128> no worry ;-)
[10:13] <Sweetshark> cjwatson: are you enableing it?
[10:14] <cjwatson> Sweetshark: I'll look at it, although timescale will be (at best) more like days than minutes
[10:14] <Sweetshark> cjwatson: the alternative is hugging amd64 and i386 buildd for 2*6hours ;)
[10:14] <Sweetshark> cjwatson: ok, its buildd hugging then.
[10:14] <cjwatson> Well
[10:14] <cjwatson> (ITYM hogging)
[10:15] <cjwatson> I wonder if I can do anything with copy-package.py
[10:15] <cjwatson> Sweetshark: Can you tell me exactly what you want copied from where to where?
[10:15] <cjwatson> I might be able to administratively intervene
[10:15] <Sweetshark> cjwatson: the two "libreoffice" packages from https://launchpad.net/~bjoern-michaelsen/+archive/libreoffice-quantaltest-20120601 to https://launchpad.net/~libreoffice/+archive/libreoffice-prereleases
[10:16] <cjwatson> Sweetshark: So that's for precise and quantal?
[10:16] <Sweetshark> cjwatson: (and I mean hogging, but hugging sounds so much more friendly)
[10:16] <Sweetshark> cjwatson: yes.
[10:17] <Sweetshark> cjwatson: yes (precise and quantal)
[10:17] <Laney> Hmm, wouldn't the PPA web UI for copying work here?
[10:18] <AlanBell> dhcp3-client dhcp3-common grub-common grub-pc grub-pc-bin grub2-common would seem likely to be the offending updates
[10:18] <AlanBell> sorry, wrong channel (but precise machines are breaking today)
[10:18] <cjwatson> Laney: No, the asynchronous mode is currently disabled and the synchronous mode times out
[10:19] <cjwatson> Laney: I'm fixing this (by re-enabling the asynchronous mode and deleting the synchronous mode), but not on the timescale Sweetshark needs
[10:19] <Laney> I see, so using copyPackage via API is to work around UI timeouts
[10:20] <cjwatson> Yes - except that it's disabled for copies to PPAs
[10:20] <cjwatson> So copy-package.py is the only remaining option
[10:20] <cjwatson> lp_archive@cocoplum:~$ copy-package.py -p bjoern-michaelsen --ppa-name libreoffice-quantaltest-20120601 --to-ppa libreoffice -s precise --to-ppa-name libreoffice-prereleases --to-suite precise -b libreoffice
[10:20] <cjwatson> lp_archive@cocoplum:~$ copy-package.py -p bjoern-michaelsen --ppa-name libreoffice-quantaltest-20120601 --to-ppa libreoffice -s quantal --to-ppa-name libreoffice-prereleases --to-suite quantal -b libreoffice
[10:20] <cjwatson> Sweetshark: Done
[10:21] <cjwatson> (Er, slightly odd option ordering there, never mind)
[10:22] <Sweetshark> cjwatson: thanks alot!
[10:22]  * Sweetshark bows galantly to cjwatson.
[10:22] <Sweetshark> ;)
[10:22] <cjwatson> Sweetshark: So, er, the set of people who can do this is not easy to enumerate because it's the subset of ~ubuntu-archive who have shell accounts on cocoplum - feel free to just ask me if you need this done again, and I'll consider it as impetus to get something better working
[10:23] <Sweetshark> cjwatson: ah, motivattion by annoyance! ;)
[10:23] <Sweetshark> cjwatson: yes, will do.
[10:23] <cjwatson> It's powerful
[10:24] <Sweetshark> cjwatson: we should write a book about it -- after TDD, XP, pair programming: annoyance-driven development
[10:25] <cjwatson> So, let's see - copy-packages-with-default-series has landed, so I could maybe upgrade dogfood, flip that feature flag, construct something that will fail to copy, and see if it shows up on the PPA page
[10:25] <cjwatson> I think I should finish the other thing I was doing first :-)
[10:31] <infinity> xnox: I did nothing to break it, that behaviour was broken before I got to it.
[10:36] <xnox> infinity: hmm... ok
[11:31] <jdstrand> @pilot in
[11:47]  * dholbach hugs jdstrand
[11:47] <xnox> jdstrand: please review py3 port of apport.... =)
[11:49] <jdstrand> heh
[11:49] <jdstrand> I'll see what I can do
[11:50] <seb128> xnox, isn't apport already py3 compliant in quantal for a while?
[11:50] <vibhav> xnox: Arent you a core devel?
[11:50] <xnox> seb128: there is ongoing confusion between me, pitti, ogra_  and now you. when I say apport, I meant *apparmor*.
[11:51] <seb128> xnox, hehe, makes sense now ;-)
[11:51] <xnox> for some reason we use the two names interchangeably given the context
[11:51] <vibhav> jdstrand: Could you have a look at https://bugs.launchpad.net/ubuntu/+source/dbus-java/+bug/1019178 ?
[11:51] <jdstrand> xnox: ahh!! that makes much more sense. I will gladly look at that :)
[11:51] <xnox> and somebody always pops up and 'hey what do you mean the other one'
[11:51] <xnox> jdstrand: as part of piloting ;-)
[11:51] <ogra_> yeah, we should rename them to iSecurity and iShield :) "App" is so worn out already
[11:52] <vibhav> ogra_: hah
[11:52] <jdstrand> xnox: yes-- convenient for me indeed :)
[11:52] <vibhav> ogra_: Wouldnt that sound too "Applish" ?
[11:52] <ogra_> you mean AppArmor and AppOrt dont ?
[11:53] <seb128> ogra_, wrong letter, we are "u" around, uSecurity and uShield
[11:53] <ogra_> oh, indeed !
[11:53] <seb128> ;-)
[11:53] <vibhav> I dont think apple invented the word "app"
[11:54] <vibhav> We should have a slogan like "There is a .deb for that" or something :P
[11:54] <ogra_> well, microsoft didnt invent the word "windows" either
[11:54] <vibhav> s/we/debian based distros/
[11:54] <xnox> seb128: isn't it ufw should be named uShield
[11:54] <ogra_> (and stil they called their OS after a hole in the wall ...)
[11:54] <seb128> xnox, indeed!
[11:58] <vibhav> "If you want to $VeryComplexAction , there is a deb for that!" :D
[12:32] <Chipzz> vibhav: except I wouldn't use the word .deb .. most users don't care about the unerlying technology
[12:37]  * hyperair likes how apple and amazon fought over the "app store" term, which is so generic it's laughable.
[12:38] <hyperair> "i'm sorry, but i trademarked the toothbrush. you can't call your toothbrush a toothbrush any more."
[12:38] <vibhav> hyperair: haha
[12:39] <vibhav> ".deb store" sounds pretty good too
[12:39] <hyperair> but nobody knows wtf a .deb is
[12:40] <hyperair> at least not new users
[12:40] <hyperair> they'd be like "i've got this setup.exe, how can i install it on ubuntu?"
[12:40] <vibhav> mm
[12:41] <hallyn> jml: bug 891045 is a dup of bug 974584, which is where that one was being handled
[12:41] <hallyn> jml: it's being handled through the debian bug now
[12:43] <hallyn> jml: oh, wait, now...  that's an *upgrade* in a chroot, not the debootstrap.  in the end there is only so much we can do to handle existing setups, but i do think that one will be handled by the fix to bug 974584.  i*think*
[12:43] <hallyn> can't decidewhether to mark it a dup or not
[12:44] <jml> hallyn: thanks.
[12:45] <jml> hallyn: so, AIUI, the precise task on sysvinit will be marked "Fix Released" when the fix is available in precise?
[12:46] <hallyn> jml: hm.  no, i thought it was going to not be fixed in precise, because in precise it was worked aroudn in lxc.
[12:46] <jml> hallyn: hmm.
[12:46] <hallyn> jml: since it affects others, not in lxc, i guess it will need to be srud after all
[12:47] <jml> hallyn: I'm no expert. This is being driven by #juju's recommendation that I put "rmdir /dev/shm; ln -s /run/shm /dev/shm" as per http://permalink.gmane.org/gmane.linux.kernel.containers.lxc.general/3724 so I can run 'apt-get dist-upgrade' without the whole thing falling over.
[12:47] <hallyn> jml: right, see that's a different problem :)
[12:47] <hallyn> a simpler one - that gets messed up in debootstrap,
[12:47] <hallyn> where the chroot hasn't had a chance to get messed up
[12:48] <hallyn> the 'upgrade in chroot' is more complicated, because who knows what shape the chroot is in
[12:48] <hallyn> that's why i'm torn on whether to mark the one a dup of the other or not
[12:51] <jml> hallyn: hmm. ok.
[12:52] <jml> hallyn: mostly what I want is a URL I can put above that work-around in a comment that says "look at this URL. If it says 'Fixed', try removing this kludge and see what happens."
[12:53] <hallyn> jml: oh i decided to mark it a dup anyway, bc it shoudl remove that warning
[12:55] <jml> hallyn: cool, thanks.
[13:33]  * apw looks for an archive admin to stroke a linux-lowlatency kernel in quantal
[13:57] <hallyn> say, is usb-creator-gtk supposed to be friendly with quantal iso's right now?
[14:02] <hippiehacker> anyone have an example of what oem-config oem-config/repository should be set to?
[14:03] <hippiehacker> trying to seed an oem run
[14:06] <zul> can an archive admin review python-swiftclient please?
[14:17] <xnox> cjwatson: ^^^ hippiehacker
[14:17]  * apw looks for an archive admin to stroke a linux-lowlatency kernel in quantal
[14:20] <cjwatson> xnox: I have no context; my network connection dropped
 anyone have an example of what oem-config oem-config/repository should be set to?
 trying to seed an oem run
[14:20] <xnox> cjwatson: ^^^
[14:21] <cjwatson> hippiehacker: It's just the same format as a single line in sources.list
[14:51] <saurabh> Hello. Can somebody tell how can we import webkit python module into ubuntu
[14:51] <saurabh> its giving an import error
[14:51] <saurabh> says "no module named webkit"
[14:53] <saurabh> anybody?
[14:57] <ScottK> Do you have the package python-webkit installed?
[14:58] <dobey> saurabh: you should use the gi bindings
[14:59] <cjwatson> ... i.e. 'from gi.repository import WebKit'
[14:59] <cjwatson> (Install python-gi or python3-gi as appropriate, and gir1.2-webkit-3.0)
[15:09] <saurabh> I have tried using gi bindings but its gives an error too
[15:11] <cjwatson> Then say what that error is
[15:11] <saurabh> just a moment, I will post here
[15:12] <saurabh> ImportError: could not import gobject (error was: ImportError('When using gi.repository you must not import static modules like "gobject". Please change all occurrences of "import gobject" to "from gi.repository import GObject".',))
[15:12] <stgraber> saurabh: from gi.repository import GObject
[15:12] <cjwatson> Right, as he says.  You can't mix and match old and new style.
[15:13] <saurabh> let me try
[15:13] <cjwatson> In general if an error message gives you explicit instructions on what to do it's probably a good idea to at least try those instructions before asking :-)
[15:13] <saurabh> its still giving an error
[15:14] <saurabh> ImportError: cannot import name _API
[15:14] <cjwatson> That sounds like something specific to your code
[15:15] <cjwatson> Perhaps post it to a pastebin
[15:15] <saurabh> I tried this "from gi.repository import Webkit"
[15:16] <saurabh> what does this mean "ERROR:root:Could not find any typelib for Webkit"?
[15:16] <cjwatson> WebKit not Webkit
[15:16] <cjwatson> The capitalisation matters
[15:17] <saurabh> ok
[15:17] <saurabh> I think, its working now...
[15:18] <saurabh> thanks guys :)
[15:18] <cjwatson> you're welcome
[15:18] <slangasek> didrocks: heya, why exactly is compiz-plugins using a deprecated version of libjpeg?
[15:18] <slangasek> didrocks: (libjpeg62 vs libjpeg8)
[15:22] <didrocks> slangasek: hey, I think there is no actual reason. I can do a test with the newer version and see what happens
[15:22] <slangasek> didrocks: would appreciate it :)  This is actually a change in the latest upload, it was using libjpeg8 before
[15:23] <didrocks> slangasek: well, as you can see the latest upload is merging 8 sources in one
[15:23] <didrocks> slangasek: so when merging the build-dep, I tried to be on the safe side and picking the lower one :)
[15:23] <slangasek> ah
[15:23] <didrocks> but let me see with the newer one ;)
[15:49] <mterry> ScottK, hello!  So the release-upgrade bits of update-manager-kde are shortly moving to ubuntu-release-upgrader-qt.  I'll update seeds, but just wanted to give a heads up
[15:51] <mterry> ScottK, oh, the kubuntu seeds don't even use it...
[15:52] <ScottK> mterry: Yes, but users do use it.
[15:52] <ScottK> IIRC.
[15:52] <mterry> ScottK, OK.  It's not dying, but sounds like I don't need to update anything except the archive.  Thanks!
[15:53] <ScottK> mterry: It is a rdepend of muon-notifier.
[15:53] <ScottK> That we do use.
[15:54] <ScottK> mterry: That will need to be fixed.
[15:54] <mterry> ScottK, OK.  update-manager-kde still exists, so I'll just see if muon-notifier is using the release-upgrader bits and fix accordingly if so
[15:56] <ScottK> mterry: Here's our documentation on upgrading: https://help.ubuntu.com/community/PreciseUpgrades/Kubuntu
[15:56] <ScottK> It looks like it does in fact use it for upgrades.
[15:57] <ScottK> Also, personally I'm suprised the KDE bits are being removed.  Was this coordinated with anyone?
[15:57] <seb128> [ -e $$i ] || continue; in a rules
[15:57] <mterry> ScottK, sorry, nothing is being removed.  I'm just splitting out update-manager and release-upgrader stuff into two separate sources
[15:57] <seb128> is there a way to extend the test to add a -L check while keeping the short version?
[15:58] <mterry> ScottK, which package is calling do-release-upgrade in that documentation?  I can't see such a call in muon source
[15:58] <ScottK> mterry: I don't know.
[15:58] <mterry> ScottK, OK.  /me digs
[15:58] <seb128> or do I need to change to a if [ -e ] && [ -L ]; then?
[15:59] <ScottK> I imagine Riddelll does, but I don't think he's around.
[16:00] <cjwatson> seb128: -L implies -e, except for the case of broken symlinks; does that matter?
[16:00] <cjwatson> Otherwise, various options:
[16:00] <cjwatson> ([ -e $$i ] && [ -L $$i ]) || continue
[16:00] <seb128> cjwatson, yes, I want to include broken symlinks as valid
[16:01] <cjwatson> [ -e $$i ] || continue; [ -L $$i ] || continue
[16:02] <cjwatson> And you can probably do something with inverting both tests somehow but I don't think it'd be very clear
[16:02] <seb128> cjwatson, thanks
[16:02] <seb128> cjwatson, I messed up my parenthesis use when I tried what you listed first, yours works, thanks ;-)
[16:03] <cjwatson> yw
[16:03] <didrocks> slangasek: looks fine to me with the newer jpeg, uploading with that
[16:05] <xnox> didrocks: 5 left to go!  http://people.canonical.com/~ubuntu-archive/transitions/libjpeg.html
[16:05] <slangasek> didrocks: super
[16:05] <didrocks> heh ;)
[16:07] <BenC> hoorah, powerpc ftbfs is tied for first with amd64
[16:08] <jdstrand> @pilot out
[16:09] <cjwatson> BenC: Impressive
[16:21] <ScottK> jelmer: I verified your bzr regression fix and will copy it to -updates as soon as it's built.  Thanks.
[16:34] <PaoloRotolo> Hi all!
[17:00] <smoser> hm..
[17:00] <smoser> anyone able to explain this
[17:01] <Daviey> smoser: unlikely
[17:01] <smoser> i ran 4 instances of the cloud images on a openstack cloud.
[17:01] <smoser> 2 were precise, 2 were quantal (alpha2)
[17:01] <smoser> upon their coming up, ssh in and see how long the resize2fs to grow the filesystem took.
[17:02] <smoser> http://paste.ubuntu.com/1066330/ is the results, and then results repeated at http://paste.ubuntu.com/1066365/
[17:03] <slangasek> maxb: hi, do you know why sbsigntool (new package in quantal) doesn't show up as being in the importer queue? http://package-import.ubuntu.com/status/
[17:03] <smoser> basically, resize2fs on quantal happens in very rougly 1/10 the time it did on precise.
[17:03] <smoser> (it could be coincidence based on hosts IO performance)
[17:03] <maxb> slangasek: hmm, I'll look. When was it published?
[17:04] <cjwatson> e2fsprogs (1.42.2-1) unstable; urgency=low
[17:04] <cjwatson>   * Speed up resize2fs for large file systems (Closes: #663237)
[17:04] <xnox> smoser: quicker or slower? quantal has newer e2fsprogs
[17:04] <cjwatson> smoser: ^-
[17:04] <cjwatson> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=663237
[17:04] <smoser> quantal is faster.
[17:04] <cjwatson> Now that says shrinking; don't know if it's related
[17:04] <xnox> smoser: there is SRU in unapproved with latest e2fsprogs, such that it is in the pipeline for prcise
[17:05] <smoser> utlemming, ^
[17:06] <utlemming> interesting
[17:06] <smoser> cjwatson, well, the changelog entry is "Speed up resize2fs for large file systems". i wouldn't exactly think of a resize from 1.4G -> 10G to be "large"
[17:07] <smoser> but it explicitly does not mention the shrink.
[17:07] <smoser> so that certainly sounds like a hit.  and a very nice bug fix.
[17:07] <smoser> i had always just assumed that it was IO that was limiting.
[17:07] <mterry> bdmurray, jibel: hey folks, just FYI that there is a new source package you may care about.  ubuntu-release-upgrader, which holds some code pulled from update-manager
[17:08] <mterry> (in terms of bug subscriptions and such)
[17:08] <cjwatson> smoser: I'm only making an educated guess, but it seems like a good place to start looking if you care to look into it further
[17:08] <smoser> cjwatson, nah. it seems like a *really* good guess.
[17:08] <smoser> and i'm happy to have something run 10x faster
[17:10] <cjwatson> I was going to say, it's not normally the sort of thing you'd complain about. :-)
[17:10] <smoser> and xnox you're implying that htat is going to come back to precise for me too?
[17:10] <smoser> that makes it even nicer.
[17:12] <Laney> xnox: meet cyphermox. Someone else who is interested in teaching ben about proposed :-)
[17:12] <xnox> smoser: yes. If you have capacity to test big data filesystems and comment on the bug 978012 that would be nice. ps. big filesystem is >16TB
[17:13] <xnox> utlemming:  smoser: yes. If you have capacity to test big data filesystems and comment on the bug 978012 that would be nice. ps. big filesystem is >16TB
[17:15] <utlemming> xnox: well, I think I have a spare PB array under my desk :)
[17:16] <utlemming> xnox: but in all seriousness, you could create one on EC2...might be a bit spendy though
[17:18] <xnox> utlemming: PB array you say, is it RAID? =) cause testing things like mdadm on PB would be great!
[17:18] <xnox> I will check if I can get the expenditure for EC2
[17:20] <smoser> utlemming, on ec2, volume slimited to 1TB
[17:20] <smoser> so gettin to 16 would require raid across 16 of them.
[17:20] <utlemming> smoser: right
[17:20] <utlemming> smoser: you'd have to LVM or mdadm it
[17:20] <smoser> right.
[17:20] <xnox> ok
[17:21] <smoser> xnox, but you could do it. and the cost is $0.10/GB Month.
[17:22] <smoser> so if you only had it up for 1 day, 0.10 * 16 * 1024 / 30 = ~ $54
[17:22] <smoser> oh, i wonder if htere is a max volumes per account by default though.
[17:22] <xnox> smoser: does it charge per day though?
[17:22] <xnox> or per month for storage?
[17:23] <utlemming> per month, but the average of the month
[17:23] <utlemming> which is why it would only cost $54
[17:23] <smoser> and potentially cost $0.0
[17:23] <xnox> define *average* =) as long as they take daily or hourly average
[17:23] <smoser> if you happened to hit the accounting right
[17:23] <xnox> I will check the accounting ;-)
[17:24] <maxb> slangasek: I've been unable to determine why it happened (no logging from the script in question), but I've queued it manually
[17:24] <utlemming> the problem is that allocating that much could take a few hours. I did a similiar test two years ago and it took about 3 hours for the volumes to be ready
[17:26] <smoser> yeah. so, it is not going to be free.
[17:26] <smoser> and then you'll also pay for IO, which i guess probably adds up on 16TB
[17:27] <slangasek> maxb: ta :)
[17:27] <smoser> http://serverfault.com/questions/336825/amazon-ec2-ebs-pricing-over-a-month-of-dynamically-allocated-space is relative
[17:27] <smoser> relavent
[17:30] <dylan-m> Hey, anyone know if 12.10 will have any symbolic icons? (A symbolic system-restart icon, in particular?)
[17:32] <bdmurray> mterry: thanks!
[20:46] <ahasenack> hi, could I get an sru sponsor to take a look at #1004678 please? Thanks
[20:46] <ahasenack> bug #1004678
[20:52] <infinity> ahasenack: Do you not have a regular sponsor for landscape?
[20:52] <ahasenack> infinity: not really
[20:53]  * infinity notes that pitti did the last round.
[22:16] <SpamapS> ahasenack: is there any reason you can't use the normal sponsorship queue?
[22:16] <ahasenack> SpamapS: am I not?
[22:16] <SpamapS> ahasenack: you are not when you ask for somebody to look at your item before others. :)
[22:16] <ahasenack> ah, in that sense
[22:17] <SpamapS> If its a critical update then that is perfectly acceptible.
[22:17] <ahasenack> SpamapS: boss breathing on my neck, that's all
[22:19]  * ahasenack -> dinner
[22:22] <SpamapS> darn the wiki foiled my plan to show him that there should have been *4* patch pilots today
[22:22] <SpamapS> https://www.google.com/calendar/embed?src=6k1e5rq45m1bdqq0n1ge3oqaok@group.calendar.google.com&ctz=Europe/Berlin&gsessionid=OK
[22:23] <xnox>  29/06 23:11:23 <rlb> fwiw, emacs24 has been uploaded to unstable
[22:23] <xnox> barry ^
[22:28] <Beret> SpamapS, it is blocking a release
[22:29] <Beret> SpamapS, if it was a typical update, we wouldn't be bothering anyone
[22:30]  * micahg figures landscape updates aren't the type of thing you'd want to push out at 5PM on Friday
[22:33] <slangasek> generally not a concern for publishing to -proposed
[22:34] <micahg> true, but the week would be up then as well though
[22:42] <infinity> micahg: We're trying to do away with the concept of waiting exactly 7 days anyway.  But yes, publishing on a Friday should be a no-go, except in dire circumstances.
[22:51] <ScottK> infinity: I think that philosophically that's counter to your arguments about milestones.  If our SRUs are so crappy we're afraid to release them on Friday, then the solution is to do better SRUs.
[22:54] <infinity> ScottK: It's not so much about quality as least surprise.  Lots of people who aren't me don't work weekends, and Friday updates can leave people a bit confused about why they have 873 voicemails over the weekend.
[22:54] <infinity> ScottK: While quality's the goal, mistakes always happen.  (I don't see how this relates to the milestone thing at all).
[22:56] <infinity> ScottK: In fact, it seems in line with my milestone philosophy.  Pretending a milestone is perfect because people stopped for two days to make it is about as silly as pretending an SRU is perfect because 3 people tested it.  Reality isn't ever on our side there.
[22:56] <geofft> cjwatson: did you see the UEFI Firmware Agreement from MS on the sysdev site? Looks like _it_ excludes GPLv3 bootloaders, so what FSF says is irrelevant :(
[22:56] <infinity> geofft: Public URL for this?
[22:57] <geofft> Hm, not sure there is one, let me save a copy
[22:57] <slangasek> geofft: that refers to objects that Microsoft is willing to sign, for the same basic reason (they don't want to receive a court order forcing them to disclose their private keys)
[22:57] <infinity> ScottK: So, absolutely, in both cases, jacking up quality (and QA) is the answer, but that doesn't mean you also tempt fate and release on a Friday. ;)
[22:58] <geofft> Oh, hm, I guess it does mean that the shim bootloader is still fine.
[23:00] <geofft> infinity: http://ldpreload.com/p/windows-logo-uefi-amendment.pdf
[23:00] <slangasek> correct - RH has already solved that part
[23:02] <slangasek> geofft: haha, why does that copy of the pdf crash evince?
[23:03] <geofft> Well, it came to me as a pdfx, but file says it's a PDF...
[23:03] <geofft> Works in evince on Natty, in any case. Also, uploaded a new copy that takes my company's name out
[23:04] <geofft> since if I do something silly like post that PDF publicly, HN is going to link to it in 3, 2...
[23:16] <ScottK> infinity: I think it depends a lot on the SRU.  KDE point release - sure, I agree.  Two line obviously correct fix that helps people out, I think you can go for it.
[23:17] <ScottK> There are a surprising number of people the just run with -proposed enabled, so at least for common/core packages if you break it in any obvious way, you'll find out.
[23:17] <infinity> ScottK: Discretion and common sense are always a factor, sure.
[23:17] <ScottK> I agree with don't release scary ones on Friday, but I don't think it's a good general rule.
[23:22] <infinity> ScottK: Well, I think we have too many "general rules", so I agree with you there.
[23:23] <infinity> ScottK: While some parts of the process need to be vaguely rigid and formal, the aim of the "make things more agile" spec was to try to get people to think a little bit while they're doing their robotic tasks. :P
[23:23] <infinity> Well, one of the aims.
[23:24] <ScottK> I did accept some SRU's today.  In one case I actually went back and re-reviewed the diff to see if it was a good idea.
[23:24] <infinity> ScottK: That said, I think micah's point about landscape being a poor choice for a Friday update may well be on point.
[23:25] <infinity> ScottK: Given that the sorts of people who use landscape may we be exactly the same sorts of people who update and leave for the (long, in Canada) weekend, and come back to "oh god, wut?"
[23:25] <infinity> s/may we/may well/
[23:25] <ScottK> Personally I'm not that worried about regressions in clients to proprietary services, but I understand others may feel differently.
[23:25] <infinity> ScottK: Heh.  Indeed.  It's what the client does that matters. ;)
[23:26] <infinity> ScottK: (I'd have similar reservations about an upstream bump with a massive patch to, say, how ksplice works)
[23:26] <ScottK> I'd have reservations just based on who owns it.
[23:26] <infinity> You know, if we distributed the proprietary kplice client, which we don't.
[23:26] <ScottK> Yeah.
[23:27] <infinity> As opposed to, say, updating purple/telepathy, which is also a collection of client for proprietary services that have a much slimmer chance of wedging your computer when you're not looking.
[23:28] <ScottK> Are they all proprietary?
[23:29] <ScottK> (I haven't looked)
[23:30] <slangasek> bdmurray: seems like bug #1019448 is the sort of thing that should've auto-duped
[23:31] <slangasek> bdmurray: is there not support for matching on file conflicts in apport?  maybe it's not common enough to have been dealt with?
[23:31] <slangasek> (they're certainly the sort of bug we should be able to triage with high-certainty and should treat as high priority)
[23:43] <infinity> ScottK: XMPP can go both ways (see GTalk versus, say, private jabberd servers)
[23:44] <ScottK> Right.
[23:44] <infinity> ScottK: Most of the other services (AIM, ICQ, MSN, Yahoo, Twitter, etc, etc) are, of course, very proprietary.
[23:44] <ScottK> For Kubuntu we're switching from Kopete to KDE telepathy for 12.10, so I haven't really experimented with it much.
[23:44] <infinity> I'm happy to hear that tp-qt4 is actually, finally usable.
[23:45] <infinity> I was involved in the initial tp-glib->tp-qt4 port/mangling (whatever you want to call it), and it was a mess for ages.