=== Guest47292 is now known as jrib === freeflying is now known as freeflying_away [00:50] cjwatson: meh I can't work out how to get the log off a virtual machine and need to wait until I'm home tomorrow morning before I can try it on a spare test machine === freeflying_away is now known as freeflying [01:14] cjwatson: yay got it [01:14] http://people.ubuntu.com/~jr/tmp/syslog [01:14] device-mapper: reload ioctl failed: No such file or directory [01:14] bug 1276739 [01:14] bug 1276739 in debian-installer (Ubuntu) "kubuntu encrypted lvm install fails" [Undecided,New] https://launchpad.net/bugs/1276739 [01:15] * Riddell snoozes === Fomina is now known as c_j [03:12] infinity: stgaber: around? [03:13] hallyn: Ish. What's up? [03:13] inifinty: my qemu uplaod to trusty may have badly messed up [03:14] i'm going to retry in a new vm; it's possible something else messed me up, but given the severity here - it messed up binfmts entirely so i can't run dpkg/ls/etc [03:14] hallyn: The one with ~ppa in the version? :P [03:15] yeah that one [03:16] When you say "can't run dpkg/ls/etc", do you mean "in an ARM chroot", or "at all"? [03:16] at all [03:16] -bash: /usr/lib/command-not-found: /usr/bin/python3: bad interpreter: Too many levels of symbolic links [03:18] Yeahp, you sure broke it. [03:18] i haven't yet found where [03:19] I'd look, but I stupidly broke my machine checking. [03:19] Cause I used a chroot. [03:19] the archive should reject uploads with a ~ppa suffix [03:19] So, let me reboot and then have a poke. [03:20] Logan_: He would have just reuploaded with a proper version and still broken the world. :P [03:20] hallyn: I'll delete the binary from the archive after I reboot and can, like, run stuff. [03:20] infinity: thanks. [03:23] that's why it passed all my tests. apparmor kept me from hosing myself. === e^0 is now known as sudo [03:36] hallyn: So, comparing old and new debs, it looks like you're now shipping binfmts for the native arch. [03:37] hallyn: As in, I get binfmts for x86_64 and i386 on amd64 which I didn't before, so qemu is being tripped for native binaries. [03:38] i'm not yet seeing *why* that's happening. first ithought my wrong use of dpkg-verison in postinst was to blame, but nope [03:42] hallyn: No, it's actual shipped filed that differ. [03:43] http://paste.ubuntu.com/6883091/ [03:44] Why that is, however, I'm not seeing immediately. [03:44] infinty: right, that makes perfect sense,given the symptoms; was just saying it wasn't what i originally expected to be the probelm [03:52] So, filter_binfmts is failing somehow, I guess? [03:53] yeah, that's what the buildlogs indicate [03:53] but I'm failing to see how [03:53] hallyn: Oh, possibly because you went and added a make conditional in the middle of a shell continuation. [03:53] hallyn: You can't do that. [03:53] hallyn: You need to write that bit as shell too, if it's in the middle of shell. [03:54] i see [03:54] Oh well. Gives you a chance to fix the version number on the next upload. :P [03:54] There's no reason to have the Ubuntu conditional in there anyway, is there? [03:54] since we're not fully merging the qemu trees i'm going to pull all incidences of the dpkg-vendor for nwo anyway, but [03:55] The arm64 bit is just a no-op when not building on arm64... [03:55] true [03:56] so how long does it take before ppl are no longer exposed to that? [04:00] (testing a new version... wont' be pushing too soon) [04:01] hallyn: It's already gone from ftpmaster, just needs mirror pulses. [04:02] hallyn: we probably want a fix uploaded soonish since until then, none of the binaries infinity removed exist at all (so nobody can install any version of those, which leads to other packages breaking and so on) [04:02] stgraber: To be fair, qemu-user-static has nearly 0 rdeps. [04:02] my guess is that just dropping the ifdef in the middle of that block of shell is the safest bet to have something that builds, that you have already tested and which fixes our immediate problem [04:03] But yeah, a fix would be nice. Dropping those two lines would fix it. [04:03] stgraber: there's another snafu (using dpkg-version in postinst but not depending on devscripts); [04:03] Eww. [04:03] You mean dpkg-vendor. [04:04] so yeah i'ts just http://paste.ubuntu.com/6883177/ [04:04] yes [04:04] But yeah, that should be subsituted in during build. [04:04] As in: if [ "@@VENDOR@@" = "ubuntu" ] [04:05] And then sed that in at build time when turning postinst.in into postinst. [04:05] that diff looks safe enough and the real fix for a common source with Debian is indeed to add a new variable that's substituted from debian/rules (as you already seem to be using quite a bit ;)) [04:06] hallyn: But go ahead and upload you current diff (looks good), and sort out the sed magic later, if you really care about the conditionals. [04:06] hallyn: Also, that should be 1.7.0+dfsg-3ubuntu1 [04:06] ok then, pushing. thanks for removing those! [04:06] oh, [04:06] oh heh, right. [04:09] I guess qemu could do with an autopkgtest to try and catch this kind of stuff next time around, can't hurt to have autopkgtest try to run a binary of each arch that are supported. [04:09] stgraber: You mean try to run a native binary to make sure the world isn't broken? [04:09] stgraber: Trying to run foreign binaries means having some available, which is a bit harder to sort out. [04:10] yup, as i need to hack on adt anyway i was going to write a script for that at least locally [04:10] infinity: well, I'd go with a simple test which grabs the supported core tarballs and try to chroot into them, which would incidently check that the host arch still works as otherwise you'd get an error when calling chroot :) [04:11] i was just gonna go with each of the templates which lxc-download supports... [04:15] stgraber: Can the adt infra download from cdimage? [04:17] infinity: I'm not aware of any location it can't download from. The LXC adt tests use gpg from outside servers and then grab stuff from external servers and those passed fine in adt, so it looks like they have unfiltered access to the outside. [04:20] infinity: oh actually, no, it does seem to be restricted, I guess it was the test adt box I was using somewhere which wasn't... last run of lxc adt had two failures for things using our pre-built images... === e^0 is now known as e^0_ === Guest73201 is now known as mfisch === mfisch is now known as Guest18735 [05:05] german mirror still offering me the broken version. wonder how long that'll go :( [05:14] hallyn: Don't have much (any) control over third-party mirrors. :/ [06:46] Good morning [07:46] fstrim cron spams when the ssd is not intel or samsung [07:57] tjaalton: oh, oops; can you please file a bug against util-linux with the mail and assign it to me? [07:58] yes, on it already === zyga_ is now known as zga === zga is now known as zyga [07:59] * zyga wonders if unity startup failure is that protobuf symbol he read about yesterday [07:59] hmm actually the spam is from a hdd [08:00] i've a raid mirror which it complains about [08:00] ara: hey [08:00] ara: are you on 14.04? [08:01] zyga, yes [08:01] hmm [08:01] * zyga wonders why unity crashes and looks at logs [08:02] zyga, I didn't update yesterday, though [08:03] zyga, look at this thread: https://lists.ubuntu.com/archives/ubuntu-desktop/2014-February/004425.html [08:03] zyga, might be related? [08:06] * zyga tries to recall how to copy paste in screen [08:06] yay [08:07] hmm, my protobuf is still 2.4.1, no 2.5 in sight [08:07] and seb isn't around yet [08:08] ara: yeah, that is what I suspected, wonder how to fix it now [08:08] zyga, it seems that updating should be enough [08:09] ara: nope, the 2.5 version isn't out yet [08:09] * zyga adds proposed and checks [08:11] zyga, did you apt-get update? protobuf is on 2.5 in trusty [08:11] * zyga is depressed by the whole release stuff [08:11] ara: yes, just a second ago [08:11] ara: not for me? which package did you check [08:12] (and it obviously didn't work which is another thing) [08:12] protobuf [08:12] https://launchpad.net/ubuntu/+source/protobuf/2.5.0-8ubuntu1 [08:12] I checked libprotobuf7 it is 2.4.1, libprotobuf8 is at 2.5 (and I have it installed) but it still doesn't work [08:13] and it wasn't updated just now so I already had 2.5 when booting this morning [08:13] (not ubuntu release) [08:17] did we move from dmraid to mdadm? [08:18] according to the blueprint; not yet [08:40] i'm creating a ubuntu based distro and have issues due to udev not creating device nodes in /dev, which is because devtmpfs is not mounted. now, there's devtmpfs entry in /lib/init/fstab, and it works when mounting it manually via mount -a, but mountall doesn't mount it. anyone? [08:40] now i see the same behaviour on raring ringtail, ie. there's no devtmpsfs mounted on /dev.. so i guess you have created the device nodes manually? is that the case for raring? [08:46] udev on /dev type devtmpfs (rw,mode=0755) [08:46] looks fine here [08:47] tjaalton: on raring? [08:48] tjaalton: whats your udevd version? [08:48] no trusty [08:48] raring is EOL [08:50] tjaalton: i'm targeting saucy (for now) on my target (udevd version 204), but i see the same problem on raring (on host, udev version 175) [08:50] doing something wrong then [08:50] tjaalton: mountall --verbose just seem to ignore the devtmpfs entry [08:51] tjaalton: well, on my target, possibly yes.. but the raring version is as you made it [08:54] same thing on precise and quantal here, so yes it's wrong on your end [08:56] tjaalton: that's useful info.. btw, i got a quantal server here, and the output from mount doesn't mention devtmpfs. how do you retrieve that info? [08:56] mount [08:58] tjaalton: sorry. bad mad. grep helped me spot it :) [08:59] s/bad mad/my bad/ [09:03] tjaalton: still no devtmpfs on target though. i have support for devtmpfs in the kernel, and it works when using mount -a [09:04] still not my problem :) [09:04] tjaalton: right :) [09:42] mardy, can you upload the unity-control-center changes in gnome-control-center-signon now? We've switched the seed to u-c-c (bug 1257505) [09:42] bug 1257505 in gnome-control-center-signon (Ubuntu) "Create Unity Control Center so can remain on old GNOME Control Center version" [Medium,In progress] https://launchpad.net/bugs/1257505 [09:43] robert_ancell: cool, will do soon [09:43] thanks [09:56] lightdm 23418 0.0 0.0 56520 12088 ? R 10:56 0:00 /usr/bin/python3 /usr/bin/click pkgdir com.ubuntu.clock [09:57] does anyone know what that is? [09:57] (on my amd64 desktop, trusty du jour) [09:57] it's been running for a long time already, and eating CPU [09:58] curious [09:58] Hmm I have some issue with the lightdm session startup on my desktop [09:58] it seems racy; I get some vague g_dbus_connection_real error in the log, sometimes it comes up sometimes not [09:58] hmmm, interesting, I cannot connect to 5Ghz wifi access points anymore [09:59] lol [09:59] 3 different bgus [09:59] tvoss, ChickenCutlass had the same issue [09:59] so if I stop lightdm + statr lightdm => no luck; if I restart lightdm, it works [09:59] (he just pragmatically changed the channel on his AP though) [09:59] ogra_, weird [09:59] ogra_, I have got a devolo network over power thingy here :) need to see if that would work [10:00] tvoss, well, still someone should tell the kernel team :) [10:00] ogra_, I would think so [10:00] (or cyphermox_, if it is NMs fault) [10:00] ah, it seems phablet-tools pulls in click now [10:02] click keeps getting respawned with the same command line, indefinitely [10:02] sergiusens, ^ [10:03] but there were no changes since the 22nd [10:03] bah and under strace it works 100% of the time of course [10:03] intresting that you didnt notice this before then [10:03] grmlblb [10:04] lool, dont you love races ? :) [10:05] lool, btw, restart never worked for me, i always had to stop/start (restart left a hanging lightdm around) [10:06] pitti, are you referring to th upstart stuff? [10:07] sergiusens: I don't know; I just heared my CPU fan go wild for 10 mins and checked in top that it's due to that [10:07] pitti, did you upgrade between the 22nd and today (apart from today) [10:07] ogra_: certainly, I upgrade every day [10:07] pitti, it might be upstart jobs and rerunning apparmor and checking for clicks [10:08] well, then it cant be phablet-tools itself i'd say [10:08] there was an apparmor-click change tonight [10:08] ogra_: no, that's just what pulls in upstart-app-launch, click, etc. [10:08] pitti, right, but since the 22nd already [10:09] I purged click and its rdepends and reinstalled phablet-tools, seems it's tame now === doko_ is now known as doko [10:09] * sergiusens has a pending task to split the package into smaller bits [10:09] * apparmor/click.py: adjust to add mock_testenv and honor it to skip [10:09] checking apparmor_dirs when set [10:09] so it seems it's gnome-settings-daemon not happy about something [10:09] pitti, might be that your PC has some mock stuff around others dont ;) [10:09] http://paste.ubuntu.com/6884348/ [10:10] this is specific to failing startups: [10:10] ** (gnome-settings-daemon:30698): WARNING **: Unable to register client: GDBus.Error:org.freedesktop.DBus.Error.ServiceUnknown: The name org.gnome.SessionManager was not provided by any .service files [10:11] hm, we don't install a .service for gnome-session as we don't dbus-activate it (and don't want to) [10:11] lightdm is supposed to just start it; so perhaps gnome-session crashed? [10:12] lool: do you have a .crash file for something like g-sessin? [10:12] it's possible, albeit hard to tell [10:12] no [10:12] just susres, whatever that is [10:12] ah suspend resume [10:12] old [10:15] pitti: it doesn't even start gnome-session [10:18] pitti, your click issue should be fixed by https://launchpad.net/ubuntu/+source/indicator-datetime/13.10.0+14.04.20140205-0ubuntu1 [10:18] infinity, thanks for fixing libcmis [10:19] so what I did was replace gnome-session with a wrapper script that calls strace gnome-session.real, and this never created a strace [10:19] I did manage once to catch a strace of a failed startup of unity-greeter in the same way [10:19] it never fails if I strace -f though [10:20] lool, what's your issue? [10:20] lool, greeter one? [10:20] seb128: lightdm greeter not coming up [10:20] but racy [10:20] sometimes it does [10:20] lool, when did it start? [10:21] seb128: it might have happened rarely previously; it's a new install; it started appearing a lot in the last days [10:21] yesterday was when I first realized there was something bad going on [10:21] seb128: Just a quick poke, mearly to make sure it hasn't fallen off the radar. [10:21] lool, ok, because the new indicator-datetime update from yesterday/the click issue pitti described made the greeter not load for kenvandine [10:21] I did some changes to my own user session (to start an upstart job as ~lool) but that shouldn't affect greeter [10:21] seb128: aha [10:21] lool, that's fixed in this night update (the one I Just pointed to pitti) [10:22] lool, indicator-datetime update that is [10:22] Unit193, what is "it" [10:22] ? [10:22] indicator-sound pavucontrol alt recommend. [10:22] seb128: but I dist-upgraded already [10:23] lool, did you restart the greeter since and still get the issue? [10:23] seb128: Yes [10:23] seb128: ack, thanks; I got a load of new packages now, I'll reboot [10:23] lool, try uninstlal indicator-datetime in case? or maybe you have a different issue... [10:23] pitti, yw! [10:24] Unit193, I pinged people about it yesterday, let me check [10:24] Cool, danke. [10:24] Unit193, approved [10:24] Nice, thanks. [10:25] robert_ancell: can you please create a MP for this? https://code.launchpad.net/~robert-ancell/gnome-control-center-signon/unity-control-center [10:25] mardy, syre [10:25] sure [10:25] hmmm why dont I see strings in execve but only pointers [10:25] in my strace [10:26] seb128, can you review too https://code.launchpad.net/~robert-ancell/gnome-control-center-signon/unity-control-center/+merge/205110 [10:26] http://paste.ubuntu.com/6884429/ is strace -e trace=process of unity-greeter [10:28] lool, do you have lightdm.log [10:29] robert_ancell: http://paste.ubuntu.com/6884441/ [10:29] sorry had to reproduce the issue [10:30] lool, you have the same problem as Ken [10:30] I have to do a roundtrip to school, brb [10:30] robert_ancell: I have latest datetime though [10:30] brb [10:57] apw, Ok, I attached a debdiff for systemd (which contains the udev rules we have to modify) to bug 1277006 [10:57] bug 1277006 in udev (Ubuntu) "[Trusty] Need additional udev rule to avoid efi framebuffer to be primary" [High,Triaged] https://launchpad.net/bugs/1277006 [11:11] fginther, did those jenkins jobs get set up OK? [11:11] seiflotfy__, are you OK with ps-jenkins being added to ~activity-log-manager? [11:14] cjwatson: any chances I can deliver one last fix? (apparently a regression) [11:18] robert_ancell, seb128: I replaced indicator-datetime-service with /bin/true and I was still able to trigger the race [11:18] like one time out of 4 [11:21] lool, ok, maybe a redherring then [11:21] or another issue [11:21] tseliot: ! [11:22] tseliot: um, I'm not sure that's realistic. details? [11:23] cjwatson: apparently my last upload of fglrx-pxpress keeps on writing "y" to a log file... two users reported this to me this morning [11:23] cjwatson: and the log file keeps growing... [11:24] fglrx-pxpress isn't on images, right? [11:24] (hope not.) [11:24] it doesn't seem to be. so delivering your fix is basically independent of 12.04.4 [11:24] but yeah, let's get that in [11:24] cjwatson: no but jockey can install it if the fglrx is installed. I assume we don't install fglrx in ubiquity [11:25] *fglrx driver [11:25] ok, good [11:25] I'll come up with a fix soon [11:25] tseliot: y would it do that? =) silly driver... =))))) [11:26] xnox: :D it's really an upstart job to handle multiple gpus that does that [11:32] smb: please don't upload bug 1277006 just yet [11:32] bug 1277006 in systemd (Ubuntu) "[Trusty] Need additional udev rule to avoid efi framebuffer to be primary" [High,Triaged] https://launchpad.net/bugs/1277006 [11:32] smb: I applied it to my local git, but that has staged changes [11:33] pitti, I could not even if I wanted, but stop apw (in case he would) [11:33] Which we should have now [11:34] smb: I'll upload it now [11:34] pitti, ok [11:35] pitti, hey .. we probabally want to include vesafb in the list of "non-primary" framebuffers while you are there [11:35] apw: hey Andy [11:36] * smb notes it would be called vesa-framebuffer [11:36] apw: good timing, two seconds away from dput :) [11:36] heh :) [11:36] i was lucky [11:36] pitti, what smb said [11:36] smb, apw: http://paste.ubuntu.com/6884698/ ? [11:37] DRIVERS=="nouveau", GOTO="graphics_end" [11:37] hm, is that still current? [11:37] oh wait, fun [11:37] we have a first rule [11:37] DRIVERS=="nouveau", ENV{PRIMARY_DEVICE_FOR_DISPLAY}="1" [11:38] (or set of rules, for i916 and radeon, too) [11:38] pitti, The vesa line looks good to me (DRIVER=vesa-framebuffer in one of my laptops) [11:38] ah, so the first set is for DRM, the second set for fb [11:38] yeah that looks right to me, and smb has the kit to test it [11:38] yeah two separate things in there [11:38] to confuse the reader [11:38] $ udevadm info --export-db|grep 'DRIVER.*-framebuf' [11:38] E: DRIVER=efi-framebuffer [11:39] ack, adding vesa-framebuffer then [11:39] smb, pitti, what about simple-framebuffer, wasn't that one you wanted smb ? [11:40] pitti, both [11:40] or am i getting confused [11:40] Err [11:40] wait [11:40] *-framebuffer would be too much? [11:40] simple-framebuffer just in case we ever would have it and thats not likely for T... (except arm maybe) [11:40] there is never the case that X would start on such a framebuffer, even if you don't have a "better" graphics card installed? [11:40] yeah it would as we are only trying to ignore the "fallback franebuffer drivers" [11:41] pitti, so all this affects is whether it is marked "PRIMARY", and if it is splash is started much earlier to get prettyness [11:41] so http://paste.ubuntu.com/6884708/ is the current version now [11:41] if no PRIMARY is found, we will start splah on whatever it can cope with, which wold include the "excluded" ones you are adding [11:42] pitti, ack [11:42] smb: thanks for checking; uploading then [11:42] smb, i thought simple-framebuffer was the one at issue in your kvm spot, where it is being replaced [11:43] apw, Yes, before we flipped the config to not build it at all [11:43] oh ok === MacSlow is now known as MacSlow|lunch === marcoceppi_ is now known as marcoceppi === MacSlow|lunch is now known as MacSlow [13:22] ogra_, sergiusens, pitti: I don't have all the context, but... the click-apparmor change ogra mentioned doesn't actually do anything with the installed package-- ie, it will behave the same as it did before the upgrade [13:22] jdstrand, yeah, seems it was indicator-datetime that caused it [13:23] ok [13:23] cool [13:25] anyone know anything about mythbuntu? (I'm trying to test 12.04.4 candidates) [13:26] its a myth ! [13:27] * xnox feels thrilled to use: try... except... else... finally... clause in python! [13:28] using extern c {} can't be far away now [13:33] cjwatson: I've just uploaded the fix in precise-proposed - fglrx-pxpress (0.6~hybrid0.0.2) for bug #1277058 [13:33] bug 1277058 in fglrx-pxpress (Ubuntu Precise) "Process keeps writing to the log" [Critical,In progress] https://launchpad.net/bugs/1277058 [13:45] tseliot: thanks, reviewing === Ursinha-afk is now known as Ursinha [13:56] jdstrand: yes, I think the latest indicator-datetime fixed that === sarnold_ is now known as sarnold [14:09] cjwatson: thanks! [14:11] Hi dear developers, I am loking for a project in C/C++ that needs contribution, the prgraming level I look for is Embdded programming or very close to hardware programming, not necessary hardware driver but things in that style. As I can't rignt now choose a project or part of Ubuntu by my own interest I am open for suggestion and probabaly if someone feels for it a Mentor trough my start. I am a hardware/embdded M.S.c. gradua === Ursinha-afk is now known as Ursinha [14:27] hi there [14:27] is it still possible to get debian packages into 14.04? [14:27] yes [14:27] i thinkt he deadline is today? [14:28] only for automatic operation [14:28] no [14:28] what's "automatic operation"? [14:28] manual requests will be possible without any particular justification up to feature freeze (https://wiki.ubuntu.com/TrustyTahr/ReleaseSchedule) [14:28] automatic imports from the debian archive [14:28] tseliot: ping [14:28] up to today we automatically sync changes in Debian to packages we haven't modified in Ubuntu [14:29] (end of today, I expect) [14:29] so February 20th is the deadline for manual imports on request [14:29] thanks [14:35] shadeslayer: pong [14:35] tseliot: I was wondering, is there a way we can prevent aptdaemon from being pulled into the Kubuntu ISO? I believe the reason why it's pulled in right now is due to ubuntu-drivers-common [14:36] shadeslayer: is it too big? [14:36] apachelogger: ^^ [14:37] tseliot: it is not used [14:37] we have qaptworker which pretty much is a qt version of aptdaemon [14:37] pitti: any ideas? ^ [14:40] shadeslayer, tseliot: it's being used for mapping modaliases to driver packages [14:40] apachelogger: ^ [14:40] pitti: I thought that was done internaly in detect.py and the pkkit functionality was only a addon [14:40] and not critical to ubuntu-drivers-common [14:41] yes, it is [14:41] i. e. if you don't need that functionality on the PackageKit API level, we can drop it to a suggests [14:41] u-d itself just uses python-apt for that [14:41] pitti: yep, we don't really need the functionality on the pkkit API level [14:41] (we are not using any PK API on the KDE side of things) [14:41] all hard wired to qapt->libapt-pkg [14:41] ^^ [14:43] tseliot, apachelogger, shadeslayer: https://github.com/tseliot/ubuntu-drivers-common/commit/2a53800 [14:43] \o/ [14:43] pitti: great :) [14:43] pitti: thank you [14:43] how soon do you need this uploaded? [14:45] pitti: can wait, it's just wasting space, as long as it lands before release we should be fine ^^ [14:45] yeah, still plenty of time [14:46] pitti: on that note, could you also have a look at 1274605 [14:46] or maybe poke someone on the firefox packaging team^^ [14:47] bug 1274605 [14:47] bug 1274605 in firefox (Ubuntu) "Please demote xul-ext-ubufox from Firefox Recommends to Suggests" [Undecided,New] https://launchpad.net/bugs/1274605 [14:47] yeah, not my area I think [14:47] blueyed, happy birthday! :) [14:47] chrisccoulson: ^ [14:57] robert_ancell, yes, the jobs are deployed and ready [14:57] fginther, great, thanks! [14:59] What should we do for Vcs-* control fields in merges? Leave them pointing them at Debian? Pull them out? [14:59] prepend XS-Debian- [14:59] I believe they should be changed to : XSBC-Debian [14:59] not BC [14:59] oh, ok [14:59] I mean you sort of can but it's redundant, they're source information so just XS- [15:00] cjwatson: on that note, do you have a document that explains those? [15:00] google doesn't give me anything [15:00] policy [15:01] I think ... [15:02] shadeslayer: at least it's in deb-src-control(5) under "USER-DEFINED FIELDS" [15:03] Understood - thanks! [15:04] cjwatson: ah, thx [15:05] dobey: could you take a look at https://code.launchpad.net/~dpm/intltool/add-qtdesigner-support/+merge/145112 ? [15:06] Riddell, I think he mentioned you'd have to get hold of danilo to review that one. I tried to get in touch with him for this MP a while ago, but he wasn't around [15:07] * Riddell e-mails [15:07] you need to get danilo to re-review [15:07] i can't change danilo's vote for him on lp === Guest18735 is now known as mfisch === mfisch is now known as Guest93890 === greyback is now known as greyback|away [15:36] ev: ping, have a moment to talk about errors.ubuntu.com? [15:37] shadeslayer: ev is on holidays through the 14th [15:37] oh [15:37] josepht: thanks [15:38] anyone else whom I can talk to about e.u.c ? [15:39] We have a patch in Kubuntu that has started reporting crashes to e.u.c ( for eg https://errors.ubuntu.com/oops/fe95cba8-60c0-11e3-b76d-e4115b0f8a4a ) but the top 4-5 frames of that crash are from the crash handler, which might confuse e.u.c into thinking that KCrashHandler is crashing [15:40] would daisy be need to modified so as to not think that kcrashhandler is crashing? [15:40] or is everything fine and it'll work perfectly [15:48] pitti: tseliot: one of the other requests for ubuntu-drivers-common, drivers like nvidia-173 are super duper old and should probably have a key/value pair that says that these should be the least preferred driver [15:49] and maybe even have generic labels such as "Wireless Card" so that users don't have to see "Broadcom ABCD a/b/g/n" in the ui [15:51] shadeslayer: I'm going to change the packages descriptions, so that we get better descriptions in the UI [15:51] that's not hardcoded in u-d-c [15:51] it's in the single packages [15:51] tseliot: yay \o/ [15:52] tseliot: I use short descriptions in my UI : http://im9.eu/picture/dz7621 [15:53] seiflotfy__, around? [15:54] shadeslayer: I see. I'll take care of that as soon as I'm done with some more work in ubuntu-drivers-common [15:54] cool [15:54] tseliot: anything exciting coming up in ubuntu-drivers-common? [15:55] shadeslayer: a program which handles multiple gpus or configuration changes on boot [15:55] e.g. you unplug a graphics card, or add one card [15:55] ah cool, I'll keep an eye out for those [15:55] :) [15:56] tseliot: something that came up during the development of the KDE Frontend, my ui is all C++ and I'm using a python script to export data over dbus [15:56]