Re: packages.debian.org hasn't been updated for non-free-firmware
On 2/19/23 17:04, Cyril Brulebois wrote: Cyril Brulebois (2023-02-19): I tried to hotpatch it, but failed to so far. Second attempt seems better. Might take an extra dinstall (+ indexing in the following hours) to have all the things in place though. If people still see problems tomorrow, please follow up with details. Cheers, Hi Cyril, Thanks a lot for this! :) Thomas
Bug#1031689: ITP: obs-scene-tree-view -- plugin for OBS Studio that adds a scene tree folder dock
Package: wnpp Severity: wishlist Owner: Joao Eriberto Mota Filho X-Debbugs-Cc: debian-devel@lists.debian.org, DigitOtter * Package name: obs-scene-tree-view Version : 0.1.5 Upstream Contact: DigitOtter * URL : https://obsproject.com/forum/resources/scene-tree-folder-plugin-for-obs-studio.1500 * License : GPL-2 Programming Lang: C++ Description : plugin for OBS Studio that adds a scene tree folder dock This plugin allows OBS to group and organize scenes into a folder structure. It is possible to switch the standard scene dock provided by OBS to this special plugin. It is possible to create several folders to group scenes on them.
Re: rust-*/librust-* arch:any vs. arch:all and cross-compilation support
Hi Fabian, On Wed, Feb 15, 2023 at 08:14:17PM +0100, Fabian Grünbichler wrote: > > // This is the best but not ideal option for us. > > // > > // Currently Debian M-A spec has a deficiency where a package X > > that > > // build-depends on a (M-A:foreign+arch:all) package that itself > > // depends on an arch:any package Z, will pick up the > > BUILD_ARCH of > > // package Z instead of the HOST_ARCH. This is because we > > currently > > // have no way of telling dpkg to use HOST_ARCH when checking > > that the > > // dependencies of Y are satisfied, which is done at > > install-time > > // without any knowledge that we're about to do a > > cross-compile. It > > // is also problematic to tell dpkg to "accept any arch" > > because of > > // the presence of non-M-A:same packages in the archive, that > > are not > > // co-installable - different arches of Z might be > > depended-upon by > > // two conflicting chains. (dpkg has so far chosen not to add an > > // exception for the case where package Z is M-A:same > > co-installable). > > // > > // The recommended work-around for now from the dpkg developers > > is to > > // make our packages arch:any M-A:same even though this results > > in > > // duplicate packages in the Debian archive. For very large > > crates we > > // will eventually want to make debcargo generate -data > > packages that > > // are arch:all and have the arch:any -dev packages depend on > > it. > > > > https://salsa.debian.org/rust-team/debcargo/-/blob/master/src/debian/control.rs#L342 I guess that I was the one giving the advice that was recorded here although I agree with Guillem that it is not recorded in a very consumable way. > > The chain is > > > > rust-lscolors (arch:any) --BD--> librust-tempfile-dev (arch:any) > > librust-tempfile-dev (arch:any) --D--> > > librust-remove-dir-all-0.7+default-dev (arch:any) --D--> > > librust-log-0.4+default-dev (arch:any) --D--> > > librust-value-bag-1.0.0+serde-dev (arch:any) --D--> > > librust-serde-fmt-1+default-dev (arch:all) --D--> librust-serde-dev > > (arch:any, but wrongly resolved!) > > > > with librust-serde-fmt-dev being switched to arch:all, it will resolve to > > :amd64 instead of :i386 and in turn pull in its own dependencies > > librust-serde-1+std-dev & librust-serde-1-dev (both provided by > > librust-serde-dev) from amd64 (in addition to librust-serde-dev:i386, which > > is also part of the arch:any (build-)dependency tree of rust-lscolors > > itself, without the "hop" over librust-serde-fmt-dev). The analysis is well done. Thank you. This is a real example of why we do this annoying arch:any+m-a:same dance. > > TL;DR: Is the switch to arch:all one that should be reverted in the face of > > it apparently breaking cross builds? Or is there another alternative > > (nowadays) that makes the "workaround" employed by debcargo no longer > > needed? Yes, the switch to arch:all needs to be reverted at least partially. No, there is no better way to achieve this. We extensively discussed alternatives in Vaumarcus and reached the conclusion that no possible interface was acceptable to dpkg. In essence, dpkg could automatically track the architectures of packages (which would incur a recursive dependency resolver onto dpkg) or architecture tracking could be a manual thing, which would be far too annoying to end users. Therefore, there is no sane alternative to the workaround. > > Depending on feedback, the rust team would either ask Jonas to switch back > > his packages to arch:any, M-A:same (probably after bookworm, to prevent > > further fallout/need for RMs/.. during the freeze), or will evaluate > > whether switching to arch:all is an option for debcargo-managed packages as > > well, and which changes on the team tooling side are needed to avoid losing > > test coverage or increasing friction. Technically, not all packages need to become arch:any+m-a:same. As you correctly observed, the problem arises from non-rust dependencies in the dependency tree. For instance, librust-typenum-dev has no dependencies. As such, it could be changed to arch:all+m-a:foreign without incurring problems to cross compilation. Likewise, librust-bitmaps-dev only depends on librust-typenum-1+default-dev, which is provided by librust-typenum-dev. Consequently, it could be converted to arch:all+m-a:foreign as well. However, as soon as you reach C bindings, such as librust-typenum-dev, the workaround to use arch:any+m-a:same is needed. Then any library that transitively depends on any C binding also needs the workaround. The problem here is that lower layers can introduce bindings at a later time and thus break cross compilation involving a higher level library. Whether a library can sa
Re: rust-*/librust-* arch:any vs. arch:all and cross-compilation support
Quoting Helmut Grohne (2023-02-20 18:12:14) > On Wed, Feb 15, 2023 at 08:14:17PM +0100, Fabian Grünbichler wrote: > > > TL;DR: Is the switch to arch:all one that should be reverted in the face > > > of it apparently breaking cross builds? Or is there another alternative > > > (nowadays) that makes the "workaround" employed by debcargo no longer > > > needed? > > Yes, the switch to arch:all needs to be reverted at least partially. Thanks, Fabian, for bringing this up, and thanks Helmut for the clarification. > Could it be that Jonas picked up such hints and thus added m-a:foreign? > Then later a C binding was added to the mix, which broke the hint, but > the conversion wasn't reverted. No, I was not guided by m-a hinter rules (assuming you mean the kind of hints that appear in the "action needed" section of e.g. https://tracker.debian.org/pkg/rust-test-case ) when I did the switch, so I am not aware that that hinting are broken. > This suggests that the hinter should gain another condition to never > issue arch:all+m-a:foreign conversion hints for librust-*-dev packages. > Do you agree? I don't see a need for such general rule for all librust-*-dev packages. E.g. librust-futures-timer-dev and librust-event-listener-dev has no dependencies so should be safe to distribute as arch-all and marked as m-a:foreign, right? Sure, there is a theoretical risk that some day in the future those packages grow dependencies that require changing that, but isn't that the case generally for m-a hinting? I guess it makes sense instead to have a lintian warning for packages marked m-a:foreign that all its dependencies are equally marked (or if that's unreasonably expensive then check only one level deep). That should help flag misuses of m-a:foreign including this one of mine (for most but not all the librust-*-dev packages that I maintain). - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ * Sponsorship: https://ko-fi.com/drjones [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: signature
Bug#1031694: ITP: libxisf -- Library to load and save XISF images
Package: wnpp Owner: Ole Streicher Severity: wishlist X-Debbugs-Cc: debian-devel@lists.debian.org,debian-as...@lists.debian.org * Package name: libxisf Version : 0.1.3 Upstream Author : Dušan Poizl https://gitea.nouspiro.space/nou/libXISF * License : GPL3 Programming Lang: C++ Description : Library to load and save XISF images Extensible Image Serialization Format (XISF, pronounced [ɛksˈɪsf]) is the native file format of PixInsight. It is a free, open format for storage, management and interchange of digital images and associated data. I wrote this library to load and save images in XISF format as it is preferred format for PixInsight. Just recently it got integrated into INDI and KStars.
Re: rust-*/librust-* arch:any vs. arch:all and cross-compilation support
Hi Jonas, On Mon, Feb 20, 2023 at 06:44:23PM +0100, Jonas Smedegaard wrote: > I don't see a need for such general rule for all librust-*-dev packages. This definitely is a trade-off. Hence I asked about what we should do about it. > E.g. librust-futures-timer-dev and librust-event-listener-dev has no > dependencies so should be safe to distribute as arch-all and marked as > m-a:foreign, right? Yeah, I mentioned librust-typenum-dev earlier and you found more. I expect that there are probably hundreds of pure rust libraries without dependencies. Really, the only reason to not have them arch:all is mitigating the risk of changing dependency trees. > Sure, there is a theoretical risk that some day in the future those > packages grow dependencies that require changing that, but isn't that > the case generally for m-a hinting? You are entirely correct about this. It definitely is a heuristic. > I guess it makes sense instead to have a lintian warning for packages > marked m-a:foreign that all its dependencies are equally marked (or if > that's unreasonably expensive then check only one level deep). That > should help flag misuses of m-a:foreign including this one of mine (for > most but not all the librust-*-dev packages that I maintain). lintian does not have the full picture. It looks at one source package plus all of its binary packages in isolation. It cannot see the multi-arch annotations of dependencies. Hence the multi-arch hinter was added as an extra component outside lintian. On the flip side, the hinter could do the flagging that you suggest here. In essence, it could flag all packages satisfying all of the following conditions: * Architecture: all * Multi-Arch: foreign * Package: librust*-dev * Depends: some package that is not m-a:foreign We can actually express this in SQL: SELECT name FROM indeppackage AS i WHERE name LIKE 'librust%-dev' AND multiarch = 'foreign' AND EXISTS (SELECT 1 FROM archdepcandidate AS c WHERE c.dependerid = i.id); I guess you're also interested in the output of the query. librust-crdts-dev librust-ahash-dev librust-assert-json-diff-dev librust-async-attributes-dev librust-async-channel-dev librust-async-executor-dev librust-async-fs-dev librust-async-net-dev librust-async-process-dev librust-async-std-dev librust-blocking-dev librust-femme-dev librust-flume-dev librust-hyper-rustls-dev librust-kv-log-macro-dev librust-lazy-regex-dev librust-leptonica-plumbing-dev librust-leptonica-sys-dev librust-nom-locate-dev librust-oxilangtag-dev librust-resource-proof-dev librust-rustls-native-certs-dev librust-rusty-pool-dev librust-serde-fmt-dev librust-smol-dev librust-socks-dev librust-tesseract-plumbing-dev librust-tesseract-sys-dev librust-test-case-dev librust-version-sync-dev librust-criterion-dev librust-oxhttp-dev librust-oxiri-dev librust-retry-dev librust-rustls-dev librust-xor-name-dev librust-nanorand-dev librust-threadfin-dev librust-ahash-0.7-dev librust-criterion-0.3-dev librust-isahc-dev librust-ureq-dev As a confirmation of Fabian's observation, this list includes librust-serde-fmt-dev. Note that this is not transitive yet. After fixing these, some reverse dependencies will be added to the list. Also note that running this query on delfin.d.o cannot be easily done by DDs yet, because the underlying sqlite database uses wal mode. Sorry about that. Should the hinter generate reverse hints for these and thus issue action items on tracker.d.o? Helmut
