from:"Ryan Pavlik"

Bug#1018329: nmudiff

2024-09-01 Thread 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#996850: ITP: rhsrvany -- Windows tools used by virt-v2v

2023-07-24 Thread Ryan Pavlik

The package is done and works well, I just haven't had time to find a
sponsor and follow it through the new queue process.

Ryan

On Mon, Jul 24, 2023, 11:09 AM Lee Garrett  wrote:

> Hi Ryan,
>
> is there any update on the packaging progress?
>
> Greets,
> Lee
>
>
> On Tue, 19 Oct 2021 10:48:35 -0500 Ryan Pavlik 
> wrote:
> > Package: wnpp
> > Severity: wishlist
> > Owner: Ryan Pavlik 
> > X-Debbugs-Cc: debian-de...@lists.debian.org
> >
> > * Package name: rhsrvany
> >   Version : 0.20210127
> >   Upstream Author : Richard W.M. Jones, Red Hat Inc.
> > * URL : https://github.com/rwmjones/rhsrvany
> > * License : GPL-2+
> >   Programming Lang: C
> >   Description : Windows tools used by virt-v2v
> >
> >  This package contains open-source replacements for
> >  proprietary Windows tools, SrvAny (RHSrvAny) and pnp_wait.
> >  They are used by the virt-v2v tool when converting
> >  Windows virtual machines.
> >
> > This is required for virt-v2v (see https://bugs.debian.org/962293)
> > which was formerly part of libguestfs in Buster and now the
> > subject of its own RFP bug linked above.
> > The draft of that package is in the libvirt team,
> > and if this package is accepted, I'd anticipate joining that team
> > for team maintenance and sponsorship. The code itself is quite stable,
> > with a limited purpose and having seen little need for changes in
> > the past several years, so I anticipate
> > packaging maintenance load to be low.
> >
>

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

2022-12-07 Thread 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#1020374: RM: solvespace [s390x] -- ANAIS; Removed from source package due to test failure

2022-09-20 Thread Ryan Pavlik

Package: ftp.debian.org
Severity: normal

Bug#1018130:

2022-08-25 Thread Ryan Pavlik

Looks like this is only for a mapping integration (?! Must have been after
my time) using the old libchamplain, should just be able to disable that
build option.

Bug#1013163:

2022-06-30 Thread 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#887978: Still present?

2022-06-30 Thread Ryan Pavlik

I'm wondering if you still see this bug in any newer stable release:
it looks like we couldn't track down any reproduction of the issue at
the time but 3.0 has a lot of changes since 2.3.

Bug#984232: status

2021-12-17 Thread 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#1001870: meshlab: reproducible-builds: BuildId differences triggered by RPATH

2021-12-17 Thread Ryan Pavlik

Oh wow, thanks! I was trying to figure out why it wasn't reproducible even
though it "should have" been. I'll apply this soon.

On Fri, Dec 17, 2021, 6:09 PM Vagrant Cascadian <
vagr...@reproducible-builds.org> wrote:

> Source: meshlab
> Severity: normal
> Tags: patch
> User: reproducible-bui...@lists.alioth.debian.org
> Usertags: buildpath
> X-Debbugs-Cc: reproducible-b...@lists.alioth.debian.org
>
> The RPATH contains the build path resulting in different buildid:
>
>
> https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/meshlab.html
>
> The attached patch to debian/rules passes
> -DCMAKE_BUILD_RPATH_USE_ORIGIN=ON via a dh_auto_configure override,
> which should use a relative path for RPATH.
>
> With this patch applied, meshlab should build reproducibly on
> tests.reproducible-builds.org!
>
> Thanks for maintaining meshlab!
>
> live well,
>   vagrant
>

Bug#990401: Status

2021-11-15 Thread Ryan Pavlik

A new upstream release solves this. A package is currently in progress.

Ryan



OpenPGP_signature
Description: OpenPGP digital signature

Bug#984232: status

2021-11-15 Thread 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

2021-10-25 Thread 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

2021-10-25 Thread 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)

2021-10-25 Thread 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#962293: Test results, recommends

2021-10-19 Thread Ryan Pavlik

I have tried the package here:
https://salsa.debian.org/libvirt-team/virt-v2v and it seems to work
well. In combination with that package, I have filed
https://bugs.debian.org/996850 for the two tools used when processing a
Windows guest: so, probably a "recommends".



OpenPGP_signature
Description: OpenPGP digital signature

Bug#996850: ITP: rhsrvany -- Windows tools used by virt-v2v

2021-10-19 Thread Ryan Pavlik

Package: wnpp
Severity: wishlist
Owner: Ryan Pavlik 
X-Debbugs-Cc: debian-de...@lists.debian.org

* Package name: rhsrvany
  Version : 0.20210127
  Upstream Author : Richard W.M. Jones, Red Hat Inc.
* URL : https://github.com/rwmjones/rhsrvany
* License : GPL-2+
  Programming Lang: C
  Description : Windows tools used by virt-v2v

 This package contains open-source replacements for
 proprietary Windows tools, SrvAny (RHSrvAny) and pnp_wait.
 They are used by the virt-v2v tool when converting
 Windows virtual machines.

This is required for virt-v2v (see https://bugs.debian.org/962293)
which was formerly part of libguestfs in Buster and now the
subject of its own RFP bug linked above.
The draft of that package is in the libvirt team,
and if this package is accepted, I'd anticipate joining that team
for team maintenance and sponsorship. The code itself is quite stable,
with a limited purpose and having seen little need for changes in
the past several years, so I anticipate
packaging maintenance load to be low.



OpenPGP_signature
Description: OpenPGP digital signature

Bug#983952: confirmed, fixed upstream

2021-04-14 Thread Ryan Pavlik

This was a floating-point related issue with negligible impact, detected
by pixel-wise compare of an export. It has been fixed upstream and will
be included in the 3.0 stable release:
https://github.com/solvespace/solvespace/pull/987 (Debian Bullseye
currently contains 3.0 RC2)




signature.asc
Description: OpenPGP digital signature

Bug#972936: Related/reproducer?

2021-02-14 Thread 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#972820: confirmation, test case

2020-12-04 Thread Ryan Pavlik

Looks like https://bugs.debian.org/964477 is related or the same, not
sure which way the merge should go. There's some existing discussion
there, including suggesting that the commit I cited below was not the
only thing that broke it, given it was marked "found" in 10.1.0-1.

It also looks like https://bugs.debian.org/972936 might be related, as
well as the archived bug https://bugs.debian.org/946285

I've collected some mentions of this issue in the readme of
<https://salsa.debian.org/rpavlik/gcc-10-compat>

Thanks for your help!

Ryan

On 12/4/2020 12:27 PM, Ryan Pavlik wrote:
> I have also experienced this bug, as have a lot of others on the
> internet (try searching for "libc6-dev : Breaks: libgcc-8-dev (<
> 8.4.0-2~) but 8.3.0-6 is to be installed" to see). The bug appears to be
> in the new gcc-10 package, not the gcc-8 package it's replacing on upgrade.
>
> It looks like it's a result of the lack of transitional packages from
> libgcc1 to libgcc-s1 (and its relatives). They were removed from sid and
> bullseye for 10.1.0-2, in this commit:
> https://salsa.debian.org/toolchain-team/gcc/-/commit/e8047f6d4947d94d7475987d0697434f1e6504d7
>  
> (though multi-arch properties were removed before then).
>
> I was able to work around this issue by creating a simple mostly-empty
> source package that created the missing transitional packages and
> installing them, though this is of course inferior to having them
> actually provided by the relevant source package.
> https://salsa.debian.org/rpavlik/gcc-10-compat (I only mocked up/built
> the packages required to test on x86_64/i386, but I'd expect the same
> problem and solution on the other platforms that have additional libgcc
> packages.)
>
> I have a reproducible test case: I did it in a Dockerfile, but you could
> do the equivalent commands in a chroot or which ever way you prefer.
> Essentially, you can start with a fairly minimal Debian Buster install,
> and install the following packages:
>
> apt-get install -y -qq --no-install-recommends gcc-8 libc6-dev libreoffice
>
> (This is one minimal set to reproduce - there may be others.)
>
> Then, when you switch the Buster sources to Bullseye, you'll get this
> error on your attempt to apt-get dist-upgrade:
>
>
> 
>
> Calculating upgrade... Error!
> Some packages could not be installed. This may mean that you have
> requested an impossible situation or if you are using the unstable
> distribution that some required packages have not yet been created
> or been moved out of Incoming.
> The following information may help to resolve the situation:
>
> The following packages have unmet dependencies:
>  libc6-dev : Breaks: libgcc-8-dev (< 8.4.0-2~) but 8.3.0-6 is to be
> installed
> E: Error, pkgProblemResolver::Resolve generated breaks, this may be
> caused by held packages.
>
> 
>
> You can confirm the fix by adding the repo with my workaround
> transitional packages:
>
> deb
> http://download.opensuse.org/repositories/home:/rpavlik:/bullseye-fix
> Debian_Testing/
>
> (key is at
> http://download.opensuse.org/repositories/home:/rpavlik:/bullseye-fix/Debian_Testing/Release.key
> )
>
> I've uploaded my dockerfile for experimenting with this bug to
> https://salsa.debian.org/rpavlik/gcc-upgrade-testcase
>
> It looks to me, based on the workaround I was able to create, that the
> solution might include re-enabling the transitional packages for
> bullseye/sid at least until the release of bullseye as stable. At that
> point, anyone upgrading to testing or unstable would be coming from a
> bullseye release that has the gcc-10 with new names, so the transitional
> packages would not be needed anymore.
>
>
>



