Bug#1032115: ITP: unl0kr -- Lightweight On-Screen-Keyboard based on LVGL
Package: wnpp Severity: wishlist Owner: Undef X-Debbugs-Cc: debian-devel@lists.debian.org, Undef * Package name: unl0kr Version : 3.1.0 Upstream Contact: JohannesMarbach * URL : https://gitlab.com/cherrypicker/unl0kr * License : GPL-3+, Apache-2, BSD-3-clause, Expat, MIT, Unlicense, Zlib Programming Lang: C Description : Lightweight framebuffer On-Screen-Keyboard based on LVGL This keyboard is designed to unlock encrypted root partitions on boot on mobile devices. It is automatically launched on boot, allowing the user to enter their disk encryption password. This package is upstream's planned replacement for osk-sdl. It allows users of mobile or otherwise touchscreen only devices to enter their full disk encryption passphrase during boot. Unlike osk-sdl, unl0kr is lightweight and requires minimal dependencies, making it far more suited to small initramfs deployments. This package will be maintained under the DebianOnMobile team.
Hoping to donate/sell a Talos II motherboard
Hello you fabulous developers! My friend has a spare Talos II motherboard that is currently sitting in his house in Indiana USA collecting dust. https://www.raptorcs.com/TALOSII/ I have convinced him to donate/sell it to an open source project or developer. I reached out to Richard Stallman, and he agreed to take the board. I am certain that the FSF would put it to good use. My friend and I have not yet decided, to whom we will give the motherboard. Is it possible that I could give it to someone or project, such that all parties here would benefit? Is there any project or developer here that would be willing to take this motherboard and create virtual machines that other projects could have access to? Thoughts? Thanks, Joshua Branson FOSS enthusiast https://gnucode.me
Re: DEB_BUILD_OPTIONS=nowerror
On Mon, Feb 27, 2023 at 03:06:25PM -0700, Sam Hartman wrote: > > "Steve" == Steve Langasek writes: > Steve> If this is for people doing out-of-archive builds who don't > Steve> want to deal with failures from -Werror, I can see how having > Steve> a single environment toggle is useful to them; but it doesn't > Steve> seem useful to *Debian* when such out-of-archive rebuilds > Steve> don't correspond to the official builds. E.g. if they're > Steve> test builds for new toolchains, knowing that the package > Steve> *could* build, with options Debian doesn't actually use, is > Steve> of limited use. (If you build twice, once with once without > Steve> and file bugs on packages where the results differ, I guess > Steve> that's one use, but involves a lot of manual labor.) > In the general case I agree. > But we have the specific case of cross-bootstrapping. > They want to be able to do builds to bootstrap and they want to have an > option they can pass into the build to ask debian/rules not to include > -Werror. > I suspect Helmut believes he can get patches accepted in the packages > where this is most important to honor the option. > Given his track record, I bet he's right. > So, we have a team in Debian wanting a interface sufficiently > standardized for them to do their work. > I think we have confidence that once we agree on a interface they can > produce appropriate consumers of the interface as well as > implementations of the interface. > I think we should have a high bar for standing in the way of this kind > of work. Well, I'm not seeking to stand in the way of the work, so much as trying to make sure this is the most useful work to be doing to meet the actual use cases. I can see that for bootstrapping a new architecture, it will sometimes be useful to use a toolchain newer than the one that is currently default in Debian, and as a result it is useful to also be able to bypass new stricter -Werror behavior from gcc upstream that breaks compatibility with existing code. It isn't clear to me from the discussion history that this is the actual use case at issue. But supposing it is, that's one use case; and it's a use case that can be addressed without having to make any per-package changes and without having to make any changes to dpkg-buildflags interfaces by exporting DEB_CFLAGS_APPEND=-Wno-error DEB_CXXFLAGS_APPEND=-Wno-error as part of the bootstrap build environment, for all packages. Of course, dpkg-buildflags also exports flags for other languages than C and C++ (and should do), so if you want to have full package coverage you would want your set of _APPEND variables to match the set of per-language flags that dpkg-buildflags already handles. Having to export 7 variables instead of 1 is annoying. But it also doesn't require reaching consensus on a new interface in dpkg. And I remain unconvinced that the particular proposed interface is the right way around for Debian at large. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developer https://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: PGP signature
Re: DEB_BUILD_OPTIONS=nowerror
> "Steve" == Steve Langasek writes: Steve> If this is for people doing out-of-archive builds who don't Steve> want to deal with failures from -Werror, I can see how having Steve> a single environment toggle is useful to them; but it doesn't Steve> seem useful to *Debian* when such out-of-archive rebuilds Steve> don't correspond to the official builds. E.g. if they're Steve> test builds for new toolchains, knowing that the package Steve> *could* build, with options Debian doesn't actually use, is Steve> of limited use. (If you build twice, once with once without Steve> and file bugs on packages where the results differ, I guess Steve> that's one use, but involves a lot of manual labor.) In the general case I agree. But we have the specific case of cross-bootstrapping. They want to be able to do builds to bootstrap and they want to have an option they can pass into the build to ask debian/rules not to include -Werror. I suspect Helmut believes he can get patches accepted in the packages where this is most important to honor the option. Given his track record, I bet he's right. So, we have a team in Debian wanting a interface sufficiently standardized for them to do their work. I think we have confidence that once we agree on a interface they can produce appropriate consumers of the interface as well as implementations of the interface. I think we should have a high bar for standing in the way of this kind of work. signature.asc Description: PGP signature
Bug#1032097: ITP: libpromise-xs-perl -- Fast promises in Perl
Package: wnpp Severity: wishlist Owner: Alexander Zangerl X-Debbugs-Cc: debian-devel@lists.debian.org * Package name: libpromise-xs-perl Version : 0.18 Upstream Author : Tom van der Woerdt , Felipe Gasper https://metacpan.org/release/Promise-XS * License : Artistic Programming Lang: Perl, C Description : Fast promises in Perl This module provides a Promises/A+ interface with its major parts implemented in XS for speed. It is a fork and refactor of AnyEvent::XSPromises, and retains that module's bare-bones interface. This is one of a few Promises implementations in perl, none of which have made it into debian yet. i think it's time to change that.
Re: DEB_BUILD_OPTIONS=nowerror
On Mon, Feb 27, 2023 at 10:49:48AM -0700, Sam Hartman wrote: > Helmut> The problem here specifically arises, because we do not have > Helmut> consensus on -Werror being a bad idea in release builds. > I agree with your reading of consensus and for that reason support > registering an option to say do not use -Werror. Sorry if I've missed it in this thread, but who is this option supposed to be *for*? Generally speaking, DEB_BUILD_OPTIONS or DEB_BUILD_MAINT_OPTIONS flags are useful for permuting the output of dpkg-buildflags, when the default output of that command is unsuitable for a particular package or for a particular rebuild environment. But here, the output of dpkg-buildflags is not incorrect because it emits neither -Werror nor -Wno-error; we are talking about an interface to override upstream defaults, not Debian defaults. If this is for the maintainer, it seems an unnecessary indirection to define a flag for the maintainer to set, to configure dpkg-buildflags, to output the correct flag that you know you want to pass to your package's build system. (Maybe the reasoning here is that it's a simpler interface for maintainers that abstracts a lot of the reasoning about build systems and makes for a more compact expression in debian/rules? I'm not sure.) If this is for people doing out-of-archive builds who don't want to deal with failures from -Werror, I can see how having a single environment toggle is useful to them; but it doesn't seem useful to *Debian* when such out-of-archive rebuilds don't correspond to the official builds. E.g. if they're test builds for new toolchains, knowing that the package *could* build, with options Debian doesn't actually use, is of limited use. (If you build twice, once with once without and file bugs on packages where the results differ, I guess that's one use, but involves a lot of manual labor.) My understanding is that the argument here is that -Werror is not a sensible option to use for production builds, that it should only be used for upstream test builds. I'm not convinced this is true; I know we've more than once caught programming errors of various severities downstream by building on ports that upstreams would generally not be in a position to cover in their developer test builds. But if that's the argument, then I think the logical desired policy outcome would be for dpkg-buildflags to be changed to emit -Wno-error *by default*, with an option flag along the lines of DEB_BUILD_OPTIONS=Werror that lets you turn it on instead. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developer https://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: PGP signature
Re: DEB_BUILD_OPTIONS=nowerror
Helmut> The problem here specifically arises, because we do not have Helmut> consensus on -Werror being a bad idea in release builds. I agree with your reading of consensus and for that reason support registering an option to say do not use -Werror.
Re: Bug#1011666: need help with groff 1.23.0 (1.23.0~rc3-1 package prepared)
Hi Branden and Colin!
On 2/27/23 13:56, G. Branden Robinson wrote:
> [added Alex Colomar to CC]
>
> At 2023-02-26T13:30:58+, Colin Watson wrote:
>>> I am not a proficient gbp user, but I think I have done what is
>>> necessary.
>>
>> groff doesn't use gbp - it uses git-dpm.
>
> Right. You told me that before and the information trickled out of my
> sieve-like brain. TLA overload, so I was SOL. FML.
$ wtf is SOL
SOL: SOL (6) - a collection of card games which are easy to play
with...
$ wtf is FML
Gee... I don't know what FML means...
Please send a patch to bsdgames :D
At least dict(1) could help with SOL. No luck with FML though,
I had to search it on the web. No good. Fuck my life! :D
$ dict -d foldoc SOL
1 definition found
From The Free On-line Dictionary of Computing (30 December 2018) [foldoc]:
SOL
1. {Simulation Oriented Language}.
2. {Second-Order lambda-calculus}.
3. Semantic Operating Language. Language for manipulating
semantic networks for building cognitive models, particularly
for natural language understanding. "Explorations in
Cognition", D.A. Norman et al, W.H. Freeman 1974.
4. Shit Outta Luck.
$ dict FML
No definitions found for "FML", perhaps you mean:
gcide: ml Fm Fil -ful
wn: ml fl fm ful
vera: ml fl fm cfml aml bml dml eml gml iml kml mml
nml qml sml uml vml wml xml fal fbl fcl fdl frl ftl
fma fmb fmm fmo fms
jargon: fm
foldoc: ml fl fm
>
>> If you try to use gbp for it then you will probably get quite confused
>> and so will I, so please don't.
>
> Yes, indeed, thanks.
>
>> First, move your current branch somewhere for reference, then make a new
>> one. Then, my routine for pulling in new upstreams looks roughly like
>> this:
>>
>> git-dpm import-new-upstream -p $UPSTREAMTAG^{} --rebase-patched
>> ../foo.orig.tar.gz
>> # this imports the unpacked upstream tarball onto an upstream branch
>> # based on $UPSTREAMTAG, then drops you into a rebase session
>>
>> ... continue with rebase as needed, then once you're finished ...
>>
>> git-dpm update-patches --amend
>> # the --amend is just because the import-new-upstream step will
>> # already have recorded the new upstream on the branch you started
>> # from, but the history looks clearer if you bundle the rebase with
>> # that in a single merge commit, which this does
May I ask something from you, Colin? Could you please embed that
info in the commit messages in salsa? That would help those who
want to learn Debian packaging from actual practice rather than
tutorials (I've read and watched many of those, and my confusion
only grows; I mean, just look at
:p).
In the Linux man pages I write the scripts or commands run to produce
a scripted or semi-scripted patch, or when some important information
needed to write a patch was gotten from some script. See for example:
commit a1eaacb1a569cd492b09c04982cd40b4b733ba3c
Author: Alejandro Colomar
Date: Wed Nov 9 16:36:36 2022 +0100
Many pages: Add '\" t' comment where necessary
Scripted change:
$ grep -l -x '^[.]TS$' man*/* | sort -u | xargs sed -i -e "1i'\" t"
Link:
Reported-by: Jakub Wilk
Cc: Mike Frysinger
Cc: "G. Branden Robinson"
Cc: Michael Kerrisk
Cc: Stefan Puiu
Signed-off-by: Alejandro Colomar
commit b324e17d3208c940622ab192609b836928d5aa8d
Author: Alejandro Colomar
Date: Sun Dec 4 20:38:06 2022 +0100
Many pages: wfix
Refer consistently to software versions. In most cases, it is done as
. In the case of Linux and glibc, use the project
name, instead of other terms such as 'kernel' or 'library'.
I found the uses of inconsistent language with the following:
$ find man* -type f \
| xargs grep -i
'\(since\|before\|after\|until\|to\|from\|in\|between\|version\|with\)
\(kernel\|version\|2\.\|3\.\|4\.\|5\.\)' \
| sort
However, I might have missed some cases. Anyway, 99% consistency is
pretty good consistency. We'll fix the remaining cases as we see them.
Signed-off-by: Alejandro Colomar
>>
>> Then you can cherry-pick your packaging changes on top of this, as well
>> as telling pristine-tar about the new upstream tarball based on the
>> appropriate imported branch.
>>
>> If you push the results to a temporary branch on salsa then I can look
>> over them, which is probably a good idea since you're unfamiliar with
>> git-dpm.
>
> Thanks for this. I also found
> https://wiki.debian.org/PackagingWithGit/GitDpm which is helpful for my
> fallback plan described below.
>
>>> How do we move forward with this? I am anxious about the closing of the
>>> soft freeze window.
>>
>> There is no way that this giant new upstream r
Re: need GBP help with groff 1.23.0 (1.23.0~rc3-1 package prepared)
At 2023-02-26T11:52:39+0100, Andrey Rakhmatullin wrote: > Just import them? Do you have any specific questions or problems with > this? [...] > Again, which advice? You said that it works for you. Hi Andrey, I think at least some of my confusion arose from trying to use gbp with a git-dpm-based repository. I was working in a big hurry, trying to make the Bullseye release but that is now looking hopeless. Thanks for responding so swiftly to my plea for help. Regards, Branden signature.asc Description: PGP signature
Re: Bug#1011666: need help with groff 1.23.0 (1.23.0~rc3-1 package prepared)
[added Alex Colomar to CC]
At 2023-02-26T13:30:58+, Colin Watson wrote:
> Sorry about that! Feel free to grab me on IRC if I'm not replying to
> email.
Ah! I'm never on IRC anymore. I shifted to machines with power
management for everyday use; the loss of a nailed-up Internet connection
destroyed my IRC continuity. (I hear there are ways around this...)
> > I am not a proficient gbp user, but I think I have done what is
> > necessary.
>
> groff doesn't use gbp - it uses git-dpm.
Right. You told me that before and the information trickled out of my
sieve-like brain. TLA overload, so I was SOL. FML.
> If you try to use gbp for it then you will probably get quite confused
> and so will I, so please don't.
Yes, indeed, thanks.
> First, move your current branch somewhere for reference, then make a new
> one. Then, my routine for pulling in new upstreams looks roughly like
> this:
>
> git-dpm import-new-upstream -p $UPSTREAMTAG^{} --rebase-patched
> ../foo.orig.tar.gz
> # this imports the unpacked upstream tarball onto an upstream branch
> # based on $UPSTREAMTAG, then drops you into a rebase session
>
> ... continue with rebase as needed, then once you're finished ...
>
> git-dpm update-patches --amend
> # the --amend is just because the import-new-upstream step will
> # already have recorded the new upstream on the branch you started
> # from, but the history looks clearer if you bundle the rebase with
> # that in a single merge commit, which this does
>
> Then you can cherry-pick your packaging changes on top of this, as well
> as telling pristine-tar about the new upstream tarball based on the
> appropriate imported branch.
>
> If you push the results to a temporary branch on salsa then I can look
> over them, which is probably a good idea since you're unfamiliar with
> git-dpm.
Thanks for this. I also found
https://wiki.debian.org/PackagingWithGit/GitDpm which is helpful for my
fallback plan described below.
> > How do we move forward with this? I am anxious about the closing of the
> > soft freeze window.
>
> There is no way that this giant new upstream release will be suitable
> at this stage in the freeze; it's too late. This should be targeted
> at experimental.
Oh, man. That really sucks the wind out of my sails. :(
(Good thing I did the packaging update work already!)
The freeze policy says, "Starting 2023-02-12, only small, targeted fixes
are appropriate for bookworm. We want maintainers to focus on small,
targeted fixes. This is mainly at the maintainers discretion, there will
be no hard rule that will be enforced."[1]
I was kind of hoping for an exercise of that discretion in favor of
getting the groff release in. I hope you feel I have been attentive to
issues of implementation quality. Nevertheless I admit I have a
conflict of interest as an active upstream (for the moment, still
unoffical) co-maintainer who wants to see his 4,000 commits including
400 bug fixes get into the next Debian release.[2]
But, also, Bertrand Garrigues (GNU maintainer, who has had to step back
quite a bit for personal reasons) is going to be unavailable to tag
1.23.0 final until _next_ weekend so I think groff and Debian release
timing may simply have a curse on them.
Please find attached my much more modest proposal. Let's make sure the
groff in Debian bookworm will not throw confusing undefined register
warnings or drop text from man pages that begin to embrace groff 1.23's
new features.
Alex Colomar, the Linux man-pages maintainer, is eager to adopt the new
man(7) MR macro ASAP, so that's 2,500 man pages, many commonly used,
that will be undergoing a transition in the next few months, I expect.
Meanwhile I reckon I'll start praying to the gods of backports and point
releases.
Regards,
Branden
[1] https://release.debian.org/testing/freeze_policy.html#soft
[2]
https://git.savannah.gnu.org/cgit/groff.git/tree/ANNOUNCE?id=99e5b4ae55a7c222f6bf57b355289a88d862478d
https://git.savannah.gnu.org/cgit/groff.git/tree/NEWS?id=99e5b4ae55a7c222f6bf57b355289a88d862478d
commit 69e844df84929b8a6a440cbbafe55dcd134107b6
Author: G. Branden Robinson
Date: Mon Feb 27 06:27:17 2023 -0600
Rename and document patch
diff --git a/debian/changelog b/debian/changelog
index ca8a27d5..4f867aeb 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,8 +1,14 @@
-groff (1.22.4-10) UNRELEASED; urgency=medium
+groff (1.22.4-10) unstable; urgency=medium
+ [ Colin Watson ]
* Set upstream metadata fields: Repository-Browse.
- -- Colin Watson Mon, 02 Jan 2023 13:38:52 -
+ [ G. Branden Robinson ]
+ * debian/patches/add-groff-1.23-forward-compatibility.patch: Prevent
+formatter warnings and dropped man(7) document text when encountering
+documents written using new features of groff 1.23.
+
+ -- G. Branden Robinson Mon, 27 Feb 2023 06:30:24 -0600
groff (1.22.4-9) unstable; urgency=medium
diff --git a/debian/patches/0017-tmac-man.local-troffrc-Add-
Re: icc-profiles_2.2_source.changes REJECTED
Quoting Simon McVittie (2023-02-27 13:04:25) > On Mon, 27 Feb 2023 at 12:22:34 +0100, Jonas Smedegaard wrote: > > I am not convinced, however, that this issue is a bug in lintian: > > The testcase you ask for is the actual files in the icc-profiles source > > package which already is already correctly identified by lintian. I.e. > > issue is not that some different files get misdetected but instead that > > lintian _correctly_ identifies the files in this non-free package and > > _correctly_ classifies those as unsuitable in main > > That's correct to a point, but it seems wrong for lintian to be emitting a > tag that means "this package is unsuitable for main and that's a problem" > for a package in non-free. Yes, we know it's unsuitable for main, and > the maintainer has acknowledged that by uploading it to non-free... it > doesn't seem like there is any benefit to having an unfixable Lintian > error as well. > > Or if the interpretation of the tag is "you should use the copy of this > file from icc-profiles instead of shipping your own copy", then the lintian > check should have a special case to silence that tag when the package being > checked *is* icc-profiles. > > There are similar special cases in other parts of Lintian. For example, > it looks for embedded code copies of zlib, but that check has a special > case to avoid it being triggered by zlib itself, because obviously zlib > should be allowed to ship zlib code; and similarly checks for a bundled > font like Deja Vu shouldn't trigger for fonts-dejavu itself. Ah, I was unaware that lintian at other places includes exceptions like that, an that lintian is expected to do reliable assessments in this kind of tests. When that's the case, then please, Bastien (or others skilled with internals of lintian) please refine the tests for icc-profiles contents to exclude icc-profiles package itself. (I'll file a bugreport against lintian if I notice no actions from this) Kind regards, - 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
Re: icc-profiles_2.2_source.changes REJECTED
On Mon, 27 Feb 2023 at 12:22:34 +0100, Jonas Smedegaard wrote: > I am not convinced, however, that this issue is a bug in lintian: > The testcase you ask for is the actual files in the icc-profiles source > package which already is already correctly identified by lintian. I.e. > issue is not that some different files get misdetected but instead that > lintian _correctly_ identifies the files in this non-free package and > _correctly_ classifies those as unsuitable in main That's correct to a point, but it seems wrong for lintian to be emitting a tag that means "this package is unsuitable for main and that's a problem" for a package in non-free. Yes, we know it's unsuitable for main, and the maintainer has acknowledged that by uploading it to non-free... it doesn't seem like there is any benefit to having an unfixable Lintian error as well. Or if the interpretation of the tag is "you should use the copy of this file from icc-profiles instead of shipping your own copy", then the lintian check should have a special case to silence that tag when the package being checked *is* icc-profiles. There are similar special cases in other parts of Lintian. For example, it looks for embedded code copies of zlib, but that check has a special case to avoid it being triggered by zlib itself, because obviously zlib should be allowed to ship zlib code; and similarly checks for a bundled font like Deja Vu shouldn't trigger for fonts-dejavu itself. smcv
Re: icc-profiles_2.2_source.changes REJECTED
Quoting Bastien Roucariès (2023-02-25 15:04:09) > Le vendredi 24 février 2023, 06:13:48 UTC Shengjing Zhu a écrit : > > Hi, > > > > On Fri, Feb 24, 2023 at 7:38 AM Jonas Smedegaard wrote: > > > > > > What to do when a package is blocked from getting updated due to it > > > being itself? > > > > > > I have tried replying to FTPmasters as invited in the rejection message, > > > but have been met with silence. > > > > > > I have tried filing bug#1030961 but have so far seen no response on that > > > either. > > > > > > Will it make sense to reassing that bugreport to the technical > > > committee? Or to the release team? Or should I request removal of the > > > package, because security bugfixes (however unlikely for a package > > > containing purely static data files) is impossible? > > > > > > > > > - Jonas > > > > > > Quoting Debian FTP Masters (2023-02-09 04:19:39) > > > > > > > > icc-profiles source: lintian output: > > > > 'license-problem-md5sum-non-free-file ECI-RGB.V1.0.icc usual name is > > > > ECI-RGB.V1.0.icc. Does not allow modification See also > > > > https://packages.debian.org/sid/icc-profiles.', automatically rejected > > > > package. > Seems like a bug on lintian > > Feel free to prod me with a small testcase or a patch will try to do something Thanks, Shengjing Zhu, for suggesting to solve this in lintian. Thanks, Bastien, for offering to help do that. I am not convinced, however, that this issue is a bug in lintian: The testcase you ask for is the actual files in the icc-profiles source package which already is already correctly identified by lintian. I.e. issue is not that some different files get misdetected but instead that lintian _correctly_ identifies the files in this non-free package and _correctly_ classifies those as unsuitable in main, but ftpmaster then using that identification and classification as reason for rejecting an upload of the non-free package. - 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
Bug#1032069: ITP: rust-rawloader -- Image processing pipeline
Package: wnpp Severity: wishlist Owner: Fab Stz X-Debbugs-Cc: debian-devel@lists.debian.org * Package name: rust-rawloader Version : 0.37.1 Upstream Author : Pedro Côrte-Real * URL : https://github.com/pedrocr/rawloader * License : LGPL-2.1 Programming Lang: Rust Description : Library to extract the data from camera raw formats This is a rust library to extract the raw data and some metadata from digital camera images. Given an image in a supported format and camera you will be able to get everything needed to process the image: - Identification of the camera that produced the image (both the EXIF name and a cleaned up name) - The raw pixels themselves, exactly as encoded by the camera - The number of pixels to crop on the top, right, bottom, left of the image to only use the actual image area - The black and white points of each of the color channels - The multipliers to apply to the color channels for the white balance - A conversion matrix between the camera color space and XYZ - The description of the bayer pattern itself so you'll know which pixels are which color Required by czkawka #1032030 Should be maintained by rust team. Sponsor required
Bug#1032068: ITP: rust-imagepipe -- Image processing pipeline
Package: wnpp Severity: wishlist Owner: Fab Stz X-Debbugs-Cc: debian-devel@lists.debian.org * Package name: rust-imagepipe Version : 0.5.0 Upstream Author : Pedro Côrte-Real * URL : https://github.com/pedrocr/imagepipe * License : LGPL-3.0-only Programming Lang: Rust Description : Image processing pipeline An image pipeline capable of taking any image format, including camera RAW files and transforming it into a final output. Required by czkawka #1032030 Should be maintained by rust team. Sponsor required
Bug#1032066: ITP: rust-image-hasher -- simple library that provides perceptual hashing and difference calculation for images
Package: wnpp Severity: wishlist Owner: Fab Stz X-Debbugs-Cc: debian-devel@lists.debian.org * Package name: rust-image-hasher Version : 1.1.2 Upstream Author : 2015-2017 The `img_hash` Crate Developers 2014-2021 Austin Bonander 2022-2023 Rafał Mikrut * URL : https://github.com/qarmin/img_hash * License : MIT or Apache-2.0 Programming Lang: Rust Description : Library for calculating perceptual hash values of images A simple library that provides perceptual hashing and difference calculation for images. Thanks to Dr. Neal Krawetz for the outlines of the Mean (aHash), Gradient (dHash), and DCT (pHash) perceptual hash algorithms: http://www.hackerfactor.com/blog/?/archives/432-Looks-Like-It.html (Accessed August 2014) Also provides an implementation of the Blockhash.io algorithm. This crate can operate directly on buffers from the PistonDevelopers/image crate. This is fork of img_hash library, but with updated dependencies without any license changes. Required by czkawka #1032030 Should be maintained by rust team. Sponsor required
Bug#1032064: ITP: fluent-syntax -- Parser/Serializer tools for Fluent Syntax
Package: wnpp Severity: wishlist Owner: Fab Stz X-Debbugs-Cc: debian-devel@lists.debian.org * Package name: fluent-syntax Version : 0.11.0 Upstream Author : Zibi Braniecki Staś Małolepszy * URL : https://github.com/projectfluent/fluent-rs * License : Apache-2.0 or MIT Programming Lang: Rust Description : Parser/Serializer tools for Fluent Syntax fluent-syntax is a parser/serializer API for the Fluent Syntax, part of the Project Fluent, a localization framework designed to unleash the entire expressive power of natural language translations. Required by czkawka #1032030 Should be maintained by rust team. Sponsor required
Re: Reducing allowed Vcs for packaging?
On Sun, Feb 26, 2023 at 02:24:26PM +0100, Bastian Germann wrote: > During the last weeks I had a look at the Vcs situation in Debian. Currently, > there are eight possible systems allowed and one might specify several of > them for > one package. No package makes use of several Vcs references and frankly I do > not > see why this was supported in the first place. > > For the allowed systems the situation in unstable is the following: > arch is used by 2 packages pointing to bad URLs: #1025510, 1025511. > bzr is used by ~50 packages, half of which point to bad URLs. > cvs is used by 3 packages, 2 of which point to bad URLs: #1031312, #1031313. > svn is used by ~130 packages, many of which point to bad URLs. > darcs, mtn, and hg are not used. > > We can see: The Vcs wars are over; with git there is a clear winner and in my > opinion, we should remove the possibility to use most of them for package > maintenance. It is one additional barrier to get into package maintenance and > we should remove the barriers that are not necessary. What about packages that don't use a Vcs today? There are far more of those today than that are using non-standard Vcs repositories. The number of packages that's using non-standards Vcs repositories is declining gradually anyway (0.4% of the archive today). What does dropping the Vcs-* headers achieve, besides making it even harder to work with these packages? As somebody who uses Vcs-Bzr for some of the Bzr packages, I'd be on board with mandating Git (because that gets us consistency in being able to work with every package) - but I don't see the point of dropping support for other Vcs-* headers without doing that. Cheers, Jelmer
Re: Reducing allowed Vcs for packaging?
On Sun, Feb 26, 2023 at 10:25:21AM -0700, Sean Whitton wrote: > Why don't we just fix all those packacges, instead of changing any > documents? Is there anyone who actually wants to introduce new packages > not using git? I'm not so sure. mostly agreed, i'm just sure there will be very few people who want that, though for the scope of developers-reference I think those should be ignored. that said, dev-ref currently only explicitly mentions vcs-git. -- cheers, Holger ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ holger@(debian|reproducible-builds|layer-acht).org ⢿⡄⠘⠷⠚⠋⠀ OpenPGP: B8BF54137B09D35CF026FE9D 091AB856069AAA1C ⠈⠳⣄ The mark of a civilized man is the ability to look at a column of numbers and weep. (Bertrand Russell) signature.asc Description: PGP signature
Re: DEB_BUILD_OPTIONS=nowerror
On Sun, Feb 26, 2023 at 08:25:25PM +0100, Helmut Grohne wrote: > On Sun, Feb 26, 2023 at 07:15:45PM +0200, Adrian Bunk wrote: > > What you describe is an RC bug as soon as the more recent toolchain > > becomes default, and the correct solution is to not build with -Werror. > > > > DEB_BUILD_OPTIONS=nowerror would imply that building with -Werror > > by default would be OK, but there are already too many FTBFS due > > to -Werror. > > I would happily agree with all of this, but I do not see consensus on > either. My point is that an opt-out DEB_BUILD_OPTIONS=nowerror would make the problem worse for the "FTBFS on buildds" problem, since it would result in more people building their packages with -Werror by default. >... > The problem here specifically arises, because we do not have consensus > on -Werror being a bad idea in release builds. >... Strictly disallowing all usage of -Werror (which might be set by the maintainer, but more often by upstream) would be controversial. It would also be hard to define what exactly would be forbidden. Individual warnings can be turned into errors, and our hardening flags set -Werror=format-security. There might be more consensus for language in Policy discouraging -Werror that leaves maintainers room to diverge from the recommendation? > Helmut cu Adrian
Re: Bug#1031701: python3-pandas: Pandas requires version '2.0.1' or newer of 'xlrd'
I don't consider the lack of .xls in pandas worth a freeze exception, but consider it reasonable for others to disagree with that. As noted in the bug, there are some (possibly not-technically-valid) .xlsx files that xlrd 1 can open but openpyxl can't - _pandas_ won't be able to open those either way, but allowing other applications to do so is still worth something. There also may be applications that could switch to openpyxl but simply haven't. I don't know how much effort switching is / whether it would be reasonably possible for us to do it. However, I wasn't aware of the security issues in xlrd 1 when I wrote that, and they may well be a reason to go to xlrd 2 and accept this breakage. Are they the long-standing "denial of service via excessive XML entity expansion" or is there now (also) a risk of something worse?
