[00:00] mind you, I don't see what's *caused* that broken symlink... but I don't see anything multiarch-related here [00:01] Yeah, it’s only multiarch-related in that it causes multiply-installed multiarch packages to fail to reinstall. [00:02] andersk: that's a mis-migration in the fuse-utils binary package [00:02] $ dpkg -c /mirror/ubuntu/pool/main/f/fuse/fuse-utils_2.9.0-1ubuntu2_all.deb |grep changelog [00:02] lrwxrwxrwx root/root 0 2012-06-11 09:18 ./usr/share/doc/fuse-utils/changelog.Debian.gz -> ../libfuse2/changelog.Debian.gz [00:02] yet /usr/share/doc/fuse-utils is itself a symlink to libfuse2 [00:04] /usr/share/doc/ure/changelog.Debian.gz is the other example I see. [00:21] What is the reason some packages are more recent in Precise then in Qunatal? For example bind9 [00:24] dupondje: Because people have been naughty, it seems. [00:25] Or because we expect a new version in quantal real-soon-now. [00:25] no newer version in debian neither [00:26] so I doubt there is a new version comming real soon :) [00:29] Hm. What bug was the SRU associated with? [00:41] RAOF: was due to http://www.ubuntu.com/usn/usn-1462-1/ [00:41] but can't find bug directly :s [01:25] is it known that dpkg update is spitting out a 403 forbidden error [01:26] yes [01:26] http://identi.ca/notice/94752326 [01:26] There's a good reason for that, too. [01:30] thanks [03:08] @pilot out === udevbot changed the topic of #ubuntu-devel to: Archive: open | Dev' of Ubuntu (not support or app devel) | build failures -> http://bit.ly/HaWdtw | #ubuntu for support and general discussion for hardy -> precise | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: pitti [03:36] jbicha: you took away infinity's beer: http://people.canonical.com/~ubuntu-archive/testing/quantal_probs.html [03:44] Good morning [03:53] micahg: I think evolution is ok now, evolution-exchange can just be synced from Debian later today [03:55] jbicha: yeah, I was referring to evolution-exchange :) [03:57] infinity: i386 and powerpc are tied now (including depwaits) :) [04:07] why is there a small thin line just under the titlebar when i move windows around? [04:08] 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] cjwatson, ev: OOI, what does the "@" do in d/t/control's Depends: line? [04:22] micahg: My poor beer. :( [04:22] micahg: On a more positive note, if the test build ever finishes, I suspect I have mono/armel licked. [04:23] micahg: With that, dpkg, and debhelper, I intend to do a mass-give-back and see what sticks. [04:23] infinity: yeah, armel takes the cake for failures [04:23] micahg: It's mostly just fallout from mono and ghc. [04:24] micahg: I have the ghc fix in the wings, just need to jam the rebootstrap in sideways. [04:24] cool [04:32] 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] pitti: Then you didn't have multi-arch:same packages installed when you upgraded to -3ubuntu1 [04:35] Or, rather, not ones with triggers. [04:35] So, desktop ones like libgtk. [04:36] $ dpkg -l *:i386 | wc -l [04:36] 78 [04:36] not GTK, though [04:36] Yeah. Was an issue specifically with packages with triggers. [04:37] Hence why I didn't catch it pre-upload. Didn't test on a fully-loaded m-a/desktop mess. [04:37] Oh well. [04:37] Sort of "fixed" now in the most recent version, but we need to revisit it later with different shaped hammers. [04:40] 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] good morning :-) [04:48] [B/c === vibhav is now known as Guest81049 [04:49] larsduesing: is it an Ubuntu specific package? [04:54] no [04:55] cyrus-sasl... [04:55] :) [04:56] https://bugzilla.cyrusimap.org/show_bug.cgi?id=3219 [04:56] bugzilla.cyrusimap.org bug 3219 in plugins "sql canonuser plugin" [Enhancement,New] [04:56] (oh, cool... ubottu is really smart :) ) [04:58] 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] good idea.. [05:00] thanks === chu_ is now known as chu [05:04] Ooo, my mono/armel passed the point where it failed on the buildds... [05:04] Exciting times. [05:05] Now, do I upload it and pray it doesn't fail later, or wait? [05:11] micahg: omg... there are _bugs_ in debian-bts (I would identify as security-ones...) from 2008 not patched in sasl... [05:12] so talks from debian to cmu aren't much better either... [05:12] 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] larsduesing: I still suggest speaking with them as upstream seems active enough (average one release per year) [05:13] yes [05:14] there are current git commits (last 10days ago) [05:18] 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] I must confirm if there is still a bug... working on it [06:04] 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] jibel: ^ FYI [06:05] pitti, I filed bug 1015400 [06:05] Launchpad bug 1015400 in ubiquity (Ubuntu Quantal) "update depends to python3-mock in autopkgtest control file" [Undecided,New] https://launchpad.net/bugs/1015400 [06:06] jibel: ah, thanks; following up there [06:08] jibel: followed up with some details; I guess that broke with --no-built-binaries [06:10] pitti, I think so. without this option build-deps are installed and python3-mock is listed there. [06:10] right [06:10] but it should still build ubiquity in this case === tkamppeter_ is now known as tkamppeter === zyga-afk is now known as zyga [07:17] good morning === smb` is now known as smb [07:59] 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] pitti: I'll fix that ubiquity control file bug, thanks. [08:00] https://wiki.ubuntu.com/ARM/OmapNetbook and http://testcases.qa.ubuntu.com/Install/ARM/PreinstalledImage don't give additional info either [08:01] 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] 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] cjwatson: right, that's why I left the ubiquity task open [08:02] pitti: @ means "all the binaries built by this source", per the spec [08:02] cjwatson: but nevertheless in that case it ought to have been built [08:02] (even if it's not necessary; I don't know if it is) [08:02] Yeah [08:02] It is [08:02] cjwatson: @> thanks [08:27] 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] ogasawara: but I don't see anything at all on hdmi and the serial port [08:28] err, ogra_ ^ [08:28] ogasawara: ignore me [08:28] pitti, just use netinst, there are SD images [08:29] ogra_: uboot is the thing that talks to the serial port, isn't it? [08:29] that gives you a normal alternate install [08:29] well, MLO (first stage bootloader) initialize the serial port, then it loads uboot-bin [08:29] I had expected this to run from some internal flash; but it seems not even that is there [08:29] nope, to costly [08:30] I also followed http://www.omappedia.org/wiki/Ubuntu_Pre-built_Binaries_Guide, but no luck [08:30] if you find something internal nowadays, its an eMMC [08:30] all documentation I can find is for sd cards [08:30] 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] 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] the server images do everything on serial though ... [08:32] so if you got display probs, start with a server image [08:32] if you want to do a real alternate install use the netboot images [08:32] that enables you also to have / on USB [08:33] (which is tons faster than SD, but you need the SD card as "bootfloppy" still) [08:33] ogra_: http://ports.ubuntu.com/dists/quantal/main/installer-armel/current/images/ -> no omap4? [08:33] http://ports.ubuntu.com/dists/quantal/main/installer-armhf/current/images/omap4/netboot/boot.img-serial.gz [08:34] nevermind, armhf [08:34] right, armel is semi dead [08:39] ogra_: thanks; with that image I at least see d-i in minicom [08:39] still no hdmi, though [08:39] 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] try the dvi port instead [08:40] would that be boot.img-fb.gz ? [08:40] or sohudl it also work with -serial? [08:40] 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] the fb image defaults to framebuffer output, yep [08:41] ogra_: ok, when I use the dvi connector (not hdmi), the monitor recognizes the hdmi input; fun [08:41] ok, trying quantal [08:41] err, precise === yofel_ is now known as yofel [08:43] let me know if you get DVI working [08:43] we talked about this a bit yesterday, seems nobody did [08:43] well, try with a precise kernel then [08:44] I was trying the precise desktop image [08:44] hmm, that should be flawless unless you have a weird monitor that reports wrong EDID data [08:44] maybe I did something wrong [08:45] there is not much you can do wrong with the preinstalled images [08:45] as long as your power supply is powerful enough andd your monitor isnt reporting insane things you should be fine [08:46] like I connected to the wrong HDMI port or something [08:46] if your monitor *does* report insane things though, you can boot with it unplugged [08:46] and plug it in after boot, that will give you at least 800x600 (fallback mode) [08:47] cheers, i'll try it later [08:48] ogra_: thanks for the hand holding! precise's -fb image works fine [08:48] yay, good [08:48] ogra_: so I guess I'll buy a large SD card on Saturday and try again next week [08:48] k [08:49] 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] ogra_: that seems like what I want anyway; except that I'll still need the SD card for the initial boot? [08:56] no, for all boots [08:56] it will become your "bootfloppy" since there is no flash and no way to boot off a USB disk directly [08:57] ogra_: but that will boot from the USB stick, when it's plugged in? [08:57] (I mean the uboot part on the SD) [08:58] and if the USB stick doesn't have anything or is not present, continue to boot from the SD? [08:58] right, but you need both, SD card and USB disk/card [08:58] yes, understood (that's what I meant with "initial" boot, the uboot part) [08:58] no, it wont boot off the Sd anymore after install [08:58] so I guess I can use one of my 1 GB SDs for booting [08:58] and just need the large one for the install [08:58] (new cmdline etc, no casper initrd anymore) [08:59] right [08:59] you can just dd the size of the first partition from one SD to another [09:57] cjwatson: ubiquity failed again, FYI; now needing python3-six :/ [09:58] pitti: Yes, that's the autopkgtest bug, I think [09:59] pitti: ubiquity already depends on python3-six, so this shouldn't be needed in debian/tests/control [09:59] ah, so that's not actually the bug I meant [09:59] Oh [09:59] I meant that it does not attempt to build the package although it should [09:59] Wouldn't it be fixed by building and installing the binaries? [09:59] so you mean that it does not actually install the @ Depends:? [09:59] Apparently not [10:00] But perhaps that's simply because it didn't build them [10:00] It wouldn't surprise me to find that that was just a consequence [10:00] that would certainly hide the other bug, yes [10:01] but even if it installed ubiquity's build dependencies it would just mean it would test ubiquity from the built tree [10:01] instead of the system-installed bits from the ubiquity package [10:01] it should install the latter and test that, not the build tree [10:01] No, I mean that @ is "all the stuff I just built" [10:01] which is what the @ Depends: is supposed to do [10:01] And if it didn't build anything it would be null [10:02] oh, you mean it computes @ from teh list of built .debs, not from debian/control? [10:02] Which would have the effect of transitively losing python3-six [10:02] I'm not sure; it seems plausible though [10:02] that's again wrong, it needs to look at debian/control [10:02] as we have a lot of packages with no-build-needed [10:02] (as we just need the test suite from the source, nothing else) [10:04] jibel: ^ perhaps we should drop --no-built-binaries for now until these bugs are sorted out [10:05] pitti, sure, I'll revert the change. [10:07] I made a note in bug 1015400 to investigate that other bug, too [10:07] Launchpad bug 1015400 in autopkgtest (Ubuntu Quantal) "does not build packages which do not declare "no-build-needed"" [High,In progress] https://launchpad.net/bugs/1015400 [10:12] GDBus GI bindings or python-dbus for new code? [10:16] ev: if you want to export DBus objects, python-dbus [10:16] ev: if you only want to call services, it doesn't matter much [10:16] I do indeed [10:16] thanks, I hadn't realized GDBus was missing that in what it exposed over GI [10:17] gnome bug 656325 FYI [10:17] Gnome bug 656325 in gdbus "Make GDBusInterfaceVTable binding friendly" [Normal,Assigned] http://bugzilla.gnome.org/show_bug.cgi?id=656325 [10:17] 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] pitti: subscribed. Thanks [10:51] 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 [10:51] Launchpad bug 1013583 in Launchpad itself "contents-generation could be 2x faster by not regenerating Packages/Sources" [Low,Triaged] [11:26] cjwatson: I don't think so, but adding it shouldn't be too hard, something like APT::FtpArchive::ContentsOnly could be added I presume === MacSlow is now known as MacSlow|lunch [11:30] cjwatson: http://paste.ubuntu.com/1050714/ <- somehting like this maybe? [11:30] 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] 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] but this means that automount messages no longer appear in syslog [11:31] i'm thinking to add descriptive changelog & NEWS entry w.r.t to this change [11:32] or is this issue serious enough to hunt down where/why autofs has changed its work behaviour [11:33] Daviey: slangasek: jodh: cjwatson: ^^^^^ [11:35] 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] cjwatson: yes, I think that could be done [11:36] An hour of cocoplum time isn't to be sniffed at [11:36] Actually 1.5 hours [11:36] xnox: I think it's at least worth understanding what the extra forks are, to start with [11:37] cjwatson: ok. let me digg a bit further. [11:41] it's clones, not forks, but still... [11:42] Meh, much the same thing [11:50] 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] xnox: i haven't checked, but i guess there is no --foreground --log= , similar option? [11:52] Daviey: /var/log/syslog -> /var/log/upstart/autofs.log for automount messages [11:52] Daviey: upstart by default now attaches console, e.g. stdout/stderr and flushes them into /var/log/upstart/$job.log [11:52] for free [11:53] 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] /var/log/upstart/$job.log that is [11:55] 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] (not sure if additional spawning counts as forks/clones or not) [11:55] * xnox goes to read git log [12:04] 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] 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] well, that is the intent i am thinking.. log aggregation is a big deal. === Guest81049 is now known as vibhav === G is now known as Nigel [12:22] xnox: +1 on needing to understand the change. [12:23] Daviey: "console syslog" is on the wishlist somewhere (along with allowing syntax like "console log output"). [12:24] jodh: oh, super! [12:34] pitti: ping [12:36] vibhav: hello [12:37] 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] Launchpad bug 1011639 in attr (Ubuntu) "Please merge attr 1:2.4.46-8 (main) from Debian Unstable (main)" [Wishlist,Fix released] [12:37] * vibhav thinks that we should have a requestmerge tool too [12:38] vibhav: no need to send debian diffs; just the diff between current debian and your merged package [12:39] Didnt get you [12:41] vibhav: oh, you mean "debdiff against -8"? [12:41] pitti: yup [12:41] that's what I meant [12:41] pitti: I have attached it at #8 [12:47] bilal: ping === _salem is now known as salem_ === MacSlow|lunch is now known as MacSlow === doko_ is now known as doko [13:16] hi [13:18] bah. [13:19] http://paste.ubuntu.com/1050861/ [13:19] anyone able to help with: mixed non-coinstallable and coinstallable package instances present [13:20] that is the result of s/precise/quantal/ then apt-get dist-upgrade [13:25] infinity: ^- looks like another regression from new dpkg [13:26] smoser: Probably a regression [13:26] maybe this is one of the database corruption instances that Guillem obliquely warned about [13:26] :) [13:27] any suggestions on how to un-foobar? [13:27] Checking the soucre code of this error [13:28] "Sanity checks: verify that the db is in a consistent state." was all that could be understood by me [13:29] 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] and post that somewhere [13:30] 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] but we'll need that tarball to look into it properly [13:33] * cjwatson -> lunch [13:33] 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] is there anything in /var/lib/dpkg that i should be weary of including ? ie, sensitive information? [13:34] 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] melodie_: No, you want /etc/default/console-setup instead [13:34] didrocks: ping [13:34] melodie_: Er, sorry, /etc/default/keyboard nowadays [13:34] hi cjwatson ! thank you. I look what it looks like [13:35] melodie_: say, XKBLAYOUT="us" and XKBVARIANT="" [13:35] smoser: I wouldn't expect so, no [13:35] cjwatson: yes, I see it right in front of me ! great ! [13:35] 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] what is the syntax for variant, ie may I insert "latin-9" ? [13:36] cjwatson: ok. I will stick with a ppa then. [13:36] smoser: Unless you think your installed package list is sensitive [13:37] melodie_: The available layouts and variants are listed in /usr/share/X11/xkb/rules/xorg.lst [13:37] e.g. [13:37] intl us: English (US, international with dead keys) [13:37] cjwatson: I look ! thanks a lot ! [13:37] indicates that you can use XKBLAYOUT="us" and XKBVARIANT="intl" and that's what it means [13:37] hm.. well you might then find out that i have 'justin-bieber-fanclub' theme installed. [13:37] melodie_: What are your exact intentions? [13:38] I am doing a remix and I would like the vc to be fr instead of azerty in the live. [13:38] Or you could use 'sudo dpkg-reconfigure keyboard-configuration' to reconfigure that file interactively [13:38] the first live I did has azerty in X but qwerty in tty's [13:38] Oh, that sounds like just a bug [13:38] They're supposed to always be in sync [13:38] yup [13:39] I can't file it, I would not know how to do that [13:39] Unfortunately probably something painfully arcane in console-setup [13:39] * vibhav wonders what package it could be [13:39] vibhav: As I just said, console-setup [13:39] 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] it failed several times in a row... :/ [13:40] I bet running 'sudo setupcon' in a TTY switches TTY configuration to match X [13:40] But that would have to be done on each boot - a permanent fix requires figuring out how to fix the bug [13:40] cjwatson: even in a chroot ? [13:40] chroot -> irrelevant [13:41] So this means that you can't actually select a different layout in VCs right now [13:41] I am working in a chrooted console, because I am now modifying the content of the build directory [13:41] Because the very problem here is that the existing configuration is not being applied at boot [13:41] You can't fix this by messing around with configuration files [13:41] cjwatson: this is why it's ok to edit files [13:41] It's not *useful* to edit files here [13:41] ? [13:41] The configuration for your system almost certainly already says that the layout is azerty [13:41] cjwatson, bug 1015567, and /var/lib/dpkg.tar.gz is in transit to launchpad (13M upload) [13:41] Launchpad bug 1015567 in dpkg (Ubuntu) "upgrade failed: mixed non-coinstallable and coinstallable package instances present" [Undecided,New] https://launchpad.net/bugs/1015567 [13:42] But it's not being applied correctly at boot [13:42] cjwatson: no the files says "us" [13:42] I mean [13:42] this file [13:42] Oh, very odd that X has a French keymap then [13:42] the one you said [13:42] It's supposed to pick that up from /etc/default/keyboard [13:43] So the default for French in /etc/default/keyboard is usually meant to be XKBLAYOUT="fr" and XKBVARIANT="oss" [13:43] I guess a naive remixing tool might have done something at some higher level [13:45] cjwatson: did you mean naive or native ? [13:45] I meant naive [13:45] or naïve if you like [13:46] 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] it can even allow the person doing the remix job to reuse a work directory to add modifications. And this is fantastic ! [13:47] it spares quite some work. [13:50] cjwatson: and thank you very much. [13:50] np, hope I wasn't too confusing [13:51] really straightforward. :) [13:51] one more for the road ! (hips ! :p ) : where are located the files where the changes on the Unity panel launcher are stored ? [13:52] 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] melodie_: IIRC it's a gsettings/dconf key [13:54] melodie_: gsettings get com.canonical.Unity.Launcher favorites [13:54] stgraber: ah ha ! I have looked into dconf and was not able to guess which section it is related to [13:55] and gsettings has a set of commands I suppose ? Is there a documentation describing the use of this command tool ? [13:57] man gsettings and calling gsettings without any argument will give you the help [14:00] stgraber: team meeting today? [14:02] stokachu: yep, mumble in ~30min, then IRC in an hour [14:02] stgraber: cool thanks [14:05] ev, hey [14:06] seb128: hi! [14:06] ev, some whoopsie questions for you ;-) [14:06] sure :) [14:06] 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] 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] 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] ev, bug #858390 [14:09] Launchpad bug 858390 in d-conf (Ubuntu) "nautilus crashed on startup in dconf_engine_refresh_user()" [High,Triaged] https://launchpad.net/bugs/858390 [14:09] 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] ev, hum, good point [14:10] that takes nautilus down :-( [14:10] yeah, nautilus is still going away by my reading of this [14:10] ev, right [14:10] we need to convey why that happened, even if we can't fix it in precise [14:10] (and that's incidentally one of the reasons why we're careful not to promise things getting fixed) [14:10] or indeed giving them something they can follow [14:10] ev, ok, second question ... is there any way to figure if those users are using ecryptfs? [14:10] seb128: once we get the metrics stuff operational, yes [14:11] ev, any eta on that? [14:11] we'll be able to query against both data sets [14:11] it's scheduled for 12.10, but it may slip [14:11] definitely by 13.04 [14:11] ev, ok, thanks for the answers ;-) [14:11] sure thing! === zyga is now known as zyga-food [14:11] that was all for today (I think) [14:11] :D [14:11] you're always welcome to ask more [14:14] ev, ;-) [14:28] seb128, ev: NB that apport already tags bugs for users who use ecryptfs with "EcryptfsInUse=yes" [14:28] by way of /usr/share/apport/general-hooks/generic.py [14:28] nice [14:30] have to reboot, thanks and bye ! [14:32] 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] smoser: maybe whatever dpkg logs mention that package [14:32] (I'm just triaging it though, hoping to not have to actually end up fixing it) [14:33] 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] seb128: it works for me, anyway [14:33] seb128: it's what kirkland advised back then [14:33] pitti, half of those bugs don't have it, but they could be using nfs and I don't think apport flag NfsInUse? === zyga-food is now known as zyga [14:34] seb128: we don't detect that, right; if you have a recipe for this, we can [14:35] pitti, I will think about it, thanks ;-) === skaet_ is now known as skaet [15:04] ugh, we're going to install the nvidia proprietary drivers by default?? I have a security support issue with that... [15:05] oh, with an option in ubiquity...ok, that's better [15:06] apw, nice blog post [15:06] apw, borrowed your last paragraph for the ubuntudev FB and G+ page :) [15:06] dholbach, :) [15:07] mdeslaur: security support issue? Canonical supports restricted already-- or am I missing something? [15:08] 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] jdstrand: but I guess an optional checkbox during install is ok [15:09] 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] jdstrand: upstream only supports their current driver, which may not work on older cards... [15:11] 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 === zyga is now known as zyga-afk [15:16] mdeslaur: I don't disagree-- I was merely being a pessimist :) [15:17] you know, it's the security way ;) [15:18] hehe [15:18] any progress on making /dev/nvidia* not world-writable? [15:19] kees: not yet, no [15:21] kees: I've just assigned myself to that bug (LP: #979307) [15:22] pitti, Is there a place where I can just download the DB/config for status.ubuntu.com ? (want to test a patch) [15:23] tedg: yes, http://status.ubuntu.com/ubuntu-quantal/ubuntu-quantal.db [15:23] likewise for precise [15:23] tedg: the config is in lp:~wi-tracker-configurators/launchpad-work-items-tracker/ubuntu-config [15:24] pitti, Cool, thanks! === fenris is now known as Guest34289 [16:25] hallyn, does it make sense for qemu-kvm to be 'Architecture: any' ? The description implies that its for x86 only. [16:26] 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] i'm hoping to get it built with acceleration for powerpc, but haven't yet [16:27] hallyn, well, its failing on all of those arches. [16:27] rtg: yes, i'm working on it [16:27] hallyn, ack [16:27]