Bug#1018329: nmudiff

[Ryan Pavlik]

Thanks! Wondering if I should maybe bring this to the Python team.

On Sat, Aug 24, 2024 at 7:33 AM Alexandre Detiste <
alexandre.deti...@gmail.com> wrote:

> Hi,
>
> The repo for the nmu is here:
>
> https://salsa.debian.org/detiste-guest/click-man/
>
> Please import all 3 branches.
>

Bug#1025311: solvespace: missing builds on mipsel and mips64el

[Ryan Pavlik]

Thanks for this advice on how to fix it better and unblock migration!

I've pushed an updated revision to both mentors and salsa. I'll reach
out to the science team for review and sponsorship.

On Fri, Dec 2, 2022 at 6:15 AM Graham Inggs  wrote:
>
> Source: solvespace
> Version: 3.1+ds1-2
> Severity: serious
> Tags: ftbfs
>
> Hi Maintainer
>
> The upload of solvespace 3.1+ds1-2 includes the change 'Drop s390x
> architecture due to test failures' [1], however the way this was done
> didn't only drop s390x, but also mipsel, mips64el, riscv64 and several
> other ports.  The missing builds on mipsel and mips64el now prevent
> migration of solvespace to testing.
>
> Seeing that solvespace builds fine on s390x, if the failing tests
> cannot be fixed, you could skip them on s390x only.  See my proposed
> debian/tests/control file below.  You could also try asking on
> debian-s...@lists.debian.org for help.
>
> Regards
> Graham
>
>
> [1] 
> https://salsa.debian.org/science-team/solvespace/-/commit/660e95c1d4583e078e31c5f91e7cd57f1aa1c7d1
>
>
> Tests: htmlmesh stlmesh surfaces
> Restrictions: allow-stderr
> Depends: solvespace, findutils, grep
> Architecture: !s390x
>
> Tests: thumbnail view wireframe
> Restrictions: allow-stderr
> Depends: solvespace, findutils, grep
>

Bug#1013163:

[Ryan Pavlik]

I'm having trouble reproducing this locally in a Docker container
using qemu on sid: it seems to work here. Similarly a Bookworm docker
in qemu into which I installed the sid package also seems to test OK.
(Ran the full autopkgtest suite in it, and while it did appear to fail
an assertion elsewhere in the tests, it didn't break the test suite?)
I'm not sure what would cause this failure.

Can these tests be re-run?

Bug#984232: status

[Ryan Pavlik]

The updated package just needs the copyright file updated and reviewed. If
you'd like a fix uploaded before I get a chance to do that (which is
somewhat intimidating, they swapped some bundled dependencies since the
last packaged version), please feel free to nmu. Alternately I'd happily
accept an mr to make the copyright file complete again.

Ryan

On Wed, Dec 15, 2021, 5:24 AM Adrian Bunk  wrote:

> On Mon, Nov 15, 2021 at 02:53:40PM -0600, Ryan Pavlik wrote:
> > Upstream has fixed this, and I have a package with the latest upstream
> > sources in progress, happy to accept help to put it over the edge.
>
> Any progress on this?
>
> If necessary, I could NMU with the minimal fix of adding
>   export DEB_CXXFLAGS_MAINT_APPEND += -std=gnu++14
> to debian/rules.
>
> > Ryan
>
> cu
> Adrian
>
>

Bug#984232: status

[Ryan Pavlik]

Upstream has fixed this, and I have a package with the latest upstream
sources in progress, happy to accept help to put it over the edge.

Ryan



OpenPGP_signature
Description: OpenPGP digital signature

Bug#984232: Diagnosis

[Ryan Pavlik]

Looks like this is because of a dynamic exception specification, which
is forbidden by C++17. I'll see if upstream has fixed this, and if not,
I'll just modify the packaging to build in C++14 mode.

Ryan



OpenPGP_signature
Description: OpenPGP digital signature

Bug#984278: Fix discovered

[Ryan Pavlik]

