Uh oh!
There was an error while loading.Please reload this page.
- Notifications
You must be signed in to change notification settings - Fork473
Add a Linux system packaging backend#1106
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 ourterms of service andprivacy statement. We’ll occasionally send you account related emails.
Already on GitHub?Sign in to your account
Uh oh!
There was an error while loading.Please reload this page.
Conversation
philsuth commentedFeb 23, 2023
I gave it a test using your process above on Linux Mint 21.1 Vera, and got "doesn't know the system packaging format for linuxmint" error. If I specified ubuntu:jammy target then it all worked, and the resulting deb could be successfully installed and run. |
freakboy3742 commentedFeb 24, 2023
@philsuth Thanks! I've just pushed an update that should now include Linux Mint (and Pop! OS) identification; can you confirm if that now works for you at the packaging step? (re-running the briefcase |
philsuth commentedFeb 24, 2023
I can confirm that after the update the packaging ran successfully on Mint 21.1. Very neat! |
eigenwijsje commentedFeb 24, 2023
I can confirm that it identifies my Ubuntu 22.04 correctly, the generated package can be installed and the application starts. |
rmartin16 commentedMar 7, 2023
I think it's a footgun because at some unknown point in the future, it will no longer produce a |
rmartin16 commentedMar 7, 2023
Targeting Arbitrary Architectures However, Docker allows running images for arbitrary architectures via (I'll try to move my out-of-scope ideas in to enhancement tickets sometime this week.) |
freakboy3742 commentedMar 7, 2023
Can't argue with this as an idea. Although the vast majority of Linux installs are x86_64, it would be nice to be able to build a Raspberry Pi package from my x86_64 CI machine, for example.
👍 |
rmartin16 commentedMar 7, 2023 • edited
Loading Uh oh!
There was an error while loading.Please reload this page.
edited
Uh oh!
There was an error while loading.Please reload this page.
RHEL Build ReqsThe base image for Of note....this only isn't a problem for PySide6 App
I put together the list below based on the Qt'srequirements for X11....and trial and error on I tried the same thing on Also, in case anyone finds it useful: Script to start Docker with X11 access#!/bin/bashif [-n"$1" ];then IMAGE="$1"else#IMAGE="debian:bullseye"IMAGE="ubuntu:jammy"#IMAGE="linuxmintd/mint21.1-amd64"#IMAGE="fedora:38"#IMAGE="kalilinux/kali-rolling"fiXSOCK=/tmp/.X11-unixXAUTH=/tmp/.docker.xauthxauth nlist$DISPLAY| sed -e's/^..../ffff/'| xauth -f$XAUTH nmerge -docker run --rm -it -e DISPLAY=$DISPLAY -e XAUTHORITY=$XAUTH -v$XSOCK:$XSOCK -v$XAUTH:$XAUTH -v$(pwd):/local$IMAGE |
freakboy3742 commentedMar 7, 2023
Agreed it doesn't hurt to be explicit; I've added gcc, make and pkgconf-pkg-config as explicit system requirements for RHEL base machines.
I'll add these to the briefcase template, but... "Alexa, how do you spell 'we don't want you to use Qt'?" :-)
It's worth noting that Fedora 38 hasn't been released yet; 36 and 37 are the only two officially supported releases. I don't know if that might have contributed to the problem. I'll have a quick poke to see if I can see anything obvious; however, I'm somewhat comfortable landing this without full PySide support, especially if (yet again) the issue is incompatibilities with PySide packaging. |
freakboy3742 commentedMar 7, 2023
Update: It wasn't a fedora 38 problem :-)
@rmartin16 FYI. I'm about to land#1107, which will involve a bit of a merge; but won't change anything functional here. |
rmartin16 commentedMar 8, 2023
I think this may be more of a function of |
rmartin16 commentedMar 8, 2023
As a PoC, I updated the This mitigated the Nonetheless, I would expect this problem to potentially encompassany Python package that's bundling its own libraries. |
freakboy3742 commentedMar 8, 2023
I mean - we can probably excludeall the app and app_packages folders - after all, they're supposed to be manylinux wheels, and if there are any dependencies, they should be being declared by As for the segfault - is there any other processing going on? I've discovered through AppImage and Deb packaging that manylinux wheels really don't play well if they're futzed with after being packaged. |
rmartin16 commentedMar 8, 2023
That's probably the best approach....at least for now. Additionally, though, this probably needs to be done for Although, that's a bit unfortunate because this auto-dependency magic that List of packages automatically pulled in
All of the And the helloworld PySide6 app properly launched from my |
freakboy3742 commentedMar 8, 2023
I think that's my read as well - I've added both these lines in.
Yeah - that list is... a little enthusiastic, to my reading. There's a whole lot of GTK dependencies that definitely aren't needed. We might be able to get a better list from the actual Qt RPM packages...
Ok - I've added those lines in as well. I've also finisehd merging the build-list changes, so I think we're at |
freakboy3742 commentedMar 8, 2023
On a vaguely related, but indepdendent note - OMG there's a whole lot of noise in the PySide package... Why the hell does awheel contain all the example code and documentation?! There's some room for some major optimisation with a |
Uh oh!
There was an error while loading.Please reload this page.
Uh oh!
There was an error while loading.Please reload this page.
Uh oh!
There was an error while loading.Please reload this page.
rmartin16 commentedMar 8, 2023
Yeah....with no dependencies listed for the PySide6 HelloWorld app, I was able to get it running after
ha, yeah, no joke; when we were trying to clean some things up for Flatpak inbeeware/briefcase-linux-flatpak-template#14, I remember seeing somewhere a whole list of files and directories being deleted from PySide6 after installing the wheel....although, I can't find it now.... |
freakboy3742 commentedMar 9, 2023
🎉 Thanks so much for all your testing and assistance on this@rmartin16. Couldn't have done it without you. |
Uh oh!
There was an error while loading.Please reload this page.
Adds a generic "Linux System" packaging backend, with (for now) support for Debian and RPM packaging.
Fixes#1062.
Fixes#1063.
Refs#1064.
Testing tl;dr
To test this PR, on any Linux distribution, run the following at a shell prompt:
Accept the default values for all questions, then:
An app should start showing an empty window. Then run:
If you're on a Debian-derived OS, this should generate a
linux/helloworld_0.0.1-1~<your distro>.debfile that you can install. If you're on a Redhat derived OS, there will be alinux/helloworld-0.0.1-1.<distro tag>.x86_64.rpm. Arch derivatives will raise an error that the backend isn't supported at this point (patches welcome - see#1064).This is a rework of#1081. Instead of treating Debian packaging as a unique backend, it treats "native system packaging" as a distribution type, and adds
debandrpmas packaging formats. In future,pkgand other packaging formats could be added to satisfy other distro packaging.Even without packaging support, Arch users can use the create/build/run parts of the Briefcase experience. It also means that Docker isn't needed for the default builds - Docker is only needed if you want to package for a distro other than your current distro. For that reason, this PR modifies the default Linux backend to be this new backend.
There is a
linux-systembranch onbriefcase-template, plus a newbriefcase-linux-system-template for apps.To test this, clone the briefcase-template locally, then run:
(substituting the path to your template).
If you're onany Linux, you should then be able to run:
and see the running app.
If you're on a Debian- or RPM-based distro, you can run:
If you're on any other Linux distro, or macOS, and you have Docker, you can run:
to build a package for a specific distro;
ubuntu:jammyis the vendor and codename of any distribution that has a Docker image (so -debian:bullseye,ubuntu:focal, andfedora:37will also work).The packaging commands will drop a
.debor.rpmfile in yourlinuxdirectory, as appropriate. You can then runsudo apt install -f <name of deb pkg>orsudo rpm -i -f <name of rpm pkg>to install the app. On installation, the app should appear in your desktop menus.The code is fully tested and documented; there are two areas which might need more work:
Linux system identification. I've done what I can based on Docker and Parallels checks; this PRshould identify any distro from Debian, Ubuntu, Linux Mint, Pop! OS, RedHat, Fedora, Centos, AlmaLinux, Arch or Manjaro. Itmay work on other distros; however, I'm limited by what I can test locally. I'm interested in any reports on the failure modes of these (or other) Linux distributions.
Non Toga apps. I haven't done a lot of testing for non-Toga apps yet. PySide apps appear to build without any additional build-time requirements; I'm not sure if there are runtime requirements (it appears like there may not be any). The good news is that the only changes hereshould be the list of system packages needed to compile and run those apps.
This PR also has a chicken-and-egg relationship withbeeware/.github#14 - This PR won't include app verification tests in CI until the PR on .github has landed; but that PR can't land until Briefcase supports system packages.
PR Checklist: