[02:58] <abuDawud> Can someone set https://bugs.launchpad.net/ubuntu/+source/apport-symptoms/+bug/678371 back to triaged?
[02:58] <ubot2> Launchpad bug 678371 in apport-symptoms (Ubuntu) "apport-gtk speaker test message refers to "Close" button as "OK" (affects: 1) (heat: 8)" [Low,In progress]
[04:04] <paultag> done abuDawud
[04:07] <abuDawud> paultag, thanks
[04:08] <paultag> no problem.
[09:02] <bullgard4> When told to hibernate, my Maverick computer reaches sometimes a hung state "s2disk: Snapshotting system." What program package should I direct to an error report in Launchpad?
[09:05] <micahg> bullgard4: well, s2disk is in uswsusp, but idk if that's the issue
[09:08] <bullgard4> micahg: Thank you.
[13:36] <mortal> when will the msn fix be committed?
[13:36] <mortal> to maverick
[13:37] <nisshh> mortal, depends on the status of the bug
[13:37] <Pici> mortal: They're already in maverick-proposed.
[13:38] <nisshh> there you go, answered for me :)
[13:38] <mortal> good good
[13:39] <mortal> but will the upgrade be automagical for the certificate error
[13:39] <mortal> so that apt-get dist-upgrade will fix it
[13:39] <mortal> how fast will it move from maverick-proposed to maverick reposities
[13:39] <Pici> Looks like it: Changelog entry is as follows: * debian/patches/workaround-msn-ssl-failure.patch: Workaround SSL connectivity issues with MSN (LP: #676972)
[13:50] <yofel> mortal: afaik it has to be at least a week in proposed to test for regressions, and it needs the verification-done tag
[13:52] <yofel> actually, the package was pushed to -updates a few hours already for some reason
[13:52] <mortal> good
[13:52] <mortal> yofel: my gf uses msn, that's the reason it is a high priority
[13:53] <yofel> well, apt-cache policy shows it's in updates too so try to update, should be there
[13:53] <yofel> (if your mirror is reasonbly in sync)
[14:01] <vish> mortal: well, you can just install it from -proposed right now.. and no waiting involved.. ;)
[14:50] <bcurtiswx> bdmurray, firefox4.0b7 isn't compatible with lp-improvements.  will this me fixed soon?
[14:52] <bdmurray> bcurtiswx: I can quickly prepare a test package
[14:52] <bdmurray> bcurtiswx: however, if something is really broken ...
[14:52] <bcurtiswx> bdmurray, i can test and verify for ya.  if you have time
[14:54] <yofel> ping me too, I'm missing it :/
[14:59] <vish> bcurtiswx: i was looking for the same thing today!! :) yofel's bug #677622
[15:00] <ubot2> Launchpad bug 677622 in launchpad-gm-scripts "please update for firefox 4 (affects: 1) (heat: 6)" [Undecided,New] https://launchpad.net/bugs/677622
[15:00] <bcurtiswx> vish, well with bdmurray's package we'll be able to close that bug :) hopefully
[16:07] <bdmurray> mvo: Do you have a moment?
[16:09] <bdmurray> I suspect bugs 615109 and 615100 are related
[16:09] <ubot2> Launchpad bug 615109 in dpkg (Ubuntu) "update-alternatives crashed with SIGSEGV in __libc_start_main() (affects: 13) (dups: 12) (heat: 108)" [Medium,Confirmed] https://launchpad.net/bugs/615109
[16:09] <ubot2> Launchpad bug 615100 in dpkg (Ubuntu) "update-alternatives crashed with SIGSEGV in __libc_start_main() (affects: 20) (dups: 21) (heat: 168)" [Medium,Confirmed] https://launchpad.net/bugs/615100
[16:18] <mvo> bdmurray: indeed, they look very similar
[16:20] <mvo> bdmurray: looks like ghostscript is a candidate that might cause it
[16:20] <bdmurray> mvo: how did you determine that?
[16:21] <mvo> I need to look closer, but the details of the trace show " current_choice = 0x9609a38 "/usr/bin/ps2pdf14"" for three of the backtraces I looked at
[16:21] <bdmurray> oh, I see ;-)
[16:21] <bdmurray> mvo: it shows it for all of them - I did the duplication
[16:21]  * mvo tries to reproduce in some way
[16:21] <mvo> nice :)
[16:22] <bdmurray> mvo: well I'd think apport would have caught some of them
[16:22] <mvo> indeed
[16:22] <mvo> they look very similar, maybe they are too short or something?
[16:25] <bdmurray> bcurtiswx, yofel: http://people.canonical.com/~brian/tmp/firefox-lp-improvements_0.99.2-0ubuntu1~ppa1_all.deb
[16:29] <yofel> now firefox doesn't even list the extension as installed
[16:36] <mvo> bdmurray: I'm pretty confident that the crash is already fixed, I added the releveant changelog
[16:36] <mvo> bdmurray: and it appears like all the reports are from august
[16:37] <bdmurray> mvo: and it was fixed in ghostscript? I think there are some more duplicates in dpkg
[16:37] <mvo> bdmurray: fixed in dpkg itself, but I think ghostscript was just what triggered it
[16:38] <bdmurray> mvo: okay, thanks for looking
[16:38] <mvo> bdmurray: thanks for raising it
[16:38] <bdmurray> mvo: that's the easy part ;-)
[16:40] <mvo> heh :)
[16:41] <yofel> bdmurray: you somehow got quotes into the extension path, works fine without them /usr/share/mozilla/extensions/"{ec8030f7-c20a-464f-9b0e-13a3a9e97384}"/"{ec8030f7-c20a-464f-9b0e-13a3a9e97384}"
[16:42] <bdmurray> yofel: hunh, that's weird
[17:36] <bdmurray> mvo: have you seen bug 678196?
[17:36] <ubot2> Launchpad bug 678196 in apt (Ubuntu Natty) (and 1 other project) "Ubuntu extras repository prevents other updates (affects: 5) (heat: 28)" [High,Triaged] https://launchpad.net/bugs/678196
[22:17] <BUGabundo> o/


[04:16] <jam> morning all
[04:25] <Dmitrii-Sh> moring jam
[04:26] <Dmitrii-Sh> morning*
[07:24] <t0mb0> are there any examples for testing operator charms?
[07:32] <Dmitrii-Sh> t0mb0: we have PRs for interfaces with unit tests that use the test harness which was recently merged (https://github.com/canonical/operator/pull/146/files)
[07:34] <Dmitrii-Sh> I am working on getting my interface PRs to a better state and will then switch my charm PRs
[07:34] <Dmitrii-Sh> https://github.com/canonical/cockroachdb-operator/pull/1/files - this charm PR has unit tests but they are for the peer relation
[07:36] <Dmitrii-Sh> I have a task to make it more modular so that I can test it in isolation from the operations that mutate the underlying machine and calls to network-get which are not yet handled by the harness
[07:37] <Dmitrii-Sh> t0mb0: sorry it's at that stage right now but I am doing what I can to move it forward
[07:41] <mthaddon> Dmitrii-Sh: how much are you expecting in the way of changes to how testing is done in the framework? Just wondering if it's worth us / t0mb0 investing time in beginning to write tests now, or whether we should hold off for a bit
[07:42] <mthaddon> test/test_cluster.py certainly looks like it has some useful examples from https://github.com/canonical/cockroachdb-operator/pull/1/files but just want to confirm how much we'd expect things to change at this point
[07:45] <Dmitrii-Sh> mthaddon: I would expect remote_app_data parameter to disappear here https://github.com/canonical/operator/blob/11a1849205d750e28aaa4a13938b5864659f928b/ops/testing.py#L143 per a discussion in https://github.com/canonical/operator/issues/211 but so far I am not aware of any other changes.
[07:45] <Dmitrii-Sh> I think it's worthwhile to start using the harness as-is
[07:46] <mthaddon> Dmitrii-Sh: thx - sounds like some minor changes, but certainly worth getting started with it. t0mb0 ^
[07:47] <niemeyer> Morning all
[07:48] <Dmitrii-Sh> morning
[07:48] <niemeyer> mthaddon, t0mb0: If you find any issues / struggles with the harness, this is a good time to raise them
[07:48] <niemeyer> jam has been pushing it forward and polishing it as we go
[07:49] <mthaddon> thx
[07:50] <t0mb0> no worries will dpo
[07:50] <t0mb0> *do
[08:30] <niemeyer> jam: Second review on #209
[08:35] <Chipaca> moin moin moin
[08:36] <jam> thanks niemeyer
[08:36] <jam> morning Chipaca
[08:38] <niemeyer> Chipaca: Morning!
[08:38] <niemeyer> Chipaca: You just got another review on #203
[08:38] <Chipaca> niemeyer: 👍
[09:30] <niemeyer> jam: You have another review on #196 as well
[09:54]  * Chipaca takes a break
[10:36] <Chipaca> dang, i messed up the revue thing
[11:13] <Dmitrii-Sh> Updated 216. I got rid of pickle but we still need to discuss serialization.
[11:13] <facubatista> Muy buenos días a todos!
[11:14] <Dmitrii-Sh> facubatista o/
[11:14] <Chipaca> facubatista: buen día!
[11:14] <facubatista> hola Dmitrii-Sh, Chipaca :)
[11:14] <Chipaca> I'm off to make lunch for m'boys
[11:14] <niemeyer> Off to lunch as well
[11:15] <facubatista> have a nice lunch!
[11:54] <t0mb0> Dmitrii-Sh, is state something that the harness supports? https://pastebin.canonical.com/p/V44mnMF9NK/ I've tried to pass my charm to the harness but it seems to trip up creating the state attribute
[11:55] <jam> t0mb0, https://github.com/canonical/operator/pull/199
[11:55] <jam> probably you just need to update your operator directory
[11:56] <Dmitrii-Sh> t0mb0: jam speaks the truth :^)
[11:56] <t0mb0> well thats easy!
[11:57] <Dmitrii-Sh> t0mb0: git submodule update --recursive --remote
[11:57] <Dmitrii-Sh> that's one way to update all of your submodules
[12:04] <t0mb0> \o/ works
[12:06] <Dmitrii-Sh> great!
[12:12]  * facubatista brb, doorbell
[12:17] <jam> facubatista, ping me when you'are back
[12:56]  * facubatista is back
[12:56] <facubatista> sorry it took long, it was the meat delivery
[12:56]  * niemeyer is sort of back too.. starting the meeting marathon
[12:58] <facubatista> jam, ping, I'm back :)
[13:02] <jam> hi facubatista, just hitting my meetings now as well. I wanted to check up on https://github.com/canonical/operator/pull/209
[13:03] <jam> Dmitrii-Sh, it seems https://bugs.launchpad.net/juju/+bug/1854635 didn't actually get backported. So it will be in 2.7.6 (landed today)
[13:04] <Dmitrii-Sh> jam: ok, then my tests were sane
[13:04] <facubatista> jam, we initiated a conversation in IRC, so for that to not be forgotten, I wrote this comment: https://github.com/canonical/operator/pull/209#issuecomment-609983367
[13:04] <Chipaca> Dmitrii-Sh: huzzah for sane tests
[13:05] <facubatista> jam, I kind of was expecting to continue the conversation there
[13:05] <jam> facubatista, hence why I pinged, but we'll chat after standup, I guess, since I can't chat live very well right now.
[13:05] <jam> I did intend to discuss it
[13:05] <jam> just ran out of time before meetings.
[13:05] <facubatista> jam, ah, perfect
[13:28] <jam> facubatista, if I understand you correctly, you're happy with the behavior, but you feel it is more obvious to pass a boolean rather than having a stream that isn't None indicating that you want the new behavior?
[13:31] <facubatista> jam, it's more about which part is deciding what... if you call setuplogging and say debug=True, is fine to that setup function to decide a level and a stream; it's weird that the stream is decided outside, and that according to that stream debug is implied (this opens a lot of questions, what if the external caller want that stream but in info, etc)
[13:31] <Chipaca> facubatista: stand up
[14:18] <jam> facubatista, so if it feels cleaner to you, go back to a boolean, and make the decisions internally again?
[14:20] <jam> I definitely prefer the env var to be evaluated in main(), but I can live with passing debug as a bool and having that decide to add a debug level log handler.
[14:22] <facubatista> jam, it feels cleaner to me to go back to the external caller saying "I want logs in debug mode" (with a bool), and the setup code internally deciding what "debug mode" means, for us here is DEBUG level and also send logs to stderr
[14:22] <facubatista> jam, the env var is perfect to be evaluated in main, yes
[14:22] <facubatista> (the main code may decide "go to debug mode" for several reasons in the future)
[14:23] <facubatista> so... who may help me splitting this schema in N charms? https://is.gd/WqBWkK
[14:23] <facubatista> to explain it...
[14:24] <facubatista> 1) everything is behind an apache, and two domains go to it
[14:24] <facubatista> 2) if that domain is blog.t.c.a, the apache just serve some static files (which are prepared before)
[14:25] <facubatista> 3) if that domain is comentarios.t.c.a, apache just proxies the request to a gunicorn serving other project
[14:26] <facubatista> so, I attempted to split that structure in charms... AFAIU, I should have two units?
[14:27] <facubatista> one with Apache serving local files... but I need a charm for the "blog" part, can I "mix it" with Apache?
[14:27] <Chipaca> facubatista: so. For docs. Get a new category on the discourse juju (charm-docs perhaps?)
[14:27] <facubatista> other with the comments system, exposing a port, for which I'll add a relation to the first unit, for apache to talk
[14:29] <Chipaca> facubatista: we probably need to talk with somebody to get the category set up fwiw
[14:29] <facubatista> is this structure correct?
[14:31] <facubatista> Chipaca, we already have https://discourse.juju.is/c/docs/charming-docs
[14:31] <facubatista> "charming-docs"
[14:33] <facubatista> Chipaca, do we want a different section? reuse that one? for sure we could reuse a lot of text fromt there, or we'll start something from the scratch?
[14:36] <Chipaca> facubatista: 1 sec
[14:39] <Chipaca> facubatista: I think we need a separate category
[14:39] <Chipaca> maybe ops-charms?
[14:39] <Chipaca> ops-charms-docs?
[14:39] <Chipaca> docops
[14:39] <facubatista> Chipaca, and start everything from scratch?
[14:40] <Chipaca> facubatista: we are
[14:40] <facubatista> "ops" is too obscure
[14:40] <Chipaca> starting from scratch i mean
[14:40] <facubatista> Yeap, but a lot from those texts are reusable, they tell a story, they talk about juju commands, etc
[14:40] <facubatista> which hooks exist and what they mean
[14:41] <facubatista> we could start from current structure, discuss if we want it verbatim or which changes we should do, then start to fill the titles
[14:47] <Chipaca> facubatista: I'd rather start with a blank slate, in a separate category, and point to the ones that apply, than making things confusing to newcomers by having things that are all about reactive or layers or w/e
[14:49] <facubatista> Chipaca, I agree; my point is that let's do not grow doc structure organically, let's plan it, and we can use current structure as a source for that planning
[14:50] <Chipaca> er
[14:50] <Chipaca> facubatista: i don't understand what you mean
[14:50] <Chipaca> maybe i'm missing something
[14:50] <Chipaca> facubatista: you needed a place to write _a_ doc
[14:51] <Chipaca> so let's make that place
[14:51] <Chipaca> it is still empty, missing all kinds of things, that yes they need planning and such
[14:51] <facubatista> Chipaca, yes; I'm also talking about what we want in a month
[14:51] <facubatista> or a year
[14:51] <facubatista> but yes, writing that one doc unblocks me
[14:51] <Chipaca> facubatista: so for now, write a doc there. It'll be weird, and disconnected from everything, but it's a place to write them
[14:52] <facubatista> eso
[14:52] <Chipaca> exactly
[14:52] <Chipaca> facubatista: and it's a place to write them that won't further confuse things, and will let us move forward better once other things line up
[14:52] <facubatista> we need a category, then... operator-charms-docs?
[14:53] <Chipaca> charm-operator-docs, or chods for short
[14:53]  * Chipaca hides
[14:55] <mthaddon> Chipaca: surely you mean "cods" :)
[14:55] <Chipaca> I dunno, there's something fishy in that one
[14:55] <mthaddon> I set them up, you knock 'em down...
[14:57] <Chipaca> mthaddon: :-D
[14:57] <facubatista> we can go with "ops-charm-docs" (which is just a token that will be used in the URLs), and "Operator Charms Docs" as the general title (which is what users will see)
[14:57] <Chipaca> facubatista: sgtm
[15:00] <facubatista> jam, you're admin in that Discourse, may you could create this new category for us? under general "Docs"? thanks!!
[15:05] <jam> facubatista, I have the edit rights to be able to create a category (once I finally found the page that has a new category button), do we care about badge colors/etc ? or just leave it at defaults for now
[15:09] <Chipaca> fwiw I don't mind (especially as you can change these later)
[15:10] <jam> https://discourse.juju.is/c/docs/ops-charm-docs
[15:15] <facubatista> jam, thanks!!
[15:15] <facubatista> jam, we should fix https://discourse.juju.is/t/about-the-operator-charm-docs-category/2893
[15:22] <Chipaca> jam: but not now. go away, now :-p
[15:23]  * jam runs away
[15:26]  * facubatista -> lunch
[16:18]  * facubatista is back
[16:25] <Dmitrii-Sh> jam:  ty for `self._framework = framework.Framework(":memory:", self._charm_dir, self._meta, self._model)` in the harness code
[16:25] <Dmitrii-Sh> makes things so much simpler in writing independent test cases with components that have state
[17:12]  * Chipaca steps away for a while
[19:36] <Dmitrii-Sh> Made some progress on splitting out logic in the cockroachdb-operator PR
[19:36] <Dmitrii-Sh> https://github.com/canonical/cockroachdb-operator/pull/1/commits/e6741a9a01432f19d445914a77ff3a65050f0bcd
[19:36] <Dmitrii-Sh> There are a couple of points to discuss related to injecting dependencies and https://github.com/canonical/operator/pull/196 needs to be merged to uncomment important lines in 3 test cases.
[19:37] <Dmitrii-Sh> otherwise, I managed to cover the logic I had to test manually previously so that's good in my view
[19:37] <Dmitrii-Sh>  *logging out for today"
[20:02] <Chipaca> Dmitrii-Sh: awesome, thank you, and good night
[20:02] <Dmitrii-Sh> Chipaca: cheers o/
[20:07] <Chipaca> facubatista: ping?
[20:16] <facubatista> Chipaca, pong
[20:17] <Chipaca> facubatista: pm
[21:31]  * facubatista eods, and eows! see you all on Monday!
[21:31] <niemeyer> facubatista: Have a good rest
[21:32] <facubatista> niemeyer, thanks!
[21:32] <facubatista> same for you
[21:32] <niemeyer> Thanks o/
[21:33] <Chipaca> facubatista: see you tuesday :D
[21:33] <facubatista> yes
[21:33]  * facubatista reboots for a long due update
[21:39] <Chipaca> I too disappear, but only until tomorrow
[21:39] <Chipaca> 👋


