[00:00] Yippeee!! Lubuntu daily appears to boot on hp dc7700 again ! [00:00] I have some progress. If I edit /etc/calamares/modules/locale.conf and change in in geoip. style to "xml" and url from "json" to "xml" i get proper timezone pickedup === guiverc2 is now known as guiverc [00:00] EXCELLENT [00:01] ^ to both [00:01] so that tells us the problem must be in the locale module [00:01] and something about parsing the json. [00:02] or it's not providing the right results but i think that's unlikely [00:02] (it meaning ipapi) [00:03] I am leaning towards not parsing correctly since it displays as I would expect in the browser. [00:03] right, and in `curl` [00:04] right [00:04] plus there was that whole error about parsing [00:04] right [00:04] oh which cala do we have in ci anyways? [00:05] latest git [00:05] oh goodie [00:05] in unstable anyway [00:05] so then we do have a bug [00:05] DID SOMEONE SAY GIT BISECT? [00:06] @franksmcb please include the log file and all the results of your testing in that bug report and i'll file upstream [00:06] :) [00:06] i mean it sure seems like a regression [00:06] There is ABI BREAK XD [00:06] XD [00:06] * guiverc passes kc2bez some scotch tape :) [00:07] …cuz, if it's not scottish, it's crap? [00:07] ^ old people will get that joke [00:07] That should cover nicely. Thanks guiverc :D [00:07] I remember [00:07] told you XD [00:08] Will do wxl [00:10] https://www.dailymotion.com/video/xgzfxs [00:10] When you get that filed please let me know [00:11] I will git bisect it in the coming day if upstream doesn't know right away [00:11] Stable or unstable? ;) [00:14] @tsimonq2 bug's here https://bugs.launchpad.net/ubuntu/+source/calamares/+bug/1898501 [00:14] Launchpad bug 1898501 in calamares (Ubuntu) "lubuntu qa-test install with internet, calamares is selecting new york" [Undecided, Confirmed] [00:15] i will again point out this from the log: [00:15] virtual QString CalamaresUtils::GeoIP::GeoIPJSON::rawReply(const QByteArray&) WARNING:Invalid YAML data for GeoIPJSON [00:15] tl;dr it appears the problem is that the code is having trouble parsing the results [00:24] Updated the bug report [00:28] @franksmcb [Updated the bug report], Thanks again! [00:30] it does seem like welcome still fails, which overall agrees with my thinking the idea here is that GeoIPJSON is broken in general [00:30] (since bill only made changes to locale) [00:30] but locale is certainly behaving now [00:31] so i heard that we know the problem exists in focal [00:32] i presume, then, that the issue did NOT exist in eoan [00:32] guiverc mentioned that it happens in focal [00:33] I thought I chased this down a cycle or two ago. [00:33] which would suggest that the problem occured after 3.2.14 but before 3.2.20 [00:33] We've had the issue before.. but I too believe it was fixed.. [00:33] yeah we had it a long time ago and it was something else from what i can remember [00:34] i certainly don't remember that particular error [00:34] so it would be good to spot check past ISOs and see if we can find the most recent time it was NOT a problem and the most distant time it WAS a problem [00:34] You might be right about the error but the failure mode is similar. [00:35] that will give @tsimonq2 the information he needs to bisect [00:37] I've a focal daily (2020-10-07), I'll boot in VM and see what it detects; will be awhile [00:38] thx guiverc. get the version too while you're at it [00:40] i'm lazy do you still need me to test 20.04 -> 20.10 upgrades wxl? [00:40] nope thx @teward001 [00:43] to test my VM (rarely use it), I booted focal 2020-04-23 with calamares 3.2.20-0ubuntu1 & it reports new york, internet is working ! [00:43] * guiverc switching it to test 2020-10-07 [00:49] sorry focal ISO reports 2020-10-06 (/etc/apt/sources.list), calamares 3.2.20-0ubuntu1 with working internet, but New York again. [00:49] ok so our last bug was fixed with 3.2.14 https://bugs.launchpad.net/ubuntu/+source/calamares/+bug/1845424 [00:49] Launchpad bug 1845424 in calamares (Ubuntu) "Calamares not selecting correct timezone when connected to internet" [Undecided, Fix Released] [00:50] interesting what i find there [00:50] WARNING: Invalid YAML data for GeoIPJSON [00:51] so like i said 3.2.14 to 3.2.20 [00:51] somewhere in there [00:51] i'm off for the night [00:53] Night wxl & thanks [00:57] grrr. groovy daily won't boot on other hp [02:43] what does the lubuntu icon mean in synaptic? https://snapforum.s3.amazonaws.com/original/2X/6/689c143d3cb5e0f2719a0907d87ec667017a8ea6.png [03:31] I believe it's an icon indicating "Package is supported by the distribution" - hover over the icon in the description and see what it says @HMollerCl [07:18] c0d3ly0k0 was added by: c0d3ly0k0 [11:30] @teward001 [I believe it's an icon indicating "Package is supported by the distribution" - h …], I don't have a 18.04 anymore, I thought at the time it was a package present at clean installation (so I didn't uninstall when I was cleaning). It's a thing I miss in muon. [14:16] *shrugs* no idea :P [14:16] but I still have SYnaptic on 20.04 ;) [14:16] becaus I use it to sort by source when i'm cleaning out PPAs and stuff [17:43] @tsimonq2: any luck with your bisecting? [17:48] That was on the TODO list for today [17:48] Looking [17:49] ko [17:55] What were our start points for this again? [17:57] 3.2.14 to 3.2.20 [17:57] we had a similar problem that was solved with 3.2.14, but somewhere along the way it popped up again [17:58] @tsimonq2: i will again emphasize that it seems to be an issue with parsing json NOT xml, so i don't think the issue is within either module's logic, but instead in the geoip utility functions [17:59] Okay sounds good [18:08] geoip utility functions... [18:08] you using a geoip library somewhere wxl? [18:09] tsimonq2: wxl: asking because if you're using GeoIP functions you might need a second set of eyes [18:09] there's a lot of weirdness that comes wtih GeoIP stuff :P [18:09] i'd know, i had to write a GeoIP integration into a python API >.< [18:10] @teward001 I think they're looking at geoip on cala [18:11] @teward001 there's functionality within lxqt that, given rather simple results from api calls to online geoip services, twiddles localization stuff accordingly [18:12] lemme guess not python then :P [18:12] online geoip can be tricky too :P [18:13] https://github.com/calamares/calamares/blob/c40a5d62ca9b81d5e0b1b19acf1b8d720aa3e198/src/libcalamares/geoip/GeoIPJSON.cpp [18:13] err https://github.com/calamares/calamares/blob/master/src/libcalamares/geoip/GeoIPJSON.cpp [18:13] yep that looks like pain xD [18:13] not so much, at least not any more than c++ normally is [18:14] for that matter, i find cala's code rather elegant and readable [18:14] i hope they aren't using MaxMind GeoIP legacy 'cause that's dead [18:14] and GeoIP2 isn't free [18:15] Syncing my ISOs now. [18:16] i mean to be fair, all this does is interpret geoip data [18:17] the actually geoip in our case is being done by ipapi.co [18:17] git bisecting does seem to be an awfully non-precise way to get a precise answer heh... [18:17] which, interestingly, they DO seem to be some testing again https://github.com/calamares/calamares/blob/master/src/libcalamares/geoip/GeoIPTests.cpp#L238 [18:18] s|\(again\)|\1st| [18:18] wxl: Where was the manual testcase for this? [18:18] Does it completely not work when selecting time zones on the current daily? (Is it that simple?) [18:18] @tsimonq2: basically, no matter what, you end up with new york [18:18] You got it [18:19] to be fair, it autoselects it all for you, so it's not like you even really need to do anything [18:43] -queuebot:#lubuntu-devel- Unapproved: libfm-qt (groovy-proposed/universe) [0.15.1-0ubuntu2 => 0.15.1-0ubuntu3] (lubuntu) [21:13] I'm going to be verbose as I do this in case anyone would find it beneficial. [21:14] My first step was identifying which Calamares Focal had. We did not see this as a Focal problem, so we know it is at least a sane starting point. [21:14] I am currently building that with a Groovy schroot and installing it in the VM I have. If that fixes it, then we have our starting points. [21:22] About my environment, I am doing the packaging on my local system and I have a VM that uses sshfs to get into my host system to pull the deb files etc. [21:23] It looks like, unfortunately, that 3.2.20 right from Focal does not solve it. I'll go back a little further, but if that doesn't work it's probably underlying libraries. [21:26] i might have not made myself clear before [21:26] the bug is not fixed anywhere, including in master [21:27] No, you are 100% clear. [21:27] we had a similar bug solved with 3.2.14. sometime after that but before 3.2.20 (where we know the bug does exist) it popped up again, or manifested in a different form [21:27] I am looking to see how far back we can go before there is a fix. [21:27] what you need to do is keep going back until you find it not broken XD [21:27] Okay, so I'll start with `ubuntu/3.2.14-0ubuntu1` in the packaging. [21:27] Yeah, we're on the same page. [21:28] This part is fun because if old Cala doesn't build against new libraries, I have to tweak along the way. [21:29] right. the fix was indeed 3.2.14-0ubuntu1 [21:29] so that definitely worked [21:29] I am confirming locally and then yes, I will start the proper Git bisect. [21:29] Good to see you around again wxl, btw. :) [21:30] You were right about Matrix, maybe a year or two early but you were right. [21:30] after that, there's 3.2.14-0ubuntu{2-3}, 3.2.17.1-0ubuntu{1-5}, 3.2.18-0ubuntu1, and 3.2.19.1-0ubuntu1 [21:31] if it were me i'd hit on those major releases first as i doubt little patches are going to be the cause of our issues [21:31] I'm not concerned about that, I will likely just do the Git bisect on the upstream repo and adjust packaging as needed. [21:31] and yes it's nice to all be back :) [21:32] glad to hear you're enjoying matrix. what mobile client you using? [21:32] Element [21:32] What about you? [21:32] same [21:33] What's your Matrix handle? I'm @tsimonq2:linuxdelta.com [21:34] 1s [21:35] I don't even use irssi anymore, I do it all through Matrix. Super convenient. [21:44] Looks like 3.2.14 won't build. [21:45] Working my way up to see if I can get a better one... [22:00] I'm hoping the regression is not in between 3.2.14 and 3.2.19. [22:00] If not, I am going to have to backport a Boost patch. Nice. [22:11] I think that's what I'm going to have to do. 3.2.19 doesn't work. [22:14] finally back. my previous provider stopped offering matrix :( [22:16] Aww. :( [22:16] You shouldn't even be able to tell I'm on Matrix (except for me saying so) yeah? [22:23] From irc I can tell [22:23] Oh? [22:24] Your name has your matrix username [22:24] huh ok [22:30] quasseldroid pulls down your matrix avatar too [22:32] NICE [22:32] That's neat. [22:32] Does it just have my username there or my full name? [22:33] Also, as a status update, I am git bisecting to see if I can find the code that fixed things with the newer Boost version. [22:34] just the username [22:34] (Photo, 760x266) https://i.imgur.com/lFx5OOf.jpg [22:34] Sweet. [22:48] tsimonq2: Fwiw, you aren't even logged in to your Freenode account currently, so you get the full glory of a KDE Matrix hostname, too. >_< [22:48] I'm not???? [22:48] Ooooooops. [22:49] @wxl [ the actually geoip in our case is being done by ipapi.co], hope the backend API usage has people paying for it... [22:49] because otherwise that API is going to have problems lol [22:49] *smacks @tsimonq2 for failure* [22:50] I'm thinking we should just point that to KDE's. [22:50] * tsimonq2 smacks @teward001 for Reasons [22:50] we're allowed up to 30k lookups a month :) [22:51] wxl: still a low number if, for instance, someone decides to move an entire set of systems over to Lubuntu. :P [22:51] Has Ubuntu gotten rid of its own geoip infrastructure? [22:51] Canonical definitely had it in the Touch days, thought it was still kicking around [22:52] I like your optimism @teward001 [22:52] I mean, Ubuntu probably does [22:52] He isn't actually far off. [22:52] :D [22:52] I mean, I use GeoIPLite2 databases off of MaxMind on my iptracker site I use for local regional testing and IP checks [22:53] works pretty well, though sliiighly inaccurate at times [22:53] i disagree. he's definitely off. but he's probably right about this [22:53] Let's have that discussion. Should it be on our own infra? What does Canonical offer? What does KDE offer? [22:53] i don't know how reliable that kde service is [22:53] wxl: I'm always 'off' - it's what makes me a good IT Security person 'cause i'm in the extremist category of insanity [22:53] extreme category* [22:53] @teward001 no i mean you stink :) [22:53] "Chaotic evil." [22:53] XD [22:54] hold that thought. *drops fifty tons of toxic waste on wxl's home* right, that's done now. [22:54] What is driving the KDE stuff? [22:54] oh i got a ping [22:54] I think just a Golang server on their infra. [22:54] https://geoip.kde.org/doc/ [22:54] Go, run away [22:55] Again, it's just up to whether we want it to be our infra that gets hammered. :P [22:55] it's a part of their infrastructure https://community.kde.org/Infrastructure [22:55] i mean... https://ifconfig.co/ is something I've used, it's a FOSS solution, and I can run it off our infra if we want it [22:55] curl the `/json` URI and you can get timezone and other data pretty easy [22:55] i think i would prefer not to run it off our own infra if we can avoid it [22:56] I'm in agreement there. [22:56] Can we just run it off of KDE's? What would be the downsides to doing that? [22:57] KDE explodes, infra goes away, ip lookups fubar hard [22:57] right [22:57] that^ [22:57] Okay, so what's the best solution then? [22:58] (Should we try to use Canonical's?) [22:58] i think using some external, established, service is going to be wise [22:58] if canonical still has it, i'm all for that [22:58] +1 [22:58] where we find that i don't know [22:59] and does it give us everything we need [22:59] I think we should explore whether Calamares can interpret the Canonical data given that it's in XML and not standardized. [22:59] you'd probably need an XML parser in Cala to handle the data [22:59] xml should work [22:59] Right. [22:59] http://geoip.ubuntu.com/lookup [22:59] xml is fine as long as it has a selector with a country code and a selector with a time zone [22:59] That's our starting point. [23:00] oh good find [23:00] right [23:00] US [23:00] America/Chicago [23:00] well if we made that switch, we can just ignore this bug because it won't affect us (it seems the problem is json not xml) [23:00] Regardless, I would like to see it fixed... [23:00] curious. i get no time zone. [23:00] wxl: does your IP have geoip location? [23:01] not all have timezone data in their geolocations [23:01] esp. if it looks up as Middle Of Nowhere [23:01] :P [23:01] well it works with all the other ones [23:01] We might also want to look at how Ubiquity handles this. [23:01] I get a time zone. [23:01] same here [23:02] might be something to do with my ip then [23:02] tor browser XD [23:02] I'm just going to see really quickly if it works as a drop-in replacement. [23:02] no tor gives like NOTHING [23:03] country code is "A1" [23:03] @tsimonq2: make sure to be very careful about the case sensitivity of the selector and don't forget to change the style to xml [23:03] I think we have country not countrycode in the settings so we will have to watch that. [23:03] ^ [23:04] yes also case sensitive [23:05] wxl PM me your IP i'll see what Maxmind says about your existence xD [23:05] @teward001 [wxl PM me your IP i'll see what Maxmind says about your existence xD], XD [23:07] well he did xD [23:12] i'm actually surprisingly impressed by ipapi heh. [23:13] but 1k lookups per day is their limit [23:13] (on free) [23:16] @tsimonq2 wxl: I'd say use Canonical or KDE's infra, or use ipapi. Failing that, I can probably reactivate my ipcheck site which is based off of ifconfig.co (but uses GeoIP2 libs) [23:16] Canonical's works as a drop-in replacement. [23:16] i'm voting on canonical [23:17] I will throw the change in ci/stable for testing prior to uploading. [23:17] i suspect that will continue to be used [23:18] Oh wait, I can't just throw it in CI. Native package. [23:18] I did test it to confirm so I'll just upload it. [23:20] Nice. Thank you tsimonq2 [23:21] ofc [23:23] maybe just file an upstream issue about the json problem. or just leave a new on cala chat [23:23] they'll figure it out :) [23:24] Okay. [23:24] Uploaded to Groovy, preparing an SRU for Focal. [23:26] -queuebot:#lubuntu-devel- Unapproved: calamares-settings-ubuntu (groovy-proposed/universe) [1:20.10.10 => 1:20.10.11] (lubuntu, ubuntustudio) [23:27] https://git.launchpad.net/ubuntu/+source/ubiquity/tree/ubiquity/plugins/ubi-timezone.py#n39 [23:29] tsimonq2: That upload is all good and everything, I just hope it doesn't break North Idaho. Ubiquity incorrectly identifies North Idaho as Mountain Time when it's in Pacific Time, and I don't know if it's related to the Canonical geoip service. [23:30] * Eickmeyer[m] is directly affected [23:32] * Eickmeyer[m] sent a long message: < https://matrix.org/_matrix/media/r0/download/matrix.org/bWMIgFTYuHNbOgjetxKnTqWV/message.txt > [23:33] @Eickmeyer so go to http://geoip.ubuntu.com/lookup and seed what it says about you :P [23:33] ahhh that's mountain time too [23:33] hmm [23:33] that sounds more like a GeoIP lib problem xD [23:33] @Eickmeyer but also that won't affect you immediately, you can always alter during the install process [23:34] that geoip i think is for autopop of the timezone during install [23:34] which can be overridden whenever heh [23:34] @teward001 Well, Fedora's installer identifies it correctly, so it's clearly something set wrong at geoip.ubuntu.com. [23:34] wellllll [23:34] from what i can see in ubiquity it doesn't use that [23:34] I realize it's trivial, but it's still wrong. [23:34] it uses geoname-lookup.ubuntu.com [23:35] I'm willing to bet it's the same bug. [23:35] i don't feel like expending the effort to figure out their api endpoints so moving on XD [23:36] wxl: I think someone at Canonical needs to get it straight. The problem is that Idaho is in two different time zones. Everything north of the Salmon River is in Pacific, south is in Mountain. [23:37] Unfortunatley, someone lumped the entire state into mountain, and it's been driving me nuts for years. [23:37] where's the bug report? :) [23:37] If I have Automatic Time Zone selected in some DEs, I get thrown into Mountain. [23:38] https://bugs.launchpad.net/ubuntu/+source/calamares-settings-ubuntu/+bug/1899854 [23:38] Launchpad bug 1899854 in calamares-settings-ubuntu (Ubuntu Focal) "[SRU] Move to Canonical's GeoIP Service" [Medium, In Progress] [23:40] -queuebot:#lubuntu-devel- Unapproved: calamares-settings-ubuntu (focal-proposed/universe) [1:20.04.2 => 1:20.04.2.1] (lubuntu) [23:40] wxl: Looking.... [23:41] https://bugs.launchpad.net/ubuntu/+source/ubiquity/+bug/1895716 [23:41] Launchpad bug 1895716 in ubiquity (Ubuntu) "Ubiqutiy erroneously sees North Idaho in US Mountain Time" [Undecided, New] [23:41] wxl: i mean, if it's that big a deal I can spin up a geoip lookup service here... I have no qualms about Lubuntu using my LLC's geoip lookup feature (it's ratelimited at like 60 lookups / minute) [23:41] just gonna take a bit [23:41] because i have to reassign IPs :P [23:42] But, if it's a bug in geoip then I need to reassign it. [23:46] Eickmeyer[m]: i'd advise updating that bug with the results of as many geoip services as possible [23:47] my guess is all of them are likely good, so that would confirm the issue is in ubiquity as suggested [23:47] Eickmeyer[m]: https://git.launchpad.net/launchpad/tree/lib/lp/services/worlddata [23:52] um [23:53] @tsimonq2: https://phab.lubuntu.me/source/calamares-settings-ubuntu/history/master/ ¿no existe? [23:53] ? [23:53] Update Frequency [23:53] 1 h, 49 m · Learn More [23:54] Just manually did an update. [23:54] https://phab.lubuntu.me/source/calamares-settings-ubuntu/manage/basics/ [23:54] Right side. [23:54] Except... where are the Phab daemons? [23:54] okok [23:54] oh it did the thing [23:54] ok [23:57] Prolly needs a kick in the pants again ^