[09:55] <javier4> abeato: are you there?
[09:56] <abeato> javier4, yep
[09:56] <abeato> javier4, any luck with sending the resume registration message?
[09:57] <javier4> abeato: still struggling with it. I'm not exactly a coder, then probably it will took a little bit more than expected. I have a question:
[09:58] <javier4> I need to use a pointer to a struct ofono_netreg
[09:58] <javier4> it's defined in src/network.c.
[09:58] <javier4> better redefine the struct, or link the existent one?
[10:01] <abeato> javier4, you do not need to have the structure defined to have a pointer to it
[10:01] <abeato> javier4, just a typedef that must already exist
[10:02] <abeato> javier4, just include <ofono/netreg.h>
[10:03] <javier4> -.-" I included just "netreg.h", thinking it was into default include dirs.
[10:23] <javier4> abeato: still getting
[10:23] <javier4> https://www.irccloud.com/pastebin/0zdH66bq/
[10:24] <abeato> javier4, show me youd code, I don't think you need to access data inside ofono_netreg
[10:25] <javier4> https://www.irccloud.com/pastebin/tkm0FcPG/%23ifdef%20HAVE_CONFIG_H%20%23include%20%3Cconfig.h%3E%20%23endif%20%20%23define%20_GNU_SOURCE%20%23include%20%3Cstring.h%3E%20%23include%20%3Cstdlib.h%3E%20%23include%20%3Cstdio.h%3E%20%20%23include%20%3Cglib.h%3E%20%20%23include%20%3Cofono%2Flog.h%3E%20%23include%20%3Cofono%2Fmodem.h%3E%20%23include%20%3Cofono%2Fn
[10:26] <javier4> etreg.h%3E%20%23include%20%3Cofono%2Fspn-table.h%3E%20%20%23include%20%22common.h%22%20%23include%20%22gril.h%22%20%20%23include%20%22grilreply.h%22%20%23include%20%22grilrequest.h%22%20%23include%20%22grilunsol.h%22%20%23include%20%3Cofono%2Fnetreg.h%3E%20static%20void%20ril_network_state_change(struct%20ril_msg%20*message%2C%20%09%09%09%09%09%09%09gpointer
[10:26] <javier4> %20user_data)%20%7B%20%09struct%20ofono_netreg%20*netreg%20%3D%20user_data%3B%20%09struct%20netreg_data%20*nd%20%3D%20ofono_netreg_get_data(netreg)%3B%20%20%09g_ril_print_unsol_no_args(nd-%3Eril%2C%20message)%3B%20%20%09ril_registration_status(netreg%2C%20NULL%2C%20NULL)%3B%20%7D%20%20static%20void%20ril_strength_notify(struct%20ril_msg%20*message%2C%20gpoin
[10:26] <javier4> ter%20user_data)%20%7B%20%09struct%20ofono_netreg%20*netreg%20%3D%20user_data%3B%20%09struct%20netreg_data%20*nd%20%3D%20ofono_netreg_get_data(netreg)%3B%20%09int%20strength%20%3D%20g_ril_unsol_parse_signal_strength(nd-%3Eril%2C%20message%2C%20%09%09%09%09%09%09%09%09nd-%3Etech)%3B%20%20%09ofono_netreg_strength_notify(netreg%2C%20strength)%3B%20%7D%20%20stat
[10:26] <javier4> ic%20void%20ril_nitz_notify(struct%20ril_msg%20*message%2C%20gpointer%20user_data)%20%7B%20%09struct%20ofono_netreg%20*netreg%20%3D%20user_data%3B%20%09struct%20netreg_data%20*nd%20%3D%20ofono_netreg_get_data(netreg)%3B%20%09int%20year%2C%20mon%2C%20mday%2C%20hour%2C%20min%2C%20sec%2C%20dst%2C%20tzi%2C%20n_match%3B%20%09char%20tzs%2C%20tz%5B4%5D%3B%20%09gcha
[10:26] <javier4> r%20*nitz%3B%20%20%09nitz%20%3D%20g_ril_unsol_parse_nitz(nd-%3Eril%2C%20message)%3B%20%09if%20(nitz%20%3D%3D%20NULL)%20%09%09goto%20error%3B%20%20%09n_match%20%3D%20sscanf(nitz%2C%20%22%25u%2F%25u%2F%25u%2C%25u%3A%25u%3A%25u%25c%25u%2C%25u%22%2C%20%26year%2C%20%26mon%2C%20%09%09%09%09%26mday%2C%20%26hour%2C%20%26min%2C%20%26sec%2C%20%26tzs%2C%20%26tzi%2C%20%
[10:26] <javier4> 26dst)%3B%20%09if%20(n_match%20%21%3D%209)%20%09%09goto%20error%3B%20%20%09sprintf(tz%2C%20%22%25c%25d%22%2C%20tzs%2C%20tzi)%3B%20%20%09nd-%3Etime.utcoff%20%3D%20atoi(tz)%20*%2015%20*%2060%3B%20%09nd-%3Etime.dst%20%3D%20dst%3B%20%09nd-%3Etime.sec%20%3D%20sec%3B%20%09nd-%3Etime.min%20%3D%20min%3B%20%09nd-%3Etime.hour%20%3D%20hour%3B%20%09nd-%3Etime.mday%20%3D
[10:26] <javier4> %20mday%3B%20%09nd-%3Etime.mon%20%3D%20mon%3B%20%09nd-%3Etime.year%20%3D%202000%20%2B%20year%3B%20%20%09ofono_netreg_time_notify(netreg%2C%20%26nd-%3Etime)%3B%20%20%09g_free(nitz)%3B%20%20%09return%3B%20%20error%3A%20%09ofono_error(%22%25s%3A%20unable%20to%20notify%20ofono%20about%20NITZ%20(%25s)%22%2C%20%09%09%09%09%09%09__func__%2C%20nitz%20%3F%20nitz%20%3
[10:26] <javier4> A%20%22null%22)%3B%20%09g_free(nitz)%3B%20%7D%20%09%09%09%09%09%09%09%20static%20gboolean%20ril_delayed_register(gpointer%20user_data)%20%7B%20%09struct%20ofono_netreg%20*netreg%20%3D%20user_data%3B%20%09struct%20netreg_data%20*nd%20%3D%20ofono_netreg_get_data(netreg)%3B%20%09ofono_netreg_register(netreg)%3B%20%20%09%2F*%20Register%20for%20network%20state%20
[10:26] <javier4> changes%20*%2F%20%09g_ril_register(nd-%3Eril%2C%20RIL_UNSOL_RESPONSE_VOICE_NETWORK_STATE_CHANGED%2C%20%09%09%09ril_network_state_change%2C%20netreg)%3B%20%20%09%2F*%20Register%20for%20network%20time%20update%20reports%20*%2F%20%09g_ril_register(nd-%3Eril%2C%20RIL_UNSOL_NITZ_TIME_RECEIVED%2C%20%09%09%09ril_nitz_notify%2C%20netreg)%3B%20%20%09%2F*%20Register%2
[10:26] <javier4> 0for%20signal%20strength%20changes%20*%2F%20%09g_ril_register(nd-%3Eril%2C%20RIL_UNSOL_SIGNAL_STRENGTH%2C%20%09%09%09ril_strength_notify%2C%20netreg)%3B%20%09%09%09%20%09g_ril_register(nd-%3Eril%2C%20MTK2_RIL_UNSOL_RESPONSE_REGISTRATION_SUSPENDED%2C%20%09%09%09mtk2_reg_suspended%2C%20netreg)%3B%20%20%09%2F*%20This%20makes%20the%20timeout%20a%20single-shot%20
[10:26] <javier4> *%2F%20%09return%20FALSE%3B%20%7D%20%20%20struct%20mtk2_ril_data%20%7B%20%09GRil%20*ril%3B%20%09enum%20ofono_ril_vendor%20vendor%3B%20%09int%20sim_status_retries%3B%20%09ofono_bool_t%20init_state%3B%20%09ofono_bool_t%20ofono_online%3B%20%09int%20radio_state%3B%20%09struct%20ofono_sim%20*sim%3B%20%09int%20rild_connect_retries%3B%20%09GRilMsgIdToStrFunc%20requ
[10:26] <javier4> est_id_to_string%3B%20%09GRilMsgIdToStrFunc%20unsol_request_to_string%3B%20%09ril_get_driver_type_func%20get_driver_type%3B%20%09struct%20cb_data%20*set_online_cbd%3B%20%09int%20suspend_id%3B%20%7D%20%20static%20void%20mtk2_reg_suspended(struct%20ril_msg%20*message%2C%20gpointer%20user_data)%20%7B%20%09struct%20ofono_modem%20*modem%20%3D%20user_data%3B%20%09
[10:26] <javier4> struct%20mtk2_ril_data%20*md%20%3D%20ofono_modem_get_data(modem)%3B%20%09struct%20parcel%20rilp%3B%20%09int%20session_id%3B%20%20%09session_id%20%3D%20g_mtk2_unsol_parse_registration_suspended(md-%3Eril%2C%20message)%3B%20%09if%20(session_id%20%3C%200)%20%7B%20%09%09ofono_error(%22%25s%3A%20parse%20error%22%2C%20__func__)%3B%20%09%09return%3B%20%09%7D%20%20%
[10:26] <javier4> WTF. 0.o
[10:26] <javier4> I'm sorry.
[10:26] <abeato> lol
[10:26] <abeato> nw
[10:27] <javier4> https://pastebin.com/7E6e036N
[10:32] <abeato> javier4, what you need is the definition of "struct netreg_data", not of ofono_netreg
[10:33] <abeato> javier4, that struct is defined in rilmodem/network-registration.c
[10:33] <abeato> javier4, you need to move that to a header, rilmodem/network-registration.h
[10:33] <abeato> javier4, check rilmodem/gprs.h for an example of how that is done in other case
[10:34] <abeato> javier4, basically whenever mtk/mtk2 need a struct from rilmodem, that is how it gets done
[10:36] <javier4> You're right. I confused a line with the next one...
[10:37] <javier4> abeato: I see that inside rilmodem/network-registration.c the struct is defined but not declare: is it implicit? I have to put the declaration inside the new header without stripping off anything from the source, right?
[10:38] <abeato> javier4, correct
[14:21] <rbasak> cpaelzer, pitti: any opinion on postgres being in the server packageset? It isn't currently I think.
[14:22] <pitti> sounds appropriate to me
[14:22] <pitti> it has "server" in the package description, and it serves bits :)
[14:23] <rbasak> Yeah that's what I was thinking :-)
[14:23] <rbasak> It's also mostly a leaf package - you don't install the server daemon unless you want to be a server.
[14:26] <cpaelzer> rbasak: I'm fine with that as an approach to the application I brought up - we can discuss that in the DMB next week in just that scope right?
[14:28] <javier4> abeato: I solved a bunch of include issues, but now I got
[14:28] <javier4> drivers/mtk2modem/network-registration.c:125:2: error: unknown type name ‘ril_get_driver_type_func’   ril_get_driver_type_func get_driver_type;
[14:28] <javier4> then I included ril.h, and got this
[14:28] <javier4> https://www.irccloud.com/pastebin/f1LKXOgh/
[14:29] <rbasak> cpaelzer: sure
[14:33] <camako> tjaalton, So are you good with the Mesa and vulkan patches?
[14:40] <abeato> javier4, try to add same includes as in rilmodem/gprs.h first
[14:42] <javier4> abeato: are you sure? That enum is defined inside src/ofono.h that's not included by that header.
[14:44] <Guest59895> why tor exit node not work in IRC
[14:47] <abeato> javier4, then include ofono.h ;)
[14:48] <javier4> abeato: I'll try. the things that seems strange to me, is that ofono.h wasn't directly included by ril.h
[15:08] <barry> jbicha: hi.  do you have any plans on fixing LP: #1671572 for zesty?  just wondering
[16:27] <jbicha> barry: chrome-gnome-shell fix uploaded to zesty unapproved queue
[16:38] <dobey> anyone know anything about sbuild and /run/user within it?
[16:47] <nacc> powersj: re: LP: #1625043, i was mostly trying to figure out if you deployed something tomcat6+java6 on 12.04 and upgraded to 14.04 -- did the tomcat6 deployment break because tomcat6 was now built with java7 ?
[16:48] <powersj> nacc: if you relied on something that had an API change then yes
[16:49] <nacc> powersj: right, i need you (or me) to do that due diligence and understand if that was supported better in that transition, etc
[16:49] <nacc> powersj: maybe by asking jamespage to take a look at that bug briefly :)
[16:49] <powersj> what do you mean by supported better
[16:49] <nacc> powersj: was there packaging changes, etc., so things didn't break
[16:50] <nacc> powersj: or is there precedence that LTS -> LTS tomcat upgrades require work?
[16:50] <tjaalton> camako: they're fine, i'll upload them after new X
[16:50] <camako> tjaalton, thanks... I'm assuming this will be the last upload for Zesty, correcT?
[16:51] <nacc> jgrimm: i just realized something re: LP: #1634989 -- i think you actaully wanted 3.5.7-1ubuntu0.16.04.1 -- not that it's likely, but if there was a ubuntu16 of 3.5.7, this upload would sort after it
[16:52] <dobey> why would anything run during a build with sbuild, be run as uid 106?
[16:52] <tjaalton> camako: pretty much
[16:52] <powersj> nacc: I went through the change log to check for exactly those changes, but if someone who was around could comment that would probably be good :)
[16:53] <nacc> powersj: ok, jamespage is probably our best bet -- or you could see if there are older/close tomcat6 bugs tht maybe refer to something similar
[16:53] <jgrimm> nacc, cool i'll look at that later today
[16:53] <nacc> jgrimm: thanks, i'm happy to sponsor with tht fixed
[16:53] <jgrimm> nacc, thanks!
[16:56] <nacc> jgrimm: np -- sorry for the delay
[16:57] <jgrimm> nacc,  no worries, was not urgent, i would have poked it it was. ;)
[17:00] <nacc> powersj: regardless, i guess, do you want to mark that bug as in progress by you? or triaged or something? (rather htan confirmed)?
[17:02] <nacc> cpaelzer: similar question for you for LP: #1320709 ?
[17:02] <powersj> nacc: hmm I'm almost tempted to put it into incomplete, but having one last comment would be good, so how about triaged
[17:02] <powersj> if you have it open :) otherwise I can go do it
[17:02] <nacc> powersj: seems reasonable, i'm happy with whatever you decide, i just want consensus in the bug and an agreement (if posisble) from the submitter
[17:02] <nacc> powersj: updated that bug
[17:03] <powersj> nacc: thanks and thanks for the ping on that one
[17:33] <barry> jbicha: great, thanks!
[17:40] <powersj> nacc: can I punt LP: #1597344 to you? :)
[17:42] <nacc> powersj: sure,
[17:42] <nacc> powersj: any context (i'll just put it on the end of my triage list rightnow)
[17:42] <powersj> a2enmod of php7 failure
[17:43] <nacc> powersj: ok
[17:43] <powersj> hoping you would know more about that possibly
[17:43] <nacc> powersj: thanks, will take a look
[18:01] <nacc> teward: thanks for picking up LP: #1673056
[18:32] <cpaelzer> nacc: I kept it confirmed instead of triaged as I would have waited on the Debian feedback to decide
[18:33] <cpaelzer> nacc: reporting to Debian without and response is almost identical to not reported yet
[18:33] <cpaelzer> nacc: once I can consider the position of the Debian peer to us for a given case I switch states, but I'm good with you setting triaged just as much
[18:34] <cpaelzer> nacc: I guess that is down to preferences
[18:34] <nacc> cpaelzer: mostly dont' want to have to re-triage it
[18:34] <jgrimm> nacc, bug1634989 updated per request
[18:34] <nacc> jgrimm: thanks!
[18:35] <jgrimm> thank you!
[19:00] <rbasak> !dmb-ping
[22:25] <mwhudson> apw, smb: do you know why the ubuntu-fan autopkgtest is failing with the new docker in zesty-proposed?
[22:26] <mwhudson> it started failing with the 1.12.6-0ubuntu3 upload but there's no way the change in that broke the fan
[22:27]  * mwhudson takes it to mail
[23:25] <mwhudson> halp
[23:25] <mwhudson> infinity, robru: you around (or anyone else who understands britney)
[23:26] <infinity> mwhudson: I'm around, but I make no claim to understanding britney.
[23:27] <mwhudson> infinity: i was wondering why britney thinks the docker autopkgtests are "always failed" on http://people.canonical.com/~ubuntu-archive/proposed-migration/zesty/update_excuses.html#runc
[23:28] <infinity> mwhudson: It's close enough to true. :P
[23:28] <infinity> But more seriously, I'm not sure of the criteria used there.
[23:28] <mwhudson> heh
[23:29] <mwhudson> the test failed, but probably because it ran against the docker in release, which has a buggy test
[23:29] <mwhudson> at least i hope that's why it failed
[23:32] <infinity>                 if ever_passed and not self.has_force_badtest(src, ver, arch):
[23:32] <infinity>                     result = 'RUNNING'
[23:32] <infinity> stgraber:force-badtest docker.io/1.12.6-0ubuntu1
[23:33] <infinity>                 else:
[23:33] <infinity>                     result = 'RUNNING-ALWAYSFAIL'
[23:33] <infinity>                 url = 'http://autopkgtest.ubuntu.com/running'
[23:33] <infinity> So, there you go.  It's "always failed" because of a badtest hint.
[23:33] <infinity> mwhudson: ^
[23:34] <mwhudson> infinity: ah hah
[23:35] <infinity> mwhudson: Any idea why the ubuntu-fan tests fails (only on amd64?) with the new docker?  Then we could promote it and that would go away.
[23:35] <mwhudson> infinity: no, i just sent a nastygram to apw and smb about that
[23:36]  * infinity nods.
[23:36] <infinity> I guess, to be fair, it fails on lots of arches, but the amd64 failure is both different and new.
[23:44] <mwhudson> infinity: i don't think it can be a docker changed, it stopped working between ubuntu2 and ubuntu3
[23:47] <mwhudson> infinity: which is this diff http://launchpadlibrarian.net/310436103/docker.io_1.12.6-0ubuntu2_1.12.6-0ubuntu3.diff.gz
[23:47] <mwhudson> (which, ironically, is the thing we really want in release)
[23:48] <bdmurray> flexiondotorg: Do your actions in bug 1641915 mean you no longer want it sponsored?
[23:48] <mwhudson> infinity, stgraber: so is it appropriate to badtest the ubuntu-fan to let docker.io migrate?
[23:49] <mwhudson> someone(tm) still needs to figure out why the test is failing but it seems letting docker migrate would strictly improve the situation
[23:50] <mwhudson> (fortunately the fixed docker autopkgtest does actually pass with the new runc so i can relax a bit on that score)
[23:52] <flexiondotorg> bdmurray It still needs sponsoring.
[23:55] <bdmurray> flexiondotorg: I'd sponsor it if you answered my question.
[23:55] <flexiondotorg> bdmurray It was added to Zesty by jbicha I believe.