[01:06] <leb> can anyone help with this?  https://gist.github.com/tildeleb/7329005 what is the issue with #include <fcntl.h>
[01:09] <sarnold> leb: change linux/inotify.h  to sys/inotify.h
[01:11] <xnox> snap.
[01:11] <xnox> leb: yeah, what sarnold said.
[01:11] <Serus> How can I see which graphics card ubuntu is using?
[01:12] <xnox> Serus: top-right system cog -> about this computer
[01:12] <xnox> Serus: should have a line "Graphics: "
[01:12]  * xnox has Intel® Ivybridge Mobile
[01:12] <Serus> can't find the about this computer in the menu
[01:13] <xnox> Serus: what ubuntu are you using?
[01:13] <Serus> 12.04
[01:14] <xnox> ah
[01:14] <Serus> found it
[01:14] <Serus> Graphics: Unknown
[01:15] <xnox> Serus: lspci on cmdline might give you more info. Btw, this sounds more of a support question which are handled on #ubuntu
[01:15] <Serus> #ubuntu is so full that many questions remain unseen
[01:16] <brainwash> Serus: make sure that the package "mesa-utils" is installed
[01:16] <infinity> That feature in the about box doesn't work in 12.04 without mea-utils being installed, if I recall.
[01:16] <infinity> brainwash: Jinx. ;)
[01:16] <brainwash> :D
[01:17] <Serus> ok and then reboot or something?
[01:17] <brainwash> does it still show "Unknown"?
[01:17] <Serus> Ah it uses the geforce card now :D
[01:18] <Serus> GeForce GT 630M/PCIe/SSE2
[01:18] <Serus> should all the artifact in video be gone now?
[01:18] <Serus> artifacts*
[01:20] <Serus> nope still artifacts in video :/
[01:20] <brainwash> the guys in #ubuntu might know an answer, this here is the channel for development talk and not general support :)
[01:20] <Serus> ok
[01:21] <Serus> well I'm going to sleep first
[01:21] <brainwash> good night
[01:21] <Serus> you too.
[01:24]  * infinity glares at /etc/gnome/defaults.list conffile prompts.
[01:24] <infinity> Oh, wait.  This is chrome's fault, I knew that already.
[01:25]  * infinity glares at Google instead.
[01:26] <mwhudson> heh
[01:33] <Noskcaj-school> rsalveti: Can you look at the merge for elementary? I think it's a sync but it would be better if you check since you made the ubuntu delta
[01:34] <rsalveti> Noskcaj-school: sure
[01:34] <Noskcaj-school> thanks
[01:38] <rsalveti> Noskcaj-school: the only difference are the additional dependencies to add support for efreet, eio and edbus
[01:39] <Noskcaj-school> oh, so there is something
[01:39] <rsalveti> I might just try to get that change in debian, and then we can sync
[04:13] <rbasak> Oooh. I found a build that eatmydata actually causes to fail in sbuild.
[04:18] <rbasak> (libvirt does some kind of fsync test that eatmydata breaks and causes a segfault)
[04:46] <ScottK> cjwatson: Would it be possible to do a one time MoM run (or some equivalent to get the diffs) against experimental?  All the KDE packages we need to merge against for trusty are there and doing it just by hand would be less fun.
[05:40] <pitti> Good morning
[06:06] <Noskcaj> tjaalton, Can you try and merge sssd from debian?
[06:33] <tjaalton> Noskcaj: i maintain both..
[06:34] <Noskcaj> tjaalton, I know. In the case that someone else might have to work on either, would it not make it easier if it was merged when possible? Why isn't it already?
[06:37] <tjaalton> iirc there isn't much to merge, and a new upstream release needs to be merged anyway
[06:40] <ScottK> Noskcaj: For packages that are actively maintained (also like pyqt5), it's probably better to leave it to the people that are already focusing on it until later in the cycle.
[06:41] <Noskcaj> ok
[06:49] <seb128> stgraber, hey, could you have a look to bug #1244736?
[06:57] <tjaalton> Noskcaj: besides, we don't have the new samba in trusty yet, so a sync/merge wouldn't build without reverting the changes to build-deps
[07:01] <tvoss_> xnox, ping
[08:29] <tvoss_> cjwatson, I'm trying to mark some symbols as optional in a .symbols file, but cannot remember the syntax. Do you have a link to documentation handy?
[08:32] <seb128> tvoss_, http://wiki.debian.org/UsingSymbolsFiles
[08:32] <tvoss_> seb128, thx, http://manpages.ubuntu.com/manpages/lucid/man1/dpkg-gensymbols.1.html was the place to look at :) rtfm, that is ;)
[08:33] <seb128> tvoss_, or see man dpkg-gensymbols
[08:33] <seb128> tvoss_, ;-)
[11:10] <xnox> ScottK: if you a smallish list of src-packages (e.g. in kubuntu seeds?!) i can run MoM against them for you. With added bonus of testing if my patches to diff against trusty-proposed work or not.
[11:11] <xnox> ScottK: and i'll publish result on people or some such.
[11:21] <pitti> xnox: as for your WI change on the logind BP: September is still in the past ;)
[11:21] <pitti> xnox: oh, it's DONE now, ignore me
[11:26] <xnox> pitti: yeah, i think it was september when I finally gave up on logind dbus api, and instead made ubiquity-dm actually create a PAM session and close it.
[11:27] <pitti> xnox: ah, so much more robust :)
[11:27] <Laney> wasn't that always the right way
[11:27] <Laney> ?
[11:28] <xnox> Laney: we ain't no need a PAM session, ubiquity-dm haz root.
[11:31] <cjwatson> ScottK: remind me tomorrow?  I'm on holiday tomorrow and I suspect this is non-trivial.  (actually it would probably be easier to have a package list that gets overridden to be always merged from experimental for a while, or something)
[11:31] <cjwatson> oh, xnox replied
[11:31] <cjwatson> fine
[11:32] <Laney> xnox: Well, other things can happen at session opening as you demonstrated by that fix
[11:33] <xnox> Laney: well, my first try was mimicking pam_systemd.so with dbus calls, which only resulted in pam-session being opened & then logind giving a hizzy hit, assume that session is dead and close it straight after.
[11:34] <Laney> ISTR the documentation saying "don't do this"
[11:34] <xnox> Laney: and it's not really a generic PAM session, as I set logind private & undocumented & non-standard variables to create a "display-manager" logind session, which seems to be enough to please network-manager and friends.
[11:35] <xnox> Laney: also "noone understands init/cgroups/linux but Lennart"
[11:35] <xnox> Laney: I don't find "PAM" the best protocol / API at all =(
[11:35] <Laney> oh well
[11:35] <Laney> done now :P
[11:36] <xnox> =)
[12:19] <sil2100> pete-woods: hi!
[12:19] <pete-woods> sil2100: hi
[12:19] <sil2100> pete-woods: how familiar are you with camera-app and autopilot...? ;)
[12:20] <pete-woods> sil2100: my familiarity is limited to knowing that the camera app autopilot tests are "somewhat unreliable"
[12:20] <sil2100> pete-woods: ok, then maybe I'll wait for Bill to pop up as I see he made the most commits to camera-app
[12:21] <sil2100> pete-woods: since we're getting test failures after the AP 1.4 switch
[12:21] <pete-woods> sil2100: unfortunately all I've done with the camera app is patching in the infographics support
[12:32] <tvoss_> doko, ping
[12:33] <tvoss_> doko, I stumbled across some interesting behavior with symbol versioning for this mp: https://code.launchpad.net/~thomas-voss/dbus-cpp/refactoring/+merge/191369
[12:34] <tvoss_> doko, two things: turns out that enabling coverage for gcc results in additional symbols being exported from a shared object. More to this, there are some arch dependent symbols exposed for std-library features that I would love to get rid of :)
[12:52] <ScottK> xnox: Yes.  It's anything with an upstream version of 4:4.11.* (or seeded in Kubuntu, whichever is easier).
[12:54] <xnox> ScottK: can you use something like dctrl-grep on a downloaded Sources file to generate a package list & check it's what you want? It should let you specify tag to grep for (e.g. Version) and tags to print (e.g. Package)
[12:54] <xnox> (also it will let you grep task, etc)
[13:05] <mitya57> ScottK: what do you think about bug 1243102? If we upload pyqwt5/pyqwt3d with good version numbers, we will be able to drop sip4 delta.
[13:05] <mitya57> (Some comment suggests that a rebuild solves the bug)
[13:09] <ScottK> I'd update sip4 from Debian first so we don't end up rebuilding again, but that's a good ide.
[13:09] <ScottK> idea even
[13:13] <mitya57> Actually, we can even add an autopkgtest to make sure we never break these again
[13:14] <mitya57> Re qtserialport build-wait, it's because our qtbase is still 5.0.2, but I think it can actually build with 5.0, will look now
[13:16] <ScottK> OK.  I'm about to be offline for ~12 hours so good luck.
[13:17] <caribou> xnox: I see that you marked the zsh package as "up for grab" to be merged
[13:18] <caribou> xnox: I would like to gain experience in merging (never done before) and I thought that this could be a good opportunity
[13:23] <xnox> caribou: it's a tough one to merge. If you do it, i'll carefully review it for you & provide feedback.
[13:24] <xnox> and if all good sponsor it.
[13:24] <caribou> xnox: tough in what sense (I'm looking at the report)
[13:24] <caribou> xnox: I can pick another one to get my feet wet
[13:25] <xnox> caribou: well try to resolve the conflicts and see how far you get =)
[13:25] <caribou> xnox: ok, will try it out
[13:26] <xnox> caribou: i think merging libpng (which is also offered up for grabs) is a better one to get ones feet wet.
[13:27] <caribou> xnox: ok, I'll look at this one too
[13:39] <caribou> xnox: I hope you don't mind me coming to you for a few questions ?
[13:53] <xnox> caribou: yeah, just ask me here.
[13:54] <caribou> xnox: for instance, the REPORT for libpng does not list any conflict; does this mean that only modifications b/w ubuntu's version and the new debian version need to be verified ?
[13:56] <xnox> caribou: i don't usually use REPORT. but as far as I understand it means that: MoM generated diff between current ubuntu & common base, took that patch, slapped on top of new debian, and "it worked"(tm)
[13:56] <xnox> caribou: but the resulting tree, might be complete brain dead and FTBFS =)
[13:57] <xnox> caribou: are you using grab-merge script?
[13:57] <caribou> xnox: yes
[13:57] <xnox> caribou: that should download all relevant files and tell you what to do =)
[13:58] <caribou> xnox: so basically check the .patch files make sure that old ubuntu modification are either still there or carried over in Debian and verify if it builds
[13:58] <caribou> xnox: for a start
[13:58] <xnox> caribou: usually i'd expect a person to rebase all applicapable changes, drop no-longer needed ones, adjust debian changelog, test-build the package, and compare diff (new_ubuntu -> new_debian) with old diff (old_ubuntu -> old_debian) to make sure it all still is sensible.
[13:58] <xnox> caribou: exactly! =)
[13:58] <caribou> xnox: ok, I will go that way, thanks
[14:00] <seb128> hum
[14:00] <seb128> shotwell autopkg tests started failing
[14:00] <seb128> https://jenkins.qa.ubuntu.com/job/trusty-adt-shotwell/10/ARCH=i386,label=adt/console
[14:00] <seb128> StateNotFoundError: State not found for class 'WelcomeDialog'.
[14:01] <seb128> sil2100, didrocks, jibel: is that due to the new autopilot? is anyone handling that transition/going to fix the autopkgtests for stuff in the archive?
[14:01] <didrocks> seb128: shotwell is using autopilot?
[14:02] <sil2100> seb128: this looks like something that AP 1.4 *could* cause
[14:02] <seb128> shouldn't also autopilot be blocked if it regresses tests? (it's marked as valid candidate on http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html)
[14:02] <seb128> didrocks, yes, pitti added autopilot tests to it
[14:03] <pitti> ah, just saw the failure notification, I'll have a look
[14:04] <pitti> seb128, didrocks, sil2100: yes, clearly from AP 1.4, I know what it is
[14:04] <pitti> that's one of the two behaviour changes that it does
[14:05] <pitti> will fix after meeting
[14:05] <seb128> pitti, do you know if whoever is doing the autopilot update plans to deal with rdepends in the archive? (that might be worth an email to ubuntu-devel@)
[14:05] <seb128> pitti, danke
[14:06] <sil2100> pitti: thanks!
[14:10] <seb128> hum
[14:10] <seb128> something seems weird with https://launchpad.net/ubuntu/+source/gnome-keyring/3.10.1-1ubuntu1
[14:10] <seb128> the builds are stucked on " dpkg-buildpackage: binary only upload (no source included)"
[14:10] <seb128> for 3 hours
[14:11] <seb128> cjwatson, infinity: ^ any idea about that?
[14:22] <didrocks> seb128: most of the time I've seen this is because of a daemon (test daemon most of the time) wasn't killed by the tests
[14:23] <seb128> didrocks, oh, I guess that makes sense, thanks
[14:23] <didrocks> yw
[14:23] <seb128> I guess infinity is going to be after me next for blocking the builders :p
[14:23] <didrocks> right ;)
[14:37] <pitti> seb128: oh, someone didn't commit to the bzr branch on upload :(
[14:37] <seb128> pitti, shotwell?
[14:38] <pitti> seb128: yes
[14:38] <seb128> pitti, that would be me :/
[14:38] <seb128> pitti, let me fix that
[14:38] <pitti> seb128: or you do happen to have these commits locally and you forgot to push?
[14:39] <seb128> pitti, I forgot to update the vcs, but I've the different sources locally so I can "replay" the commits easily
[14:39] <pitti> seb128: or diffs from https://launchpad.net/ubuntu/+source/shotwell/+changelog :) (last two uploads)
[14:41] <pitti> seb128, didrocks: test ported, FYI (now changing debian/tests/import to use the new autopilot-sandbox-run)
[14:44] <didrocks> excellent, thanks pitti!
[14:51] <pitti> seb128: (want me to do the import, if you are busy? no problem)
[15:06] <seb128> pitti, sorry, door bell, I was away for a bit, doing it now
[15:10] <seb128> pitti, ok, you can pull
[15:11] <pitti> seb128: thanks
[15:12] <seb128> pitti, I put back your unreleased change on top of the releases
[15:14] <pitti> seb128: aand uploaded, cheers!
[15:15] <seb128> pitti, danke ;-)
[15:15] <bdmurray> pitti: could you have a look at change for bug 1084979?
[15:16] <mlankhorst> confound these questions!
[15:18] <pitti> bdmurray: it's a nice hack, but not something which I'd like to put upstream (as this is quite specific how we bolted on whoopsie support in the ubuntu branch); need to think about it
[15:19] <pitti> bdmurray: I'd rather not pass an UI object to the hooks but call them anyway, as they usually do other things than just asking questions
[15:19] <pitti> bdmurray: some, like rhythmbox, even change the affected package
[15:20] <pitti> not passing an UI object will crash those hooks which don't check for it, but that doesn't matter that much
[15:23] <bdmurray> pitti: Do you mean you'd rather the solution stopped passing an UI object to the hook but that it still ran?
[15:25] <pitti> right
[15:25] <bdmurray> pitti: got it, thanks
[15:26] <pitti> bdmurray: that bug is still in an open tab; sorry, getting too many higher-urgency requests lately :/
[15:27] <maxiaojun> hi, does anyone know the utf8 filename issue of unzip in 12.04-13.04 ?
[15:27] <bdmurray> pitti: no problem, thanks
[15:30] <pitti> maxiaojun: unzip works fine with UTF-8 in general
[15:31] <maxiaojun> pitti: no, it makes all filenames appear to be ???? until 13.10
[15:31] <pitti> ah sorry, I tried on current trusty; misread 13.04
[15:31] <pitti> but we have unzip 6.0 since lucid
[15:32] <pitti> maxiaojun: ah, apparently fixed in http://packages.qa.debian.org/u/unzip/news/20130224T163250Z.html
[15:32] <GunnarHj> pitti: Hi Martin, do you have any idea what causes the problem at bug 1248343?
[15:32]  * pitti really needs to run out for a bit, bbl
[15:33] <maxiaojun> pitti: sure, the fix is there, i'm just asking how to deal with the issue in old releases, most importantly, 12.04
[15:33] <GunnarHj> pitti: No hurry with my question...
[15:33] <happyaron> does Super-Space for switching input method really work for you?
[15:35] <seb128> happyaron, define "switching input method"
[15:35] <pitti> 25.0+build3-0ubuntu0.12.04.1
[15:35] <pitti> GunnarHj: needs an apt-get update, it's now version 25.0+build3-0ubuntu0.12.04.1
[15:35] <happyaron> seb128: switching among "input sources"
[15:36] <seb128> happyaron, it works for me with gsd if I run ibus-setup and change the ibus binding to another one, I guess there is a grab conflict between ibus and gsd
[15:36] <seb128> happyaron, ibus sources or gsd input sources?
[15:36] <maxiaojun> ... what about the unzip issue in 12.04-13.04 ...
[15:36] <hggdh> maxiaojun: supposing it is just a patch applied on the same version, we will need a SRU for it
[15:36] <happyaron> still not very clear for me, but it just does not work out-of-box on my newly installed system.
[15:37] <seb128> happyaron, right, there is that conflict (I noticed this week)
[15:37] <seb128> happyaron, you also need the current gsd SRU
[15:37] <GunnarHj> pitti: Aha, will suggest that. Thanks!
[15:37] <pitti> GunnarHj: (followed up to the bug)
[15:37] <seb128> happyaron, can you check with the gsd SRU and ibus changed to not conflict?
[15:37] <happyaron> ok
[15:37] <pitti> meh, autopkgtest fail galore due to uninstallable pykde
[15:37] <pitti> jibel: ^ FYI, will retry in a bit
[15:37] <maxiaojun> there are various fix over unzip 6.0 (upstream almost dead) accumulated over time
[15:38] <GunnarHj> pitti: You are too fast to me as usual. ;-)
[15:38] <TheLordOfTime> maxiaojun: i would assume that perhaps the patch that exists on the Debian bug for unzip, if it's in the Debian package, might be able to be applied to the packages as SRUs... (http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=682682 is relevant?)
[15:39] <maxiaojun> i just wonder whether we just upgrade to what saucy have or just apply the specific patch, i don't care other fixes at this point
[15:40] <maxiaojun> i just want to know which is more acceptable to you and i will file a sru request then
[15:42] <seb128> bdmurray, can you let the file-roller SRU in saucy be rolled out? The system reported a bunch of new issues but none seems related to the SRU (they are mostly retracing not working that create new buckets and slightly different signatures of existing issues that e.u.c fails to match in the same report)
[15:44] <bdmurray> ev: Can we update errors yet?  I noticed and fixed saucy-proposed not being enabled in the retracers yesterday.
[15:45] <bdmurray> seb128: I'll have a look
[15:46] <seb128> bdmurray, not having proposed would explain why some of the retracing didn't work
[15:46] <seb128> bdmurray, thanks
[15:46] <maxiaojun> hggdh: maybe you can answer my question?
[15:46] <GunnarHj> happyaron: Hi Aron! I just changed the font for Chinese to fonts-droid (bug 1173571). Considering that this is kind of a mined area, do you have any thoughts? I noticed that fonts-droid is used in Ubuntu Touch.
[15:46] <TheLordOfTime> pitti, hggdh: i'm curious on maxiaojun's behalf, about whether this would be version-bumped or SRU'd to fix the UTF8 issue.
[15:47] <happyaron> seb128: after changing the ibus's shortcut, gsd's works, but then unity's shortcut help page will be displayed at the same time.
[15:47] <TheLordOfTime> pitti, hggdh: there is a patch on the debian bug for it, so I'd think SRU, but again, you guys know better.
[15:47] <TheLordOfTime> (in relation to maxiaojun's issue)
[15:47] <bdmurray> TheLordOfTime, maxiaojun: I'll have a look at it.  Is the Ubuntu bug linked to the debian bug?
[15:47] <happyaron> GunnarHj: it's good to use fonts-droid as default for Chinese, but there could be problem that they cannot be displayed in the editor area in libreoffice
[15:47] <TheLordOfTime> bdmurray: i dont' see an Ubuntu bug on it
[15:47] <seb128> happyaron, that's because you hold super for longer than a second, we have the same issue on other shortcuts (e.g super-s/f/v/...)
[15:47] <happyaron> GunnarHj: that would need to be checked
[15:48] <TheLordOfTime> maxiaojun: is there a bug about this in Ubuntu?
[15:48] <bdmurray> bug 580961
[15:48] <TheLordOfTime> yeah just saw it
[15:48] <happyaron> seb128: if press shorter then the input source switch does not work for me
[15:48] <TheLordOfTime> (failed to search all bugs :/)
[15:48] <TheLordOfTime> bdmurray: the debian bug with the fix is 682682...
[15:49] <TheLordOfTime> bdmurray: the ubuntu bug doesn't seem to be linked right to that...
[15:49] <happyaron> seb128: it's actually first show the help and then switchable among input sources.
[15:49] <maxiaojun> https://bugs.launchpad.net/ubuntu/+source/unzip/+bug/1199239
[15:50] <TheLordOfTime> maxiaojun: i... think that's the wrong bug...
[15:50] <TheLordOfTime> maxiaojun: but 580961 which bdmurray found seems to be right... https://launchpad.net/bugs/580961
[15:51] <GunnarHj> happyaron: Needs to be checked by someone who speaks Chinese, I suppose. Could you check it out when language-selector has made it into the archive? Or should we just wait and see if bug reports drop in?
[15:51] <maxiaojun> this was the bug that i filed when i noticed that the unzip utf8 issue can be fixed, and soon I found debian fixed it already
[15:51] <TheLordOfTime> bdmurray: i think that debian 483290 got overlooked in favor of debian 682682...
[15:51] <caribou> xnox: here's bug #1248573 regarding the merge of libpng
[15:52] <happyaron> GunnarHj: I will check that later, just wonder when will it be made into archive?
[15:52] <GunnarHj> happyaron: Anytime (already in -proposed).
[15:52] <maxiaojun> i know a bug from end users would be more ideal, but many people don't understand the concept of utf8 zip, as both non-utf8 and utf8 zip both appeared broken
[15:52] <GunnarHj> happyaron: TIA
[15:53] <ev> bdmurray: yes! Could you please file an RT for it?
[15:53] <TheLordOfTime> maxiaojun: bdmurray and I already ID'd a bug about this, I think he was going to take a look at it...
[15:54] <happyaron> GunnarHj: I'll need to check them after working on ibus of saucy, and I think allow it in trusty archive right now is ok.
[15:54] <bdmurray> Yes, hopefully today but this week for sure
[15:54] <maxiaojun> ok
[15:54] <GunnarHj> happyaron: That's fine; no hurry.
[15:55] <seb128> happyaron, weird :/
[15:55] <seb128> happyaron, with the current SRUs and changing the ibus binding the keypress is fine here
[15:55] <seb128> happyaron, well, anyway, attente is looking at moving the key grabbing to unity, hopefully that should fix that
[15:56] <seb128> happyaron, btw do you know if we still need ibus to handle the keybinding or if we should just unset it from there?
[15:56] <happyaron> seb128: I think it's still needed (at least for now), there are missing functions from gsd/indicator-keyboard right now
[15:57] <maxiaojun> for the ibus issue, actually in my u12.04 untiy 2d, super+space works ...
[15:59] <happyaron> good to know, never tested that.
[15:59] <happyaron> seb128: do you think we need a session evaluating fcitx?
[15:59] <seb128> happyaron, what is missing? it seems to not make sense to have different pieces of code handling the same thing
[16:00] <seb128> happyaron, that would be good to have I guess, not sure we have enough people knowing both and the impact of a change to have a discussion though
[16:00] <happyaron> seb128: for example bug 1188509
[16:00] <pitti> chrisccoulson: did you see the chromium autopkgtest failure?
[16:00] <seb128> hate keyboard and input methods, hate hate hate
[16:00] <pitti> chrisccoulson: "Package 'libunity-webapps-chromium' has no installation candidate"
[16:01] <Laney> I pinged qengho about that already
[16:01] <seb128> happyaron, I've no clue what is right there, some days I wonder if we should go back to just have different indicators for layouts and ims rather than trying to combine both
[16:01] <happyaron> seb128: if so I can send some comparision material later, and do not have a dedicated session for it.
[16:01] <happyaron> :)
[16:01] <seb128> happyaron, and go back use libgnomekbd/libxklavier
[16:01] <pitti> Laney: ah, it's qengho now, sorry; thanks (the notification went to chrisccoulson)
[16:02] <Laney> He's been doing some sponsoring / uploading IIRC
[16:02] <chrisccoulson> hi :)
[16:02] <happyaron> seb128: well at least input method is having really bad experience right now. after installing saucy ISO, when I login to the user for the first time, ibus-ui-gtk3 crashed...
[16:02] <pitti> seb128: yeah, combining the two wasn't the best thing in the world; I still have my ears ringing from a friend of mine "you broke my keyboard" :)
[16:03] <seb128> happyaron, that's the bug assigned to you right?
[16:03] <pitti> seb128: (not your fault, I know)
[16:03] <seb128> happyaron, I asked you to have a look for a reason :p
[16:03] <qengho> pitti, Laney, hi hi.  Ah, autopktest. Hrm.  Thanks for that.
[16:03] <seb128> pitti, I pushed back on those changes for 3 cycles, we couldn't keep revert of GNOME code for ever
[16:03] <seb128> pitti, but yeah, situations sucks
[16:03] <pitti> I know
[16:03] <happyaron> seb128: ok, I didn't get a trace from apport and think that could be another issue, will try again.
[16:04] <pitti> qengho: https://jenkins.qa.ubuntu.com/view/Trusty/view/AutoPkgTest/job/trusty-adt-chromium-browser/13/ (started failing yesterday)
[16:04] <seb128> happyaron, the SRUs should improve things, if you set the keybinding to e.f ctrl-space things should be mostly working with current versions
[16:04] <happyaron> seb128: but seems installing SRUs solved it, I cleaned my user dir and it won't crash on login
[16:06] <pitti> qengho: (it also holds back systemd and gdk-pixbuf)
[16:08] <qengho> pitti: "it" holds back?
[16:08] <cjwatson> seb128: gnome-keyring> I suggest asking #webops to help investigate if you haven't already
[16:08] <Laney> qengho: http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html search for chromium
[16:09] <qengho> What does chromium-browser have to do with systemd?
[16:10] <seb128> cjwatson, done, thanks
[16:10] <Laney> Depends: libudev1
[16:21] <pitti> qengho: it seems to depend on udev and gdk-pixbuf
[16:21] <pitti> qengho: and we test reverse dependencies before allowing a package to go in (see http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html)
[16:21] <GunnarHj> Laney: I broke my promise and filed the u-s-s bug 1248349. ;-) Not directly related to "the prepend issue", but I still thought I'd let you know.
[16:22] <Laney> I saw it
[16:22] <GunnarHj> Laney: Ok.
[16:24] <maxiaojun> any news on the unzip utf8 filename issue?
[16:25] <Laney> GunnarHj: note that it's different in trunk
[16:26] <GunnarHj> Laney: Didn't know. Maybe I'd talk to attente about it?
[16:26] <Laney> try building a package from lp:ubuntu-system-settings yourself
[16:27] <Laney> it doesn't use that helper but I think achieves the same effect
[16:28] <GunnarHj> Laney: Ok, will do that. (But code reuse is still a good idea, isn't it?)
[16:28] <Laney> sure
[16:36] <saiarcot895> Just to check, the Depends field in debian/control can specify an upper-bound version and lower-bound version like so: package (>> minversion), package (<< maxversion), correct?
[16:37] <pitti> saiarcot895: yes
[16:40]  * maxiaojun is editing bug ...
[16:43] <TheLordOfTime> maxiaojun: bdmurray is kinda busy, he and many others have a lot of stuff to juggle... patience is a virtue, this won't be addressed as a priority above everything else...
[16:43] <maxiaojun> TheLordOfTime: so i'm doing my part of editing bug :)
[16:44] <pitti> rsalveti: FYI, I just updated your PARTNAME udev patch from not too long ago: http://paste.ubuntu.com/6371440/
[16:45] <pitti> rsalveti: upstream pointed out that /dev/disks/by-name/ is for FS labels, /dev/disks/by-partlabel/ is for that kind of thing (GPT uses that, too)
[16:45] <rsalveti> pitti: right, but the by-name was to match what android was using
[16:46] <pitti> rsalveti: do we depend on that? or can we move the ubuntu side to by-partlabel/?
[16:46] <rsalveti> I need to check if this patch is still useful, will take a look later today
[16:46] <rsalveti> yeah, will check
[16:46] <pitti> rsalveti: I just committed it to my local disk, no problem to revert/change it; but I just had it upstream reviewed, that's how it came up now
[16:46] <ogra_> rsalveti, pitti, i tried to drop it back when we discussed it last and iirc not all devices got a link then
[16:47] <pitti> no reason to completely drop the patch
[16:47] <ogra_> (which is why i didnt push for dropping it before release)
[16:47] <pitti> I'd just like to keep fs labels and partition labels apart, as they don't need to coincide
[16:47] <ogra_> well, it would be nice to use the same thing across phone and desktop ... whatever we end up with
[16:47] <rsalveti> yeah
[16:48] <pitti> not yet relevant for desktop -- the PARTNAME property is an Android kernel change for now
[16:49] <pitti> although https://www.kernel.org/doc/Documentation/block/cmdline-partition.txt already documents it (it's just not actually implemented in linux)
[16:49] <rsalveti> right
[16:59] <maxiaojun> my bug become a sru request now: https://bugs.launchpad.net/ubuntu/+source/unzip/+bug/1199239 no branch or debdiff yet though
[17:05] <tjaalton> hallyn_: did you mean adding libxext-dev fixed -qxl build on arm? for some reason it builds fine on debian
[17:08] <hallyn_> tjaalton: i mean taht the first failure in the build log is a missing file from that package;  and the porter-armhf box builds it fine in chroot, but the chroot has that package installed
[17:08] <hallyn_> so i'm not 100% sure that that's the only thing needed, but it is apparemtly needed
[17:09] <tjaalton> ok, and the debian package version wasn't pushed to git
[17:09] <tjaalton> though it looks like not missing a build-dep or anything
[17:10] <tjaalton> umm i mean the diff didn't add any build-dep
[17:10] <tjaalton> but yeah, I'll just add libxext-dev and sort the mess with guoliang
[17:20] <infinity> pitti: You around?
[17:23] <tjaalton> hallyn_: it's missing a check for xextproto > 7.1, I'll add it
[17:24] <hallyn_> tjaalton: cool, thanks, here's hoping that's it :)
[17:26] <tjaalton> yeah, src/qxl_drmmode.c includes dpms.h if the conditional for xextproto isn't set, and this was added in the new release (kms support)
[17:26] <tjaalton> fallback is dpms.h
[17:45] <slangasek> bdmurray: so in trusty, apport seems unwilling to submit bug reports to LP for me; do you know of anything that's changed to cause this?
[17:50] <slangasek> bdmurray: btw, I noticed from my upstart logs a bug in the use of watershed... watershed isn't on the path, it needs to be invoked as /lib/udev/watershed
[17:53] <bdmurray> slangasek: bug reports or crash reports?  for the latter see problem_types in /etc/apport/crashdb.conf
[17:54] <bdmurray> I think apport (reporting to Launchpad) has traditionally been disabled until alpha something
[17:58] <tjaalton> hallyn_: looks good, arm64 still fails but looks like some sort of asm error
[17:59] <hallyn_> tjaalton: yeah arm64 won't build anything for me :)
[17:59] <GunnarHj> Laney: My test with an u-s-s build from the trunk made it even worse. :(
[17:59] <hallyn_> tjaalton: thanks!  now i can try and get unity running in a container
[18:09] <tjaalton> nice :)
[19:06] <bdmurray> stgraber: could you have a look at bug 1196975 again?  The reporter responded a bit ago.
[19:08] <stgraber> bdmurray: yeah, I'm aware of that report, but it's not very high on my todo
[19:09] <stgraber> bdmurray: it's very far from a trivial change, fixing this properly would likely need some more heavy patching of isc-dhcp, so I prefer the status quo to rushing a patch in isc-dhcp
[19:10] <stgraber> anyway, moved to isc-dhcp for now
[19:11] <bdmurray> stgraber: great, thanks for looking at it
[19:32] <jibel> pitti, the problem with pykde4 is the latest upload of systemd adds a Breaks: consolekit (<< 0.4.6-1) to udev but consolekit 0.4.5-3.1ubuntu2 is available and libpolkit-qt-1-1 depends on consolekit
[19:33] <TheLordOfTime> bdmurray: around still?
[19:35] <jibel> pitti, output of apt-get install -o  Debug::pkgProblemResolver=1 software-properties-kde http://paste.ubuntu.com/6372301/
[19:45] <bdmurray> TheLordOfTime: yes
[19:45] <TheLordOfTime> bdmurray: i'm not super familiar with the bug, but with https://bugs.launchpad.net/ubuntu/+source/unzip/+bug/580961 are we certain 483290 is the correct Debian bug for this?
[19:46] <TheLordOfTime> because there seem to be two debian bugs on it..
[19:46] <TheLordOfTime> one with a fix implemented in Sid, and another without...
[19:47] <bdmurray> TheLordOfTime: I didn't read through all fo 580961 or the corresponding debian bug and just uploaded SRU fixes for the other bug
[19:47] <TheLordOfTime> bdmurray: ack.
[19:47] <bdmurray> but the change also resolves the test case in bug 580961
[19:49] <TheLordOfTime> bleh stupid IRC client...
[19:49] <TheLordOfTime> bdmurray: ah, okay, cool.
[20:26] <slangasek> bdmurray: bug reports; I have a modified /etc/apport/crashdb.conf to set problem_types = ['Bug', 'Package'], and it seems not to be talking to my browser
[21:07] <bdmurray> slangasek: it's missing, 'Crash'
[21:57] <slangasek> bdmurray: oh - is this a new behavior change?
[22:02] <bdmurray> slangasek: well before whoopsie apport would be just turned on or off, now for stable releases 'Crash" is removed from the list of problem_types to set to Launchpad
[22:02] <slangasek> hmm
[22:02] <slangasek> I don't remember ever seeing that value before
[22:03] <slangasek> hopefully we don't have something automatically editing the conffile on package upgrade
[22:04] <bdmurray> slangasek: http://bazaar.launchpad.net/~ubuntu-core-dev/ubuntu/saucy/apport/ubuntu/revision/2249
[22:04] <bdmurray> oh maybe if problem_types is not there it sends them all
[22:05] <slangasek> ah, ok
[22:05] <slangasek> so it seems my problem was mistakenly accepting the new version of the conffile on upgrade
[22:06] <slangasek> I wonder if we aren't at the point that we should stop flip-flopping this between devel and release... just leave it off by default and only turn bug reporting on for those who explicitly edit the file
[22:09] <bdmurray> I think it may have been discussed in the past and we were waiting for server side hooks in the error tracker, so that we can communicate with / get data from reporters.
[22:09] <slangasek> alright