signature.asc
Description: OpenPGP digital signature

Bug#972820: confirmation, test case

2020-12-04 Thread Ryan Pavlik

Control: reassign gcc-10 10.2.0-19


I have also experienced this bug, as have a lot of others on the
internet (try searching for "libc6-dev : Breaks: libgcc-8-dev (<
8.4.0-2~) but 8.3.0-6 is to be installed" to see). The bug appears to be
in the new gcc-10 package, not the gcc-8 package it's replacing on upgrade.

It looks like it's a result of the lack of transitional packages from
libgcc1 to libgcc-s1 (and its relatives). They were removed from sid and
bullseye for 10.1.0-2, in this commit:
https://salsa.debian.org/toolchain-team/gcc/-/commit/e8047f6d4947d94d7475987d0697434f1e6504d7
 
(though multi-arch properties were removed before then).

I was able to work around this issue by creating a simple mostly-empty
source package that created the missing transitional packages and
installing them, though this is of course inferior to having them
actually provided by the relevant source package.
https://salsa.debian.org/rpavlik/gcc-10-compat (I only mocked up/built
the packages required to test on x86_64/i386, but I'd expect the same
problem and solution on the other platforms that have additional libgcc
packages.)

I have a reproducible test case: I did it in a Dockerfile, but you could
do the equivalent commands in a chroot or which ever way you prefer.
Essentially, you can start with a fairly minimal Debian Buster install,
and install the following packages:

apt-get install -y -qq --no-install-recommends gcc-8 libc6-dev libreoffice

(This is one minimal set to reproduce - there may be others.)

Then, when you switch the Buster sources to Bullseye, you'll get this
error on your attempt to apt-get dist-upgrade:




Calculating upgrade... Error!
Some packages could not be installed. This may mean that you have
requested an impossible situation or if you are using the unstable
distribution that some required packages have not yet been created
or been moved out of Incoming.
The following information may help to resolve the situation:

The following packages have unmet dependencies:
 libc6-dev : Breaks: libgcc-8-dev (< 8.4.0-2~) but 8.3.0-6 is to be
installed
E: Error, pkgProblemResolver::Resolve generated breaks, this may be
caused by held packages.



You can confirm the fix by adding the repo with my workaround
transitional packages:

deb
http://download.opensuse.org/repositories/home:/rpavlik:/bullseye-fix
Debian_Testing/

(key is at
http://download.opensuse.org/repositories/home:/rpavlik:/bullseye-fix/Debian_Testing/Release.key
)

I've uploaded my dockerfile for experimenting with this bug to
https://salsa.debian.org/rpavlik/gcc-upgrade-testcase

It looks to me, based on the workaround I was able to create, that the
solution might include re-enabling the transitional packages for
bullseye/sid at least until the release of bullseye as stable. At that
point, anyone upgrading to testing or unstable would be coming from a
bullseye release that has the gcc-10 with new names, so the transitional
packages would not be needed anymore.





signature.asc
Description: OpenPGP digital signature

Bug#975157: (no subject)

2020-11-30 Thread Ryan Pavlik

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



signature.asc
Description: OpenPGP digital signature

Bug#881075: Update

2020-08-06 Thread Ryan Pavlik

