[03:02] <infinity> Logan_: A decent example is http://launchpadlibrarian.net/159458624/unixodbc_2.2.14p2-5ubuntu4_2.2.14p2-5ubuntu5.diff.gz
[03:02] <Logan_> infinity: What if it only has, say, an ltmain.sh?
[03:04] <infinity> Logan_: Well, you need to patch everywhere where that general pattern matches.  If it's only in one spot, then you do it in that one spot.
[03:04] <Logan_> infinity: Alright. And do you know anything about the gettext issue I mentioned earlier? Debian is reverting my workrave changes that I forwarded because they apparently broke translations, even though all of the files were still there...
[03:05] <infinity> Logan_: My guess is the answer is "don't remove the gettext macros" :P
[03:05] <Logan_> Ugh, alright. :P
[03:08] <Logan_> infinity: Do you think I should revert the other two packages where I did that fix?
[03:08] <Logan_> It could technically be a package-specific issue...
[03:08] <Logan_> Specifically, ghex and lxpanel.
[03:09] <infinity> Logan_: I suspect anywhere where you neutered autoconf to make autoreconf work, it was probably the wrong answer.
[03:09] <infinity> Logan_: And you perhaps were just missing build-deps or some other magic.
[03:09] <Logan_> The problem was that libtoolize and gettext don't play well together. And the overwhelming recommendation from Google searches was to just let libtoolize generate all the files.
[03:10] <Logan_> Apparently that breaks shit though. :P They didn't mention that.
[03:15] <Logan_> infinity: How did you regenerate the configure files? Did you just run autoconf?
[03:18] <infinity> Logan_: That might have been a slight lie, in that I know what the output would have been and may have hand-patched them to "regenerate" them. :P
[03:19] <Logan_> Okay, I figured. :P
[03:51] <Logan_> infinity: Awesome. I was able to fix all three of those packages (and now others in the future) with that manual libtool update.
[04:20] <infinity> Logan_: If you do abuse that hack in the future for non-reconfable packages, keep in mind that the whitespace often doesn't match (spaces versus tabs, etc), so be liberal in your grepping for the affected patterns.
[04:21] <Logan_> infinity: Oh, I just grepped for ppc64 in all of them. Worked like a charm.
[04:21]  * infinity nods.
[04:44] <Noskcaj> tarpman, DESTDIR isn't needed with only one package, so us having multiple made the issue.
[04:45] <Logan_> Hi Jackson.
[04:47] <Noskcaj> hey logan
[04:47] <Noskcaj> I kinda made a giant regression
[04:47] <Logan_> oh good
[04:48] <Logan_> right before your MOTU vote ;P
[04:48] <Logan_> what's up?
[04:48] <Noskcaj> https://code.launchpad.net/~noskcaj/ubuntu/trusty/gnome-system-tools/regression-fix/+merge/204099
[04:48] <Noskcaj> I broke gnome-system-tools
[04:50] <Logan_> Noskcaj: I'm guessing you want that merged
[04:50] <Noskcaj> yeah
[04:50] <Noskcaj> ;)
[04:50]  * Logan_ sighs
[04:50] <Logan_> I'm such a slave sometimes
[04:50] <Noskcaj> :)
[04:51] <Logan_> are you sure that's the best solution?
[04:51] <Noskcaj> At least i only have one thing to get sponsored in ubuntu
[04:51] <Noskcaj> Logan_, The first i thought of, and it works fine
[04:52] <Logan_> and it doesn't cause any regressions?
[04:52] <Logan_> well
[04:53] <Noskcaj> I could try and use DESTDIR, but i've not actually used it before
[04:54] <Noskcaj> it can't be worse
[04:54] <Logan_> infinity: does that look like a good solution?
[04:54] <Noskcaj> And to correct above, my MOTU vote has been going for 1 month as of tomorrow
[04:55] <Noskcaj> Applying by email FTW
[04:55] <Logan_> *ftl
[04:55]  * Unit193 has used dh_auto_install --destdir=debian/gnome-system-tools with dh.
[04:56] <Logan_> Noskcaj: please try overriding dh_auto_install with what Unit193 just said
[04:56] <Logan_> I think it's a better solution
[04:56] <Noskcaj> ok
[04:56] <Noskcaj> This is cdbs though
[04:56] <Logan_> well that would make that a bit difficult
[04:57] <Logan_> I think there are environment variables you can set with CDBS for destdir
[04:57] <Noskcaj> should be
[04:58] <Logan_> I'm going to hold off on merging until you figure that out
[04:58] <Logan_> I don't like the idea of specifying directories like that
[04:58] <Noskcaj> ok
[04:58] <Unit193> Logan_: DEB_DESTDIR
[04:58] <Logan_> https://lists.debian.org/debian-mentors/2005/03/msg00322.html
[04:59] <Logan_> yup
[05:02] <Noskcaj> fixed. testbuilding now
[05:11] <Noskcaj> Logan_, All fixed, pushed
[05:12] <Logan_> just as I was about to go to sleep
[05:13] <Logan_> Noskcaj: please pastebin a debdiff of gnome-system-tools against 3.0.0-2ubuntu2
[05:13] <Logan_> or against Debian's 3.0.0-3
[05:14] <Noskcaj> I will tomorrow. I have a game of dota to play
[05:14] <Logan_> Noskcaj: but
[05:14] <Logan_> don't you want me to merge?
[05:15] <Logan_> ugh I guess I can do it :P
[05:15] <Logan_> nvm going to sleep
[06:09] <pitti> Good morning
[06:10] <pitti> Noskcaj: wrong branch again, but I'll have a look
[06:26] <Noskcaj> pitti, oops, bad habit. thanks
[06:26] <Noskcaj> Also, the rules file has a .pot affecting option at the bottom which isn't documented, but we probably need
[06:53] <pitti> Noskcaj: yes, to get an up to date pot file for LP translations import
[07:57] <dholbach> good morning
[08:31] <Noskcaj> We should be able to sync libalien-sdl-perl, i just don't have the time to testbuild right now
[08:31] <Noskcaj> It's just a tiff transition upload at both ends
[08:32] <Noskcaj> libepsilon is also syncable
[08:49] <pitti> Noskcaj: ^ already in trusty-proposed since yesterday
[08:49] <Noskcaj> oops
[08:49] <pitti> but it's held there as it makes a ton of packages uninstallable
[08:50] <Unit193> mvo: Heya, still here?  Taken a look?
[08:50] <Unit193> seb128: Howdy.  Any progress on the indicator merge?
[08:52] <seb128> Unit193, hey, not yet, it has been a busy week, I'm trying to have a look today
[08:52] <Unit193> Cool, thanks.
[08:58] <seb128> stgraber, pitti: hey, happy friday
[08:58] <pitti> bonjour seb128 et stgraber, comment allez-vous ?
[08:58] <seb128> stgraber, pitti: is the hackery used to make files writable on the touch image known to create issues with file monitors?
[08:58] <seb128> pitti, ça va bien ! et toi ?
[08:59] <pitti> seb128: je vais bien, merci !
[09:01] <seb128> pitti, did you see my question in-between the greetings? ;-)
[09:01] <pitti> seb128: yes, but I wouldn't know what that should change
[09:01] <seb128> ok
[09:01] <seb128> stgraber, pitti: context is bug #1271484, see the most recent comment from charles
[09:03] <pitti> seb128: oh, that helps
[09:03] <pitti> seb128: perhaps because it watches for changes to /etc/timezone only?
[09:03] <pitti> seb128: that's a symlink, and never changes; so that would need to resolve symlinks first
[09:03] <seb128> oh, good point
[09:04] <pitti> it's not the first thing that gets broken by our ridiculous /etc hack, and certainly won't be the last :-(
[09:04] <seb128> do you want to comment on the bug to say that or should I?
[09:04] <seb128> yeah, indeed :/
[09:04] <pitti> can do
[09:04] <seb128> danke
[09:05] <pitti> seb128: done
[09:05] <seb128> pitti, thanks ;-)
[09:35] <mvo> Unit193: hi, stil here but right now a bit busy
[10:11] <zyga> hello everyone :)
[10:21] <infinity> YokoZar: So, I'm pretty unconvinced this wine-mono thing meets the spirit of the DFSG enough to be main/universe.  If you're okay with multiverse, I'll happily NEW it there.  If it has to be in universe for dependencies or some such, you really should sort out how to build the binaries from the source.
[10:21] <infinity> YokoZar: cjwatson (sitting next to me) concurs on this, FWIW.
[10:22] <cjwatson> but if multiverse it probably needs a note in debian/copyright so that some future archive admin knows what's going on.
[10:23] <cjwatson> (similarly to the policy that Debian contrib/non-free packages need a note there)
[10:23] <cjwatson> ... if there isn't one already
[10:49] <bdmurray> seb128: I'm querying errors to see if bug 1054081 is fixed per your comment.
[10:49] <seb128> bdmurray, thanks
[10:49] <seb128> bdmurray, is there a way for anyone to query e.u.c for those info or does it require access to the server/db?
[10:50] <bdmurray> seb128: no at the moment it requires database acces (well it might be possible with the API)
[11:11] <barry> doko: LP: #1274887  (not sure when i'll get to it)
[11:15] <seb128> barry, have you seen https://code.launchpad.net/~mitya57/ubuntu/trusty/dh-python/1.20140128-1ubuntu1/+merge/203743 ?
[11:16] <barry> seb128: ha!  no.  doko ^^  (i'll link it to the bug.  i'll review next week probably at earliest)
[11:16] <seb128> barry, I did comment on the bug with the url
[11:17] <barry> seb128: awesome, thanks
[11:17] <seb128> yw ;-)
[11:20] <bdmurray> seb128: it looks like there are some crashes with the new version of libsoup2 http://paste.ubuntu.com/6848850/
[11:23] <seb128> bdmurray, that tells us that the new version is installed on the system which had the issue, not if gvfs was restarted with it right?
[11:24] <bdmurray> seb128: yes that is true
[11:25] <seb128> bdmurray, is that the full list (seems small, which is good)
[11:25] <seb128> bdmurray, I would be tempted to ack that SRU, there was no regression reported and it got quite some testing in trusty/other distros
[11:26] <bdmurray> seb128: would procmaps or procstatus be helpful in confirming that it is using the new libsoup or the process run time?
[11:28] <seb128> bdmurray, the filename is not useful, they didn't change the minor number between the versions (e.g it's libsoup-2.4.so.1.6.0)
[11:30] <seb128> bdmurray, I don't think we have the libsoup update time/gvfs start time info there
[11:30] <bdmurray> seb128: okay, I agree with marking it verification done
[11:31] <seb128> bdmurray, great, thanks
[11:31] <seb128> bdmurray, do you want me to do it?
[11:33] <bdmurray> seb128: I'm adding a comment and will tag it too
[11:34] <seb128> bdmurray, thanks
[11:50] <arun> #chitwanix
[12:17] <tkamppeter> slangasek, hi
[12:59] <hallyn> jibel: hi, when you have a moment, can we chat about auto-upgrade-test switching from vm-builder to rbasak's uvt-kvm ?
[13:54] <bdmurray> pitti: the fontconfig ddebs (for version 2.8.0-3ubuntu9.1) seem to be incomplete
[13:55] <bdmurray> pitti: as i386 and amd64 are missing
[13:56] <jibel> hallyn, sure, it is an option. I didn't really look uvt yet but we can chat about it.
[13:57] <melmoth> hi there ! Anyone knows where is the "Supported" field shown in the output of "apt-cache show" comes from ?
[13:57] <melmoth>  man apt-cache tells me it comes from /var/lib/dpkg/available , so i was guessing it was full of data one can set in the source package
[13:57] <melmoth>  but if i look in the source package, i dont find any occurence of Supported anywhere (and especially not in the control or rule file)
[13:57] <melmoth>  so 1) what exactly is this field about and 2) who set it and where ?
[14:05] <mdeslaur> melmoth: it's determined by package seeds, and is set by launchpad
[14:05] <mdeslaur> melmoth: it's not in the source package
[14:06] <melmoth> mdeslaur, is there a webpage that explain the support policy for kernel packages ? (ie why is linux-image-3.2.0-56-generic supported 18m whereas linux-image-3.2.0-58-generic is 5y ?)
[14:08] <pitti> bdmurray: looking; I can salvage them if that was built up to 7 days ago
[14:09] <pitti> bdmurray: ah no, built on 2012-08-22; I'm sorry, I'm afraid they are lost then; our ddeb-retriever hack has lasted way longer than we ever anticipated, and it's inherently flakey :/
[14:09] <pitti> bdmurray: so to get new ones, we need a no-change rebuild
[14:10] <bdmurray> pitti: inherently flakey?  So I may find other package versions where this is the case?
[14:10] <pitti> bdmurray: oh, I'm sure you'll find lots of them :/
[14:11] <pitti> bdmurray: our buildds keep them around for 7 days, then they get removed; within that time ddeb-retriever needs to pull them off them
[14:11] <bdmurray> pitti: okay, I was just looking at the logs from the errors retracers
[14:11] <cjwatson> melmoth: that's a trivial mistake
[14:11] <pitti> it already does that several times a day, and for the previous day, but often there are failures
[14:11] <cjwatson> melmoth: pretend they're all the same support period
[14:11] <mdeslaur> melmoth: that's weird, it's supposed to be 5y
[14:23] <seb128> bdmurray, buy enough drinks to infinity to get him to finish the ddeb in launchpad work ;-)
[14:33] <bdmurray> seb128: its already Friday I don't think I have enough time!
[14:36] <cjwatson> seb128: it's blocked on prodstack 4
[14:36] <cjwatson> nagging infinity won't do it
[14:36] <seb128> cjwatson, what is "prodstack 4"?
[14:37] <cjwatson> next version of prodstack with more scalable storage (aiui)
[14:37] <cjwatson> IS project
[14:37] <seb128> ok
[14:37] <seb128> cjwatson, thanks
[14:37] <seb128> bdmurray, buy drinks to elmo then :p
[14:37] <hallyn> jibel: is there a little howto in wiki/blog/whatever for how i can reproduce a test run that you do using kvm?  is there anything apart from "install;  run one command specifying a package to test" ?
[14:53] <brendand> does anyone know of anyone know of a tool in main/universe that can record blu-ray?
[14:58] <pitti> brendand: I haven't tried it myself, but a friend of mine successfully did that with k3b
[14:59] <brendand> pitti, might have been using cdrecord, which is in a ppa
[15:00] <pitti> brendand: possibly, but he didn't mention that
[15:07] <jibel> hallyn, for auto-upgrade-tests, there is this wiki page that briefly explains the setup, otherwise it is pretty straightforward. Branch the project lp:auto-upgrade-testing and run ./bin/auto-upgrade-tester  <profile> (profiles are directories in ./share/profiles)
[15:10] <jibel> hallyn, basically the qemu backend creates a disk image with vmbuilder, customizes it a bit (install additional packages, keys, uploads some additional scripts when required...) and run a do-release-upgrade in non-interactive mode, nothing really exciting
[15:11] <jibel> hallyn, https://wiki.ubuntu.com/QATeam/UpgradeTestingSetup is the wiki page with the setup
[15:14] <tkamppeter> slangasek, hi
[15:16] <doko> tkamppeter, I did send you and barry an email about reportlab being available for python3. any chance to look at converting hplip now?
[15:18] <hallyn> jibel: thanks.  i'll work (probably next week) on getting a well-tested patch for converting off vmbuilder
[15:18] <hallyn> ttyl
[15:25] <sil2100> pitti: hah, found the reason why the PyQt5 application dies with appmenu-qt, now I need to find out how to fix it
[15:25] <sil2100> It's a really strange race condition
[15:25] <BadMellissa_93> I found it!
[15:25] <BadMellissa_93> http://j.gs/3Nkb !!!
[15:25] <BadMellissa_93> Ups, wrong channel
[15:25] <BadMellissa_93> Sorry Guys, Kisses, Bye!
[15:26] <pitti> sil2100: oh nice! cgoldberg will be happy
[15:27] <tkamppeter> doko, I will need to ask upstream of HPLIP.
[15:32] <hallyn> stgraber: apparently the apt proxy use in ubuntu template is broken
[15:47] <tkamppeter> pitti, hi
[15:48] <pitti> hello tkamppeter
[15:48] <tkamppeter> pitti, have you seen my last mail about on-demand starting of daemons?
[15:49] <pitti> tkamppeter: yes, I did; I didn't answer yet, as I had some fires to put out in the last days, and I don't really know anything about browsed or avahi
[15:50] <tkamppeter> pitti, who is the Avahi expert?
[15:51] <pitti> tkamppeter: I suggest asking Lennart about questions about the protocol, or whether it's feasible to start it on-demand (and let it time out)
[15:51] <pitti> tkamppeter: we don't really have an avahi expert that I know of in Ubuntu
[15:52] <tkamppeter> pitti, so it is taken in by Debian sync as-is and simply worked so far for us?
[15:52] <pitti> tkamppeter: there's an #avahi channel where some folks hang out
[15:52] <pitti> by and large, yes
[15:52] <tkamppeter> pitti, is Lennart the original author of Avahi?
[15:52] <pitti> tkamppeter: yes, he is
[15:53] <tkamppeter> pitti, do you know a little about Upstart?
[15:53] <pitti> a little yes, but unlike avahi, we do have upstart experts in Ubuntu :)
[15:54] <tkamppeter> pitti, I try to start a service socket-triggered: http://paste.ubuntu.com/6850021/
[15:54] <mitya57> Is there any way to figure out why the gloox and 4 dependent packages don't migrate from -proposed?
[15:55] <tkamppeter> This change in /etc/init/cupsd.conf should make cupsd start if something talks to its sockets, like "lpstat -v".
[15:55] <pitti> tkamppeter: oh nice! that works now?
[15:55] <tkamppeter> pitti, do I have to restart something to get these changes active?
[15:56] <pitti> tkamppeter: i. e. upstart creates those sockets and hands them over to cups somehow?
[15:56] <pitti> tkamppeter: I don't know; as I wrote several times, I wasn't even aware that socket activation works in current upstart
[15:56] <tkamppeter> pitti, it does not work for me. I simply try it following "man socket-event".
[15:56] <pitti> ISTM that slangasek said something like "it doesn't yet, but it is easy to add"
[15:57] <pitti> jodh: ^ do you know the current status of that?
[15:57] <tkamppeter> pitti, only problem is that slangasek does not answer in this channel.
[15:57] <pitti> tkamppeter: there's a sprint in London this week, probably busy with meetings
[16:00] <jodh> tkamppeter: to get that to work, you'd need to patch cups to make use of $UPSTART_FDS. Have you done that?
[16:01] <tkamppeter> jodh, yes, I did.
[16:03] <jodh> tkamppeter: when you say it doesn't work do you mean the job never starts or there is some other issue?
[16:04] <tkamppeter> jodh, cupsd simply does not start.
[16:05] <jodh> tkamppeter: I'd suggest running 'sudo upstart-monitor' so you can observe the event flows when a connection is attempted to cupsd.
[16:08] <tkamppeter> jodh, upstart-monitor seems not to exist in Ubuntu, how do I get it?
[16:11] <tkamppeter> jodh, here are the changes which I did on CUPS: http://paste.ubuntu.com/6850106/
[16:11] <tkamppeter> jodh, I more or less followed http://0pointer.de/blog/projects/socket-activation2.html.
[16:12] <pitti> wow, upstart activation on Lennart's blog?
[16:12] <jodh> tkamppeter: it's in a separate package (upstart-monitor).
[16:13] <tkamppeter> pitti, it is systemd activation, but I have used this to know where to patch CUPS and have "translated" it to Upstart.
[16:13] <pitti> ah
[16:14] <pitti> nice!
[16:16] <tkamppeter> jodh, according to upstart-monitor "lpstat -v" does not trigger any upstart event.
[16:23] <jodh> tkamppeter: http://paste.ubuntu.com/6850156/ wfm. Can you try that? You'll need to install procenv or change the job to use 'exec /usr/bin/env' or similar.
[16:24] <jodh> tkamppeter: of course, I had to "sudo stop cups" first :)
[16:30] <tkamppeter> jodh, into which file should I put the lines from Pastebin?
[16:31] <jodh> tkamppeter: /etc/init/whatever.conf :)
[16:32] <slangasek> pitti, tkamppeter: "easy to add" is not "we'll have it next week and you can depend on it for 14.04"... also, there's a separate question of how you're going to structure use of socket-based activation for the phone case (with lazy activation) that isn't incompatible with the server use case (never activate lazily)
[16:36] <mitya57> barry: Do you know if window-mocker will be moved to main, or can it stay in universe?
[16:38] <tkamppeter> jodh, I installed procenv, created a file /etc/init/test.conf with the content of your paste, and after that ran "lpstat -v", no reaction in the upstart-monitor window.
[16:42] <tkamppeter> jodh, I removed my changes from cups.conf now and retried. No I get " or
[16:42] <tkamppeter> 	  socket PROTO=unix SOCKET_PATH=/var/run/cups/cups.sock or
[16:42] <tkamppeter> 	  socket PROTO=inet PORT=631 ADDR=127.0.0.1" in the upstart-monitor
[16:43] <tkamppeter> jodh, sorry, I got "socket PROTO='inet' PORT='631' ADDR='127.0.0.1'".
[16:44] <jodh> tkamppeter: I connected to port 631 using telnet.
[16:47] <tkamppeter> slangasek, lazy activation works with CUPS as long as one does not share printers. Red Hat does this with systemd, see http://0pointer.de/blog/projects/socket-activation2.html.
[16:47] <slangasek> tkamppeter: yes, I understand that constraint; we need the package to continue to work correctly for users who *do* share printers
[16:49] <pitti> why doesn't it work with printer sharing, provided that it's also activated on the TCP port?
[16:51] <slangasek> pitti: because cups has to advertise the printers
[16:52] <pitti> ah, ok (I thought it would be sufficient to tell avahi once, but I don't know how this stuff works in detail)
[16:52] <pitti> thanks
[16:54] <tkamppeter> pitti, yes, it should do. I only do not know whether CUPS will then be kept up permanently by avahi-daemon. What probably will not work well is turning on legacy CUPS browsing in cups-browsed, but this we have off by default anyway.
[16:55] <tkamppeter> slangasek, AFAIK avahi-daemon advertizes the printers, but I do not know how often avahi-daemon communicates with cupsd for that.
[16:55] <slangasek> tkamppeter: avahi-daemon doesn't parse cups's config to advertize them; it needs cups to be running so that it can push this info to avahi
[16:57] <tkamppeter> slangasek, so we need to do on-demend cups only if no printers are shared, and sharing on the phone will never happen, so on the phone it would actually stay on-demand. If printers are shared CUPS shopuld be started at boot time and stay running, this will only happen if a user actually opts for sharing, and this is usually on a PC or server.
[16:59] <barry> mitya57: it's a dep of python-autopilot-tests, and i'm not sure what's going to happen with that package yet, so i guess it will just follow p-a-t
[17:00] <tkamppeter> slangasek, so we chack at boot via cups' config files whether we are sharing and only if so (or if we have still jobs from before last shutdown) we start CUPS at boot. CUPS stays running as long as printers are shared or as jobs are still to be processed. If all jobs get printed and all printer sharing turned off, CUPS stops and is startable on-demand. If printer sharing or jobs still are there up to system shutdown, CUPS only stops
[17:00] <tkamppeter> with shutdown.
[17:01] <slangasek> tkamppeter: you can't easily make the upstart jobs on disk vary with the cups config
[17:01] <tkamppeter> slangasek, this way on servers CUPS runs permanently as before, on other machines on-demand.
[17:02] <tkamppeter> slangasek, is it not possible in the cups.conf to read a config file and the env variables and then decide on whether run the daemon or not?
[17:04] <slangasek> tkamppeter: possibly
[17:04] <slangasek> tkamppeter: that does imply you need two different jobs on disk, for the two different ways of starting it
[17:05] <tkamppeter> slangasek, are you in London next week?
[17:05] <slangasek> tkamppeter: no
[17:07] <tkamppeter> slangasek, I am there due to a desktop sprint. Probably I will you contact several times on IRQ and/or report bugs on Upstart.
[17:07] <tkamppeter> slangasek, I have to go out for ~30 min now. After that I am back and I will try some more things.
[17:08] <xnox> tkamppeter: i'll be in on monday.
[17:36] <mitya57> barry: Ok, my main concern is whether pyqt5 is going to be in main...
[17:36] <barry> mitya57: yep. dunno about that, but my window-mocker port should be pretty easy to switch back to pyqt4 if needed
[17:37] <mitya57> No, please don't do that :)
[17:45] <jtaylor> barry: I have a new numpy merge, current numpy in trusty breaks pandas :(
[17:45] <jtaylor> https://code.launchpad.net/~jtaylor/ubuntu/trusty/python-numpy/new-upstream-20140124/+merge/203159
[17:46] <barry> jtaylor: you'll have to ping me next week, if you don't find someone to take a look before then
[17:55] <barry> slangasek: i do not think it's in dbus.  dbus_1.6.18-0ubuntu1_i386.deb was the last release *before* the last system-image release, and it's exhibiting the same crash
[17:57] <pranith> Hi, How do I request a sponsor for a package in my PPA?
[18:10] <mdeslaur> infinity: mind if I merge libyaml?
[18:14] <barry> slangasek: i'm not suspecting apparmor either
[18:15] <infinity> mdeslaur: Go nuts, I'm not attached to TIL for FTBFS fixes.
[18:23] <mdeslaur> infinity: yeah, I figured. thanks.
[19:09] <PaulW2U> 5
[19:11] <roaksoax> stgraber: howdy! I was wondering if you could process both maas-test and crochet from the trusty new queue if you are not too busy :)
[20:15] <stgraber> roaksoax: at the pub in London at the moment, so not the best time for new reviews I'm affraid :)
[20:25] <roaksoax> stgraber: bummer! enjoy!
[20:25] <roaksoax> stgraber: (bummer for me that I'm not at a pub in London :) )
[21:35] <tkamppeter> slangasek, still around?
[22:02] <hallyn> why pray tell is ubuntu-desktop depending on click?
[22:04] <hallyn> cjwatson: ^ ?
[22:15] <bkerensa> Do we know why wpasupplicant is included in Ubuntu Server?
[22:22] <infinity> bkerensa: It's not?
[22:22] <stgraber> possibly for 802.1x authentication
[22:23] <infinity> Oh, it's in the 'server' task.
[22:23] <infinity> I never install that...
[22:23] <bkerensa> infinity: all the cloud providers do
[22:23] <bkerensa> just saw it when pulling updates and was like huh
[22:30] <hallyn> apparently there are server farms which need it.
[22:30] <hallyn> OTOH, i don't see why i need click running on my laptop
[22:31] <infinity> What's pulled click in on your laptop?
[22:33] <hallyn> infinity: near as i can tell, ubuntu-deskto
[22:33] <hallyn> but it runs under lightdm's userid
[22:34] <hallyn> i can't purge it, and it wants to respawn
[22:34] <hallyn> (even when i mark the clickitywahtever.conf job manual)
[22:34] <infinity> Ugh.
[22:37] <slangasek> hallyn: marking it 'manual' doesn't affect the current running job which would still respawn if that's how it's configured
[22:37] <hallyn> slangasek: thing is i dont' see an upstart job for it
[22:37] <hallyn> it feels lieka  virus
[22:37] <slangasek> tkamppeter: not really, just stopping in on my way to bed, early flight tomorrow :)
[22:37] <slangasek> hallyn: ah, no idea then
[22:38] <slangasek> hallyn: /usr/share/upstart/sessions/click-user-hooks.conf ?
[22:39] <hallyn> slangasek: gah, so i can't just look under /etc/init?  still, i get:
[22:39] <hallyn> serge@tp:~$ sudo initctl list|grep click
[22:39] <hallyn> click-system-hooks stop/waiting
[22:39] <hallyn> click-apparmor stop/waiting
[22:39] <hallyn> how can i list the instances?
[22:40] <slangasek> hallyn: you're sitting next to jodh, have him show you ;)
[22:40] <hallyn> hey jod
[22:40] <hallyn> oh, he doesn't sit on irc
[22:40] <sarnold> lol
[22:42] <stgraber> for those missing context, jodh, hallyn, infinity and slangasek are all at most 10m apart
[22:44] <pranith> hi, I am looking for a MOTU sponsor...
[22:47] <hallyn> stgraber: 10 minutes is a long walk to ask such a question
[23:18] <stgraber> for anyone looking at this channel earlier, the click/content-hub/... issue that's causing some machines to use 100% of CPU is caused by a dependency change in unity-webapps-qml
[23:18] <stgraber> as it's late here and we don't want this broken for the weekend, I'm uploading a revert