-
-
Notifications
You must be signed in to change notification settings - Fork 113
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
feat: add deb and rpm package #198
Comments
i second this, the flatpak version is not usable on ubuntu - slow as hell at refreshing changes in my repos(on disk) example project that uses it: https://software.opensuse.org/download.html?project=home%3AAlexx2000&package=doublecmd-gtk |
Yes there should be deb and rpm (and other distro) packaging. No it should not be part of this repository. Distro packaging should be managed using distro tooling not part of upstream projects. That being said, I've tried several times to get Arch Linux packaging setup, but this project layout makes it VERY hard to do. What I believe this project should do is fix the build system so that it does not assume everything is vendored and bundled. It should support normal methods (such as There has been some progress in this direction and even some currently open PRs headed that way (e.g. #191), but more work is needed. |
@Murmele @exactly-one-kas what about create portable version like in old |
@micpub How did you verify if the native package is much faster or it might be a problem with Gittyup in general? @long76 This might be possible, but one has to setup it again. I don't see a benefit of AppImage over flatpak. There must be a maintainer for this. Currently we have three packages (win, flatpak, macos) we have to handle. We would not handle more because it is a lot of effort |
for example:
|
if you know answer why C++ faster than Java then it the same |
The problem is the maintenance effort of such packages. We decided to use flatpak, because I can maintain it and it is cross distribution capable. So I maintain one package for complete linux. If there is someone which is maintaining the appimage package we will add it to the repository CI so it will be created automatically. |
The difference is that the flatpak does not run in a virtual machine, but native. So there should not be a performance difference. |
|
if you do not want maintain AppImage why don't add |
@Murmele after seeing your reply today i started gittyup via flatpak on my linux (i am using gitahead + git(command-line) cause it was impossible to use gittyup) and to be honest it works now - not sure if it was something that was fixed in the flatpak itself or in the gittyup. the speed is still slower than gitahead - opening repo from my disk still freezes ui for some time (like ten secs or so) - gitahead loads it faster. i'll try to use it for some time and will write some more - if i find something. but still as you can see the flatpak can be crazy - i bet it wasnt only for me (i am using ubuntu - nothing fancy) |
@Murmele even selecting files as staged for commit takes longer - can even freeze app for a while. I've had a bigger commt to do and on many files / heavily changed it has a hard time - gitahead / even gittyup on windows works a lot better. given these things i can say that gittyup can be used now(it works atleast) but its troublesome in many cases. |
@micpub can you provide more information about your system, which flatpak version are you using? |
@Murmele - sure, but as i said i use nothing fancy - normal ubuntu mostly up to date (havent switched yet to 23.04) if i missed some info - please tell me. ubuntu 22.10 x86-64 uname -a gnome-shell --version flatpak --version flatpak list ` flatpak info com.github.Murmele.Gittyup
Collection: org.flathub.Stable
` |
@micpub thanks for the info. Maybe this is a problem of flatpak on the Ubuntu system Found this one: https://forums.opensuse.org/t/why-are-flatpaks-that-slow-under-opensuse/151172 |
@Murmele - i've tried that but its the same. The worst part is that how the hell even flatpak can cause thing like these to happen - it shouldnt touch anything that is not related to the installation of the app - its role should end at that part. also i understand that you dont want to create many different types of packages - cause its a nightmare - i also develop an app and distributing to 3 oses where linux has many packages is crazy. |
I'm going to echo the sentiments here with it being unreasonably slow on Linux. Attempting to create a plain repository for an empty Unity3D project is nigh on impossible:
Yes, it's an issue with Gittyup/Flatpak. FWIW: |
Can we please open separate issues for tracking different topics? Flatpack builds being slow is a completely different issue with a different resolution that "should RPM packaging be in this repository". I suggest somebody open that issue, then copy relevant comments there, then mark them as off-topic here. |
@micpub @LCWilliams I see the same problem with the performance on a RHEL 7.9 version (9 years old), with flatpak version 1.0.4 |
@alerque yes and no - cause i for one dont care what type of package that is as long as it works, so if that flatpak would would for me there would be 'no need' for deb / rpm anymore. @Murmele good to know it isnt only ubuntu/mint (debian) related thing, but i wonder if its the very same issue - cause as you said its a 9 years old - and we are using up-to-date distros. |
Just because you are okay with an either/or solution doesn't mean everybody is. Adding deb/rpm packaging will be useful to some people, but others will still want the Flatpak bug tracked and fixed. The issue should be split based on the obvious difference in underlying causes and solutions, and people like you that could benefit from either one can track both. And the rest of is that don't know much about or care about Flatpack can still subscribe to this issue without it being spammy noise. |
Build native for your linuxTested on sudo apt install gcc make cmake ninja-build pkgconf qttools5-dev qtdeclarative5-dev qtbase5-dev git g++ maybe it's full list run bash script in your folder(for example #!/usr/bin/env bash
BASEDIR=$(pwd)
echo "current dir $BASEDIR"
RELEASE_TAG='gittyup_v1.3.0'
ROOT_DIR=$BASEDIR/Gittyup
if [ ! -d "$ROOT_DIR/.git" ]; then
echo 'Not clonned'
git clone https://github.com/Murmele/Gittyup.git $ROOT_DIR -b $RELEASE_TAG
cd $ROOT_DIR
else
echo 'Clonned'
cd $ROOT_DIR
git checkout $RELEASE_TAG
fi
git submodule init
git submodule update
cd dep/openssl/openssl
./config -fPIC
make
cd $ROOT_DIR
mkdir -p build/release && cd build/release
cmake -G Ninja -DCMAKE_BUILD_TYPE=Release ../..
ninja after just run Note i'm not a "master" in git and bash maybe you can write this instruction better |
@micpub can you try this: flatpak/xdg-desktop-portal-gtk#72 |
@Murmele i've tried but regarding the speed nothing changed. its crazy im using linux like 12 years or more and its first time ive seen smth like that. |
I think #198 (comment) addresses the original issue at its core and hasn't been given the consideration it merits so I am quoting it here again.
The last paragraph is the crux: When building from source, for each dependency that is provided by the system:
|
@micpub Can you post the output of the run command with |
@Murmele sure. the log is long though... so ive pasted it to "pastebin" (alternative cause pastebin smart filter found my log 'offensive' lol) https://privatebin.io/?0c9dfc112912fd8b#FKWnmWZt196zZ3johq71ZUqJjsZS4hWuVn9Hy6NJDQCp up to the last 3 lines with "setNativeLocks failed: "Function not implemented"" is a log that prints when the app starts |
Logs
|
just wanted to add here that over the weekend ive upgraded ubuntu to 23.04 (newest) and nothing changed regarding the issues mentioned before.
|
another 'bug' under new ubuntu came up - when gittyup auto updates changed files / clicking refresh button manually its probably the same bug as this or related somehow: not that you(Gittyup) can do something about it - posting it here to 'warn' some ppl about it. btw. gitahead does not cause it to leak - flatpak thing. once again flatpak "delivers" btw. maybe it has something to do with the slowness - as it relates to disk access |
This thread got derailed with "I hate flapak" instead of "I love deb/rpm". If there's a problem with flatpak, maybe that deserves it's own issue? Also, side note: why does the flatpak problem affect some but not others? Deserves a separate thread. |
I started building an appimage, but I did not get it to work yet #579 |
From the artifacts from #579 you get an appimage. Can you test? |
@Murmele it works correctly - starts / loads repo very fast |
not find artifact in pr, you can run ci for generate AppImage? artifact from https://github.com/probonopd/Gittyup/releases/tag/continuous opened but i got error on pull |
You can find them here: https://github.com/Murmele/Gittyup/actions/runs/5513002113?pr=579 just scroll down to the bottom |
thanks! works! pull without error, looks good |
it works flawlessly for a 6 days? or so(without a restart) - ram usage stays the same for me its solved - i dont need deb / rpm - AppImage shall work for everyone. (again ITS FOR ME - saying it again cause some ppl will bad mouth me...) thanks a lot! |
Actually it does not yet perfectly for me. Still have also problems with AppImage. |
anyone with 'modern' (not older than a few years old(8? 10?) distro) - i saw your talk with 'probonopd' - i see that you have problems with RHEL7 - but cmon thats not what common ppl use. also about that daily download count - please take a note that many people will not come here and 'whine' that it is not working(just simply uninstall and call it 'shit') - for example i was also in that number of install - and it wasnt working for me (for a year). switch to qt6 will force you to ditch anything older than windows 10 (1809) again thank you. |
This is your oppinion ;) |
It's a pity that people wanted deb/rpm - that is literally in the title. Then micpub jumped in and hijacked murmele's efforts to change the conversation to flatpak/appimage. May I suggest murmele - if you aren't already tired of this issue - that we keep it open for some time in the future? deb/rpm is still the most common, by far. Up to you, I appreciate the effort, whatever you decide. |
I sympathize with the message above. I would also like a native, much smaller, installer. But maybe its is better to do that work as part of #581 to tackle the issue at the core? |
@lonix1 yes we can still let it open as long as no deb/rpm package exists |
Is there an issue tracking debundling of the remaining git submodules? Big part of the appeal of native packages is that they use system-wide libraries (depend on other native packages). Most of the dependencies currently listed in |
@Murmele Appimage 1.4.0 crash on Kubuntu 24.04
|
|
Why?
Store like Snap, Flatpak uses virtual envirovment for lauch apps. It's much slower than "direct" execution which used after install deb/rpm package. Thanks!
The text was updated successfully, but these errors were encountered: