/srv/irclogs.ubuntu.com/2013/12/09/#ubuntu-devel.txt

=== shuduo_afk is now known as shuduo
=== shuduo is now known as shuduo_afk
=== shuduo_afk is now known as shuduo
lfaraonemhall119: 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?03:30
TheMusoc/04:08
apacheloggerpitti: apport uses core_pattern, getting the core dump from the kernel as argument?05:48
pittiGood morning06:48
pittiapachelogger: not as argument, the core dump gets fed into stdin; there are some macros like %p (pid)06:49
apacheloggerah06:49
pitti%s (signal number), %c (core limit)06:49
apacheloggerI see06:49
apacheloggerpitti: 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
pittiapachelogger: ah, if you do that you should just re-raise() the signal in the sighandler07:04
pittiapachelogger: that's the usual way that we do with firefox or LibO07:04
apacheloggerraise(sig);07:04
apacheloggeryeah, testing that right now07:05
pittiapachelogger: but I guess you want the KDE crash handler UI, right?07:05
pittiapachelogger: from that, can you somehow see (in the coredump or whereever) if the user agreed to report the issue?07:05
apacheloggerthat's the plan07:05
pittiapachelogger: oh, I guess you can conditionally re-raise() only if the user agreed to07:05
apacheloggeroh, that's a good idea07:06
pittiapachelogger: then you can call /usr/share/apport/whoopsie-upload-all from an upstart job to process the initial .crash and create the .upload stamp07:07
pittiapachelogger: we do that in our CI machinery to auto-upload crashes during testing07:07
pittiapachelogger: we can discuss the details of that, but I think these are  the ready-made building blocks which ought to work for you07:08
pittiapachelogger: then we'll only report to whoopsie for reports that the user agreed to send, and you don't get a second UI07:08
pittiapachelogger: do you have a plan what to do for non-signal crashes? (package installation failures, python, etc.)07:09
apacheloggerthey go through apport, kde's kcrash handler only applies to actual kde applications07:10
pittiapachelogger: right, I meant in terms of UI07:10
apacheloggerapport-kde07:10
apacheloggerfor UI consistency reasons I will probably have to fiddle with that a bit as well07:11
=== geser_ is now known as geser
penghuancjwatson: ping07:33
penghuancjwatson: Can you take some time to have a look at my merge proposal about  https://code.launchpad.net/~penghuanmail/ubiquity/lp.1197220/+merge/19571207:35
=== ikonia_ is now known as ikonia
dholbachgood morning08:08
=== work_alkisg is now known as alkisg
OdyXtkamppeter_: 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...08:40
ubottuDebian bug 731658 in cups-filters "cups-filters FTBFS on kfreebsd, varying values of PATH_MAX" [Serious,Open]08:40
=== dholbach_ is now known as dholbach
=== shuduo is now known as shuduo_afk
brendanddoes anyone know why my qt plugin (with suffix .so) might have cpython-33m-x86_64-linux-gnu inserted into its name?09:54
apacheloggerpitti: 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. any09: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:56
pittiapachelogger: 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 accepted09:57
apacheloggerhm10:00
apacheloggerpitti: and write a .upload file immediately I guess?10:00
pittiapachelogger: 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 steps10:01
pitti"usr/..."10:01
apacheloggerright, that's why I was thinking about those additional stamps10:01
apacheloggeras we need to set the reports apart as already-approved or already-rejected10:01
pittiapachelogger: where would you create the stamps, if not in the signal handler?10:01
apacheloggerpitti: in the signal handler :P10:02
pittiapachelogger: then skip the stamps and just don't raise() if  the user doesn't want to report10:02
pittiapachelogger: that saves you needlessly calling apport and creating the .crash (which is quite CPU intense), and the stamp handling10:02
apacheloggertrue, we'd still need and approved/accept stamp though10:02
pittiwhy?10:03
pittioh, for non-KDE crashes10:03
apacheloggeraye10:03
pittiwell, that stamp is .upload10:03
apachelogger-> [11:00:18] <apachelogger> pitti: and write a .upload file immediately I guess?10:03
apacheloggerthat's what I meant there ;)10:04
pittiapachelogger: 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
pittiargh no, at that point the .crash doesn't even exist yet10:04
pittimeh10:04
apacheloggerI know, it's headache material ^^10:05
pittiwe might put that into whoopsie itself, it could do the information collection when needed10:05
pittiw/when/if/10:06
apacheloggerpitti: that'd be cool10:08
evpitti, apachelogger: branches welcome :)10:12
apacheloggerev: oh, btw, how does the metrics stuff work?10:17
evapachelogger: which metrics stuff is this?10:18
apacheloggerev: com.ubuntu.WhoopsiePreferences.SetReportMetrics10:18
seb128xnox, 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
ubottuUbuntu bug 1259111 in usb-creator (Ubuntu) "/usr/bin/usb-creator-gtk:UnboundLocalError:<lambda>:_device_changed:_udisks_obj_added:_udisks_partition_added" [Undecided,New]10:19
xnoxseb128: argh =) thanks.10:19
seb128yw ;-)10:19
evapachelogger: that's not wired up to anything yet10:20
apacheloggerI see10:20
xnoxseb128: i wonder how come i am not subscribed to usb-creator bugs.... now subscribed10:20
evapachelogger: https://wiki.ubuntu.com/ErrorTracker#Invitation_for_metrics_collection10:20
seb128ev, 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
apacheloggerev: I'll hide the UI option for the time being then10:21
seb128xnox, seems like a good idea if you are the maintainer nowadays ;-)10:21
Laneysome cool guy wrote a script to automatically subscribe you to packages you upload10:24
seb128does it unsubscribe you have <n> days?10:25
Laneyyep10:25
seb128cool10:25
seb128how is that called/where is it?10:25
Laneycron10:25
* Laney tries to remember where it is10:26
xnoxLaney: i found that it would randomany unsubscribe my custom subscriptions....10:26
evseb128: we need to re-run the calculation to generate that graph, I suspect. Adding something into Asana to track this10:26
=== iahmad is now known as iahmad|afk
seb128ev, thanks10:27
Laneyyou didn't report the bug?!?!?!10:27
xnoxLaney: well, i didn't backup my existing subscriptions, now did I?! =)10:28
Laneyit's supposed to not subscribe you if you already are10:29
Laneyho hum10:29
=== Sweetsha1k is now known as Sweetshark
xnoxLaney: where was that script again? i clearly haven't used it since the incident....10:32
Laneylp:~laney/+junk/lp-subscribe-uploads10:32
Laneyit was fairly fire and forget, but I'd still merge patches / fix bugs10:33
Laneybah10:40
Laneyscreen has started segfaulting10:40
cjwatsonpenghuan: done11:01
penghuancjwatson:thx11:02
seb128Laney, let's maybe ask here?11:03
seb128doko_, what's the rational for changes like11:03
seb128-dh $@ --with autotools_dev11:03
seb128+dh $@ --with autoreconf11:03
seb128(Laney was trying to get that harfbuzz diff to Debian but pochu wants to understand what it's fixing/the rational)11:03
cjwatsonseb128: does a better job of handling new ports - there's a libtool fix that that picks up11:05
seb128cjwatson, do we have a description of "better job" for those who want to understand want issue it fixes in practice?11:05
seb128e.g a link to an email/wiki/bug reference?11:05
cjwatsonman dh_autoreconf ? :-)11:06
Laneymmm, that fix doesn't appear to be in Debian11:06
cjwatsonseb128: dh_autotools-dev_* only updates config.guess/config.sub11:07
seb128cjwatson, fair enough, thanks ;-)11:07
cjwatsonseb128: dh_autoreconf does a full update of all the autotools output - so it also picks up bug-fixes in other parts of that toolchain11:07
seb128cjwatson, thanks, that's the sort of explanation I was after, and it makes sense ;-)11:07
cjwatsonseb128: 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 regenerated11:08
seb128yeah, I know about that :p11:08
LaneyWe were more after the specific rationale for this batch of changes; the libtool hint was enough11:08
cjwatsonseb128: 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 thing11:09
seb128cjwatson, thanks11:10
seb128we have been using dh-autoreconf for all the desktop stuff for a while11:10
* cjwatson nods11:10
seb128(especially when we had launchpad integration changes that needed to update configure and other stuff)11:10
seb128I was just unsure how to "sell" it to others/not familiar enough with dh_autotools-dev to explain the difference11:11
seb128as Laney said, we have what we need to forward that fix to Debian ;-)11:11
xnoxcjwatson: slangasek: any updates re https://bugs.launchpad.net/ubuntu/+source/sysvinit/+bug/1184006 branches ?11:11
ubottuUbuntu bug 1184006 in sysvinit (Ubuntu Saucy) "wrong conffile prompt for /etc/default/rcS when UTC=no" [High,In progress]11:11
Laneyit was more "why specifically is this interesting for this package now"11:11
Laneynot "why is dh-autoreconf good in general?"11:11
xnoxLaney: to get libtool goodness =)11:12
Laneygot it11:12
Laneyta11:12
cjwatsonxnox: not something I've had time to look at for some time11:16
cjwatson(nor expect to before EOY)11:17
xnoxcjwatson: in that case no outstanding merge proposals for ubiquity, upload time? (it has quite a few changes staged)11:18
Laneyxnox: want to review the remaining libtimezonemap changes? :-)11:19
cjwatsonxnox: up to you, I wasn't touching that due to the note at the top of the changelog ...11:19
xnoxcjwatson: yeah, that's all fixed now.11:21
xnoxLaney: =)11:21
LaneyI did a chunk but there's still a few left11:22
Laneychanges what are more relevant to ubiquity's use of it11:22
=== _salem is now known as salem_
xnoxdoing a package merge "cross-cross merge encountered" => please work it all out =)))11:32
xnoxcjwatson: 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:54
ubottuDebian bug 728620 in debhelper "Update dh_installemacsen etc. for emacsen policy as of emacsen-common 2.0.5" [Normal,Fixed] http://bugs.debian.org/72862011:54
* xnox goes to check if emacsen-common is merged.11:55
xnoxyeap, we do have the new enough emacsen.11:55
cjwatsonxnox: go for it11:59
xnoxack.11:59
=== tkamppeter_ is now known as tkamppeter
tkamppeterOdyX, 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:05
=== alkisg is now known as work_alkisg
=== MacSlow is now known as MacSlow|lunch
=== tvoss is now known as tvoss|lunch
tkamppeterOdyX, fixed upstream, BZR rev. 7140.12:27
mlankhorsthow often do packages move from NEW to DONE?12:28
cjwatsonno fixed schedule, depends on human attention12:29
cjwatsonassuming you're asking about mesa, accepted now12:30
mlankhorstah12:33
mlankhorsti was curious since arm64 was accepted12:33
=== Ursinha-afk is now known as Ursinha
cjwatsonmlankhorst: I assume it was just the first one in place12:34
cjwatsonmlankhorst: oh, no, it's because arm64 doesn't build libxatracker*12:35
cjwatsonand those were the new binaries12:35
mlankhorstah right, ofc :)12:35
cjwatsonwait, what?  sbuild is seriously in universe?12:36
cjwatsonthat I did not expect12:36
=== doko_ is now known as doko
tseliotdidrocks: hey, bbswitch is now ready for promotion (bug 1255583)13:04
ubottubug 1255583 in bbswitch (Ubuntu) " [MIR] Main inclusion request for bbswitch" [Medium,Incomplete] https://launchpad.net/bugs/125558313:04
didrockstseliot: thanks, please just reassign to me, on other stuff, will do later on13:04
tseliotdidrocks: sure, thanks13:04
=== iahmad|afk is now known as iahmad
mlankhorstdoko: 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 things13:28
dokomlankhorst, I'd like to wait for a fast reliable native system. don't want to setup my cross hacks again to build this13:30
mlankhorstok13:31
mlankhorstdoko: but we already build arm64 right? you could just test the package from debian-experimental on arm6413:39
OdyXtkamppeter: 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 ...13:47
=== Pici` is now known as Pici
=== MacSlow|lunch is now known as MacSlow
alkisghighvoltage: /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:22
alkisg...is that also used in gnome-shell? Can we ship the version from Precise in order to have sane menus?14:23
alkisgI 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:24
=== tvoss|lunch is now known as tvoss
alkisg(or stgraber ^)14:25
seb128alkisg, 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 think14:26
alkisgseb128: 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
seb128mardy, hey, did you see bug #1258578? seems a new issue in trusty with the signon update, it's one of the most reports errors there14:27
ubottubug 1258578 in signon (Ubuntu) "/usr/bin/signond:4:QListData::shared_null:qDeleteAll:qDeleteAll:SignonDaemonNS::SignonSessionCore::destroy:SignonDaemonNS::SignonDisposable::destroyUnused" [Undecided,New] https://launchpad.net/bugs/125857814:27
alkisgthere'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 them14:28
alkisgThe settings submenus are all wrong.. too many things are wrong to list them in order14:28
alkisgI 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:29
alkisgThe .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
seb128alkisg, 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 issue14:30
alkisgYup I'm using trusty, let me check the bug report, but the "others" submenu is only 5% of the problems there14:31
seb128alkisg, 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 well14:31
seb128but we are not going to revert upstream work randomly14:31
alkisgseb128: thanks, will do, but could you help me a bit to understand the rationale? Are those menus used for gnome-shell nowadays?14:32
seb128we need to understand the changes, why they are there and what we can do that accomodate gnome-shell uses and other desktops as well14:32
seb128alkisg, https://git.gnome.org/browse/gnome-menus/commit/?h=gnome-3-8&id=36d5d699d7d4193a1b3d84777566466326f78b1914:32
seb128read https://bugzilla.gnome.org/show_bug.cgi?id=694131 I guess14:32
ubottuGnome bug 694131 in layout "New directories for use in app pickers" [Normal,Resolved: fixed]14:33
alkisgThanks, I think that last one contains most of the changes14:33
alkisgHehe, "Uhm, except for the first patch, the series was not actually meant to be committed literally."14:34
* alkisg wonders if there's any way to dump the effective menu layout to attach it to bug reports14:35
JordiGHHow do I get the debian/control of this package? https://launchpad.net/~octave/+archive/unstable/+packages14:38
alkisgIs mate-desktop going to be available in Trusty? Maybe they've already solved this problem there...14:38
JordiGHI mean, other than adding it to my apt.sources and doing apt-get source.14:38
pittijibel: download and unpack https://launchpad.net/~octave/+archive/unstable/+files/octave_3.7.7-0%7Eppa1%7Eraring1.debian.tar.gz14:38
pittisorry14:38
pittiJordiGH: ^14:39
pittijibel: wrong nick, sorry14:39
JordiGHMan, I wish there was a web interface to it like packages.debian.org :-/14:39
JordiGHpitti: Okay, thanks.14:39
sladenalkisg: /usr/lib/libdbusmenu/dbusmenu-dumper14:39
pittiJordiGH: there (kind of) is for ubuntu packages, but not for PPAs14:39
alkisgsladen: thanks, I installed libdbusmenu-tools, will check that in a while.14:42
* alkisg waves...14:42
seb128sladen, he was asking about xdg .desktop menus, I doubt that's the right tool...14:43
JordiGHpitti: Alright, thanks for your help.14:44
mhall119lfaraone: I think jamesh is still running that project, but I can take a look at the mp14:45
lfaraonemhall119: awesome, thanks!15:17
=== wedgwood_ is now known as wedgwood
mhall119lfaraone: have a link to the MP?15:18
=== smoser` is now known as smoser
lfaraonemhall119: https://code.launchpad.net/~lfaraone/django-openid-auth/custom_response/+merge/19584515:20
mhall119lfaraone: can you add tests that check the value of openid_response in render_failure?15:27
=== greyback is now known as greyback|london
lfaraonemhall119: sure.15:29
mhall119thanks lfaraone15:29
=== freeflying is now known as freeflying_away
bdmurrayseb128: were you going to do the merging / upload of the apturl fix for bug 1050826?16:17
ubottubug 1050826 in apturl (Ubuntu) "apturl-gtk crashed with AttributeError in parseArgs(): 'str' object has no attribute 'decode'" [High,Triaged] https://launchpad.net/bugs/105082616:17
seb128bdmurray, hey, yes, I just got a busy monday and didn't get to do it yet ;-)16:17
seb128bdmurray, thanks for the review!16:17
hallyn_is there a simple way to get do-release-upgrade (for a test) to ignore the fact that some packages are unauthenticated?16:19
bdmurrayhallyn_: I don't think so16:20
hallyn_drat16:20
bdmurrayhallyn_: what exactly are you trying to do?16:21
hallyn_test whether a candidate qemu for trusty woudl cleanly upgrade in lts-to-lts16:22
xnoxhallyn_: i do schroot into precise & add sources as appropriate and do a dist-upgrade.16:23
rbasakhallyn_: you can just update sources.list and dist-upgrade I think16:23
xnoxhallyn_: also you can run piuparts to do automated lts->lts upgrades/downgrades/install/remove/reinstall and a bunch of other tests.16:23
xnoxhallyn_: piuparts can work with pbuilder tarballs or schroots, if I remember correctly.16:24
hallyn_rbasak: no, but i can ctrl-z and re-insert my custom entries.  that bit is fine :)16:26
hallyn_piuparts?  i've heard of it...16:27
hallyn_sounds like maybe what i need16:27
hallyn_xnox: is there a good wiki link showing simple usage?16:28
xnoxhallyn_: it's running automatically against the whole debian archive and reports problems to PTS.16:28
xnoxhallyn_: https://piuparts.debian.org/16:28
xnoxhallyn_: and links from there https://piuparts.debian.org/doc/README_1st.html https://piuparts.debian.org/doc/piuparts.1.html16: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 repertoire16:29
hallyn_xnox: how do you run it for lts-to-lts upgrades?16:48
xnoxhallyn_: 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:48
xnoxhallyn_: it was a long time since i used it last =) i know I am bad.16:49
hallyn_xnox: oh - np, i just figured you used it daily.  thanks!  i'll figure it out16:50
slangasekxnox: https://bugs.launchpad.net/ubuntu/+source/sysvinit/+bug/1184006> none, sorry; haven't had time to straighten out the bugs cjwatson pointed out17:06
ubottuUbuntu bug 1184006 in sysvinit (Ubuntu Saucy) "wrong conffile prompt for /etc/default/rcS when UTC=no" [High,In progress]17:06
slangasekxnox: 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 Ubuntu17:06
xnoxslangasek: thanks.....17:07
* xnox goes to reupload debhelper i think.17:07
mlankhorsthm, why is mesa still in -proposed ? (it has a new binary libxatracker2)17:08
xnoxslangasek: looks good? http://paste.ubuntu.com/6546703/17:11
xnoxdarn, wrong DEB_NAME17:11
slangasekxnox: it looks familiar, and if it's a straight revert I trust that it's fine :)17:13
xnoxack.17:13
cjwatsontrying: mesa17:13
cjwatsonskipped: mesa (68 <- 160)17:13
cjwatson    got: 26+0: i-2617:13
cjwatson    * i386: kubuntu-active, xserver-xorg-video-all, xserver-xorg-video-vmware17:13
cjwatsonmlankhorst: ^-17:13
cjwatsonhttp://people.canonical.com/~ubuntu-archive/proposed-migration/update_output.txt17:13
mlankhorstoh right17:13
mlankhorstfixed :p17:14
=== freeflying_away is now known as freeflying
jibelslangasek, 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:28
ubottubug 1257305 in sbsigntool (Ubuntu) "Wrong efivars magic in sbkeysync" [High,Triaged] https://launchpad.net/bugs/125730517:28
slangasekjibel: 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 releases17:34
slangasekjibel: if you want to upload it be my guest17:34
jibelslangasek, thanks but I cannot upload :)17:36
brendandhi, i'm trying to build a package containing a qt plugin whose target is 'libgui-engine'17:41
brendandthis builds as 'libgui-engine.so'17:42
brendandbut when i install the package, it turns into 'libgui-engine.cpython-33m-x86_64-linux-gnu.so'17:43
brendandi can't figure out how python comes into it17:43
xnoxbrendand: did you install the .so into /usr/lib/python* ?17:45
slangasekjibel: ok.  are you ok to have this wait until I have a chance to get a poper upstream release sorted?17:45
slangasekjibel: (which will be a couple weeks at least)17:45
brendandxnox, no it's installed to /usr/lib/checkbox-gui/plugins17:45
brendandxnox, i think i just realised :/17:47
=== bschaefer_ is now known as bschaefer
brendandxnox, for some reason i put ${python3:Depends} in the binary packages Depends17:47
xnoxbrendand: don't do that =) or do override_dh_python3 and use exclude to exclude that path and/or that package17:51
xnoxsuch that they are untouched.17:51
brendandxnox, well having it serves no purpose so i remove it :)17:51
brendandxnox, dumb stuff that creeps in thanks to the evils of Ctrl+C/V17:51
slangasekLaney: 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
cjwatsonslangasek: I notice that seb128 has an update building at the moment17:53
Laneyslangasek: I expect it's just du17:53
Laneythat17:53
slangasekok17:53
Laneyuninstallable due to transition etc17:54
slangasekxnox: 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 angry17:57
=== bfiller is now known as bfiller_afk
xnoxslangasek: with my limited W3C skillz, it appears to me entirely unused?!17:59
slangasekhmm17:59
slangasekisn't it used to create the graphs at the bottom of the page?17:59
xnoxslangasek: also it looks fine in my web-browser.17:59
* xnox uses Google Chrome17:59
slangasekI didn't say it doesn't /look/ ok :)17:59
slangasekbut it gets itself into some stupid busy loop (in firefox) that eventually causes firefox to kill it as a runaway js process18:00
xnoxslangasek: ouch, that graph is sure a good way to generate..... every client does it, instead of server side.18:00
slangasekxnox: 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
xnoxslangasek: yeah spotted it now.18:01
xnoxslangasek: i can look into splitting a graph into a separate page, would that work?18:01
slangasekxnox: bitcoin miner> hahaha18:02
slangasekxnox: sure, splitting it would work18:02
shadeslayerI'm curious as to what's the long term plan with logind18:05
shadeslayerwill Ubuntu maintain logind with upstart integration? ( I'm mostly interested in the dbus interfaces )18:06
shadeslayeror will upstart have it's own user session namespace ?18:06
xnoxshadeslayer: what do you mean? logind as a daemon is here to stay, as is with compatible dbus API as everywhere else.18:07
=== mhall119 is now known as mhall119|afk
shadeslayerxnox: well, that's my question, will logind be dropped in the future or is it going to stay18:07
xnoxshadeslayer: we do have a shim in place, but that should be mostly opaque. If there bugs, file them on launchpad as usual.18:07
xnoxshadeslayer: lennart didn't write a replacement for logind yet, until that happens it's here to stay.18:08
shadeslayerxnox: there's just a minor bug, some KDE applications ask systemd for the systemd version, which isn't implemented on the dbus interface in ubuntu18:08
xnoxshadeslayer: (remember that logind is rewrite of consolekit)18:08
xnoxshadeslayer: those applications are wrong, they should be checking for presence of the _logind_ not of _systemd_.18:08
xnoxshadeslayer: loads of packages were fixed by pitti, and the upstrem "sd_*" static files were updated as well.18:09
shadeslayerxnox: the idea I got was to check if the version is greater than a certain version to check if the interface was implemented18:09
xnoxshadeslayer: 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:09
xnoxshadeslayer: one should check the interface presence, rather than version numbers.18:10
shadeslayer*nod*18:10
xnoxshadeslayer: i believe all compatible interfaces are implemented, check with e.g. d-feet if the needed interfaces are implemented.18:10
shadeslayerI'll try and refactor the code that way18:10
xnoxshadeslayer: 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
slangasekintroducing, duck typing for dbus18:11
shadeslayerxnox: sure, kde-workspace, powerdevil checks for systemd version18:11
xnoxshadeslayer: or he can better consult which interfaces are available.18:11
xnoxshadeslayer: 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
shadeslayerxnox: actually I'm already fixing it :)18:12
xnoxshadeslayer: good, please upstream it as well =)18:13
slangasekLaney, cjwatson: the update being built is for which package?18:13
shadeslayerofcourse, 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
shadeslayerwell, s/ubuntu specific/upstart specific/18:14
slangasekshadeslayer: writing a different interface would be silly; we deliberately made logind work on upstart18:14
slangasekand even if the logind code base became unmaintainable on top of upstart, there's no reason to implement a distinct API18:15
shadeslayer*nod*, thanks for that18:15
=== mhall119|afk is now known as mhall119
mcpierceHi, all. Looking for some guidance on becoming a Ubuntu packager. I've got experience with packaging on Fedora.19:11
NoskcajWhen can i expect http://qa.ubuntuwire.com/bugs/rcbugs/ to have trusty listed? Is there anything i can do to speed it up?19:20
mlankhorstmesa 10 in trusty soon, enjoy19:45
Laneyslangasek: webkitgtk19:45
slangasekLaney: ah, thanks; somehow I thought the problem was in webkit itself19:46
Laneyhrm, that should be removed19:46
LaneyI thought Seb took care of that; will sort it out in the morning19:46
Laney(webkitgtk supersedes it)19:46
slangasekok19:46
=== bfiller_afk is now known as bfiller
hallyn_could someone push the sru fix for https://bugs.launchpad.net/ubuntu/+source/qemu/+bug/1243403 into saucy's qemu?20:10
ubottuUbuntu bug 1243403 in qemu (Ubuntu Saucy) "Upgrade from qemu 1.0+noroms-0ubuntu14.11 fails" [High,Fix committed]20:10
stgraberhallyn_: I'll do an SRU round in a few minutes. (unless infinity is planning one, I believe it's his SRU day)20:13
hallyn_stgraber: thx20:16
=== freeflying is now known as freeflying_away
=== salem_ is now known as _salem
slangasekxnox: 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 minutes20:57
slangasekutlemming: hmm, your mail suggests that UEFI support comes in the form of a separate disk image - how come?21:25
utlemmingslangasek: UEFI and BIOS/GPT come together21:26
slangasekwhy is that an additional image, instead of changes to the existing image?21:26
slangasekan image can have both a GPT and an MBR partition table on it21:27
utlemminga couple of reasons21:27
utlemmingthe biggest is that we wanted to preseve root being the first partition. Hybrid images make the difficult21:27
utlemmingthe second reason is that there is the question of supporting a hybrid mbr/gpt image21:28
utlemmingafter consulting with cjwatson, he strongly advised against going that route21:28
slangasekhmm, ok21:28
utlemmingfor 14.10, we are going to talk about making the UEFI image the cloud image default and droping the BIOS/MBR disk image21:29
=== freeflying_away is now known as freeflying
slangasekxnox: the straightforward proposal: https://code.launchpad.net/~vorlon/udd/no-auto-refresh/+merge/19832021:57
xnoxslangasek: ack. will pull and deploy it tomorrow. afk at the moment. =)21:58
slangasek;)21:58
infinityawe_: Why are we adding -dbg packages in Ubuntu deltas when we prefer ddebs? (urfkill, in this case)22:55
infinitycyphermox: ^22:55
cyphermoxinfinity: useful in a ppa22:55
cyphermoxif you feel we really shouldn't ...22:55
cyphermoxI'm sending that to debian too btw22:55
infinitycyphermox: 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
cyphermoxinfinity: sure :)22:56
cyphermoxI don't feel strongly for it, though it does tend to be useful when you build things in a PPA22:57
infinityYou can get PPAs with ddebs.22:57
cyphermoxyou 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
cyphermoxah22:57
cyphermoxa matter of asking the right magician22:57
awe_cyphermox, we probably should fix ofono too22:59
infinityAnyhow, 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
cyphermoxawe_: you mean re: dbg packages?22:59
awe_yes22:59
cyphermoxinfinity: I'll strongly suggest it to the debian maintainer.22:59
cyphermox(for what my opinion really matters)23:00
cyphermoxawe_: you mean removing them?23:00
infinityThis 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
infinitySo we can make -dbg a thing of the past everywhere.23:00
cyphermoxinfinity: 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 too23:01
geofftinfinity: 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 code23:01
cyphermoxawe_: just pull the plug when you feel like it23:01
infinityawe_: 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:01
cyphermoxawe_: or I'll fix the debian side of things for ofono23:02
infinityawe_: Some day, we want them gone from both Debian and Ubuntu, and ddebs to rule the world.23:02
awe_ok23:02
cyphermoxI think it might already be a delta from us23:02
awe_yea, pretty sure it is23:02
infinitygeofft: It's doable with binary uploads.23:02
awe_( ie. we added the -dbg package for ofono )23:02
infinitygeofft: Though I'm firmly on the "source uploads forever" side of that debate too. :P23:02
geofftBy asking folks to upload ddebs too?23:02
cyphermoxI'll look, and apply the right thing if needed23:02
infinitygeofft: 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:03
geofftNeat.23:04

Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!