Re: feedback for NEW packages: switch to using the BTS?
Paul Wise left as an exercise for the reader: > I think the same problem and suggestions also apply with the current > system of prods and rejects, so please do add or propose adding it in > the appropriate documentation and templates. I will of course seek to > preserve these statements if I end up working on the BTS proposal. absolutely, there's just enough opacity in a current REJECT (in my fairly minimal experience) that i think it less susceptible to such invalid inferences. but yes, this is something that could go in the Mentors notes now. (to be sure, at no time did i intend to impugn your suggestions in this thread, which seem a definite improvement from the user's perspective.) -- nick black -=- https://www.nick-black.com to make an apple pie from scratch, you need first invent a universe. signature.asc Description: PGP signature
Re: feedback for NEW packages: switch to using the BTS?
On Sat, 2022-04-30 at 22:47 -0400, nick black wrote: > i understand. i suppose that what i'm saying is it will probably > be worthwhile to convey in Mentors etc. documentation that > "resolving the bugs filed thus far [regarding the package in > NEW] does not imply that no further bugs will be filed." > > i'm just worried that people will get a bug filed that is not a > complete, exhaustive analysis, and think that it's the only > thing standing between them and archive glory. perhaps whatever > files the bug ought indicate this in the text of the bug itself. I think the same problem and suggestions also apply with the current system of prods and rejects, so please do add or propose adding it in the appropriate documentation and templates. I will of course seek to preserve these statements if I end up working on the BTS proposal. -- bye, pabs https://wiki.debian.org/PaulWise signature.asc Description: This is a digitally signed message part
Bug#1010416: ITP: python-ansible-compat -- Ansible compatibility goodies
Package: wnpp Severity: wishlist Owner: Josenilson Ferreira da Silva X-Debbugs-Cc: debian-devel@lists.debian.org, nilsonfsi...@hotmail.com * Package name: python-ansible-compat Version : 2.0.2 Upstream Author : Sorin Sbarnea * URL : https://github.com/ansible/ansible-compat * License : MIT Programming Lang: Python Description : Ansible compatibility goodies Python package contains functions that facilitate working with various versions of Ansible 2.9 and newer.
Re: feedback for NEW packages: switch to using the BTS?
Paul Wise left as an exercise for the reader: > > if resolving the resulting bug report is the bar needing clearing to > > enter the archive, that does seem to require FTPmasters to create a > > complete statement of REJECT-worthy problems in each uploaded > > package, which seems like more work than they must currently do. > > The bar for acceptance would be the same as it is now, the proposal > just changes how the issues blocking acceptance are communicated. > Now you get a REJECT mail, under the proposal you get a serious bug. i understand. i suppose that what i'm saying is it will probably be worthwhile to convey in Mentors etc. documentation that "resolving the bugs filed thus far [regarding the package in NEW] does not imply that no further bugs will be filed." i'm just worried that people will get a bug filed that is not a complete, exhaustive analysis, and think that it's the only thing standing between them and archive glory. perhaps whatever files the bug ought indicate this in the text of the bug itself. -- nick black -=- https://www.nick-black.com to make an apple pie from scratch, you need first invent a universe. signature.asc Description: PGP signature
Re: feedback for NEW packages: switch to using the BTS?
On Sat, 2022-04-30 at 14:20 -0700, Sean Whitton wrote: > This would really slow things down; > I don't think we could work that way. Using separate bug reports or not would of course be up to the person filing them, but I expect the process could be automated well enough that it wouldn't be much different to the current process (which I am not familiar with). An automated multi-bug process might be something like this; press the button for filing a bug, get a template with the right version etc, type out the problem details, press send, repeat the process. Is the current process any different other than the repeating? -- bye, pabs https://wiki.debian.org/PaulWise signature.asc Description: This is a digitally signed message part
Re: feedback for NEW packages: switch to using the BTS?
Hello, On Sat 30 Apr 2022 at 07:44AM +08, Paul Wise wrote: > It also means the ftpmasters can file separate bugs for each problem, > rather than combining them all into one mail. This would really slow things down; I don't think we could work that way. -- Sean Whitton signature.asc Description: PGP signature
Bug#1010396: ITP: tsn-scripts -- Tool set for Time Sensitive Networking testing
Package: wnpp Severity: wishlist Owner: Vladimir Oltean * Package name: tsn-scripts Version : 0.8 Upstream Author : Vladimir Oltean * URL : https://github.com/vladimiroltean/tsn-scripts * License : GPL Programming Lang: C Description : Tool set for Time Sensitive Networking testing The tsn-scripts project contains the isochron program, a real-time application for testing Time Sensitive Networking equipment. It works by monitoring the network synchronization status and sending time-triggered Ethernet packets. It has a server-client architecture and it measures network latency by taking multiple timestamps (some hardware, some software) along the path of the packets. It has been tested by me on x86_64, armv7 and armv8 systems, but care has been taken for format interoperability with big endian systems such as PowerPC. The isochron program is mainly used in system testing, and there is a desire to integrate it in the kselftest framework of the Linux kernel, where it will constitute the basis for future TSN selftests of equipment from various vendors. There is no existing program known to me that serves this role. During review of the kernel selftests it was pointed out that for users it may be desirable for isochron to be distributed by Debian: https://patchwork.kernel.org/project/netdevbpf/patch/20220428204839.1720129-1-vladimir.olt...@nxp.com/#24838122 This is my first Intent To Package. I am the upstream maintainer of the project, would like to be the maintainer of the Debian package as well, and would need a sponsor and mentor to help with review and walk me through the packaging process. I am flexible in making changes to the upstream project if this makes Debian packaging easier. In fact, in expectation of changes to come, I've marked "v0.8" as the version of the software to package, as opposed to the currently latest "v0.7".
Bug#1010395: ITP: neom -- desktop IM client for the Matrix protocol
Package: wnpp Severity: wishlist Owner: Jonas Smedegaard X-Debbugs-Cc: debian-devel@lists.debian.org, Matrix Packaging Team -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 * Package name: neom Version : 0.0~git20220427 Upstream Author : Antti Keränen * URL : https://git.sr.ht/~detegr/neom * License : BSD-3-clause Programming Lang: Rust Description : desktop IM client for the Matrix protocol Neom is A Matrix client that tries to be light but feature complete. . Matrix is an open, federated communications protocol. The project is in arly development still. It is only vaguely usable, and until it matures it will be used to test packaging of Rust crates also needed by Fractal (when that project uses stable crate releases). This project will be maintained in the Matrix team, here: https://salsa.debian.org/matrix-team/neom - Jonas -BEGIN PGP SIGNATURE- iQIzBAEBCgAdFiEEn+Ppw2aRpp/1PMaELHwxRsGgASEFAmJtLswACgkQLHwxRsGg ASF+0A/9EqWo+qLftjIwtnwV4j2qBi/8k3b/0vww87S48V8kUy+v3FjT/VEQjCGv O34O6g5yJgz8/vQWPwU6EOOJEZ/C90FPA8fKlxitrJsVqQcWVQDwGFEdBeMzP48D 2wiNKA/hs9juRB4HeN1xVeqcsTZzUsLRaMqm1oXrydgN2/dxnc0c+uxcwQ/+Xw+5 cRLHYfnVMx6wZZBBNQQekFe2IXeN07T9s9FG3a6DWZjviBHAv+1tRyQ2IEsH4x5I KDVUao3pB/v1yBeXjVuKtSQDmsU8+TV/uONPQt9IedHg4/roqZT/CPtVRWfFf1Av E7QYQecN52YYSNuSmg48xi+9J2zbKyS3XHGF/W5FNG32ojffE3bcLu2KQkyDTaPJ 4L00jyLcGPAQjpBZmw/r4RIr3y+vMVAZRWmQqolJyDSf9v7xcN6LK+UC9XvmEEgO 8onKgzX/Vn5rufw4hODzUuaIK+YC9pHTZ5GUD8VfOpIsOe/4j/EF2n/mxsJCgXlk 6msnSI5yem/AGbKuRtCYjBW7uPFtkD2k5C5pkXBEs3f7RRI3U40PRY4wu8y8nEVz 0SL7v0dzAAMLXtgypjBtFbWfoT5tcjiHe9PAD6AOhCrV8b3OcnF26EicXXFTdvpV arnzEssOqSx9gZMshpZsOZRHFk2r3F+cU6sn8nY9JqObWm2jPdQ= =mcqw -END PGP SIGNATURE-
Re: Firmware - what are we going to do about it?
Hi Steve et al, On Tue, Apr 19, 2022 at 01:27:46AM +0100, Steve McIntyre wrote: > TL;DR: firmware support in Debian sucks, and we need to change this. See the > "My preference, and rationale" Section below. Thank you for the excellent write-up. > 5. We could split out the non-free firmware packages into a new > non-free-firmware component in the archive, and allow a specific exception > only to allow inclusion of those packages on our official media. We would > then generate only one set of official media, including those non-free > firmware packages. My perception is that we already have largely consensus on this option despite a few vocal minorities disagreeing with it. I think that the main disagreements fall into one of two categories: * Debian should provide an entirely free installation media. * The user should have a choice for whether to run/install non-free firmware. A few people have spoken in favour of continuing the building of free images. Can you give more intuition on how much extra cost (work) these images add if the alternative is to only produce the ones with non-free firmware? How about reducing the effort to test free images? I imagine here that we kinda reverse our current presentation. Rather than show the free ones and hide the non-free ones, we'd present the ones with firmware as official installation media. I trust that those users that really need the free ones, will be able to locate them despite not being presented prominently. If continuing the production of free images does not impose an undue workload, I think we could increase the consensus for an option 5b (and also produce hidden free images). Regarding the choice, Russ and others mentioned that the presentation of that choice is not encoded in the option. From a GR-pov, I think that's the right way forward. However, we may discuss it separately. The argument about making an informed choice seems rather convincing to me. As such, I'd prefer for the default installation to do the following: * Check whether any non-free firmware is being used by the installer. I'm not 100% sure whether this is possible with reasonable effort and precision, but an approximation might not be too bad. A first try could be: dmesg | grep "firmware: direct-loading firmware" * Add a prompt to the default installation that asks whether non-free firmware should be included in the installation. It should also indicate whether non-free firmware has already been used in the process of booting the installation media. Regardless of whether it has been used, I'd prefer the default answer to be "yes". * Possibly add a second prompt in case firmware has been used and the user said "no" to ask for confirmation as this outcome would be very unlikely. * The prompts should be preseedable. This one likely is easy. I understand that much of what I'm proposing here puts extra load on the installer team. That's why I'm interested in better understanding how much extra work that'd be and whether it's worth. My expectation is that these two adaptions would alleviate much of the concern presented in this thread. >From a practical side, I'd likely put option 5 (without the extra changes requested here) somewhere close to the top for all the good reasons given in this thread. Quite clearly, the default installation medium should work and it kinda does not right now. Helmut
Re: feedback for NEW packages: switch to using the BTS?
On Sat, 2022-04-30 at 03:09 -0400, nick black wrote: > currently, as far as i understand things, a REJECT can be issued > for the first REJECT-worthy problem. The same would occur under the proposal, except that there would presumably be separate bug reports for separate issues. > if resolving the resulting bug report is the bar needing clearing to > enter the archive, that does seem to require FTPmasters to create a > complete statement of REJECT-worthy problems in each uploaded > package, which seems like more work than they must currently do. The bar for acceptance would be the same as it is now, the proposal just changes how the issues blocking acceptance are communicated. Now you get a REJECT mail, under the proposal you get a serious bug. -- bye, pabs https://wiki.debian.org/PaulWise signature.asc Description: This is a digitally signed message part
Re: feedback for NEW packages: switch to using the BTS?
Paul Wise left as an exercise for the reader: > Packages with incomplete or incorrect debian/copyright information > currently would recieve a REJECT rather than acceptance. The proposal > would not change that, just turn that REJECT into a bug report, which > you could fix in a second upload to NEW and then the package would be > reprocessed and get an ACCEPT or another bug. currently, as far as i understand things, a REJECT can be issued for the first REJECT-worthy problem. if resolving the resulting bug report is the bar needing clearing to enter the archive, that does seem to require FTPmasters to create a complete statement of REJECT-worthy problems in each uploaded package, which seems like more work than they must currently do. if the resulting bug is *not* a complete statement of problems, and that is understood, this isn't an issue. just a thought. -- nick black -=- https://www.nick-black.com to make an apple pie from scratch, you need first invent a universe. signature.asc Description: PGP signature