I have figured out a fix (the issue was in detecting what flags were
needed to use std::filesystem, my conclusion is: with gcc11+, tell CMake
C++17 or it will misbehave), and an updated package will be available
soon pending sponsorship.



OpenPGP_signature
Description: OpenPGP digital signature

Bug#997239: (no subject)

[Ryan Pavlik]

This has been fixed upstream, and I'm cherry-picking that patch to the
package in lieu of a new upstream release, which we should do sometime
soon here.




OpenPGP_signature
Description: OpenPGP digital signature

Bug#972936: Related/reproducer?

[Ryan Pavlik]

I've been working on a similar bug, possibly the same bug or subset of
it? https://bugs.debian.org/972820 is one of its many names. I had made
a reproducer minimal test case from my own experience, which I posted
here https://salsa.debian.org/rpavlik/gcc-upgrade-testcase  and, to get
myself out of a jam, the corresponding "transitional" packages here:
https://salsa.debian.org/rpavlik/gcc-10-compat  (That repo also contains
a list of a number of other places where that bug has been filed.)

I'm not sure if this is the same bug or not, but it seems related, at
least, and of similar importance. As of my test a few minutes ago, my
docker test case can now upgrade successfully, I'll see if I can find
time to use my pre-upgrade |/var/lib/dpkg/status| to make a more
complete test case to verify that one. I'll also look at the package
changelog.

Thanks for your work on the upgrade use case here.

Ryan



signature.asc
Description: OpenPGP digital signature

Bug#975157: (no subject)

[Ryan Pavlik]

This has been fixed upstream, so an upcoming update will resolve it.



signature.asc
Description: OpenPGP digital signature

Bug#958837: vulkan-loader breaks openxr-sdk-source autopkgtest: VK_DEBUG_REPORT_OBJECT_TYPE_OBJECT_TABLE_NVX_EXT’ was not declared

[Ryan Pavlik]

I'm not sure who was in the wrong here, if OpenXR shouldn't have had
that NVX line in the source, or if the removal of that symbol form the
header was not expected. In any case, the error-inducing line
"_(INDIRECT_COMMANDS_LAYOUT_NVX)" can be patched out of
OpenXR-SDK-Source - the next upstream release has that change already
queued.

If this isn't a Vulkan bug, I can revise the OpenXR-SDK-Source
package, though it will need sponsorship as usual.

Ryan


