[03:09] <ahoneybun> when someone gets around to it can you tell me what is old and out of date other then the screenshots on this page: https://wiki.kubuntu.org/Kubuntu/Bugs/Reporting. I'll be working on it during lunch break tomorrow
[03:09]  * ahoneybun sleeps
[05:13] <ovidiu-florin> ahoneybun: Plasma-desktop
[05:13] <ovidiu-florin> This seems outdated
[05:17] <ovidiu-florin> ahoneybun: that page is for intermediate to advanced users
[05:18] <ovidiu-florin> Do we have something for new users? Beginners? Non technical people?
[09:25] <Riddell> micahg: Mirv: who knows why we have a hardcoded plugin path? https://mail.kde.org/pipermail/plasma-devel/2015-May/041692.html
[09:33]  * mitya57 looks
[09:34] <mitya57> Riddell: we pass '-plugindir "/usr/lib/$(DEB_HOST_MULTIARCH)/qt5/plugins"' to Qt's configure so that *our* own plugins are installed there. But I think that env variable should still work.
[09:35] <mitya57> I.e. in some packages we set QT_PLUGIN_PATH=$(CURDIR)/plugins when running tests, and that seems to work.
[09:35] <mitya57> qtsensors is an examples
[09:36] <mitya57> *example
[09:38] <Mirv> yes, env var should be working, I think it's used in a couple of packages run build time tests
[09:56] <Riddell> sitter: no kubuntu_wily_archive branches for frameworks?
[09:58] <sitter> not created yet
[09:58] <sitter> Riddell: https://github.com/apachelogger/kubuntu-repo-merge
[09:58] <sitter> Riddell: are you doing 5.10
[09:58] <sitter> ?
[09:59] <Riddell> sitter: I was thinking about it
[09:59] <Riddell> should I?
[09:59] <sitter> just asking because of the command :P
[09:59] <sitter> if you are doing 5.10 -> ./merge.rb -o kubuntu_unstable -t kubuntu_wily_archive frameworks
[09:59] <sitter> if not ./merge.rb -o kubuntu_vivid_backports -o kubuntu_vivid_archive -t kubuntu_wily_archive frameworks
[10:00] <sitter> former derives the branch from unstable, latter derives it from vivid_backports or if that doesn't exist from vivid_archive
[10:01] <Riddell> sitter: what about merging in debian's master branch ?
[10:01] <sitter> Riddell: that should happen via CI
[10:02] <Riddell> sitter: does it?
[10:02] <sitter> someone needs to step up and resolve the conflicts
[10:02] <Riddell> sitter: right, so it needs a manual merge first then CI an do it magically?
[10:03] <sitter> depends
[10:04] <sitter> I'd have CI merge into unstable/stable and then land that into a release branch once a new upstream release comes out
[10:04] <sitter> which would be a merge through CI with manual intervention being needed when there is a conflict
[10:05] <sitter> the other option is to use the merge tool to merge master into a release branch (such as kubuntu_wily_archive) and the release branch then gets merged into CI
[10:05] <sitter> there's no real difference between the two as far as work is concerned
[10:05] <sitter> what needs to happen is someone telling me that master or exermpeintal was merged into branch foobar such that I can enable automatic merges using CI moving forward
[10:05] <sitter> so we don't have to do these batch merges anymore
[10:13] <Riddell> sitter: it's not happy with something https://paste.kde.org/pfacotuih
[10:15] <sitter> Oo
[10:15] <sitter> Riddell: did you run bundle install?
[10:15] <Riddell> ah no good point
[10:16] <Riddell> however some documentation saying what this script does would be useful
[10:17] <sitter> Riddell: --help not clear enough?
[10:17] <Riddell> still no luck https://paste.kde.org/p7bjdbcq9
[10:21] <sitter> that makes no sense, bundle gives you exactly the same versions as I have
[10:21] <sitter> Riddell: bundle show git; ruby -v
[10:22] <Riddell> jr@gallus:~/src/frameworks/kubuntu-repo-merge (master)>bundle show git; ruby -v
[10:22] <Riddell> /var/lib/gems/2.1.0/gems/git-<IP_ADDRESS>
[10:22] <Riddell> ruby 2.1.2p95 (2014-05-08) [x86_64-linux-gnu]
[10:23] <Riddell> ooh works if I  apt remove ruby-git
[10:23] <Riddell> silly apt package
[10:24] <sitter> I wonder if maybe I should just change the instructions to bundle into the directory
[10:24] <sitter> bundler is really neat. you can basically make it put the dependencies inside the directory itself and then simply call the script through bundler so it always picks the right versions of the gems regardless of whatever else is available in the system
[10:26] <sitter> anyway
[10:26] <sitter> expanded readme a bit
[10:48] <Riddell> pushing wily branches for frameworks
[10:48] <sgclark> morning
[10:53] <Riddell> wow there's lots to merge when merging in debian's master branch
[10:57] <Riddell> sitter: not dealing too well with conflicts? https://paste.kde.org/p3ljhmbvj
[11:00] <sitter> Riddell: go into the repo, merge manually, then run script again
[11:00] <sitter> and push after merge mind you
[11:02] <sitter> the workflow is a bit meh as it cannot pick up where it left off, though tbh the code is mostly meant to end up in some KCI job and resuming is not a thing there ;)
[11:02] <sitter> wgrant: https://answers.launchpad.net/launchpad/+question/267111
[11:03] <Riddell> ug, pesky debian adding in patches without dep3 headers or even changelog entries
[11:03] <Riddell> "New patch: renamed_header"  ug renaming headers?
[11:03] <sitter> >.<
[11:03] <sitter> \o/
[11:04] <sitter> Riddell: it occurs to me that is an upstream bug
[11:05] <sitter> libkf5dnssd-dev: /usr/include/KF5/KDNSSD/dnssd/domainbrowser.h
[11:05] <sitter> so this probably wouldn't ever work -#include <kdnssd/domainbrowser.h>
[11:07] <sitter> incomplete_header probably also should go upstream as it appears to remove headers that do not actually go anywhere because their underlying thingies were removed (such as Solid/AudioInterface)
[11:18] <yossarianuk> hi - found a bug with 'ubuntu-bug' / apport-kde - it crashes 100% of the time in 15.04 if you choose certain options
[11:18] <yossarianuk> https://bugs.launchpad.net/ubuntu/+source/apport/+bug/1456579
[11:23] <Riddell> ug more patches in kio with no indication of their origin
[11:23] <Riddell> yossarianuk: I'm pretty sure that's a known bug in pyqt , check release announcement for 15.04, sorry I'm too lacking in energy to investigate
[11:23] <sitter> Riddell: tell maxy to dep3 and upstream ^^
[11:25] <yossarianuk> Riddell: thanks - this appears different to this one (which I also raised)
[11:25] <yossarianuk> https://bugs.launchpad.net/ubuntu/+source/apport/+bug/1437803
[12:04] <BluesKaj> Howdy folks
[12:04] <KDDA> hi BluesKaj
[12:05] <BluesKaj> hi KDDA
[13:02] <Riddell> sitter: pushing kubuntu_wily_archive with merges from master for frameworks
[13:03] <sitter> bummer
[13:03] <sitter> Riddell: you didn't pause integration
[13:03] <Riddell> oh hmm, does that mean I just broke the world?
[13:03] <sitter> http://kci.pangea.pub/ pointless red :'<
[13:04] <sitter> not too bad actually
[13:04] <sitter> the odd thing is
[13:04] <sitter> only part of the repos triggered a build Oo
[13:27] <sitter> ah uh oh
[13:27] <sitter> Riddell: there are some legit build failures
[13:27] <sitter> http://kci.pangea.pub/job/wily_unstable_kwindowsystem/5/console failing patch for example
[13:27] <sitter> I think it'd be good to go through all the red willys
[13:28] <sitter> hm
[13:30] <sitter> Riddell: so the reason not all jobs triggered was because most repos had nothing to push (e.g. ECM's master is from november)
[13:30] <sitter> I am not sure that is correct
[13:30] <sitter> ah
[13:31] <sitter> Riddell: ECM for example still has its changes in the experimental branch
[13:31] <sitter> I think you should talk to maxy about which stuff needs merging
[13:34] <sitter> Mirv, mitya57: since sebas asked me about it ... do we have any plans on getting qtwebengine?
[13:35] <sitter> I understand lisandro isn't too happy with it
[13:35] <Mirv> sitter: no plans. Ubuntu uses Oxide-qt which is also chromium based but with constant security updates.
[13:36] <Mirv> which means there's no pressure on the Unity side of things to get qtwebengine
[13:36] <sitter> hm
[13:37] <sebas> qtwebengine also gets constant security updates, btw (sounded a bit like qtwebengine doesn't while oxide does)
[13:37] <sebas> oxide is entirely tied to Unity though, it's really useless for anything non unity
[13:37] <sebas> I'd personally trust Qt more to maintain a chromium fork in their package
[13:37] <Mirv> sebas: ah, ok. my impression was that at least release wise upstream only releases it when doing 5.x/5.x.x releases, not when CVE:s are filed.
[13:38] <sitter> I trust no one to maintain a fork of anything :P
[13:38] <sebas> Mirv: I doubt that's practical
[13:38] <sebas> sitter: fair enough :)
[13:40] <Mirv> sebas: I'm not that familiar with Oxide myself, but I didn't know it'd be tied to Unity? looking at the build deps at least it seems all standard libraries aside from one armhf-only dependency that's probably not really optimally implemented that way
[13:40] <Mirv> both the library and QML module seem pretty standard too
[13:40] <sebas> Mirv: I tried to build it a few months ago, there's unity specifics everywhere I looked, I gave up eventually
[13:42] <Mirv> sebas: it should be just bzr bd with nothing Unity needed on x86 http://bazaar.launchpad.net/~oxide-developers/oxide/packaging.vivid/view/head:/debian/control
[13:42] <Mirv> they have a funny way of having packaging outside of the main lp:oxide though
[13:42] <sebas> Mirv: yes, I tried to build it on Debian
[13:43] <sebas> it's already a few months back, maybe things have changed, perhaps I don't remember it well enough
[13:43] <Mirv> sebas: ok, interesting that you hit blockers with that list of build deps. although chromium is never fun, I don't want to even look at those ;)
[13:43] <sebas> yes, chromium is horrible to build
[13:44] <sebas> I think the wider usecase of qtwebengine serves us a bit better mid-term
[13:44] <sitter> that makes me wonder whether steam also forked chromium for their inapp browser o_O
[13:44] <sitter> or perhaps they used the gecko
[13:44] <sebas> or webkit
[13:44] <swizgard> hi. what is the best place to start reading about compiling/packaging kdepim?
[13:44] <sitter> someone should make a gecko fork for qt
[13:45] <sitter> swizgard: google. unless you can ask a more concrete question
[13:46] <sitter> depending on what you want to do you'll want to read up on general debian packaging and using cmake at the very least
[13:47] <swizgard> sitter: i'm suffering from a bug in how kdepim handles recurrence-ids in ics-files and i want to see if i can make some crude fixes to investigate the problem further
[13:48] <swizgard> and then i want to run my own package until fixes in master trickle down to kubuntu stable
[13:49] <sitter> swizgard: http://paste.ubuntu.com/11225592/
[13:50] <swizgard> ok. but when i want to pull in git master it gets complicated, doesn't it?
[13:50] <sitter> assuming you simply want to create or apply a patch (which is what I would suggest) you want to read up on a tool called 'quilt' and possibly on the general subject of 'dpkg-source patches'
[13:50] <Mirv> sitter: well there's Jolla's https://github.com/tmeshkova/qtmozembed ...
[13:51] <sitter> swizgard: yeah, with master in the picture it gets lots more complicated
[13:51] <swizgard> ok. then maybe i will leave that for now (-: thank you!
[13:51] <sitter> swizgard: general outline is clone -> copy debian/ from existing package -> use a tool called dch to manipulate the changelog -> use that dpkg-buildpackage line I pasted to build binaries
[13:52] <sitter> depending on how far diverged master it this can be all that is necessary or but the beginning
[13:52] <sitter> swizgard: I would probably suggest that you find the exact commit that fixes your problem and import it as a single patch into the packaging
[13:53] <sitter> this would then also allow the change to be applied to official the official packages
[13:53] <sitter> Mirv: oh my xD
[13:53] <swizgard> thank you again (-:
[14:03] <Mirv> sebas: I tried to build the wily proposed Oxide in Debian. I don't see any Unity dependencies, and it starts the build, but I'm hitting some python problem. on sid.
[14:04] <Mirv> anyway if someone wants to play with it chrisccoulson on #ubuntu-devel can help understanding what's needed on Debian
[14:04] <Mirv> since I noticed it, I'll file a bug against Oxide to not use the transitional qml module packages, Debian already dropped them while we carry them until 16.04 LTS
[14:05]  * sitter still would like something better to handle qml dependencies :|
[14:10] <sebas> Mirv: thanks for that ... I've moved on by now though, so don't spend too much time on it for my sake
[14:31] <Mirv> yeah, I was just curious
[14:31] <sebas> Mirv: aye :)
[14:35] <BluesKaj> shadeslayer, did you file a bug about dolphin places ? I didn't get the chance to so and I checked this morning and someone already had filed one.
[14:39] <shadeslayer> BluesKaj: didn't you see the bug link from yesterday
[14:39] <shadeslayer> BluesKaj: https://bugs.launchpad.net/hundredpapercuts/+bug/1422469/comments/55
[14:40] <BluesKaj> !bug 347893
[14:41] <shadeslayer> what?
[14:41] <BluesKaj> not launchpad , kde-bugs
[14:41] <shadeslayer> kde bug 347893
[14:41] <BluesKaj> the bot has it wromg
[14:41] <shadeslayer> BluesKaj: there's a fix in vivid-proposed
[14:41] <shadeslayer> please test it out
[14:41] <shadeslayer> and report with results on 1422469
[14:42] <BluesKaj> hmm proposed eh , I'm on Wily already
[14:42] <shadeslayer> sitter: ^^ wasn't pushed to wily right
[14:46] <BluesKaj> I could switch over to the Vivid install and check it out
[14:46] <shadeslayer> would be nice
[14:46] <BluesKaj> bbiab
[15:08] <sitter> shadeslayer: twas not because I've been ignoring all the notifiers that told me to upload
[15:09] <shadeslayer> :)
[15:14] <BluesKaj> ok what's the proposed ppa url? not finding it on launchpad or anywhere else
[15:16] <BluesKaj> for vivid
[15:35] <sitter> Riddell: please be fixing that frameworks stuff
[15:40] <BluesKaj> actually Wily is performing better wirh plsama5 and 4 integration than Vivid
[17:29] <Etriaph> Riddell: ping
[17:29] <Riddell> hi Etriaph
[17:29] <Etriaph> Riddell: Can I query you with a quick question?
[17:29] <Riddell> you can try
[18:02] <Etriaph> Congratulations to the winners!
[18:04] <KDDA> winners?
[18:07] <Etriaph> KDDA: Council election winners; it's on both the mailing lists.
[18:07] <KDDA> ah
[18:10] <yofel> \o/
[18:12] <Etriaph> So is there any thing else that has to be wrapped up prior to tomorrow with respect to the election?
[18:12] <Etriaph> I can't change the council details on Launchpad, I'm assuming someone with take care of that?
[18:13] <yofel> I just did that
[18:13] <Etriaph> Excellent.    :D
[18:30] <KDDA> sounds like amzing fun!
[18:31] <sgclark> don't have to develop as council, they make decisions on direction and such
[18:31] <KDDA> is jonathan head of the council?
[18:32] <yofel> not officially, but we treat him as such
[18:32] <sgclark> I think he like a more equal rights heiarchy
[18:32] <KDDA> big chair and a crown ;)
[18:34] <KDDA> I need to book an appointment to get more lessons!
[18:35] <yofel> KDDA: really all we do is approve membership applications and we more or less have the last word in discussions. Most of the time we're invisible
[18:38] <KDDA> how does one package for different distro, say I have a CentOS RPM package, how does that transfer to Ubuntu with its different paths etc?
[18:40] <yofel> the paths shouldn't be different, the biggest issue would be translating the packaging.
[18:40] <yofel> There is "alien" which can attempt that on a binary package if you're desperate
[18:41] <yofel> For sources, you would really have to repackage
[18:42] <yofel> how much work that is depends on how you later build the packages, e.g. launchpad requires pretty much proper debian sources, the opensuse build service can also build debs from a bit simplier packaging
[18:42] <yofel> KDDA: how far did you get with digikam?
[18:43] <KDDA> havent got any further, waiting for another session with Riddell
[18:46] <soee> hiho
[18:48] <BluesKaj> ok gents , what's the proposed ppa url for the dolphin places patch ?
[18:54] <soee> BluesKaj: wasnt it fixed in apps ?
[18:54] <Etriaph> BluesKaj: Check 'Pre-released updates' while configuring software sources in Muon
[18:54] <soee> 15.04.1 maybe ?
[18:54] <Etriaph> soee: It's fixed in 15.04.1
[18:55] <Etriaph> soee: But there was a patch in proposed that didn't work (at least for me)
[18:55] <soee> yeah so wait for 15.04.1 backport :)
[18:55]  * Etriaph nods.
[18:55] <Etriaph> Do we have a timeline on 15.04.1 backport for 15.04?
[18:56] <Etriaph> (out of curiosity)
[18:56] <BluesKaj> yeah I'll wait for the backport. I'm on my Wily HDD atm and don't feel like switching
[18:57] <soee> Etriaph: probably not, packages are ready for Willy
[18:57] <soee> so we need some packager to backport them :)
[18:58] <Etriaph> What volume of information would I need to learn to begin that?
[19:01] <KDDA> how do I test on wily?
[19:16] <soee> KDDA: its in ppa https://launchpad.net/~kubuntu-ppa/+archive/ubuntu/next-stage2/+packages
[19:17] <KDDA> you mean the "Packages in “Kubuntu Next Stage 2 (DON'T USE)”" one?
[19:26] <soee> yes
[19:30] <BluesKaj> KDDA, I changed my sources.list with this: sudo sed -i 's/vivid/wily/g' /etc/apt/sources.list , then update and upgrade. Of course you'll need to backup your data
[19:31] <KDDA> I have wily installed
[19:31] <soee> i would say: wait for alpha :)
[19:31] <KDDA> I want to learn how to package
[19:31] <soee> Riddell: ^ :)
[19:32] <BluesKaj> that's my method of upgrading to Wily ... it's working fine , just don't use it on a critical pc
[19:32] <soee> KDDA: i want to tbh
[19:32] <soee> but my time is limited atm
[19:32] <KDDA> BluesKaj: there was an appeal to test KApps
[19:32] <KDDA> but the PPA says do not use
[19:33] <KDDA> in capital letters!
[19:33] <BluesKaj> that's true KDDA , but if you're a brave tester then ignore warnings :-)
[19:34] <KDDA> but its capital letters, thats shouting!
[19:34] <soee> KDDA: those packages that are ready to test must land somewhere
[19:34] <soee> so we are using thise ppas
[19:34] <soee> iv been testing a lot of releases from them
[19:35] <soee> you can always ppa-purge it if you get some critical errors
[19:37] <KDDA> any major bugs so far?
[19:45]  * BluesKaj takes the plunge with ppa:kubuntu-ppa/next-stage2
[20:46] <BluesKaj> well ,so far so good with the ppa:kubuntu-ppa/next-stage2
[20:46] <soee> ;]
[20:48] <ahoneybun> congrats to valorie shadeslayer and yofel
[20:58] <shadeslayer> ahoneybun: thanks! :)
[20:58] <shadeslayer> ahoneybun: and thanks for running!
[21:00] <yofel> ahoneybun: thanks :)
[21:00] <ahoneybun> np shadeslayer and yofel
[21:01] <yofel> your next chance is in a year, make yourself famous till then ;)
[21:01] <ahoneybun> have anyone of you use a ISO to fix Windows EFI bootloader?
[21:02] <soee> what did just happend ?
[21:06] <yofel> soee: council elections ended
[21:06] <soee> oh and i missed it :(
[21:06] <yofel> soee: nothing changed ;P
[21:06] <soee> anyway congrats to to new council members :)
[21:22] <KDDA> do they get new company cars and benifits?
[21:23] <shadeslayer> I wish
[21:23]  * shadeslayer wants a BMW M4
[21:23] <shadeslayer> the performance model :P
[21:26]  * yofel wants a tesla model X when it's out
[21:28] <KDDA> anyone know why shutdown sometimes fails from within my session?
[21:30] <shadeslayer> yofel: meh @ suv's
[21:30] <shadeslayer> though those gull wing doors :3
[21:31] <yofel> shadeslayer: usually I agree, but that's the only one I could settle wiith ;)
[21:31] <shadeslayer> I'm willing to settle for a Electric DMC 12
[21:31] <shadeslayer> one that goes upto 88 KMPH
[21:31] <yofel> hehehe
[21:33] <shadeslayer> yofel: http://delorean.com/dmcev/
[21:33] <shadeslayer> what a lovely car
[21:33] <yofel> that slogan XD
[21:34] <yofel> just perfect
[21:34] <shadeslayer> xD
[21:35] <shadeslayer> I don't think they're making new chassis for those anymore
[21:35] <shadeslayer> which is sad
[21:35] <shadeslayer> so they only have pre owned ones http://delorean.com/for-sale/
[21:36] <shadeslayer> only slightly unreasonable prices :P
[21:36] <shadeslayer> I was expecting them to be upwards of 60K USD
[21:36] <KDDA> they dont need gas, they need petrol
[21:55] <mparillo> I am running Plasma 5.2.2, with oxygen yellow cursor theme, but otherwise pretty stock Kubuntu. When I mouse down to reveal the panel, my cursor goes black on one laptop (15.04) but not the other (15.10). (1) Can anybody replicate? (2) If so, can anybody guess the component to file a bug report (I assume at bugs.kde.org).
[23:29] <valorie> wow, used Deloreans cost more than my nifty new hybrid Subaru
[23:29] <valorie> also, thank you to all who ran for the Council, and Etriaph for running the election!
[23:41] <Etriaph> yw!
[23:48]  * ahoneybun yells at silly UEFI


