WxWidgets 3.2.0 debian packages for bullseye (Issue #22672)
Mikhail Grushinskiy
I've built Debian packages of WxWidgets 3.2.0 for binaries, sources, headers, debug symbols (everything) for Debian Bullseye
using circleci. They do have arm native support now.
The packages are available for arm64, armhf, amd64.
The source code how it is done is here
https://github.com/bareboat-necessities/wxWidgets
and the packages are uploaded to cloudsmith from circleci automatically
https://cloudsmith.io/~bbn-projects/repos/bbn-repo/packages/?q=format%3Adeb
you can add repo like this:
curl -1sLf
'https://dl.cloudsmith.io/public/bbn-projects/bbn-repo/setup.deb.sh'
| sudo -E distro=debian codename=bullseye arch=arm64 bash
See more cases here:
Try it after Aug 1st. I run out of my free cloudsmith download bandwidth allowance due to popularity of BBN Marine OS which
is also hosted there.
Thanks
More: OpenCPN/OpenCPN#2396 (comment)
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
Scott Talbert
The official Debian packages are also coming soon. The wxwidgets3.2 package is sitting in the NEW queue, awaiting review:
https://ftp-master.debian.org/new/wxwidgets3.2_3.2.0+dfsg-1.html
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
VZ
Mikhail, thanks for building these packages! I'd be glad to link to these packages from our download page, please don't hesitate to make a PR to wxWidgets/website repository changing it.
Also, I wonder if it would make sense to add the Circle CI config file you've used to wx repository itself, so that we could test building the packages before the next release ourselves? @swt2c or do you think it would be confusing to have the files under debian in the main repository (I seem to remember that we had them a long time ago but then removed them at the request of the Debian maintainers)? Perhaps we could have debian-3.2 branch with these files or something like this?
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
Mikhail Grushinskiy
Mikhail, thanks for building these packages! I'd be glad to link to these packages from our download page, please don't hesitate to make a PR to wxWidgets/website repository changing it.
Also, I wonder if it would make sense to add the Circle CI config file you've used to wx repository itself, so that we could test building the packages before the next release ourselves? @swt2c or do you think it would be confusing to have the files under
debianin the main repository (I seem to remember that we had them a long time ago but then removed them at the request of the Debian maintainers)? Perhaps we could havedebian-3.2branch with these files or something like this?
My free cloudsmith account will not be able to handle all the interest to wxWidgets. I think you should just copy my CircleCi scripts somewhere into wxWidgets GitHub and deploy to your cloudsmith or whichever archive hosting you use. You might also cleanup some redundant scripting in my scripts as I used to build arm/arm64 with qemu docker. Now it can be done natively.
Thanks
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
Mikhail Grushinskiy
I think the reason Debian guys asked you to remove Debian package is that they do not like having directory callled ‘debian’ in main source code tree. You can call that directory debian-pkg or other name and use that in CircleCi scripts.
Then there is no conflict
thanks
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
VZ
I'd indeed like to have your Circle CI scripts in our repository but, as always, it would be great if you could please make a PR adding them.
As for hosting, we actually don't use anything other than GitHub, but I don't think you can host an apt repository on GitHub, can you? I wonder what do CodeLite folks use for their packages.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
Mikhail Grushinskiy
There is this:
https://github.com/rpatterson/github-apt-repos
so looks like it’s possible to host apt repo on GitHub
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
Mikhail Grushinskiy
And also something like this: https://assafmo.github.io/2019/05/02/ppa-repo-hosted-on-github.html
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
Mikhail Grushinskiy
Also I came across this opensource project:
https://github.com/ArduPilot/apm_planner
And they do automatic debian packaging for their project quite neat.
By generating debian/changelog on the fly.
cd ~/workspace/apm_planner/debian
./gitlog-to-changelog.pl > changelog
cd ..
debuild -us -uc -d
So via circleci it would be possible to completely automate debian packaging and uploading it back into github
which will host it let's say as some kind of 'deb-apt' release assets.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
VZ
It would be great to have something like this for 3.3 packages (when we get to 3.3.0) but I don't know if I'm going to have time to do it any time soon, so any PRs doing this would be really welcome.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
Mikhail Grushinskiy
Can you set up CircleCi account for wxWidgets organization? And register me as user in it?
As a first step.
Thanks
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
VZ
Can you set up CircleCi account for wxWidgets organization? And register me as user in it? As a first step.
Sorry, I'm not sure how to do it. I've authorized CircleCI to give it access to all my public repositories, including wx, but there doesn't seem to be any way to register another user.
The setup process created circleci-project-setup branch with the "Hello world" config in it, I wonder if you could just make PRs to this branch and if they would run on CircleCI?
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
dghart
I wonder what do CodeLite folks use for their packages.
Nothing modern like CI! I build each package locally, in a VirtualBox guest of the appropriate distro/version; then upload rpms, and add the debs to a reprepro repository.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
Mikhail Grushinskiy
Can you set up CircleCi account for wxWidgets organization? And register me as user in it? As a first step.
Sorry, I'm not sure how to do it. I've authorized CircleCI to give it access to all my public repositories, including wx, but there doesn't seem to be any way to register another user.
The setup process created
circleci-project-setupbranch with the "Hello world" config in it, I wonder if you could just make PRs to this branch and if they would run on CircleCI?
Hmm. It seems it just inherits permissions from github. Probably organization names have to match as well.
See:
https://support.circleci.com/hc/en-us/articles/360034990033-Am-I-an-Org-Admin-
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
Mikhail Grushinskiy
What if you create a branch for me in WxWidgets project with .circleci directory and simplest "hello world" config.yml in it?
And run one build pipeline in circle CI with it.
I'd need github permission to commit only into that branch.
Did you run al least one pipeline on circleci with what it generated by default?
This https://app.circleci.com/pipelines/github/WxWidgets
gives me page not found.
Thanks
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
VZ
@dghart If we could have a Github Actions workflow or its equivalent in any of the other CI providers (Circle, Cirrus, anything except Travis really) doing this, it would be great, please don't hesitate to contribute if you have anything like this, even if it's not perfect.
@mgrouch The correct URL is https://app.circleci.com/pipelines/github/wxWidgets/wxWidgets Have you tried making a PR to this branch?
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
Mikhail Grushinskiy
I'll try to make more proper set up in my fork before doing PR from it. Currently I've just set it up to build one particular version.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
Mikhail Grushinskiy
@vadz
I've created PR now
try it.
Thanks
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
Mikhail Grushinskiy
Here is a better pull request
Thanks
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
Scott Talbert
Mikhail, thanks for building these packages! I'd be glad to link to these packages from our download page, please don't hesitate to make a PR to wxWidgets/website repository changing it.
Also, I wonder if it would make sense to add the Circle CI config file you've used to wx repository itself, so that we could test building the packages before the next release ourselves? @swt2c or do you think it would be confusing to have the files under
debianin the main repository (I seem to remember that we had them a long time ago but then removed them at the request of the Debian maintainers)? Perhaps we could havedebian-3.2branch with these files or something like this?
TBH, I'm not sure about having a debian directory in the upstream repository. Downstream, we would probably have to remove it, as we currently maintain the official Debian packaging on Debian's VCS, salsa.debian.org (a GitLab instance, see: https://salsa.debian.org/freewx-team/wxwidgets3.2). Some Debian packages do maintain their packaging files in upstream repositories, but by and large, most packaging is maintained on salsa. CC'ing @ojwb for additional opinion.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
Mikhail Grushinskiy
@swt2c
This was preliminary PR to illustrate how builds are done in circle CI. Later you could remove Debian directory and download it in circleci yaml script and unarchive over your source base. This PR only illustrates how to build and upload to cloudsmith for 3.2.0 release only.
In comments above there is example how to modify debian/changelog to make the build continuous.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
Olly Betts
It used to be the case that if the upstream tarball contained a debian directory then it would have to be repacked to be usable as the basis for a package in Debian. This was really just a tooling issue, and I'm pretty sure it was fixed some years ago (by the "3.0 (quilt)" source format IIRC).
My suggestion to drop the debian directory from the the upstream sources was also some time ago now - 2013 it seems, which is after the new source format - I suspect it was just because it had become so outdated that it wasn't useful to anyone.
I have some reservations about 3rd-party packages for Debian of software that I'm involved with maintaining in Debian though, mainly because it's likely I'll end up having to deal with bug reports about them, and sometimes those can waste significant time and effort before it emerges the reporter is actually using some other package of the software.
If there's demand for wx3.2 for Debian bullseye, we can provide a backported package via backports.debian.org once the package reaches testing, which would mean there's a clean upgrade path to the next Debian stable release. It would also be available for all architectures rather than a subset.
We had a backport of wxwidgets3.0 for stretch, but releases have been so infrequent lately that stable (bullseye) has the latest version anyway - even oldstable (buster) is only one point release behind:
wxwidgets3.0 | 3.0.2-1 | oldoldoldstable | source
wxwidgets3.0 | 3.0.2+dfsg-4 | oldoldstable | source
wxwidgets3.0 | 3.0.4+dfsg-4~bpo9+1 | stretch-backports | source
wxwidgets3.0 | 3.0.4+dfsg-4~bpo9+1 | stretch-backports-debug | source
wxwidgets3.0 | 3.0.4+dfsg-8 | oldstable | source
wxwidgets3.0 | 3.0.5.1+dfsg-2 | stable | source
wxwidgets3.0 | 3.0.5.1+dfsg-4 | testing | source
wxwidgets3.0 | 3.0.5.1+dfsg-4 | unstable | source
wxwidgets3.0 | 3.0.5.1+dfsg-4 | unstable-debug | source
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
VZ
Personally I think it would be very useful to have 3.2 for bullseye, but I can't judge the demand for it, of course.
My preference for having debian in the main repository is mainly due to the fact that I'd like to use these files to make unofficial 3.3.x releases, which are not going to be included in any Debian release. For 3.2.x it's not that important, especially if it's available in the backports.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
Mikhail Grushinskiy
BTW WxWidgets 3.2.0 failed to build for buster. Failed in configure script.
Although I was able to build it on buster raspberry by hand.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
Mikhail Grushinskiy
I think release should happen when beta packages on all major platforms are tested. For that you need continuous build of those
test packages. 3.3 and 3.2 branch both would benefit from such continuous build and package process.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.