On Sat, Apr 25, 2020 at 1:45 PM Paul Gevers  wrote:
>
> Source: vulkan-loader, openxr-sdk-source
> Control: found -1 vulkan-loader/1.2.135.0-2
> Control: found -1 openxr-sdk-source/1.0.8~dfsg1-2
> Severity: serious
> Tags: sid bullseye
> X-Debbugs-CC: debian...@lists.debian.org
> User: debian...@lists.debian.org
> Usertags: breaks needs-update
>
> Dear maintainer(s),
>
> With a recent upload of vulkan-loader the autopkgtest of
> openxr-sdk-source fails in testing when that autopkgtest is run with the
> binary packages of vulkan-loader from unstable. It passes when run with
> only packages from testing. In tabular form:
>
>passfail
> vulkan-loader  from testing1.2.135.0-2
> openxr-sdk-source  from testing1.0.8~dfsg1-2
> all others from testingfrom testing
>
> I copied some of the output at the bottom of this report.
>
> Currently this regression is blocking the migration of vulkan-loader to
> testing [1]. Due to the nature of this issue, I filed this bug report
> against both packages. Can you please investigate the situation and
> reassign the bug to the right package?
>
> More information about this bug and the reason for filing it can be found on
> https://wiki.debian.org/ContinuousIntegration/RegressionEmailInformation
>
> Paul
>
> [1] https://qa.debian.org/excuses.php?package=vulkan-loader
>
> https://ci.debian.net/data/autopkgtest/testing/amd64/o/openxr-sdk-source/5144212/log.gz
>
> autopkgtest [19:21:52]: test build-hello-xr-vulkan-xlib:
> [---
> /tmp/autopkgtest-lxc.p07f1zh7/downtmp/build.6EI/src/src/tests/hello_xr/graphicsplugin_vulkan.cpp:
> In member function ‘VkBool32
> {anonymous}::VulkanGraphicsPlugin::debugReport(VkDebugReportFlagsEXT,
> VkDebugReportObjectTypeEXT, uint64_t, size_t, int32_t, const char*,
> const char*)’:
> /tmp/autopkgtest-lxc.p07f1zh7/downtmp/build.6EI/src/src/tests/hello_xr/graphicsplugin_vulkan.cpp:1644:10:
> error: ‘VK_DEBUG_REPORT_OBJECT_TYPE_OBJECT_TABLE_NVX_EXT’ was not
> declared in this scope; did you mean
> ‘VK_DEBUG_REPORT_OBJECT_TYPE_END_RANGE_EXT’?
>  1644 | case VK_DEBUG_REPORT_OBJECT_TYPE_##name##_EXT: \
>   |  ^~~~
> /tmp/autopkgtest-lxc.p07f1zh7/downtmp/build.6EI/src/src/tests/hello_xr/graphicsplugin_vulkan.cpp:1638:5:
> note: in expansion of macro ‘MK_OBJECT_TYPE_CASE’
>  1638 | _(OBJECT_TABLE_NVX)  \
>   | ^
> /tmp/autopkgtest-lxc.p07f1zh7/downtmp/build.6EI/src/src/tests/hello_xr/graphicsplugin_vulkan.cpp:1647:17:
> note: in expansion of macro ‘LIST_OBJECT_TYPES’
>  1647 | LIST_OBJECT_TYPES(MK_OBJECT_TYPE_CASE)
>   | ^
> /tmp/autopkgtest-lxc.p07f1zh7/downtmp/build.6EI/src/src/tests/hello_xr/graphicsplugin_vulkan.cpp:1644:10:
> error: ‘VK_DEBUG_REPORT_OBJECT_TYPE_INDIRECT_COMMANDS_LAYOUT_NVX_EXT’
> was not declared in this scope; did you mean
> ‘VK_DEBUG_REPORT_OBJECT_TYPE_DESCRIPTOR_SET_LAYOUT_EXT’?
>  1644 | case VK_DEBUG_REPORT_OBJECT_TYPE_##name##_EXT: \
>   |  ^~~~
> /tmp/autopkgtest-lxc.p07f1zh7/downtmp/build.6EI/src/src/tests/hello_xr/graphicsplugin_vulkan.cpp:1639:5:
> note: in expansion of macro ‘MK_OBJECT_TYPE_CASE’
>  1639 | _(INDIRECT_COMMANDS_LAYOUT_NVX)
>   | ^
> /tmp/autopkgtest-lxc.p07f1zh7/downtmp/build.6EI/src/src/tests/hello_xr/graphicsplugin_vulkan.cpp:1647:17:
> note: in expansion of macro ‘LIST_OBJECT_TYPES’
>  1647 | LIST_OBJECT_TYPES(MK_OBJECT_TYPE_CASE)
>   | ^
> autopkgtest [19:22:04]: test build-hello-xr-vulkan-xlib:
> ---]
>

Bug#956510: Need help?

[Ryan Pavlik]

Is there anything I can do to help resolve this issue? It's
(transitively) blocking a package I maintain, so if there's a way to
help fix this I'd be happy to do so.

Ryan Pavlik



signature.asc
Description: OpenPGP digital signature

Bug#954092: meshlab: none

[Ryan Pavlik]

Package: src:meshlab
Version: 2020.02+git200217-1
Severity: serious
Justification: Policy 2.3
Tags: pending
Owner: ryan.pav...@gmail.com

Dear Maintainer,

The recently uploaded 2020.02+git200217-1 package has some DFSG
violations - some of which are file-exclusions that got lost in the new
package, while others are newly found. The "newly found" one I'll
consider key for this bug is use of GPL-incompatible source (ISC license
with a "do not sell it" clause added) in a GPL package: three files in
the "filter_screened_poisson" plugin.

