[01:55] <rick111> trying ot run empty file setup on codeblocks
[01:55] <rick111> anyone know how to do this?  i have to manually set the file paths i guess
[04:23] <pitti> Good morning
[07:00] <dholbach> good morning
[07:09] <ion> that
[09:58] <xnox> rsalveti: do you use zoneminder?
[10:56] <LocutusOfBorg1> Hi, I'm wondering if poedit will be automatically sync'd from debian
[10:56] <LocutusOfBorg1> https://launchpad.net/debian/+source/poedit
[10:57] <LocutusOfBorg1> but not shown in https://launchpad.net/ubuntu/+source/poedit
[10:57] <LocutusOfBorg1> MoM should run twice every hour, I'm wondering if something broke again :(
[10:58] <cjwatson> LocutusOfBorg1: It will be, you're just not quite patient enough
[10:58] <ypwong> xnox, hi, does the branch for ubuntu kylin seed look good? wonder if you will have some time on working on the meta package.
[10:58] <cjwatson> LocutusOfBorg1: MoM doesn't do the auto-syncing; that runs every six hours, not long after the import into https://launchpad.net/debian/...
[10:59] <LocutusOfBorg1> ok thanks colin!
[10:59] <cjwatson> That job is due to start in six minutes
[10:59] <cjwatson> Sorry, actually one minute
[10:59] <LocutusOfBorg1> ack wonderful :)
[10:59] <LocutusOfBorg1> anyway, I'm rebuilding vtk with your fix
[10:59] <LocutusOfBorg1> do you mind sponsoring it?
[11:00] <cjwatson> err send me mail and we'll see
[11:00] <cjwatson> seems a bit quick for an NMU; usually I would give a few days
[11:01] <cjwatson> and I already uploaded that fix to Ubuntu
[11:01] <LocutusOfBorg1> I was thinking about a delayed/5
[11:01] <xnox> ypwong: right, sorry got swamped with other work. That will miss alpha-1, as we are frozen for it. Will aim for friday to upload, such that alpha2 is for sure built using seeds.
[11:01] <cjwatson> LocutusOfBorg1: ok, maybe, send me mail
[11:01] <LocutusOfBorg1> sorry but this is the third NMU, the maintainer seems to be not caring anymore :)
[11:02] <cjwatson> don't drag me into that :)
[11:02] <LocutusOfBorg1> I'll put the package on mentors maybe tomorrow
[11:02] <LocutusOfBorg1> and mail you
[11:08] <LocutusOfBorg1> the problem is that on debian I know where to look (incoming, upload queue, mentors, buildd, dinstall) on ubuntu is everything more "complicated"
[11:09] <LocutusOfBorg1> I see it now :)
[11:10] <cjwatson> LocutusOfBorg1: I think in general giving things slightly more than half an hour would be a good diea
[11:10] <cjwatson> *idea
[11:14] <LocutusOfBorg1> oh yes of course :) I just would like to know the "dependency graph", in order to be aware in case of troubles
[12:09] <LocutusOfBorg1> xnox, you there?
[12:09] <LocutusOfBorg1> thanks for the libavg upload
[12:11] <LocutusOfBorg1> Seems that you added libmtdev-dev
[12:11] <LocutusOfBorg1> but this is available for linux-any
[12:11] <LocutusOfBorg1> :( is it possible to build without it?
[12:12] <LocutusOfBorg1> also mipsel is FTBFS :(
[12:28] <rsalveti> xnox: yes
[12:28] <tseliot> pitti: hi, is it possible that when suspending (S3) using "pm-suspend" logind fails to catch the event?
[12:29] <xnox> rsalveti: excellent! i've uploaded zoneminder with patches to build against libav10. If at some point you could test utopic-proposed that it is still somewhat operational, that would be great.
[12:29] <tseliot> pitti: in that logind doesn't get to emit a ""PrepareForSleep" event
[12:29] <rsalveti> xnox: sure
[12:29] <xnox> rsalveti: we have a few instances where e.g. it builds fine but there is no sound and/or video is jammed =(
[12:43] <pitti> tseliot: right, it's not only possible, but certain -- there is no event sent by the kernel when you call pm-suspend directly
[12:43] <pitti> tseliot: i. e. logind would never notice
[12:44] <tseliot> pitti: ok, so that certainly explains why LP: #1210077 can only be reproduced with pm-suspend
[12:44] <pitti> tseliot: also, sending PrepareForSleep wouldn't work anyway, as logind couldn't inhibit suspend for the listeners
[12:45] <tseliot> pitti: would the solution be to write a hook for pm-suspend to send a message to Unity (through dbus?)?
[12:46] <pitti> tseliot: err no; what are you trying to do?
[12:47] <pitti> tseliot: everything in the desktop/phone is supposed to call logind's Suspend() method which will DTRT
[12:47] <pitti> tseliot: some might still call upower's, but we are moving away from that
[12:47] <tseliot> pitti: so, Unity listens to logind to see when the system enters S3, so that it can redraw the launcher on resume
[12:47] <pitti> tseliot: hm, is that to work around graphics driver bugs?
[12:48] <pitti> tseliot: but regardless of the "why", yes; that would only work if you actually request suspend through logind
[12:48] <tseliot> pitti: it's not really a bug, you are not supposed to reuse the FBO
[12:49] <tseliot> pitti: now the problem is that using fwts for testing triggers the problem
[12:49] <tseliot> by calling pm-suspend directly
[12:49] <pitti> tseliot: oh, is fwts calling pm-suspend?
[12:49] <pitti> yes, that's a problem then :)
[12:49] <pitti> programs should never ever call pm-utils directly
[12:50] <pitti> it's not guaranteed to be installed (an in fact, 95% of hardware doesn't need it), we don't install it on the phone, etc.
[12:50] <tseliot> pitti: yep. Shall we fix fwts instead? If so, where can I find the code that suspends the system on the desktop
[12:50] <tseliot> ?
[12:50] <tseliot> gnome-power something?
[12:50] <pitti> there's basically only two ways (jedi-handwaving away all the old ones): logind suspend, or echo mem > /sys/power/state if you want a low-level one
[12:51] <pitti> tseliot: yes, fixing fwts sounds right
[12:52] <pitti> tseliot: there's not really much to it:
[12:52] <pitti> $ gdbus call -y -d org.freedesktop.login1 -o /org/freedesktop/login1 -m org.freedesktop.login1.Manager.CanSuspend
[12:52] <pitti> ('yes',)
[12:52] <pitti> tseliot: if that's "yes", call .Suspend false
[12:52] <tseliot> pitti: would that be /lib/systemd/systemd-logind in systemd-services ?
[12:52] <pitti> (the boolean is the "interactive" flag)
[12:52] <pitti> tseliot: yes, but don't assume that anywhere; d-bus it is :)
[12:54] <tseliot> pitti: so I have to call .Suspend with false to make it suspend?
[12:54] <pitti> tseliot: right; that's what things like indicator-session, gnome-settings-daemon, etc. do
[12:54] <tseliot> pitti: ok, that's interesting, thanks
[12:55] <pitti> tseliot: FTR, in the future that's easier with "systemctl suspend", but we don't have that part yet
[12:55] <tseliot> pitti: that sounds a little easier. This solution will do for now, thanks again!
[13:01] <tseliot> cking: would it be ok if I made fwts use dbus+logind to suspend (and hybrid suspend) instead of calling pm-suspend?
[13:02] <cking> tseliot, what is the benefit?
[13:02] <cjwatson> Ampelbein: Looks like you made the last substantial changes to scribes.  It's since been removed from Debian ("RoQA; RC buggy, unmaintained, dead upstream; Debian bug #745896").  Do you mind if I remove it from Ubuntu too?
[13:03] <tseliot> cking: Unity will get a notification that the system suspended and will redraw itself thus avoiding certain corruption
[13:03] <tseliot> cking: namely LP: #1210077
[13:04] <pitti> cking: also, things should never call pm-utils these days; it's been long obsoleted, you can't assume it's there (folks might uninstall it as 95% of hw doesn't need it, and we don't have it on the phone)
[13:05] <cking> tseliot, pitti, fair point, however, fwts does run on other distros so I'd prefer it if we had an option in fwts to select the suspend mechanism rather that remove the older functionality
[13:06] <pitti> cking: oh, even more important then :)
[13:06] <pitti> cking: pm-utils has been dropped by e. g. fedora (and supposedly also on arch or gentoo) a long time ago
[13:07] <pitti> cking: these days, logind is the standard API; it can have a fallback to echo mem > /sys/power/state for embedded systems and the like
[13:07] <Ampelbein> cjwatson: no objection from me with regards to removing "scribes". Looks like it's dead for good :(.
[13:08] <cjwatson> Ampelbein: OK, done, thanks
[13:08] <cking> tseliot, so perhaps we should have an extra option, such as --pm-method=[pm-utils | sysfs | dbus.. ] etc
[13:09] <tseliot> cking: or maybe detect if logind is running and use that when available?
[13:09] <cking> tseliot, yes - making it smart is useful, but I still think an over-ride option is always useful too ;-)
[13:10] <tseliot> cking: ok then autodetection and --pm-method to override it
[13:10] <cking> tseliot, sounds like a plan to me
[13:10] <tseliot> it sounds sane this way
[13:10] <tseliot> good
[13:10] <cking> patches welcome :-)
[13:12] <tseliot> cking: shall I call dbus using the (painful) c dbus bindings or would a command line tool be ok too?
[13:12] <cking> tseliot, i'm pragmatic, do what is easiest
[13:13] <cking> since we call pm-suspend etc already, calling the command line tool is fine
[13:14] <tseliot> cking: great, I'll send you a patch when it's ready. Does the project use a git/bazaar repository?
[13:14] <cking> git://kernel.ubuntu.com/hwe/fwts,  and send patches to fwts-devel for review,  fwts is rather kernel like in the patch review process
[13:16] <cking> (https://lists.ubuntu.com/mailman/listinfo/fwts-devel)
[13:16] <tseliot> cking: excellent, thanks
[13:16] <cking> tseliot, thanks for picking this up :-)
[13:16] <tseliot> ;)
[13:25] <pitti> thanks tseliot
[13:26] <tseliot> yw
[13:27] <rbasak> pitti: for the juju-quickstart test requirement, would you expect me to do this before upload to stable-proposed, or as part of SRU verification after the upload has been accepted? I would do both - just wondering what stage I need to document.
[13:36] <pitti> rbasak: from my POV it doens't need to be overly bureaucratic; it's always better to test with teh actual packages from -proposed, i. e. as part of the SRU verification
[13:37] <pitti> rbasak: but if the SRU bug somewhere has your confirmation "tested quickstart with this juju version", that's fine
[13:38] <rbasak> pitti: that was my thinking - thanks. I'll do a proper check with the real binaries during SRU verification, and a cheap (not necessarily exactly reproducible, but enough to satisfy myself) before upload.
[13:38] <rbasak> eg. I might change the changelog before upload, but not retest, etc.
[13:38] <pitti> rbasak: btw, if you'd like any autopkgtest result to refer to, I'm happy to manually run the trusty jobs
[13:38] <rbasak> OK - thanks!
[13:39] <pitti> or, if you set up VPN, you can trigger them yourself too of course
[14:41] <ypwong> xnox, sorry i was away for dinner. that's great, thanks for helping on that
[14:54] <doko> bdmurray, arm unwind ping
[14:57] <bdmurray> doko: hi
[14:58] <doko> bdmurray, does the unwinding work with the coreutils ddbg package installed?
[14:59] <bdmurray> doko: I could test that today
[15:01] <infinity> @pilot in
[15:09] <asomething> mdeslaur, did you see jdub's comment in LP: #1307027?
[15:11] <asomething> I'm seeing the same thing. I seeing the same thing. Even on a fresh install I need to go edit /etc/php5/fpm/pool.d/www.conf to get php5-fpm working
[15:12] <shadeslayer> chrisccoulson: poke bug 1274605
[15:24] <mdeslaur> asomething: yes, you need to either relax permissions, or configure it with the account whatever you're accessing it is using
[15:25] <mdeslaur> asomething: whatever procedure you followed to configure integration between your web server and php-fpm needs to be modified
[15:29] <asomething> hmm... ok. are you saying there is no secure default that will work out of the box? I can handle that, but it seems to break most documentation on the web
[15:30] <mdeslaur> we could make it default to www-data perhaps...not sure that would cover all the use cases
[15:31] <asomething> that seems to be the most common, but maybe I'm just not aware of other uses
[15:32] <mdeslaur> if someone can file a bug, and attach a debdiff, I'll sponsor it for an SRU assuming the SRU team considers it an appropriate change
[15:33] <mdeslaur> asomething: actually, just file a bug, and I'll push it out as a regression fix
[15:33] <asomething> ok, will do
[15:34] <mdeslaur> asomething: thanks
[15:35] <seb128> hum
[15:36] <seb128> is that standard/agreed behaviour for packages using c++11 to specify a fixed g++ version to control ABI changes?
[15:36] <seb128> slangasek, ^
[15:38] <infinity> mdeslaur: Yeah, that's a perfectly reasonable fix.  All webservers in Debian/Ubuntu are meant to run as www-data, so that would cover the common case.
[15:39] <infinity> mdeslaur: People with weird setups are on their own, but they already knew that.
[15:39] <seb128> (unping about that question, discussing the specific change with those who suggested it)
[15:40] <mdeslaur> infinity: ok, will do, thanks
[15:41] <mdeslaur> asomething: let me know when you get the bug #, so I can add it to the changelog I'm preparing
[15:44] <asomething> mdeslaur, LP #1334337 Not the best bug report, but you already know the issue =)
[15:44] <asomething> Thanks!
[15:44] <mdeslaur> asomething: perfect, thanks!
[16:02] <xnox> mdeslaur: probably regression from migrating to upstart job from initscript.
[16:03] <mdeslaur> xnox: huh?
[16:03] <mdeslaur> xnox: are you talking about the php update?
[16:04] <xnox> mdeslaur: bug is marked fix-released in utopic, how was it fixed there?
[16:04] <mdeslaur> xnox: utopic already set the user:group on the socket
[16:04] <mdeslaur> I'm doing the same for trusty and saucy
[16:04] <xnox> mdeslaur: oh, i think i am missundersting it completly.
[16:04] <mdeslaur> xnox: my security update removed 'other' permissions from the php fpm socket
[16:05] <mdeslaur> xnox: and the socket is root:root by default
[16:05] <mdeslaur> so it broke setups that were relying on documentation that was relying on the 'other' permissions on the socket
[16:05] <mdeslaur> etc.
[16:05] <xnox> mdeslaur: so php5-fpm by default runs as root? or does it self drop priviliges?
[16:05] <mdeslaur> xnox: no worries, it's under control, I'll push an update out soon
[16:06] <mdeslaur> xnox: it drops privs after opening the socket
[16:06] <xnox> ok, cool.
[17:51] <doko> xnox, boost head ping
[17:52] <doko> https://github.com/ruediger/Boost-Pretty-Printer
[17:52] <doko> do you want to integrate that?
[18:02] <bdmurray> infinity: maybe you could have a look at the patch in bug 1331201?
[18:06] <infinity> bdmurray: Seems reasonable enough.  If you work up SRU paperwork, I'll do the uploads.
[18:07] <infinity> bdmurray: Well, I suppose you probably don't know what the testcase would be, but we can hope the submitter does. :P
[18:32] <infinity> bdmurray: Uploaded to both utopic and trusty.
[18:32] <infinity> @pilot out
[18:35] <arges> infinity: hey if you have a few minutes can you check out this patch, and see if its reasonable to fix an FTBFS: https://bugs.launchpad.net/ubuntu/+source/crtools/+bug/1256675/comments/8 . I think my hack is a bit heavy-handed ( i can upload if it looks reasonable)
[19:16] <infinity> arges: Here's my hack instead: http://paste.ubuntu.com/7702094/
[19:17] <infinity> arges: Uploaded that.  The better fix is probably to link with $(CC) instead, but my carefactor is too low, since I've been awake for too long. :P
[19:17] <arges> infinity: yea, how many hours is it now: )
[19:18] <infinity> arges: A few.
[19:18] <arges> infinity: heh. yea i like your patch better. that's why I pinged you: ) thanks
[19:20] <infinity> arges: The bug log seems to have upstream people involved.  If that's true, tell them to stop *&^#!% passing LDFLAGS (a CC argument) to LD.
[19:20] <infinity> arges: Ideally, by linking with CC instead.
[19:20] <arges> infinity: yea that confused me a bit; since -Wl is a gcc flag right?
[19:20] <infinity> arges: But my hack works if they really want to link with LD and use LDFLAGS.
[19:21] <infinity> arges: Right, -Wl,foo means "hey, gcc, pass foo to ld".
[19:21] <infinity> arges: And LDFLAGS is generally always passed to CC, hence it having commas and -Wl all over it.
[19:22] <infinity> arges: So, my little conversion turns it into valid ld(1) arguments, but that's icky. ;)
[19:22] <arges> infinity: the wierd thing is that 'make' by itsself in that envirnoment works fine. but maybe that's because LDFLAGS isn't populated with anything?
[19:22] <arges> 'make' without dpkg-buildpackage
[19:22] <infinity> arges: LDFLAGS is being populated by dpkg-buildflags, via debhelper, via debian/rules.  So, yeah, if you bypass all of that, you win.
[19:23] <arges> infinity: makes sense. I can pass a helpful note upstream if you don't mind
[19:23] <infinity> arges: Go nuts.
[19:23]  * arges goes nuts.
[19:37] <knocte> any python expert here? been hitting my head against the wall with this: http://stackoverflow.com/questions/24414278/attributeerror-module-object-has-no-attribute-cairo-font-map-get-default (and http://pastebin.com/b2VC6JxY )
[19:51] <luist_> hey guys… can i run such commands in postinst when creating a new deb package? http://paste.ofcode.org/ycbXvi9DNjjv8kXjB77VyX
[20:00] <dobey> omg the text on that site is so tingy
[20:00] <dobey> tiny
[20:00] <dobey> also wow that postinst script is awful
[23:11] <tedg> bdmurray, Does the daisy webpage of an entry show all the fields? Or does it show a subset?
[23:13] <bdmurray> tedg: Do you have a web page url in particular you are curious about?
[23:13] <tedg> bdmurray, Uhm, a set, but for example: https://errors.ubuntu.com/oops/c9926216-fc08-11e3-8022-fa163e4ccdf2
[23:14] <bdmurray> tedg: so that's really errors not daisy and yes it shows all the entries from the database. Is there something missing?
[23:16] <tedg> bdmurray, Yeah, the filename for one: http://bazaar.launchpad.net/~indicator-applet-developers/url-dispatcher/trunk.14.10/view/head:/service/update-directory.c#L133
[23:16] <tedg> bdmurray, We're putting that on as "Filename"
[23:16] <tedg> bdmurray, But I also think that apport attaches the upstart logs for url-dispatcher on those, which don't seem to be there.
[23:17] <bdmurray> tedg: whoopsie only accepts a subset of apport's data so we don't have tons of kernel, xorg, whatever log files. https://bazaar.launchpad.net/~daisy-pluckers/whoopsie/trunk/view/head:/src/whoopsie.c#L93
[23:19] <tedg> bdmurray, Hmm, that's a bit of a bummer. As we don't get data from apport hooks as well.
[23:20] <bdmurray> tedg: long term the goal is to be able to ask for more details as needed for a specific problem e.g. for the next instance of this problem get this log file
[23:22] <tedg> bdmurray, Seems like in general fields that are added by the app on the recoverable error or by upstream package hooks should probably make it.
[23:23] <tedg> bdmurray, Even without adding them.
[23:25] <bdmurray> tedg: I think the point was for each instance to have things that were quantifiable so for this problem we have 40 i386 instances and 20 amd64 ones. And with random log files that isn't possible / useful.  However, it'd be best to check with evan about the decision he made there.
[23:26] <tedg> I think we have a brand new database, let's fill it! :-)
[23:27]  * bdmurray shakes head
[23:28] <tedg> Hmm, there's a parameter to send the full report. Seems in every call it is set to FALSE.
[23:31] <mark06> anyone in here which knows software-center's code? I can't make it stop showing apt repositories which don't exist anymore
[23:34] <bdmurray> are there corresponding sources.list files in /etc/apt/sources.list.d/ for these repositories? perhaps if you remove them that'll help sort it out
[23:44] <bekks> mark06: So fix your repos then, in /etc/apt/sources.list and /etc/apt/sources.list.d/
[23:45] <mark06> nothing I do fixes it, that sources.list.d was just one of the first things I've tried
[23:46] <sarnold> mark06: maybe delete their lists from /var/lib/apt/lists ?
[23:46] <mark06> does software-center store repositories in binary config? cause grep just can't find it by repo name or url
[23:48] <mark06> there's nothing like that in  /var/lib/apt/lists
[23:49] <bekks> mark06: Did you check both, /etc/apt/sources.list and /etc/apt/sources.list.d/ ?
[23:53] <mark06> yes, in fact I checked whole /etc... SC shows a ghost 'Main' repo, but `sudo grep -rn Main /etc` can't find anything... it can't find it anywhere
[23:54] <bdmurray> check for lower case main
[23:55] <mark06> but the name is Main, which was the name of my ppa
[23:55] <mark06> tried -I renatosilva as well, which is my username...
[23:55] <mark06> what is /var/lib//mlocate/mlocate.db?