[06:18] <Quintasan> Good morning.
[07:42] <geser> good morning
[07:53] <dholbach> good morning
[10:27] <mitya57> dholbach: hi
[10:27] <dholbach> hey mitya57
[10:27] <mitya57> are you able to retry builds?
[10:27] <dholbach> yes, I should IIRC
[10:27] <mitya57> last time it helped (see bug 1039721)
[10:27] <tumbleweed> if you can upload a package, you can retry its builds
[10:28] <dholbach> ll right
[10:28] <dholbach> will do
[10:28] <mitya57> thank you
[10:28] <dholbach> mitya57, https://launchpad.net/ubuntu/+source/sphinx/1.1.3+dfsg-7ubuntu1/+build/4308887
[10:28] <dholbach> mitya57, I wanted to ask you about the translator credits branch: when is the script going to be run and what needs to be installed where to make it work?
[10:29] <mitya57> dholbach: you can run it on the server directly, the only dependency is python3-polib
[10:29] <mitya57> I can add python2 compatibility if needed
[10:30] <dholbach> mitya57, none of the two are installed on the machine currently, so I'll have to file an RT any way
[10:30] <dholbach> mitya57, I'll review the branch again and add to my TODO list
[10:35] <mitya57> dholbach: maybe I should make that HTML page build during package build?
[10:35] <dholbach> sure, why not
[10:36] <mitya57> will do now
[10:36] <dholbach> rock and roll
[10:36] <dholbach> mitya57, pt_BR is up to 57% :)
[10:36] <mitya57> ru on 84% :)
[10:37] <dholbach> yeah - great work
[10:38] <dholbach> 20% for 'de', will take a bit longer :)
[10:39] <mitya57> 20% is already a big progress
[11:11] <dholbach> mitya57, a-page-a-day :)
[11:19]  * mitya57 will test the build-translators-page patch and also do his a-page-a-day
[11:52] <mitya57> dholbach: I've updated the branch
[11:53] <dholbach> mitya57, thanks a bunch - I'll take a look later on
[11:54] <mitya57> dholbach: wait, there are some 10 commits there, I'll now maybe redo it in a cleaner way and push --overwrite
[11:54] <dholbach> ok
[11:54] <mitya57> (and also resolve conflicts)
[11:56] <mitya57> dholbach: also: does anybody care about dirhtml target? it looks broken to me...
[14:34] <cjohnston> cmake needs "PYTHON3_LIBRARY" to be defined. I'm unable to determine the path that it should point to. Suggestions?
[15:00] <hrw> cjohnston: /usr/lib/TRIPLET/ probably
[15:11] <cjohnston> thanks hrw
[15:44] <ESphynx> Good morning :)
[23:34] <ESphynx> micahgc: =)
[23:35] <ESphynx> -c


