WxWidgets 3.2.0 debian packages for bullseye

[mgrouch]

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:

https://cloudsmith.io/~bbn-projects/repos/bbn-repo/packages/detail/deb/wx3.2-i18n/3.2.0+dfsg-1/a=all;d=debian%252Fbullseye;t=binary/#install

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: https://github.com/OpenCPN/OpenCPN/issues/2396#issuecomment-1197700026

[swt2c]

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

[vadz]

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?

[mgrouch]

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?

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

[mgrouch]

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

[vadz]

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.

[mgrouch]

There is this:

https://github.com/rpatterson/github-apt-repos

so looks like it’s possible to host apt repo on GitHub

[mgrouch]

And also something like this: https://assafmo.github.io/2019/05/02/ppa-repo-hosted-on-github.html

First approach uses release/assets, second one uses github io pages

[mgrouch]

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.

[vadz]

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.

[mgrouch]

Can you set up CircleCi account for wxWidgets organization? And register me as user in it? As a first step.

Thanks

[vadz]

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?

[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.

[mgrouch]

@vadz

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?

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-

and

https://docs.github.com/en/organizations/managing-peoples-access-to-your-organization-with-roles/roles-in-an-organization

[mgrouch]

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

[vadz]

@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?

[mgrouch]

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.

[mgrouch]

@vadz I've created PR now

https://github.com/wxWidgets/wxWidgets/pull/22674

try it.

results of my build

https://app.circleci.com/pipelines/github/bareboat-necessities/wxWidgets/124/workflows/c94ef5ab-f4c9-4a54-9f67-d45dbd49bc75

https://app.circleci.com/pipelines/github/bareboat-necessities/wxWidgets?invite=true

Thanks

[mgrouch]

@vadz

Here is a better pull request

https://github.com/wxWidgets/wxWidgets/pull/22675

Thanks

[swt2c]

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?

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.

[mgrouch]

@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.

[ojwb]

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

[vadz]

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.

[mgrouch]

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.

[mgrouch]

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.

The cost of finding bugs increases exponentially as you go into next stage of production. So most needs to be weeded out in development before the release.