Re: Next attempt to add Blends to Debian installer
Andreas Tille writes: ... > As far as I understood Phil's last posting he is working on an enhanced > tasksel. Actually, what I've been working on is infrastructure to allow others to contribute to such an effort. I've recently enabled a CI pipeline in the tasksel master branch, so anyone forking that will now get the benefit of this work for free (as long as they set the CI file to be 'debian/salsa-ci.yml'). I intend to blog about the details shortly, but a quick run down is that this pipeline was triggered by a commit to my fork: https://salsa.debian.org/philh/tasksel/-/pipelines/337031 which (via a multi-project pipeline) generates a mini-iso: https://salsa.debian.org/installer-team/debian-installer/-/jobs/2364015/artifacts/file/public/gtk-mini.iso that is configured to use an additional apt repo, which in this case includes a version of tasksel built from the above branch: https://salsa.debian.org/installer-team/branch2repo/-/jobs/2364013/artifacts/browse/public/pool/main/t/tasksel/ which one can then download the min-iso for testing, and/or cause to be automatically tested with openQA, as seen here: https://openqa.debian.net/tests/overview?groupid=13&build=-salsa-337031:philh:tasksel:salsa-CI_tasksel where if one drills down to the logs, and search for 'salsaci', one can see that the tasksel packages came from the extra repo: https://openqa.debian.net/tests/37964/logfile?filename=_collect_data-debs.txt The same is true for udebs that are included at build time, and that would be expected to be downloaded at d-i runtime, so simply by creating named branches with the same name across all the (u)debs that one wants to test together you can get hold of a mini-iso that will use those versions in preference to the released versions, without needing to know anything about building d-i or debian CDs. Hopefully that lowers the bar enough so that people can concentrate on the bits they want to improve without immediately getting stuck on how they could possibly test their efforts. However, I've not really put much thought into what actually needs to be changed in order to address the Blends Selection problem. In the past when this has come up I've come up with some temporary hacks that worked around the lack of a decent user interface, but if we want to fix this properly then I think Steve has a point that one way to do that is to extend debconf, and then use new features in tasksel. I don't have anything like a design for how that should look in my head though -- I guess interested parties should get together and come up with a design _before_ we start trying to implement it :-) Cheers, Phil. -- |)| Philip Hands [+44 (0)20 8530 9560] HANDS.COM Ltd. |-| http://www.hands.com/http://ftp.uk.debian.org/ |(| Hugo-Klemm-Strasse 34, 21075 Hamburg,GERMANY signature.asc Description: PGP signature
Bug#1003942: ITP: cisco7crack -- Crypt and decrypt the cisco type 7 passwords
Package: wnpp Severity: wishlist Owner: Guilherme de Paula Xavier Segundo X-Debbugs-Cc: debian-devel@lists.debian.org, guilherme@gmail.com * Package name: cisco7crack Version : 0.0~git20121221.f1c21dd-1 Upstream Author : Davide Madrisan * URL : https://github.com/madrisan/cisco7crack * License : GPL-2+ Programming Lang: C Description : Crypt and decrypt the cisco type 7 passwords Crypt and decrypt the cisco type 7 passwords This tool is used to crack Cisco Type 7 passwords. Can be used to encrypt and decrypt Cisco device passwords. . Originally designed in order to allow quick decryption of stored passwords, Type 7 passwords are not a secure form of password storage. There are many tools available that can easily decrypt these passwords. Use of Type 7 passwords should be avoided unless required by a feature that is in use on the Cisco IOS device.
Bug#1003950: ITP: pyobjcryst -- Object-Oriented Crystallographic Library Python3 bindings
Package: wnpp Severity: wishlist Owner: Neil Williams X-Debbugs-Cc: debian-devel@lists.debian.org, codeh...@debian.org * Package name: pyobjcryst Version : 2.2.1-1 Upstream Author : Prof. Simon Billinge * URL : https://github.com/diffpy/pyobjcryst * License : BSD-like custom Programming Lang: C++, Python Description : Object-Oriented Crystallographic Library Python3 bindings Python bindings to ObjCryst++, the Object-Oriented Crystallographic Library. . Some examples offer 3D support which can use python3-ipywidgets. . This package installs the library for Python 3. This package is to be maintained within the Debian PaN Maintainers team and Debian Science Team. The package build-depends in libobjcryst (ITP #1001380) which in turn build-depends on cctbx (ITP: 679905), so packaging work will continue for a while until cctbx is accepted from NEW and libobjcryst can go through NEW.
Re: The future of src:ntp
On 1/17/22 21:13, Marco d'Itri wrote: On Jan 17, Bernhard Schmidt wrote: What do you think? chrony is MUCH better since Debian 10, I agree that it should be the preferred NTP client for when systemd-timesyncd is not enough. You can definitely spend your time on something more fun and more useful. +1 "chronyc tracking" r0x! :) Thomas Goirand (zigo)
Bug#1003961: ITP: cwl-upgrader -- Common Workflow Language standalone document upgrader
Package: wnpp Severity: wishlist Owner: Jonas Smedegaard X-Debbugs-Cc: debian-devel@lists.debian.org -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 * Package name: cwl-upgrader Version : 1.2.2 Upstream Author : Common Workflow Language contributors * URL : https://github.com/common-workflow-language/cwl-upgrader * License : Apache-2.0 Programming Lang: Python Description : Common Workflow Language standalone document upgrader cwl-upgrader is a standalone upgrader for Common Workflow Language documents from draft-3, v1.0, and v1.1 to v1.2. . It does not check for correctness of the input document, for that one can use the CWL reference implementation available for Debian in package cwltool. . The Common Workflow Language (CWL) is a standard for describing computational data-analysis workflows, aiming to allow the creation of a workflow that is portable and thus may be run reproducibly in different computational environments. This package will be maintained in the collaborative Debian section of Salsa. - Jonas -BEGIN PGP SIGNATURE- iQIzBAEBCgAdFiEEn+Ppw2aRpp/1PMaELHwxRsGgASEFAmHm8t0ACgkQLHwxRsGg ASFs2w/8DCgEf3PaikKgKQYMXPfznS2PepxaeufdKkaBdrqx/72MYkoA54FrTl7I 5kOumrIUJuqFFyJ217KMP0EEyWicCbe+CV+c51OROlrDE8zrVxc2wnlamsyxxoiy /q9umRGGu814BhbFtJmWdYc3rQOs13TMmq53n9UsVmrDyF7FgZx1mZ6rfBrZNTVT UfJ9oz2qUnc8fYs4dhxpJXgPQB09wrhW57ne/lojzzc2BBusc2nBGeJlvRq7c1gG 6iNmzIjictXMVln/uU+Rht+kXVrK7Nps28V0dpuY6JzoWFDLzk4HejrrZiHTVvfs DqvwnUHRpywZvadBbTZOnU7IRSKYyl/R8xrX2W6h3QcbhQH8s8KXhsDnAfd6qlYc puNehfbd5ShuPercg8LX/FegzLDn/ke71f1XCywupT3MDaiKLD55Ess5O4vrJEcM gesCtLZ7vqEZl8HRQe+uO37cOi/jmQMMbCLJuW5ExeTZCsPQJ0AL5iK9jpm+gXCu GaKRPK3T5bY4bZTvJjSV+LAJddvNw2zJ28FZXtvhep3W9+O3aH856u3IwvJBR2XX IHUaC/J+3VRQkgVCou+jlWmwWIzq9R64nVzn2gZtseQjaQzEeGOOslygI+5WbBPe 9fviZB/5vMi7JWpJ0ev4ezByd89VdWI+JrlDGqjyeO2O03mfJJA= =FM+D -END PGP SIGNATURE-
Re: The future of src:ntp
Bernhard Schmidt wrote on 17/01/2022: > ntpsec and ntp should be largely configuration compatible, so even a > takeover of the binary package names might be practical. I played a bit with ntpsec some time ago, I remember being very pleased with it, and I think it can very well replace ntp in Bookworm. The incompatible changes [1] are not blockers IMHO, provided that they're documented. I'd prefer making ntp a dummy package depending on ntpsec rather than having src:ntpsec takeover bin:ntp. A dummy package will allow us to easily switch back to ntp from ntp.org if needed, and to document the incompatible changes in NEWS.Debian. Paride [1] https://docs.ntpsec.org/latest/ntpsec.html#incompatible
Re: The future of src:ntp
Bernhard Schmidt wrote: > However, development for ntp.org is slow, upstream still using BitKeeper > is cumbersome, and even the testsuite needs to be fixes on some > architectures for new releases. Both ntpsec and chrony are (from my POV) > the better alternatives now. To a point where I would rather use chrony > for new deployments, but I'm shying away from not using my own work > anymore for the lack of real-life testing. Agreed, I think we should simply remove src:ntp at this point. Fedora migrated existing installs to ntpsec it seems: (https://fedoraproject.org/wiki/Changes/NtpReplacement Cheers, Moritz
Re: The future of src:ntp
Am 18.01.22 um 19:44 schrieb Moritz Mühlenhoff: Bernhard Schmidt wrote: However, development for ntp.org is slow, upstream still using BitKeeper is cumbersome, and even the testsuite needs to be fixes on some architectures for new releases. Both ntpsec and chrony are (from my POV) the better alternatives now. To a point where I would rather use chrony for new deployments, but I'm shying away from not using my own work anymore for the lack of real-life testing. Agreed, I think we should simply remove src:ntp at this point. Fedora migrated existing installs to ntpsec it seems: (https://fedoraproject.org/wiki/Changes/NtpReplacement I think Fedora prefers chrony instead of ntpsec. Fwiw, I'm with Marco here: If systemd-timesyncd (a simple SNTP client which is enabled by default) doesn't fit your needs, chrony is a great alternative. If "ntp" the binary package would become a transitional package that installs chrony, that'd be fine with me if that eases the transition. I'd also be ok if src:ntp would just be dropped and we document that in our release notes accordingly. OpenPGP_signature Description: OpenPGP digital signature
Re: The future of src:ntp
On Jan 18, Michael Biebl wrote: > I think Fedora prefers chrony instead of ntpsec. Fedora even uses btrfs, so who cares. :-) The interesting point is that RHEL switched to chrony for RHEL 7. Also, I want to add that chrony is not just better as a client, but also as a NTP server. https://engineering.fb.com/2020/03/18/production-engineering/ntp-service/ offers quite some insights. > If "ntp" the binary package would become a transitional package that > installs chrony, that'd be fine with me if that eases the transition. I am not sure that this would be practical since they cannot share the same configuration. I have no objections if somebody wants to work on packaging ntpsec, but I do not think that either ntp or ntpsec should be promoted over chrony nowadays. -- ciao, Marco signature.asc Description: PGP signature
Re: The future of src:ntp
Marco d'Itri wrote on 18/01/2022: > On Jan 18, Michael Biebl wrote: > >> If "ntp" the binary package would become a transitional package that >> installs chrony, that'd be fine with me if that eases the transition. > I am not sure that this would be practical since they cannot share the > same configuration. > I have no objections if somebody wants to work on packaging ntpsec, but > I do not think that either ntp or ntpsec should be promoted over chrony > nowadays. But ntpsec is already packaged and actively maintained, which is why I propose making ntp a transitional package installing ntpsec. After all bin:ntp has always been a specific NTP implementation, I think it's OK if it's replaced by an almost compatible fork, less OK if a completely different implementation is brought in instead. Dropping ntp altogether will certainly surprise some users. Paride
Bug#1003985: ITP: yggdrasil-go -- foo
Package: wnpp Severity: wishlist Owner: John Goerzen X-Debbugs-Cc: debian-devel@lists.debian.org Package: wnpp Severity: wishlist Owner: John Goerzen * Package name: yggdrasil-go Version : 0.4.2-1 Upstream Author : Yggdrasil Network * URL : https://github.com/yggdrasil-network/yggdrasil-go * License : LGPL Programming Lang: Go Description : Scalable, distributed, encrypted IPv6 overlay network Yggdrasil is a fully end-to-end encrypted IPv6 network. It is lightweight, self-arranging, supported on multiple platforms and allows pretty much any IPv6-capable application to communicate securely with other Yggdrasil nodes. Yggdrasil does not require you to have IPv6 Internet connectivity - it also works over IPv4.
Bug#1003988: ITP: golang-github-arceliar-phony -- A ponylang-inspired actor model library for Go
Package: wnpp Severity: wishlist Owner: John Goerzen * Package name: golang-github-arceliar-phony Version : 0.0~git20210209.dde1a8d-1 Upstream Author : Arceliar * URL : https://github.com/Arceliar/phony * License : MPL-2.0 Programming Lang: Go Description : A ponylang-inspired actor model library for Go Phony is a Pony-inspired proof-of-concept implementation of shared-memory actor-model concurrency in the Go programming language. Actors automatically manage goroutines and use asynchronous causal messaging (with backpressure) for communcation. This makes it easy to write programs that are free from deadlocks, goroutine leaks, and many of the for loops over select statements that show up in boilerplate code. The down side is that the code needs to be written in an asynchronous style, which is not idiomatic to Go, so it can take some getting used to.
Re: The future of src:ntp
[I'm the Debian ntpsec maintainer.] On 1/18/22 11:21 AM, Paride Legovini wrote: > I'd prefer making ntp a dummy package depending on ntpsec rather than > having src:ntpsec takeover bin:ntp. If I understand correctly, you're suggesting src:ntp builds bin:ntp that is a dummy package which depends on ntpsec? Another option would be to have src:ntpsec build the bin:ntp dummy package and remove src:ntp entirely. Either seems fine to me. I don't have a strong preference. I can implement whatever is necessary on the ntpsec side. And for either option, probably likewise ntp-doc -> ntpsec-doc, ntpdate -> ntpsec-ntpdate, and if I broke out ntpdig as suggested in bug #1003966, sntp -> ntpsec-ntpdig. There are some differences. For example, ntp stores its configuration file at /etc/ntp.conf while ntpsec uses /etc/ntpsec/ntp.conf. [1] But bin:ntpsec's postinst already handles that transition. On 1/18/22 5:03 PM, Paride Legovini wrote: > bin:ntp has always been a specific NTP implementation, I think > it's OK if it's replaced by an almost compatible fork, less OK if a > completely different implementation is brought in instead. I'm biased here, but I agree. I think it makes the most sense to transition existing ntp installs to ntpsec, not chrony, as ntpsec is a drop-in replacement with a shared code history. This is my position even if we think that chrony should be the default for new installs. On that topic, I think the current default of systemd-timesyncd is fine. [1] When I was first packaging ntpsec, I was going to have it share as many paths, service names, etc. with ntp (as upstream NTPsec does). But this lead to issues with certain tooling (e.g. around init scripts) and ultimately I decided it was better to use a different namespace. This does mean that Debian ntpsec is patched and diverges a bit from upstream NTPsec. -- Richard OpenPGP_signature Description: OpenPGP digital signature
