[03:30] <lfaraone> mhall119: I submitted a merge proposal to django-openid-auth a few weeks ago. Is the project still active, slash where should I poke on that branch?
[04:08] <TheMuso> c/
[05:48] <apachelogger> pitti: apport uses core_pattern, getting the core dump from the kernel as argument?
[06:48] <pitti> Good morning
[06:49] <pitti> apachelogger: not as argument, the core dump gets fed into stdin; there are some macros like %p (pid)
[06:49] <apachelogger> ah
[06:49] <pitti> %s (signal number), %c (core limit)
[06:49] <apachelogger> I see
[07:04] <apachelogger> pitti: after poking around a bit I think that we'll end up having the core dump handled by apport anyway. the kde crash handler acts on the in-process signal of the crashing application so we don't have access to a core dump at that point. what I imagine right now is triggering a core dump after kde's crash handler (currently we exit()) and have apport itself handle the report business.
[07:04] <pitti> apachelogger: ah, if you do that you should just re-raise() the signal in the sighandler
[07:04] <pitti> apachelogger: that's the usual way that we do with firefox or LibO
[07:04] <apachelogger> raise(sig);
[07:05] <apachelogger> yeah, testing that right now
[07:05] <pitti> apachelogger: but I guess you want the KDE crash handler UI, right?
[07:05] <pitti> apachelogger: from that, can you somehow see (in the coredump or whereever) if the user agreed to report the issue?
[07:05] <apachelogger> that's the plan
[07:05] <pitti> apachelogger: oh, I guess you can conditionally re-raise() only if the user agreed to
[07:06] <apachelogger> oh, that's a good idea
[07:07] <pitti> apachelogger: then you can call /usr/share/apport/whoopsie-upload-all from an upstart job to process the initial .crash and create the .upload stamp
[07:07] <pitti> apachelogger: we do that in our CI machinery to auto-upload crashes during testing
[07:08] <pitti> apachelogger: we can discuss the details of that, but I think these are  the ready-made building blocks which ought to work for you
[07:08] <pitti> apachelogger: then we'll only report to whoopsie for reports that the user agreed to send, and you don't get a second UI
[07:09] <pitti> apachelogger: do you have a plan what to do for non-signal crashes? (package installation failures, python, etc.)
[07:10] <apachelogger> they go through apport, kde's kcrash handler only applies to actual kde applications
[07:10] <pitti> apachelogger: right, I meant in terms of UI
[07:10] <apachelogger> apport-kde
[07:11] <apachelogger> for UI consistency reasons I will probably have to fiddle with that a bit as well
[07:33] <penghuan> cjwatson: ping
[07:35] <penghuan> cjwatson: Can you take some time to have a look at my merge proposal about  https://code.launchpad.net/~penghuanmail/ubiquity/lp.1197220/+merge/195712
[08:08] <dholbach> good morning
[08:40] <OdyX> tkamppeter_: Hi. Did you see http://bugs.debian.org/731658 ? It would be nice to avoid using PATH_MAX globally. Your advice on the patch would be nice too...
[09:54] <brendand> does anyone know why my qt plugin (with suffix .so) might have cpython-33m-x86_64-linux-gnu inserted into its name?
[09:56] <apachelogger> pitti: to not discriminate against !kapplications I think we shouldn't simply assume that every report was actually accepted by the user. instead I am thinking about having specific stamps set by the kde crash handler with the suffixes .drkonqi-accept or .drkonqi-reject. former would lead to UI-less upload, latter would discard the entire report as the user didn't want an automatic report. reports without either will bring up the apport UI. any
[09:56] <apachelogger>  opinion on possibly supporting this by apport in general? or should I simply limit support for ui-less accept/reject to kubuntu tools?
[09:57] <pitti> apachelogger: no, you shouldn't assume it; my thought was that the signal handler would know whether drkonqui accepted the crash or not, and only re-raise if it was accepted
[10:00] <apachelogger> hm
[10:00] <apachelogger> pitti: and write a .upload file immediately I guess?
[10:01] <pitti> apachelogger: no, that won't work; you need to add package and other information to it, i. e. call sr/share/apport/whoopsie-upload-all or do the equivalent steps
[10:01] <pitti> "usr/..."
[10:01] <apachelogger> right, that's why I was thinking about those additional stamps
[10:01] <apachelogger> as we need to set the reports apart as already-approved or already-rejected
[10:01] <pitti> apachelogger: where would you create the stamps, if not in the signal handler?
[10:02] <apachelogger> pitti: in the signal handler :P
[10:02] <pitti> apachelogger: then skip the stamps and just don't raise() if  the user doesn't want to report
[10:02] <pitti> apachelogger: that saves you needlessly calling apport and creating the .crash (which is quite CPU intense), and the stamp handling
[10:02] <apachelogger> true, we'd still need and approved/accept stamp though
[10:03] <pitti> why?
[10:03] <pitti> oh, for non-KDE crashes
[10:03] <apachelogger> aye
[10:03] <pitti> well, that stamp is .upload
[10:03] <apachelogger> -> [11:00:18] <apachelogger> pitti: and write a .upload file immediately I guess?
[10:04] <apachelogger> that's what I meant there ;)
[10:04] <pitti> apachelogger: for that, can you teach drkonqui to either call a few python functions or call a script which adds the necessary information to the .crash?
[10:04] <pitti> argh no, at that point the .crash doesn't even exist yet
[10:04] <pitti> meh
[10:05] <apachelogger> I know, it's headache material ^^
[10:05] <pitti> we might put that into whoopsie itself, it could do the information collection when needed
[10:06] <pitti> w/when/if/
[10:08] <apachelogger> pitti: that'd be cool
[10:12] <ev> pitti, apachelogger: branches welcome :)
[10:17] <apachelogger> ev: oh, btw, how does the metrics stuff work?
[10:18] <ev> apachelogger: which metrics stuff is this?
[10:18] <apachelogger> ev: com.ubuntu.WhoopsiePreferences.SetReportMetrics
[10:19] <seb128> xnox, https://bugs.launchpad.net/ubuntu/+source/usb-creator/+bug/1259111 is probably yours (new since your uploaded on friday according to e.u.c)
[10:19] <xnox> seb128: argh =) thanks.
[10:19] <seb128> yw ;-)
[10:20] <ev> apachelogger: that's not wired up to anything yet
[10:20] <apachelogger> I see
[10:20] <xnox> seb128: i wonder how come i am not subscribed to usb-creator bugs.... now subscribed
[10:20] <ev> apachelogger: https://wiki.ubuntu.com/ErrorTracker#Invitation_for_metrics_collection
[10:21] <seb128> ev, we have been consistently tackling highest reports for 13.10 since release, and they are dropping off the list, it's weird that the curve doesn't reflect more that...
[10:21] <apachelogger> ev: I'll hide the UI option for the time being then
[10:21] <seb128> xnox, seems like a good idea if you are the maintainer nowadays ;-)
[10:24] <Laney> some cool guy wrote a script to automatically subscribe you to packages you upload
[10:25] <seb128> does it unsubscribe you have <n> days?
[10:25] <Laney> yep
[10:25] <seb128> cool
[10:25] <seb128> how is that called/where is it?
[10:25] <Laney> cron
[10:26]  * Laney tries to remember where it is
[10:26] <xnox> Laney: i found that it would randomany unsubscribe my custom subscriptions....
[10:26] <ev> seb128: we need to re-run the calculation to generate that graph, I suspect. Adding something into Asana to track this
[10:27] <seb128> ev, thanks
[10:27] <Laney> you didn't report the bug?!?!?!
[10:28] <xnox> Laney: well, i didn't backup my existing subscriptions, now did I?! =)
[10:29] <Laney> it's supposed to not subscribe you if you already are
[10:29] <Laney> ho hum
[10:32] <xnox> Laney: where was that script again? i clearly haven't used it since the incident....
[10:32] <Laney> lp:~laney/+junk/lp-subscribe-uploads
[10:33] <Laney> it was fairly fire and forget, but I'd still merge patches / fix bugs
[10:40] <Laney> bah
[10:40] <Laney> screen has started segfaulting
[11:01] <cjwatson> penghuan: done
[11:02] <penghuan> cjwatson:thx
[11:03] <seb128> Laney, let's maybe ask here?
[11:03] <seb128> doko_, what's the rational for changes like
[11:03] <seb128> -	dh $@ --with autotools_dev
[11:03] <seb128> +	dh $@ --with autoreconf
[11:03] <seb128> (Laney was trying to get that harfbuzz diff to Debian but pochu wants to understand what it's fixing/the rational)
[11:05] <cjwatson> seb128: does a better job of handling new ports - there's a libtool fix that that picks up
[11:05] <seb128> cjwatson, do we have a description of "better job" for those who want to understand want issue it fixes in practice?
[11:05] <seb128> e.g a link to an email/wiki/bug reference?
[11:06] <cjwatson> man dh_autoreconf ? :-)
[11:06] <Laney> mmm, that fix doesn't appear to be in Debian
[11:07] <cjwatson> seb128: dh_autotools-dev_* only updates config.guess/config.sub
[11:07] <seb128> cjwatson, fair enough, thanks ;-)
[11:07] <cjwatson> seb128: dh_autoreconf does a full update of all the autotools output - so it also picks up bug-fixes in other parts of that toolchain
[11:07] <seb128> cjwatson, thanks, that's the sort of explanation I was after, and it makes sense ;-)
[11:08] <cjwatson> seb128: dh_autoreconf is more complete, but it also requires more care, because it's often the case that packages' autotools source requires some massaging before it can be regenerated
[11:08] <seb128> yeah, I know about that :p
[11:08] <Laney> We were more after the specific rationale for this batch of changes; the libtool hint was enough
[11:09] <cjwatson> seb128: dh_autoreconf is a superset of dh_autotools-dev_* only if libtool is used (I think that's right) - there are some edge cases that are more complicated, so it's definitely not a "drop it in automatically" kind of thing
[11:10] <seb128> cjwatson, thanks
[11:10] <seb128> we have been using dh-autoreconf for all the desktop stuff for a while
[11:10]  * cjwatson nods
[11:10] <seb128> (especially when we had launchpad integration changes that needed to update configure and other stuff)
[11:11] <seb128> I was just unsure how to "sell" it to others/not familiar enough with dh_autotools-dev to explain the difference
[11:11] <seb128> as Laney said, we have what we need to forward that fix to Debian ;-)
[11:11] <xnox> cjwatson: slangasek: any updates re https://bugs.launchpad.net/ubuntu/+source/sysvinit/+bug/1184006 branches ?
[11:11] <Laney> it was more "why specifically is this interesting for this package now"
[11:11] <Laney> not "why is dh-autoreconf good in general?"
[11:12] <xnox> Laney: to get libtool goodness =)
[11:12] <Laney> got it
[11:12] <Laney> ta
[11:16] <cjwatson> xnox: not something I've had time to look at for some time
[11:17] <cjwatson> (nor expect to before EOY)
[11:18] <xnox> cjwatson: in that case no outstanding merge proposals for ubiquity, upload time? (it has quite a few changes staged)
[11:19] <Laney> xnox: want to review the remaining libtimezonemap changes? :-)
[11:19] <cjwatson> xnox: up to you, I wasn't touching that due to the note at the top of the changelog ...
[11:21] <xnox> cjwatson: yeah, that's all fixed now.
[11:21] <xnox> Laney: =)
[11:22] <Laney> I did a chunk but there's still a few left
[11:22] <Laney> changes what are more relevant to ubiquity's use of it
[11:32] <xnox> doing a package merge "cross-cross merge encountered" => please work it all out =)))
[11:54] <xnox> cjwatson: do you mind if I do a debhelper merge, or would you rather do it? (i have a dep-wait on 9.20131104 for debian bug #728620)
[11:55]  * xnox goes to check if emacsen-common is merged.
[11:55] <xnox> yeap, we do have the new enough emacsen.
[11:59] <cjwatson> xnox: go for it
[11:59] <xnox> ack.
[12:05] <tkamppeter> OdyX, this with PATH_MAX was simply overlooked when merging foomatic-rip into cups-filters. I will take your patch upstream. Thanks for the patch.
[12:27] <tkamppeter> OdyX, fixed upstream, BZR rev. 7140.
[12:28] <mlankhorst> how often do packages move from NEW to DONE?
[12:29] <cjwatson> no fixed schedule, depends on human attention
[12:30] <cjwatson> assuming you're asking about mesa, accepted now
[12:33] <mlankhorst> ah
[12:33] <mlankhorst> i was curious since arm64 was accepted
[12:34] <cjwatson> mlankhorst: I assume it was just the first one in place
[12:35] <cjwatson> mlankhorst: oh, no, it's because arm64 doesn't build libxatracker*
[12:35] <cjwatson> and those were the new binaries
[12:35] <mlankhorst> ah right, ofc :)
[12:36] <cjwatson> wait, what?  sbuild is seriously in universe?
[12:36] <cjwatson> that I did not expect
[13:04] <tseliot> didrocks: hey, bbswitch is now ready for promotion (bug 1255583)
[13:04] <didrocks> tseliot: thanks, please just reassign to me, on other stuff, will do later on
[13:04] <tseliot> didrocks: sure, thanks
[13:28] <mlankhorst> doko: hey, can you check if needing to suppress building gallium and egl is still needed? We're no longer carrying the patches in 10.0 that broke things
[13:30] <doko> mlankhorst, I'd like to wait for a fast reliable native system. don't want to setup my cross hacks again to build this
[13:31] <mlankhorst> ok
[13:39] <mlankhorst> doko: but we already build arm64 right? you could just test the package from debian-experimental on arm64
[13:47] <OdyX> tkamppeter: great, thanks. I hope it won't break anything then. Uses of PATH_MAX should be replaced though, see http://www.gnu.org/software/hurd/community/gsoc/project_ideas/maxpath.html ...
[14:22] <alkisg> highvoltage: /etc/xdg/menus/applications.menu is a mess in Trusty, the gnome-session-flashback is ruined with that. If I replace it with the version from Precise, then it's fine.
[14:23] <alkisg> ...is that also used in gnome-shell? Can we ship the version from Precise in order to have sane menus?
[14:24] <alkisg> I could create a wrapper package e.g. gnome-session-flashback-oldmenus that dpkg-diverts it, but wouldn't it be better to solve it upstream, or at least in debian?
[14:25] <alkisg> (or stgraber ^)
[14:26] <seb128> alkisg, what's the issue exactly? and no you can't put the old content back, open an upstream bug if GNOME screwed it up for other desktops, they did some tweaking for gnome-shell I think
[14:27] <alkisg> seb128: the new menu structure splits the menus in a non-sensible way, half of the things that were in accessories have now gone to utilities,
[14:27] <seb128> mardy, hey, did you see bug #1258578? seems a new issue in trusty with the signon update, it's one of the most reports errors there
[14:28] <alkisg> there's a sundry submenu, a full "others" menu... and some translations are the same, so e.g. in greek I see two same entries for "Accessories" and "Utilities", "Βοηθήματα" for both of them
[14:28] <alkisg> The settings submenus are all wrong.. too many things are wrong to list them in order
[14:29] <alkisg> I tried to find the logic behind the new organization, but I couldn't find any, and I don't use gnome-shell nor unity, so I don't know if those entries make more sense there...
[14:29] <alkisg> (logic ==> I meant the rationale, via googling...)
[14:30] <alkisg> The .desktop files in /usr/share/applications are more or less unchanged, it's just that /etc/xdg/menus/applications.menu file that messes up everything...
[14:30] <seb128> alkisg, you are using trusty? https://git.gnome.org/browse/gnome-menus/commit/?h=gnome-3-8&id=b89833d78a9ab43f1fea1d01cd233551d47f08a7 was supposed to fix the "others" category issue
[14:31] <alkisg> Yup I'm using trusty, let me check the bug report, but the "others" submenu is only 5% of the problems there
[14:31] <seb128> alkisg, you should open upstream gnome-menus bugs reports for each of the specific issues you have, you might want to open launchpad bugs corresponding to those as well
[14:31] <seb128> but we are not going to revert upstream work randomly
[14:32] <alkisg> seb128: thanks, will do, but could you help me a bit to understand the rationale? Are those menus used for gnome-shell nowadays?
[14:32] <seb128> we need to understand the changes, why they are there and what we can do that accomodate gnome-shell uses and other desktops as well
[14:32] <seb128> alkisg, https://git.gnome.org/browse/gnome-menus/commit/?h=gnome-3-8&id=36d5d699d7d4193a1b3d84777566466326f78b19
[14:32] <seb128> read https://bugzilla.gnome.org/show_bug.cgi?id=694131 I guess
[14:33] <alkisg> Thanks, I think that last one contains most of the changes
[14:34] <alkisg> Hehe, "Uhm, except for the first patch, the series was not actually meant to be committed literally."
[14:35]  * alkisg wonders if there's any way to dump the effective menu layout to attach it to bug reports
[14:38] <JordiGH> How do I get the debian/control of this package? https://launchpad.net/~octave/+archive/unstable/+packages
[14:38] <alkisg> Is mate-desktop going to be available in Trusty? Maybe they've already solved this problem there...
[14:38] <JordiGH> I mean, other than adding it to my apt.sources and doing apt-get source.
[14:38] <pitti> jibel: download and unpack https://launchpad.net/~octave/+archive/unstable/+files/octave_3.7.7-0%7Eppa1%7Eraring1.debian.tar.gz
[14:38] <pitti> sorry
[14:39] <pitti> JordiGH: ^
[14:39] <pitti> jibel: wrong nick, sorry
[14:39] <JordiGH> Man, I wish there was a web interface to it like packages.debian.org :-/
[14:39] <JordiGH> pitti: Okay, thanks.
[14:39] <sladen> alkisg: /usr/lib/libdbusmenu/dbusmenu-dumper
[14:39] <pitti> JordiGH: there (kind of) is for ubuntu packages, but not for PPAs
[14:42] <alkisg> sladen: thanks, I installed libdbusmenu-tools, will check that in a while.
[14:42]  * alkisg waves...
[14:43] <seb128> sladen, he was asking about xdg .desktop menus, I doubt that's the right tool...
[14:44] <JordiGH> pitti: Alright, thanks for your help.
[14:45] <mhall119> lfaraone: I think jamesh is still running that project, but I can take a look at the mp
[15:17] <lfaraone> mhall119: awesome, thanks!
[15:18] <mhall119> lfaraone: have a link to the MP?
[15:20] <lfaraone> mhall119: https://code.launchpad.net/~lfaraone/django-openid-auth/custom_response/+merge/195845
[15:27] <mhall119> lfaraone: can you add tests that check the value of openid_response in render_failure?
[15:29] <lfaraone> mhall119: sure.
[15:29] <mhall119> thanks lfaraone
[16:17] <bdmurray> seb128: were you going to do the merging / upload of the apturl fix for bug 1050826?
[16:17] <seb128> bdmurray, hey, yes, I just got a busy monday and didn't get to do it yet ;-)
[16:17] <seb128> bdmurray, thanks for the review!
[16:19] <hallyn_> is there a simple way to get do-release-upgrade (for a test) to ignore the fact that some packages are unauthenticated?
[16:20] <bdmurray> hallyn_: I don't think so
[16:20] <hallyn_> drat
[16:21] <bdmurray> hallyn_: what exactly are you trying to do?
[16:22] <hallyn_> test whether a candidate qemu for trusty woudl cleanly upgrade in lts-to-lts
[16:23] <xnox> hallyn_: i do schroot into precise & add sources as appropriate and do a dist-upgrade.
[16:23] <rbasak> hallyn_: you can just update sources.list and dist-upgrade I think
[16:23] <xnox> hallyn_: also you can run piuparts to do automated lts->lts upgrades/downgrades/install/remove/reinstall and a bunch of other tests.
[16:24] <xnox> hallyn_: piuparts can work with pbuilder tarballs or schroots, if I remember correctly.
[16:26] <hallyn_> rbasak: no, but i can ctrl-z and re-insert my custom entries.  that bit is fine :)
[16:27] <hallyn_> piuparts?  i've heard of it...
[16:27] <hallyn_> sounds like maybe what i need
[16:28] <hallyn_> xnox: is there a good wiki link showing simple usage?
[16:28] <xnox> hallyn_: it's running automatically against the whole debian archive and reports problems to PTS.
[16:28] <xnox> hallyn_: https://piuparts.debian.org/
[16:29] <xnox> hallyn_: and links from there https://piuparts.debian.org/doc/README_1st.html https://piuparts.debian.org/doc/piuparts.1.html
[16:29] <hallyn_> well, it does seem to be workign ok though (just drops to complaints about trusty packages not installed)
[16:29] <hallyn_> xnox: ok, thanks.  i'll definately have to add that to my repertoire
[16:48] <hallyn_> xnox: how do you run it for lts-to-lts upgrades?
[16:48] <xnox> hallyn_: i can't remember for sure, but the semantics was to specify the base release (e.g. precise) and the target releases, or even a just compiled binaries.
[16:49] <xnox> hallyn_: it was a long time since i used it last =) i know I am bad.
[16:50] <hallyn_> xnox: oh - np, i just figured you used it daily.  thanks!  i'll figure it out
[17:06] <slangasek> xnox: https://bugs.launchpad.net/ubuntu/+source/sysvinit/+bug/1184006> none, sorry; haven't had time to straighten out the bugs cjwatson pointed out
[17:06] <slangasek> xnox: if you're merging debhelper, please take care to preserve the versioned dep on sysv-rc that joeyh dropped recently, as it still applies for precise upgrades in Ubuntu
[17:07] <xnox> slangasek: thanks.....
[17:07]  * xnox goes to reupload debhelper i think.
[17:08] <mlankhorst> hm, why is mesa still in -proposed ? (it has a new binary libxatracker2)
[17:11] <xnox> slangasek: looks good? http://paste.ubuntu.com/6546703/
[17:11] <xnox> darn, wrong DEB_NAME
[17:13] <slangasek> xnox: it looks familiar, and if it's a straight revert I trust that it's fine :)
[17:13] <xnox> ack.
[17:13] <cjwatson> trying: mesa
[17:13] <cjwatson> skipped: mesa (68 <- 160)
[17:13] <cjwatson>     got: 26+0: i-26
[17:13] <cjwatson>     * i386: kubuntu-active, xserver-xorg-video-all, xserver-xorg-video-vmware
[17:13] <cjwatson> mlankhorst: ^-
[17:13] <cjwatson> http://people.canonical.com/~ubuntu-archive/proposed-migration/update_output.txt
[17:13] <mlankhorst> oh right
[17:14] <mlankhorst> fixed :p
[17:28] <jibel> slangasek, could you review the MP attached to bug 1257305 ? I think it is the only change between the version in the distro and upstream so it is probably better to directly release latest upstream revision.
[17:34] <slangasek> jibel: I've seen it, and the change is obviously correct; but I'm more concerned about getting sbsigntool upstream sorted out so we can get proper releases
[17:34] <slangasek> jibel: if you want to upload it be my guest
[17:36] <jibel> slangasek, thanks but I cannot upload :)
[17:41] <brendand> hi, i'm trying to build a package containing a qt plugin whose target is 'libgui-engine'
[17:42] <brendand> this builds as 'libgui-engine.so'
[17:43] <brendand> but when i install the package, it turns into 'libgui-engine.cpython-33m-x86_64-linux-gnu.so'
[17:43] <brendand> i can't figure out how python comes into it
[17:45] <xnox> brendand: did you install the .so into /usr/lib/python* ?
[17:45] <slangasek> jibel: ok.  are you ok to have this wait until I have a chance to get a poper upstream release sorted?
[17:45] <slangasek> jibel: (which will be a couple weeks at least)
[17:45] <brendand> xnox, no it's installed to /usr/lib/checkbox-gui/plugins
[17:47] <brendand> xnox, i think i just realised :/
[17:47] <brendand> xnox, for some reason i put ${python3:Depends} in the binary packages Depends
[17:51] <xnox> brendand: don't do that =) or do override_dh_python3 and use exclude to exclude that path and/or that package
[17:51] <xnox> such that they are untouched.
[17:51] <brendand> xnox, well having it serves no purpose so i remove it :)
[17:51] <brendand> xnox, dumb stuff that creeps in thanks to the evils of Ctrl+C/V
[17:53] <slangasek> Laney: I hear you may know something about libwebkitgtk being broken; once it's fixed, can you let me know and/or give back gnome-online-accounts for building?
[17:53] <cjwatson> slangasek: I notice that seb128 has an update building at the moment
[17:53] <Laney> slangasek: I expect it's just du
[17:53] <Laney> that
[17:53] <slangasek> ok
[17:54] <Laney> uninstallable due to transition etc
[17:57] <slangasek> xnox: do you know anything about the jquery/flot stuff on http://package-import.ubuntu.com/status/ ?  It is not well-behaved and makes my browser angry
[17:59] <xnox> slangasek: with my limited W3C skillz, it appears to me entirely unused?!
[17:59] <slangasek> hmm
[17:59] <slangasek> isn't it used to create the graphs at the bottom of the page?
[17:59] <xnox> slangasek: also it looks fine in my web-browser.
[17:59]  * xnox uses Google Chrome
[17:59] <slangasek> I didn't say it doesn't /look/ ok :)
[18:00] <slangasek> but it gets itself into some stupid busy loop (in firefox) that eventually causes firefox to kill it as a runaway js process
[18:00] <xnox> slangasek: ouch, that graph is sure a good way to generate..... every client does it, instead of server side.
[18:01] <slangasek> xnox: and it is used, <div id="queue_graph" style="width:600px;height:300px"></div>[...]$.plot($("#queue_graph"), [[ [...]
[18:01]  * xnox ponders to write a javascript bitcoin miner and infect parked domains with it.
[18:01] <xnox> slangasek: yeah spotted it now.
[18:01] <xnox> slangasek: i can look into splitting a graph into a separate page, would that work?
[18:02] <slangasek> xnox: bitcoin miner> hahaha
[18:02] <slangasek> xnox: sure, splitting it would work
[18:05] <shadeslayer> I'm curious as to what's the long term plan with logind
[18:06] <shadeslayer> will Ubuntu maintain logind with upstart integration? ( I'm mostly interested in the dbus interfaces )
[18:06] <shadeslayer> or will upstart have it's own user session namespace ?
[18:07] <xnox> shadeslayer: what do you mean? logind as a daemon is here to stay, as is with compatible dbus API as everywhere else.
[18:07] <shadeslayer> xnox: well, that's my question, will logind be dropped in the future or is it going to stay
[18:07] <xnox> shadeslayer: we do have a shim in place, but that should be mostly opaque. If there bugs, file them on launchpad as usual.
[18:08] <xnox> shadeslayer: lennart didn't write a replacement for logind yet, until that happens it's here to stay.
[18:08] <shadeslayer> xnox: there's just a minor bug, some KDE applications ask systemd for the systemd version, which isn't implemented on the dbus interface in ubuntu
[18:08] <xnox> shadeslayer: (remember that logind is rewrite of consolekit)
[18:08] <xnox> shadeslayer: those applications are wrong, they should be checking for presence of the _logind_ not of _systemd_.
[18:09] <xnox> shadeslayer: loads of packages were fixed by pitti, and the upstrem "sd_*" static files were updated as well.
[18:09] <shadeslayer> xnox: the idea I got was to check if the version is greater than a certain version to check if the interface was implemented
[18:09] <xnox> shadeslayer: at the time all applications were doing a check " if systemd; then do logind stuff; fi" instead of "if logind; then do logind stuff; fi"
[18:10] <xnox> shadeslayer: one should check the interface presence, rather than version numbers.
[18:10] <shadeslayer> *nod*
[18:10] <xnox> shadeslayer: i believe all compatible interfaces are implemented, check with e.g. d-feet if the needed interfaces are implemented.
[18:10] <shadeslayer> I'll try and refactor the code that way
[18:11] <xnox> shadeslayer: do you have example / package? you could ask pitti as he did write/upstream a lot of patches where bad assumptions were made upstream.
[18:11] <slangasek> introducing, duck typing for dbus
[18:11] <shadeslayer> xnox: sure, kde-workspace, powerdevil checks for systemd version
[18:11] <xnox> shadeslayer: or he can better consult which interfaces are available.
[18:12] <xnox> shadeslayer: please open a bug about it & subscribe myself and pitti to it. I'm getting annoyed with this "logind is not a freedesktop specification"
[18:12] <shadeslayer> xnox: actually I'm already fixing it :)
[18:13] <xnox> shadeslayer: good, please upstream it as well =)
[18:13] <slangasek> Laney, cjwatson: the update being built is for which package?
[18:14] <shadeslayer> ofcourse, already had a discussion with upstream, and the question that came out was "Will ubuntu be sticking to logind or will they be implementing something of their own, in which case it makes sense to write a ubuntu specific backend"
[18:14] <shadeslayer> well, s/ubuntu specific/upstart specific/
[18:14] <slangasek> shadeslayer: writing a different interface would be silly; we deliberately made logind work on upstart
[18:15] <slangasek> and even if the logind code base became unmaintainable on top of upstart, there's no reason to implement a distinct API
[18:15] <shadeslayer> *nod*, thanks for that
[19:11] <mcpierce> Hi, all. Looking for some guidance on becoming a Ubuntu packager. I've got experience with packaging on Fedora.
[19:20] <Noskcaj> When can i expect http://qa.ubuntuwire.com/bugs/rcbugs/ to have trusty listed? Is there anything i can do to speed it up?
[19:45] <mlankhorst> mesa 10 in trusty soon, enjoy
[19:45] <Laney> slangasek: webkitgtk
[19:46] <slangasek> Laney: ah, thanks; somehow I thought the problem was in webkit itself
[19:46] <Laney> hrm, that should be removed
[19:46] <Laney> I thought Seb took care of that; will sort it out in the morning
[19:46] <Laney> (webkitgtk supersedes it)
[19:46] <slangasek> ok
[20:10] <hallyn_> could someone push the sru fix for https://bugs.launchpad.net/ubuntu/+source/qemu/+bug/1243403 into saucy's qemu?
[20:13] <stgraber> hallyn_: I'll do an SRU round in a few minutes. (unless infinity is planning one, I believe it's his SRU day)
[20:16] <hallyn_> stgraber: thx
[20:57] <slangasek> xnox: so alternatively, we could axe the 'refresh' at the top of http://package-import.ubuntu.com/status/, which would stop the script from trying to graph n million data points every 10 minutes
[21:25] <slangasek> utlemming: hmm, your mail suggests that UEFI support comes in the form of a separate disk image - how come?
[21:26] <utlemming> slangasek: UEFI and BIOS/GPT come together
[21:26] <slangasek> why is that an additional image, instead of changes to the existing image?
[21:27] <slangasek> an image can have both a GPT and an MBR partition table on it
[21:27] <utlemming> a couple of reasons
[21:27] <utlemming> the biggest is that we wanted to preseve root being the first partition. Hybrid images make the difficult
[21:28] <utlemming> the second reason is that there is the question of supporting a hybrid mbr/gpt image
[21:28] <utlemming> after consulting with cjwatson, he strongly advised against going that route
[21:28] <slangasek> hmm, ok
[21:29] <utlemming> for 14.10, we are going to talk about making the UEFI image the cloud image default and droping the BIOS/MBR disk image
[21:57] <slangasek> xnox: the straightforward proposal: https://code.launchpad.net/~vorlon/udd/no-auto-refresh/+merge/198320
[21:58] <xnox> slangasek: ack. will pull and deploy it tomorrow. afk at the moment. =)
[21:58] <slangasek> ;)
[22:55] <infinity> awe_: Why are we adding -dbg packages in Ubuntu deltas when we prefer ddebs? (urfkill, in this case)
[22:55] <infinity> cyphermox: ^
[22:55] <cyphermox> infinity: useful in a ppa
[22:55] <cyphermox> if you feel we really shouldn't ...
[22:55] <cyphermox> I'm sending that to debian too btw
[22:56] <infinity> cyphermox: If it's going to end up in Debian too, fine.  But it seems like a silly delta for us to carry when we'd really rather get rid of all -dbg packages, not have more. :)
[22:56] <cyphermox> infinity: sure :)
[22:57] <cyphermox> I don't feel strongly for it, though it does tend to be useful when you build things in a PPA
[22:57] <infinity> You can get PPAs with ddebs.
[22:57] <cyphermox> you can?
[22:57] <infinity> (To be fair, not a default option, cause we don't want all PPAs having massive ddebs in them)
[22:57] <cyphermox> ah
[22:57] <cyphermox> a matter of asking the right magician
[22:59] <awe_> cyphermox, we probably should fix ofono too
[22:59] <infinity> Anyhow, if you're pushing this delta to Debian and it will, thus, no longer be a delta, I'm fine with processing these from binNEW.
[22:59] <cyphermox> awe_: you mean re: dbg packages?
[22:59] <awe_> yes
[22:59] <cyphermox> infinity: I'll strongly suggest it to the debian maintainer.
[23:00] <cyphermox> (for what my opinion really matters)
[23:00] <cyphermox> awe_: you mean removing them?
[23:00] <infinity> This does remind me that I need to revisit the Debian ddeb proposal, apply some sanity to it, and get them moving in the right direction.
[23:00] <infinity> So we can make -dbg a thing of the past everywhere.
[23:01] <cyphermox> infinity: happy to help. I need more work in Debian to eventually do NM process.
[23:01] <awe_> cyphermox, I actually don't know enough about the problem to speak intelligently about it.  However if getting rid of -dbg packages is a goal, then we should probably do so for ofono too
[23:01] <geofft> infinity: out of curiosity, is that doable without discarding binary uploads, which seems to be a political quagmire?
[23:01] <awe_> right now I'm neck deep in modem power code
[23:01] <cyphermox> awe_: just pull the plug when you feel like it
[23:01] <infinity> awe_: Getting rid of them is a long-term goal, not something we should carry a delta against Debian for, it's not worth the merging effort.
[23:02] <cyphermox> awe_: or I'll fix the debian side of things for ofono
[23:02] <infinity> awe_: Some day, we want them gone from both Debian and Ubuntu, and ddebs to rule the world.
[23:02] <awe_> ok
[23:02] <cyphermox> I think it might already be a delta from us
[23:02] <awe_> yea, pretty sure it is
[23:02] <infinity> geofft: It's doable with binary uploads.
[23:02] <awe_> ( ie. we added the -dbg package for ofono )
[23:02] <infinity> geofft: Though I'm firmly on the "source uploads forever" side of that debate too. :P
[23:02] <geofft> By asking folks to upload ddebs too?
[23:02] <cyphermox> I'll look, and apply the right thing if needed
[23:03] <infinity> geofft: They'd be an artifact of the build process and referenced in .changes, so nothing extra to do.  No different than a package that produces both debs and udebs today.
[23:04] <geofft> Neat.