[06:16] <tgm4883> According to the scope tutorial (I'm loooking at the sound cloud one) I should be able to run the scope at any time. Does that include immediatly after creating a new scope?
[08:12] <iloverivi> [ASK] can i update kit (ubuntu-sdk-14.04) from terminal? how? thanks
[08:13]  * iloverivi [ASK] can i update kit (ubuntu-sdk-14.04) from terminal? how? thanks
[17:15] <PaoloRotolo> Hi all!
[17:15] <PaoloRotolo> Can you please tell me how can I detect if an HTML5 app is running on Ubuntu Touch?
[17:41] <PaoloRotolo> mhall119, :)?
[19:28] <mhall119> PabloRubianes: what do you mean?
[19:28] <mhall119> like, check if the process exists? or that it's active and not suspended?
[20:04] <popey> mhall119: i think he means self awareness "Am I running on Ubuntu or FFOS or something else"
[20:05] <popey> (I guess if you had a common code base this may be useful)
[21:11] <mzanetti> hey. I have this http://paste.ubuntu.com/10131771/
[21:11] <mzanetti>  in my app's content-hub hook. Yet it doesn't show up as a destination for images. Anyone has a hint on what I'm missing?
[21:16] <mzanetti> ah... found it... it's "share", not "destination".


[00:30] <Unit193> !away > krokus
[02:51] <phunyguy> @mark #ubuntu-offtopic ImTheBitch inappropriate nick, and possible content.  More at 11.
[10:49] <k1l> @mark #ubuntu s trolling
[15:41] <Pici> @mark #ubuntu-offtopic metamorphosis nsfl image and discussing politics. Gave guidelines, hopefully they follow them.
[15:56] <IdleOne> You are much more forgiving than I would have been
[15:59] <Pici> hmmm
[15:59] <Pici> not that we really need it, but the new j extban could be useful for namespace bans.
[16:00] <tsimpson> http://blog.freenode.net/2014/06/new-extban-j/ new ban type
[16:01] <Pici> i.e. we setup #ubuntu-bans or similar, and have every other Ubuntu channel just +b $j:#ubuntu-bans.  So that when we ban someone in u-bans, it applies everwhere else.
[16:01] <Pricey> Seems a bit excessive to me.
[16:02] <IdleOne> it would only be needed in excessive cases
[16:02] <Pici> again, we really haven't had a need for those sort of things in a long time.
[16:02] <Pricey> I look forward to the bureaucracy around adding and removing bans to that channel ;)
[16:05] <IdleOne> Pici: I would call it #ubuntu-namespace-bans but it could be useful on very rare occasions
[16:18] <phunyguy> ban all the things.
[16:20] <bazhang>  /b phunyguy
[16:20] <bazhang> whoopsie!
[16:20] <phunyguy> :)
[20:41] <genii> I get a feeling we're going to see this a few more times yet in the future.
[23:24] <sarnold> hello; Gnar in #ubuntu-touch may deserve a close eye...
[23:27] <sarnold> ah. nice. no one fed the troll and he left. :D


[16:03] <glenn_> hi
[16:09] <ikonia> hello glenn_
[16:10] <glenn_> he ikonia my problem is solved
[16:12] <glenn_> hello ikonia


