Re: RFC: Support for selective usage of (fake)root during package build (R³)
Niels Thykier: > Hi > > We have written a new specification for supporting selective usage of > (fake)root during package builds (see attached file). The specification > defines a new field called "Rules-Requires-Root" (R³ for short) that > enables maintainers to define if and how their package requires root > during package build. > > The specification is accompanied by an initial implementation in dpkg > and debhelper (in unstable), so you can experiment with it already now. > While dpkg and debhelper implement the entire specification, there are > still some limitations in what we can support at the moment. These > limitations are listed in the "Limitations" section below. > > * Please, review the specification plus implementations and provide >feedback on the proposal. > > * Deadline for feedback: 2 weeks from today (but we are happy to extend >it if people find this too short). >- if there are no major concerns with this proposal at that time > we will consider the specification as stable, and mark it as so. > > * Even though we think the current specification is solid, as long >as it is not marked as stable, it might change its semantics, and >any early adopter should be prepared to adapt to new updates. > > [...] > > Thanks, > Guillem and Niels > Hi, While there has not been any comments / feedback on devel-devel, we have seen about 35-40 packages adopting R³ since the proposal was posted to debian-devel. :) This puts us on about ~50 packages that can now build without (fake)root today (per [codesearch query]). * Please consider taking R³ for a spin and see if it works for your packages. * Thanks to Simon McVittie (#880095), dh_girepository now supports R³=no builds (available both in unstable and testing). * If your package is (bit-for-bit) reproducible, then the checksum will generally remain the same when you adopt R³ (assuming you fixate package version, build-dependencies, etc.). * Even when you do not have/get a bit-for-bit reproducible output, there is always diffoscope to tell you what changed. Thanks, ~Niels PS: Thanks to codesearch.d.n for making a (mostly) "silent adoption" visible! -- [codesearch query]: https://codesearch.debian.net/search?q=Rules-Requires-Root+path%3A%2Fdebian%2Fcontrol&perpkg=1 NB: There are 5 unique packages in the "per package view". Currently, dpkg is still "opt'ing out" but is expected to opt-in on the 1.19.1 upload.
Bug#880731: ITP: node-num2fraction -- convert number to fraction
Package: wnpp Severity: wishlist Owner: Wout Bertrums X-Debbugs-CC: debian-devel@lists.debian.org * Package name: node-num2fraction Version : 1.2.2 Upstream Author : yisi (http://iyunlu.com/view) * URL : https://github.com/yisibl/num2fraction#readme * License : Expat Programming Lang: JavaScript Description : convert number to fraction This modules converts a number to a fraction. For example: 0.2 → 1/5. . Node.js is an event-based server-side JavaScript engine. It is a dependency of GitLab. I would like to maintain this package as part of JavaScript packaging team. Praveen has agreed to sponsor this package.
Bug#880799: ITP: prelude-lml-rules -- Rules for Prelude LML package
Package: wnpp Severity: wishlist Owner: Thomas Andrejak * Package name: prelude-lml-rules Version : 3.1.0 Upstream Author : Thomas Andrejak * URL : https://www.prelude-siem.org/ * License : GPL-2 Programming Lang: C, Python Description : Rules for Prelude LML package Rules for Prelude LML contributed by the community Since Prelude 1.1, rules of Prelude LML are in an other package that the initial prelude-lml. This new package is prelude-lml-rules and has to be packaged for new prelude-lml versions. I plan to maintain it.
Bug#880825: ITP: libkcapi -- Linux Kernel Crypto API User Space Interface Library
Package: wnpp Severity: wishlist Owner: Mathieu Malaterre * Package name: libkcapi Version : 1.0.0 Upstream Author : Stephan Mueller * URL : http://www.chronox.de/libkcapi.html * License : BSD Programming Lang: C Description : Linux Kernel Crypto API User Space Interface Library The Linux kernel exports a Netlink interface of type AF_ALG to allow user space to utilize the kernel crypto API. libkcapi uses this Netlink interface and exports easy to use APIs so that a developer does not need to consider the low-level Netlink interface handling. . The library does not implement any cipher algorithms. All consumer requests are sent to the kernel for processing. Results from the kernel crypto API are returned to the consumer via the library API. . The kernel interface and therefore this library can be used by unprivileged processes.
Re: RFC: Support for selective usage of (fake)root during package build (R³)
On Sat, Nov 04, 2017 at 07:14:00AM +, Niels Thykier wrote:
> Niels Thykier:
> > We have written a new specification for supporting selective usage of
> > (fake)root during package builds (see attached file). The specification
> > defines a new field called "Rules-Requires-Root" (R³ for short) that
> > enables maintainers to define if and how their package requires root
> > during package build.
>
> While there has not been any comments / feedback on devel-devel, we have
> seen about 35-40 packages adopting R³ since the proposal was posted to
> debian-devel. :)
> This puts us on about ~50 packages that can now build without
> (fake)root today (per [codesearch query]).
Have you perhaps gathered some data about how many packages would build
reproducibly wrt the old state after a blind mechanical change to R³?
I'd guess it's the vast majority (especially if you change MakeMaker).
I do have a concern: this adds a yet another field every new package needs
to manually set. And even if in 10 years from now, the Policy will require
R³ to be set (even to "yes" ("binary-targets")), it'd be a manual effort for
every single package.
Thus, what about making R³ default to "no" in a new dh compat level?
--
⢀⣴⠾⠻⢶⣦⠀ Laws we want back: Poland, Dz.U. 1921 nr.30 poz.177 (also Dz.U.
⣾⠁⢰⠒⠀⣿⡁ 1920 nr.11 poz.61): Art.2: An official, guilty of accepting a gift
⢿⡄⠘⠷⠚⠋⠀ or another material benefit, or a promise thereof, [in matters
⠈⠳⣄ relevant to duties], shall be punished by death by shooting.
