Re: RFC: yet another list of data duplicated: public-suffix.txt
Hi, On 31/10/2018 10:07, Bastien ROUCARIES wrote: > It seems that public-suffix.txt from mozilla fundation is embeded in a > few package. > > The Public Suffix List is a catalog of certain Internet domain names. > The term is also known by the form effective top-level domain (eTLD). > The Mozilla Foundation maintains suffix list for the security and > privacy policies of its Firefox web browser, though it is available > for other uses under the Mozilla Public License (MPL). > > This list is therefore security sensitive. > > I suppose the way to go is to create a data package and get a MBF > after getting a consensus here. > > Any volontuers for the packaging ? It's already packaged: https://tracker.debian.org/pkg/publicsuffix Do you have a list of packages which need fixing? Can you add a lintian check for this? James signature.asc Description: OpenPGP digital signature
Re: Nutty systemd package dependencies
On 28/08/16 12:43, Jonathan de Boyne Pollard wrote: > Simon McVittie: > >> Once per thread about systemd, I point out that dbus-daemon links to >> both libapparmor and libselinux - which results in at least one >> useless library for literally everyone with dbus installed, since >> "major" LSMs don't stack, so nobody can possibly be using both >> AppArmor and SELinux at the same time. Oddly enough, nobody has >> complained about that, only about libsystemd... >> > Which rather neatly brings us to something that I've been wondering > about for some time. It's a pointless package dependency. But for > novelty it's one that the people who *use* systemd might be interested > in, rather than the people who *want to avoid* systemd. > > Consider the "initscripts" package. > > The "systemd" package has an explicit package dependency from it (in > both Debian 8 and the prospective Debian 9). > > * > https://anonscm.debian.org/cgit/pkg-systemd/systemd.git/tree/debian/control?h=debian/215-18&id=b1e8aa81062a0fcbcc27b99144521579ab873245#n56 That commit is from systemd 215-18 which is over a year old. The version of systemd in unstable has no such dependency. In fact I don't even have initscripts installed on my laptop. You can read the systemd changelog to see why it was originally needed. James signature.asc Description: OpenPGP digital signature
Bug#839185: ITP: libopenmpt -- module music decoding library based on OpenMPT
Package: wnpp Severity: wishlist Owner: James Cowgill X-Debbugs-Cc: debian-devel@lists.debian.org * Package name: libopenmpt Version : 0.2.7025~beta20.1 Upstream Author : OpenMPT contributors * URL : https://lib.openmpt.org/libopenmpt/ * License : BSD-3-clause Programming Lang: C++ Description : module music decoding library based on OpenMPT libopenmpt is a cross-platform C++ and C library to decode tracked music files (modules) into a raw PCM audio stream. It is based on the player code of the OpenMPT project, a descendant of the original ModPlug Tracker. I intend to maintain this package as part of the Debian Multimedia Team. The existing libmodplug is also descended from the ModPlug Tracker like libopenmpt. libopenmpt specifically aims for more accurate decoding compared to libmodplug, and is currently more activly developed (by virtue of being part of a larger project). signature.asc Description: OpenPGP digital signature
Re: Interface of `shutdown', 'halt', ... programs
Hi, On 06/10/16 11:51, Dmitry Bogatov wrote: >>> #838480 >>> [...] >>> Any suggestions? >> >> Is it possible to use a pointyclicky desktoppy widgety thing to reboot >> a system with runit ? I guess from your mails you use the command >> line. >> [...] >> I think if I were you I would try installing a system with runit and >> GNOME, make enough of an emulation that the GNOME shutdown and reboot >> functions work, and call that "done". > > Thank you for your advice, Ian. You guessed correctly -- 'sudo init 0' is > good enough for me and I have little knowledge about "pointy-clicky" > things. While I can install GNOME on virtual machine (sigh) there are > also other desktop enviroments (KDE, XFCE, ...). > > Is there some common way to get "pointy-clicky widget"? I assume > (correct me, if I am wrong) all desktop enviroments share some > mechanism how to invoke root-only command (shutdown) as regular user, > so there may be way to invoke just shutdown menu, without need other > parts of desktop enviroments. GNOME does this using logind which is probably the closest you'd get to a common interface for this. If using systemd-shim to implement logind for runit, you would need to provide the shutdown and reboot commands used here: https://sources.debian.net/src/systemd-shim/10-2/src/power-unit.c/ James signature.asc Description: OpenPGP digital signature
Re: Someone can upload "verilog-mode" package as sponsor?
Hi, On 11/10/16 13:22, Kiwamu Okabe wrote: > Someone can upload "verilog-mode" package as sponsor? > The ITP number is #840413: > > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=840413 > > The debian source package is found at following: > > https://anonscm.debian.org/cgit/collab-maint/verilog-mode.git Read these pages: https://mentors.debian.net/intro-maintainers https://mentors.debian.net/sponsors Then file an RFS bug. James signature.asc Description: OpenPGP digital signature
Re: Doxygen has 3 RC bugs preventing packages to build - is droping documentation a sensible option?
On 28/10/16 12:09, Andreas Tille wrote: > Hi, > > I really want to update cimg since a long time, missing several upstream > releases but I cimg does not build due to #836168. In the bug report it > was also suggested to use sphinx as doxygen replacement but I'm not sure > how sensible this might be since upstream is using doxygen. I just tried building the version of cimg in its git repo and it worked fine... It looks like the % and & handling was fixed in doxygen 1.8.12 which is in unstable. I expect there is a bug somewhere involving URL fragments, but it no longer affects cimg. James signature.asc Description: OpenPGP digital signature
Re: Bug#820780: clarify syntax of ‘cancel’ command for queue control
On 26/12/16 21:36, Ben Finney wrote: > Is this constraint – the argument to ‘cancel’ *must* be a base > filename only – imposed by the upload queue processor? If so, the > response: > >> .commands file has invalid Commands line: cancel >> ../pytest-django_2.9.1-2.1_amd64.changes >> debsign: .commands file appears to be invalid. see: >> ftp://ftp.upload.debian.org/pub/UploadQueue/README >> for valid format > > is not very helpful, because the referenced document does not make > that constraint plain. > > > I'm casting this to ‘debian-devel’ for confirmation whether this is > actually the problem. Can someone with knowledge of the upload queue > processing clarify this? On the archive side, arguments to 'cancel' must match this regex: https://anonscm.debian.org/cgit/mirror/dak.git/tree/tools/debianqueued-0.9/debianqueued#n71 which is used here: https://anonscm.debian.org/cgit/mirror/dak.git/tree/tools/debianqueued-0.9/debianqueued#n1294 Forward slash is not in the regex, so paths are disallowed. James signature.asc Description: OpenPGP digital signature
Re: Bug#899299: libu2f-udev: Post-inst script should make udev reload rules
Hi, On 03/06/18 16:08, Nicolas Braud-Santoni wrote: > X-Debbugs-CC: debian-devel@lists.debian.org > > Hi Debianites ! > > On Tue, May 22, 2018 at 10:23:33AM +0200, Nicolas Braud-Santoni wrote: >> [libu2f-udev's post-inst script should make udev reload rules.] >> Otherwise, the rules are not active until the next reboot (or until the user >> manually calls `udevadm control -R`). > > To fix this bug, I need to call `udevadm` from the postinstall script, > meaning that libu2f-udev needs to Pre-Depends on udev. Running a command from another package in postinst only requires a normal Depends - not a Pre-Depends. However, I don't think you need to run "udevadm control -R" at all. udev will monitor rules from /lib/udev/rules.d while its running and automatically reload them when changed. For the second half of this bug: > Consider investigating whether it is possible to apply the udev rules to > already-plugged-in devices (as setting tag uaccess should be idempotent). This can be done by running "udevadm trigger". By default every device on the system will be triggered which is a bit heavyweight, so you probably want to add some *match parameters to restrict this to the devices you're interested in (see the udevadm man page). James signature.asc Description: OpenPGP digital signature
Bug#905096: ITP: aom -- AV1 Video Codec Library
Package: wnpp Severity: wishlist Owner: James Cowgill X-Debbugs-Cc: debian-devel@lists.debian.org * Package name: aom Version : 1.0.0 Upstream Author : Alliance for Open Media * URL : https://aomedia.org/ * License : BSD-2-Clause Programming Lang: C Description : AV1 Video Codec Library AOMedia Video 1 (AV1) is an open and royalty free video encoding format optimized for the Internet and the successor of VP9. aom is the reference encoder and decoder implementation published by the Alliance for Open Media. I intend to maintain this package as part of the Debian Multimedia Team. James signature.asc Description: OpenPGP digital signature
Bug#856165: ITP: pupnp-1.8 -- Portable SDK for UPnP Devices, version 1.8
Package: wnpp Severity: wishlist Owner: James Cowgill X-Debbugs-Cc: debian-devel@lists.debian.org, n...@leverton.org * Package name: pupnp-1.8 Version : 1.8.0 Upstream Author : Intel Corporation, Marcelo Roberto Jimenez * URL : http://pupnp.sourceforge.net/ * License : BSD Programming Lang: C Description : Portable SDK for UPnP Devices, version 1.8 The Portable SDK for UPnP Devices (libupnp) provides developers with an API and open source code for building control points, devices, and bridges that are compliant with Version 1.0 of the Universal Plug and Play Device Architecture Specification - see http://www.upnp.org/ for specifications. Version 1.8 has been a work in progress for many years and makes a number of API changes compared to version 1.6. It's designed to be co-installable with libupnp 1.6. Upstream are planning to continue maintaining the 1.6 branch since it's much more widely used. It's currently only available on GitHub: https://github.com/mrjimenez/pupnp pupnp-1.8 is needed for packaging the active fork of mediatomb which I'm having a look into. This fork solves the current issues facing the mediatomb package which bundles a heavily patched version of libupnp containing a number of security issues. I'm CCing the maintainer for libupnp, although I have a strong feeling he is MIA. Thanks, James signature.asc Description: OpenPGP digital signature
Bug#863719: ITP: gerbera -- UPnP Media Server
Package: wnpp Severity: wishlist Owner: James Cowgill X-Debbugs-Cc: debian-devel@lists.debian.org * Package name: gerbera Version : 1.0.0 Upstream Author : Ian Whyman * URL : https://gerbera.io/ * License : GPL-2 Programming Lang: C++ Description : UPnP Media Server Gerbera is a UPnP media server, originally based on MediaTomb, which allows you to stream your digital media through your home network and consume it on a variety of UPnP compatible devices. This package is intended to replace MediaTomb which has been abandoned upstream. I intend to package this as part of the Debian Multimedia Team. Thanks, James signature.asc Description: OpenPGP digital signature
Re: versioned Provides status
Hi, On 18/06/17 19:26, Niko Tyni wrote: > [bcc'd -release as a heads-up, but I guess this should stay on -devel] > > Hi, and thanks to everybody who contributed to the stretch release! > > As discussed in #758100, I'd like to switch to using versioned Provides > in perl/perl-base/perl-modules-5.xx for buster. I'd be interested to > hear if anybody knows of any remaining blockers for that. > > The change is already in place in experimental for the Perl 5.26 packages, > and our test rebuilds indicate things seem to be working OK. The issues > on the archive / infrastructure side that I'm aware of have been fixed: > > - britney support has been in place for a year (#786803) > > - wanna-build should be fine with the dose3 in stretch (#786671) > > There's an open policy bug about this in #761219. I see a dozen or so > packages (mostly PHP related) in sid already seem to be using versioned > Provides, so the archive does seem ready, but I'm trying to play it > safe with such core packages as the src:perl ones. > > My current thinking would be not to couple this change with the future > Perl 5.26 transition, so I'm planning to push this into sid (= the 5.24 > packages) soonish. Unless there's a reason not to? One thing I did notice recently was #864906 in apt-cudf where versioned provides broke the acuspd resolver slightly. I guess this will only affect experimental builds though (where that resolver is used). James signature.asc Description: OpenPGP digital signature
Re: Why small "Uncompressed Size: 2,048" for ssmtp
Hi, On 11/09/17 15:11, Osamu Aoki wrote: > I am wondering what makes aptitude screen to print: > Compressed Size: 54.2 k > Uncompressed Size: 2,048 > Source Package: ssmtp > for ssmtp package. > > Uncompressed size is usually bigger than compressed Size. > Am I missing something. > > INFO file in the ssmtp deb package has: > > new debian package, version 2.0. > size 54172 bytes: control archive=17623 bytes. > 58 bytes, 2 lines conffiles > 1082 bytes,64 lines * config #!/bin/sh > 940 bytes,21 lines control > 2312 bytes,96 lines * postinst #!/bin/sh > 362 bytes,26 lines * postrm #!/bin/sh > 367 bytes,21 lines * preinst #!/bin/sh >38672 bytes, 317 lines templates > Package: ssmtp > Source: ssmtp (2.64-8) > Version: 2.64-8+b2 > Architecture: amd64 > Maintainer: Anibal Monsalve Salazar > Installed-Size: 2 > > This 2 is in KB. iConsistent with aptitude but why so small??? The debian/rules file calls dpkg-gencontrol before installing anything, so dpkg-gencontrol doesn't "see" any of the binaries when calculating the installed size. https://sources.debian.net/src/ssmtp/2.64-8/debian/rules/ Maybe it should start using debhelper... James signature.asc Description: OpenPGP digital signature
Re: changing source and binary package names
Hi, On 18/12/17 13:06, Osamu Aoki wrote: > Hi, > > When changing only the binary package name, it is easy to do it. All I > have to do is package an empty transitional package with the old binary > package name in its new source package with proper dependencies and > upload it :-) > > But what is needed when changing both the source and binary package name > together? > > Specifically for getmail upstream is moving to version 5.4 now and > Debian unstable has now: > > * source: getmail4 (upstream 4.53 based) >* Binary: getmail4 > > * source: getmail (upstream 5.4 based) >* Binary: getmail > > Here, getmail packaeg is compatible replacement of getmail4 package. > > I am thinking to add getmal4 dummy transitional package to getmail > source package and upload it. This seems reasonable to me. > Can I upload such binary dummy package now when there is an older > package in unstable? Yes, your upload will replace the existing getmal4 binary package in the archive. > Should I ask getmail4 source package removal to ftp master before > uploading the dummy transitional package? Or should I do it after? Probably after so your getmail upload doesn't have to go through NEW. James signature.asc Description: OpenPGP digital signature
Re: promoting virtualbox-dkms to virtualbox pre-depends
Hi, On Tue, 2015-09-22 at 15:00 +, Gianfranco Costamagna wrote: > As shown in policy 7.2 > > "You should not specify a Pre-Depends entry for a package before this > has been discussed on the debian-devel mailing > list and a consensus about doing that has been reached. See > Dependencies, Section 3.5." > > the problem actually is that virtualbox-dkms should be configured > *before* configuring virtualbox, otherwise > without a built kernel module, restarting VMs > will fail and lead to an half-configured package. > > Please see bugs #798527 and #798979 as examples. This should work with a normal Depends relation (reread Policy 7.2). This commit helped since it prevented a circular dependency involving the two packages: https://anonscm.debian.org/cgit/pkg-virtualbox/virtualbox.git/commit/?id=68f57408199e304df63285910a360bc2f6ae2372 So after that commit, a normal Depends from virtualbox to virtualbox -dkms should be all that's nessesary. Thanks, James signature.asc Description: This is a digitally signed message part
Re: promoting virtualbox-dkms to virtualbox pre-depends
Hi, On Tue, 2015-09-22 at 16:40 +, Gianfranco Costamagna wrote: > Hi James! > > > This should work with a normal Depends relation (reread Policy 7.2). > > > > This commit helped since it prevented a circular dependency involving > > the two packages: > > https://anonscm.debian.org/cgit/pkg-virtualbox/virtualbox.git/commit/?id=68f57408199e304df63285910a360bc2f6ae2372 > > > > So after that commit, a normal Depends from virtualbox to virtualbox > > -dkms should be all that's nessesary. > > thanks for the useful pointer, I admit I get headache when I have to deal > with such things :) > > however, according to the debdiff of the fix: [...] > prior the virtualbox-dkms | virtualbox-source was in Recommends, not in > Depends. > > was it really a circular dependency? No sorry I meant that if you had added a normal Depends without the above commit, you would have created a circular dependency. Before these changes, the dependency from virtualbox-dkms to virtualbox was causing virtualbox to always be configured first. James signature.asc Description: This is a digitally signed message part
Bug#801133: ITP: node-tern -- JavaScript code analyzer for text editors
Package: wnpp Severity: wishlist Owner: James Cowgill X-Debbugs-CC: debian-devel@lists.debian.org * Package name: node-tern Version : 0.15.0 Upstream Author : Marijn Haverbeke * URL : https://github.com/marijnh/tern * License : Expat Programming Lang: JavaScript Description : JavaScript code analyzer for text editors Tern is a JavaScript code analysis engine intended for use in text editors to improve support for intelligent JavaScript editing. . Tern includes features to support: autocompletion on variables and properties, function argument hints, query expression types, finding the definition of something, and automatic refactoring. Tern is used by the JavaScript editor in Codelite. signature.asc Description: This is a digitally signed message part
Bug#801420: ITP: mbedtls -- lightweight crypto and SSL/TLS library
Package: wnpp Owner: James Cowgill Severity: wishlist X-Debbugs-CC: debian-devel@lists.debian.org * Package name: mbedtls Version : 2.1.2 Upstream Author : ARM Limited * URL : http://tls.mbed.org/ * License : Apache-2.0 or GPL-2+ Programming Lang: C Description : lightweight crypto and SSL/TLS library mbed TLS (formerly known as PolarSSL) is a lean open source crypto library for providing SSL and TLS support in your programs. It offers an intuitive API and documented header files, so you can actually understand what the code does. It features: - Symmetric algorithms, like AES, Blowfish, Triple-DES, DES, ARC4, Camellia and XTEA - Hash algorithms, like SHA-1, SHA-2, RIPEMD-160 and MD5 - Entropy pool and random generators, like CTR-DRBG and HMAC-DRBG - Public key algorithms, like RSA, Elliptic Curves, Diffie-Hellman, ECDSA and ECDH - TLS 1.0, 1.1 and 1.2 - Abstraction layers for ciphers, hashes, public key operations, platform abstraction and threading Around a year ago control of PolarSSL was passed to ARM and the project was later rebranded as mbed TLS. Version 2 made large changes to the API (including renaming all the functions, include paths, etc) so it makes sense to me to create an entirely separate source package. Due to the number of API changes, even the -dev package does not conflict with libpolarssl-dev. signature.asc Description: This is a digitally signed message part
Re: Linux kernels v3.18.x and v4.2.x in sid
Hi, On Wed, 2015-10-21 at 12:35 +0200, Dmitry Katsubo wrote: > Dear Debian developers, > > I wonder if somebody knows what are the plans for packaging kernels > 3.18.x and 4.2.x? 3.18 was released long time ago, and I think it is > mature. 4.2.x would be nice to play with. I have searched here: > > > https://packages.debian.org/search?suite=all&searchon=names&keywords=kernel-image 4.2.3 is already in unstable. Have a look at this page at the list of package versions on the left: https://tracker.debian.org/pkg/linux The kernel image packages are called "linux-image-". The packages called "kernel-image-" are used by the debian installer but not for full installations. If you specifically want 3.18, you can download it from snapshot.debian.org. http://snapshot.debian.org/package/linux/ James signature.asc Description: This is a digitally signed message part
Re: Linux kernels v3.18.x and v4.2.x in sid
Hi, On Sat, 2015-10-24 at 01:02 +0200, Dmitry Katsubo wrote: > On 23/10/2015 22:43, James Cowgill wrote: > > If you specifically want 3.18, you can download it from > > snapshot.debian.org. http://snapshot.debian.org/package/linux/ > > Thanks, James! I tried to search for "linux-image" but it finds only > kernels from squeeze and wheezy repos: > > > https://packages.debian.org/search?suite=all&arch=any&searchon=names&keywords=linux-image I think this was already mentioned, but since the search generated too many results, only the first 100 were given. If you set the suite to sid then you might find what you are looking for. > Perhaps > > > there is some trick with that UI interface. Anyway, I read a > note on http://snapshot.debian.org/ concerning how to add snapshots > repository to apt-get. I have added the following to > /etc/apt/sources.list: > > > deb http://snapshot.debian.org/archive/debian/20150208T160746Z/ sid main [...] > Still no 3.18.6 in the output of "apt-cache search linux-image". What > I did wrong? Does it matter what repo to pick up? 3.18 was only ever in experimental, so you need to replace sid with experimental in your sources line. > Also from what I see, the latest 3.18 kernel in snapshot repo is > 3.18.6, however kernel.org has releases up to 3.18.22. Is it because > the kernel was superseded by 3.19 so there are no more builds for 3.18 > branch? Yes > Will it be OK then to take 3.19.6 kernel from stability point of > view? If you want something which gets updated and gets bug fixes, you shouldn't be using snapshot.d.o and instead use a kernel from the main archive. Install "linux-image-amd64" to get the latest one from sid. James signature.asc Description: This is a digitally signed message part
Re: Bug#815980: tracker.debian.org: All packages have uscan issues
Control: reassign -1 qa.debian.org Control: retitle -1 UDD: upstream watch file checker is broken with devscripts 2.16.1 On Fri, 2016-02-26 at 11:45 +0100, Vincent Danjean wrote: > Package: tracker.debian.org > Severity: normal > > Hi, > > In the PTS, all packages I currently look at display the following > "action needed" item: > * Problems while searching for a new upstream version > > When looking at the details, it seems to be a connectivity problem > (and I checked for a few packages that the watch file is correct). I think this is rooted in UDD which tracker.debian.org gets its data from. For example, If I run this against UDD it returns "errors" none of which are actually errors: > jcowgill@quantz:~$ psql service=udd -x -c "SELECT * FROM upstream WHERE > source='easytag'" > -[ RECORD 1 > ]---+- > source | easytag > version | 2.4.2-1 > distribution| debian > release | sid > component | main > watch_file | version=3 > | > http://ftp.gnome.org/pub/GNOME/sources/easytag/(\d.)+/ \ > | easytag-([\d.]+)\.tar\.xz > | > signing_key_pgp | > signing_key_asc | > debian_uversion | 2.4.2 > debian_mangled_uversion | 2.4.2 > upstream_version| 2.4.2 > upstream_url| > http://ftp.gnome.org/pub/GNOME/sources/easytag/2.4/easytag-2.4.2.tar.xz > errors | uscan output on stderr: uscan: Newest version of > easytag on remote site is 2.4.2, local version is 2.4.2 > | uscan warn: No upstream tarball downloaded. No > further processing with mk_origtargz ... > | > | > warnings| No upstream tarball downloaded. No further > processing with mk_origtargz ... > | > status | up to date > last_check | 2016-02-26 00:04:48.688531 My guess is that this was triggered in UDD when devscripts 2.16.1 got uploaded to jessie-backports. In devscripts 2.15.10, the interface to uscan changed with everything being printed to stderr (even if it's not an error) if --dehs is used. If all errors uscan gives are always given in the relevant dehs element, can the output from stderr simply be ignored? James signature.asc Description: This is a digitally signed message part
Re: Package openBVE requires a new maintainer
Hi, On Fri, 2016-03-25 at 14:44 +, Christopher Lees wrote: > I hope this is the correct place to try and get into touch with someone. > > I appear to have become the current upstream coder for the package openBVE: > https://packages.debian.org/search?keywords=openbve > My Github repository is here: > http://github.com/leezer3/OpenBVE/ > > This was abandoned by the original developer in ~2007 or so, and > unfortunately the version in the Debian repositories is broken on anything > above Wheezy. I had a go with the version in unstable using some routes I found and things seem to work ok. What exactly is broken? > Whilst I'm not sure I'd currently consider my much updated version ready > for Debian itself, I would like to get into touch with someone who could > potentially adopt the maintainership of the current package, and fix the > current breaking issues with it. > > When that's done, discussion could be had about what is required, and guide > me through the process of getting a version of my builds into the > repositories. > > I have tried mailing the current maintainer- Paul Sladen, but whilst I've > had two replies promising he'll get back to me, I've had nothing more. > Whilst I have no experience in Debian packaging, I'm happy to work with > someone to get this situation sorted out. Did you contact the Debian CLI Applications Team, the team listed in the maintainer field of the package as well? pkg-cli-apps-t...@lists.alioth.debian.org How long ago were those replies? The package was last updated in January this year so it doesn't seem unmaintained. James signature.asc Description: This is a digitally signed message part
Re: Strange link error with -lusb on sid
Hi, On Thu, 2016-05-05 at 18:10 +0200, Alec Leamas wrote: > Dear list, > > I get the following linker error building upstream lirc on sid, > updated as of today: > > /usr/bin/ld: cannot find /lib/ > /usr/bin/ld: cannot find s/libusb-0.1.so.4.4.4 I've just filed this as bug #823525 against libusb-dev. You can downgrade to 2:0.1.12-28 in testing as a temporary workaround. Thanks, James signature.asc Description: This is a digitally signed message part