[06:59] <cpaelzer> good morning
[08:12] <Mirv> cjwatson: would https://code.launchpad.net/~timo-jyrinki/click/dont_use_@_in_testscontrol/+merge/302514 fix the autopkgtest failure?
[08:58] <jtaylor> LocutusOfBorg: I figured out why clang is not working in 16.04
[08:58] <jtaylor> having gccgo-6 installed breaks it
[08:58] <jtaylor> it selects gcc6 then but that installation is incomplete
[09:12] <xnox> mwhudson, doko, see jtaylor ^ sounds like fun
[09:13] <jtaylor> bug 1611676
[09:39] <doko> jtaylor, well, fix that silly clang ... there are absolutely no c++ headers
[09:47] <cjwatson> Mirv: approved, feel free to try it :)
[09:47] <Mirv> thanks!
[09:47] <cjwatson> seems plausible at least
[11:59] <doko> cjwatson, cyphermox: filed https://bugs.launchpad.net/ubuntu/+source/grub/+bug/1611740  I think I talked with cyphermox about it at the last sprint. do you can think of anything which still uses it?
[12:00] <showaz> ubuntu — clamav-unofficial-sigs v3.7.2 (updated 2013-08-25)
[12:00] <showaz> https://github.com/extremeshok/clamav-unofficial-sigs - 20 July 2016 (5.4.1)
[12:00] <Mirv> cjwatson: http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#click :( now the configure is searching for packagekit-plugin, when the test rebuild runs
[12:02] <cjwatson> doko: pass
[12:02] <cjwatson> doko: trace paths through grub-installer I guess
[12:06] <cjwatson> Mirv: debian/tests/run-tests.sh needs to do the same thing that debian/rules does - run debian/packagekit-check and if it says "no" then add the --disable-packagekit option to configure
[12:07] <cjwatson> Mirv: actually, TBH it could probably just pass --disable-packagekit - the integration tests don't need it
[12:07] <doko> cjwatson, so recursively look at all dependencies for a grub dependency?
[12:07] <cjwatson> Mirv: (unconditionally, I mean)
[12:08] <cjwatson> doko: no, I mean the code.
[12:08] <doko> ahh
[12:08] <cjwatson> doko: grub-installer is the d-i component that installs the actual grub package needed for the system
[12:08] <cjwatson> it probably still has some paths where it installs grub or grub-legacy, rather than some grub2ish grub-whatever package
[12:08] <cjwatson> so if you want to remove grub you need to work out whether those paths are still relevant
[12:09] <cjwatson> and you probably also need to work out what to do about upgrades which I think we may have punted on in Ubuntu
[12:09] <cjwatson> you cannot just say "no dependencies left, it doesn't matter"
[12:09] <doko> ok
[12:14] <jtaylor> hm wasn'T clang in xenial patched to support gccs abi tags?
[12:14] <jtaylor> still get linking errors with boost
[12:27] <showaz> jtaylor: ? http://apt.llvm.org/
[12:32] <Mirv> cjwatson: ok, thanks
[12:35] <jtaylor> showaz: I'm refering to the 1:3.8-2ubuntu4 update
[12:38] <showaz> ubuntu too old upstream software
[12:40] <doko> showaz, there is no newer release
[12:41] <showaz> 3.9
[12:41] <showaz> 4.0
[12:42] <doko> no, there is no release
[12:43] <showaz> 4.9-prelease/rc
[12:43] <showaz> 3.9*
[12:57] <ginggs> jtaylor: llvm 3.8 in xenial is still not quite right, see LP: #1610957 - i'm currently using a backport of 3.81 in yakkety
[13:00] <showaz> ubuntu-llvm used "ninja" for build/deploy?
[13:30] <cyphermox> doko: cjwatson: the only way you install grub (legacy) with grub-installer is if you were about to install grub-pc and someone preseeded grub-installer/grub2_instead_of_grub_legacy=false
[15:07] <seb128> hum
[15:07] <seb128> is pad.ubuntu.com working for others?
[15:08] <seb128> it gives me a "Failed to discover an OpenID server"
[15:08] <Laney> there is something going on
[15:08] <Pici> looks like launchpad is down.
[15:08] <Laney> I just got pagerduty calling me
[15:09] <seb128> launchpad wfm
[15:09] <Laney> about some kind of socket timeout
[15:09]  * Laney screams
[15:09] <seb128> Laney, is #is the right channel for that?
[15:10] <seb128> or is there a #is-something for services
[15:10] <Laney> seb128: they should know I guess
[15:10] <seb128> I asked there
[15:10] <seb128> let's see
[15:12] <Laney> seb128: #is-outage has some activity, guessing it's known
[15:21] <juliank> APT master has completed the switch to CMake. I specifically wrote the translation part so that we generate per-domain templates with headers now (build/po/libapt-pkg5.0.pot, build/po/apt.po, etc), so Launchpad can import them correctly. I hope it works...
[15:21] <juliank> In case you're wondering: Yes, launchpad has not imported apt translations for quite some time.
[15:22] <juliank> This should mean that langpacks can ship updated translations for apt again
[15:23] <seb128> juliank, great ;-)
[15:24] <cjwatson> LP> there was/is a switchover to a new firewall system which seems to have gone a bit wrong, not sure yet whether it's been totally fixed / rolled back
[15:48] <solarce> any chance anyone here has a contact with whomever at Canonical is involved in building and
[15:48] <solarce>  publishing the Ubuntu GCE images?
[15:56] <cyphermox> solarce: what problem are you seeing? maybe we can solve it right here, otherwise we can get you in contact with the right people
[16:25] <solarce> cyphermox: it seems like the setting to disable ipv6 by default in the GCE VMs was lost in an update to the images, at least for Trusty. But I'm not sure which because we just went from a 2015 release toa 2016 release yesterday
[16:25] <solarce> cyphermox: we were based on ubuntu-1404-trusty-v20150909a before and now we're based on ubuntu-1404-trusty-v20160627
[16:26] <solarce> cyphermox: https://github.com/travis-ci/packer-templates/commit/94f32ea4a6bb8c56c9dd3677a5c4708678b6ae8b#diff-8ed6e32f5d271c8bce697243861ea28aL31
[16:26] <solarce> cyphermox: we (travisci) because our build environment GCE images off the official Ubuntu ones, we do a packer + chef build process to customize it
[16:31] <solarce> cyphermox: is the tooling that's used to build the images for GCE public?
[16:58] <cyphermox> solarce: ok
[16:59] <solarce> i've been digging around, http://blog.utlemming.org/2014/11/gce-anyone.html indicates three people to reach out to in #ubuntu-server, so i've taken my question there
[17:10] <juliank> solarce: Did you guys also notice some network/port issues on trusty travis? The apt tests cannot seem to connect to ports on localhost they opened before. I'm not entirely sure what the cause of that is, but it used to work until yesterday
[17:11] <solarce> juliank: yes, it seems to be a side effect of ipv6 being enabled
[17:11] <solarce> juliank: we're building new trusty images with ipv6 disabled via sysctl.conf and should have that live in an hour or two
[17:12] <juliank> solarce: Great.
[17:12] <solarce> it took a long time to notice because most of the user bug reports where things like selenium failing to bind a port, etc
[17:12] <solarce> life in the cloud
[18:12] <solarce> cyphermox: thanks for the help
[18:13] <cyphermox> solarce: yeah, you'd want Odd_Bloke to respond to questions I guess
[18:13] <solarce> we got in touch in #ubuntu-server
[18:15] <cyphermox> ok good :)
[23:23] <infinity> GunnarHj: You around?
[23:24] <Unit193> I am.
[23:24] <GunnarHj> infinity: Yep
[23:28] <infinity> GunnarHj: Looks like https://sourceware.org/bugzilla/show_bug.cgi?id=9809 (and the patch we carry for it) needs updating for 2.24
[23:29] <infinity> GunnarHj: That's just the first failure I hit, I suspect most of our out-of-tree locales will need updating (because of Unicode 8.0)
[23:29] <infinity> GunnarHj: See, eg https://launchpad.net/~adconrad/+archive/ubuntu/ppa/+build/10596201
[23:30] <infinity> GunnarHj: Side-note, I really wish we didn't have out-of-tree locales. :P
[23:30] <infinity> (Backported ones from trunk, sure, but not random locales from wherever)
[23:38] <GunnarHj> infinity: I'll take a closer look. Are you saying they fail to build in next glibc version? As regards new locales, once in a while it's justified to be fast for motivational purposes. When a group of people wants to establish a new language, they shouldn't need to wait for months/years IMO. (But those situtations don't happen very often.)
[23:54] <GunnarHj> infinity: Will compare the patches which bring additional locales, and compare them with one of the 'established' ones. Getting back to you.