I have forwarded this particular issue upstream since it affects their
binaries as well (they might be essentially not redistributable):
 Subsequently I
fixed that by removing the files in question and applying modifications
based on another, compatible source (the issue is in a vendored
project's vendored project, neither of which are packaged in Debian or
intended for anything other than standalone usage or source integration
by upstreams.) This patch was applied upstream.

I have inspected the source and restored the list of "Files-Excluded" in
debian/copyright (including all the previously-listed files that their
exclusion is still applicable, and adding additional new files that
should be excluded for DFSG or source-missing reasons), and added a
script that can generate the dfsg-cleaned repacked upstream tarball.
(They're using Git with a submodule).

My repacked version, which removes problematic files and patches a
number of issues (including a version of the patch applied upstream to
fix the filter_screened_poisson filter) is ready for review and uploaded
to https://mentors.debian.net/package/meshlab . The source is up at
https://salsa.debian.org/rpavlik-guest/meshlab - I have not pushed it to
the science team repo out of courtesy since it hasn't been reviewed yet.
However, I think it's ready to go.  (The system information below
reflects my installation of my own package on Buster, but I have set the
version entry in the header correctly.)

Ryan

-- System Information:
Debian Release: 10.3
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable-debug'), (500,
'stable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.4.0-0.bpo.3-amd64 (SMP w/16 CPU cores)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE,
TAINT_UNSIGNED_MODULE
Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8),
LANGUAGE=en_US.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages meshlab depends on:
ii  lib3ds-1-3  1.3.0-9+b1
ii  libc6   2.28-10
ii  libgcc1 1:8.3.0-6
ii  libglew2.1  2.1.0-4
ii  libglu1-mesa [libglu1]  9.0.0-2.1+b3
ii  libglx0 1.1.0-1
ii  libgmp102:6.1.2+dfsg-4
ii  libgomp18.3.0-6
ii  libmuparser2v5  2.2.6.1+dfsg-1
ii  libopenctm1 1.0.3+dfsg1-2+b1
ii  libopengl0  1.1.0-1
ii  libqhull7   2015.2-4
ii  libqt5core5a5.11.3+dfsg1-1+deb10u3
ii  libqt5gui5  5.11.3+dfsg1-1+deb10u3
ii  libqt5network5  5.11.3+dfsg1-1+deb10u3
ii  libqt5opengl5   5.11.3+dfsg1-1+deb10u3
ii  libqt5script5   5.11.3+dfsg-3
ii  libqt5widgets5  5.11.3+dfsg1-1+deb10u3
ii  libqt5xml5  5.11.3+dfsg1-1+deb10u3
ii  libqt5xmlpatterns5  5.11.3-2
ii  libstdc++6  8.3.0-6

Versions of packages meshlab recommends:
pn  chemical-mime-data  

meshlab suggests no packages.

-- no debconf information

Bug#953062: Update

[Ryan Pavlik]

Ah, I figured out the conflict.

Qt5 on armel/armhf uses OpenGL ES, not OpenGL full (desktop). So, using
full OpenGL causes conflicts. My most recent changes (pushed to salsa,
waiting on my cowbuilder before pushing to mentors) change the
dependency in control to libqt5opengl5-desktop-dev, so that it doesn't
attempt to build on armel/armhf since it will fail there.

Bug#953062: status update

[Ryan Pavlik]

OK, I got a chance to build aarch64 and it does build there.
Unfortunately I hit a more fundamental error with armhf, that it has
type mismatches when trying to use GLEW.  Not sure if this is intrinsic
or if it can be solved: the last version that was in Debian was a long
time ago...

This error repeats for essentially every GL entrypoint.

