Debugging, PKGBUILD, Theme and issues with connection #45
Comments
Humn, I haven't seen that, although I don't really "test" the deployed images past checking that they work. I was running it for 12 hours last night and it was just running fine. Does it happen with a non appimage version (i.e build from source)? If it's AppImage only it might be difficult to trace quickly due to the way AppImages work. Can I also confirm that you're trying one of the latest releases, there was a leak with socket handles a while back which only really seemed to cause problems on macOS as far as I could see.
What operating system? The dark mode that's built into the app is dependant on macOS. If other operating systems support dark mode, then I can look to add the support in. There's a few instances of ThemeSupport throughout the project that would need to be modified to add the required support, as it stands if you forced it to dark mode on an OS that doesn't support dark mode then you'll end up with something that is a mix of light and dark and probably not looking very pretty.
ArchLinux is not something I use, I can install a VM and take a look though. I'm not familar with PKGBUILD though, sorry.
This happens to be on one of the hops from my ISP, the router appears to drop packages. You can test if this is the case by opening 2 terminals in linux, and then running the following command in each:
WHere the 2 is the HOP number that you are seeing packet loss on. If I run 1 ping, it works fine. But as soon as I add in a second ping, the hop stops responding in one of the terminals, it then does this until you stop one of the pings. Ocassionally, the timeouts witll switch between the terminals, but only 1 will respond at any given time.
I'm on DOCSIS so it's entirely possible as I see the same issue.
No worries. |
|
Just to add, it should be fairly easy to create a build environment for the application on arch. I'm just installing arch, but essentially you need to install git cmake and the qt5 development libraries. There may be a couple of other things that need installing, but it should give you enough hints during the cmake command to tell you what you need to install. |
|
@sxiii You can set up an arch installation to be able to compile from scratch: Then in your home folder (or wherever the source is to be kept): You can set the raw socket capabilities on the generated binaries which allows you to use the better ping engine by running the following command from the root of the git clone. And you can then run it with the following command: |
|
The python3 dependency is for the deployment script, if you are looking to create a packaged version of pingnoo, then you will need to study this script (and the ones in the pingnoo_support_python folder and create a new Linux deployment target of "arch". The deployment script runs autonomously and generates the deployable image without and user interaction, everything is passed into the deploy.py via command line switches. This is because packaging for each and every platform is a time drain without doing it via the script, my CI system (TeamCity) runs every build on all target platforms and then notifies be when it's finished and supplies me with images ready to upload to GitHub, it saves me a lot of time and reduces the chance of errors. |
|
I've added the instructions for arch Linux under docs/build/arch.md |
|
@sxiii I've completed most of the work on the actual packaging side for arch Linux, I need to add support for it in the deployment script though. |
I've got also my AppImage working for hours. This problem actually arises if I try to run like 2 or 3 test at the same time. I haven't tested that with non-appimage version because the built-from-source version failed to even start scanning for me. The version I'm using for all tests is Pingnoo.2021.03.21-develop.x86_64.
Manjaro basically. But I can test as well on other Arch-based distros as well (Garuda, EndeavourOS etc.). I do have dark theme everywhere enabled by default and the compiled-from-source version appreciate that and boots dark theme MOSTLY, I think it's all dark with exception of top-ribbon.
PKGBUILD's are basically the same as pure clean bash (scripts) with some default variables and functions, that allows all the ArchLinux (AUR) community to auto-build and pack all the programs out there. Pretty neat. Not much (if any) additional time needed to understand PKGBUILD.
Sadly, i got: Thanks for your fast and precious answer! |
I think you basically can reach the same goal not doing this step by step: Also wget, dbus and python3 are usually preinstalled out of the box (AFAIK) on Manjaro and a lot of other Arch-based distros with GUI. Python3 is default in here for long time. UPD: Thanks for the overall instructions, I will try to incorporate the Cmake of your recommendation into PKGBUILD and see where this leads. Thanks also for the docs and deployment script, this seems to be soon possible to add into AUR when we finish testing and then you have official support of 10+++ Arch-based distros, which are ones fastest on the market. P.S. Additional short intro into PKGBUILD. Take any Arch-based distro. You first download the PKGBUILD file in empty directory (let's say ~/pingnoo). Enter this dir with terminal, then just run So basically I take all the files from bin/x86_64/Release/* and put them into new folder /usr/share/pingnoo. But I will need to research where should I actually put which files. |
|
Update: YAY! Thanks! Your procedure works! Probably the addition of CMake helped, but I'm not sure fully. Here's the new PKGBUILD file anyways if you like to give it a try:After you put it into empty directory, go there from teminal and just Thanks for your help. I will prepare the package information and upload the file into AUR soon, so all Arch users will benefit. |
|
@sxiii thanks for that. There are a few issues with that package script (although you've got further than I did last night). This is my PKGBUILD. A few notes from me on your script:
If you fix these things and then post the changed script, I will take a look again and give you feedback and if necessary how it worked installing on a clean arch environment. Thanks for your efforts! Also, to point out, you'll also need to look at deploy.py and add support for arch to it as I mentioned earlier, this is critical as it's part of the CI system for ensuring that the application compiles and packages correctly and provides me with an image that I can directly add to releases on GitHub. There's also the issue of gpg keys, signing the package. I have the gpg keys, so will have to build and push to the arch repository myself. |
Yes, you can, but for clarity these are all on their own lines, those instructions are more for my benefit than others, the instructions tell me exactly what I need to do to configure a container that is capable of building Pingnoo via my TeamCity CI server.
Don't assume anything, you need to add all dependencies otherwise somebody somewhere will say "it doesn't work". My testing environment for Arch does not have these packages installed, it's a Linux container and is the one that will be used to build the package, so those dependencies need to be there otherwise the build won't work.
all files need to be where they are after the build, i.e the libraries (things like libICMPPacket and so on) live next to the Pingnoo binary. There's a folder at this level called "Components" which is where the plugins live, Pingnoo expects (on linux) that the Components folder is in the same folder as the Pingnoo executable. Additionally (off the top of my head, you can verify this by looking in the application main.cpp) there are some other folders which it may use to check for plugins, specifically in the users home folder. This allows the user to install plugins without needing root privileges. |
|
@sxiii regarding the light ribbon, what window manager are you using? If I can find out how to read the light/dark state then I can switch the GUI to use dark mode, I will have to write extra code and move themesupport into it's own library (I had plans to do this anyway) as it's duplicated in a few places. |
Try with the latest source code, I have made changes to the ping engine and route engine, there were issues with the route engine when running > 2 tests which I've fixed.
From you executing ping from a terminal? If so, that's your firewall dropping ICMP packets.
|
|
Hmm your PKGBUILD is way smaller and cleaner than mine... This is mine current version:I've added all the stuff and it seems it works more or less okay but yes you're right it shouldn't have sudo and there are some issues. Like I have to symlink the program myself after building, the symlink from PKGBUILD does not work for me for some reason: I'd be really happy if you could push pingnoo to AUR yourself, also, please note that in this case you will also need to add .SRCINFO file in the same directory where PKGBUILD will be to successfully push everything: And then you could push it. I'd be happy to try & test your PKGBUILD from AUR as soon as it's ready and rate your package! |
Mine was unfinished, I hadn't done the actual packaging part only the build! 📦 There are still issues with the script you just posted, as I mentioned above, depends is wrong and makedepends is missing, cmake doesn't need to be downloaded at the build step. The version needs to be generated from git. A mix of what I did and what you've done should give the desired result. |
|
I'm also installing manjaro. |
|
@sxiii I have created a branch and pushed what I've been working on. https://github.com/nedrysoft/pingnoo/tree/feat/arch
I need to copy the desktop entries so that the resulting installation is integrated into the desktop. |
|
@sxii regarding dark mode, I've created an issue. I will add support for operating systems other than macOS. Under macOS I use the cocoa API to discover and react to theme changes, however it's much more complex on Linux, there's a hacky cheat way which I will add initially which will be labelled "System", you'll be able to select: "System" <- hacky detection, probably will work in most situations |
|
@sxiii btw I'm happy to give you credit for this once we've finalised it! |
|
I just pushed more changes, now it creates the desktop entry so after installation it's integrated into the desktop. |
|
@fizzyade You're my hero :)) Thanks! I'll review your new branch right away! |
|
Took your first part and combined with my package(). Fixed small typos and stripped unneeded rows. Also took the Arch branch. Here's what I got:Builds for me, the result is 6mb file, installs fine. No desktop icon, though. |
|
make install does nothing, in pingnoo "make install" creates a deploy images. /usr/share is for data, not binaries. You need to pull my version and try that, I tested it on manjaro, so no idea why base-devel is causing you problems. The stuff to do with ldconfig is critical, as is pingnoo.install which invokes ldconfig and also does setcap |
Aha, well. Should remove that
I know that. However I wasn't able to spread the files into /usr/bin/pingnoo and /usr/share/pingnoo (when I did that, the program couldn't find files and just quit).
Maybe I just need to update my system (doing it now).
Ok I'll check this part right after my update finishes. Thanks! |
this is where the cmake flag -CMAKE_SKIP_RPATH comes to the rescue, along with installing pingnoo.conf and also running ldconfig after installation and uninstallation.
Remove your installation of pingnoo, clone the repo and then go into pkg and run makepkg, the software should build and pop out the package. sudo pacman -U after which you should be able to go straight to the menu in manjaro and find pingnoo installed under internet/networking, it should launch without any issues. I need to fix the precedence of the ping engines when ICMPPingEngine is available, currently it's always picking the command ping engine which is a workaround for AppImage really. Let me know how you get on. |
|
|
it's because it's not in the master branch, go into your clone, then edit the PKGBUILD file: source=("${pkgname}::git+http://github.com/nedrysoft/pingnoo.git") should be: source=("${pkgname}::git+http://github.com/nedrysoft/pingnoo.git#branch=feat/arch") This is purely an issue because I haven't merged the branch in so it pulls from develop but the extra files aren't in develop, just modifying that file to pull from the right branch should fix it. |
Yes I was doing this first with my test file and then forgot to fix in your file, LOL. |
|
Yes, done again from scratch with only branch fix, that works. Icon and everything. :) Both ICMP and Ping scanning, without root, too. The only thing that's left is the dark theme and then I just need to start finally analyze the results I get. Thanks again for the nice work! Hope this will be pushed to the main repo as well as AUR pretty soon! (By the way, you can add the desktop icon and all the additional files in the AUR repo for pingnoo as well). |
|
About pings: got TTL exceeded on all hops (when pinging 1.1.1.1 I have a total of 6) from 1 to 5 ( Also, with latest version, got no packet loss shown (tested for several minutes to an hour or so) to 1.1.1.1, but when I replace it with a domain like yandex.ru, I got 50%-60% losses at my gateway, back again. And same stands when I try hostname of 1.1.1.1, which is "one.one.one.one", I got 100% losses. WEIRD! Might that be KINDA DNS issue? o__o |
ttl exceeded is exactly what you expect to get (or no reply). the -t switch sets the maximum ttl, it's how it figures out the route. To figure out the route and to calculate the latency to a target, we ping the destination with the ttl set to the hop number, we either get a reply of ttl exceeded which tells us the IP of the router at that hop + the round trip time to that hop or we get no reply, in which case that hop is dropping ICMP packets. |
Ok, so there's no issue then in here with that. But why the "1.1.1.1" has no losses while "one.one.one.one" hostname has 100% losses, or yandex.ru has 50-70% losses, is still a riddle to me. Interestingly, when I do |
|
I don't know. pingnoo doesn't care, it does a DNS lookup and then uses the IP address, tracing to 1.1.1.1 or one.one.one.one is exactly the same, no difference. I will try to add support for dark mode on Linux this evening. |
|
Thank you @fizzyade you're really knowledgeable and helpful and you do things fast. :) |
A quick hack.
|
|
@sxiii there is a branch feat/darkmode clone and compile this version. In order to get the dark mode working properly, you will need to add It should hopefully look ok (I haven't tested on manjaro, only on Ubuntu). I need to figure out some stuff with selecting the qt style, on my ubuntu if I use -style=gtk2 then Qt crashes, I have to use It also may not correctly switch colors when the theme is changed while the application is running. |
|
The latest push should try to select the gtk2 theme without having to do the above steps. |
|
@fizzyade fetched the feat/darkmode branch, compiled successfully, and tried to run from the However components are in place. Thought also about taking two branches (feat/arch and feat/darkmode) but I'm frankly don't know how to combine them both into one... |
|
from terminal: export QT_QPA_PLATFORMTHEME=gtk2 i don’t know why you can’t run it. |
|
feat/arch only contains the stuff for packaging, there is no other changes that are relevant in that branch. |
|
I have been unwell today, but I just pulled the code on manjaro, compiled and ran it and dark mode worked as expected. (there are a few text and control rendering issues, spacing and sizing is wrong)
|
|
I have merged the darkmode and arch branches into develop and created an arch test package. https://github.com/nedrysoft/pingnoo/releases/tag/2021.04.03 for some reason, the dark mode doesn't activate as expected, but this version does fix the half dark/half light mode that was occurring in previous releases when the OS was set to a dark theme. you can force it to use the system theme by launching it: and/or right click on the icon in the launcher menu, select Edit Application... and then add: after the application executable, so it reads: It should then launch in dark mode (or light if the OS theme is set). The repo is also set up with my deployment script which creates the package, the PKGBUILD file is actually a template now (PKGBUILD.in) and deploy.py uses the template to generate the correct PKGBUILD file with version, architecture and dependencies which are discovered by the script. |
|
I will sort out the AUR today. |
|
Should now be available in the AUR. |
|
Hi @fizzyade ! Thank you very much for your nice work! Just fetched it from AUR and it compiled without any issues. However, there's several issues, still:
As for dark theme, it seems to be working ok but hard to know without program correctly working :) I will test as well from a different laptop and installation to see if the issue is only on my local machine here or everywhere. Thanks. |
|
@sxiii argh, I know what's going on 0.0.0, the cmake build assumes that the code is checked out from git where in this case it isn't. I'll figure out the best way of fixing this and let you know when there's a fix. Sorry. I switched from git to tarball because of comments on the arch repo, but it's broken the build. |
|
@sxii yeah and because it's 0.0.0 all the components other than core fail to load because they need a later version than that. |
|
@sxii should be working now. |
|
@fizzyade tested everything, running for over an hour, no issues. Dark theme works perfectly. Happy to see everything spins! :) 👍🏻 |
|
Awesome. I'm going to close this issue now, if you have any other issues related to this then feel free to re-open it. Any other issues, thoughts, ideas etc open a new issue. Thanks for your feedback/help/testing on this. |
Greetings dear devs!
First, I hope you don't mind that I decided to make this combined issue, if you prefer, I can re-create separate issue for the confirmed problems as well. So. I have several questions about Pingnoo. Some of these is probably bugs:
3. I've made this PKGBUILD to use the program in ArchLinux/Manjaro/Garuda/EndeavourOS environments:
The program builds and it even start with the proper dark theme. Nice.
But when press "start" button, it drops out with the following (I've run strace to see what's happening):
Probably my PKGBUILD procedure is a little bit wrong in the package() function. Can you give me a hand with these? I would be happy to build a correct PKGBUILD for your package and add it (publish) to AUR, so all users of ArchLinux, Manjaro, Garuda, ando ther Arch-based distros can benefit from that and install your cool software with just one command or even search for the program from GUI. I am also ready to become a package maintainer for ArchLinux version if you teach me how to install the program after compiling for it to correctly work (the package() function in PKGBUILD). Thanks!
a) When I run "ping executable" to 1.1.1.1 with 2.5s intervals, I got 70-80-90-98% packet loss levels at my gateway (192.168.0.1). The screen is full with red stripes. Wow! What is that?
b) When I run "ICMP socket" to 1.1.1.1 with same 2.5s intervals separately, I sometimes got no packet losses at my gateway, but the other times I get same loss levels.
c) When I run both of a) and b) at the same time, I get the packet loss on both tests.
d) I've asked a friend with the same internet to check stuff from her side, and she send me screenshots with the same issues: error packets in the DOCSIS information page, as well as packet loss in "pings" in pingnoo. She also has same modem as me.
So it might be a provider-wide error thing or modem/DOCSIS router dependent thing? Do you see is there any way to further debug these problems? My provider just kicks me away when I'm trying to ask them (Telia/Get internet, Norway).
Thank you very much for these nice program.
The text was updated successfully, but these errors were encountered: