truf's questions

Estou tentando construir um deb de acordo com o https://packaging.ubuntu.com/html/packaging-new-software.html
Tudo estava funcionando há 6 meses. Agora quando executo: bzr dh-make hello 2.10 hello-2.10.tar.gzestou recebendo:

brz: ERROR: unknown command "dh-make"

Eu tentei apt install -reinstall: bzr, bzr-builddeb, dh-make
Isso não ajuda. Meus pacotes são:

bzr 2.7.0+bzr6622+brz
bzr-builddeb 2.8.12+brz
devscripts 2.21.1ubuntu1
dh-make 2.202003

$ python -V
Python 3.9.5

Sistema: Kubuntu 21.04

O que pode estar errado e como depurar?

Eu tenho um pacote que pode ser compilado para groovy e xenial. O Ubuntu groovy tem libpng-devque resolve para libpng16. Além disso tem libpng12. Xenial não tem libpng-devou libpng16. Tem apenas libpng12-dev. Não há problema em construir o aplicativo com libpng12 no xenial, mas não quero usar libpng16 no groovy.

Também o xenial's debhelperparece não fornecer debhelper-compat.

Assim eu preciso Build-Depends: debhelper-compat (=9), libpng-dev(>=1.2.0)para groovy e Build-Depends: debhelper (>=9.0), libpng12-dev(>=1.2.0)para xenial.

Minha versão do pacote éapp-1.0-0ubuntu1_i386.deb

O Launchpad parece não permitir a construção da mesma fonte duas vezes no mesmo PPA. Você pode copiar binários entre séries, mas não reconstruir a fonte. Parece que o launchpad ignora a parte "0-ubuntu1" da versão ao tomar essa decisão. Também não permite fazer upload de nenhuma versão menor do que já tem. Portanto, mesmo que eu acabe com algum arquivo dependente de série Build-Depends:- debian/controlnão poderia me beneficiar disso, pois a fonte será compilada apenas uma vez. E eu não quero incrementar a versão do aplicativo duas vezes apenas para fazer backport para xenial.

Existe alguma solução elegante para este problema?

Estou tentando enviar um deb para meu PPA de acordo com este manual:
https://packaging.ubuntu.com/html/packaging-new-software.html
Consigo construir meu aplicativo bzr builddeb -- -nc -us -uce assiná-lo com bzr builddeb -S. Mas a execução de pbuilder-dist groovy build myproject_0.2.8-1.dscin ../build-areafalha.
O log completo está disponível no pastebin: https://pastebin.com/whr6Qsd1

Acredito que o problema esteja na seguinte peça:

Determining if the CXX compiler accepts the flag -fno-keep-inline-dllexport failed with the following output:
Change Dir: /build/myapp-0.2.8/obj-x86_64-linux-gnu/CMakeFiles/CMakeTmp

Run Build Command(s):/usr/bin/gmake cmTC_3ab02/fast && gmake[1]: Entering directory '/build/myapp-0.2.8/obj-x86_64-linux-gnu/CMakeFiles/CMakeTmp'
/usr/bin/gmake -f CMakeFiles/cmTC_3ab02.dir/build.make CMakeFiles/cmTC_3ab02.dir/build
gmake[2]: Entering directory '/build/myapp-0.2.8/obj-x86_64-linux-gnu/CMakeFiles/CMakeTmp'
Building CXX object CMakeFiles/cmTC_3ab02.dir/DummyCXXFile.cxx.o
/usr/bin/c++    -std=c++0x -fno-keep-inline-dllexport   -o CMakeFiles/cmTC_3ab02.dir/DummyCXXFile.cxx.o -c /usr/share/cmake-3.16/Modules/DummyCXXFile.cxx
c++: error: command-line option '-fno-keep-inline-dllexport' is not supported by this configuration
gmake[2]: *** [CMakeFiles/cmTC_3ab02.dir/build.make:66: CMakeFiles/cmTC_3ab02.dir/DummyCXXFile.cxx.o] Error 1
gmake[2]: Leaving directory '/build/myapp-0.2.8/obj-x86_64-linux-gnu/CMakeFiles/CMakeTmp'
gmake[1]: *** [Makefile:121: cmTC_3ab02/fast] Error 2
gmake[1]: Leaving directory '/build/myapp-0.2.8/obj-x86_64-linux-gnu/CMakeFiles/CMakeTmp'



