[systemsettings] [Bug 340982] No way to change just the date format but not its actual translated text
https://bugs.kde.org/show_bug.cgi?id=340982 --- Comment #215 from Keith Zubot-Gephart --- With this bug remaining unresolved (in the colloquial sense ;)) for nearly a decade now however, doesn't that seem like a matter of letting the perfect be the enemy of the good? It certainly seems like if we're holding out for a change at that low of a level, we'll be holding out forever. -- You are receiving this mail because: You are watching all bug changes.
[kdeconnect] [Bug 375644] Unable to pair kdeconnect when connecting via OpenVPN, even if specifying hostname or IP address
https://bugs.kde.org/show_bug.cgi?id=375644 --- Comment #15 from Keith Zubot-Gephart --- To be explicit: after adding a routing rule, I can then ping from the host PC to the Android device (vice-versa was always true). However, the Android app still does not see the PC as a valid pairing target, even after adding the hostname or IP address via "Add devices by IP". -- You are receiving this mail because: You are watching all bug changes.
[kdeconnect] [Bug 375644] Unable to pair kdeconnect when connecting via OpenVPN, even if specifying hostname or IP address
https://bugs.kde.org/show_bug.cgi?id=375644 --- Comment #14 from Keith Zubot-Gephart --- I do intend on trying to bludgeon an OpenVPN and routing setup at work this week (hopefully Monday if nothing else gets in the way) into accomplishing this. I'm still somewhat unsure that this is entirely possible with my own setup, however; Erik Duisters' solution including removing a masquerade rule making all traffic appear to be coming from the VPN server doesn't apply to my case, where each VPN client in fact gets its own IP address. That a lack of an applicable routing rule is nonetheless stymieing me doesn't seem entirely unlikely; however I've tried setting one from the host PC and added the hostname in the Android app and seen no success. (All of this would be abrogated, at least in scenarios identical in practice to mine, by bluetooth support finally landing, which I'm *also* looking to try out this week although I know it's far from actually ready yet.) -- You are receiving this mail because: You are watching all bug changes.
[kdeconnect] [Bug 330536] Bluetooth device link
https://bugs.kde.org/show_bug.cgi?id=330536 Keith Zubot-Gephart changed: What|Removed |Added CC||keit...@gmail.com --- Comment #23 from Keith Zubot-Gephart --- So is there any progress on this becoming stable? Thanks to the reliance on UDP broadcasts I can't use kdeconnect at work, and bluetooth would largely solve that, so I've been anxiously awaiting this! -- You are receiving this mail because: You are watching all bug changes.
[kdeconnect] [Bug 375644] Unable to pair kdeconnect when connecting via OpenVPN, even if specifying hostname or IP address
https://bugs.kde.org/show_bug.cgi?id=375644 Keith Zubot-Gephart changed: What|Removed |Added CC||keit...@gmail.com --- Comment #7 from Keith Zubot-Gephart --- Created attachment 109920 --> https://bugs.kde.org/attachment.cgi?id=109920&action=edit logcat output while hitting refresh in the Android app -- You are receiving this mail because: You are watching all bug changes.
[kdeconnect] [Bug 375644] Unable to pair kdeconnect when connecting via OpenVPN, even if specifying hostname or IP address
https://bugs.kde.org/show_bug.cgi?id=375644 --- Comment #6 from Keith Zubot-Gephart --- (In reply to Matthijs Tijink from comment #5) > I think the problem might be that connecting to a server which is remotely > connected through VPN is impossible (after all: how should the VPN know > which remote VPN connection it should go to?). KDE Connect works by sending > an UDP broadcast as you mentioned, and direct UDP packets to the configured > ip addresses (only on Android). The other device reacts by setting up a TCP > connection to the source of the UDP packet. So both devices act like a > server in this setting up process. I hope it's somewhat clear what I mean. Sure, but everything there except for the UDP broadcast works completely fine via the VPN connection; I can send TCP and UDP packets between remote and local machines just fine using their addresses, and I can't see what the UDP broadcast could possibly be for other than discovering the addresses to potentially send to; if you tell it precisely the address, why not use that address? Figuring out where to route the traffic to when given an address to use is the networking stack's job, not the software's job. And in my testing, manually sending UDP packets over the VPN to specific addresses has worked fine. Anyways, though, I've given your testing steps a shot---thanks very much for bringing that up, I should have thought of that myself! My initial finding is that I see the following error from kdeconnectd twice whenever I hit "refresh" on the Android app: kdeconnect.core: Fallback (1), try reverse connection (send udp packet) "Connection refused" I'll attach the logcat output from the same brief timeframe. -- You are receiving this mail because: You are watching all bug changes.
[kdeconnect] [Bug 375644] Unable to pair kdeconnect when connecting via OpenVPN, even if specifying hostname or IP address
https://bugs.kde.org/show_bug.cgi?id=375644 --- Comment #4 from Keith Zubot-Gephart --- It's not just a matter of UDP. I can communicate via UDP between clients on the VPN and computers physically on the network being connected into. For instance, if I run a UDP iperf server instance on a PC in the office, a remote computer connecting via our VPN (which is specifically: OpenVPN, device TUN, protocol TCP) can connect to it just fine. The problem would appear to be that TUN doesn't support broadcasting across subnets, and KDE Connect apparently uses UDP broadcasting; see https://community.kde.org/KDEConnect#I_have_two_devices_running_KDE_Connnect_on_the_same_network.2C_but_they_can.27t_see_each_other. So yes, the VPN does not route these *specific* UDP packets, even though UDP is supported in general, but it's weird to me that this is a problem. What is the point of being able to specify addresses if it will refuse to try those and rely on the same UDP broadcasting approach to discover other instances anyways? -- You are receiving this mail because: You are watching all bug changes.
[kdeconnect] [Bug 375644] Unable to pair kdeconnect when connecting via OpenVPN, even if specifying hostname or IP address
https://bugs.kde.org/show_bug.cgi?id=375644 --- Comment #1 from Keith Zubot-Gephart --- Addendum: I have tried connecting both my home PC and my Nexus 6P to my work VPN. As long as both are "physically" (somewhat figurative in the case of the phone, but you know) on my local LAN, then they still see eachother, regardless of their respective states in regard to the VPN. If I disconnect my phone from my home wireless yet still connect it to the work VPN, they cease seeing eachother through KDE Connect. Everything else I can think to try (ping, ssh, sftp) acts as expected, ie. works if they're ostensibly connected to the same network via the VPN (or are both not connected to the VPN but via my home network) and doesn't work if one is connected to the VPN and the other isn't. What dark sorcery is at work here? (Or alternatively---as it is I who runs the work OpenVPN instance---what weird edge case with OpenVPN+kdeconnect could I be running into here in terms of failing to actually route traffic through the VPN?) -- You are receiving this mail because: You are watching all bug changes.
[kdeconnect] [Bug 375644] New: Unable to pair kdeconnect when connecting via OpenVPN, even if specifying hostname or IP address
https://bugs.kde.org/show_bug.cgi?id=375644 Bug ID: 375644 Summary: Unable to pair kdeconnect when connecting via OpenVPN, even if specifying hostname or IP address Product: kdeconnect Version: 1.5 Platform: Kubuntu Packages OS: Linux Status: UNCONFIRMED Severity: normal Priority: NOR Component: android-application Assignee: albertv...@gmail.com Reporter: keit...@gmail.com Target Milestone: --- Tested with version 1.0.3 from the Kubuntu backports PPA. Phone is a Nexus 6P running up-to-date Android (7.1.1, Jan 5 security patches). For the Android app, I have tested version 1.4.4 from F-Droid, and the current Play Store beta of 1.5 (Dec 17, 2016 is the updated date I see on the Play Store). On my home system (running yakkety), this works fine (with a caveat I'll get to below). However, at work (running xenial) where our WiFi is not the same LAN as our wired LAN and thus I connect via OpenVPN, my desktop and phone never see eachother. I would have assumed this could be mitigated by manually specifying the IP address or hostname to connect to in the Android app, but this causes no change in behaviour. In fact, bizarrely enough, connecting to my work VPN while at home, my 6P appears to remain paired with my home PC, and even receives pings from it! Is there any way to get kdeconnect to respect my intentions vis-a-vis network traffic routing? -- You are receiving this mail because: You are watching all bug changes.
[systemsettings] [Bug 340982] I cannot set my short date to YYYY-MM-DD, nor my time to HH:MM
https://bugs.kde.org/show_bug.cgi?id=340982 --- Comment #99 from Keith Zubot-Gephart --- That seems surprising to me, since although I find it weirdly difficult to find a direct list, the CLDR website links in turn to lists that include "English (Denmark)". On http://www.unicode.org/cldr/charts/29/ they even say "ICU does not contain all of the data in CLDR" when linking to the ICU which lists "English (Denmark)", which implies that CLDR is a superset of ICU. The comment you have linked to does not explain *why* en_DK is not included in the CLDR database. On Tue, Aug 2, 2016, 07:54 Erik Quaeghebeur via KDE Bugzilla < bugzilla_nore...@kde.org> wrote: > https://bugs.kde.org/show_bug.cgi?id=340982 > > --- Comment #98 from Erik Quaeghebeur > --- > (In reply to EMR_Kde from comment #97) > > > > Interesting, KDE doesnt even support en_DK locale ... > > > > Yet, KDE defaults to en_US... so what is it? either you honor the > locale, or > > allow us to change it like back with kde4 > > Already covered earlier in Comment 77: > https://bugs.kde.org/show_bug.cgi?id=340982#c77 > (Please try and avoid adding to this report about things that have already > been > covered…) > > -- > You are receiving this mail because: > You voted for the bug. > You are on the CC list for the bug. -- You are receiving this mail because: You are watching all bug changes.
[systemsettings] [Bug 340982] I cannot set my short date to YYYY-MM-DD, nor my time to HH:MM
https://bugs.kde.org/show_bug.cgi?id=340982 Keith Zubot-Gephart changed: What|Removed |Added CC||keit...@gmail.com --- Comment #85 from Keith Zubot-Gephart --- (In reply to tdyzio from comment #84) > To me, this thing sounds like someone funding KDE5 development is forcing > the issue against the rest of us. As far as I can gather, it's rather the opposite. That is to say, without more funding---and for various other practical and well-intentioned reasons---it's generally better when possible to stick with upstream rather than complicating things with additional solutions atop of the upstream stack. Unfortunately in this case, QLocale is pretty dramatically inferior to KLocale for any of us (myself very much included) who can't stand the "correct" date and time formats for our locales and have years-bordering-on-decades of relying on the ability to customize this. The hope is that someone steps up with usable patches for QLocale, and that the Qt folks accept them. Unfortunately I, like most of the people balking at this regression, don't have anywhere near the programming skill to reasonably provide such code. But lacking that, we wait in perpetuity. -- You are receiving this mail because: You are watching all bug changes.
