Re: Supporting alternative zlib implementations
One minor moment: zlib-ng doesn't seem to be fully backward compatible. E.g. Angie (nginx's fork with enhancements) is unable to perform gzip compression [1] if built against zlib-ng. It's highly likely that nginx is affected too. [1] https://t.me/angie_support/4205 пт, 4 окт. 2024 г. в 03:13, Fay Stegerman : > > * Sebastian Andrzej Siewior [2024-10-03 22:03]: > > On 2024-09-26 01:35:45 [+0200], Fay Stegerman wrote: > > > For example, ZIP files or Android APKs built on a Debian system will have > > > a > > > different compressed stream, like the test files you mention. Which will > > > likely > > > break Reproducible Builds tooling like apksigcopier [1] and > > > reproducible-apk-tools [2]. > > > > wouldn't it work to compare the decompressed stream? Is an identical ZIP > > file a requirement? > > By definition a Reproducible Build means a bit-by-bit identical APK, including > the signature (which is why I built a tool to extract an existing signature > and > use it as a build input instead of the private key). Which means you need > identical compressed data for Reproducible Builds. > > Having identical uncompressed data gets you pretty close to the goals of RB, > but > unpacking and/or skipping over signatures is very very hard to get right and > simply cannot provide the same guarantees as having two bitwise identical > files. > > And it's impossible to create an APK you can actually install if it's not > bit-by-bit identical as the signature would not be valid otherwise. So yes, > unfortunately an identical ZIP file is a requirement and comparing the > decompressed stream not an option, which is why this kind of change is not > something we can just consider an implementation detail or work around. > > I wrote more about the very messy situation Fedora's switch to zlib-ng already > created for Android Reproducible Builds [1]. Which likely would have broken a > lot more reproducible Android apps already if Fedora's OpenJDK packages linked > against the system zlib like Debian's OpenJDK packages do (instead of using an > embedded copy of regular zlib). > > - Fay > > [1] > https://lists.reproducible-builds.org/pipermail/rb-general/2024-September/003547.html > -- SY, Konstantin Demin
Re: Accepted matrix-synapse 1.116.0-1 (source) into unstable
Hi Jonas, Thanks for helping with maintaining Synapse. I appreciate that you did some valuable work, but it would be great if you gave me a heads-up before uploading. While we’re both members of the team, and it’s true I haven’t had time to dedicate to Debian recently, there was a workflow for this package which you didn’t respect by uploading directly without any discussion and without proposing your changes as a merge request. Moreover, there was an existing merge request which you disregarded. Please don’t do this in future. On Thu, 3 Oct 2024, at 20:05, Debian FTP Masters wrote: >* simplify rules; > build-depend on dh-rust (not dh-cargo); > add X-Cargo-Crates hint; > drop patch debian-rust I disagree with you using dh-rust. Please revert this change. If dh-cargo doesn’t work well enough, it needs to be improved, not replaced. -- Cheers, Andrej
Re: Supporting alternative zlib implementations
On 2024-09-26 01:35:45 [+0200], Fay Stegerman wrote: > For example, ZIP files or Android APKs built on a Debian system will have a > different compressed stream, like the test files you mention. Which will > likely > break Reproducible Builds tooling like apksigcopier [1] and > reproducible-apk-tools [2]. wouldn't it work to compare the decompressed stream? Is an identical ZIP file a requirement? > There might also be issues with reproducibility of Debian packages themselves > if > e.g. zlib-ng output can differ on different hardware (e.g. number of cores) > even > with an otherwise identical build environment. At the very least I think it > would be good to know how all this could be affected (and how likely things > are > to remain as stable as zlib has been so far) before making a decision to > switch. I don't know at this time. Maybe we could throw it into exp first and evaluate the situtation. > - Fay Sebastian
Re: [Pkg-matrix-maintainers] Accepted matrix-synapse 1.116.0-1 (source) into unstable
Quoting Andrej Shadura (2024-10-03 21:41:49) > Hi Jonas, > > Thanks for helping with maintaining Synapse. > > I appreciate that you did some valuable work, but it would be great if you > gave me a heads-up before uploading. While we’re both members of the team, > and it’s true I haven’t had time to dedicate to Debian recently, there was a > workflow for this package which you didn’t respect by uploading directly > without any discussion and without proposing your changes as a merge request. > Moreover, there was an existing merge request which you disregarded. > > Please don’t do this in future. > > On Thu, 3 Oct 2024, at 20:05, Debian FTP Masters wrote: > >* simplify rules; > > build-depend on dh-rust (not dh-cargo); > > add X-Cargo-Crates hint; > > drop patch debian-rust > > I disagree with you using dh-rust. Please revert this change. > If dh-cargo doesn’t work well enough, it needs to be improved, not replaced. I am awfully sorry that I took for granted that I could contribute without close coordination with you. I cannot revert the use of dh-rust and still have a package that builds. What I can do, and will do if you want me to, is to a) remove myself again as uploader, and b) request that ftpmasters remove the package from unstable. Do you want me to make sure that my contribution here is nullified? 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 signature.asc Description: signature
Re: [Pkg-matrix-maintainers] Accepted matrix-synapse 1.116.0-1 (source) into unstable
Quoting Jonas Smedegaard (2024-10-03 23:08:38) > Quoting Andrej Shadura (2024-10-03 21:41:49) > > Hi Jonas, > > > > Thanks for helping with maintaining Synapse. > > > > I appreciate that you did some valuable work, but it would be great if you > > gave me a heads-up before uploading. While we’re both members of the team, > > and it’s true I haven’t had time to dedicate to Debian recently, there was > > a workflow for this package which you didn’t respect by uploading directly > > without any discussion and without proposing your changes as a merge > > request. Moreover, there was an existing merge request which you > > disregarded. > > > > Please don’t do this in future. > > > > On Thu, 3 Oct 2024, at 20:05, Debian FTP Masters wrote: > > >* simplify rules; > > > build-depend on dh-rust (not dh-cargo); > > > add X-Cargo-Crates hint; > > > drop patch debian-rust > > > > I disagree with you using dh-rust. Please revert this change. > > If dh-cargo doesn’t work well enough, it needs to be improved, not replaced. > > I am awfully sorry that I took for granted that I could contribute > without close coordination with you. > > I cannot revert the use of dh-rust and still have a package that builds. > What I can do, and will do if you want me to, is to a) remove myself > again as uploader, and b) request that ftpmasters remove the package > from unstable. > > Do you want me to make sure that my contribution here is nullified? Please disregard, as I did manage to push a package release with my change of debhelper tool reverted, by pushing a source-only build. Again, I am terribly sorry for my stupidity, and I wish you the best with the future maintenance of the 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 signature.asc Description: signature
Re: Supporting alternative zlib implementations
* Sebastian Andrzej Siewior [2024-10-03 22:03]: > On 2024-09-26 01:35:45 [+0200], Fay Stegerman wrote: > > For example, ZIP files or Android APKs built on a Debian system will have a > > different compressed stream, like the test files you mention. Which will > > likely > > break Reproducible Builds tooling like apksigcopier [1] and > > reproducible-apk-tools [2]. > > wouldn't it work to compare the decompressed stream? Is an identical ZIP > file a requirement? By definition a Reproducible Build means a bit-by-bit identical APK, including the signature (which is why I built a tool to extract an existing signature and use it as a build input instead of the private key). Which means you need identical compressed data for Reproducible Builds. Having identical uncompressed data gets you pretty close to the goals of RB, but unpacking and/or skipping over signatures is very very hard to get right and simply cannot provide the same guarantees as having two bitwise identical files. And it's impossible to create an APK you can actually install if it's not bit-by-bit identical as the signature would not be valid otherwise. So yes, unfortunately an identical ZIP file is a requirement and comparing the decompressed stream not an option, which is why this kind of change is not something we can just consider an implementation detail or work around. I wrote more about the very messy situation Fedora's switch to zlib-ng already created for Android Reproducible Builds [1]. Which likely would have broken a lot more reproducible Android apps already if Fedora's OpenJDK packages linked against the system zlib like Debian's OpenJDK packages do (instead of using an embedded copy of regular zlib). - Fay [1] https://lists.reproducible-builds.org/pipermail/rb-general/2024-September/003547.html
Bug#1083229: ITP: intel-qpl -- Intel Query Processing Library (Intel QPL)
Package: wnpp Severity: wishlist Owner: Miguel Bernal Marin X-Debbugs-Cc: debian-devel@lists.debian.org, miguel.bernal.ma...@gmail.com * Package name: intel-qpl Version : 1.6.0 Upstream Contact: Maria Zhukova * URL : https://github.com/intel/qpl * License : MIT Programming Lang: Assembly, C, C++ Description : Intel Query Processing Library (Intel QPL) The Intel Query Processing Library (Intel QPL) is an open-source library to provide high-performance query processing operations on Intel CPUs. Intel QPL is aimed to support capabilities of the new Intel In-Memory Analytics Accelerator (Intel IAA) available on Next Generation Intel® Xeon® Scalable processors, codenamed Sapphire Rapids processor, such as very high throughput compression and decompression combined with primitive analytic functions, as well as to provide highly-optimized SW fallback on other Intel CPUs. Intel QPL primarily targets applications such as big-data and in-memory analytic databases. Intel QPL provides Low-Level C API. You can use it from C/C++ applications. See also: https://www.intel.com/content/www/us/en/developer/tools/query-processing-library/overview.html I intend to maintain this Debian package, and tracking recent releases, checking the code for any security issues and programming issues using static analysis tools and contributing to the upstream project with any fixes I make during as I support this package. Sincerely, Miguel Bernal Marin
Bug#1083231: ITP: fonts-roboto-mono -- Monospace font from Google developed for Android
Package: wnpp Severity: wishlist Owner: Russell Coker X-Debbugs-Cc: debian-devel@lists.debian.org * Package name: fonts-roboto-mono Version : 20240508-1 Upstream Contact: Christian Robertson * URL : https://github.com/googlefonts/RobotoMono/tree/main * License : Apache-2.0 Programming Lang: UFO (fontmake compiler) Description : Monospace font from Google developed for Android This is a fixed width font developed for Android which should work well for modern smart phones. It also works well for desktop PCs. . It replaces the prior fonts Noto and Droid for Google use. . https://en.wikipedia.org/wiki/Roboto#Roboto_Mono See the Wikipedia page for background information. This package was developed as a replacement for the noto font family and while it's a matter of taste I like it better and expect that many others will too. We have 5 packages for roboto proportional fonts so it makes sense to have the mono one as well. I will maintain it on my own. I don't expect that there will be a new upstream release any time soon and if it happens I don't expect a security problem or other issue that requires a fast response. This package should just work in the same way for decades.
Bug#1083234: RFH: libpgjava libscram-java libstringprep-java -- Java database (JDBC) driver for PostgreSQL and dependencies
Package: wnpp Severity: normal X-Debbugs-Cc: libpgj...@packages.debian.org, libscram-j...@packages.debian.org, libstringprep-j...@packages.debian.org, debian-devel@lists.debian.org, Debian Java Maintainers , Debian PostgreSQL Maintainers Control: affects -1 + src:libpgjava I request assistance with maintaining the libpgjava package and the libscram-java libstringprep-java dependencies. PostgreSQL JDBC Driver allows Java programs to connect to a PostgreSQL database (8.4 or later) using standard, database independent Java code. It is an open source JDBC driver written in Pure Java (Type 4), and communicates in the PostgreSQL native network protocol. Truth is, I do not understand the maven build system and even less so what the debhelper integration does with it. So far, forward-porting the libpgjava packaging to newer versions has worked, but now libscram-java has released a new version, and I just don't know how to update it to the new version. libstringprep-java has had a new version around for years, but it was incompatible with the back then current libscram-java version. Perhaps that situation has changed, and it can be updated as well (or even has to). Please get in touch with me, or just push and upload the new version(s) if you have the salsa permissions. Thanks, Christoph
