[00:01] <mwhudson> root@localhost:~# start plymouth
[00:01] <mwhudson> plymouth start/running, process 1127
[00:01] <mwhudson> root@localhost:~# plymouth --ping
[00:01] <mwhudson> root@localhost:~# echo $?
[00:01] <mwhudson> 0
[00:01] <mwhudson> seems better
[00:30] <straemer> Hey, I'm interested in doing some bug-fixing for the ubuntu one music android app. Would anyone be able to show me where to get started on that?
[00:31] <sarnold> straemer: (guessing) try #ubuntuone  ?
[00:33] <straemer> sarnold: I think that's a support channel
[00:33] <sarnold> straemer: ah :) darn, sorry
[01:07] <mwhudson> ok now i'm reading the mountall source
[01:07] <mwhudson> time to get out of the rabbit hole i think
[04:02] <pitti> Good morning
[06:03] <mlankhorst> morningg
[06:15] <infinity> didrocks: The new webapps-application pulls a few things into main without an MIR.  Was someone going to do something about that?
[06:16] <infinity> didrocks: Specifically gjs and mozjs.
[06:16] <didrocks> infinity: we are going to demote all those scripts to universe AFAIK
[06:17] <infinity> didrocks: "All those scripts"?
[06:17] <didrocks> so I guess webapps-application is part of it
[06:17] <infinity> didrocks: As in, unseed unity-webapps-common?
[06:17] <didrocks> infinity: indeed, I still need to do a final check with robru, but that's what I understood
[06:18] <infinity> didrocks: Alright.  Well, as soon as you know, please yank it from the seeds and I'll demote with extreme prejudice. ;)
[06:18] <didrocks> infinity: ahah, I'll maybe take that demoting pleasure for myself TBH. This has been such a pain :p
[06:19] <robru> didrocks: infinity: hi
[06:20] <didrocks> oh, a robru!
[06:20] <robru> I don't know about whether or not this stuff needs to be in main. that's a strategical question that you'd need to ask to somebody who makes plans. I just do what people tell me
[06:21] <didrocks> robru: so, IIRC, the plan of record is to have all the scripts in universe, right?
[06:21] <didrocks> robru: as we even don't install the firefox nor the chromium extension by default
[06:21] <robru> didrocks: is that so? but I thought we were prompting people to install webapps by default
[06:23] <robru> didrocks: maybe vrruiz is a better person to ask about this.
[06:23] <didrocks> robru: I'm still lost in all that maze of webapps*, where is the firefox extension?
[06:23] <robru> didrocks: I don't think the browser extensions are enabled for daily release yet, only CI
[06:23] <didrocks> robru: yeah, I just need the name of the extension :)
[06:24] <didrocks> robru: IIRC, the goal was: extension in main, all scripts in universe (including -common)
[06:24] <robru> didrocks: ok, so it's unity-firefox-extension and unity-chromium-extension
[06:25] <didrocks> ok, the extension is still in main for firefox
[06:25] <robru> didrocks: as long as we end up in a situation where the default ubuntu install will prompt users to install webapps, then I think we're ok. I don't personally have any stake in whether the apps are living in main or universe.
[06:25]  * robru just wants this nightmare to end
[06:25] <didrocks> ah, there are those desktop files we install by default though :/
[06:25] <didrocks> robru: I'm afraid that -common still need to be in main for now
[06:26] <robru> didrocks: just amazon and ubuntuone-music right?
[06:26] <didrocks> robru: right
[06:26] <robru> didrocks: so it sounds like those .desktop files need to be in a different package so that we don't bring in gjs into main with -common package
[06:27] <didrocks> robru: gjs is used for your lintian script?
[06:28] <robru> didrocks: nope, gjs is used for style_checker.js, which is a wrapper around jslint. that's different than my linter script (jslint is linting js syntax, my linter is linting the packages, ensuring that translations are present, etc.)
[06:28] <didrocks> robru: style_checker.js is run during package build?
[06:28] <robru> didrocks: yeah
[06:29] <robru> didrocks: yeah, there's no way around depending on gjs in -common, that's the closest thing we have to test coverage at the moment.
[06:30] <didrocks> robru: in fact, I think we should move them
[06:30] <didrocks> robru: scripts/third_party/jslint.js usr/share/unity-webapps/tools/
[06:30] <didrocks> common/rules.mk usr/share/unity-webapps/
[06:30] <dholbach> good morning
[06:31] <didrocks> those should be move to another package (same source)
[06:31] <didrocks> but another binary
[06:31] <robru> didrocks: ok, that can be done
[06:31] <didrocks> we can call it unity-webapps-script-build
[06:31] <didrocks> robru: or any better word ^
[06:31] <robru> didrocks: but keep in mind, either the -common package will have to depend on it, or we'll have to edit all 41 apps to depend on this new package too
[06:31] <didrocks> having all the script biuld-dep on it
[06:31] <didrocks> (yeah, I know :/)
[06:32] <didrocks> robru: but you have sed foo now :)
[06:32] <robru> didrocks: unity-webapps-dev
[06:32] <didrocks> robru: excellent :)
[06:32] <didrocks> and this one has the gjs dep
[06:32] <didrocks> will be in universe
[06:32] <didrocks> with all the scripts in universe
[06:32] <didrocks> robru: do you think you'll have time to do that? any idea once this can be done (so that we can clear the mismatch components)
[06:33] <robru> didrocks: if you make me push 41 MPs I am going to scream. I'll just commit those packaging changes directly to trunk
[06:33] <didrocks> (this has the benefit to not ship -dev content on user's machine as well)
[06:33] <didrocks> robru: direct commit is fine :)
[06:33] <didrocks> hey dholbach!
[06:33] <dholbach> hey didrocks
[06:33] <robru> didrocks: I can do that right now.
[06:33] <didrocks> robru: \o/
[06:33] <didrocks> robru: we are *almost* there!
[06:34] <robru> didrocks: ;-)
[06:34] <didrocks> robru: btw, I relaunched the daily for webapps
[06:34] <didrocks> robru: as I relaxed now the constrain to have the bootstrap commit message for distro
[06:34] <robru> didrocks: this is going to cause another bootstrapping nightmare, isn't it? we'll need unity-webapps-dev pushed everywhere
[06:35] <robru> didrocks: I saw your improvements to the changelog generation, very nice.
[06:35] <didrocks> robru: well, I'll handle it, it's juts an upload to distro and to the ppa
[06:35] <didrocks> robru: great ;)
[06:35] <didrocks> robru: just put this unity-webapps-dev to review please :)
[06:35] <robru> didrocks: right
[06:37] <infinity> didrocks, robru: Thanks for the prompt handling.  Maybe you can teach the server team how to deal with component mismatches. ;)
[06:39] <didrocks> infinity: ahah, yw! Sorry for introducing it first :-)
[06:45] <robru> didrocks: https://code.launchpad.net/~robru/webapps-applications/dev/+merge/163848
[06:48] <robru> didrocks: wait, build just failed locally. bah
[06:49] <didrocks> robru: commenting
[06:51] <robru> didrocks: ugh, I'm confused. my changes are causing dh_install --fail-missing to fail. I have no idea why... it says utils.js is not installed to anywhere, but I didn't change anything about utils.js (and trunk builds fine)
[06:51] <robru> didrocks: and I added a line to unity-webapps-common.install to explicitly install it, but it doesn't help.
[06:52] <didrocks> robru: I smell you forgot a bzr add unity-webapps-dev.install :)
[06:52] <robru> didrocks: nope, if that were the case it'd be complaining about the files that go in the -dev package. it's complaining about files that should be in the -common package
[06:54] <didrocks> robru: let me bzr branch
[06:54] <robru> didrocks: please take my branch and do a 'bzr bd' in it, total mystery to me
[06:55] <didrocks> robru: grep utils.js debian/*
[06:55] <didrocks> -> nothing
[06:56] <didrocks> robru: shouldn't you list usr/share/unity-webapps/userscripts/common/ in -common.install?
[06:56] <robru> didrocks: yeah, well, build trunk and it works!
[06:56] <robru> didrocks: but I added that line, like you would obviously expect to find, and it didn't make a difference.
[06:57] <didrocks> robru: trunk built because your .install file was not that relevant (no debian/tmp for just one binary)
[06:58] <didrocks> robru: added usr/share/unity-webapps/userscripts/common to debian/unity-webapps-common.install works here
[06:58] <didrocks> the build pass then, and all files that we need to install are installed :)
[07:00] <robru> didrocks: no idea
[07:00] <robru> didrocks: anyway, pushed. please approve
[07:01] <didrocks> robru: please set to UNRELEASED
[07:01] <didrocks> robru: not saucy
[07:01] <didrocks> in debian/changelog
[07:01] <didrocks> other than that, looking good
[07:02] <didrocks> (and wrap to 80 characters :p)
[07:02] <didrocks> robru: I wonder why emacs didn't forbid you to save the file with all your automation :-)
[07:02] <robru> didrocks: rushing
[07:02] <robru> didrocks: it does display the long line with big angry red letters though
[07:04] <didrocks> ahah ;)
[07:06] <didrocks> robru: thanks! approving now
[07:06] <didrocks> robru: once it's merged, I'll upload to saucy and the ppa for the boostrap
[07:06] <didrocks> bootstrap*
[07:06] <robru> didrocks: should I wait for you to be ready before pushing commits to the webapps trunks? or can I do that now
[07:06] <robru> ?
[07:07] <didrocks> robru: well, just show a diff and I will tell you yes/no, then, just push :)
[07:07] <didrocks> robru: it's just about appending on build-dep I guess
[07:07] <robru> didrocks: I am literally just going go s/unity-webapps-common/unity-webapps-dev in the control files
[07:08] <didrocks> robru: you don't need -common still for the usr/share/unity-webapps/userscripts/common/* content to build the scripts?
[07:08] <didrocks> (honest question, I have no idea ;))
[07:09] <robru> didrocks: I guess so. -dev should have depended on -common though, oops ;-)
[07:09] <didrocks> robru: I came to the exact same conclusion :)
[07:09] <didrocks> robru: I aborted the merge, please push an extra rev :)
[07:09] <robru> didrocks: it's fine. I'm just pulling all the webapps branches now, once that's done I'll show you one diff and then push identical changes to all branches
[07:09] <robru> didrocks: oh, ok
[07:11] <pitti> infinity: I tried to reproduce the libsoup2.4 armhf test case failure (leading to ftbfs) on my nexus; with plain dpkg-buildpackage, with and without fakeroot, our code vs. upstream git head, etc; it always works there
[07:11] <pitti> infinity: is it possible to somehow get ssh access to a buildd-like machine?
[07:12] <pitti> mbiebl: ^ FYI (affects Debian as well)
[07:13] <infinity> cache-test: 1 error(s). Run with '-d' for details
[07:13] <infinity> FAIL: cache-test
[07:13] <infinity> ^-- If only it then DID that, so we had details in the build log...
[07:14] <robru> didrocks: http://paste.ubuntu.com/5666777/ I am going to push this to all 41 webapps branches
[07:14] <didrocks> robru: excellent :)
[07:15] <didrocks> robru: I approved your additional commit bw
[07:15] <didrocks> btw*
[07:15] <robru> didrocks: great
[07:17] <robru> didrocks: ok, pushing
[07:17] <pitti> infinity: yeah, the makefile doesn't pass that on; we can temporarily call it manually in debian/rules, but that will also just list the individual tests, not why it's failing
[07:17] <pitti> infinity: do we have a PPA where I can throw lots of test builds in, so that I don't have to clutter the actual archive?
[07:17] <pitti> (which builds arm)
[07:17] <infinity> pitti: We do, but let me give this a whirl locally first.
[07:18] <infinity> pitti: Was your nexus7 test with a buildd chroot?
[07:19] <pitti> infinity: no, just standard phablet installation
[07:19] <infinity> Is that saucy?
[07:20] <pitti> it's raring, but I got saucy's source
[07:20] <pitti> oh, I guess I should upgrade to saucy's glib
[07:20] <infinity> pitti: But not saucy's toolchain.
[07:20] <infinity> pitti: Which is gcc-4.8...
[07:20] <pitti> ack
[07:21] <infinity> pitti: Better off just grabbing the chroot tarball from LP and using that.
[07:21] <infinity> https://api.launchpad.net/1.0/ubuntu/saucy/armhf
[07:21] <pitti> oh, handy!
[07:22] <infinity> Just untar that, fix resolv.conf, mount /proc and /dev/pts, dist-upgrade, and go to town. :P
[07:22] <infinity> Should be easier than going piecemeal on your phablet install.
[07:22] <robru> didrocks: ok, done pushing the s/-common/-dev/ change for all webapps
[07:23] <robru> didrocks: is that all you need from me? I'm thinking about going to sleep ;-)
[07:23] <didrocks> robru: excellent! as you saw, the previous daily run worked, but it's in manual publishing mode due to the packaging changes (and upstream stack, like the QA one failing)
[07:23] <infinity> pitti: Anyhow, also running here on a Panda, but I really doubt the kernel or hardware are your issue here.
[07:23] <didrocks> robru: so I'll push -common once it's merged manually to bootstrap
[07:23] <didrocks> robru: then run the daily
[07:24] <robru> didrocks: you mean push -dev, but yeah
[07:24] <didrocks> robru: then manually publish (as the failure from QA stack doesn't impact us)
[07:24] <didrocks> robru: yeah, the source package containing both :)
[07:24] <didrocks> robru: and I think we'll be done then! :-)
[07:24] <robru> didrocks: the source package is called webapps-applications. I wonder if it would be too much of a pain to name that more meaningfully
[07:25] <didrocks> robru: yeah, I'm also trying to bzr branch lp:<something>-common, but let's keep it that way for now
[07:25] <robru> yeah, we would need to rename the lp project and everything, total pain
[07:25] <didrocks> yep
[07:26] <robru> didrocks: ok, g'night then.
[07:26] <didrocks> robru: enjoy your (relatively early this time ;)) night!
[07:40] <pitti> meh, no overlayfs or aufs on nexus kernel?
[07:40]  * pitti repacks the unpacked chroot to not have a top-level directory then, to use it in tarball mode
[07:43] <infinity> pitti: FFS, it didn't fail here.
[07:43] <infinity> My test chroot wasn't entirely clean, but...
[07:54] <pitti> aah, now I have schroot -c saucy working on the nexus at last
[07:54] <tjaalton> siretart: hey, any reason not to sync libva & intel-vaapi-driver from experimental for saucy? I have gstreamer-vaapi updated for gst1.0 and would like to test these on haswell too
[08:20] <infinity> pitti: Ah, the cache test failure is intermittent.  Re-running make check, I tripped it.
[08:20] <pitti> ah, it seemed to happen fairly consistently on the buildds in the last few builds
[08:20] <infinity> pitti: And, indeed, a retry on the buildd succeeded.
[08:20] <pitti> infinity: I now have sbuild etc. set up, libsoup building ATM
[08:20] <pitti> infinity: oh, handy; I'll still see if I can reproduce it here
[08:20] <pitti> buildds are pandas, right?
[08:21] <pitti> (i. e. slightly slower than nexus 7)
[08:21] <infinity> pitti: http://paste.ubuntu.com/5666948/
[08:22] <infinity> pitti: buildds are Pandas, yes.
[08:22] <pitti> "leaked GInputStream!
[08:22] <infinity> pitti: Took me about 10 tries to get that failure.
[08:23] <infinity> pitti: So, it could just be racy, and slow machines trip it more easily.
[08:23] <infinity> pitti: Which would explain my slightly faster Panda doing better than the slower ones in the DC.
[08:23] <infinity> pitti: And Debian's much slower buildds always failing.
[08:23] <infinity> pitti: And x86/ppc having no issues.
[08:23] <infinity> (ie: it might not be ARM-specific)
[08:23]  * pitti runs (set -e; for i in `seq 50`; do echo "[08:25]  * pitti runs again with a find / in the background
[08:25] <infinity> pitti: Same failure on mipsel (which is also notoriously slow) seems to back up my wild guess.
[08:25] <pitti> infinity: ack, very much sounds like a race; thanks for confirming!
[08:25] <infinity> pitti: Try to reproduce it on eder.debian.org ... No time like the present, doko's building GCC in the background. :P
[08:27] <seb128> pitti, https://bugzilla.gnome.org/show_bug.cgi?id=698305 ?
[08:27] <seb128> pitti, just pointing the bug for reference, it has no info/patch/...
[08:27] <pitti> yep
[08:28] <pitti> seb128: that's the one I have chased for the past two hours now..
[08:28] <seb128> pitti, thanks for looking into that!
[08:28] <seb128> pitti, I tried for a bit before pinged you, but had no luck :/
[08:33] <mbiebl> pitti: since you are a DD, you might try http://db.debian.org/machines.cgi (which I'm pretty sure you know about)
[08:33] <mbiebl> iirc, you should now be able to install b-deps without having to contact DSA
[08:33] <pitti> mbiebl: yes, I do (eder seems appropriate, it's really slow)
[08:34] <mbiebl> even for a small lib like libsoup2.4, ouch
[08:35] <pitti> I tried on my nexus7 with letting a cat /dev/urandom > /dev/null and a tar cj /usr running in the background, doing "echo 3 > /proc/sys/vm/drop_caches" all the time, and running the test endlessly, and it survived > 250 iterations so far
[08:44] <ogra_> pitti, cant you do that easier via sysctl (cache_timeout or so) instead of always echoing into /proc ?
[08:44] <ev> Daviey: it's not. Could stick it in on Thursday if you think we couldn't settle that one with a phone call?
[08:45] <Daviey> ev: I don't think it needs a dedicated session or anything.  Just need to work out, *if* it is worth doing .. *how* to do it.. and *who* to do it :)
[08:46] <rbasak> I'd love to see it. I think it'd be useful. Right now the best information we get is from bug reports, and most of those are from people who have misconfigured things and then send us reports for maintainer script failures.
[08:46] <rbasak> No idea *how* though.
[08:47] <Daviey> rbasak: Right, last time i spoke to ev about this.. we were interested in running it during the dev cycle, but turning off by default on production
[08:47] <rbasak> And many server operators may prefer not to send us anything from production servers.
[08:47] <Daviey> rbasak: do you think people would be happy running this on production servers?
[08:47] <rbasak> Right - thanks makes sense, and would be a great start.
[08:47] <rbasak> I think most people running production servers would want to vet reports, but wouldn't object if they had the option of sending reports.
[08:47] <rbasak> Eg. how about a CLI with a prompt on motd if there's pending stuff in /var/crash?
[08:48] <Daviey> That actually seems reasonable middleground.. :)
[08:48] <rbasak> A "talk me through it CLI" like ubuntu-bug
[08:48] <Daviey> maybe a session is warranted.. but our schedule is already full. Ugh
[08:49]  * Daviey suspects we'll need a third track next time.
[08:49] <rbasak> I think this is the sort of case where we really want an ML discussion thread first.
[08:49] <rbasak> Not sure we'd gain much from a session as-is.
[08:49] <ev> Daviey: we could just schedule a google hangout out of band
[08:49] <Daviey> rbasak: Fancy kicking that off?
[08:50] <ev> or that :)
[08:50] <Daviey> ev: that sounds crazy enough that it might just work.
[08:50] <rbasak> Sure. Give me a day though - I've some errands to run before vUDS.
[08:50] <Daviey> rbasak: thanks :)
[08:51] <mlankhorst> could one of the sru admins accept all the xorg related packages in https://launchpad.net/ubuntu/precise/+queue?queue_state=0&queue_text= ?
[08:55] <siretart> tjaalton: no, please do. I just don't have the time and ressources to actually test them right now, but they should be good for saucy!
[08:55] <Daviey> mlankhorst: is this the tracking bug 1177679?
[08:56] <tjaalton> siretart: one glitch I found is that libva-dev probably needs to depend on libva-drm1 too, but we can fix that later
[08:56] <tjaalton> siretart: but yeah, I'll sync the current versions, thanks
[08:56] <siretart> tjaalton: well, patches, as always, are very welcome  :-)
[08:56] <tjaalton> :)
[08:57] <mlankhorst> Daviey: yeah
[09:00] <Daviey> mlankhorst: I think the bug report probably needs expansion TBH.  FOllowing the SRU template would be helpful, and linking to related discussion on the xserver ennoblement agreements made already?
[09:01] <mlankhorst> Daviey: lts-quantal didn't even have a tracking bug at all
[09:01] <mlankhorst> and it's pretty much s/quantal/raring s/ltsq/ltsr/
[09:02] <Daviey> mlankhorst: Okay, I wasn't involved in that.  Maybe ping the person that handled that?
[09:03] <mlankhorst> Daviey: code is at https://bazaar.launchpad.net/~xorg-edgers/xorg-server/xorg-pkg-tools/files running 'lts-stack raring' in an empty directory on raring grabs all the right versions. rerunning on precise in that directory with dev tools installed will make all the packages
[09:06] <ev> rsalveti, apw: mornin'! What's the latest on the grouper kernel? Are you still fighting gcc bugs, or was this an issue with the kernel config?
[09:06] <mlankhorst> but there is no way for this to break existing things anyway, they're all new packages
[09:13] <Laney> mardy: I hear you want to hear about bugs like bug #1180297 :-)
[09:14] <mardy> Laney: in a way, yes :-)
[09:17] <mardy> Laney: damn, Facebook is redirecting to plain http again :-(
[09:17] <apw> ev, it was an interaction between the kernel and compiler, who is to blame is unresolved, but the kernel in the archive is bootable
[09:20] <ev> apw: oh? I hadn't noticed a new upload in saucy-changes
[09:20] <ev> weird
[09:20] <ev> I'll give it a bash today
[09:20] <ev> thanks
[09:21] <apw> ev, hmmmm maybe i am getting them all the different versions mixed up
[09:22] <ev> nexus 7 :)
[09:22] <cjwatson> That'd be "grouper"
[09:23] <infinity> It was mako and/or manta that we were fiddling with gcc-4.8 issues on, wasn't it?
[09:23] <infinity> Or did grouper suffer the same issue and need a rebuild?
[09:38] <seb128> pitti, can you see https://code.launchpad.net/~nottheoilrig/ubuntu/quantal/python-gnutls/fix-for-1013798/+merge/154767 as merged? (went in quantal:  https://launchpad.net/ubuntu/+source/python-gnutls/1.2.4-1ubuntu0.1à
[09:38] <pitti> seb128: done
[09:39] <seb128> pitti, danke
[09:52] <pitti> infinity: sheesh -- now that eder finally built that thing, "cache-test: OK" *grumpf*; but i'll try some iterations
[09:59] <infinity> pitti: Hahaha.  D'oh.
[09:59] <seb128> pitti, can you reject https://code.launchpad.net/~vandersonmr/gnome-screenshot/bugfix1169904/+merge/161262 ?
[09:59] <pitti> done
[09:59] <seb128> thanks
[10:00] <pitti> ok, it does reproduce quite often on eder
[11:19] <tkamppeter> Any Upstart expert around? Can I start daemons on-demand with upstart, for example triggered by an access to a given port (like xinetd does) or to a given domain socket?
[11:19] <tkamppeter> systemd is capable of this.
[11:20] <doko> jodh, xnox: ^^^
[11:21] <jodh> tkamppeter: see socket-event(7)
[11:27] <tkamppeter> jodh, so if CUPS would have "start on socket PROTO=unix /var/run/cups/cups.sock, a client ("lpr" or anything else using libcups2) accessing /var/run/cups/cups.sock would trigger the start of cupsd and the access gets processed by cupsd?
[11:32] <jodh> tkamppeter: "yes", but cupsd would need to be modified such that it does not call socket() et al itself - it would simply need to call accept(2) on the socket fd passed to it via the UPSTART_FDS env var. I believe systemd requires something similar.
[11:33] <pitti> something like http://pkgs.fedoraproject.org/cgit/cups.git/tree/cups-systemd-socket.patch
[11:43] <tkamppeter> pitti, thanks.
[11:43] <tkamppeter> jodh, can you have a look into patch and see whether this can also be used with Upstart?
[11:45] <rbasak> Looks like the patch is very systemd specific, but the general mechanism is the same.
[11:48] <seb128> cjwatson, infinity: is https://launchpadlibrarian.net/138772411/saucy.debdiff fine to sponsor (just asking in case you have another upload planned for live-build)?
[11:49] <seb128> (to sru for raring as well)
[11:49] <cjwatson> seb128: sure
[11:49] <seb128> cjwatson, thanks
[11:56] <tkamppeter> rbasak, pitti, could someone of you help me to add upstart support to the patch?\
[11:56] <pitti> seb128: I sent some analysis to gnome bug 698305, but I stop at this now; at this point I really don't understand glib weak refs and threading well enough, and as we can just give back the package it's not immediately urgent
[11:56] <tkamppeter> pitti, is there also a patch for the cupsd to stop after a certain time being idle?
[11:56] <pitti> tkamppeter: you can check http://pkgs.fedoraproject.org/cgit/cups.git/tree/, but I don't think there is
[11:57] <pitti> you usually don't want cups to stop
[11:57] <seb128> pitti, ok, thanks ... did you manage to get it to build after retries? we had a few on the buildds and it never went through
[11:57] <pitti> and you usually don't want to start cups at the time when you need it first, but much earlier
[11:57] <pitti> as remote printer detection will just take a while (DNS-SD announcements are only sent every 30 seconds or so)
[11:57] <pitti> seb128: yes, infinity gave it back once, and it's built now
[11:57] <rbasak> It looks non-trivial to me :(
[11:58] <seb128> pitti, great, thanks again!
[11:59] <rbasak> Although from that patch it looks like systemd provides a library as a general mechanism. It might be worth considering if it's worth implementing an equivalent compatibility library that supports upstart's socket bridge that could be used in place of it and support the same API. I'm not sure how likely systemd upstream are to change the API though. But it would be nice to easily support anything that supports systemd socket activation in this way. Bu
[12:01] <tkamppeter> rbasak, pitti, we had discussion about starting cupsd and cups-browsed on-demand on mobile devices yesterday on the OpenPrinting Summit.
[12:02] <tkamppeter> rbasak, pitti, to save some memory, battery, resources.
[12:03] <rbasak> Is there a general Zeroconf story to fix the DNS-SD delay?
[12:09] <tkamppeter> rbasak, not AFAIK.
[12:47] <pitti> tkamppeter: yes, I think starting on demand on a mobile device is an acceptable compromise (the first time you want to print you just have to wait a bit)
[12:48] <pitti> tkamppeter: I just wouldn't do it on a desktop; I think "start cups after one minute or when requested" keeps it out of the boot path, and yet has it ready when you realistically need it
[12:49] <pitti> I guess on a mobile phone we actually do want to shut it down after some time, too
[12:49] <pitti> on a desktop one usually has swap, so if it's not being used, it just gets swapped out
[13:17] <GridCube> tedg, hello :) can you review https://wiki.ubuntu.com/GridCube/HUD_in_Xubuntu_Rationale please?
[13:19]  * tedg clicks
[13:20] <GridCube> :D thanks
[13:22] <tedg> GridCube, Looks good to me!
[13:24] <GridCube> :) excellent
[13:25] <GridCube> by the way, could you consider joining the vUDS tomorrow at 20hs UTC to follow https://blueprints.launchpad.net/xubuntu-desktop/+spec/client-xubuntu-1305-software
[13:26] <GridCube> if you cant there its no problem, but i do think you could bring some interesting help in the topic, sadly i wont be able to join :(
[13:28] <ogra_> infinity, do you think it would be possible to build udev against klibc ?
[13:37] <rsalveti> ev: for grouper it's probably a config issue still, didn't have time to investigate yet, was in vac last week
[13:41] <roadmr> Hey folks! question about SRU. I have prepared a SRU bug 1059544, added a task for the affected Ubuntu release, and uploaded a branch with a fix. I have upload rights for the package. Should I just merge and upload this to -proposed, or do I need approval from e.g. release team?
[13:52] <ev> rsalveti: *nods*
[13:55] <rbasak> roadmr: AIUI, you upload -proposed, and then it sits in Unapproved until the SRU team review the upload. But IANAUbuntuDeveloper.
[13:55] <roadmr> rbasak: thanks! well that makes sense. I'll probably do just that
[14:31] <stokachu> stgraber: did you get my ping last night?
[14:33] <stgraber> stokachu: I saw it but I'm rather busy at the moment between UDS and other tasks, will try to take a look later this week.
[14:34] <stokachu> stgraber: ok thanks
[15:36] <mpt> ev, how's the error rate recalculation going?
[16:49] <cjwatson> mlankhorst: https://launchpadlibrarian.net/139941740/buildlog_ubuntu-saucy-amd64.ubiquity_2.15.2_FAILEDTOBUILD.txt.gz - hmm, is this X's fault?
[16:57] <mlankhorst> cjwatson: seems more like a lack of root on xserver
[16:58] <cjwatson> Nothing should have changed there ... trying a local build
[17:02] <mlankhorst> but honestly I have no idea what's going on there :)
[17:03] <cjwatson> Looks like I can't check properly until the 3FP outage is sorted out
[17:12] <JordiGH> Is there a clean way to get an upstream Debian git-buildpackage archive and use it to maintain several different releases (the P, Q, and R releases) in a PPA for Ubuntu?
[17:12] <JordiGH> Something hopefully cleaner than this: https://github.com/dac922/octave-pkg-octave/network
[17:29] <rbasak> I've decided that gnome-terminal should have messaging indicator support for terminal beeps. Just putting it out there, in case someone wants to implement it :-/
[17:29] <sarnold> I'd be happy if unity would do something with the URGENT flag..
[17:31] <dobey> anyone know what the maximum value a digit in the version string of a package can have, with dpkg?
[17:31] <dobey> rbasak: i don't see how that would belong in the messaging indicator
[17:32] <rbasak> dobey: for when the thing inside the terminal signals a message with a beep.
[17:32] <dobey> rbasak: a beep is not a message. a message is a commincation from another person, to the user, in terms of the messaging indicator.
[17:32] <rbasak> But yeah, it isn't a good fit. Just solves my particular issue with missing irssi notifications.
[17:33] <dobey> write an irrssi plug-in that puts irssi in the messaging indicator?
[17:33] <rbasak> I would like to do that, yes.
[17:33] <rbasak> I'd also like one for mutt.
[17:33] <rbasak> And the terminal beep covers both cases.
[17:34] <rbasak> (and it also covers the case when I'm attached to remote screen that's running irssi without having to forward the indicator plugin somehow)
[17:37] <sarnold> rbasak: you can "this bug affects me" on https://bugs.launchpad.net/ubuntu/+source/unity/+bug/1108348 ... :D
[17:38] <rbasak> sarnold: I'm pretty sure I've seen Unity wiggle the icon on the left. But I only occasionally see it continously wiggle until cleared. I never figured out what it was supposed to do.
[17:40] <sarnold> rbasak: hrm. I've seen something vaguely similar with an update widget thingy, but it surely isn't the URGENT flag that does that, or I'd have seen it thousands of times by now...
[17:40] <rbasak> I'm not familiar enough with X and window managers to understand this stuff in detail.
[17:41] <rbasak> My gnome-terminal doesn't even beep audibly. No idea why. Probably some setting somewhere I've inherited from a dozen releases ago.
[17:41] <sarnold> hehe
[17:50] <cjwatson> dobey: Er.  9?
[17:50] <pitti> rbasak: beep?
[17:50] <cjwatson> dobey: (You may mean something else by "digit" ...)
[17:50] <pitti> rbasak: it's not supposed to beep around
[17:51] <cjwatson> dobey: If you mean a numeric part of a version, there's no upper limit
[17:52] <dobey> cjwatson: i mean i can't use the infinity symbol, and dpkg complains that it's not a "digit" if i use it for the version number
[17:52] <cjwatson> If you're trying to find a version greater than all other versions, there isn't one
[17:53] <dobey> cjwatson: so just looking for the next best thing. wasn't sure if it converted it to an int, or kept it as a string, and just complained if it wasn't between 0-9
[17:53] <cjwatson> dpkg's version comparison algorithm works on strings
[17:53] <dobey> right. would be great if it treated the infinity character correctly, though
[17:53] <cjwatson> And digits are only 0-9
[17:59] <achiang> would a patch to unity-2d that a) adds a performance optimization but b) hides it behind a gconf setting to preserve existing behavior be acceptable for a 12.04 SRU?
[18:00] <stgraber> achiang: provided very good justification for the added "feature", yes, it's something we may allow
[18:01] <achiang> stgraber: see r1157 here - https://code.launchpad.net/~unity-2d-team/unity-2d/trunk
[18:01] <achiang> stgraber: considering unity-2d is meant for low-end devices *and* this feature saves memory... it's very appropriate from my pov
[18:03]  * sarnold idly notes that Unicode Character 'RIGHT ANGLE' (221F) is greater than 'INFINITY' (221E) ...
[18:07] <stgraber> achiang: I think that's reasonable assuming you have a reasonably large pool of users who want that feature. Technically this doesn't fit in the standard SRU process but the TB can grant an exception for those.
[18:08] <achiang> stgraber: i think potential ubuntu for android customers would count as a large pool of users? :)
[18:08] <stgraber> achiang: agreed
[18:09] <xnox> achiang: a few performance related only SRU have been pushed into precise, kind of hand-in-hand with hardware enablement story of low-end devices =)
[18:09] <xnox> and scale-out workloads (well, maybe not for unity ;-) )
[18:10] <stgraber> achiang: can you send an e-mail to the TB mailing-list about this? kind of in the middle of a meeting now so it'll be the best way to remind me to do a proper review and grant an exception
[18:10] <doko> slangasek, mailx doesn't support maildir folders
[18:10] <achiang> stgraber: yes, i can send an email. is there anything else i should do, considering the code is already in unity-2d trunk?
[18:10] <slangasek> doko: is this in the context of my c-m fixing upload of lsb?
[18:11] <doko> slangasek, yes
[18:11] <stgraber> achiang: ideally a bug with a debdiff ready for upload attached to it would help
[18:11] <achiang> stgraber: ah, ok. sounds good
[18:11] <slangasek> doko: I was only restoring the previous state of affairs; if you think we should be kicking bsd-mailx out of main and replacing it with mailutils, that's fine with me, but I don't care about it and didn't want to be on the hook for an MIR
[18:12] <doko> ok
[18:12] <slangasek> doko: I would rather kick the lsb binary packages out of main than do an MIR for any of this stuff :)
[18:32] <hallyn> ubuntu@server-f94526fe-8f7f-44df-93d7-710c86eb8927:~$ pull-lp-source lxc raring-updates
[18:32] <hallyn> pull-lp-source: Error: The source package 'lxc' does not exist in the Ubuntu primary archive in raring-updates
[18:33] <hallyn> this happens to me both in canonistack instances and my home laptop...  not sure why
[18:34] <hallyn> oh i see - it shouldn't be there.  but also pull-lp-source lxc raring gives me 0.9.0-0ubuntu3.1
[18:46] <barry> bdmurray: two questions re: the eof/pyc problem.  could this be related to a missing fsync at some place?  is there any way to identify whether this is happening primarily on laptops/mobiles or always-on desktops/servers?
[18:49] <bdmurray> barry: I think we'd could only guess if it is a server based off InstallationMedia in the bug reports
[18:50] <barry> bdmurray: i just wish we had a way to reproduce it ;/
[18:53] <bdmurray> barry: maybe look for these types of bugs from ubuntu developers to see if they know more about the system that experienced it?
[18:54] <bdmurray> or active community members
[18:55] <barry> bdmurray: it's probably worth a message to ubuntu-devel anyway.  i'll write one to u-d and one to python-dev
[20:21] <bkerensa> <jono> beer hangout: everyone welcome - https://plus.google.com/hangouts/_/2e35c93b7aca2d5bc4ce8eeaae65aba61ae84205?authuser=0&hl=en
[21:42] <bdmurray> barry: maybe I should be telling people how to workaround this error since I am looking at all these bugs.  Any tips on what to say?
[21:56] <mwhudson> eh?
[21:57] <mwhudson> why is there no linux-tools-$VERSION for armhf in raring?
[21:57] <mwhudson> https://launchpad.net/ubuntu/+source/linux/3.8.0-19.30/+build/4538742
[21:59] <mwhudson> ah https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1171580
[22:00] <mwhudson> ah proposed
[22:26] <sarnold> barry: re: busted .pyc files, what feels to me more likely than a race condition is an abrupt marshal process death, before it has had an opportunity to flush stdio buffers -- or, not checking an fclose() error return value that might indicate a write error for some edge case internal to the marshaling code..
[23:37] <mwhudson> how many times does building the python2.7 debian package run test suite??
[23:42] <doko> one for the static build, one for the shared build, and one for the debug build
[23:42] <mwhudson> oh ok
[23:43] <mwhudson> i think i'm on the last one then...
[23:43] <doko> but you can disable it using DEB_BUILD_OPTIONS=nocheck