Bug#1072974: ITP: kilo -- Small text editor
Package: wnpp Severity: wishlist Owner: Alex Myczko X-Debbugs-Cc: debian-devel@lists.debian.org * Package name: kilo Version : 0.0.1 Upstream Authors: Salvatore Sanfilippo URL : https://github.com/antirez/kilo * License : BSD-2 Description : Small text editor This is a text editor in less than 1000 LOC with syntax highlighting and search.
Bug#1072975: ITP: edlin -- Standard line editor
Package: wnpp Severity: wishlist Owner: Alex Myczko X-Debbugs-Cc: debian-devel@lists.debian.org * Package name: edlin Version : 2.17 Upstream Authors: Gregory Pietsch URL : https://github.com/FDOS/edlin * License : GPL-2+ Description : Standard line editor This is a small line editor, written for FreeDOS as a functional clone of the old MS-DOS program edlin. It differs from MS edlin in that first, it's free software, and second, the user interface is slightly different in a few places. The reason for the difference is so that the user does not have to type in control characters mandated by MS edlin's syntax.
Re: Mandatory LC_ALL=C.UTF-8 during package building
Hi, On 6/11/24 00:26, Simon McVittie wrote: Reproducibility outside of sterile environments is however a problem for us as a distribution, because it affects how well people are able to contribute to packages they are not directly maintaining If our package-building entry point sets up aspects of its desired normalized (or "sterile") environment itself, surely it's equally easy for those contributors to build every package in that way, whether they maintain this particular package or not? Yes, but building the package is not the hard part in making a useful contribution -- anything but trivial changes will need iterative modifications and testing, and the package building entrypoint is limited to "clean and build entire package" and "build package without cleaning first", with the latter being untested and likely broken for a lot of packages -- both meson and cmake utterly dislike being asked to configure an existing build directory as if it were new. For my own packages, I roughly know how far I can deviate from the clean environment and still get meaningful test results, but for anything else, I will still need to deep-dive into the build system to get something that is capable of incremental builds. if my package is not required to work outside of a very controlled environment, that is also an impediment to co-maintenance I'm not sure that follows. If the only thing we require is that it works in a controlled environment, and the controlled environment is documented and easy to achieve, then surely every prospective co-maintainer is in an equally good position to be contributing? That seems better, to me, than having unwritten rules about what environment is "close enough" and what environment doesn't actually work. I will need to deviate from the clean environment, because the clean environment does not have vim installed. Someone else might need to deviate further and have a graphical environment and a lot of dbus services available because their preferred editor requires it. Adding a global expectation about the environment that a package build can rely on *creates* an unwritten per-package rule whether it is permissible to deviate from this expectation during development. I expect that pretty much no one uses the C.UTF-8 locale for their normal login session, so adding this as a requirement to the build environment creates a pretty onerous rule: "if you want to test your changes, you need to remember to call make/ninja with LC_ALL=C.UTF-8." Of course we know that this rule is bullshit, because the majority of packages will build and test fine without it, but this knowledge is precisely one of the "unwritten rules" that we're trying to avoid here. We already do expect maintainers to be building in a specified environment: Debian unstable (not stable, and not Ubuntu, for example). I develop mostly on Debian or Devuan stable, then do a pbuilder build right before upload to make sure it also builds in a clean unstable environment. The original requirement was mostly about uploading binary packages, which we (almost) don't do anymore. (I also do agree that it is an anti-pattern if we have a specified environment where tests or QA will be run, and serious consequences for failures in that environment, without it being reasonably straightforward for contributors to repeat the testing in a sufficiently similar controlled environment that they have a decent chance at being able to reproduce the failure. But, again, that isn't this thread.) This is largely what I think is this thread -- narrowing the environment where builds, tests and QA will be run, and narrowing what will be considered a bug. Indeed -- however this class of bugs has already been solved because reproducible-builds.org have filed bugs wherever this happened, and maintainers have added workarounds where it was impossible to fix. Someone (actually, quite a lot of someones) had to do that testing, and those fixes or workarounds. Who did it benefit, and would they have received the same benefit if we had said "building in a locale other than C.UTF-8 is unsupported", or in some cases "building in a non-UTF-8 locale is unsupported", and made it straightforward to build in the supported locales? I'd say that developers who don't have English as their first language have directly benefited from this, and would not have benefited if it was not seen as a problem if a package didn't build on their machines without the use of a controlled environment. I also think that we have indirectly benefited from better test coverage. Turning this workaround into boilerplate code was a mistake already, so the answer to the complaint about having to copy boilerplate code that should be moved into the framework is "do not copy boilerplate code." If you don't want package-specific code to be responsible for forcing a "reasonable" locale where necessary, then what layer do you want to be resp
Re: Enabling some -Werror=format* by default?
Hi! On Mon, 2024-06-10 at 18:01:58 +0200, Helmut Grohne wrote: > Ideally, we'd not just do a rebuild with the flags, but also do a > rebuild without and then compare the binary .debs. In the event that we > misguide configure, we expect the .debs to differ and otherwise to equal > due to the work of the reproducible builds folks. That equality has a > really annoying difference in practice though: Build ids are dependent > on the compiler flags, so the comparison would have to magically ignore > changes in build id and this is where things become quite difficult. A quick check seems to indicate warning flags do not get recorded in the object files, which make sense as these are not supposed to change the emitted objects. (This can be seen with «dwarfdump .../*.debug | grep DW_AT_producer» on the debug files from the -dbgsym packages.) Thanks, Guillem
Re: Seeking consensus on file conflict between python3-proto-plus and nanopb
Hi Laszlo and Yogeswaran, I'm explicitly adding Laszlo to Cc to increase the chances of him chiming in. On Mon, Jun 10, 2024 at 06:40:02PM -0400, Yogeswaran Umasankar wrote: > There is a file conflict between python3-proto-plus and nanopb. The > conflict arises due to both packages has a file at > /usr/lib/python3/dist-packages/proto/__init__.py [0]. I am maintaining > python3-proto-plus, and I am seeking guidance. Thank you for going the extra mile and resolving this constructively and consensually. > The module name "proto" is an integral part of the python3-proto-plus > package. Renaming the "proto" module in python3-proto-plus would > significantly impact future dependent packages. I agree with this assessment. At the same time, I note that "proto" is a fairly generic name. Even though it seems unlikely that upstream would want to change it, I think telling them would be useful still. It definitely is conceivable that another project would later try to also use this module name and therefore it is best to avoid it. > It appears that nanopb's use of the module name "proto" does not align > with the conventional identification of a Python module. Given this, it > might be plausible to make this module private within the nanopb > package. This adjustment could potentially resolve the conflict without > affecting the dependent packages. Yes. In particular, I could not locate external uses of nanopb's proto module. chromium and firefox also use this module name though my impression is that they have another conflict on this name again arguing in favour of not using it at all. > I have attempted to reach out to the nanopb maintainer to discuss this > issue, but I have not yet received a response. In case the maintainer is > MIA, should I proceed with renaming the "proto" module in nanopb to > "nanopb-proto"? As one of the team members, I am willing to implement > this change if it is deemed the best solution. I recommend that you send a patch to the bug and give Laszlo two weeks before proceeding to NMU in the absence of a reply as the proposed change is a bit intrusive. Helmut
Re: Seeking consensus on file conflict between python3-proto-plus and nanopb
Hi, On 6/11/24 07:40, Yogeswaran Umasankar wrote: It appears that nanopb's use of the module name "proto" does not align with the conventional identification of a Python module. Given this, it might be plausible to make this module private within the nanopb package. This adjustment could potentially resolve the conflict without affecting the dependent packages. From a quick glance at the package, not completely. It seems the "proto" module is used by the generator only, which is called as a plugin from Google protoc, so I'm not sure it can be taken fully private. I think it should be possible to rename this module though with little adverse effect. The standard invocation certainly is convoluted[1], and given that CMake is usually not the first choice for cross compiling in embedded environments, I also expect that there will be a lot of users rolling their own -- but I don't see the name of the module used on that command line, only the name of the plugin. The script tries to do a relative import and provides fallback code if that is not yet supported in the Python interpreter (which it is since 2007), so that might explain why the module is not up to current conventions. Simon [1] https://github.com/nanopb/nanopb/blob/master/extra/FindNanopb.cmake
Bug#1073003: ITP: python-django-structlog -- Structured Logging for Django
Package: wnpp Severity: wishlist Owner: Michael Fladischer X-Debbugs-Cc: debian-devel@lists.debian.org -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 * Package name: python-django-structlog Version : 8.1.0 Upstream Contact: Michael Fladischer * URL : https://github.com/jrobichaud/django-structlog * License : Expat Programming Lang: Python Description : Structured Logging for Django django-structlog is a structured logging integration for Django project using structlog. Logging will then produce additional cohesive metadata on each logs that makes it easier to track events or incidents. I intend to maintain this as part of the DPT. -BEGIN PGP SIGNATURE- iQFPBAEBCgA5FiEEqVSlRXW87UkkCnJc/9PIi5l90WoFAmZogXwbHGZsYWRpc2No ZXJtaWNoYWVsQGZsYWRpLmF0AAoJEP/TyIuZfdFqXPoIAJC4pQVllONVB1tF0xZI 0bJ0HGSW9UHtAC3HlkirN5RNS2Ax8VCUGRQjBlXtfDh38CdHuMH6KodCRi0t0mqR 7lnUu7cvK/I//3FGutqKonRAO9RQGA5d+dqLGauATQ0CrRFSU05BMspRAdWWjWHA 4/iaVbl2crB2obgQnCxHFf3Wg/HowdchY2yyMQlgeQgt1SdIzu0ttt+LZKqUaYs/ zM+DHBVL0hRF92JcROvTD/iH5X3DCsCp7upkkvYZ45NyVMBza68lKwGUkIwQh9LJ nrs5oibLlkupbhXPyGMJvcLPf1irbVae2Aw/icWAKAlelHorMqw1cwuBm6EhQbx8 Hvo= =XYb0 -END PGP SIGNATURE-
Re: Illegal Instruction Using sudo in Bookworm on i686
Hi, On 09-06-2024 1:56 p.m., rhys wrote: So given that these no longer fit the "old and busted" description, is Debian going to stick with the decision to not support them? Or is Debian going to continue to support this processor, since it is still apparently a viable product, enough that new systems are using it? https://lists.debian.org/debian-devel-announce/2023/12/msg3.html still stands. Debian basically isn't going to support any i386 CPU anymore in the sense that the Release Team gave the teams the wildcard to drop kernel, installer and images support for i386 (I don't have the details of the current status). """ Following that, there are two routes into running i386: 1. as a multi-arch option on an otherwise amd64 system 2. as an i386 chroot on another architecture system """ That's what we intend to do as Debian. If you want an Debian architecture to keep Debian running on i386 CPU's, you can create a port. But unless you find enough volunteers, I'm a bit skeptical you'll succeed. There are enough problems to cover, of which upstream kernel support and the 32 bit memory build problem are on the top of my mind. Paul OpenPGP_signature.asc Description: OpenPGP digital signature