dh_auto_configure: error: cd obj-x86_64-linux-gnu && cmake -DCMAKE_INSTALL_PREFIX=/usr -DCMAKE_BUILD_TYPE=None -DCMAKE_INSTALL_SYSCONFDIR=/etc -DCMAKE_INSTALL_LOCALSTATEDIR=/var -DCMAKE_EXPORT_NO_PACKAGE_REGISTRY=ON -DCMAKE_FIND_PACKAGE_NO_PACKAGE_REGISTRY=ON -DCMAKE_INSTALL_RUNSTATEDIR=/run -DCMAKE_SKIP_INSTALL_ALL_DEPENDENCY=ON "-GUnix Makefiles" -DCMAKE_VERBOSE_MAKEFILE=ON -DCMAKE_INSTALL_LIBDIR=lib/x86_64-linux-gnu .. returned exit code 1
make: *** [debian/rules:6: binary] Error 25
dpkg-buildpackage: error: debian/rules binary subprocess returned exit status 2

Então, cmakeestá verificando se /usr/c++suporta -fno-keep-inline-dllexport. Compilador termina com 1 bcs não suporta, cmake retorna 2 e dh_auto_configure painics.

Se eu executar cmakeno meu sistema, estou recebendo o seguinte stdout:

-- Checking to see if CXX compiler accepts flag -ffunction-sections -fdata-sections -Wl,--gc-sections
-- Checking to see if CXX compiler accepts flag -ffunction-sections -fdata-sections -Wl,--gc-sections - yes
-- Checking to see if CXX compiler accepts flag -fno-keep-inline-dllexport
-- Checking to see if CXX compiler accepts flag -fno-keep-inline-dllexport - no
-- Checking to see if CXX compiler accepts flag -Werror=return-type
-- Checking to see if CXX compiler accepts flag -Werror=return-type - yes

Portanto, mesmo o compilador no meu sistema não suporta arquivos -fno-keep-inline-dllexport. E eu estou bem com isso. Não importa para mim. cmakenão falha.

Parece que a verificação com falha do recurso não obrigatório cmakearruina todo o pbuilder-distprocesso. Existe alguma maneira de mudar esse comportamento ou estou perdendo alguma coisa?

Ps Minhas dependências de construção são:debhelper-compat (= 13), cmake (>=2.8.9), gcc (>=4.6), qt5-qmake (>= 5.4), qtbase5-dev (>= 5.4), libtiff5-dev (>= 4.0.3), libjpeg8-dev (>= 8c), libpng-dev (>=1.6.2)

Estou tentando empacotar um aplicativo Qt 5.x conforme descrito em https://packaging.ubuntu.com/html/packaging-new-software.html
Meus Build-Depends no debian/controlarquivo são:
debhelper-compat (= 13), libqt5widgets5 (>=5.4), libqt5xml5 (>=5.4), libqt5gui5 (>=5.4), libqt5core5a (>=5.4), libtiff5 (>=4.0.3), libjpeg8 (>=8c), libgcc1 (>=1.3.0), libc6 (>=2.14), libpng16-16 (>=1.6.2-1), libstdc++6 (>=5.2)
Estou construindo deb combzr builddeb -- -us -uc

Infelizmente, o processo de compilação falha porque ele tenta iniciar os casos de teste após a compilação binária e um deles está travando. O caso de teste usa QPainterque requer uma instância de QApplicationpara funcionar. E parece que o aplicativo trava na criação de arquivos QApplication. A saída é:

qt.qpa.xcb: could not connect to display 
qt.qpa.plugin: Could not load the Qt platform plugin "xcb" in "" even though it was found.
This application failed to start because no Qt platform plugin could be initialized. Reinstalling the application may fix this problem.

Available platform plugins are: wayland-org.kde.kwin.qpa, dxcb, eglfs, linuxfb, minimal, minimalegl, offscreen, vnc, wayland-egl, wayland, wayland-xcomposite-egl, wayland-xcomposite-glx, xcb.

Então, meu palpite é que o bzr está tentando executar o aplicativo em algum ambiente limpo que é feito com base na minha lista Build-Depends. E esta lista perde algo que é exigido pelo qt5/plugins/platforms/libqxcb.so.

A questão é: o que pode ser e como rastrear isso?
Eu posso executar lddna minha máquina, mas preciso dele em ambiente bzr.

Aqui está o log de compilação https://pastebin.com/BVbZVwr6 Eu cortei um meio do processo de compilação para ajustar os limites de tamanho da pasta. Mas a compilação está bem, é fazer teste que falha. O código das provas está aqui: https://cutt.ly/BgYQITO