[  352s] In file included from
/usr/include/arm-linux-gnueabihf/qt5/QtGui/qopengl.h:105,
[  352s]  from
/usr/include/arm-linux-gnueabihf/qt5/QtOpenGL/qgl.h:45,
[  352s]  from
/usr/include/arm-linux-gnueabihf/qt5/QtOpenGL/QGLWidget:1,
[  352s]  from
/usr/src/packages/BUILD/src/common/ml_shared_data_context.h:34,
[  352s]  from
/usr/src/packages/BUILD/src/common/meshmodel.h:61,
[  352s]  from
/usr/src/packages/BUILD/src/common/scriptinterface.h:28,
[  352s]  from
/usr/src/packages/BUILD/src/common/interfaces.h:31,
[  352s]  from
/usr/src/packages/BUILD/src/common/interfaces.cpp:1:
[  352s] /usr/include/GLES3/gl32.h:1821:187: error: 'void
__glewTexStorage3DMultisample(GLenum, GLsizei, GLenum, GLsizei, GLsizei,
GLsizei, GLboolean)' redeclared as different kind of symbol
[  352s]  GL_APICALL void GL_APIENTRY glTexStorage3DMultisample (GLenum
target, GLsizei samples, GLenum internalformat, GLsizei width, GLsizei
height, GLsizei depth, GLboolean fixedsamplelocations);
[  352s]

  ^
[  352s] In file included from
/usr/src/packages/BUILD/src/common/meshmodel.h:26,
[  352s]  from
/usr/src/packages/BUILD/src/common/scriptinterface.h:28,
[  352s]  from
/usr/src/packages/BUILD/src/common/interfaces.h:31,
[  352s]  from
/usr/src/packages/BUILD/src/common/interfaces.cpp:1:
[  352s] /usr/include/GL/glew.h:20901:50: note: previous declaration
'void (* __glewTexStorage3DMultisample)(GLenum, GLsizei, GLenum,
GLsizei, GLsizei, GLsizei, GLboolean)'
[  352s]  GLEW_FUN_EXPORT PFNGLTEXSTORAGE3DMULTISAMPLEPROC
__glewTexStorage3DMultisample;
[  352s]
^



signature.asc
Description: OpenPGP digital signature

Bug#953062: FTBFS on arm64, armel, armhf, ppc64el, s390x

[Ryan Pavlik]

On 3/4/20 1:12 PM, Moritz Mühlenhoff wrote:
> On Tue, Mar 03, 2020 at 05:56:18PM -0600, Ryan Pavlik wrote:
>> armel and armhf: these platforms only have OpenGL-ES, not desktop
>> OpenGL, so the correct thing to do is to disable this package on those
>> platforms. Is there a better way to do this than to list all other
>> platforms in the control file?
> 
> No, I think listing the archs it's known to build on is the only
> way.
> 
> Cheers,
> Moritz
> 

Looking at the old build logs, it looks like it should build on
armel/armhf anyway. My most recent mentors upload disables the
StructureSynth bundled source, which was where the build issue was, and
so it should skip that plugin and build right now. (I don't have buildd
access and haven't tried building it on an rpi yet or cross-building
yet. The package hit a resource limit when building on the public Open
Build Service instance.)

Ryan



signature.asc
Description: OpenPGP digital signature

Bug#953062: FTBFS on arm64, armel, armhf, ppc64el, s390x

[Ryan Pavlik]

arm64 and s390x (and maybe ppc64el?) are all an issue with signed char
conversions. I have a patch to fix that in my git repo, along with other
fixes that effectively block further usage (dfsg, etc):
https://salsa.debian.org/rpavlik-guest/meshlab/-/commit/2631636f29b7375a1d7977a1484b826db55ba153

armel and armhf: these platforms only have OpenGL-ES, not desktop
OpenGL, so the correct thing to do is to disable this package on those
platforms. Is there a better way to do this than to list all other
platforms in the control file?

Ryan

On 3/3/20 4:08 PM, Moritz Muehlenhoff wrote:
> Package: meshlab
> Severity: serious
>
> The new meshlab FTBFSes on arm64, armel, armhf, ppc64el, s390x.
>
> This also means that on those archs meshlab still uses Qt4.
>
> Cheers,
> Moritz
>



signature.asc
Description: OpenPGP digital signature