I'd be willing to look into updating this package, as long as the
maintainer has no objection. It would be helpful if the git repo of
packaging were available (see https://bugs.debian.org/928335 ), though
failing that I could just use dgit.

Ryan

Bug#960307: linux-image-5.5.0-0.bpo.2-amd64: Please enable NVME_HWMON

2020-05-11 Thread Ryan Pavlik

Package: src:linux
Version: 5.5.17-1~bpo10+1
Severity: wishlist

Dear Maintainer,

Linux 5.5 includes HWMON support for NVMe drives[1][2] without needing a 
superuser
userspace binary like nvme-cli. However, it appears to be off in this build:

$ grep NVME /boot/config-5.5.0-0.bpo.2-amd64 
...
# CONFIG_NVME_HWMON is not set
...

Please consider enabling it so existing hwmon-based tools in Debian can easily
access temperature, etc. data from NVMe devices.

Thanks!

Ryan

[1]: 
https://git.kernel.dk/cgit/linux-block/commit/?h=for-next&id=866ca95da5e5c4fad59f1b08254168284bd6a911
[2]: 
https://www.phoronix.com/scan.php?page=news_item&px=Linux-5.5-NVMe-HWMON-Support

-- Package-specific info:
** Version:
Linux version 5.5.0-0.bpo.2-amd64 (debian-ker...@lists.debian.org) (gcc version 
8.3.0 (Debian 8.3.0-6)) #1 SMP Debian 5.5.17-1~bpo10+1 (2020-04-23)

** Command line:
BOOT_IMAGE=/vmlinuz-5.5.0-0.bpo.2-amd64 
root=UUID=66e14321-6a5d-4e78-83ba-da8ce9a279fd ro quiet

** Not tainted

** Kernel log:
Unable to read kernel log; any relevant messages should be attached

** Model information
sys_vendor: Dell Inc.
product_name: Inspiron 5676
product_version: 1.3.0
chassis_vendor: Dell Inc.
chassis_version: 1.3.0
bios_vendor: Dell Inc.
bios_version: 1.3.0
board_vendor: Dell Inc.
board_name: 
board_version: 

** Loaded modules:
hidp
fuse
xt_conntrack
xt_MASQUERADE
nf_conntrack_netlink
xfrm_user
xfrm_algo
nft_counter
xt_addrtype
nft_compat
nft_chain_nat
nf_nat
nf_conntrack
nf_defrag_ipv6
nf_defrag_ipv4
nf_tables
nfnetlink
br_netfilter
bridge
stp
llc
rfcomm
cmac
overlay
bnep
squashfs
nls_ascii
nls_cp437
btusb
vfat
btrtl
fat
btbcm
btintel
bluetooth
snd_hda_codec_realtek
ath10k_pci
snd_hda_codec_generic
joydev
ledtrig_audio
edac_mce_amd
snd_hda_codec_hdmi
ath10k_core
efi_pstore
snd_hda_intel
snd_intel_dspcfg
dell_smm_hwmon
snd_hda_codec
ath
drbg
kvm_amd
snd_usb_audio
loop
mac80211
kvm
dell_wmi
snd_usbmidi_lib
snd_rawmidi
hid_sony
snd_seq_device
snd_hda_core
dell_smbios
mc
sparse_keymap
ff_memless
snd_hwdep
dcdbas
wdat_wdt
irqbypass
pcspkr
serio_raw
video
wmi_bmof
alienware_wmi
efivars
snd_pcm
ansi_cprng
dell_wmi_descriptor
sp5100_tco
cfg80211
k10temp
snd_timer
ecdh_generic
watchdog
ecc
ccp
snd
rfkill
rng_core
soundcore
libarc4
sg
evdev
acpi_cpufreq
i2c_dev
parport_pc
ppdev
binfmt_misc
lp
parport
efivarfs
ip_tables
x_tables
autofs4
btrfs
blake2b_generic
zstd_decompress
zstd_compress
algif_skcipher
af_alg
raid10
raid456
async_raid6_recov
async_memcpy
async_pq
async_xor
async_tx
xor
raid6_pq
libcrc32c
raid1
raid0
multipath
linear
md_mod
dm_mirror
dm_region_hash
dm_log
ext4
crc16
mbcache
jbd2
crc32c_generic
lrw
gf128mul
dm_crypt
dm_mod
sd_mod
hid_generic
usbhid
hid
amdgpu
crct10dif_pclmul
crc32_pclmul
crc32c_intel
ghash_clmulni_intel
gpu_sched
i2c_algo_bit
ttm
drm_kms_helper
ahci
libahci
drm
xhci_pci
xhci_hcd
aesni_intel
libata
crypto_simd
psmouse
cryptd
glue_helper
usbcore
i2c_piix4
r8169
mfd_core
nvme
scsi_mod
realtek
nvme_core
libphy
usb_common
wmi
gpio_amdpt
i2c_designware_platform
gpio_generic
i2c_designware_core
button

** PCI devices:
00:00.0 Host bridge [0600]: Advanced Micro Devices, Inc. [AMD] Family 17h 
(Models 00h-0fh) Root Complex [1022:1450]
Subsystem: Dell Family 17h (Models 00h-0fh) Root Complex [1028:089a]
Control: I/O- Mem- BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B- DisINTx-
Status: Cap- 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- TAbort- SERR- 

00:01.0 Host bridge [0600]: Advanced Micro Devices, Inc. [AMD] Family 17h 
(Models 00h-1fh) PCIe Dummy Host Bridge [1022:1452]
Control: I/O- Mem- BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B- DisINTx-
Status: Cap- 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- TAbort- SERR- TAbort- Reset- FastB2B-
PriDiscTmr- SecDiscTmr- DiscTmrStat- DiscTmrSERREn-
Capabilities: 
Kernel driver in use: pcieport

00:01.3 PCI bridge [0604]: Advanced Micro Devices, Inc. [AMD] Family 17h 
(Models 00h-0fh) PCIe GPP Bridge [1022:1453] (prog-if 00 [Normal decode])
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B- DisINTx+
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- TAbort- Reset- FastB2B-
PriDiscTmr- SecDiscTmr- DiscTmrStat- DiscTmrSERREn-
Capabilities: 
Kernel driver in use: pcieport

00:02.0 Host bridge [0600]: Advanced Micro Devices, Inc. [AMD] Family 17h 
(Models 00h-1fh) PCIe Dummy Host Bridge [1022:1452]
Control: I/O- Mem- BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B- DisINTx-
Status: Cap- 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- Reset- FastB2B-
PriDiscTmr- SecDiscTmr- DiscTmrStat- DiscTmrSERREn-
Capabilities: 
Kernel driver in use: pcieport

00:04.0 Host bridge [0600]: Advanced Micro Devices, Inc

Bug#958749: libconfig-model-dpkg-perl: Parsing of wrapped long patch subjects incorrect

2020-05-01 Thread Ryan Pavlik

Control: reassign -1 git-buildpackage 0.9.14
Control: retitle -1 gbp-pq should not wrap long subjects


Thanks for following up on this one, that makes sense. In the mean
time, I'll try to keep those subject lines shorter when I control
them. I've reassigned the issue accordingly - not sure how feasible
fixing it is but may as well track it.

Ryan

On Thu, Apr 30, 2020 at 10:47 AM Dominique Dumont  wrote:
>
> On samedi 25 avril 2020 00:17:18 CEST you wrote:
> > I have packages with patches maintained using gbp-pq, which wraps long
> > first lines of commits, indenting the subsequent line with a single space,
> > using that full (wrapped) line as the "Subject:".
>
> On the other hand the DEP-3 specification [1] mentions:
> "This obligatory field contains at least a short description on the first 
> line.
> When Subject is used, it is expected that the long description is outside of
> the structured fields. "
>
> Cme tries to salvage information from the Subject field and move in the free
> form description, after all allowed parameters (Last-UPdate) in this case.
>
> I think gbp-pq should not produce multi lines Subject fields
>
> All the best
>
> [1] https://dep-team.pages.debian.net/deps/dep3/
>
>
>
>
>

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

2020-04-29 Thread 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?

2020-04-28 Thread 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#599146: git-buildpackage: gbp-pq should deal with unknown fields more gracefully

2020-04-24 Thread Ryan Pavlik

On Sun, 17 Oct 2010 15:08:56 +0200 Guido =?iso-8859-1?Q?G=FCnther?= <
a...@sigxcpu.org> wrote:
> On Sat, Oct 16, 2010 at 07:26:07PM +0200, Guido Günther wrote:
> > Hi David,
> > sorry for the late reply.
> >
> > On Tue, Oct 05, 2010 at 12:12:17AM -0300, David Bremner wrote:
> > > Package: git-buildpackage
> > > Version: 0.5.4
> > > Severity: wishlist
> > >
> > > Currently gbp-import silently drops unknown header fields. This
is
> > > problematic for the proposed DEP3 header, which allows more
fields
> > > than From, Date, and Subject.  Minimally it should complain that
> > Yes, that sucks. It's caused by gbp-pq using "git quilt-import" for
the
> > import. We have to get rid of git-quilt-import due to other bugs
like
> Just as a side note: If you put the header fields after the patch
> description - just like the first example at
> http://dep.debian.net/deps/dep3/ the header fields are preserved by
git
> quilt-import.
> Cheers,
>  -- Guido
>
>
>

Note that while this format (the additional fields after the
description) is left alone by gbp-pq, it is rearranged by edits by cme
(libconfig-model-dpkg-perl) which places all the DEP-3 fields at the top
of the patchfile.

Bug#958749: libconfig-model-dpkg-perl: Parsing of wrapped long patch subjects incorrect

2020-04-24 Thread Ryan Pavlik

Package: libconfig-model-dpkg-perl
Version: 2.132~bpo10+1
Severity: normal
Tags: upstream

Dear Maintainer,

I have packages with patches maintained using gbp-pq, which wraps long
first lines of commits, indenting the subsequent line with a single space,
using that full (wrapped) line as the "Subject:".

When loading a package with such a patch in its series in cme edit dpkg:

- the text before the wrap is loaded as the "Synopsis" field, and the
  wrapped text (as well as some? following lines) is in "Subject".
- Upon editing the metadata (e.g. adding Forwarded: not-needed) and saving 
again,
  the second half of the subject line is now un-indented and placed among the 
other headers
  (see attached before.patch and after.patch)

I would expect the subject to be persisted unmodified if I don't modify it - 
perhaps only
adjusting wrap point or indentation.

Thank you,

Ryan Pavlik

-- 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.4-amd64 (SMP w/16 CPU cores)
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 libconfig-model-dpkg-perl depends on:
ii  debhelper  12.9~bpo10+1
ii  libapt-pkg-perl0.1.34+b1
ii  libarray-intspan-perl  2.003-1
ii  libconfig-model-backend-yaml-perl  2.133-2
ii  libconfig-model-perl   2.133-1
ii  libexporter-lite-perl  0.08-1
ii  liblog-log4perl-perl   1.49-1
ii  libmouse-perl  2.5.6-1+b1
ii  libparse-recdescent-perl   1.967015+dfsg-2
ii  libsoftware-licensemoreutils-perl  1.004-1
ii  libsort-versions-perl  1.62-1
ii  libtext-autoformat-perl1.74-2
ii  libtext-levenshtein-damerau-perl   0.41-1
ii  liburi-perl1.76-1
ii  libwww-perl6.36-2
ii  libyaml-libyaml-perl   0.76+repack-1
ii  licensecheck   3.0.46-1~bpo10+1
ii  lintian2.65.0~bpo10+1
ii  perl [libmodule-corelist-perl] 5.28.1-6

Versions of packages libconfig-model-dpkg-perl recommends:
ii  libconfig-model-tkui-perl  1.369-2

libconfig-model-dpkg-perl suggests no packages.

-- no debconf information
Subject: pretend this is a long subject
 that got wrapped by gbp-pq
Last-Update: 2020-04-24
Date: Thu, 9 Apr 2020 17:57:07 -0500

Not sure what's going on, this looks
constexpr to me. Raised issue in upstream instead of
forwarding this workaround-resembling patch.
---
 src/xrt/auxiliary/tracking/t_tracker_psmv_fusion.cpp | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/xrt/auxiliary/tracking/t_tracker_psmv_fusion.cpp 
b/src/xrt/auxiliary/tracking/t_tracker_psmv_fusion.cpp
index 191d6ea..de32c83 100644
--- a/src/xrt/auxiliary/tracking/t_tracker_psmv_fusion.cpp
+++ b/src/xrt/auxiliary/tracking/t_tracker_psmv_fusion.cpp
@@ -148,7 +148,7 @@ namespace {
reset_filter_and_imu();
}
// 7200 deg/sec
-   constexpr double max_rad_per_sec = 20 * EIGEN_PI * 2;
+   double max_rad_per_sec = 20 * EIGEN_PI * 2;
if (filter_state.angularVelocity().squaredNorm() >
max_rad_per_sec * max_rad_per_sec) {
fprintf(stderr,
Subject: pretend this is a long subject
Forwarded: not-needed
Last-Update: 2020-04-24
that got wrapped by gbp-pq
Date: Thu, 9 Apr 2020 17:57:07 -0500

Not sure what's going on, this looks
constexpr to me. Raised issue in upstream instead of
forwarding this workaround-resembling patch.
---
 src/xrt/auxiliary/tracking/t_tracker_psmv_fusion.cpp | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/xrt/auxiliary/tracking/t_tracker_psmv_fusion.cpp 
b/src/xrt/auxiliary/tracking/t_tracker_psmv_fusion.cpp
index 191d6ea..de32c83 100644
--- a/src/xrt/auxiliary/tracking/t_tracker_psmv_fusion.cpp
+++ b/src/xrt/auxiliary/tracking/t_tracker_psmv_fusion.cpp
@@ -148,7 +148,7 @@ namespace {
reset_filter_and_imu();
}
// 7200 deg/sec
-   constexpr double max_rad_per_sec = 20 * EIGEN_PI * 2;
+   double max_rad_per_sec = 20 * EIGEN_PI * 2;
if (filter_state.angularVelocity().squaredNorm() >
max_rad_per_sec * max_rad_per_sec) {
fprintf(stderr,

Bug#958746: libconfig-model-dpkg-perl: URLs in patch descriptions mangled (treated as fields?)

2020-04-24 Thread Ryan Pavlik

Package: libconfig-model-dpkg-perl
Version: 2.132~bpo10+1
Severity: normal
Tags: upstream

Dear Maintainer,

I have used cme edit dpkg to modify metadata on some patches (which were 
produced with
gbp pq). The description of one of those patches (deriving from the commit 
message)
has a (final) line that starts with a url.

After modifying that patch, the description is mangled:
the URL is moved above the rest of the description and separated by blank lines,
and there is a space inserted after https:

I expected that only my manual changes, plus any re-ordering due to differing 
opinions
between gbp-pq and cme, would have been made, not modifying the line
with the URL.

(My suspicion is that it parsed the https: as a RFC882 header name, so it 
formatted
that "field" with a space between the header/field name and the "contents".)

Thank you,

Ryan Pavlik


-- 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.4-amd64 (SMP w/16 CPU cores)
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 libconfig-model-dpkg-perl depends on:
ii  debhelper  12.9~bpo10+1
ii  libapt-pkg-perl0.1.34+b1
ii  libarray-intspan-perl  2.003-1
ii  libconfig-model-backend-yaml-perl  2.133-2
ii  libconfig-model-perl   2.133-1
ii  libexporter-lite-perl  0.08-1
ii  liblog-log4perl-perl   1.49-1
ii  libmouse-perl  2.5.6-1+b1
ii  libparse-recdescent-perl   1.967015+dfsg-2
ii  libsoftware-licensemoreutils-perl  1.004-1
ii  libsort-versions-perl  1.62-1
ii  libtext-autoformat-perl1.74-2
ii  libtext-levenshtein-damerau-perl   0.41-1
ii  liburi-perl1.76-1
ii  libwww-perl6.36-2
ii  libyaml-libyaml-perl   0.76+repack-1
ii  licensecheck   3.0.46-1~bpo10+1
ii  lintian2.65.0~bpo10+1
ii  perl [libmodule-corelist-perl] 5.28.1-6

Versions of packages libconfig-model-dpkg-perl recommends:
ii  libconfig-model-tkui-perl  1.369-2

libconfig-model-dpkg-perl suggests no packages.

-- no debconf information

Bug#956253: mu-editor: Update to 1.1.0 alpha 2 or newer

2020-04-08 Thread Ryan Pavlik

Package: mu-editor
Version: 1.1.0~alpha2+dfsg-0.1
Severity: wishlist
Tags: patch

Dear Maintainer,

It would be good to get the alpha version of mu-editor in Debian, since the 
existing version
has some issues in my experience accessing (at least newer) Adafruit devices 
with
CircuitPython (blank REPL, etc).

I've forked the repo on Salsa and tried my hand at updating the package:

https://salsa.debian.org/rpavlik-guest/mu-editor

(just to the alpha2 level that uscan found)

I can build it locally (on Buster) and on salsa-ci (on unstable?) but when 
building in a buster cowbuilder,
I'm getting a strange error (see log below).
Not sure if this is a blocking issue, but this is the first package I've had 
this problem with.
Once this issue gets resolved I think the package on my fork would be ready to 
upload.
(You may take it and modify it, or alternately sponsor it, as I do not have 
upload capability)

Thanks,
Ryan

Log:


   debian/rules override_dh_auto_test
make[1]: Entering directory '/build/mu-editor-1.1.0~alpha2+dfsg'
xvfb-run -a dh_auto_test
pybuild --test -i python{version} -p 3.7
D: pybuild pybuild:545: version: 3.20190308
D: pybuild pybuild:546: ['/usr/bin/pybuild', '--test', '-i', 'python{version}', 
'-p', '3.7']
D: pybuild pybuild:36: cfg: Namespace(after_build=None, after_clean=None, 
after_configure=None, after_install=None, after_test=None, before_build=None, 
before_clean=None, before_configure=None, before_install=None, 
before_test=None, build_args=None, build_only=False, clean_args=None, 
clean_only=False, configure_args=None, configure_only=False, custom_tests=True, 
destdir='debian/tmp', detect_only=False, 
dir='/build/mu-editor-1.1.0~alpha2+dfsg', disable=None, ext_destdir=None, 
ext_pattern='\\.so(\\.[^/]*)?$', ext_sub_pattern=None, ext_sub_repl=None, 
install_args=None, install_dir=None, install_only=False, 
interpreter=['python{version}'], list_systems=False, name='mu-editor', 
print_args=None, quiet=False, really_quiet=False, system=None, test_args=None, 
test_nose=False, test_only=True, test_pytest=True, test_tox=False, 
verbose=True, versions=['3.7'])
D: pybuild __init__:36: cannot initialize 'cmake' plugin
Traceback (most recent call last):
  File "/usr/share/dh-python/dhpython/build/__init__.py", line 32, in 
module.BuildSystem.is_usable()
  File "/usr/share/dh-python/dhpython/build/base.py", line 120, in is_usable
raise Exception("missing command: %s" % command)
Exception: missing command: cmake
D: pybuild tools:232: invoking: /usr/bin/dpkg-architecture
D: pybuild pybuild:129: detected build system: distutils (certainty: 60%)
I: pybuild pybuild:272: mkdir -p 
/build/mu-editor-1.1.0~alpha2+dfsg/.pybuild/cpython3_3.7_mu-editor/build/mu/resources/fonts;
 cp /usr/share/fonts/truetype/inconsolata/Inconsolata.otf 
/build/mu-editor-1.1.0~alpha2+dfsg/.pybuild/cpython3_3.7_mu-editor/build/mu/resources/fonts/Inconsolata.otf
D: pybuild tools:232: invoking: mkdir -p 
/build/mu-editor-1.1.0~alpha2+dfsg/.pybuild/cpython3_3.7_mu-editor/build/mu/resources/fonts;
 cp /usr/share/fonts/truetype/inconsolata/Inconsolata.otf 
/build/mu-editor-1.1.0~alpha2+dfsg/.pybuild/cpython3_3.7_mu-editor/build/mu/resources/fonts/Inconsolata.otf
I: pybuild base:217: cd 
'/build/mu-editor-1.1.0~alpha2+dfsg/.pybuild/cpython3_3.7_mu-editor/build'; 
python3.7 -m pytest --random-order
D: pybuild tools:232: invoking: cd 
'/build/mu-editor-1.1.0~alpha2+dfsg/.pybuild/cpython3_3.7_mu-editor/build'; 
python3.7 -m pytest --random-order
= test session starts ==
platform linux -- Python 3.7.3, pytest-3.10.1, py-1.7.0, pluggy-0.8.0
Using --random-order-bucket=module
Using --random-order-seed=926224

rootdir: /build/mu-editor-1.1.0~alpha2+dfsg, inifile:
plugins: xvfb-1.0.0, random-order-1.0.4
Aborted
E: pybuild pybuild:341: test: plugin distutils failed with: exit code=134: cd 
'/build/mu-editor-1.1.0~alpha2+dfsg/.pybuild/cpython3_3.7_mu-editor/build'; 
python3.7 -m pytest --random-order
Traceback (most recent call last):
  File "/usr/bin/pybuild", line 338, in main
run(func, i, version, c)
  File "/usr/bin/pybuild", line 289, in run
result = func(context, args)
  File "/usr/share/dh-python/dhpython/build/base.py", line 267, in wrapped_func
raise Exception(msg)
Exception: exit code=134: cd 
'/build/mu-editor-1.1.0~alpha2+dfsg/.pybuild/cpython3_3.7_mu-editor/build'; 
python3.7 -m pytest --random-order
dh_auto_test: pybuild --test -i python{version} -p 3.7 returned exit code 13
make[1]: *** [debian/rules:42: override_dh_auto_test] Error 25
make[1]: Leaving directory '/build/mu-editor-1.1.0~alpha2+dfsg'
make: *** [debian/rules:25: binary] Error 2
dpkg-buildpackage: error: debian/rules binary subprocess returned exit status 2





-- 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 Architectu

Bug#955425: libopenhmd0: No udev rules provided for device access

2020-03-31 Thread Ryan Pavlik

Package: libopenhmd0
Severity: wishlist

Dear Maintainer,

In order for OpenHMD to access the input devices it's designed to use,
permissions or udev rules are needed.

Currently, the package does not provide any, as upstream only provides 
instructions
for making your own.

I have recently filed an ITP for "xr-hardware", a package solely
intended to contain freely-licensed, best-practice udev rules for this hardware,
for use as a DFSG clean dependency or Recommends for OpenHMD and other related
software.

https://bugs.debian.org/955424

Thanks,

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.4-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 libopenhmd0 depends on:
ii  libc6  2.28-10
ii  libhidapi-libusb0  0.8.0~rc1+git20140818.d17db57+dfsg-2

libopenhmd0 recommends no packages.

libopenhmd0 suggests no packages.

Bug#955424: ITP: xr-hardware -- udev rules files for normal user access to XR input devices

2020-03-31 Thread Ryan Pavlik

Package: wnpp
Severity: wishlist
Owner: Ryan Pavlik 

* Package name: xr-hardware
  Version : 0.2.1
  Upstream Author : Ryan Pavlik 
* URL : https://gitlab.freedesktop.org/monado/utilities/xr-hardware
* License : BSL-1.0
  Programming Lang: udev rules, generated by Python
  Description : udev rules files for normal user access to XR input devices

This package contains a udev rules file to permit access to virtual
reality (VR) and augmented reality (AR), collectively "XR",
interaction devices as a normal user.

--

I am the upstream maintainer of this package. It is used by (recent ITP)
monado, but also can be used by other packaged software, including libopenhmd,
which currently instruct users to manually create a udev file.
This is why I have chosen to maintain it separately and package it separately.

Also, it is a free partial alternative to the steam-devices non-free package for
the Steam-related devices that are VR/AR related. In addition to the DFSG-free
license, it also follows best practices for udev rules more closely.
(using uaccess instead of setting group and permissions directly, etc.)

I will maintain this package along with Monado.

Bug#955423: ITP: monado -- Implementation (preview) of the OpenXR API

2020-03-31 Thread Ryan Pavlik

Package: wnpp
Severity: wishlist
Owner: Ryan Pavlik 

* Package name: monado
  Version : 0.1.0
  Upstream Author : Jakob Bornecrantz 
* URL : https://gitlab.freedesktop.org/monado/monado
* License : BSL-1.0, some parts Apache-2.0
  Programming Lang: Primarily C, some C++
  Description : Implementation (preview) of the OpenXR API

Monado is an open-source package for interacting with virtual and
augmented reality (collectively known as XR) hardware and software.

This package provides a runtime that is intended to meet the
conformance tests for the OpenXR API after further development and once
those tests are released.

--

I co-maintain the upstream package. Despite the version number and the
mandatory disclaimer about conformance, the runtime is suitable
for some use already. To my knowledge, it is the only
project currently aiming to provide an OpenXR runtime on Linux.

I will maintain the package, with help (and sponsorship)
from my colleagues.

Bug#955383: terminator: URLs are not clickable

2020-03-30 Thread Ryan Pavlik



On 3/30/20 4:21 PM, Antonio Terceiro wrote:
> Control: tag -1 + patch
> 
> On Mon, Mar 30, 2020 at 05:45:33PM -0300, Antonio Terceiro wrote:
>> Package: terminator
>> Version: 1.91-4
>> Severity: normal
>>
>> I just installed terminator. All the documentation I found, and the
>> preferences dialog, led me to expect URLs to be clickable. However, they
>> are not. They work just find on gnome-terminal in the same machine, so
>> maybe there is something wrong with how terminator talks to vte for it.
> 
> Looking up the vte documentation online, it suggests that
> add_match_gregex was deprecated some time ago, and made a noop at some
> point.
> 
> The attached patch seems to fix it for me. I will be running it for the
> text days and will let you know if I find any issue with it.
> 

For what it's worth, at least on Buster, I can click URLs - ctrl-click
makes them open, just like some other terminals I've used.

Ryan



signature.asc
Description: OpenPGP digital signature

Bug#953506: Updated version

2020-03-27 Thread Ryan Pavlik

NOTE:
This is an updated upstream version: the pypi package now includes the
unit tests, so they're included both in the build process and as
autopkgtests, in addition to the other upstream changes.

Dear mentors,

I am looking for a sponsor for my package "click-man"


 * Package name: click-man
   Version : 0.4.1-1
   Upstream Author : Timo Furrer 
 * URL : https://github.com/click-contrib/click-man
 * License : Expat
 * Vcs : https://salsa.debian.org/rpavlik-guest/click-man
   Section : devel

It builds those binary packages:

  python3-click-man - Generate man pages for click based CLI
applications (Python 3)
  click-man - Generate man pages for click based CLI applications -
command (Python 3)

To access further information about this package, please visit the
following URL:

  https://mentors.debian.net/package/click-man

Alternatively, one can download the package with dget using this command:

  dget -x
https://mentors.debian.net/debian/pool/main/c/click-man/click-man_0.4.1-1.dsc

Changes since the last upload:

   * Initial Release. (Closes: #924099)

Regards,

--
  Ryan A. Pavlik

Bug#954998: update

2020-03-27 Thread Ryan Pavlik

On 3/26/20 11:58 AM, gregor herrmann wrote:
> On Thu, 26 Mar 2020 11:23:23 -0500, Ryan Pavlik wrote:
> 
>> OK, I found lintian 2.55.0~bpo10+1 on snapshot.d.o, and cme edit dpkg
>> works fine there. So, some change between lintian 2.55.0~bpo10+1 and
>> 2.57.0~bpo10+1 broke cme edit dpkg.
> 
> Right, that was lintian 2.57.0 breaking libconfig-model-dpkg-perl;
> the latter is fixed in version 2.132.
> 
> For some background cf.
> https://lists.debian.org/debian-perl/2020/03/msg00027.html
> 
> Maybe lintian should add a "Breaks: libconfig-model-dpkg-perl (<<
> 2.132)" …
> And maybe we should create a backport for libconfig-model-dpkg-perl …
> 
> Cheers,
> gregor
> 

Ah, right, didn't realize that. Yeah, both a Breaks: clause and a
libconfig-model-dpkg-perl backport would be good ideas.
If nothing else, the "Breaks" in the backported lintian would presumably
block the update from backports without much hassle.

I'm not sure I'm the right person to do the backporting of this because
of the deps tree, but I did give it a shot. I backported licensecheck
and its deps libregexp-pattern-perl and libregexp-pattern-license-perl,
and have uploaded them to mentors.d.n. However, I got an error when
trying to backport libconfig-model-dpkg-perl against those new deps,
looks like the libconfig-model-tester-perl Build-Depends is too loose:

Config::Model::Tester version 4.002 required--this is only version 3.007
at t/model_tests.t line 6.
BEGIN failed--compilation aborted at t/model_tests.t line 6.
t/model_tests.t ..
Dubious, test returned 255 (wstat 65280, 0xff00)
No subtests run

I tightened the build-depends and backported libconfig-model-tester-perl
too, which was enough to get libconfig-model-dpkg-perl to build
properly, so those two are also up on mentors:
https://mentors.debian.net/packages/uploader/ryan%40ryanpavlik.com

I have also pushed debian/buster branches for all these repos to my
salsa account: https://salsa.debian.org/rpavlik-guest

Naturally if you'd find time or someone willing to verify the backports
whole deps tree for cme's dpkg module, I'd be very grateful, but I am
handling it OK for now. I can install my local backports, if nothing else.

Ryan

signature.asc
Description: OpenPGP digital signature

Bug#954998: update

2020-03-26 Thread Ryan Pavlik

control: affects -1 lintian

OK, I found lintian 2.55.0~bpo10+1 on snapshot.d.o, and cme edit dpkg
works fine there. So, some change between lintian 2.55.0~bpo10+1 and
2.57.0~bpo10+1 broke cme edit dpkg.

Ryan

Bug#954998: libconfig-model-dpkg-perl: cme edit dpkg does not start

2020-03-26 Thread Ryan Pavlik

Package: libconfig-model-dpkg-perl
Version: 2.122
Severity: important

Dear Maintainer,

Recently, I have had cme edit dpkg stop working on my Buster system, which is 
mostly clean,
with some use of buster-backports. This seemed to occur in conjunction with an 
update in which 
lintian was upgraded - lintian (2.59.0~bpo10+1) over (2.55.0~bpo10+1). However, 
downgrading
(to 2.57~bpo10+1 at least) did not resolve it, so perhaps it was something 
unrelated.
(the only other possibly-related update in that batch was libicu63/libicu-dev.)

The error message I get, no matter the package I run it on, is:

Reading package lists... Done
Building dependency tree   
Reading state information... Done
Single parameters to new() must be a HASH ref data => debian at 
/usr/share/perl5/Config/Model/Dpkg/Control/Source/StandardVersion.pm line 15.
Compilation failed in require at /usr/share/perl5/Config/Model/Node.pm line 
247,  line 84.

I have in the past attempted to backport newer versions of this package and its 
deps,
but as it introduced a number of dependencies I was unfamiliar with, I did give 
up rather quickly,
and I don't believe I have any of them installed.

Thanks for any help.

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 libconfig-model-dpkg-perl depends on:
ii  libapt-pkg-perl0.1.34+b1
ii  libarray-intspan-perl  2.003-1
ii  libconfig-model-backend-yaml-perl  2.133-2
ii  libconfig-model-perl   2.133-1
ii  libexporter-lite-perl  0.08-1
ii  liblog-log4perl-perl   1.49-1
ii  libmouse-perl  2.5.6-1+b1
ii  libparse-recdescent-perl   1.967015+dfsg-2
ii  libsoftware-licensemoreutils-perl  1.004-1
ii  libtext-autoformat-perl1.74-2
ii  libtext-levenshtein-damerau-perl   0.41-1
ii  liburi-perl1.76-1
ii  libwww-perl6.36-2
ii  libyaml-perl   1.27-1
ii  licensecheck   3.0.31-3
ii  lintian2.57.0~bpo10+1
ii  perl [libmodule-corelist-perl] 5.28.1-6

Versions of packages libconfig-model-dpkg-perl recommends:
ii  libconfig-model-tkui-perl  1.369-2

libconfig-model-dpkg-perl suggests no packages.

-- no debconf information

Bug#954092: meshlab: none

2020-03-16 Thread 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#886580: meshlab crashes on empty .stl

2020-03-16 Thread Ryan Pavlik

Control: tags -1 + fixed-upstream pending

Looks like this is fixed upstream in the newest release, which I have
sitting on Mentors ready for review and upload:
https://mentors.debian.net/package/meshlab


On Sun, 7 Jan 2018 19:52:55 + Ian Jackson
 wrote:
> Package: meshlab
> Version: 1.3.2+dfsg1-3
> Severity: minor
> 
> This silly file causes it to crash.  It ought to print an error
> message, but not actually crash.
> 
> (FAOD the fact that the file is empty is almost certainly not admesh's
> fault - it'll be my fault.)
> 
> zealot:play> cat t.stl 
> solid  Processed by ADMesh version 0.98.2
> endsolid  Processed by ADMesh version 0.98.2
> zealot:play> meshlab t.stl 
> Current Plugins Dir is: /usr/lib/meshlab/plugins 
> Reading Param with name MeshLab::Appearance::backgroundBotColor : 
> RichColor
> Reading Param with name MeshLab::Appearance::backgroundTopColor : 
> RichColor
> Reading Param with name MeshLab::Appearance::baseLightAmbientColor : 
> RichColor
> Reading Param with name MeshLab::Appearance::baseLightDiffuseColor : 
> RichColor
> Reading Param with name MeshLab::Appearance::baseLightSpecularColor : 
> RichColor
> Reading Param with name MeshLab::Appearance::fancyBLightDiffuseColor : 
> RichColor
> Reading Param with name MeshLab::Appearance::fancyFLightDiffuseColor : 
> RichColor
> Reading Param with name MeshLab::Appearance::logAreaColor : RichColor
> Reading Param with name MeshLab::Appearance::pointDistanceAttenuation : 
> RichBool
> Reading Param with name MeshLab::Appearance::pointSize : RichFloat
> Reading Param with name MeshLab::Appearance::pointSmooth : RichBool
> Reading Param with name MeshLab::Appearance::textureMagFilter : RichEnum
> Reading Param with name MeshLab::Appearance::textureMinFilter : RichEnum
> Reading Param with name MeshLab::Decoration::AreaHistParam : RichBool
> Reading Param with name MeshLab::Decoration::BoxRatio : RichFloat
> Reading Param with name MeshLab::Decoration::CameraFixedScaleParam : 
> RichFloat
> Reading Param with name MeshLab::Decoration::CameraInfoType : RichEnum
> Reading Param with name MeshLab::Decoration::CameraRenderScaleType : 
> RichEnum
> Reading Param with name MeshLab::Decoration::CameraShowCameraDetails : 
> RichBool
> Reading Param with name MeshLab::Decoration::CameraShowFrustum : RichBool
> Reading Param with name MeshLab::Decoration::CubeMapPath : RichString
> Reading Param with name MeshLab::Decoration::FixedHistMaxParam : RichFloat
> Reading Param with name MeshLab::Decoration::FixedHistMinParam : RichFloat
> Reading Param with name MeshLab::Decoration::FixedHistWidthParam : 
> RichFloat
> Reading Param with name MeshLab::Decoration::GridBack : RichBool
> Reading Param with name MeshLab::Decoration::GridColorBack : RichColor
> Reading Param with name MeshLab::Decoration::GridColorFront : RichColor
> Reading Param with name MeshLab::Decoration::GridMajor : RichFloat
> Reading Param with name MeshLab::Decoration::GridMinor : RichFloat
> Reading Param with name MeshLab::Decoration::GridSnap : RichBool
> Reading Param with name MeshLab::Decoration::HistBinNumParam : RichInt
> Reading Param with name MeshLab::Decoration::NormalLength : RichFloat
> Reading Param with name MeshLab::Decoration::ProjRasterAlpha : 
> RichDynamicFloat
> Reading Param with name MeshLab::Decoration::ProjRasterLighting : RichBool
> Reading Param with name MeshLab::Decoration::ProjRasterOnAllMeshes : 
> RichBool
> Reading Param with name MeshLab::Decoration::ProjRasterUseVBO : RichBool
> Reading Param with name MeshLab::Decoration::SSAORadius : RichFloat
> Reading Param with name MeshLab::Decoration::ShadowIntensityVal : 
> RichDynamicFloat
> Reading Param with name MeshLab::Decoration::ShadowMethod : RichEnum
> Reading Param with name MeshLab::Decoration::ShowBorderFlag : RichBool
> Reading Param with name MeshLab::Decoration::ShowMeshCameras : RichBool
> Reading Param with name MeshLab::Decoration::ShowNonRegular : RichBool
> Reading Param with name MeshLab::Decoration::ShowRasterCameras : RichBool
> Reading Param with name MeshLab::Decoration::ShowSeparatrix : RichBool
> Reading Param with name MeshLab::Decoration::ShowShadow : RichBool

Bug#953506: RFS: click-man/0.3.0-1 [ITP] -- Generate man pages for click based CLI applications - command (Python 3)

2020-03-09 Thread Ryan Pavlik

Package: sponsorship-requests
Severity: normal [important for RC bugs, wishlist for new packages]

Dear mentors,

I am looking for a sponsor for my package "click-man"

 * Package name: click-man
   Version : 0.3.0-1
   Upstream Author : Timo Furrer 
 * URL : https://github.com/click-contrib/click-man
 * License : Expat
 * Vcs : https://salsa.debian.org/rpavlik-guest/click-man
   Section : devel

It builds those binary packages:

  python3-click-man - Generate man pages for click based CLI
applications (Python 3)
  click-man - Generate man pages for click based CLI applications -
command (Python 3)

To access further information about this package, please visit the
following URL:

  https://mentors.debian.net/package/click-man

Alternatively, one can download the package with dget using this command:

  dget -x
https://mentors.debian.net/debian/pool/main/c/click-man/click-man_0.3.0-1.dsc

Changes since the last upload:

   * Initial Release. (Closes: #924099)

Regards,

Ryan A. Pavlik



signature.asc
Description: OpenPGP digital signature

Bug#740678: (no subject)

2020-03-09 Thread Ryan Pavlik

Back in the day I was closely involved with AbiWord, including packaging
on Debian and Ubuntu. Since it's not a very fast-moving project right
now, I think I can safely offer to help keep it alive in Debian.

Ryan

Bug#953062: Update

2020-03-06 Thread 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#951904: Status

2020-03-06 Thread Ryan Pavlik

I have a work in progress package here that will resolve this issue.

Bug#629171: Update

2020-03-06 Thread Ryan Pavlik

The referenced RFP bugs have been closed for lack of activity. My most
recent work resolves this bug differently, by simply not exposing the
"broken" exporter. I've listed this bug in the changelog so it will be
closed once that package enters the archives.

Bug#953062: status update

2020-03-05 Thread 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

2020-03-05 Thread 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#924099: ITP

2020-03-04 Thread Ryan Pavlik

I now have a package for this tool up on mentors, seeking sponsorship.
(And yes, the package builds its own man pages with itself.)

https://mentors.debian.net/package/click-man

I have the source maintained on salsa at
https://salsa.debian.org/rpavlik-guest/click-man

Let me know if there are changes you'd recommend. (Besides mentioning
the ITP bug in the changelog) It is passing all the salsa-ci tests
except for the reprotest.

Thanks!

Ryan



signature.asc
Description: OpenPGP digital signature

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

2020-03-03 Thread 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

Bug#901245: x-terminal-emulator -e

2020-02-27 Thread Ryan Pavlik

This blocks updating policy version past 4.0.1 since 4.1.0 mandates that
-e works in this way:
https://www.debian.org/doc/debian-policy/ch-customized-programs.html#packages-providing-a-terminal-emulator


(This is the only item I've noticed in the upgrading checklist up
through 4.5.0)




signature.asc
Description: OpenPGP digital signature

Bug#947716: RFH: terminator -- multiple GNOME terminals in one window

2020-02-27 Thread Ryan Pavlik

I am also an active user. I have a few hours a week of "upstream" time
at work that I could look at this package during.


Ryan




signature.asc
Description: OpenPGP digital signature

Bug#924099: RFP: click-man -- Automate generation of man pages for python click applications

2020-02-25 Thread Ryan Pavlik

I created a package for this as a part of packaging a Click-based tool
where, as you described, I didn't like the manual options for manpage
creation. (Started with py2dsp output but have made it better than
that.) I'd be happy to collaborate with you on it.


Ryan


On Sat, 09 Mar 2019 16:05:08 +0100 Nicolas Braud-Santoni
 wrote:

> Package: wnpp
> Severity: wishlist
>
> * Package name : click-man
> Version : 0.3.0
> Upstream Author : Timo Furrer 
> * URL : https://github.com/click-contrib/click-man
> * License : MIT
> Programming Lang: Python
> Description : Automate generation of man pages for python click
> applications
> 
> 
> click-man is a tool that can automatically generate manpages for
> application
> written with the click CLI framework. It provides setuptools
> integration and
> can easily be used during the build of a Debian package:
> 
> https://github.com/click-contrib/click-man#debian-packages
> 
> 
> As far as I know, current packaging practices involve either
> 1. writing a manpage by hand, which is a lot of work
> 2. generating it ahead-of-time with help2man or somesuch, and
> commiting it to
> the debian/ directory, where it might get out-of-sync with the actual
> program
> 3. not shipping manpages at all :(
> 
> Automatically generating a manpage during package build would
> definitely be
> preferable to (2) and (3), and possibly to (1) if the result is of
> sufficient
> quality.
> 
> 
> I cannot currently commit to packaging and maintaining this package,
> hence why I
> am filing a RFP, and in any case I would probably appreciate having a
> comaintainer. :)
> 
> 
> Best,
> 
> nicoo
> 
>



0xCBC55E3D986A54C7.asc
Description: application/pgp-keys

Bug#946876: mingw32: Linking failure when using std::experimental::filesystem

2019-12-16 Thread Ryan Pavlik

Package: g++-mingw-w64-x86-64
Version: 8.3.0-6+21.3~deb10u1
Severity: normal
Tags: patch

Dear Maintainer,

I had some issues linking an application being built as C++14 and using the 
std::experimental::filesystem -
it mentioned unresolved "fs_err_concat" symbols. When researching it, I 
discovered this page,
which explained the exact message and contained a patch. 
https://patches-gcc.linaro.org/patch/12753/#22525

Apparently a change elsewhere removed a symbol that the experimental filesystem 
support was still using,
and my testing suggests that the Debian package lacks this patch.

I've added the patch to the Buster package here: 
https://salsa.debian.org/mingw-w64-team/gcc-mingw-w64/merge_requests/1
and I've confirmed that it applies and starts building - I didn't have the 
storage space to run the build
to completion locally.

The minimized test file is attached: the comment explains how to build and link 
as either C++17
(using std::filesystem - this works) or C++14 (using 
std::experimental::filesystem, produces the error)
I suspect newer upstream (e.g. not Buster) already contains the patch, but this 
test file should make it easy to check.

The error message is:

/usr/bin/x86_64-w64-mingw32-ld:
/usr/lib/gcc/x86_64-w64-mingw32/8.3-win32/libstdc++fs.a(path.o):(.text$_ZNSt12experimental10filesystem2v17__cxx1116filesystem_error11_M_gen_whatEv+0x639):
undefined reference to
`std::filesystem::fs_err_concat(std::__cxx11::basic_string, std::allocator > const&,
std::__cxx11::basic_string, std::allocator >
const&, std::__cxx11::basic_string,
std::allocator > const&)'

Thank you!

Ryan

-- System Information:
Debian Release: 10.2
  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.3.0-0.bpo.2-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 g++-mingw-w64-x86-64 depends on:
ii  gcc-mingw-w64-base8.3.0-6+21.3~deb10u1
ii  gcc-mingw-w64-x86-64  8.3.0-6+21.3~deb10u1
ii  libc6 2.28-10
ii  libgcc1   1:8.3.0-6
ii  libgmp10  2:6.1.2+dfsg-4
ii  libisl19  0.20-2
ii  libmpc3   1.1.0-1
ii  libmpfr6  4.0.2-1
ii  libstdc++68.3.0-6
ii  zlib1g1:1.2.11.dfsg-1

g++-mingw-w64-x86-64 recommends no packages.

Versions of packages g++-mingw-w64-x86-64 suggests:
pn  gcc-8-locales  

-- no debconf information

/*
This builds and links:

$ x86_64-w64-mingw32-g++ -std=c++17 demo.cpp -o demo17.o -Wl,--no-undefined
-lstdc++fs

This fails to link:

$ x86_64-w64-mingw32-g++ -std=c++14 demo.cpp -o demo14.o -Wl,--no-undefined
-lstdc++fs

/usr/bin/x86_64-w64-mingw32-ld:
/usr/lib/gcc/x86_64-w64-mingw32/8.3-win32/libstdc++fs.a(path.o):(.text$_ZNSt12experimental10filesystem2v17__cxx1116filesystem_error11_M_gen_whatEv+0x639):
undefined reference to
`std::filesystem::fs_err_concat(std::__cxx11::basic_string, std::allocator > const&,
std::__cxx11::basic_string, std::allocator >
const&, std::__cxx11::basic_string,
std::allocator > const&)'
*/

// If the C++ macro is set to the version containing C++17, it must support
// the final C++17 package
#if __cplusplus >= 201703L
#include 
namespace fs = std::filesystem;
#else
#include 
namespace fs = std::experimental::filesystem;
#endif

bool is_reg_file(const std::string &path) { return fs::is_regular_file(path); }
int main() {
(void)is_reg_file("/etc/os-release");
return 0;
}

Bug#946685: meshlab: Most current upstream builds without modification on Buster, re-packaging started but need help

2019-12-13 Thread Ryan Pavlik

Package: meshlab
Severity: important
Tags: patch

Dear Maintainer,

I saw that meshlab was removed due to build issues. I have done some work on it
upstream recently, including incorporating patches/functionality from the
debian package. It now builds easily with fewer patches - and my PR to add a
CMake build system (instead of qmake) was just accepted and will probably be in
a snapshot release https://github.com/cnr-isti-vclab/meshlab/releases tomorrow
or early next week.

I've tried to update the package - however, since the previous package, they've
split meshlab and vcglib so we're in a "multiple upstream tarballs" scenario
which I'm not very familiar with packaging. My work-in-progress (based on a
snapshot release of a few days ago) is here: https://salsa.debian.org/rpavlik-
guest/meshlab/tree/rp/update but I'd strongly recommend going with a version
that includes my CMake build system since it makes the dependency handling
smoother and more reliable.

I also tried to fix the issue in the most recent package that kept it from
being migrated - the desktop OpenGL usage isn't compatible with armel or armhf,
so I disabled those architectures the best I know how.

There is interest from users at upstream in using MeshLab in Debian, so
hopefully this package can be revived. I'm happy to help - I'm now pretty
familiar with the code structure and build system, and upstream has been
accepting my patches pretty readily recently.

Thanks,

Ryan

-- System Information:
Debian Release: 10.2
  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.3.0-0.bpo.2-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  libbz2-1.0  1.0.6-9.2~deb10u1
ii  libc6   2.28-10
ii  libgcc1 1:8.3.0-6
ii  libgl1  1.1.0-1
ii  libglew2.1  2.1.0-4
ii  libglu1-mesa [libglu1]  9.0.0-2.1+b3
ii  libmuparser2v5  2.2.6.1+dfsg-1
ii  libopenctm1 1.0.3+dfsg1-2+b1
ii  libqhull7   2015.2-4
ii  libqt4-network  4:4.8.7+dfsg-18
ii  libqt4-opengl   4:4.8.7+dfsg-18
ii  libqt4-script   4:4.8.7+dfsg-18
ii  libqt4-xml  4:4.8.7+dfsg-18
ii  libqt4-xmlpatterns  4:4.8.7+dfsg-18
ii  libqtcore4  4:4.8.7+dfsg-18
ii  libqtgui4   4:4.8.7+dfsg-18
ii  libstdc++6  8.3.0-6

Versions of packages meshlab recommends:
ii  chemical-mime-data  0.1.94-7

meshlab suggests no packages.

Bug#687664: devscripts-licensecheck: Does not recognize MPL 2.0

2012-09-14 Thread Ryan Pavlik

WWW browsable pager with excellent

-- no debconf information
>From 041f90cb124128cf74dc7db90185ffd36ec1cd0f Mon Sep 17 00:00:00 2001
From: Ryan Pavlik 
Date: Fri, 14 Sep 2012 15:18:37 -0500
Subject: [PATCH] Modify licensecheck to recognize the MPL v2.0.

It should recognize both as given in "Exhibit A" (no comma)
as well as used in Eigen post-relicensing (comma).

Tests have been added for MPL 1.1 (based on license text) as
well as the two variations of MPL 2.0 notices.

Signed-off-by: Ryan Pavlik 
---
 scripts/licensecheck.pl|  4 ++--
 test/licensecheck/mpl-1.1.sh   | 16 
 test/licensecheck/mpl-2.0-comma.sh |  5 +
 test/licensecheck/mpl-2.0.sh   |  5 +
 test/test_licensecheck |  6 ++
 5 files changed, 34 insertions(+), 2 deletions(-)
 create mode 100644 test/licensecheck/mpl-1.1.sh
 create mode 100644 test/licensecheck/mpl-2.0-comma.sh
 create mode 100644 test/licensecheck/mpl-2.0.sh

diff --git a/scripts/licensecheck.pl b/scripts/licensecheck.pl
index 26740e1..c5c7808 100755
--- a/scripts/licensecheck.pl
+++ b/scripts/licensecheck.pl
@@ -478,8 +478,8 @@ sub parselicense($) {
}
 }
 
-if ($licensetext =~ /Mozilla Public License Version ([^ ]+)/) {
-   $license = "MPL (v$1) $license";
+if ($licensetext =~ /Mozilla Public License,? (Version|v\.) 
(\d+(?:\.\d+)?)/) {
+   $license = "MPL (v$2) $license";
 }
 
 if ($licensetext =~ /Released under the terms of the Artistic License ([^ 
]+)/) {
diff --git a/test/licensecheck/mpl-1.1.sh b/test/licensecheck/mpl-1.1.sh
new file mode 100644
index 000..aa75a2a
--- /dev/null
+++ b/test/licensecheck/mpl-1.1.sh
@@ -0,0 +1,16 @@
+# The contents of this file are subject to the Mozilla Public License
+# Version 1.1 (the "License"); you may not use this file except in
+# compliance with the License. You may obtain a copy of the License at
+# http://www.mozilla.org/MPL/
+#
+# Software distributed under the License is distributed on an "AS IS"
+# basis, WITHOUT WARRANTY OF ANY KIND, either express or implied. See the
+# License for the specific language governing rights and limitations
+# under the License.
+# 
+# The Original Code is debian devscripts code.
+#
+# The Initial Developer of the Original Code is
+# devscripts developers.
+# Portions created by the Initial Developer are Copyright (C) 2012
+# the Initial Developer. All Rights Reserved.
diff --git a/test/licensecheck/mpl-2.0-comma.sh 
b/test/licensecheck/mpl-2.0-comma.sh
new file mode 100644
index 000..caf2954
--- /dev/null
+++ b/test/licensecheck/mpl-2.0-comma.sh
@@ -0,0 +1,5 @@
+# Copyright devscripts developers
+#
+# This Source Code Form is subject to the terms of the Mozilla Public
+# License, v. 2.0. If a copy of the MPL was not distributed with this
+# file, You can obtain one at http://mozilla.org/MPL/2.0/.
diff --git a/test/licensecheck/mpl-2.0.sh b/test/licensecheck/mpl-2.0.sh
new file mode 100644
index 000..1ce4472
--- /dev/null
+++ b/test/licensecheck/mpl-2.0.sh
@@ -0,0 +1,5 @@
+# Copyright devscripts developers
+#
+# This Source Code Form is subject to the terms of the Mozilla Public
+# License v. 2.0. If a copy of the MPL was not distributed with this
+# file, You can obtain one at http://mozilla.org/MPL/2.0/.
diff --git a/test/test_licensecheck b/test/test_licensecheck
index e7178df..fb67859 100755
--- a/test/test_licensecheck
+++ b/test/test_licensecheck
@@ -48,6 +48,12 @@ testDual() {
 license "dual.c" "Public domain GPL (v3)"
 }
 
+testMPL() {
+   license "mpl-1.1.sh" "MPL (v1.1)"
+   license "mpl-2.0.sh" "MPL (v2.0)"
+   license "mpl-2.0-comma.sh" "MPL (v2.0)"
+}
+
 testMachine() {
 license2 "-m" "beerware.cpp" "Beerware"
 license2 "--machine" "lgpl-2.1.h" "LGPL (v2.1)"
-- 
1.7.11.3

55 matches

Mail list logo