[00:52] <davecheney> wallyworld: is there a page on the wiki describing the days the company is closed this year ?
[00:53] <wallyworld> davecheney: not sure, i know there was something about the 28th. let me see if i have anything in my email
[00:55] <wallyworld> davecheney: this is all i know - it says company closed between xmas and new year https://wiki.canonical.com/PeopleAndCulture/Policies/Leave
[00:55] <davecheney> i love how out of date this information is
[00:55] <wallyworld> but there's a separate page somewhere with reference to the 28th being a free day
[00:55] <davecheney> it makes it really useful
[00:55] <wallyworld> yeah
[00:56] <davecheney> there is an up to date pdf on the page
[00:56] <davecheney> thanks
[00:58] <wallyworld> davecheney: i think that pdf is the one with the free day etc
[06:48] <TheMue> Morning
[07:19] <fwereade> TheMue, rogpeppe: heyhey
[07:19] <TheMue> fwereade: Hi
[07:21] <TheMue> fwereade: The improved firewaller is in at https://codereview.appspot.com/6875053/
[07:21] <fwereade> TheMue, cool, looking
[07:21] <TheMue> fwereade: Cheers
[07:42] <fwereade> TheMue, what happens when a machine has a unit removed after initGlobalPorts and createMachineData?
[07:42] <fwereade> s/and/and before/
[07:43] <TheMue> fwereade: This is catched by the error check for an unassigned machine.
[07:44] <fwereade> TheMue, and what happens in response?
[07:45] <fwereade> TheMue, I don't get how you can distinguish between "this unit is not assigned to the machine I'm looking at: keep it around until we find the machine that does"
[07:45] <TheMue> fwereade: Today the unit is skipped, but you're right, it should be dropped from those temporary stored units.
[07:46] <fwereade> TheMue, but then the first machine you process will trash all the others, won't it?
[07:46] <TheMue> fwereade: Why?
[07:47] <fwereade> TheMue, because it will go through all the valid data saying "nope, not mine, trash it" -- won't it?
[07:47] <TheMue> fwereade: Each machine data, when created, is scanning the remaining units from the initial scan and checks, if that unit is assigned to the machine the data is representing.
[07:47] <TheMue> fwereade: No, I only should trash those without any assigned machine id. Today I just skip it.
[07:47] <fwereade> TheMue, yes
[07:48] <fwereade> TheMue, and you *have* to
[07:48] <TheMue> fwereade: Line 228.
[07:48] <fwereade> TheMue, because that unit might be assigned to another machine
[07:48] <TheMue> fwereade: So far it's by accident as good as it is. ;)
[07:49] <fwereade> TheMue, ok, what I'm afraid I'm saying is that you have I think rearranged the problems but not fixed them
[07:49] <TheMue> fwereade: I had this when during testing units have been created while init runs in background and those units are not yet assigned.
[07:50] <fwereade> TheMue, the fundamental problem is that you cannot effectively take a delta between the initial-scan state and the state at the point where you've started all the watches you need
[07:51] <TheMue> fwereade: machineData and unitData are proper initialized before returning to the loop. I had masses of runs with debugging statements. They shown that, depending on who is faster, init, adding or mixed, the state afterwards is always correct.
[07:52] <TheMue> fwereade: Yes, you never can, because scanning it initially takes time, especially when state is large, and during this time state can be changed.
[07:54] <TheMue> fwereade: So this CL fetches its initial state as good as it can and at the time machineData and unitData are created it looks if those initial units match to them.
[07:54] <fwereade> TheMue, so how are you in a position to assume that the initial-changes state that you build up corresponds to the globalUnitPorts state you built up before?
[07:55] <fwereade> TheMue, ISTM that a removed unit will stay in globalUnitPorts forever
[07:56] <TheMue> fwereade: Yes, that's the only problem I still have. I have no kind of safe signal that says "Now you can clean it up, guy."
[07:56] <fwereade> TheMue, yeah
[07:57] <fwereade> TheMue, and this is an inescapable consequence of the decision to separate the initial scan from the creation of the watchers, isn't it?
[07:57] <TheMue> fwereade: One way could be a kind of timer checking those entries from time to time if they are removed.
[07:57] <fwereade> TheMue, it's just another layer of paper over the problem
[07:57] <TheMue> fwereade: Sure.
[07:58] <TheMue> fwereade: We need the initial scan to look if the current open ports are those we need when the Firewaller starts.
[07:58] <TheMue> fwereade: And the initial scan needs time.
[07:59] <TheMue> fwereade: And during this time the state can (and will) change.
[07:59] <fwereade> TheMue, understood -- but why don't you also create the *Datas at that point?
[07:59] <fwereade> TheMue, they hold the watchers which have properties that allow us to avoid this problem
[07:59] <TheMue> fwereade: Thought about it, niemeyer disliked it.
[07:59] <TheMue> fwereade: But here it's the same problem.
[08:00] <TheMue> fwereade: Starting those watchers still produces a gap while scanning.
[08:04] <fwereade> TheMue, the initial events from those watchers *give* you the initial state, don't they?
[08:05] <TheMue> fwereade: At least if I start the right ones which may possibly not happen because the state changes while I'm scanning to know which watchers I have to start.
[08:06] <fwereade> TheMue, er, don't you just need to start the machines watch and handle the initial event?
[08:07] <TheMue> fwereade: That's what the firewaller has done in his first "release", just that.
[08:07] <TheMue> fwereade: :/
[08:08] <fwereade> TheMue, I've never seen the FW setting up initial UD state by consuming the first event from the unit watcher before starting the watchLoop
[08:08] <fwereade> TheMue, did it really do that>
[08:09] <fwereade> TheMue, AFAICS the only way to do this reliably is to follow that model
[08:09] <rogpeppe> fwereade, TheMue: morning!
[08:09] <TheMue> fwereade: Please rephrase the UD sentence.
[08:09] <TheMue> rogpeppe: Morning.
[08:09] <fwereade> TheMue, if everything in the data tree makes sure it's initialized via initial event before starting its watch loop
[08:10] <fwereade> TheMue, then all you need to do the global port open/close (just once) at the end of the first machinesw.Changes event
[08:10] <fwereade> s/need to/need is to/
[08:11] <fwereade> no that s/ is crack
[08:11] <fwereade> whoops, no, it's what I meant
[08:11] <fwereade> TheMue, er, am I making any sense?
[08:13] <TheMue> fwereade: I have to think about it more.
[08:13] <TheMue> fwereade: It would avoid possibly remaining removed units in that one map, yes.
[08:14] <TheMue> fwereade: But it would totally change the way of initialization and have to check how this effects the instance mode, because we here talk about the global mode.
[08:14] <TheMue> fwereade: *sigh*
[08:19] <fwereade> TheMue, yeah, I'm sorry :(
[08:19] <TheMue> fwereade: Fridays discussion ended with this proposal, but seems it falls too short.
[08:22] <fwereade> TheMue, I was always trying to communicate that separating watcher setup from initial scanning was intrinsically broken -- sory I haven't been very effective at that
[08:22] <TheMue> fwereade: Funnily it works really fine, it only has the I-dont-know-if-those-left-units-are-removed-during-startup-in-global-mode-problem.
[08:22] <fwereade> TheMue, which is exactly the bug we're concerned about
[08:23] <fwereade> TheMue, fwiw, you've also introduced a goroutine-unsafety bug in unitData.watchLoop
[08:23] <fwereade> TheMue, ud.ports is used on the main goroutine
[08:24] <TheMue> fwereade: Could you point me to the line?
[08:24] <fwereade> TheMue, old: line 542 removed; new: lines 612, 615 changed
[08:25] <TheMue> fwereade: IMHO the goroutine is started after initialization (btw opposit to the former solution).
[08:25] <fwereade> TheMue, sorry, rephrase please?
[08:26] <TheMue> fwereade: Seems to be independent, sorry. I have a deeper look. Thought you meant something different.
[08:27] <dimitern> jam, wallyworld, rogpeppe: PTAL https://codereview.appspot.com/6877054/
[08:28] <TheMue> fwereade: But I see the problem, yes. I stumbled about the same naming ports as field (where it's just used by the Firewaller itself) and the local variable. Shit, has been intended, but not lucilly.
[08:28] <TheMue> luckilly
[08:28] <TheMue> Hehe, this word doesn't exist.
[08:28] <TheMue> Just lucky.
[08:28] <fwereade> TheMue, sorry, I'm still a bit confused :)
[08:30] <TheMue> fwereade: In the old version the unitData has a field named ports and in watchLoop() a variable named ports. I thought that this has been a mistake, but that has been intended.
[08:30] <TheMue> fwereade: So my "correction" has been wrong.
[08:30] <fwereade> TheMue, yeah, it's definitely required, but it demands close reading -- probably worth a comment for future reference
[08:30] <TheMue> fwereade: Yes.
[08:30] <fwereade> TheMue, otherwise people will definitely try the same "correction" in future :)
[08:31] <TheMue> fwereade: Maybe also a better naming. Dunno, will think about it. First I'll mark it again as WIP.
[08:32] <fwereade> TheMue, cool, thanks
[08:32] <TheMue> fwereade: Done
[08:33] <TheMue> fwereade: So the problem now is, that following your/our approach is a larger change.
[08:34] <TheMue> fwereade: And starting the datas based on the initial event is independent of instance or global mode.
[08:34] <TheMue> fwereade: The later ony is interesting to mark ports as opened and to manage the ref count.
[08:35] <TheMue> fwereade: Which can be handled during this startup phase.
[08:36] <TheMue> fwereade: So, before entereing the firewaller loop, init is called waiting for the first machine watcher event.
[08:37] <TheMue> fwereade: It starts the machines, but then? Hmm, how do I know that all unit watchers and service watchers are set up based on it?
[08:38] <TheMue> fwereade: All machines have to notify the init via a channel when they are done and the same with units and services, bottom up.
[08:38] <TheMue> fwereade: Does that makes sense?
[08:39] <fwereade> TheMue, sorry, I'm still processing
[08:40]  * TheMue thinks of a concurrently initializing tree which at least has to signal the firewallers init that it's done so that it can continue and enter the loop.
[08:40] <fwereade> TheMue, the trouble is partly that I haven't ever analysed the non-global mode
[08:41] <TheMue> fwereade: Hehe
[08:42] <fwereade> TheMue, but I *think* that the "initial scan" can be perfectly synchronous if the MD creation goes something like...
[08:42] <fwereade> w := m.WatchUnits()
[08:42] <fwereade> units := <-w.Changes()
[08:42] <fwereade> for _, u := range units {
[08:42] <fwereade>     // create unit data similarly
[08:42] <fwereade> }
[08:42] <fwereade> go md.loop(w)
[08:43] <fwereade> TheMue, (very poorly sketched ofc)
[08:44] <TheMue> fwereade: When are the ud loops started?
[08:44] <fwereade> TheMue, exactly the same model as the MD ones
[08:45] <TheMue> fwereade: Then it's very similar to my thought, only expressed in code. ;)
[08:45] <fwereade> TheMue, so, after you've created all your MDs (synchronously) in the first event
[08:46] <fwereade> TheMue, sorry -- it's the thought I've been trying to communicate for a week or 2 ;p
[08:46] <TheMue> fwereade: *rofl*
[08:46] <TheMue> fwereade: To come back to the mode question.
[08:47] <TheMue> fwereade: IMHO independent of the mode the startup of the watcher is always the same. What differs is, how the firewaller itself (the type Firewaller) handles those informations based on the mode.
[08:48] <TheMue> fwereade: And here instance and global mode have to be handled differently, yes.
[08:48] <fwereade> TheMue, yes, indeed -- in global mode you can do a flush-everything at the end of the first machine event, and in instance mode just flush each machine as it's handled
[08:49] <TheMue> fwereade: +1
[08:49] <fwereade> TheMue, I *think* this also means you can drop everything global* except globalPortRef
[08:50] <TheMue> fwereade: A ref != 0 means true, yes
[08:50] <fwereade> TheMue, you just need to be a little bit careful about updating it for initial events in create methods *only* before the first init run has completed
[08:50] <fwereade> TheMue, and subsequently doing so only as a consequence of flushes
[08:51] <fwereade> TheMue, ...or maybe I'm overcomplicating it
[08:51] <TheMue> fwereade: Could you please explain your thoughts more.
[08:53] <fwereade> TheMue, I think that I misspoke -- you never need to touch the refcounts while you're doing the "initial scan", they can be handled purely on the main goroutine as they currently are
[08:54] <TheMue> fwereade: Am I right you're thinking of a kind of "init" argument set to true during startup and later being false and internally work as described above only when it's true?
[08:54] <fwereade> TheMue, I *was*, but I don't think it's needed by anything except the main FW loop, so it can just be a var therein
[08:55] <fwereade> TheMue, sorry, bbiab
[08:55] <TheMue> fwereade: Hmm, I need the refcounts at the end of the startup to compare the needed ports to the currently open ports.
[08:55] <fwereade> TheMue, you can build the refcounts during the initial global flush, can't you?
[08:56] <TheMue> fwereade: Pardon?
[09:02] <fwereade> TheMue, sorry, back
[09:02] <TheMue> fwereade: NP
[09:03] <fwereade> TheMue, when you first do the initial global mode flush, won't you have a complete set of MDs and UDs available?
[09:03] <fwereade> TheMue, so you can just build the refcounts from that data
[09:04] <fwereade> TheMue, I think?
[09:05] <TheMue> fwereade: So you think of an explicit flush at the end of the init? Otherwise I have somewhere to remember that it's the first time.
[09:05] <fwereade> TheMue, yeah, exactly -- I'm saying that I think the only place you need that information is within the main FW loop
[09:07] <fwereade> TheMue, I could well be wrong though -- I'm hardly conversant with all the details of the FW
[09:07] <TheMue> fwereade: In the loop? Opposit to a firewaller field?
[09:07] <fwereade> TheMue, yeah -- I can't see when else you'd need it -- but you know the FW better than I do
[09:08] <TheMue> fwereade: We're still talking about the ref count? Just to make sure.
[09:08] <fwereade> TheMue, maybe "initial global mode flush" is the wrong term?
[09:08] <fwereade> TheMue, yeah, we're talking about the refcounts
[09:08] <fwereade> TheMue, they can be build up in initGlobalMode
[09:09] <TheMue> fwereade: I need access to it in the method flushGlobalPorts().
[09:09] <fwereade> TheMue, but *that* only needs to be called, once, at the end of the first machines change
[09:09] <fwereade> TheMue, doesn't initGlobalMode call flushGlobalPorts? I may be confused
[09:10] <TheMue> fwereade: Not today, but I would do it at the end of the init after the change we talked about and when global mode is active.
[09:10] <fwereade> TheMue, ah, no, I'm on crack, sorry
[09:10] <fwereade> TheMue, so "flush" was the wrong term
[09:10] <TheMue> fwereade: But it's also needed later, it is the alternative to flushInstancePorts()
[09:10] <TheMue> fwereade: You smoke too much. *lol* And maybe the wrong stuff.
[09:11] <TheMue> fwereade: *scnr*
[09:11] <fwereade> TheMue, what I'm trying to say is that if you call initGlobalMode after handling the first machines change
[09:11] <fwereade> TheMue, you can use all the MD/UDs that have been built up -- and never have to hit state at all
[09:11] <fwereade> TheMue, it's a simple loop through all the units to count up the port refs
[09:12] <fwereade> TheMue, and then do the usual open/close as you currently do at the end of initGlobalMode
[09:12] <TheMue> fwereade: Yes, that's right, here I would update the refcounts based on the datas, compare it to the open ports and handle the needed opens and closes.
[09:12] <fwereade> TheMue, ...and then you're done, because you *know* that any changes from that state are already being watched for
[09:13] <fwereade> TheMue, and will be handled sanely once you hit the main loop select again
[09:13] <TheMue> fwereade: Bingo!
[09:14] <fwereade> TheMue, the only wrinkle about which I am still uncertain is service exposure
[09:15] <TheMue> fwereade: If that changes during init?
[09:15] <fwereade> TheMue, just in general -- I know there's code to handle it but I've never needed to tease out the details
[09:15] <fwereade> TheMue, but, yes, the same general strategy needs to be used, I think
[09:16] <TheMue> fwereade: We're watching the expose flag to see if a service is exposed. That's covered today in init (what will change) and during runtime (by the watches).
[09:18] <fwereade> TheMue, yeah -- my point is that you need to unify init and watcher setup in the same way we discussed for MD/UD
[09:19] <TheMue> fwereade: Yep, the whole chain MD/UD/SD.
[09:20] <fwereade> TheMue, I think it's pretty easy so long as you're careful to make sure all your *Data creation is done on the main goroutine
[09:20] <fwereade> TheMue, including for subsequent events
[09:21] <TheMue> fwereade: Yes, sounds reasonable.
[09:21] <fwereade> TheMue, cool :)
[09:22] <TheMue> fwereade: So I think I'll exactly do this now.
[09:22] <fwereade> TheMue, great
[09:22] <fwereade> TheMue, tyvm for your time on this, I'm sorry it's such a hassle
[09:23] <TheMue> fwereade: No, it's absolutely great to do this kind of design review.
[09:23] <TheMue> fwereade: I have to thank you.
[09:25] <fwereade> TheMue, always a pleasure :)
[09:41] <fwereade> btw TheMue, or rogpeppe, I need another review on https://codereview.appspot.com/6864050/ if either of you has a moment
[09:43] <rogpeppe> fwereade: looking
[10:06] <rogpeppe> fwereade: you've got a review
[10:07] <rogpeppe> fwereade: BTW i don't *think* it's possible for the transaction mechanism to determine which op failed.
[10:07] <rogpeppe> fwereade: because the asserts are executed in a distributed way
[10:07] <fwereade> rogpeppe, I'm still not sure it's a good idea -- but it should at least be able to figure out the doc, right?
[10:07] <rogpeppe> fwereade: i'm not sure
[10:08] <rogpeppe> fwereade: because it can't do the check and write the doc in the same moment
[10:09] <rogpeppe> fwereade: if someone else happens to execute the transaction, how do we get that information back to the entity that started that transaction?
[10:12] <fwereade> rogpeppe, you could be right
[10:12] <fwereade> rogpeppe, I suspect it would still be possible, but almost certainly not worth the effort :)
[10:13] <rogpeppe> fwereade: i'm not sure actually. seeing when a transaction fails and writing some information about it is non-atomic, and it needs to be atomic to work.
[10:16] <fwereade> rogpeppe, maybe so, I certainly don't claim to understand all the nuances of txn's implementation
[10:17] <rogpeppe> fwereade: neither me :-)
[10:31] <fwereade> rogpeppe, TheMue: I have a couple of responses to the reviews, would appreciate your thoughts
[10:31] <fwereade> rogpeppe, (I'm not disagreeing that a comment is called for, btw, I'm explaining the logic in case I'm on crack)
[10:31] <TheMue> fwereade: Already writing.
[10:33] <fwereade> morning Aram
[10:33] <Aram> yo
[10:40] <rogpeppe> fwereade: replied
[10:41] <rogpeppe> Aram: hiya
[10:41] <Aram> hey there
[10:41] <fwereade> rogpeppe, TheMue, cheers guys
[10:41] <TheMue> fwereade: YW
[10:41] <TheMue> Aram: Hiay
[10:41] <TheMue> Hiya
[10:41] <Aram> hello.
[10:42] <TheMue> Grmpf, fingers too fast.
[10:44] <fwereade> oh, bugger, doc appointment, bb after lunch
[11:33] <wallyworld> dimitern: hi, i just commented on your mp
[11:33] <dimitern> wallyworld: hey, 10x
[11:33] <wallyworld> sorry about the delay, i was eating dinner and having a few tasty drinks :-(
[11:33] <wallyworld> :-) i mean
[11:34] <dimitern> wallyworld: no worries :)
[11:34] <dimitern> wallyworld: the FlavorDetail used internally is enough to return lists of either Entity or FlavorDetail with the HTTP API
[11:36] <wallyworld> dimitern: ok, so long as the current goose nova client can unmarshall the data as returned by the double, then i;m happy :-)
[11:36] <dimitern> wallyworld: certainly
[11:37] <wallyworld> dimitern: i'll plug in the live/local tests once this lands and we can see how it all pans out
[11:38] <dimitern> wallyworld: yep, can't wait already
[11:39] <dimitern> rogpeppe: when you can, could you look at my CL please?
[11:39] <rogpeppe> wallyworld: i've just sent another review of your errors CL
[11:39] <wallyworld> dimitern: yeah, when you have worked on a branch for a little while, you just want it to land!
[11:39] <rogpeppe> wallyworld: perhaps we could have a chat about it some time
[11:39] <rogpeppe> dimitern: which one?
[11:40] <wallyworld> rogpeppe: ok, let me take a look
[11:40] <dimitern> rogpeppe: https://codereview.appspot.com/6877054/
[11:40] <rogpeppe> dimitern: looking
[11:43] <wallyworld> rogpeppe: happy to chat when you have a moment, after you finish reviewing. just ping me
[11:46] <rogpeppe> dimitern: sorry, "d" is shorthand for "delete this line" (ed(1) syntax :-])
[11:47] <dimitern> rogpeppe: I see :)
[11:47] <niemeyer> Hello all
[11:47] <rogpeppe> niemeyer: mornin'
[11:47] <dimitern> niemeyer: hiya
[12:15] <rogpeppe> dimitern: you've got another review
[12:15] <rogpeppe> wallyworld: ping
[12:16] <dimitern> rogpeppe: thanks!
[12:16] <wallyworld> rogpeppe: mumble?
[12:16] <rogpeppe> wallyworld: what *is* mumble??
[12:16] <wallyworld> oh, maybe google hangout?
[12:16] <wallyworld> rogpeppe: mumble is a chat program, like skype
[12:16] <rogpeppe> wallyworld: i'd be happy to use mumble if i knew what it was :-)
[12:16] <wallyworld> except free, open source etc
[12:16] <rogpeppe> wallyworld: ah
[12:17] <rogpeppe> wallyworld: i'll give it a go. presumably i can apt-get it?
[12:17] <wallyworld> yeah, believe so. but you need a passwrd etc for the server - it's on y=the wiki
[12:17] <wallyworld> i'll see if i can dig up a link
[12:18] <wallyworld> rogpeppe: https://wiki.canonical.com/StayingInTouch/Voice/Mumble
[12:27] <rogpeppe> wallyworld: ok, i'm on mumble
[12:28] <rogpeppe> wallyworld: which space do you use?
[12:28] <wallyworld> rogpeppe: goto cloud engineering kitchen?
[12:33] <dimitern> rogpeppe: settings links to []nova.Link{} prevents AddFlavor/Server from generating them (it does that when links == nil). Not setting them will cause DeepEquals  to fail and will force the unnecessary IMHO creating the full list of links every time I need to compare what's in the state vs. what I set there.
[12:34] <dimitern> s/settings/setting
[12:50]  * niemeyer => reboot
[13:12] <niemeyer> fwereade: ping
[13:12] <fwereade> niemeyer, pon
[13:12] <fwereade> er, pong
[13:12] <niemeyer> fwereade: Heya :)
[13:12] <niemeyer> fwereade: pon is great, though
[13:12] <fwereade> niemeyer, how's it going?
[13:12] <niemeyer> fwereade: We should totally switch over
[13:13] <niemeyer> pin.. pon
[13:13] <fwereade> niemeyer, yeah, think how much typing we'd save :)
[13:13] <fwereade> niemeyer, thanks for your reviews last night, very helpful
[13:14] <niemeyer> fwereade: No worries.. that's actually what I'm pinging about.. is there anything you'd like to chat on to unblock?
[13:15] <fwereade> niemeyer, I think I'm good, thanks
[13:16] <fwereade> niemeyer, I'm still marshalling my thoughts re testing methods
[13:17] <niemeyer> fwereade: Coolio
[13:17] <fwereade> niemeyer, I guess the differing perspective may be that I see the testing methods as implying "do all required busywork to get to the point where I can call, say, RemoveService"
[13:18] <fwereade> niemeyer, but the current uses are not very compelling
[13:19] <fwereade> niemeyer, I'm fine dropping AddAnonymousService, but I reserve the right to get it out and wave it around if and when I spot a situation that deserves it, even if it probably never deserves to go on a shared test case
[13:19] <fwereade> s/case/suite/
[13:20] <fwereade> ;)
[13:22] <niemeyer> fwereade: Hehe :)
[13:22] <niemeyer> fwereade: Sounds good :)
[13:38] <TheMue> lunchtime, biab
[14:00] <niemeyer> rogpeppe: Regarding this comment:
[14:00] <niemeyer> """
[14:00] <niemeyer> one possibility would be to allow forcing the version number only, and have
[14:00] <niemeyer> version.Current always report the current series.
[14:00] <niemeyer> """
[14:00] <niemeyer> rogpeppe: I don't get the idea
[14:00] <niemeyer> rogpeppe: version.Current.Series already does report the current series
[14:01] <rogpeppe> on a call, back in mo
[14:02] <niemeyer> rogpeppe: Suppa
[14:06] <rogpeppe> niemeyer: version.Current.Series doesn't report the current series if the version is forced, i think
[14:07] <rogpeppe> niemeyer: i may be wrong, let me check
[14:07] <rogpeppe> niemeyer: no, that's right
[14:07] <niemeyer> rogpeppe: Ah, I see what you meant
[14:08] <niemeyer> rogpeppe: Hacking the hack sounds a bit hackish :-)
[14:08] <rogpeppe> niemeyer: actually we'd be making the hack slightly smaller
[14:08] <rogpeppe> niemeyer: by making it change the version number only
[14:09] <niemeyer> rogpeppe: I guess so
[14:09] <niemeyer> rogpeppe: I'll have a look at this
[14:12] <fwereade> brb cleaner cleaning
[14:18] <niemeyer> rogpeppe: Actually, on a second thought, I don't understand why that matters for that particular CL
[14:18] <rogpeppe> niemeyer: aren't you trying to verify that an instance with the given series is actually started?
[14:19] <niemeyer> Yes, and where's current series picked from?
[14:19] <niemeyer> Ah, from the system
[14:19] <niemeyer> That's slightly unexpected (by me)
[14:20] <rogpeppe> niemeyer: where else could it come from?
[14:20] <niemeyer> It basically means what we get out of the agent tools is reporting the machine, not the actual running tools
[14:21] <niemeyer> Not sure which way is more useful, though
[14:22] <rogpeppe> niemeyer: they're both potentially useful
[14:22] <niemeyer> Yeah
[14:22] <rogpeppe> niemeyer: but it's hard to bake the current series into the compiled executable
[14:22] <niemeyer> rogpeppe: Well.. I'm coding a change right now to *avoid* doing it, so it shouldn't be so hard.. 8)
[14:23] <niemeyer> rogpeppe: Either way, we'd be guessing in both directions.. so we don't have to make any changes to that right now
[14:23] <niemeyer> I'll just do that one side-change as an independent CL and see how it looks
[14:24] <niemeyer> After lunch, though
[14:24] <niemeyer> biab
[14:59] <fwereade> dimitern, wallyworld, jam: is http://paste.ubuntu.com/1416964/ expected? I just updated goose...
[15:00] <dimitern> fwereade: well, that seems you're missing some openstack env vars
[15:01] <fwereade> dimitern, surely the tests should pass on a clean system?
[15:01] <dimitern> fwereade: if you don't pass -live to the tests it should not matter
[15:01] <fwereade> dimitern, I'm pretty certain my env vars should not be able to cause tests to either fail or succeed :)
[15:01] <fwereade> dimitern, I didn't, though
[15:02] <fwereade> dimitern, I concede the point re -live though :)
[15:02] <dimitern> fwereade: hmm.. well, I don't know if wallyworld is around - that are his last changes
[15:03] <fwereade> dimitern, bah, I never know whether to dive in and fix myself, or revert, or flag and move on
[15:04] <dimitern> fwereade: as a workaround until fixed, you'll need to set these to non-empty strings: OS_USERNAME, OS_PASSWORD, OS_TENANT_NAME, OS_REGION_NAME
[15:05] <dimitern> fwereade: if tests are failing I think revert is the best bet
[15:06] <fwereade> dimitern, yeah, probably sensible :)
[15:06] <fwereade> rogpeppe, TheMue: https://codereview.appspot.com/6864050 comments addressed I think
[15:08] <fwereade> (fwiw, does anyone know best practice for reversing a merge into trunk? absent better ideas I'm just going to copy the old version over the top and ask for a trivial LGTM on trust)
[15:09] <fwereade> bah, it's not the latest
[15:09] <rogpeppe> fwereade: last time i did it, i used patch with a revert diff
[15:09] <rogpeppe> reverse diff
[15:10] <rogpeppe> fwereade: LGTM  BTW
[15:10] <fwereade> rogpeppe, yeah, I'm *sure* bzr would do it for me if I knew what I were doing :)
[15:13] <TheMue> fwereade: Review is in.
[15:27] <rogpeppe> niemeyer: next stage in bottom-up API implementation: https://codereview.appspot.com/6913043
[15:28] <niemeyer> rogpeppe: Cheers
[15:39] <niemeyer> dimitern: Can you give a hand there and propose a fix to avoid the issue for the moment?
[15:40] <dimitern> niemeyer: what fix?
[15:40] <niemeyer> dimitern: One that unbreaks tests
[15:40] <dimitern> niemeyer: ok, I'll take a look
[15:40] <niemeyer> dimitern: Thanks a lot
[15:40] <fwereade> niemeyer, dimitern: I just proposed a branch with that commit straight-up reverted -- https://codereview.appspot.com/6907049
[15:41] <fwereade> niemeyer, dimitern: I'll go ahead and reject it if a fix is incoming
[15:41] <niemeyer> fwereade: I'm assuming that a trivial temporary fix for this would be under 10 lines of code.. if it seems any controversial, +1 on reverting
[15:41] <dimitern> fwereade: I have no idea what the fix should be yet, looking..
[15:41] <fwereade> rogpeppe, fwiw, `bzr diff -r-2..-3` gave me a patch that I could just apply
[15:42] <rogpeppe> fwereade: yeah, that's what i was suggesting
[15:42] <fwereade> niemeyer, gut says it's a bit of trivial test setup
[15:42] <rogpeppe> fwereade: sorry if i wasn't clear enough
[15:42] <fwereade> rogpeppe, not to worry
[15:43] <dimitern> fwereade: i cannot even compile the tests from trunk - go test -i in environs/openstack says: ../../state/open.go:72: undefined: mgo.DialWithInfo; mgo.DialInfo
[15:43] <fwereade> dimitern, if it looks like it'll be complex then maybe just give my CL a quick check and let me know if it's sane
[15:44] <fwereade> dimitern, go get -u labix.org/v2/mgo/...
[15:44] <niemeyer> dimitern: Update your mgo
[15:44] <niemeyer> What fwereade says
[15:44] <niemeyer> dimitern: How long since you last run tests, btw? :-)
[15:44] <dimitern> fwereade: ok I'll check out the CL in the mean time
[15:44] <fwereade> niemeyer, I think he's been on goose :)
[15:44] <niemeyer> Ah, that'd explain it
[15:44] <dimitern> niemeyer: a week probably - been working on goose mostly, not juju-core
[15:45] <niemeyer> fwereade: Can we do that on our side maybe, if we know what to do? Is it just a matter of putting those vars in the env?
[15:46] <fwereade> niemeyer, no idea, it probably is
[15:46] <fwereade> niemeyer, I was trying to avoid distracting myself... didn't actually manage that, though :)
[15:46] <niemeyer> fwereade: If it is, +1 on adding them next to a TODO: This is wrong as the test shouldn't have to hack the environment to work out-of-the-box. Please fix at next chance.
[15:46] <niemeyer> fwereade: LOL
[15:47] <dimitern> fwereade: the CL looks fine to me
[15:47] <fwereade> dimitern, I'll see if there's an easy fix -- we can race :)
[15:49] <dimitern> fwereade: I don't think the revert was premature - ListServers() for example in the test I have has some arguments in the provider, but not in goose, so I think it's half-baked anyway
[15:50] <fwereade> dimitern, yeah, looking at the tests I haz a bit of a confuse, it looks like it *ought* to work
[15:52] <rogpeppe> it's going to be interesting keeping goose and juju-core in sync
[15:52] <niemeyer> Slightly unfortunate but if the APIs are diverging, there's no other way
[15:52] <niemeyer> rogpeppe: Feels pretty easy
[15:53] <niemeyer> rogpeppe: We've been doing that with every other package for quite  awhile
[15:53] <rogpeppe> niemeyer: true, but the external packages weren't perhaps changing quite as fast
[15:53] <niemeyer> rogpeppe: Sure, but the idea is still the same.. merge only when both as ready to go in
[15:53] <niemeyer> s/as/are
[15:58] <niemeyer> rogpeppe: https://codereview.appspot.com/6907050
[16:04] <niemeyer> dimitern: It doesn't look like the API is broken, though?
[16:04] <niemeyer> dimitern: It seems to compile fine here
[16:04] <dimitern> niemeyer: maybe I'm not getting something right then
[16:06] <fwereade> dimitern, ah, no, it's just a broken string (and tests which appear to run twice), plus whatever the deal is with local_test which I don't really get at all
[16:06] <dimitern> fwereade: I think the local tests are supposed to use the test doubles
[16:08] <fwereade> dimitern, yeah, but none of those tests actually hit anything let alone the test double
[16:09] <dimitern> fwereade: no idea, wallyworld would know I haven't looked at them yet
[16:09] <rogpeppe> niemeyer: looking
[16:09] <fwereade> dimitern, ISTM that they're failing to construct an env and trying to get the provider from that
[16:11] <niemeyer> fwereade: I have a fix.. pushing
[16:11] <fwereade> dimitern, it looks like that's what we do in ec2, though, although I can't figure out *why*
[16:13] <dimitern> fwereade: probably it needs both tenant and region, which is not needed for ec2?
[16:13] <fwereade> dimitern, it doesn't need an env at all :/
[16:14] <fwereade> dimitern, it's creating one for absolutely no reason
[16:14] <dimitern> fwereade: I see, so it shouldn't?
[16:14] <rogpeppe> niemeyer: LGTM
[16:15] <fwereade> dimitern, AFAICT it should just be doing Provider("openstack").PrivateAddress()
[16:15] <fwereade> dimitern, PrivateAddress has to work with no credentials or it's worthless
[16:15] <niemeyer> fwereade, dimitern: https://codereview.appspot.com/6912047
[16:16] <fwereade> niemeyer, LGTM as far as it goes, but it might be nice to drop the redundant Test() func in config_test.go
[16:16] <niemeyer> fwereade: Yep, there's no point in having credentials there
[16:16] <fwereade> niemeyer, and frankly local_test.go should just be deleted
[16:17] <niemeyer> fwereade: DOing it
[16:18] <dimitern> niemeyer: LGTM
[16:19] <fwereade> niemeyer, LGTM
[16:21] <niemeyer> dimitern, fwereade: Thanks. I've sent an improvement to the comment as well, to point out that what was done there is a temporary hack to get things building, but definitely not the right thing to do.
[16:21] <dimitern> ok
[16:21] <fwereade> niemeyer, lovely, cheers
[16:26] <fwereade> niemeyer, ah, sorry, I thought you were submitting - LGTM again, I guess, but really almost all that file is useless and confusing
[16:28] <fwereade> niemeyer, hard to fault the implementer, though, it looks exactly like the ec2 version -- I think I'll propose my own on top when you've submitted
[16:31] <niemeyer> fwereade: Yes, my attempt is not to fix anything other than doing the smallest possible to help unrelated work to continue
[16:31] <fwereade> niemeyer, actually it's not quite as simple as it looks
[16:31] <fwereade> niemeyer, yeah, sensible
[16:31] <niemeyer> fwereade: What's that?
[16:32] <fwereade> niemeyer, I think the *Address tests should have their own metadataHost patching
[16:33] <fwereade> niemeyer, and I don;t think any of the other tests have any justification for doing so
[16:33] <niemeyer> fwereade: Agreed on both counts
[16:35] <fwereade> niemeyer, ok, it is pretty easy, I'll dash it off a bit later
[16:39] <rogpeppe> niemeyer: i was in the process of implementing jujud server (to serve the API) then realised that perhaps it might be good as another machine worker. what do you think?
[16:39] <rogpeppe> fwereade: ^
[16:46] <fwereade> rogpeppe, I don't *think* so
[16:47] <fwereade> rogpeppe, but would you expand?
[16:47] <rogpeppe> fwereade: i started doing it separately and then realised that it had almost everything in common
[16:47] <fwereade> rogpeppe, hum, interesting -- if you can pull it out cleanly then that would probably be a Good Thing then
[16:48] <rogpeppe> fwereade: it looks at state and does stuff to it. almost the same as any other worker.
[16:48] <rogpeppe> fwereade: the only thing i'd want to do (to make things consistent) is to remove the --ca-cert argument from jujud
[16:48] <rogpeppe> fwereade: and have it pull the file from a known file within data-dir
[16:48] <fwereade> rogpeppe, +1 to that for sure
[16:48] <rogpeppe> s/the file/the cert/
[16:49] <rogpeppe> fwereade: then the API worker can look in data-dir too to get the server cert and key
[16:50] <rogpeppe> fwereade: hmm, maybe it's crack though actually
[16:50] <rogpeppe> fwereade: they are almost identical *now*
[16:50] <fwereade> rogpeppe, I'm still a bit confused by it, it is true, but laura is shouting persistently in the other room so I am finding it tricky to concentrate
[16:51] <rogpeppe> fwereade: but in the future, the agents will need to talk to the API server, not the db
[16:51] <fwereade> rogpeppe, ah, yes, good point
[16:52] <rogpeppe> fwereade: yeah, so the upgrader loop must be different, because they're talking to two different kinds of state server.
[16:53] <rogpeppe> fwereade: i mean the state-reconnect loop
[16:53] <fwereade> rogpeppe, maybe best to keep them separate for now then
[16:53] <rogpeppe> fwereade: definitely
[16:53] <rogpeppe> fwereade: thanks for the feedback
[16:54] <fwereade> rogpeppe, it's always nice to be thanked for saying "er... dunno" :)
[16:54] <rogpeppe> fwereade: it could be worse, you might be a teddy bear
[16:56] <rogpeppe> fwereade: it will be a little weird though, 'cos i think the API server agent will need to listen to itself...
[16:56] <fwereade> rogpeppe, haha
[17:00] <rogpeppe> fwereade: the worker does need an entity name though, as it needs to store its password in state and in a directory. how about just "server" for the entity name, and having State.SetAPIServerPassword ?
[17:05] <rogpeppe> fwereade: oh bugger, that doesn't work
[17:10] <rogpeppe> anyone wanna have a look at this CL? https://codereview.appspot.com/6913043
[17:23] <fwereade> rogpeppe, niemeyer: can I get a trivial LGTM on https://codereview.appspot.com/6907051 please? I ran all the tests :)
[17:23] <niemeyer> fwereade: Looking
[17:23] <niemeyer> fwereade: That seems rather controversial
[17:23] <fwereade> niemeyer, :p
[17:23] <niemeyer> fwereade: LGTM :-)
[17:24] <fwereade> niemeyer, cheers
[17:24] <rogpeppe> fwereade: how did that compile before?
[17:24] <fwereade> rogpeppe, it didn't, niemeyer owes us cookies :p
[17:24] <niemeyer> rogpeppe: Probably didn't.. the guy was incompetent
[17:24] <niemeyer> :-)
[17:24] <rogpeppe> ha ha
[17:25] <fwereade> rogpeppe, niemeyer: the trouble is I didn't spot it when I did the full test run for my previous submit
[17:25] <rogpeppe> niemeyer: that probably cancels out a few cookies i owe you :-)
[17:25] <niemeyer> rogpeppe: I'm not sure.. I should write down a footnote about the effects of the rule on build fixes
[17:25]  * niemeyer laughs in an evil way
[17:26] <niemeyer> Reminds of that game where we make up rules as we go
[17:26] <niemeyer> We should play that at some point
[17:26] <fwereade> rogpeppe, niemeyer, I don't suppose there's a way to get go test to put the bad output, that I care about, at the end where I see it more obviously?
[17:26] <niemeyer> fwereade: Can I get a second review on this easy one: https://codereview.appspot.com/6907050
[17:27] <fwereade> niemeyer, looking
[17:27] <niemeyer> fwereade: Hmm.. not that I know of
[17:27] <fwereade> niemeyer, just a NO YUO or something, that's all I ask :)
[17:29] <niemeyer> That's the game, btw: http://en.wikipedia.org/wiki/Mao_(card_game)
[17:29] <fwereade> niemeyer, can you briefly explain the context? code looks good but I don't quite understand what it helps us do
[17:29] <niemeyer> fwereade: It's a pre-req of..
[17:29] <niemeyer> fwereade: https://codereview.appspot.com/6868070/
[17:30] <fwereade> niemeyer, ah, ok
[17:31] <fwereade> niemeyer, LGTM
[17:33] <niemeyer> fwereade: Cheers
[17:34] <fwereade> I think I'm done for the day
[17:34] <fwereade> dimitern, I think we're all going down to get ribs at la rive, join us if you fancy it, they're pretty good :)
[17:35] <dimitern> fwereade: cool, when?
[17:35] <fwereade> dimitern, imminently :)
[17:35] <dimitern> fwereade: :) be there in 20m
[17:35] <fwereade> sweet, see you shortly then :)
[17:35] <fwereade> happy weekends everyone
[17:36] <dimitern> from me too :) happy weekend!
[17:38] <fwereade> niemeyer, (don't quite know how I failed to get to the deployer rework today :( -- it'll be there soon though :))
[17:39] <niemeyer> fwereade: All good
[17:52] <niemeyer> fwereade, rogpeppe: I'll be off on Monday, btw, in exchange for the 28th that I missed.. Back Tuesday and on
[17:53] <rogpeppe> fwereade: have a good one!
[17:53] <rogpeppe> niemeyer: ok, have a great weekend
[17:54] <niemeyer> fwereade, rogpeppe: A great weekend to all as well
[17:57] <niemeyer> rogpeppe: api-server LGTM
[17:57] <rogpeppe> niemeyer: cool, thanks
[17:57] <rogpeppe> niemeyer: next up is adding a conventional Stop method, then adding a jujud server command.
[17:58] <niemeyer> rogpeppe: Sweet, sounds sensible
[17:59] <rogpeppe> niemeyer: i'm wondering how we should manage the api server's state password
[18:00] <rogpeppe> niemeyer: it probably needs its own entity management stuff in state, which i'm not too keen on doing, as it seems a lot of work for not much gain
[18:01] <rogpeppe> niemeyer: i've been toying with the idea of making the state server part of the machine agent
[18:01] <niemeyer> rogpeppe: How do you mean
[18:01] <niemeyer> ?
[18:01] <rogpeppe> niemeyer: it can't *quite* be "just another worker" but maybe not far off
[18:01] <niemeyer> rogpeppe: Soryr, let me be more specific
[18:02] <niemeyer> rogpeppe: Why state password would the API server need?
[18:02] <niemeyer> s/Why/what
[18:02] <rogpeppe> niemeyer: i think we probably want to keep mongodb password access
[18:03] <rogpeppe> niemeyer: even after the API server is done
[18:03] <niemeyer> rogpeppe: I see
[18:03] <niemeyer> rogpeppe: The API server is a bit of an interesting case
[18:03] <rogpeppe> niemeyer: and so we still need to go through the same initial password dance that we do now
[18:04] <rogpeppe> niemeyer: yeah, it is. but it's perhaps not as special as we might initially think.
[18:04] <niemeyer> rogpeppe: It can be, depending which way we go
[18:04] <rogpeppe> niemeyer: yea
[18:04] <niemeyer> rogpeppe: We could opt to use a unix socket, for example
[18:04] <rogpeppe> h
[18:04] <niemeyer> Which isn't supported by mgo right now
[18:05] <niemeyer> rogpeppe: I'm not sure about how much that'd make things easier/nicer, though
[18:05] <rogpeppe> niemeyer: i don't think that works so well, as i think we want to be able to have a state server fan out to several mongos, perhaps
[18:05] <rogpeppe> niemeyer: and the state server might implement some caching, so it might make sense to have more state servers than mongods
[18:06] <niemeyer> rogpeppe: Yeah, that's an interesting schema to keep in the sleeve, even if we don't do it right away
[18:07] <rogpeppe> niemeyer: i'm thinking that in fact, if we choose it to be, the state server is actually very similar to a normal worker.
[18:07] <rogpeppe> niemeyer: except that, eventually, it will act on the mongo state rather than the api state
[18:07] <niemeyer> rogpeppe: Agreed
[18:08] <niemeyer> rogpeppe: Sounds like a good way to put it
[18:08] <rogpeppe> niemeyer: and thinking that way, perhaps it makes sense to make it just another worker in the machine agent's arsenal.
[18:08] <niemeyer> rogpeppe: Yep
[18:09] <rogpeppe> niemeyer: there will be an interesting little dance for machine agents that also happen to be api servers, but i *think* it's possible
[18:10] <rogpeppe> niemeyer: the upgrade logic will want to talk to the api that's being served by the same machine agent, for example, but that will probably work ok.
[18:15] <niemeyer> rogpeppe: Yeah, it might work alright
[18:25] <rogpeppe> right, time for me to go too
[18:25] <rogpeppe> night all! have great weekending.


