[00:42] <TheMuso`> 6/c -all
[01:23] <ScottK> Just like the good old days.
[01:24] <jpds> Luxury.
[02:30] <happyaro1> cjwatson: http://packages.ubuntu.com/source/trusty/ibus-pinyin
[02:30] <happyaro1> cjwatson: the removed one isn't the android one, but open-phrase.
[02:31] <ScottK> happyaro1: You'll probably have more luck filing a bug since it's the middle of the night for him (assuming he's not travelling)
[02:32] <happyaron> ScottK: that's not a bug, cjwatson asked me about it
[02:45] <ScottK> Oh.  OK.
[04:20] <lamont> tab completion seems to have gone away in trusty  - or is it just me?
[04:21] <lamont> ah, it just seems to have gotten smarter in stupid ways
[06:25] <cjwatson> slangasek: hw-detect still uses it to try to figure out whether it needs to install mouseemu to support single-button mice on Mac laptops ... dunno if there are any other reasons
[06:26] <cjwatson> happyaron: I don't much care what packages.ubuntu.com thinks is built, it's wrong.  Check Launchpad - if you look at https://launchpad.net/ubuntu/+source/ibus-pinyin/1.5.0-1ubuntu1/+build/5641888 you can see it isn't building the android package
[06:26] <sarnold> heh, love the description of mouseemu that mentions "only works on 2.6", where "2.6" is The New Kernel :)
[06:28] <cjwatson> happyaron: Or, you know, you could just look at the source package you uploaded and see that it doesn't have an ibus-pinyin-db-android in debian/control?
[06:36] <pitti> Good morning
[06:37] <cjwatson> slangasek: ubiquity also uses laptop-detect as part of its default hostname generation
[06:37] <cjwatson> slangasek: there may be a few other embedded uses here and there
[06:37] <pitti> slangasek: -schroot patch> Debian bug or ubuntu bug preferred, but pretty much anything else (mail/pastebin/etc.) WFM :)
[07:04] <pitti> slangasek: ah, saw your bug, thanks
[07:19] <slangasek> cjwatson: ah; so a lot of undeclared dependencies?
[07:20] <cjwatson> slangasek: I think so
[07:20] <slangasek> bother
[07:20] <slangasek> ok :)
[07:20] <cjwatson> Or optional use-if-present but we kind of want it, I guess
[07:20] <pitti> http://ubuntu-codesearch.surgut.co.uk/search?weighted=1&q=laptop-detect
[07:20] <pitti> hm, error
[07:21] <pitti> Laney, xnox: ^ it seems your codesearch instance is broken ATM? it doesn't seem to find anything
[07:22] <Logan_> ooh, I didn't know that existed
[07:22] <Logan_> I was actually looking for something like that last week
[07:22] <pitti> it's an instance of http://codesearch.debian.net/ for Ubuntu
[07:22] <pitti> or, rather, was
[07:22] <Logan_> heh
[07:23] <pitti> but yes, codesearch.d.n is incredibly useful for questions like that (undeclared dependencies, finding users of deprecated API, etc.)
[07:23] <sarnold> woot, I thought it was dead entirely after the grand canonistack purge
[07:23] <pitti> sarnold: ah, so that's probably the cause
[07:23] <chiluk> cjwatson, bdmurray, apparently my changes to try to fix memtest86+ for bug 560839 caused a regression.  I've uploaded a debdiff that reverts the changes for the serial console, but keeps them for regular terminal.  It wasn't till now that I had a machine up to test serial console on.  off to sleep see you guys in the morning.
[07:23] <pitti> sarnold: AFAIR Laney set it up, and xnox set up DNS for it for convenience
[07:24] <sarnold> pitti: the dns is news to me tonight :) it -is- convenient, hehe
[07:24] <pitti> slangasek: anyway, http://codesearch.debian.net/search?q=laptop-detect might be a bit helpful, but I'm fairly sure that we have some more usages in Ubuntu
[07:30] <dholbach> good morning
[07:31] <Logan_> hey Daniel :)
[07:32] <Noskcaj> evening Logan_, dholbach
[07:32] <Logan_> hi Jackson
[07:32] <Logan_> it's actually 2:30 AM where I am, and I should be off to sleep
[07:32] <Logan_> except for the fact that I'm definitely going to do awful on my exam :(
[07:33] <dholbach> hi Noskcaj
[07:33] <dholbach> hi Logan_
[07:33] <sarnold> Logan_ :/ -- more sleep almost always trumps more study in my experience..
[07:34] <Noskcaj> Logan_, If you're going to be awake anyway, could you add a testimony to https://wiki.ubuntu.com/Noskcaj#MOTU ?
[07:34] <Logan_> sarnold: even if you don't have a basic solid understanding of the material? ;P
[07:34] <Logan_> Noskcaj: ha
[07:34] <sarnold> Logan_: definitely, it's easier to reason about completely novel things on a fresh brain
[07:34] <Noskcaj> This month is probably the last one i can apply for MOTU in
[07:35] <Logan_> sarnold: hmm, that seems valid
[07:35] <Logan_> ironically, I should know this because my test is on cognitive science :/
[07:35] <Noskcaj> yep, on april 6th 19UTC becomes 5am
[07:35] <Logan_> Noskcaj: it seems awfully soon to do that again, no?
[07:35] <Logan_> don't tell me it's just because of making meetings
[07:36] <sarnold> Logan_: hehe :) good luck and stay calm, that also helps :)
[07:36] <Logan_> thanks man :)
[07:36] <Noskcaj> Logan_, daylight savings ending + i'll never apply by email again + i think my only failure was not getting better testimonials in my 2 month wait
[07:36] <Noskcaj> and the gnome-xchat screwup
[07:37] <Logan_> personally, I'd give it more time
[07:37] <tvoss> doko, around?
[07:37] <Logan_> Noskcaj: whether or not you might think you're a better candidate a month later, it's not enough time for people to get a new impression of you
[07:37] <Logan_> and they may think you're being overeager by applying again so quickly
[07:38] <Noskcaj> I'd would wait, but ~8 months is too much time
[07:38] <sarnold> Noskcaj: why the pressure? ubuntu will probably still be here two, three, four months away..
[07:38] <happyaron> cjwatson: I see, will deal with it today.
[07:38] <happyaron> cjwatson: should be generated from src:libpyzy now.
[07:39] <Logan_> sarnold: Noskcaj has been experiencing firsthand how broken applying by email is right now
[07:39] <Logan_> since he's in the land down under, it's hard for him to make DMB meetings
[07:40] <Noskcaj> sarnold, it's very frustrating waiting for sponsorship
[07:40] <Noskcaj> especially with xubuntu having no one who has time to sponsor stuff ATM (dev lead gone + micah always busy)
[07:40] <sarnold> Noskcaj: ohhh, how long does it take for the queue to be handled, typically?
[07:41] <sarnold> Logan_: meetings during sleep time are -also- unfun. hehe.
[07:41] <doko> tvoss, yes, but in sessions
[07:41] <Noskcaj> sarnold, I've got stuff that's been in 2+ weeks currently
[07:42] <Logan_> oh dear
[07:42] <Noskcaj> and a few things that are fairly release critical to xubuntu
[07:42] <sarnold> Noskcaj: ahhhhh. by the time you get feedback on things your brain has long since moved on. makes sense. thanks :)
[07:42] <Noskcaj> yep
[07:42] <tvoss> doko, ack. Wanted to ask if you have had a chance to look into the thread sanitizer example I sent you by mail?
[07:43] <Logan_> okay, imma sleep now
[07:43] <sarnold> nn Logan_,
[07:43] <doko> tvoss, sorry, no
[07:43] <sarnold> good luck
[07:43] <Logan_> everyone cross his or her fingers that I don't fail cogsci, lol
[07:43] <Logan_> thanks :)
[07:43] <tvoss> doko, ack
[07:43] <doko> tvoss, did you check this with 4.9 too?
[07:43] <Unit193> Logan_: Awwwh, darn.  Right when I wanted to tell you about a cryptsetup upload you can't do. :P
[07:43] <tvoss> doko, I haven't, yet
[07:44] <Logan_> Unit193: wat
[07:44] <Unit193> Good luck on cogsci.
[07:44] <Logan_> thanks Unit :P
[07:44] <Unit193> -_-
[07:45] <Logan_> lol, I'll try to be a core dev eventually
[07:46] <Logan_> a lot of people assume I am for some odd reason
[07:46] <Logan_> but anyway, sleep
[09:04] <Laney> hey pitti, it regularly breaks
[09:04] <Laney> let me give it a kick
[09:05] <pitti> Laney: FYI, I just added the xauth test dep to glib-networking's debian svn (I think that was discussed between you and seb128 yesterday)
[09:05] <Laney> pitti: no, not discussed but I did add it to some other ones
[09:05] <Laney> not that one though
[09:06] <pitti> no 2.39.91 to package, though; I won't upload it just for that
[09:06] <seb128> yeah, that can wait the next update
[09:06] <Laney> those failures I only saw in Debian anyways
[09:06] <pitti> Laney: ah, which ones were you looking at?
[09:07] <Laney> glib and pango
[09:07] <pitti> glib for sure
[09:07] <pitti> ah, good
[09:07] <Laney> I just forgot about -networking otherwise I would have added it there too
[09:07]  * Laney goes to kick codesearch now
[09:07] <pitti> Laney: can we sync pango1.0 from Debian, btw?
[09:08] <Laney> there's a s/Breaks/Conflicts/ that I didn't do in Debian
[09:08] <pitti> sid now has 1.36.2, we have 1.36.1-0ubuntnu1
[09:08] <Laney> but I have an FFe in for that version
[09:08] <Laney> (as it adds the new tests package)
[09:08] <pitti> an FFE for a new test? ugh :)
[09:08] <Laney> should be easy, maybe somebody looked at it already
[09:12] <Laney> pitti: hm, what search didn't give you results? http://162.213.35.4/search?weighted=1&q=org.gnome.Shell works here, for example
[09:12] <Laney> also, whoops
[09:12] <Laney> @pilot in
[09:13] <pitti> Laney: I tried on http://ubuntu-codesearch.surgut.co.uk/
[09:13] <Laney> should be the same
[09:13] <pitti> Laney: but indeed it seems to work again; this morning it immediately returned with "no search results" for anything I threw at it
[09:13] <Laney> ah
[09:13] <pitti> slangasek, cjwatson: so http://ubuntu-codesearch.surgut.co.uk/search?weighted=1&q=laptop-detect is indeed working again, that should answer the "undeclared reverse depends"?
[09:43] <darkxst> hey Laney, pitti
[09:43] <pitti> hey darkxst
[09:46] <darkxst> Laney, can you look at https://code.launchpad.net/~darkxst/gnome-themes-standard/3.12-backgrounds
[09:47] <Laney> darkxst: hey, sure
[09:47] <jodh> pitti: re sbuild dep8 on ppc64el - looks like the lxc config is still missing the required 'lxc.aa_profile = ...' for mounting /proc.
[09:52] <pitti> jodh: yes, I was just about to look at that
[09:52] <pitti> jodh: I'm using stgraber's adt profile, but this needs some modifications
[09:52] <pitti> jodh: I'll test it on one machine, and if it works, roll it out to all ~ 10
[09:52] <jodh> pitti: thanks!
[10:01] <pitti> jtaylor: FYI, the recent ipython failure seems to be an autopkgtest bug, with having multiple tests create artifacts; I'll look into that
[10:04] <seb128> doko, hey, did you see https://bugs.launchpad.net/ubuntu/+source/bash-completion/+bug/1288031 ?
[10:08] <pitti> jodh: yay, works locally
[10:08] <pitti> jibel: ^ see above bug, that's the one you mentioned an hour ago
[10:09] <pitti> really unnerving bug
[10:15] <Laney> yeah, not sure why we took the new bash... I didn't see an FFe for it.
[10:21] <xnox> happyaron: cjwatson: ibus-pinyin android-db is removed and replaced by a dependency on libpyzy (commit by chromium.org person upstream). adjusted the seeds appropriately for the three seeds that seeded -db-android, it's not needed anymore as far as i can tell.
[10:22] <seb128> Laney, yeah, that update looks not trivial and should have got a ffe imho
[10:23] <xnox> happyaron: src:libpyzy should generate it? hm. ok.
[10:26] <jodh> pitti: sbuild => yay! :)
[10:26] <pitti> jodh: c'est vert! https://jenkins.qa.ubuntu.com/job/trusty-adt-sbuild-ppc64el/9/
[10:26] <pitti> jodh: hah,  snap
[10:26] <jodh> pitti: :)
[10:26] <pitti> jodh: armhf still running
[10:27] <xnox> happyaron: yeah, you are right, i should revert my seed changes.
[10:27]  * jodh crosses ahem, arms...
[10:27] <seb128> xnox, are you doing the 2 sides of the conversations yourself? ;-)
[10:27] <seb128> xnox, or just going through night backlog and commenting as you go?
[10:28] <xnox> seb128: yes, yes indeed the latter one. former one sounds bipolar.
[10:28] <xnox> seb128: i don't think i'm bipolar.
[10:28] <seb128> ;-)
[10:34] <darkxst> Laney, thanks
[10:35] <Laney> no problemo
[10:35] <pitti> jodh: aaand success! https://jenkins.qa.ubuntu.com/job/trusty-adt-sbuild-armhf/9/
[10:35] <pitti> jodh: thanks again
[10:35] <jodh> pitti: phew. np :)
[13:05] <Laney> @pilot out
[13:06] <seb128> Laney, going close from 40, good job!
[13:29] <cjwatson> seb128: IIRC I added _removable to "click list --manifest" for something you were doing (system settings?).  Do you remember where the code that uses that is?
[13:30] <cjwatson> seb128: I'm wondering whether existing users would tolerate it being a JSON boolean instead, or if I need to keep it as an int for compatibility
[13:30] <cjwatson> (I must have been drunk the day I made that be 0/1, or something)
[13:30] <seb128> cjwatson, hum, that doesn't ring a bell, what is _removable doing?
[13:31] <cjwatson> It indicates whether this particular version of the package can be removed, as opposed to a preinstalled version
[13:31] <cjwatson> Maybe it wasn't you then, I'll look elsewhere.  Could've been the scope ...
[13:31] <cjwatson> ./src/click-interface.vala:130:        const string REMOVABLE_FIELD = "_removable";
[13:31] <seb128> yeah, shouldn't be us
[13:31] <cjwatson> ah, there we go
[13:31] <cjwatson> get_int_member.  I guess I'll leave it alone
[13:33] <seb128> cjwatson, https://code.launchpad.net/~alecu/unity-scope-click/prevent-non-removable/+merge/188616
[13:34] <cjwatson> Yeah, I dug it up eventually
[13:34] <cjwatson> Thanks
[13:34] <seb128> (click is not an easy name to google for :p)
[13:34] <seb128> yw ;-)
[13:34] <cjwatson> The name wasn't my idea ...
[13:40] <davmor2> seb128, cjwatson: it gets worse when you type installing a click package, You get the first couple of pages of google play, amazon store and ios eventually
[13:40] <cjwatson> Oh, mind you, get_boolean_member would map back and forth implicitly anyway
[13:42] <davmor2> cjwatson: the most confusing thing seems to be that click has an install option but that's not how you install an app on touch grrrrrr :)
[13:43] <sergiusens> cjwatson, are you planning on changing that?
[13:44] <cjwatson> sergiusens: I was thinking of it just because it's ugly and I was rewriting that code anyway, but I won't do it if it actually breaks anything
[13:44] <cjwatson> As it happens I'm pretty sure it wouldn't break the scope.  Do you know of other users?
[13:46] <sergiusens> cjwatson, fwiw I'm not using it yet, but was planning to add it to a couple of packages
[13:46] <sergiusens> so I can hold off until the change is made
[13:52] <cjwatson> sergiusens: I would say, if you're writing anything new please be prepared for that field either being int or boolean
[13:52] <cjwatson> sergiusens: if you're using json-glib, then get_boolean_member is AFAICS fine for this, it'll cope with the value being an int
[13:52] <cjwatson> sergiusens: I probably won't change it for the moment just to minimise risk
[13:53] <sergiusens> I'm only adding it to the manifest; not using them directly; and the click scope is where I believe the magic happens
[13:54] <sergiusens> the merge request linked to seems from last year though
[13:54] <sergiusens> I thought the scope was under a rewrite
[13:54] <cjwatson> wait, you're not allowed to add that key to the manifest
[13:54] <cjwatson> it's dynamically-generated
[13:55] <cjwatson> and it has to be, because the same .click package might wind up being removable or not depending on the way it's installed
[13:56] <cjwatson> click build will warn you and ignore the key if you try to add any manifest key starting with an underscore
[13:58] <sergiusens> great; I was going to look at the docs again wrt this
[13:59] <sergiusens> so this is a garbage collection thing or an uninstallable flag?
[13:59] <sergiusens> seems only applied to garbage collection
[14:00] <sergiusens> do we have anything for making it uninstallable?
[14:00] <cjwatson> _removable basically means that the package is in a writeable location
[14:00] <cjwatson> if it's preinstalled on a read-only fs, it's not removable
[14:01] <cjwatson> the only real point in having a removable flag otherwise is to prevent people accidentally screwing themselves by say hiding the dialer app (because you can "remove" a preinstalled package by slapping a whiteout-style hidden flag on top of it)
[14:02] <cjwatson> we don't have a flag for that right now, but it's possible.  I'm not sure that the manifest is the right place for that though; I think again it ought to be a property of how the package is installed rather than embedded in the package
[14:02] <cjwatson> maybe
[14:04] <sergiusens> a property on how it's installed is fine; and yes; use cases are dialer and friends as well as gallery and camera as they are default 'providers'
[14:05] <cjwatson> making sure that people can always make emergency calls was the case I'd heard
[14:05] <xnox> and i like that on android, i can revert to the stock version of the app.
[14:05] <cjwatson> right, that's true on Ubuntu too
[14:06] <xnox> so e.g. to unbreak my music app, i've cleared the data and "uninstalled" updates.
[14:06] <cjwatson> I patterned that very loosely after experience on Android
[14:06] <cjwatson> (I don't know if the scope exposes it, but it's definitely in place in click)
[14:06] <xnox> i guess we just don't have ui to unhide pre-installed clicks yet, then.
[14:07] <xnox> i guess "register that version for a user again"
[14:07] <cjwatson> that would work though it's simpler to unregister the updated version
[14:08] <cjwatson> remove => unregister pretty much
[14:08] <xnox> right, i see.
[14:10] <cjwatson> stgraber: https://code.launchpad.net/~click-hackers/click/trunk/+merge/209698 - please could you silo me up?  I'd like to try to squeeze this in before Qt 5.2 if possible
[14:10] <cjwatson> stgraber: (and I have Ubuntu dual-booting on my phone now so testing should be less painful than my last attempt on a Nexus 7)
[14:17] <cjwatson> stgraber: (never mind, getting Seb to do it)
[14:48] <hallyn> smoser: hey look!  infinity mentioned my transmeta laptop.  "not widely deployed", he says.  pshaw!
[14:49] <hallyn> d'oh
[14:49] <hallyn> i misread email headers.  wasn't him.
[15:23] <tkamppeter> xnox, hi
[15:24] <xnox> tkamppeter: hey.
[15:26] <tkamppeter> xnox, you tell in the Blueprint about printing that you have soved the Upstart/CUPS socket trigger problem, but I do not see any comment in the bug and nowhere a patch or fix.
[15:27] <xnox> tkamppeter: https://launchpad.net/ubuntu/+source/cups/1.7.1-5ubuntu6 ?
[15:27] <xnox> tkamppeter: http://launchpadlibrarian.net/168508764/cups_1.7.1-5ubuntu5_1.7.1-5ubuntu6.diff.gz
[15:30] <tkamppeter> xnox, thank you very much. Can you comment on the bug report and, if appropriate, close the Upstart task?
[15:31] <xnox> tkamppeter: i didn't remember there was a bug =) which one is that?
[15:33] <tkamppeter> xnox, it is bug 1276713, also linked in the Blueprint.
[15:37] <cjwatson> doko: do you desperately need https://launchpad.net/~ubuntu-toolchain-r/+archive/aarch64/+build/5665607 (on powerpc)?  I could use a powerpc builder ...
[15:39] <doko> cjwatson, cancelled. please give it back when resources are available
[15:40] <cjwatson> doko: thanks
[15:41] <Laney> xnox: rsalveti: can we upload ubuntu-touch-meta for the gst split?
[15:41] <Laney> I see it's committed but not uploaded
[15:43] <Laney> wait one second, meta is attached to a landing
[15:45] <rsalveti> Laney: yeah, probably mir
[15:45] <Laney> https://launchpad.net/~ci-train-ppa-service/+archive/landing-007/+packages
[15:45] <rsalveti> Laney: but sure
[15:45] <Laney> whyever are we adding gst-0.10?
[15:45] <rsalveti> that's weird
[15:45] <rsalveti> ogra: ^^
[15:45] <Laney> is that because it's used by camera or something
[15:46] <Laney> and those are going to click packages
[15:46] <rsalveti> I believe it's used by gallery-app
[15:46] <ogra> Laney, ask sergiusens, i only merged it
[15:46] <rsalveti> yeah
[15:46] <rsalveti> Depends: libc6 (>= 2.14), libcontent-hub0, libexiv2-12, libgcc1 (>= 1:4.1.1), libgl1-mesa-glx | libgl1, libglib2.0-0 (>= 2.12.0), libgstreamer0.10-0 (>= 0.10.0), libmediainfo0 (>= 0.7.52), libqt5core5 (>= 5.0.2), libqt5gui5 (>= 5.0.2), libqt5qml5, libqt5quick5, libqt5sql5 (>= 5.0.2), libqt5widgets5 (>= 5.0.2), libstdc++6 (>= 4.1.1), gstreamer0.10-plugins-base, gstreamer0.10-plugins-good, qtdeclarative5-accounts-plugin, libqt5sql5-sqlite, qtdecla
[15:46] <rsalveti> rative5-qtquick2-plugin, qtdeclarative5-qtmultimedia-plugin, qtdeclarative5-ubuntu-ui-toolkit-plugin, qtdeclarative5-ubuntu-ui-extras0.1 (>= 0.1+13.10.20130829-0ubuntu1), qtdeclarative5-window-plugin
[15:47] <Laney> man oh man
[15:47] <rsalveti> wonder if we can get that ported soon
[15:47] <sergiusens> Laney, rsalveti correct, gallery requires it
[15:47] <rsalveti> bfiller_afk: can we get someone to drop support for gst0.10 in gallery-app?
[15:48] <rsalveti> better, just port to gst1.0
[15:48] <tkamppeter> xnox, I have downloaded the fixed CUPS now, thank you very much.
[15:48] <rsalveti> it uses gst0.10 and qtmultimedia
[15:49] <rsalveti> which creates an issue for us
[15:49] <rsalveti> because qtmultimedia still uses gst0.10
[15:49] <rsalveti> but wonder if that is still really needed
[15:50] <rsalveti> or if we could just use the mediaplayer-app to play videos or such
[15:51] <xnox> tkamppeter: no problem, i was a pain to figure out. I've ended up writing a pure service in python3 and then in C and both worked, and then when i copied all of my stuff from C into early main() was when i realised that -F/-f both set "fg" variable with very diff semantics.
[15:53] <xnox> s/diff/different/
[16:15] <stgraber> @pilot in
[16:17] <OdyX> xnox: it'd be nice to report the non-upstart specific cups bugfixes to cups.org
[16:18] <OdyX> (as well as merging the upstart support code in Debian properly (on a branch that others can review before including) )
[16:18] <xnox> OdyX: yes, after we shake it out. It only took 3 people and multiple attempts to get it at all do something useful.
[16:18] <xnox> OdyX: plus it's still buggy in a few ways.
[16:19] <xnox> OdyX: i'm planning to submit it, but at the moment, it's split across 3-4 messy patches.
[16:19] <xnox> OdyX: my last one is on top of the stack of the others...
[16:20] <OdyX> xnox: it won't be made easier as I did the same work for systemd in parallel
[16:31] <xnox> OdyX: and the two are incompatible. since in upstart you get only one socket, and cups by default uses many sockets. thus while it is started up, it's only partially managed by upstart =(
[16:38] <OdyX> xnox: with my latest patch iteration, cups manages it's socket configuration for systemd and then systemd wakes up cups on incoming connections on any of the sockets.
[16:41] <pitti> bdmurray: hm, seems your gpg fix to software-properties wasn't sufficient?
[16:43] <xnox> OdyX: that's the proper approach to do it. Where can I see those patches?
[16:43] <bfiller> rsalveti: I think we've dropped it already when the MR to use libthumbnailer
[16:43] <bfiller> rsalveti: let me check the MR
[16:43] <xnox> OdyX: it wouldn't be quite easy to do with upstart as is, without me re-engineering the socket-bridge (essentially embedding one into cups =/)
[16:44] <bdmurray> pitti: right, I've just uploaded a new version of gnupg and will sort out software-properties shortly
[16:44] <pitti> bdmurray: splendid, thanks
[16:44] <pitti> bdmurray: oh, something in gnupg itself regressed? interesting
[16:44] <bdmurray> https://bugs.g10code.com/gnupg/issue1622
[16:44] <Logan_> pitti: looks like it works now: http://ubuntu-codesearch.surgut.co.uk/search?weighted=1&q=laptop-detect
[16:45] <pitti> bdmurray: right, just read the diff; it's an unexpected place to find a gnupg regression, but *shrug* nice :)
[16:46] <pitti> Logan_: yep, seems Laney prodded it hard enough
[16:46] <Logan_> :)
[16:46] <tkamppeter> xnox, socket-activated CUPS works now. Thank you very much.
[16:47] <xnox> OdyX: where is your systemd work / patches for cups?
[16:47] <tkamppeter> OdyX, starting CUPS socket-activated works now via Upstart, too.
[16:47] <tkamppeter> xnox, OdyX
[16:48] <tkamppeter> xnox, OdyX' work is all on the Debian repo of CUPS, master branch.
[16:49] <tkamppeter> xnox, not (yet) in Ubuntu CUPS, due to FF (or do we need an FFE here?).
[16:49] <smagoun> seb128: Hey, I think you were working on the LIM changes for Nautilus? There is a regression in nautilus (and probably other apps). Each new window is smaller than the previous one, it looks like we're subtracting the height of a menu bar when we shouldn't be. I filed bug 1288855.
[16:51] <seb128> smagoun, hey, that's a compiz bug, Trevinho is working on it
[16:51] <smagoun> seb128: oh, cool. Good to know
[16:51] <seb128> Trevinho, if it's an easy fix you might want to just roll that one out and then get back to lockscreen and other things
[16:51] <Laney> mardy: syncevolution is going up now
[16:51] <xnox> tkamppeter: well. yes and no, only one of the three default sockets is upstart socket activated, and the other two are self-allocated by cups. And that's upstart socket activation limitation - it only triggers upon one socket, and only passes one socket to the daemon.
[16:52] <seb128> smagoun, https://bugs.launchpad.net/ubuntu/+source/compiz/+bug/1287472
[16:53] <smagoun> i'll mark 1288855 as a dupe of 1287472
[16:53] <seb128> smagoun, feel free, I marked it invalid on nautilus with a comment saying it's a compiz issue
[16:54] <infinity> smagoun: Have you upgraded and logged out recently?  A bug not unlike that one was just fixed.
[16:54] <seb128> infinity, it's a non fixed issue
[16:54] <infinity> Okay, so it's not https://bugs.launchpad.net/ubuntu/+source/compiz/+bug/1282305 ?
[16:54] <infinity> Just vaguely related, I guess.
[16:54] <seb128> infinity, the previous one (which got fixed) was that windows were shifted by the decoration height
[16:55] <infinity> seb128: The one you're referring to is 1282304 (I filed both), but smagoun's sounded more related to 1282305
[16:55] <seb128> infinity, no, the new one is happening without hidding the decorations
[16:55] <infinity> Ahh, fun.
[16:55] <infinity> Kay.
[16:55] <seb128> infinity, click on nautilus in the launcher, ctrl-W it, cycle
[16:55] <seb128> and notice how nautilus shrinks
[16:57] <tkamppeter> xnox, here is the /etc/init/cups.conf which I using successfully for tests. It starts once CUPS on boot, for the case that there are jobs or shared printers, if not cupsd stops after 30 secs, after that it is triggered on either localhost:631 or /var/run/cups/cups.sock and also stops after 30 secs of inactivity: http://paste.ubuntu.com/7045084/
[16:57] <tkamppeter> OdyX ^^
[16:58] <tkamppeter> xnox, OdyX: Changes are the "start on ..." rule and the added "-x 30" (30 sec timeout also when started on boot) in the cupsd command line.
[16:58] <xnox> tkamppeter: next upstart release will have INET6 socket as well. I think there are corner cases, where it would fall apart. Let me test it here more.
[17:00] <rsalveti> bfiller: cool, maybe we just forgot to remove that dependency from the control file
[17:00] <rsalveti> which would be easy to fix :-)
[17:00] <xnox> tkamppeter: as root: stop upstart-socket-bridge; stop cups; start cups; start upstart-socket-bridge; stop cups; lpstat -v  -> error bad file descriptor
[17:00] <bfiller> rsalveti: we're testing it now on this branch: https://code.launchpad.net/~amanzi-team/gallery-app/gallery-app-sdk-thumbnailer/+merge/207222
[17:01] <xnox> tkamppeter: thus imho this is fragile, and shouldn't be enabled by default. And only use socket-activation on the phone, via .override file for "start on" and "exec" stanzas only.
[17:01] <xnox> tkamppeter: because we know that on phone we will not be cups-server / sharing printers.
[17:03] <dholbach> pitti, infinity: if you're around... the CC is catching up with the TB in #u-meeting
[17:03]  * pitti joins
[17:05] <tkamppeter> xnox, if you could provide me an appropriate /etc/init/cups.conf would be great.
[17:06] <xnox> tkamppeter: it should be reproducible (the bug) with yours cups.conf.
[17:06] <tkamppeter> xnox, my simple test of the pasted cups.conf and not stopping and starting cups and socket bridge makes everything working for me.
[17:07] <xnox> tkamppeter: correct. in a simple/common case it works. I'm showing the buggy behaviour that it has.
[17:07] <xnox> sudo -i -c "stop upstart-socket-bridge; stop cups; start cups; start upstart-socket-bridge; stop cups; lpstat -v"
[17:08] <xnox> sudo sh -c "stop upstart-socket-bridge; stop cups; start cups; start upstart-socket-bridge; stop cups; lpstat -v"
[17:09] <tkamppeter> xnox, sorry, I want to say the following: I will upload cups 1.7.1-5ubuntu7 with your last fix plus some further (upstream for general stability, not Upstart socket) patches and it would be great that you then upload -5ubuntu8 with appropriate .override.
[17:09] <tkamppeter> xnox, this would be great.
[17:10] <xnox> tkamppeter: hm? all of my patches are uploaded into the archive as ubuntu6.
[17:11] <xnox> tkamppeter: yeah, upload anything/everything that's needed, but don't change upstart job to auto-shutdown/be socket activated.
[17:11] <xnox> tkamppeter: i'll do that on touch only.
[17:11] <tkamppeter> xnox, and I have downloaded this and backported some upstream patches (for other bugs) and upload this as ubuntu7.
[17:11] <tkamppeter> xnox, OK, I will upload ubuntu7 then.
[17:12] <xnox> tkamppeter: gotcha. cool! =)
[17:12] <tkamppeter> xnox, the bug you mention I can reproduce with my cups.conf.
[17:15] <xnox> tkamppeter: ack.
[17:15] <tkamppeter> xnox, ubuntu7 uploaded.
[17:21] <tkamppeter> xnox, now, once I have reproduced the bug you mention, socket activation stopped working for me. How can I reset it.
[17:22] <rsalveti> bfiller: cool, but this MP is still not removing the dependencies from debian/control
[17:22] <bfiller> rsalveti: I know, it needs to be updated if all is working
[17:22] <rsalveti> great
[17:23] <xnox> tkamppeter: to recover - sudo sh -c "stop upstart-socket-bridge; stop cups; start upstart-socket-bridge; lpstat -v"
[17:30] <tkamppeter> xnox, thanks.
[17:39] <pitti> bdmurray: nice, fixed again; thanks!
[17:41] <tkamppeter> xnox, OdyX, it seems that some apps need to get modified so that they do not keep a connection to CUPS open through the whole session and are not able to reconnect when CUPS has shut down while the app is still running.
[17:41] <tkamppeter> xnox, OdyX, system-config-printer seems to have problems.
[17:42] <xnox> tkamppeter: i hope I've done my bit, and don't have to work on that =)
[17:42] <tkamppeter> xnox, I think so, too.
[17:43] <xnox> tkamppeter: i daubt it will be the only issue, e.g. i can think of monitoring systems going crazy "cups is not there, oh wait it's not there, oh it's back again" set to flapping & tripping off sysadmins.
[17:44] <xnox> tkamppeter: hence the siding to only ship socket activation on touch/mobile by default for 14.04, but keep working on enabling it by default.
[17:46] <tkamppeter> xnox, OK.
[17:52] <bdmurray> pitti: did you see my bug about apport and default browsers?
[17:53] <pitti> bdmurray: yes, I did
[18:06] <mapreri> pitti: I can't reproduce the issue -.- I also write a short pbuilder hook (http://goo.gl/exXIbN) to call adt after the build, but the tests now are always successful :S
[18:06] <mapreri> what do you suggest to try now? I'm very new to autopkgtest, maybe I'm missing something...
[18:07] <mapreri> (if you have time right now, of course)
[18:29] <tkamppeter> OdyX, I have uploaded cups 1.7.1-5ubuntu7 to Ubuntu and also committed it to the Debian GIT, in the master-ubuntu branch. It has basically working (still with some bugs) Upstart-based socket activation support, the official upstream patch for supporting avahi-daemon restarts, and several patches backported from upstream for general stability. Perhaps you want to merger one or another patch to Debian.
[18:54] <psusi> so I'm trying to debug a coredump and gdb bt just shows kernel_vsyscall, ??, ??, then stops saying previous frame is inner to this frame ( corrupt stack? ).  Is this just one really messed up core dump, or am I doing something stupid, like forgetting to install debug symbols...
[18:58] <psusi> wait... is the current trusty kernel generating broken core dumps?  there was some sort of bug about that upstream
[19:38] <Noskcaj> Laney, Thanks for the sponsoring
[19:50] <seb128> Noskcaj, you need to get upload right for universes so you can help cleaning the queue ;-)
[19:51] <Noskcaj> seb128, I want to. I'm thinking i might apply for MOTU again this month, since my timezone makes it impossible to apply after april 6th
[19:52] <seb128> Noskcaj, you can apply by email if needed I think
[19:52] <slangasek> Noskcaj: the calendar jumps straight from april 6 to Jan 1 in your timezone?
[19:53] <Noskcaj> slangasek, 19utc becomes 5am
[19:53] <slangasek> oh ;)
[19:53] <slangasek> I thought there were provisions for applying by mail
[19:53] <Noskcaj> seb128, That took 2 months and 2 irc meetings to be told i didn't have enough testimonials, so no
[19:54] <seb128> Noskcaj, just a recommendation, you need to forward to Debian directly when the change apply to them (especially if we have no delta in Ubuntu)
[19:55] <Noskcaj> seb128, I do, whenever possible
[19:55] <sladen> Noskcaj: where's your list of testimonials, how 'lacking' is it---should be reasonably easy to solve...
[19:55] <arges> bdmurray: hey, checking in. have you looked at the queue yet
[19:55] <seb128> Noskcaj, it would also be nice if you followed up on bugs you create with your sync requests
[19:56] <seb128> Noskcaj, https://launchpad.net/ubuntu/trusty/+source/cherrypy3/3.2.2-4ubuntu4 ... is was possible for example ;-)
[19:56] <Noskcaj> sladen,  ... is was possible for example ;-)
[19:56] <Noskcaj> crap
[19:56] <Noskcaj> https://wiki.ubuntu.com/Noskcaj#MOTU
[19:56] <Noskcaj> stupid irc copy/paste
[19:57] <Noskcaj> seb128, That's been forwarded to debian i think
[19:59] <Noskcaj> seb128, All the sync bugs that i've left are from some time ago and are because i lack the skills to fix the issue, so i wouldn't be making the bad syncs again
[20:00] <seb128> Noskcaj, k, I was just mentioning it because that's the sort of think I would point in your wikipage if you asked me to write some feedback in it
[20:02] <seb128> Noskcaj, https://code.launchpad.net/~noskcaj/ubuntu/trusty/cherrypy3/lp-463065/+merge/207852 ... I didn't notice it was commited to debian because there was no bug in the bts and no tag in the patch, you also didn't reply to my review comment until I changed the status 10 days later
[20:02] <Noskcaj> seb128, ok. I'll look into the current rc bug for cherrypy3 so i can get an upload with the ubuntu delta gone
[20:03] <seb128> Noskcaj, that's not the issue, we can carry a delta for that release, as long as the change is forward so we don't have to carry it forever
[20:03] <Noskcaj> yep
[20:04] <Noskcaj> the lack of response was because i had already done the changes in debian and had thought you'd merged it
[20:04] <seb128> k
[20:04] <seb128> ok, need to go
[20:04] <seb128> bbl
[20:07]  * lamont grumbles at bash completion... grep string file<tab> no longer completes - known?
[20:08] <ChrisTownsend> lamont: Yes, very annoying.  Here is the bug: https://bugs.launchpad.net/ubuntu/+source/bash-completion/+bug/1288031
[20:09] <lamont> ChrisTownsend: ta
[20:09] <ChrisTownsend> lamont: np
[20:21] <bdmurray> arges: no, I haven't yet
[20:22] <arges> bdmurray: ok. I see some green ones
[20:22] <bdmurray> arges: Why don't you focus on the queues and I'll look at the pending ones
[20:23] <arges> bdmurray: sure
[20:34] <arges> hallyn: hey I see two unapproved uploads of libvirt in the saucy queue. I think you just want the latest one. Is that right?
[20:36] <hallyn> arges: yup.  everyone was scared off by teh first one :)
[20:36] <arges> hallyn: cool thanks
[20:36] <hallyn> thank you
[21:44] <cjwatson> tedg: I'm working on the upstart-app-launch changes to make use of libclick, or at least the first batch of them, and was wondering if you could advise on testing
[21:45] <cjwatson> tedg: the test for click-exec is going to need to tell libclick to use a different database directory, to replace the current scheme where it relies on tests/click being on $PATH
[21:46] <tedg> cjwatson, Yeah. Or you can just mock out the libclick API.
[21:46] <cjwatson> tedg: would it be OK to have click-exec check an environment variable and use a different DB dir if that env var is set?
[21:46] <cjwatson> tedg: or would such a change have to be only compiled in while testing?
[21:46] <cjwatson> I'd rather be able to test the as-installed click-exec binary if possible
[21:46] <cjwatson> tedg: Yeah, I could mock it out, but it would be better to integration-test if possible I think
[21:47] <tedg> cjwatson, I don't see any reason that would be an issue, we control the environment through Upstart. If someone can add environment variables to upstart it seems we're kinda screwed.
[21:47] <cjwatson> tedg: Not least because I've just about had my fill of strange LD_PRELOAD hacks for this month
[21:47] <cjwatson> tedg: Right, and it doesn't matter if somebody runs click-exec by hand?
[21:47] <tedg> cjwatson, No, it's just set environment variables for their terminal :-)
[21:47] <tedg> it'd
[21:47] <cjwatson> OK, cool
[21:48] <cjwatson> In that case I'll send you over the first branch tomorrow (just about done for today)
[21:48] <cjwatson> A "click info" replacement isn't in place yet, so it's just "click pkgdir" for now, but I have a branch in progress for "click info" too
[21:48] <cjwatson> Will hopefully speed things up a bit ...