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.
>
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
> Severit
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
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
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
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
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
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
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
This has been fixed upstream, so an upcoming update will resolve it.
signature.asc
Description: OpenPGP digital signature
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 rel
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
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
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
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 re
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
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
a
17 matches
Mail list logo