[10:00] <acagastya> Hello, can anyone help me? I can't obtain fingerprint for OpenPGP.
[10:02] <cjwatson> Can you be more specific about what you're trying to do and what you've tried so far?
[10:08] <acagastya> I need to sign the Ubuntu Code of Conduct on Launchpad.
[10:09] <acagastya> I am struck at the first step, where we are supposed to Change OpenPGP keys.
[10:09] <Mc> https://help.ubuntu.com/community/SigningCodeofConduct ?
[10:09] <Mc> ( https://help.ubuntu.com/community/GnuPrivacyGuardHowto#Signing_Data more precisely )
[10:11] <cjwatson> Exactly which sequence of steps are you following at the moment?  Presumably you're going from a web page somewhere.
[10:11] <acagastya> I can't get the fingerprint (https://launchpad.net/%7Eacagastya/+editpgpkeys).
[10:12] <acagastya> I use Elementary OS, so I can't retrieve the key in the key from System > Preferences > Passwords and Encryption Keys.
[10:12] <cjwatson> What have you done so far?  Have you generated a key, for instance?
[10:13] <acagastya> You mean the fingerprint, no.
[10:13] <cjwatson> I mean what I said.
[10:13] <Mc> have you generated the keypair itself ?
[10:14] <acagastya> No, I don't know how to.
[10:14] <Mc> you might want to read https://help.ubuntu.com/community/GnuPrivacyGuardHowto
[10:14] <cjwatson> or https://help.launchpad.net/YourAccount/ImportingYourPGPKey#Using_GPG_to_manage_OpenPGP_keys
[16:43] <om26er> Hi! my debian/rules have a `export DEB_BUILD_OPTIONS='<something>' entry, when I upload that package to my ppa, apparently that var is not being read. is launchpad eating that variable ?
[16:44] <cjwatson> Launchpad doesn't control anything at a level that could eat that.
[16:45] <cjwatson> However, you're probably doing it wrong anyway.  DEB_BUILD_OPTIONS is supposed to be something that debian/rules may check, but not something that it should set itself.
[16:46] <cjwatson> Anything you could do by setting DEB_BUILD_OPTIONS you should probably just be doing more directly.
[16:48] <om26er> cjwatson: there are multiple ifeq blocks that are controlled by DEB_BUILD_OPTIONS - -doing something around that is doable but could break if upstream changes anything.
[16:48] <om26er> so if we can't export DEB_BUILD_OPTIONS from within rules file, then I guess I have to go that way
[16:48] <cjwatson> You should still be able to; it's just wrong.
[16:49] <cjwatson> Can't you reproduce this in sbuild?
[16:49] <cjwatson> It should be no different for this purpose.
[16:51] <cjwatson> om26er: export DEB_BUILD_OPTIONS:="$DEB_BUILD_OPTIONS nocheck testkeys" doesn't seem like correct make syntax
[16:51] <cjwatson> I think perhaps you're confusing make variable syntax with shell variable syntax
[16:52] <cjwatson> So the variable isn't going to include testkeys as a separate word, because it'll actually have the " at the end
[16:52] <om26er> cjwatson: I also tried without appending i.e export DEB_BUILD_OPTIONS="nocheck testkeys"
[16:52] <cjwatson> om26er: correct syntax would be: DEB_BUILD_OPTIONS += nocheck testkeys
[16:52] <om26er> oh
[16:52] <cjwatson> you can export if you like but it's not necessary
[16:53] <om26er> and that would be 6hours
[16:53] <cjwatson> (since it's only checked within this file)
[16:53] <cjwatson> A good strategy for debugging this kind of thing is to use make's $(warning) function
[16:59] <om26er> cjwatson: prepended by export ?
[17:00] <om26er> re: correct syntax
[17:02] <om26er> figured.
[17:02] <cjwatson> export> doesn't matter unless it's used outside this file
[17:02] <om26er> thanks cjwatson, seems its finally working.
[17:02] <cjwatson> or rather, in a child process
[20:04] <acagastya-afk> I am getting an error while uploading Ubuntu Code of Conduct.
[20:05] <wxl> acagastya-afk: which error is that?


[00:02] <cjalmeida> poolie, I tried the 2.5b2 from ppa and same issue. I'll try to check mtu. BTW, nautilus ssh connection also stopped working. however, dolphin and large scp transfers are OK.
[00:02] <cjalmeida> weird...
[00:03] <poolie> uh
[00:03] <poolie> maybe you turned on ssh connection auto-master?
[00:03] <poolie> try turning that off
[00:04] <cjalmeida> presto! it was mtu.
[00:04] <cjalmeida> set it to 576 and everthing worked
[00:05] <cjalmeida> I had a hunch about it when firefox started dropping conns, but set it to 1400, still too large
[00:06] <cjalmeida> even nautilus is working fine now
[00:06] <cjalmeida> poolie, I'll see if i can find a good mtu. Canonical should put a post connect test to determine best value.
[00:08] <poolie> what, in network-manager or something?
[00:08] <poolie> hm
[00:08] <poolie> path mtu discovery does already exist
[00:08] <poolie> i don't recall why it doesn't work in some cases
[00:30] <cjalmeida> poolie, for some reason, my /proc/sys/net/ipv4/tcp_mtu_probing was set to 0.
[00:34] <poolie> mine too
[00:41] <poolie> perhaps there is some tradeoff about having it on
[01:30] <fullermd> Path MTU discover _does_ require that you not have any networks in the path run by flaming idiots who think "Oh, hey, let's block all ICMP; that way we're more secure!"
[01:31] <bob2> yes
[01:31] <bob2> alack
[01:32] <fullermd> (I dunno if that's less of a problem now than it was a decade ago.  My cynical side says 'no'...)
[01:32] <bob2> there are still people who think icmp is how teh hackers get in, but they mostly seem to be sysadmins rather than netadmins
[01:32] <fullermd> Luckily, I'm buoyed up by my native optimism and happy outlook.
[01:46] <poolie> i wonder if it might not be possible to do some kind of heuristic detection
[02:00] <lifeless> fullermd: PTMUd can handle blackholes... just faster without them
[02:02] <lifeless> cjalmeida: poolie: that sysctl is for RFC 4821 checking, which is new (2007) vs RFC 1191 checking, which is what most folk expect/need
[02:02] <lifeless> cjalmeida: poolie: http://kb.pert.geant.net/PERTKB/PathMTU covers both
[02:03] <lifeless> I speculate it is disabled due to newness; pehraps we should default it on
[02:04] <lifeless> fullermd: 4821 doesn't need ICMP according to that wiki page
[02:07] <poolie> lifeless, yes i thought perhaps there was another one
[02:10] <fullermd> Ah.
[02:18] <cjalmeida> poolie, lifeless, fullermd the tcp_mtu_probing setting to 1 seems to have fixed mos issues.
[03:16] <cjalmeida> #openerp
[03:30] <lifeless> poolie: btw - http://www.erlang.org/doc/man/dialyzer.html
[03:30] <poolie> thanks
[05:00] <BlindWolf8> Hey all. I have a Bazaar server where clients use ssh_path_limiter to access a repo. Am I able to pass multiple paths in my authorized_keys file?
[05:00] <BlindWolf8> I want to do this so a single person doesn't need to generate a key per project
[05:00] <BlindWolf8> I am using Shared repos
[05:23] <BlindWolf8> Anyone?
[05:58] <lifeless> BlindWolf8: just put all the repos under a common root
[05:58] <lifeless> /srv/repos/A /srv/repos/B and make /srv/repos the permitted path
[05:59] <BlindWolf8> but then clients would need to change their paths, right?
[05:59] <BlindWolf8> for bound branches?
[05:59] <lifeless> uhm, yes
[06:00] <BlindWolf8> i figured
[06:00] <BlindWolf8> right now it's bzr+ssh://<user>@<ip>:<port>/.bzr/branches/trunk/
[07:06] <vila> hi all
[07:07]  * fullermd wavels.
[07:07] <vila> poolie: 'Requests' looks very good indeed, dependencies may be an issue there though
[07:08] <vila> poolie: in short, too late for 2.5, worth considering for 2.6
[07:10] <poolie> hi
[07:10] <poolie> yeah
[07:49] <jelmer> 'morning
[07:55] <mgz> morning all!
[07:58] <jelmer> hey mgz
[08:01] <jelmer> are we hanging out?
[08:02] <mgz> I need to head downstairs if so
[08:03] <jelmer> mgz: are you up for that journey?
[08:03] <mgz> if that's where we'll all be :)
[08:05] <jelmer> vila, poolie: ^
[08:05] <vila> morning guys !
[08:05] <vila> oh, right !
[08:06] <poolie> hi jelmer, mgz,
[08:06] <poolie> yes let's try it
[08:14] <wgz> hm, where is the thingy?
[08:14] <jelmer> wgz: it's on http://plus.google.com/
[08:15]  * wgz reloads
[08:15] <jelmer> wgz: the top item should be an invite from poolie for the hangout
[08:16] <vila> can't see it
[08:17] <jelmer> mgz: no can hear you
[08:17] <jelmer> vila: hmm, that's odd.. should be the first item in the stream
[08:21] <vila> poolie is the first in the stream but I can't see any ref to an ongoing hangout :-(
[08:26] <jelmer> vila: there should be a join button
[08:26] <vila> yeah, that's what I remember but there is none
[08:27] <vila> ha !
[08:39] <tvoss> Hi all
[08:40] <tvoss> I'm trying to setup a packaging recipe and hitting a problem with bzr-builder
[08:40] <tvoss> apparently missing a launchpad id
[08:43] <tvoss> build log is here: https://launchpadlibrarian.net/90240218/buildlog.txt.gz
[08:50] <jelmer> tvoss: for now, please use the 0.3 version of recipes
[08:53] <tvoss> jelmer, thx, adjusted my recipe and requested a build
[09:07] <mgz> okay. enough fun
[09:13] <vila> mgz: regarding the seg fault, here is the only trace I found in kernel.log: http://paste.ubuntu.com/807177/
[09:16] <mgz> not very informative indeed
[09:17] <vila> yeah, if I wasn't searching for it I've probably missed it
[09:18] <vila> I had probably ?
[09:25] <tvoss> jelmer, 0.3 version of the recipes work fine
[09:51] <vila> jelmer: colocated-names reviewed, mostly questions for now but the change looks ok, I need answers to understand the impact but it seems low risk  enough to be ok
[09:54] <jelmer> vila: thanks
[10:04] <jelmer> vila: replied
[10:04] <vila> jelmer: already reading and replying ;)
[10:04] <vila> one question
[10:04] <jelmer> vila: thanks for the quick followups :)
[10:04] <vila> self.name = name in __init__ makes it an instance variable right ?
[10:05] <vila> BzrBranch.__init__ that is
[10:05] <vila> and great answer by the way, I smelled a bug but couldn't put my finger on it
[10:06] <jelmer> vila: ah, sorry
[10:06] <jelmer> vila: I missed that that code was in Branch, I was only reading the diff
[10:06] <jelmer> yeah, I can see why documenting it as an instance variable makes sense
[10:07] <vila> unless the line should be deleted, I see no use of it from a quick grep...
[10:07] <jelmer> vila: which line, assigning to self.name ?
[10:08] <vila> yeah
[10:09] <vila> well, annotations say you added it so you should know ;)
[10:09] <vila> damn, there *is* doc for it
[10:09] <vila> sry
[10:10] <vila> why did I miss it in the first place....
[10:10] <jelmer> vila: it is meant to be used by things that need to display colocated branch names
[10:11] <vila> fine
[10:12] <vila> jelmer: approved, but watch for lp:bzr/2.5 as a target
[10:12] <jelmer> vila: thanks
[10:12] <jelmer> vila: I guess I should probably resubmit against 2.5?
[10:13] <vila> jelmer: depends on how you submit to pqm, don't wait for another review if you resubmit on lp though ;)
[10:13] <jelmer> vila: resubmitting against 2.5, would you mind re-reviewing?
[10:13] <jelmer> *resubmitted
[10:14] <vila> I don't mind but I just said you didn't need it ;)
[10:15] <jelmer> well, that way we have the review record right.. I don't like reviewing my own stuff :)
[10:19] <vila> jelmer: done, one last time: check news entry ;)
[10:23] <jelmer> vila: huh, wha ? :-P
[10:23]  * jelmer RUNS
[10:23] <vila> I knew, trap activated as planned
[10:36] <vila> jelmer: jokes aside, if you still encounter news merge issues on pqm, let me know ;)
[10:38] <jelmer> vila: will do
[11:35] <zyga> hi
[11:35] <zyga> is the author of lp:bzr-interactive around?
[15:11] <mgz> oo larstiq magic
[15:12] <LarstiQ> mgz: oh oh, I hoped it wasn't too magical :)
[15:17] <mgz> approved, but you probably want to do some shuffling to get it on 2.5 which branched yesterday
[15:18] <mgz> may just be able to branch lp:bzr/2.5, merge your change into that (and --fixes) then add news and repropose
[15:19]  * LarstiQ looks for a corresponding bug
[15:19] <mgz> bug 881142
[15:20] <mgz> really good job tracking that down, gets us down to a sensible number of failures on pypy I take it?
[15:20] <LarstiQ> mgz: not entirely sure
[15:20] <mgz> I'll do a run later this evening and report back.
[15:21] <LarstiQ> mgz: while running test_http.TestBadStatusServer.test_http_get bzr hangs for a long time and then: zsh: alarm      ../pypy-1.7/bin/pypy ./bzr selftest
[15:22] <LarstiQ> reading around that can happen when a signal handler isn't properly set when the signal arrives
[15:22] <LarstiQ> but looking at the code I couldn't figure it out
[15:22] <jelmer> LarstiQ: we register an alarm handler to kill hanging tests
[15:22]  * LarstiQ nods
[15:22] <LarstiQ> jelmer: "something" goes wrong there :)
[15:23] <jelmer> LarstiQ: so most likely this is a hanging test, rather than anything to do with the signal handler
[15:24] <LarstiQ> jelmer: my understanding is that the signal handler doesn't run and it passes down to zsh
[15:24]  * LarstiQ might be wrong
[15:25] <jelmer> LarstiQ: I don't think we register a signal handler at all, (intentionally?)
[15:25] <LarstiQ> jelmer: possibly, I didn't quite follow the code. One _exists_ at least.
[15:25] <LarstiQ> vila might know more
[15:25] <jelmer> LarstIQ: At least, if I have hanging tests on cpython it dies the same way
[15:26] <LarstiQ> jelmer: ah ok
[15:26] <jelmer> so it might be that the signal handler isn't being called, but at least it's consistent across the various python implementations :)
[15:26] <vila> LarstiQ: hey !
[15:27] <LarstiQ> vila: heya :)
[15:28] <vila> AFAIK, we don't use signals in tests *expect* SIGALRM to kill hanging tests (based on selftests.timeout defaulting to... 60s I think)
[15:28] <vila> except not expect
[15:29] <LarstiQ> vila: who is supposed to handle that signal, bzr or the shell?
[15:30] <vila> err... dunno :)
[15:31] <mgz> see <https://code.launchpad.net/~mbp/bzr/test-timeout/+merge/83559>
[15:31] <vila> I think we just arm a timer
[15:32] <vila> so yeah, we never try to catch it
[15:32] <LarstiQ> ok, so then the only question is why it times out
[15:34] <vila> LarstiQ: you run with -v ?
[15:34] <vila> LarstiQ: said otherwise: are you sure the hanging tests is TestBadStatusServer ?
[15:35] <mgz> it tracking it down to one test that hangs (semi) reliably would be a good start
[15:35] <LarstiQ> vila: good point
[15:35]  * LarstiQ tries a run with just that test
[15:36] <mgz> can set that conf value to less than 60 for less patient alarm timeout while trying test subsets
[15:36] <vila> ... or to more than 60 if you need to debug ;)
[15:37] <mgz> that's true, breaking in poking thread states can be useful
[15:37] <mgz> +and
[15:38] <LarstiQ> after which point would the alarm kick in? It's not giving any progress info (while with -v) for more than a minute already
[15:38] <mgz> it should just be 60s after test start
[15:38] <mgz> otherwise try ctrl+\ and see where you land
[15:44] <LarstiQ> http://paste.debian.net/152579/
[15:48] <mgz> TestBadStatusServer.test_http_has it is.
[15:48] <LarstiQ> the following completes in 21 seconds: ../pypy-1.7/bin/pypy ./bzr selftest -v -s bt.test_http -x test_http.TestBadStatusServer.test_http_has -x test_http.TestBadStatusServer.test_http_get -x test_http.TestPost.test_post_body_is_received -x test_http.TestRecordingServer.test_send_receive_bytes
[15:49] <vila> ./bzr selftest -s bt.test_http.TestBadStatus -v would be simpler to start with
[15:50]  * LarstiQ has to run now
[15:50] <LarstiQ> I'll be back tomorrow
[15:50] <mgz> thanks LarstiQ!
[15:50] <vila> k
[15:51] <vila> thanks for digging  !
[15:51] <LarstiQ> mgz: then I'll also have some questions about proper NEWS entry writing
[15:51]  * LarstiQ off
[15:55] <mgz> actually, could just merge to 2.5 and add news for LarstiQ, will do that later unless pp gets there first
[15:56] <vila> LarstiQ: in case your read the log, I suspect you're re-trying a request that failed, we want the first failure as the server is not supposed to receive more than one request which is probably why it's hanging
[15:56] <vila> mgz: I'll do
[16:05] <vila> mgz: I did
[16:25] <mgz> vila: ta!
[18:58] <mgz> ha, okay, fixed eucatools proxying signature checking
[19:00] <mgz> ...and that was the wrong channel this time.
[19:01] <jelmer> mgz!
[19:42] <BlindWolf8> Hello. Is bzr_path_limiter able to traverse soft links? I'm getting a "not a repo" error
[19:44] <BlindWolf8> Actually, it's "No repository present"
[19:53] <BlindWolf8> Is it because I'm pointing it towards a branch and not a repo?
[19:54] <jelmer> BlindWolf8: yeah, it won't be able to browse down towards the repo in that case
[20:02] <BlindWolf8> Is tehre a way to remove the ugly "/.bzr/branches/trunk/" from URLs without making symlinks or is that just the way it's going to be?
[20:03] <jelmer> BlindWolf8: huh, why would you need symlinks to that?
[20:06] <BlindWolf8> Just was trying to make my URLs for team members easier to pop in/look less ugly, but Iif they have to look like bzr+ssh://<user>@<ip>:<port>/<project_name>/.bzr/branches/trunk/ then that's the way it's going to be
[20:08] <beuno> so, couldn't you register a shortcut like lp: has?
[20:08] <BlindWolf8> the project isn't on lp
[20:09] <beuno> no, I mean "lp:" is probably registered in the launchpad plugin
[20:09] <beuno> maybe you could have a plugin to register "something:"
[20:09] <jelmer> BlindWolf8: why not just bzr+ssh://<user>@<ip>:<port>/<project_name>/trunk ?
[20:10] <mgedmin> there's a bookmarks plugin, iirc
[20:10] <mgedmin> http://doc.bazaar.canonical.com/plugins/en/bookmarks-plugin.html
[20:10] <BlindWolf8> I don't think bzr+ssh://<user>@<ip>:<port>/<project_name>/trunk works. That would be the ideal solution, I think
[20:11] <BlindWolf8> I'm using colocated branches...the project only really needs a trunk
[20:11] <jelmer> BlindWolf8: ah
[20:11] <jelmer> BlindWolf8: so this is very specific to bzr-colo
[20:11] <BlindWolf8> I'm not using that plugin
[20:12] <BlindWolf8> at least on the server
[20:12] <BlindWolf8> I think the Windows installer version of bzr comes with that though
[20:13] <jelmer> BlindWolf8: you should be able to just push to your desired location of bzr+ssh://<user>@<ip>:<port>/<project_name>/trunk
[20:16] <BlindWolf8> want me to try and report back?
[20:18] <BlindWolf8> Fails with "not a branch" error
[20:18] <glyph> I notice that there's no 'qmissing' in bzr
[20:18] <glyph> erm qbzr
[20:18] <glyph> is there a thing that's similar?
[20:18] <jelmer> BlindWolf8: when you're pushing?
[20:20] <BlindWolf8> when I'm pulling
[20:20] <jelmer> BlindWolf8: you'd have to push to that location first (and ditch the .bzr/branches/ bit from bzr-colo)
[20:21] <BlindWolf8> why? would that create it on the server?
[20:22] <BlindWolf8> just an FYI: everyone's using colo'd bound branches...no checkouts or master branch
[20:22] <jelmer> BlindWolf8: yes, that should create it on the server
[20:22] <BlindWolf8> just a single branch, nothing fancy
[20:22] <jelmer> BlindWolf8: you're complaining about colocated branches on the server
[20:23] <BlindWolf8> server doesn't have any fiels on it...every else has those files though
[20:23] <BlindWolf8> only dir on the server is the .bzr dir
[20:23] <jelmer> BlindWolf8: right, that's fine - the server just has to have the branch, not the working tree
[20:24] <BlindWolf8> but isn't the branch technically in the .bzr dir already...?
[20:24] <jelmer> BlindWolf8: it is, but it lives in a special location which is a bit of a hack used by bzr-colo
[20:24] <jelmer> BlindWolf8: that's why you have to specify /.bzr/branches/foo rather than just /foo
[20:25] <BlindWolf8> I'm assuming it's going to be awhile until that's fixed :-)
[20:25] <jelmer> BlindWolf8: bzr 2.5 will have proper colocated branch support, different from bzr-colo
[20:26] <BlindWolf8> what's the ETA on that?
[20:26] <jelmer> BlindWolf8: 2.5.0 is due out in a month I think
[20:26] <BlindWolf8> what's the upgrade path for old repos with the old colo format?
[20:27] <jelmer> BlindWolf8: no idea; I think Neil (the author of bzr-colo) had some ideas but I've only been involved with the colo support in the core
[20:28] <BlindWolf8> gotcha...the new version sounds like it's even more friendly
[20:30] <BlindWolf8> just thought about my folder layout and I think I'm goign to need to make symlinks on a per user basis for security reasosns
[20:30] <BlindWolf8> so epeople can't get into other projects
[20:30] <BlindWolf8> since I can only pass one directory with ssh_path_limiter
[20:31]  * jelmer has to head out, sorry
[20:32] <jelmer> back later tonight
[20:32] <BlindWolf8> see ya! thanks!
[22:17] <poolie> hi all
[23:10] <GRiD> hi poolie, how's it going
[23:54] <poolie> hi grid, pretty good, how are you?


[00:41] <wxl> i've long looked for the "status of openbox" notice and finally found it https://icculus.org/pipermail/openbox/2017-December/009329.html
[00:42] <wxl> needless to say openbox isn't *dead* (see changes since 2015 http://git.openbox.org/?p=mikachu/openbox.git;a=shortlog;h=refs/heads/wip/mikabox) but there's not much doing
[01:01] <kc2bez> still breathing but we lost the pulse.
 @The_LoudSpeaker [Once we had at Saturday 8am US Central na? That was best time for me. Wxl Think …], I'll be up tomorrow at 8:30ish CT so if you want to bounce some stuff off of me, ping me then
[04:56] <The_LoudSpeaker> @tsimonq2: day after tomorrow. Tomorrow last exam.
 Okay
[10:09] <goomohn> is there a date set for 20.04 stable release?
[10:17] <goomohn> a: 23apr is the set date
 anyone has experience running test for GUI with debuild? Tests works fine when I run pybuild —test but with debuild with the correct override it doesn't
 https://paste.ubuntu.com/p/tkJhpkKq7X/ vs https://paste.ubuntu.com/p/vty9h8yd68/
 test didn't work becasue of qt.qpa.xcb: could not connect to display  … qt.qpa.plugin: Could not load the Qt platform plugin "xcb" in "" even though it was found.
 wxl tsimonq2 ^
 anyone?


[10:33] <tosaraja> Should PXE booting with vlan tag work? Anything I should know? I managed to get one host doing it, but the second one boots to grub only
[12:57] <tosaraja> I commented here what my problem is: https://discourse.maas.io/t/pxe-boot-over-trunk-port-at-the-switch/538/10
[12:57] <tosaraja> seemed to be a semi-known case
[15:53] <mup> Bug #1866234 changed: [Feature] Remote rackd <MAAS:Invalid> <https://launchpad.net/bugs/1866234>


[06:45] <dax> !zesty =~ s/Ubuntu -.*$/Ubuntu. Support ended on January 13th, 2017. See !eol and !eolupgrade/
[06:45] <dax> (no, an email didn't get sent about it yet today)
[06:46] <Flannel> s/ed/s/ :P
[06:47] <dax> i'm assuming they failed at email because Saturday
[06:47] <dax> if not, i'll be right in the near future so oh well
[06:48] <dax> they didn't fix the download site for 17.10 yet, even though new downloads for that have been available since Thursday
[06:48] <Flannel> Now you're thinking fourth dimensionally!
[06:48] <dax> (granted, the "send email about things dying" and "fix the website" people are entirely different)
[20:07] <jelly> hi, why is <uBOTu|packages> Titre: Index of /debian/ (chez mirrors.kernel.org)  # in #debian ?
[20:08] <jelly> the name vaguely suggests it might be an official bot
[20:09] <jelly> I'm going to ban it from #debian for the time being; if there's a reason, send me a Memo or /msg or poke me in #debian-ops
[20:12] <krytarik> niko: Is that yours?
[20:13] <jelly> well it sounds french so that's as good a guess as any :-)
[21:11]  * jelly waves