[00:00] <slangasek> mind you, I don't see what's *caused* that broken symlink... but I don't see anything multiarch-related here
[00:01] <andersk> Yeah, it’s only multiarch-related in that it causes multiply-installed multiarch packages to fail to reinstall.
[00:02] <slangasek> andersk: that's a mis-migration in the fuse-utils binary package
[00:02] <slangasek> $ dpkg -c /mirror/ubuntu/pool/main/f/fuse/fuse-utils_2.9.0-1ubuntu2_all.deb |grep changelog
[00:02] <slangasek> lrwxrwxrwx root/root         0 2012-06-11 09:18 ./usr/share/doc/fuse-utils/changelog.Debian.gz -> ../libfuse2/changelog.Debian.gz
[00:02] <slangasek> yet /usr/share/doc/fuse-utils is itself a symlink to libfuse2
[00:04] <andersk> /usr/share/doc/ure/changelog.Debian.gz is the other example I see.
[00:21] <dupondje> What is the reason some packages are more recent in Precise then in Qunatal? For example bind9
[00:24] <RAOF> dupondje: Because people have been naughty, it seems.
[00:25] <RAOF> Or because we expect a new version in quantal real-soon-now.
[00:25] <dupondje> no newer version in debian neither
[00:26] <dupondje> so I doubt there is a new version comming real soon :)
[00:29] <RAOF> Hm. What bug was the SRU associated with?
[00:41] <dupondje> RAOF: was due to http://www.ubuntu.com/usn/usn-1462-1/
[00:41] <dupondje> but can't find bug directly :s
[01:25] <gnomefreak> is it known that dpkg update is spitting out a 403 forbidden error
[01:26] <slangasek> yes
[01:26] <slangasek> http://identi.ca/notice/94752326
[01:26] <StevenK> There's a good reason for that, too.
[01:30] <gnomefreak> thanks
[03:08] <TheMuso> @pilot out
[03:36] <micahg> jbicha: you took away infinity's beer: http://people.canonical.com/~ubuntu-archive/testing/quantal_probs.html
[03:44] <pitti> Good morning
[03:53] <jbicha> micahg: I think evolution is ok now, evolution-exchange can just be synced from Debian later today
[03:55] <micahg> jbicha: yeah, I was referring to evolution-exchange :)
[03:57] <micahg> infinity: i386 and powerpc are tied now (including depwaits) :)
[04:07] <pp7> why is there a small thin line just under the titlebar when i move windows around?
[04:08] <pitti> cjwatson, ev: https://jenkins.qa.ubuntu.com/view/Quantal/view/AutoPkg%20Test/job/quantal-adt-ubiquity/lastFailedBuild/ARCH=i386,label=albali/ failed due to not finding the "mock" module; I think you need to change python-mock to python3-mock in debian/tests/control
[04:09] <pitti> cjwatson, ev: OOI, what does the "@" do in d/t/control's Depends: line?
[04:22] <infinity> micahg: My poor beer. :(
[04:22] <infinity> micahg: On a more positive note, if the test build ever finishes, I suspect I have mono/armel licked.
[04:23] <infinity> micahg: With that, dpkg, and debhelper, I intend to do a mass-give-back and see what sticks.
[04:23] <micahg> infinity: yeah, armel takes the cake for failures
[04:23] <infinity> micahg: It's mostly just fallout from mono and ghc.
[04:24] <infinity> micahg: I have the ghc fix in the wings, just need to jam the rebootstrap in sideways.
[04:24] <micahg> cool
[04:32] <infinity> So, after our panic to fix dpkg, has anyone run into problems with -3ubuntu2?
[04:34]  * pitti must admit he never noticed any trouble with dpkg
[04:35] <infinity> pitti: Then you didn't have multi-arch:same packages installed when you upgraded to -3ubuntu1
[04:35] <infinity> Or, rather, not ones with triggers.
[04:35] <infinity> So, desktop ones like libgtk.
[04:36] <pitti> $ dpkg -l *:i386 | wc -l
[04:36] <pitti> 78
[04:36] <pitti> not GTK, though
[04:36] <infinity> Yeah.  Was an issue specifically with packages with triggers.
[04:37] <infinity> Hence why I didn't catch it pre-upload.  Didn't test on a fully-loaded m-a/desktop mess.
[04:37] <infinity> Oh well.
[04:37] <infinity> Sort of "fixed" now in the most recent version, but we need to revisit it later with different shaped hammers.
[04:40] <larsduesing> it won't be honoured, if I add a patch to a package in ubuntu, if this patch is in upstream bugzilla for >2 years as enhancement, nobody at upstream cares about, but users are asking me what's on with that patch?
[04:40] <larsduesing> good morning :-)
[04:48] <TheMuso> [B/c
[04:49] <micahg> larsduesing: is it an Ubuntu specific package?
[04:54] <larsduesing> no
[04:55] <larsduesing> cyrus-sasl...
[04:55] <larsduesing> :)
[04:56] <larsduesing> https://bugzilla.cyrusimap.org/show_bug.cgi?id=3219
[04:56] <larsduesing> (oh, cool... ubottu is really smart :) )
[04:58] <micahg> larsduesing: I suggest speaking with the Debian devs about it, as they sometimes have upstream connections (the Debian SASL team seems to have an ML as well) http://packages.qa.debian.org/c/cyrus-sasl2.html
[05:00] <larsduesing> good idea..
[05:00] <larsduesing> thanks
[05:04] <infinity> Ooo, my mono/armel passed the point where it failed on the buildds...
[05:04] <infinity> Exciting times.
[05:05] <infinity> Now, do I upload it and pray it doesn't fail later, or wait?
[05:11] <larsduesing> micahg: omg... there are _bugs_ in debian-bts (I would identify as security-ones...) from 2008 not patched in sasl...
[05:12] <larsduesing> so talks from debian to cmu aren't much better either...
[05:12] <micahg> larsduesing: well, it's maintained (last upload 3 months ago, but they might need help if this is an itch you'd like to scratch)
[05:12] <micahg> larsduesing: I still suggest speaking with them as upstream seems active enough (average one release per year)
[05:13] <larsduesing> yes
[05:14] <larsduesing> there are current git commits (last 10days ago)
[05:18] <micahg> larsduesing: there are no known open security issues in Ubuntu for cyrus-sasl2: http://people.canonical.com/~ubuntu-security/cve/pkg/cyrus-sasl2.html, if there are issues affecting us, please let the security team know: https://wiki.ubuntu.com/DebuggingSecurity#How%20to%20File
[05:28] <larsduesing> I must confirm if there is still a bug... working on it
[06:04] <pitti> cjwatson, ev: wrt adt-ubiquity again, I think there's a bug in autopkgtest; ubiquity does not specify "no-build-needed", so it shoudl buidl the package and therefore install all its build deps (which include python3-mock)
[06:04] <pitti> jibel: ^ FYI
[06:05] <jibel> pitti, I filed bug 1015400
[06:06] <pitti> jibel: ah, thanks; following up there
[06:08] <pitti> jibel: followed up with some details; I guess that broke with --no-built-binaries
[06:10] <jibel> pitti, I think so. without this option build-deps are installed and python3-mock is listed there.
[06:10] <pitti> right
[06:10] <pitti> but it should still build ubiquity in this case
[07:17] <dholbach> good morning
[07:59] <cjwatson> pitti: I think that autopkgtest behaviour is deliberate and sensible.  The tree has been built, but that doesn't mean that the tests are run in the same chroot that built it.  They really shouldn't assume that they do, since what they're trying to do is test the as-installed environment, which won't include build-dependencies.
[08:00]  * pitti is a bit lost with his brand new panda board; I wrote the daily-preinstalled to an USB stick, connected the board to a HDMI monitor, switch on, nothing happens at all except the green LED turning on
[08:00] <cjwatson> pitti: I'll fix that ubiquity control file bug, thanks.
[08:00] <pitti> https://wiki.ubuntu.com/ARM/OmapNetbook and http://testcases.qa.ubuntu.com/Install/ARM/PreinstalledImage don't give additional info either
[08:01] <cjwatson> pitti: Oh, no, you're right, I see now that it isn't trying to build the package, so yes that's a bug.  I think my point stands as well though
[08:01] <pitti> cjwatson: hm, I don't see a build in https://jenkins.qa.ubuntu.com/view/Quantal/view/AutoPkg%20Test/job/quantal-adt-ubiquity/37/ARCH=amd64,label=albali/artifact/results/log
[08:02] <pitti> cjwatson: right, that's why I left the ubiquity task open
[08:02] <cjwatson> pitti: @ means "all the binaries built by this source", per the spec
[08:02] <pitti> cjwatson: but nevertheless in that case it ought to have been built
[08:02] <pitti> (even if it's not necessary; I don't know if it is)
[08:02] <cjwatson> Yeah
[08:02] <cjwatson> It is
[08:02] <pitti> cjwatson: @> thanks
[08:27] <pitti> ogra_: do you know if there is any chance to set up a panda board without an SD card? I only have 1 GB cards available, but an 8 GB usb stick with the current preinstalled image
[08:28] <pitti> ogasawara: but I don't see anything at all on hdmi and the serial port
[08:28] <pitti> err, ogra_ ^
[08:28] <pitti> ogasawara: ignore me
[08:28] <ogra_> pitti, just use netinst, there are SD images
[08:29] <pitti> ogra_: uboot is the thing that talks to the serial port, isn't it?
[08:29] <ogra_> that gives you a normal alternate install
[08:29] <ogra_> well, MLO (first stage bootloader) initialize the serial port, then it loads uboot-bin
[08:29] <pitti> I had expected this to run from some internal flash; but it seems not even that is there
[08:29] <ogra_> nope,  to costly
[08:30] <pitti> I also followed http://www.omappedia.org/wiki/Ubuntu_Pre-built_Binaries_Guide, but no luck
[08:30] <ogra_> if you find something internal nowadays, its an eMMC
[08:30] <pitti> all documentation I can find is for sd cards
[08:30] <pitti> ogra_: i. e. the serial port is by and large useless, I just need a big enough SD card and then I don't need to worry about the serial port?
[08:31] <ogra_> the serial port is disabled in the desktop images ... you will only see the first few bootloader messages, else it behaves identically to an x86 images
[08:32] <ogra_> the server images do everything on serial though ...
[08:32] <ogra_> so if you got display probs, start with a server image
[08:32] <ogra_> if you want to do a real alternate install use the netboot images
[08:32] <ogra_> that enables you also to have / on USB
[08:33] <ogra_> (which is tons faster than SD, but you need the SD card as "bootfloppy" still)
[08:33] <pitti> ogra_: http://ports.ubuntu.com/dists/quantal/main/installer-armel/current/images/ -> no omap4?
[08:33] <ogra_> http://ports.ubuntu.com/dists/quantal/main/installer-armhf/current/images/omap4/netboot/boot.img-serial.gz
[08:34] <pitti> nevermind, armhf
[08:34] <ogra_> right, armel is semi dead
[08:39] <pitti> ogra_: thanks; with that image I at least see d-i in minicom
[08:39] <pitti> still no hdmi, though
[08:39] <pitti> the monitor doesn't even recognize that there's somethign attached to the cable
[08:39]  * ogra_ would recommend using screen for serial 
[08:39] <ogra_> try the dvi port instead
[08:40] <pitti> would that be boot.img-fb.gz ?
[08:40] <pitti> or sohudl it also work with -serial?
[08:40] <ogra_> thats a quantal image ? we had some display issues and are waiting for a new codedrop from TI, if you cant get it to work, downgrade to the precise kernel package
[08:40] <ogra_> the fb image defaults to framebuffer output, yep
[08:41] <pitti> ogra_: ok, when I use the dvi connector (not hdmi), the monitor recognizes the hdmi input; fun
[08:41] <pitti> ok, trying quantal
[08:41] <pitti> err, precise
[08:43] <Laney> let me know if you get DVI working
[08:43] <Laney> we talked about this a bit yesterday, seems nobody did
[08:43] <ogra_> well, try with a precise kernel then
[08:44] <Laney> I was trying the precise desktop image
[08:44] <ogra_> hmm, that should be flawless unless you have a weird monitor that reports wrong EDID data
[08:44] <Laney> maybe I did something wrong
[08:45] <ogra_> there is not much you can do wrong with the preinstalled images
[08:45] <ogra_> as long as your power supply is powerful enough andd your monitor isnt reporting insane things you should be fine
[08:46] <Laney> like I connected to the wrong HDMI port or something
[08:46] <ogra_> if your monitor *does* report insane things though, you can boot with it unplugged
[08:46] <ogra_> and plug it in after boot, that will give you at least 800x600 (fallback mode)
[08:47] <Laney> cheers, i'll try it later
[08:48] <pitti> ogra_: thanks for the hand holding! precise's -fb image works fine
[08:48] <ogra_> yay, good
[08:48] <pitti> ogra_: so I guess I'll buy a large SD card on Saturday and try again next week
[08:48] <ogra_> k
[08:49] <ogra_> note that we will switch to live images in quantal ... that means USB disk is required (ubiquity cant install to its installation media yet)
[08:54] <pitti> ogra_: that seems like what I want anyway; except that I'll still need the SD card for the initial boot?
[08:56] <ogra_> no, for all boots
[08:56] <ogra_> it will become your "bootfloppy" since there is no flash and no way to boot off a USB disk directly
[08:57] <pitti> ogra_: but that will boot from the USB stick, when it's plugged in?
[08:57] <pitti> (I mean the uboot part on the SD)
[08:58] <pitti> and if the USB stick doesn't have anything or is not present, continue to boot from the SD?
[08:58] <ogra_> right, but you need both, SD card and USB disk/card
[08:58] <pitti> yes, understood (that's what I meant with "initial" boot, the uboot part)
[08:58] <ogra_> no, it wont boot off the Sd anymore after install
[08:58] <pitti> so I guess I can use one of my 1 GB SDs for booting
[08:58] <pitti> and just need the large one for the install
[08:58] <ogra_> (new cmdline etc, no casper initrd anymore)
[08:59] <ogra_> right
[08:59] <ogra_> you can just dd the size of the first partition from one SD to another
[09:57] <pitti> cjwatson: ubiquity failed again, FYI; now needing python3-six :/
[09:58] <cjwatson> pitti: Yes, that's the autopkgtest bug, I think
[09:59] <cjwatson> pitti: ubiquity already depends on python3-six, so this shouldn't be needed in debian/tests/control
[09:59] <pitti> ah, so that's not actually the bug I meant
[09:59] <cjwatson> Oh
[09:59] <pitti> I meant that it does not attempt to build the package although it should
[09:59] <cjwatson> Wouldn't it be fixed by building and installing the binaries?
[09:59] <pitti> so you mean that it does not actually install the @ Depends:?
[09:59] <cjwatson> Apparently not
[10:00] <cjwatson> But perhaps that's simply because it didn't build them
[10:00] <cjwatson> It wouldn't surprise me to find that that was just a consequence
[10:00] <pitti> that would certainly hide the other bug, yes
[10:01] <pitti> but even if it installed ubiquity's build dependencies it would just mean it would test ubiquity from the built tree
[10:01] <pitti> instead of the system-installed bits from the ubiquity package
[10:01] <pitti> it should install the latter and test that, not the build tree
[10:01] <cjwatson> No, I mean that @ is "all the stuff I just built"
[10:01] <pitti> which is what the @ Depends: is supposed to do
[10:01] <cjwatson> And if it didn't build anything it would be null
[10:02] <pitti> oh, you mean it computes @ from teh list of built .debs, not from debian/control?
[10:02] <cjwatson> Which would have the effect of transitively losing python3-six
[10:02] <cjwatson> I'm not sure; it seems plausible though
[10:02] <pitti> that's again wrong, it needs to look at debian/control
[10:02] <pitti> as we have a lot of packages with no-build-needed
[10:02] <pitti> (as we just need the test suite from the source, nothing else)
[10:04] <pitti> jibel: ^ perhaps we should drop --no-built-binaries for now until these bugs are sorted out
[10:05] <jibel> pitti, sure, I'll revert the change.
[10:07] <pitti> I made a note in bug 1015400 to investigate that other bug, too
[10:12] <ev> GDBus GI bindings or python-dbus for new code?
[10:16] <pitti> ev: if you want to export DBus objects, python-dbus
[10:16] <pitti> ev: if you only want to call services, it doesn't matter much
[10:16] <ev> I do indeed
[10:16] <ev> thanks, I hadn't realized GDBus was missing that in what it exposed over GI
[10:17] <pitti> gnome bug 656325 FYI
[10:17] <pitti> ev: I finally fixed the underlying pygobject bug a while ago, but didn't get around to fixing this in glib, mostly because python3-dbus is there now
[10:19] <ev> pitti: subscribed. Thanks
[10:51] <cjwatson> mvo: Is there any way to use 'apt-ftparchive generate' to generate Contents files without it also generating Packages/Sources?  https://bugs.launchpad.net/launchpad/+bug/1013583
[11:26] <mvo> cjwatson: I don't think so, but adding it shouldn't be too hard, something like APT::FtpArchive::ContentsOnly could be added I presume
[11:30] <mvo> cjwatson: http://paste.ubuntu.com/1050714/ <- somehting like this maybe?
[11:30] <xnox> autofs has changed the # of times it forks, which results in upstart tracking wrong pid. The actual number of forks is now probably 4, instead of previous 1. But i'm not too sure, because depending on which auto.foo scripts are enabled there can be more forks.
[11:31] <xnox> I have changed autofs to run in the foreground mode instead, and let upstart connect conlose log to it into /var/upstart/autofs.log
[11:31] <xnox> but this means that automount messages no longer appear in syslog
[11:31] <xnox> i'm thinking to add descriptive changelog & NEWS entry w.r.t to this change
[11:32] <xnox> or is this issue serious enough to hunt down where/why autofs has changed its work behaviour
[11:33] <xnox> Daviey: slangasek: jodh: cjwatson: ^^^^^
[11:35] <cjwatson> mvo: Seems plausible, though I haven't looked in detail; if that works, do you think we could SRU that to lucid and precise, for LP's benefit?  (A bit out of the ordinary for an SRU, but we've done it before for apt-ftparchive.)
[11:36] <mvo> cjwatson: yes, I think that could be done
[11:36] <cjwatson> An hour of cocoplum time isn't to be sniffed at
[11:36] <cjwatson> Actually 1.5 hours
[11:36] <cjwatson> xnox: I think it's at least worth understanding what the extra forks are, to start with
[11:37] <xnox> cjwatson: ok. let me digg a bit further.
[11:41] <xnox> it's clones, not forks, but still...
[11:42] <cjwatson> Meh, much the same thing
[11:50] <Daviey> xnox: not having autofs logging at all is bit of a pain, but based on both issues, is the better of two.  Ideally, still logging the output somewhere would make me a happy bunny.. but i supposed you have explored that?
[11:51] <Daviey> xnox: i haven't checked, but i guess there is no --foreground --log= , similar option?
[11:52] <xnox> Daviey: /var/log/syslog -> /var/log/upstart/autofs.log for automount messages
[11:52] <xnox> Daviey: upstart by default now attaches console, e.g. stdout/stderr and flushes them into /var/log/upstart/$job.log
[11:52] <xnox> for free
[11:53] <xnox> Daviey: so instead of doing logcheck/logwatch/ manual troubleshooting from /var/log/syslog it now needs to be done from /var/log/upstart.....
[11:53] <xnox> /var/log/upstart/$job.log that is
[11:55] <xnox> cjwatson: Daviey: there is a new function called check_nfs_mount_version, which calls fork, and possibly spawns shells when executing /etc/mount.[net|nfs] et all
[11:55] <xnox> (not sure if additional spawning counts as forks/clones or not)
[11:55]  * xnox goes to read git log
[12:04] <Daviey> xnox: Providing it's documented, and as more log data seems to be going into upstart, it seems reasonable to JFDI...  I do wonder if upstart might be able to log job output to syslog.. jodh ? :)
[12:05] <xnox> Daviey: spamming syslog, is not inline with upstart's goals. although it does bring the question of syslogd pushing logs to remote machines....
[12:10] <Daviey> well, that is the intent i am thinking.. log aggregation is a big deal.
[12:22] <jodh> xnox: +1 on needing to understand the change.
[12:23] <jodh> Daviey: "console syslog" is on the wishlist somewhere (along with allowing syntax like "console log output").
[12:24] <Daviey> jodh: oh, super!
[12:34] <vibhav> pitti: ping
[12:36] <pitti> vibhav: hello
[12:37] <vibhav> pitti: Should I attach the debdiff for -8 at https://bugs.launchpad.net/ubuntu/+source/attr/+bug/1011639 or file a new merge request?
[12:37]  * vibhav thinks that we should have a requestmerge tool too
[12:38] <pitti> vibhav: no need to send debian diffs; just the diff between current debian and your merged package
[12:39] <vibhav> Didnt get you
[12:41] <pitti> vibhav: oh, you mean "debdiff against -8"?
[12:41] <vibhav> pitti: yup
[12:41] <pitti> that's what I meant
[12:41] <vibhav> pitti: I have attached it at #8
[12:47] <vibhav> bilal: ping
[13:16] <melodie_> hi
[13:18] <smoser> bah.
[13:19] <smoser> http://paste.ubuntu.com/1050861/
[13:19] <smoser> anyone able to help with: mixed non-coinstallable and coinstallable package instances present
[13:20] <smoser> that is the result of s/precise/quantal/ then apt-get dist-upgrade
[13:25] <cjwatson> infinity: ^- looks like another regression from new dpkg
[13:26] <vibhav> smoser: Probably a regression
[13:26] <cjwatson> maybe this is one of the database corruption instances that Guillem obliquely warned about
[13:26] <smoser> :)
[13:27] <smoser> any suggestions on how to un-foobar?
[13:27] <vibhav> Checking the soucre code of this error
[13:28] <vibhav> "Sanity checks: verify that the db is in a consistent state." was all that could be understood by me
[13:29] <cjwatson> smoser: before doing anything else, take a tarball of /var/lib/dpkg so that we can analyse it even if you (accidentally?) fix it
[13:29] <cjwatson> and post that somewhere
[13:30] <cjwatson> I believe the problem it's complaining about here is that you have >1 package of the same name installed (presumably different architectures), some of which are Multi-Arch: same and some of which are not
[13:31] <cjwatson> but we'll need that tarball to look into it properly
[13:33]  * cjwatson -> lunch
[13:33] <melodie_> could someone give me a little information ? In a remix I am doing the vc (tty) is qwerty instead of french azerty. I found the file /etc/kbd/config where I could set it up : does someone know the exact syntax which must be used in it ?
[13:34] <smoser> is there anything in /var/lib/dpkg that i should be weary of including ? ie, sensitive information?
[13:34] <xnox> If I want to push something into quantal-proposed, how do i make sure somebody else doesn't copy it into quantal until it's ready?
[13:34] <cjwatson> melodie_: No, you want /etc/default/console-setup instead
[13:34] <vibhav> didrocks: ping
[13:34] <cjwatson> melodie_: Er, sorry, /etc/default/keyboard nowadays
[13:34] <melodie_> hi cjwatson ! thank you. I look what it looks like
[13:35] <cjwatson> melodie_: say, XKBLAYOUT="us"  and  XKBVARIANT=""
[13:35] <cjwatson> smoser: I wouldn't expect so, no
[13:35] <melodie_> cjwatson: yes, I see it right in front of me ! great !
[13:35] <cjwatson> xnox: We don't have a good way to inhibit promotion yet; that's one of the several outstanding problems with using -proposed more seriously
[13:36] <melodie_> what is the syntax for variant, ie may I insert "latin-9" ?
[13:36] <xnox> cjwatson: ok. I will stick with a ppa then.
[13:36] <cjwatson> smoser: Unless you think your installed package list is sensitive
[13:37] <cjwatson> melodie_: The available layouts and variants are listed in /usr/share/X11/xkb/rules/xorg.lst
[13:37] <cjwatson> e.g.
[13:37] <cjwatson>   intl            us: English (US, international with dead keys)
[13:37] <melodie_> cjwatson: I look ! thanks a lot !
[13:37] <cjwatson> indicates that you can use XKBLAYOUT="us" and XKBVARIANT="intl" and that's what it means
[13:37] <smoser> hm.. well you might then find out that i have 'justin-bieber-fanclub' theme installed.
[13:37] <vibhav> melodie_: What are your exact intentions?
[13:38] <melodie_> I am doing a remix and I would like the vc to be fr instead of azerty in the live.
[13:38] <cjwatson> Or you could use 'sudo dpkg-reconfigure keyboard-configuration' to reconfigure that file interactively
[13:38] <melodie_> the first live I did has azerty in X but qwerty in tty's
[13:38] <cjwatson> Oh, that sounds like just a bug
[13:38] <cjwatson> They're supposed to always be in sync
[13:38] <vibhav> yup
[13:39] <melodie_> I can't file it, I would not know how to do that
[13:39] <cjwatson> Unfortunately probably something painfully arcane in console-setup
[13:39]  * vibhav wonders what package it could be
[13:39] <cjwatson> vibhav: As I just said, console-setup
[13:39] <melodie_> I have used a set of scripts having for name "ModCustom", which appears to work, whereas UCK failed without any clear clue in the build.log
[13:40] <melodie_> it failed several times in a row... :/
[13:40] <cjwatson> I bet running 'sudo setupcon' in a TTY switches TTY configuration to match X
[13:40] <cjwatson> But that would have to be done on each boot - a permanent fix requires figuring out how to fix the bug
[13:40] <melodie_> cjwatson: even in a chroot ?
[13:40] <cjwatson> chroot -> irrelevant
[13:41] <cjwatson> So this means that you can't actually select a different layout in VCs right now
[13:41] <melodie_> I am working in a chrooted console, because I am now modifying the content of the build directory
[13:41] <cjwatson> Because the very problem here is that the existing configuration is not being applied at boot
[13:41] <cjwatson> You can't fix this by messing around with configuration files
[13:41] <melodie_> cjwatson: this is why it's ok to edit files
[13:41] <cjwatson> It's not *useful* to edit files here
[13:41] <melodie_> ?
[13:41] <cjwatson> The configuration for your system almost certainly already says that the layout is azerty
[13:41] <smoser> cjwatson, bug 1015567, and /var/lib/dpkg.tar.gz  is in transit to launchpad (13M upload)
[13:42] <cjwatson> But it's not being applied correctly at boot
[13:42] <melodie_> cjwatson: no the files says "us"
[13:42] <melodie_> I mean
[13:42] <melodie_> this file
[13:42] <cjwatson> Oh, very odd that X has a French keymap then
[13:42] <melodie_> the one you said
[13:42] <cjwatson> It's supposed to pick that up from /etc/default/keyboard
[13:43] <cjwatson> So the default for French in /etc/default/keyboard is usually meant to be XKBLAYOUT="fr" and XKBVARIANT="oss"
[13:43] <cjwatson> I guess a naive remixing tool might have done something at some higher level
[13:45] <melodie_> cjwatson: did you mean naive or native ?
[13:45] <cjwatson> I meant naive
[13:45] <cjwatson> or naïve if you like
[13:46] <melodie_> I would like to say a very good point for this ModCustom set of scripts : easy to use and a great fantastic feature : it can resume a work which has been interrupted !
[13:47] <melodie_> it can even allow the person doing the remix job to reuse a work directory to add modifications. And this is fantastic !
[13:47] <melodie_> it spares quite some work.
[13:50] <melodie_> cjwatson: and thank you very much.
[13:50] <cjwatson> np, hope I wasn't too confusing
[13:51] <melodie_> really straightforward. :)
[13:51] <melodie_> one more for the road ! (hips ! :p ) : where are located the files where the changes on the Unity panel launcher are stored ?
[13:52] <melodie_> this is really bugging my curiosity, I didn't find any info on the web about it : is it related to gconf ? or else ?
[13:54] <stgraber> melodie_: IIRC it's a gsettings/dconf key
[13:54] <stgraber> melodie_: gsettings get com.canonical.Unity.Launcher favorites
[13:54] <melodie_> stgraber: ah ha ! I have looked into dconf and was not able to guess which section it is related to
[13:55] <melodie_> and gsettings has a set of commands I suppose ? Is there a documentation describing the use of this command tool ?
[13:57] <stgraber> man gsettings and calling gsettings without any argument will give you the help
[14:00] <stokachu> stgraber: team meeting today?
[14:02] <stgraber> stokachu: yep, mumble in ~30min, then IRC in an hour
[14:02] <stokachu> stgraber: cool thanks
[14:05] <seb128> ev, hey
[14:06] <ev> seb128: hi!
[14:06] <seb128> ev, some whoopsie questions for you ;-)
[14:06] <ev> sure :)
[14:06] <seb128> ev, 1- is there any ignore list in whoopsie? like a "those bugs are known, they are harmless, we should stop bothering users about them"
[14:07] <seb128> ev, I've a case of harmfless bug that is going to be hard to fix in precise, I would like users to stop getting "oops" dialogs about it, that ruins their user experience for no good reason
[14:08] <ev> seb128: could I have a concrete example? If this is a desktop application, then we always want to show those dialogs, as they tell the user why the window just disappeared on them.
[14:09] <seb128> ev, bug #858390
[14:09] <seb128> ev, basically dconf hitting a bug because mmap doesn't work reliably on ecryptfs,nfs and we don't support XDG_RUNTIME_DIR
[14:09] <seb128> ev, hum, good point
[14:10] <seb128> that takes nautilus down :-(
[14:10] <ev> yeah, nautilus is still going away by my reading of this
[14:10] <seb128> ev, right
[14:10] <ev> we need to convey why that happened, even if we can't fix it in precise
[14:10] <ev> (and that's incidentally one of the reasons why we're careful not to promise things getting fixed)
[14:10] <ev> or indeed giving them something they can follow
[14:10] <seb128> ev, ok, second question ... is there any way to figure if those users are using ecryptfs?
[14:10] <ev> seb128: once we get the metrics stuff operational, yes
[14:11] <seb128> ev, any eta on that?
[14:11] <ev> we'll be able to query against both data sets
[14:11] <ev> it's scheduled for 12.10, but it may slip
[14:11] <ev> definitely by 13.04
[14:11] <seb128> ev, ok, thanks for the answers ;-)
[14:11] <ev> sure thing!
[14:11] <seb128> that was all for today (I think)
[14:11] <ev> :D
[14:11] <ev> you're always welcome to ask more
[14:14] <seb128> ev, ;-)
[14:28] <pitti> seb128, ev: NB that apport already tags bugs for users who use ecryptfs with "EcryptfsInUse=yes"
[14:28] <pitti> by way of /usr/share/apport/general-hooks/generic.py
[14:28] <ev> nice
[14:30] <melodie_> have to reboot, thanks and bye !
[14:32] <smoser> cjwatson, is there anything else you'd like in that bug report? i seemed to have gotten by the dpkg error by removing the entry for that package from /var/lib/dpkg/status at least for the moment.
[14:32] <cjwatson> smoser: maybe whatever dpkg logs mention that package
[14:32] <cjwatson> (I'm just triaging it though, hoping to not have to actually end up fixing it)
[14:33] <seb128> pitti, is that reliable? does it show on errors.ubuntu.com as well (I guess it does, the detailed reports seem to be dumps of the apport files)
[14:33] <pitti> seb128: it works for me, anyway
[14:33] <pitti> seb128: it's what kirkland advised back then
[14:33] <seb128> pitti, half of those bugs don't have it, but they could be using nfs and I don't think apport flag NfsInUse?
[14:34] <pitti> seb128: we don't detect that, right; if you have a recipe for this, we can
[14:35] <seb128> pitti, I will think about it, thanks ;-)
[15:04] <mdeslaur> ugh, we're going to install the nvidia proprietary drivers by default?? I have a security support issue with that...
[15:05] <mdeslaur> oh, with an option in ubiquity...ok, that's better
[15:06] <dholbach> apw, nice blog post
[15:06] <dholbach> apw, borrowed your last paragraph for the ubuntudev FB and G+ page :)
[15:06] <apw> dholbach, :)
[15:07] <jdstrand> mdeslaur: security support issue? Canonical supports restricted already-- or am I missing something?
[15:08] <mdeslaur> jdstrand: we can't fix security issues in the binary driver, I thought it was going to get installed for everyone by default
[15:08] <mdeslaur> jdstrand: but I guess an optional checkbox during install is ok
[15:09] <jdstrand> mdeslaur: no *we* can't, but we are supposed to talk with upstream about those sorts of things. I agree that not by default is preferred generally speaking, but I imagine at some point that will slip to checked by default...
[15:10] <mdeslaur> jdstrand: upstream only supports their current driver, which may not work on older cards...
[15:11] <mdeslaur> jdstrand: when we push an update, we'll most certainly break people...using the open source driver as default for a majority of users is the better choice
[15:16] <jdstrand> mdeslaur: I don't disagree-- I was merely being a pessimist :)
[15:17] <jdstrand> you know, it's the security way ;)
[15:18] <mdeslaur> hehe
[15:18] <kees> any progress on making /dev/nvidia* not world-writable?
[15:19] <mdeslaur> kees: not yet, no
[15:21] <mdeslaur> kees: I've just assigned myself to that bug (LP: #979307)
[15:22] <tedg> pitti, Is there a place where I can just download the DB/config for status.ubuntu.com ?  (want to test a patch)
[15:23] <pitti> tedg: yes, http://status.ubuntu.com/ubuntu-quantal/ubuntu-quantal.db
[15:23] <pitti> likewise for precise
[15:23] <pitti> tedg: the config is in lp:~wi-tracker-configurators/launchpad-work-items-tracker/ubuntu-config
[15:24] <tedg> pitti, Cool, thanks!
[16:25] <rtg> hallyn, does it make sense for qemu-kvm to be 'Architecture: any' ? The description implies that its for x86 only.
[16:26] <hallyn> rtg: at least powerpc is supposed to support kvm, and eventually arm too.  historically we've compiled it without acceleration for those, but built it
[16:27] <hallyn> i'm hoping to get it built with acceleration for powerpc, but haven't yet
[16:27] <rtg> hallyn, well, its failing on all of those arches.
[16:27] <hallyn> rtg: yes, i'm working on it
[16:27] <rtg> hallyn, ack
[16:27] <xnox> ev: googletest might not work for C at all. It's for C++ =( http://stackoverflow.com/questions/7668510/can-we-use-googletest-gtest-to-test-c-code
[16:27] <hallyn> rtg: i'd happily not build for those arches, but was afraid someone would miss them
[16:28] <rtg> hallyn, they're gonna miss 'em anyways if they don't build :)
[16:29] <ev> xnox: http://code.google.com/p/test-dept/wiki/TestDept looks interesting
[16:30] <hallyn> SpamapS: the cgroups-mount and cgroups-umount should be moved from /usr/bin to /bin.  Any objections to SRUing that?
[16:30] <hallyn> (this is to support systems with separate /usr)
[16:31] <xnox> ev: hmmm... after you do the ground work, I'd be happy to pick up =)
[16:31] <ev> xnox: :)
[16:31] <xnox> ev: btw what does upstart use for it's intensive test-suite? anything in / for C ?
[16:32] <ev> xnox: libnih has testing functions, if I remember correctly
[16:32] <xnox> ev: pre-arranged. hmm.
[16:32] <ev> but nothing that does function replacement ( jodh do correct me if I'm wrong)
[16:32] <SpamapS> hallyn: can we keep a compat symlink in /usr/bin ?
[16:32] <SpamapS> hallyn: I worry about people who have automated with full path
[16:32] <cjwatson> upstart adopts a coding style where testing it doesn't really need a lot of function replacement, I think
[16:33] <cjwatson> if I were in the mood for an argument I would say that needing function replacement is a sign that your code is structured wrongly :-)
[16:35] <hallyn> SpamapS: those scripts are only (meant to be) used by the upstart jobs...
[16:36] <hallyn> but i can do symlinks :)
[16:36] <SpamapS> hallyn: your call.. if you think people wouldn't have hard coded them, then a move is fine.
[16:36] <SpamapS> hallyn: but I'd feel better, and I don't see a problem with it, if there were symlinks
[16:37] <hallyn> SpamapS: great, thanks.
[16:42] <stokachu> xnox: o/
[16:42] <xnox> stokachu: \o
[16:42] <xnox> high-five ;-)
[16:42] <stokachu> lol
[16:43] <stokachu> so re: apt, does it actually apply patches in lucid building somehow?
[16:43] <xnox> stokachu: nope
[16:43] <cjwatson> it's a native package, they don't usually use patch systems
[16:43] <stokachu> ah ok.. so just update the code and commit then build again?
[16:44] <cjwatson> yes
[16:44] <stokachu> sounds good! thanks
[16:44]  * xnox feels information overload after the meeting
[16:44] <stokachu> xnox: org-mode is my savior
[16:45] <ev> cjwatson: generally I would agree, but I'd like to test the point where things intersect. And I can see no way to structure code to make those easy to test, short of passing in a struct of function pointers
[16:45] <xnox> stokachu: yeah, doesn't work that well for me. I don't embrase GTD, so don't set deadlines, and it just piles up with cruft.
[16:45] <xnox> plus my org-mode is mostly spammed with personal stuff. Need to better configure work/non-work items
[16:45] <stokachu> xnox: lol, sounds like how i handle things i dont understand.. "get rid of it"
[16:46] <bdmurray> infinity: you'd said link to the build pages with sru-sccept?  https://bugs.launchpad.net/ubuntu/+source/cron/+bug/794082/comments/7
[16:47]  * xnox still want's to browse through all the bugs stokachu linked at during the meeting. at least to see if anything interesting tickles my fance
[16:47] <stokachu> xnox: there are a couple ugly multi-arch ones, but the rest is just administrative stuff
[16:47] <xnox> hmmm, ok.
[16:47] <stokachu> getting sru's written and formatted patches
[16:48] <xnox> stokachu:  did you know that there is 5.0.4-3.1ubuntu5.2 autofs sitting in Lucid's SRU queue for 301 days now
[16:48] <xnox> stokachu: can you validate it?
[16:48] <xnox> stokachu bug #578536
[16:49] <stokachu> xnox: so we need to invalidate that sru
[16:50] <xnox> stokachu: why?
[16:50] <stokachu> xnox: the patch i sent to be tested overwrites that one
[16:50] <stokachu> that was done before i even touched the case
[16:50] <stokachu> also re: #23 doesn't look like it fixed it
[16:50] <xnox> stokachu: ah, so superseed with 5.3 then
[16:50] <stokachu> yea
[16:50] <xnox> .*ubuntu5.3 that is =))))
[16:51] <stokachu> what autofs version is in oneiric
[16:51] <stokachu> 5.0.5?
[16:57] <xnox> stokachu: rmadison is your friend
[16:57] <xnox> http://paste.ubuntu.com/1051200/
[16:58] <stokachu> nice.. what is rmadison :X
[16:58] <xnox> rmadison $package
[16:59] <xnox> stokachu: in ubuntu it would be probably called: distro-series-version-checker
[16:59] <stokachu> xnox: nice
[16:59] <stokachu> i wouldve never guess rmadison
[16:59] <xnox> stokachu: it's Remote query tool of MADISON....
[17:00] <xnox> stokachu: it's a script from debian, all archive scripts in debian are named after human names.
[17:00] <stokachu> gotcha
[17:00] <xnox> e.g. britney, madison, ana, a few others
[17:01] <xnox> there is bob as well
[17:02] <stokachu> never forget about bob
[17:05] <cjwatson> madison is 'dak ls' in Debian now, but the name stuck
[17:07] <xnox> cjwatson: and rmadison needs to be added to the 'geek names for your child'
[17:07] <xnox> book
[17:13] <infinity> bdmurray: Oh, indeed, there's a chicken and egg issue with actually linking to builds before they've been completed. ;)
[17:13] <infinity> bdmurray: Or, rather, before they've been created.
[17:13] <infinity> bdmurray: But linking to the versioned source page (as you've done there) seems reasonable.
[17:14] <bdmurray> infinity: well plus I wouldn't want to link to every arch's build
[17:15] <infinity> Ahh, I see USNs have switched to just linking to the source version too.
[17:15] <infinity> bdmurray: So, my only complaint would be the wall-o-text.  Could perhaps be formatted a bit nicer.
[17:16] <bdmurray> infinity: okay, thanks
[17:20] <zul> i sent an email to the tech board can someone unmoderate it please? thanks
[17:22] <cjwatson> zul: done
[17:23] <zul> cjwatson: thanks
[17:35] <rtg> --:1
[17:39] <jtaylor> doko: do we really need that diff: https://launchpad.net/ubuntu/+archive/primary/+files/mpich2_1.4.1-1build1_1.4.1-1ubuntu1.diff.gz
[17:39] <jtaylor> blcr is broken since natty anyway
[18:30] <dupondje> any idea when new kernel will be accepted from queue ?
[18:30] <dupondje> want to upgrade :)
[18:47] <dupondje> lamont: any chance on new bind9 in debian ?
[19:07] <dupondje> mdeslaur: can you patch bind9 in quantal ? :)
[19:08] <mdeslaur> dupondje: lamont is supposed to update to a newer version soon
[19:08] <mdeslaur> lamont: any ETA?
[19:09] <dupondje> aha ok, cause now precise -> quantal is a downgrade
[19:10] <mdeslaur> dupondje: yes, but it's synced from debian...I don't want to introduce a delta if lamont's going to upload a new version soon
[19:10] <dupondje> yea sure :)
[19:10] <dupondje> delta shouldn't be a problem imo, if its simple, it can be synced again
[19:14] <seb128> dupondje, downgrades are not possible, soyuz wouldn't accept a lower version
[19:14] <seb128> nor would apt downgrade you
[19:15] <dupondje> seb128: apt will not downgrade indeed :)
[19:15] <dupondje> but current bind9 version in quantal is lower then in precise
[19:16] <Laney> isn't it usual for those kind of security uploads to be copied up to the dev release?
[19:16] <Laney> or uploaded
[19:17] <mdeslaur> Laney: we have a procedure...we either merge from debian, or submit the patch to debian and merge, and if we think it'll take a long time, we will upload to the dev release
[19:17] <mdeslaur> In this case, lamont, the debian bind9 maintainer said a new upload was imminent
[19:17] <Laney> mdeslaur: ok
[19:17] <dupondje> so we just need to pull lamont's ears ;)
[19:18] <mdeslaur> as it's not happened yet, I'll upload to quantal in a few minutes
[19:19] <Laney> is there a report which tracks packages in this state?
[19:20] <dupondje> there is another one: https://launchpad.net/ubuntu/+source/xen
[19:21] <dupondje> ^^ smb` ?
[19:22] <mdeslaur> well, for security updates, our tracker lists quantal as not being fixed...but we don't specifically have a report to indicate if a package in the dev release is older than the stable release
[19:22] <mdeslaur> unless someone else does
[19:22] <Laney> well, that one's only 2 days
[19:22] <dupondje> mmm yea :)
[19:22] <dupondje> anyone knows the status on kmod ?
[19:23] <geser> there is a merge of our current delta needed, don't remember who had it on his TODO list
[19:24] <dupondje> geser: for kmod ?
[19:24] <geser> dupondje: yes as it replaces the current tools which has ubuntu delta
[19:24] <dupondje> hmz ok, cause https://launchpad.net/ubuntu/+source/kmod hasn't been in ubuntu yet
[19:25] <dupondje> which makes oss-compat uninstallable from the start ...
[19:25] <geser> it can't be synced as it replaces module-init-tools which has changes which need to be checked and applied to kmod too
[19:27] <lamont> dupondje: trying to figure where to put bind9 (and nmap, tbf) into my schedule this week.  It may turn out to be saturday.  I'm hoping that it's tomorrow night
[19:27] <lamont> mdeslaur: ^^
[19:28] <mdeslaur> lamont: ok, cool...thanks...I'll wait then
[19:28] <geser> dupondje: slangasek wanted to look at kmod
[19:30] <dupondje> geser: ok :) lets remind slangasek then ;
[19:33] <dupondje> also kernel is uninstallable atm, but guess somebody will accepted it from the queue I guess :)
[19:34] <bambee> http://paste.ubuntu.com/1051451/  <--- circular dependency on itself ?
[19:34] <bambee> (on quantal)
[19:35] <dupondje> hallyn: update-rc.d: warning: /etc/init.d/qemu-kvm missing LSB information
[19:35] <dupondje> fyi :)
[19:36] <geser> bambee: where? note the missing -dev in the package name in line 12
[19:36] <bambee> woo good catch
[19:36]  * bambee is tired v_v
[19:42] <slangasek> dupondje: cryptsetup sync> wow, interesting
[19:43] <slangasek> I wonder if the cryptsetup upstart jobs work in Debian
[19:46] <mdeslaur> dupondje: bind9 uploaded to quantal, FYI
[19:49] <bambee> additional informations: http://paste.ubuntu.com/1051474/
[19:54] <geser> bambee: any specific reason why you don't try the multi-arch package? "sudo apt-get install libc6:amd64" (note the : instead the -)
[19:56] <hallyn> dupondje: weird.  that should be autogenerated as an upstart wrapper
[19:56] <hallyn> thanks
[19:56] <dupondje> slangasek: yea sync is good, all ubuntu changes are in the debian package :d
[19:56] <dupondje> hallyn: just noted it on upgrade so :D
[19:56] <dupondje> mdeslaur: thx
[19:56] <dupondje> slangasek: you'll check kmod ?
[19:59] <slangasek> dupondje: yes, though not today
[20:02] <dupondje> great! :)
[20:07] <arges> cyphermox, hello. looking at pad.lv/872824. would it make sense to at least try to get a proper PPA going and do some tests? or what do you think would be a good approach?
[20:08] <cyphermox> arges: way ahead of you, package is almost ready
[20:08] <arges> cyphermox, oh awesome
[20:08] <arges> cyphermox, : )
[20:09] <cyphermox> ppa:mathieu-tl/nm
[20:09] <dupondje> Do we have bumblebee or something as default now in Quantal ? or
[20:10] <cyphermox> arges: so I just uploaded a package for precise
[20:13] <arges> cyphermox, in -proposed?
[20:14] <cyphermox> arges: ah, sorry, no, I mean in my PPA: ppa:mathieu-tl/nm
[20:14] <arges> cyphermox, ok cool.. i'll make sure that gets tested
[20:14] <cyphermox> thanks
[20:15] <arges> : )
[20:19] <kees> SpamapS: zul says "Clint Byrum is on the SRU team and he can vouch for these packages." :) you feel Nova, Glance, Horizon, and Keystone are in good shape?
[20:21] <SpamapS> kees: I think upstream's processes are far more capable of stopping regressions than our SRU process...
[20:21] <SpamapS> kees: I won't speak to how bug-free the software is.. but I don't think it will regress on micro releases
[20:22] <kees> SpamapS: okay, thakns
[20:22] <zul> kees: i think we are in the position to spot regressions before uploading to -proposed with our testing that we do as well
[20:22]  * kees nods
[20:23] <kees> seems like it's in a good shape overall. I've emailed to that effect. I'd like to hear from at least 1 other TB member before making it official.
[20:26] <SpamapS> kees: any need for me to email?
[20:26] <stgraber> cjwatson: can you moderate my message to ubuntu-devel-announce (DMB meeting minutes)?
[20:43] <micahg> slangasek: cjwatson: stokachu: re bug bug 977940, sorry, I snagged it for sponsoring, but it got lost in my stack, if it's urgent, feel free to resteal, otherwise, I'll try to get to it when I finish my pilot sponsoring this time around
[20:56] <kees> SpamapS: nah, thanks.
[21:29] <cjwatson> stgraber: done
[21:32] <dupondje> Do we have something to support Optimus now in Quantal ?
[21:32] <stgraber> cjwatson: thanks
[21:38] <infinity> TheMuso: Do you plan to bring the linux-lowlatecy package in quantal into the present?
[21:41]  * micahg wonders what happened with the kernel team adopting that as a flavor
[21:45] <Caesar> Hi, I'd like to get a newer version of audit into quantal, and getting it into Debian first isn't looking doable with the imminent freeze and a library transition being needed
[21:46] <Caesar> How are library transitions handled in Ubuntu?
[21:46] <Caesar> (audit is in universe fwiw)
[21:48] <geser> now large is the transition?
[21:48]  * micahg was going to suggest speaking to the Debian release team as it seems to only have 2 rdeps (at least in UBuntu)
[21:48] <ajmitch> reverse-depends on libaudit0 looks pretty small
[21:59] <micahg> slangasek: why not just use lsb_release and a .in file in devscripts to autogenerate the release it's on?
[22:12] <TheMuso> infinity: I thought there were plans to possibly integrate lowlatency into the main kernel package, depending on whether the kernel guys could get rid of other kernels. But since that doesn't appear to be happening yet, yes I'll attend to it in the coming days.
[22:13] <infinity> TheMuso: It was still an "in discussion" deal, I believe.  I think we all expected the -lowlatency source to continue to be maintained up until that discussion reached fruition. :)
[22:13] <infinity> TheMuso: But hey, you successfully skipped the entire 3.4.x cycle, and get to jump from 3.2 to 3.5!
[22:14] <TheMuso> Right
[22:14] <TheMuso> I really need to get the studio guys to take t over.
[22:14] <infinity> Yeah.
[22:15] <infinity> Given what it is, it should be trivial for them to merge against master every ABI bump.
[22:15] <infinity> (Yeah, easier still if it can be integrated, but that requires changing the patch to be a config option, config review, etc, etc)
[22:22] <Bluefoxicy> are /var/spool/cron crontabs run by default?
[22:22] <Bluefoxicy> 0 * * * * root fstrim /
[22:22] <Bluefoxicy> 0 * * * * root fstrim /home/_vm/
[22:23] <Bluefoxicy> I have this in /var/spool/cron/crontabs/root, but I just manually ran those commands (it's been in there for months) and a LOT got discarded.  Not a lot of activity really goes on on /home/_vm/
[22:23] <Bluefoxicy> I can only surmise that this wasn't run at midnight last night (there aren't actually any VMs running atm, so there's no activity on that partition)
[22:24] <Bluefoxicy> trying to figure out if this is normal behavior (on Precise) or a bug
[22:29] <slangasek> micahg: <shrug> no objection if you want to write it; I was just restoring the previous code
[22:33] <cjwatson> dobey: Please to be evicting python-support from ubuntuone-control-panel again?  We don't want it in main.
[22:35] <Bluefoxicy> oh I'm stupid nm.
[22:35] <Bluefoxicy> i don't need the username, so it thinks 'root' is a command.
[22:35] <Bluefoxicy> the bug is me :|