Re: The future of src:ntp
Bernhard Schmidt writes: > - Since NTS leverages X.509, how does it work with a broken clock on > boot that is ticking outside of the certificate validity period? I don't know how it is intended to work, but it seems pretty obvious that NTS certificate validation must ignore the validity period. If you have a validating DNS resolver with correct time, then you might replace it with DANE validation (i.e if the certificate matches the current DNS TLSA record then it is valid regardless of current time). But I don't know if you can make that a requirement. Bjørn
Re: The future of src:ntp
On Jan 19, Paride Legovini wrote: > That's what I had in mind, but the other option: > > > Another option would be to have src:ntpsec build the bin:ntp dummy > > package and remove src:ntp entirely. > > also looks sensible to me after all. No strong opinion. I think that this would be better since they are close enough that ntpsec can usually be a drop-in replacement. -- ciao, Marco signature.asc Description: PGP signature
Re: The future of src:ntp
On 1/19/22 20:34, Richard Laager wrote: For people that want something more than systemd-timesyncd, e.g. to get NTS, I think either are acceptable choices. It seems that the consensus for new installs is towards chrony over ntpsec. But I don't think we as the distro need to push either over systemd-timesyncd. For people who don't care, systemd-timesyncd should be fine. Do you disagree on that point (that systemd-timesyncd is fine for people who don't care about NTP)? If so, can you elaborate? Well, could you elaborate why you didn't write "chrony is fine for people who don't care"? I fail to understand why you're having a preference on systemd-timesyncd... Cheers, Thomas Goirand (zigo)
Re: The future of src:ntp
2022, ജനുവരി 19 5:27:28 PM IST, Paride Legovini ൽ എഴുതി >Richard Laager wrote on 19/01/2022: >> 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? > >That's what I had in mind, but the other option: > >> Another option would be to have src:ntpsec build the bin:ntp dummy >> package and remove src:ntp entirely. > >also looks sensible to me after all. No strong opinion. Do we really need a dummy package for upgrades to work? Can't ntpsec binary package just add Provides: ntp (=$source:Version) ? >Paride > -- Sent from my Android device with K-9 Mail. Please excuse my brevity.
Re: The future of src:ntp
On Thu, 20 Jan 2022 at 20:09:18 +0530, Pirate Praveen wrote: > Do we really need a dummy package for upgrades to work? Yes, we do need transitional packages. > Can't ntpsec binary package just add Provides: ntp (=$source:Version) ? No, apt won't automatically replace a real package "ntp" with a package that merely Provides: ntp during upgrades. (One way to think about this is: how would that work? If more than one package provided ntp, which one would be correct for apt to choose, and why?) smcv
Re: The future of src:ntp
On 1/20/22 8:04 AM, Thomas Goirand wrote:
On 1/19/22 20:34, Richard Laager wrote:
For people that want something more than systemd-timesyncd, e.g. to
get NTS, I think either are acceptable choices. It seems that the
consensus for new installs is towards chrony over ntpsec. But I don't
think we as the distro need to push either over systemd-timesyncd. For
people who don't care, systemd-timesyncd should be fine.
Do you disagree on that point (that systemd-timesyncd is fine for
people who don't care about NTP)? If so, can you elaborate?
Well, could you elaborate why you didn't write "chrony is fine for
people who don't care"?
Because that question is about changing the status quo, where
systemd-timesyncd is the default.
I fail to understand why you're having a
preference on systemd-timesyncd...
Let me separate the two scenarios:
A) Imagine we had no NTP support by default and we are considering
adding NTP support to the default install.
B) systemd-timesyncd is currently the default and we are discussing
whether it should be changed.
In both scenarios, I assume that most users don't particularly care
about their NTP daemon. They don't generally interact with it. They just
want their clock to be "accurate enough". (And for people who don't
care, "accurate enough" is pretty wide. If you need extremely precise
time, you presumably know that and thus care about things like NTP or
even PTP.) This is no different than other system components: some
people have preferences (sometimes strong ones) about certain
components, but essentially nobody cares about every single one.
In scenario A, any of chrony, ntp, ntpsec, or systemd-timesyncd will
achieve the desired objective of having an accurate enough clock by
default. So we would consider other things, for example:
One might say ntpsec > ntp, because ntpsec comes from the same history
(so has the same advantages) plus the codebase has been cleaned up
(which has security and maintainability advantages). Also, the ntp
maintainer wants to discontinue maintaining it.
One might say that chrony > {ntp, ntpsec, systemd-timesyncd?} because
chrony is more accurate. FWIW, I can't personally weigh in on that
argument, as I haven't researched it well enough myself.
One might say that systemd-timesyncd > {chrony, ntp, ntpsec} because
it's part of systemd, which we're already using by default.
One might say that {chrony, ntpsec} > systemd-timesyncd because they
support NTS. Of course, there are problems with configuring NTS by
default, as I mentioned.
These, and potentially other factors, would need to be weighed.
Different individuals might come to different conclusions.
In scenario B, it's the same calculation, PLUS we need to overcome the
inertia of the current default. The new default must be sufficiently
better to be worth the change.
Personally, my take is:
It's not practical to deploy NTS by default right now. If we had
multiple operators of geo-diverse, high-capacity, non-smeared (or
consistently smeared and a consensus that this was desirable by default)
NTS servers, that'd be different. So NTS is not currently a
consideration for the default.
systemd-timesyncd is good enough for people who don't particular care
about their NTP daemon. For people that do care, they are free to
install software of their choice, be that chrony or ntpsec.
--
Richard
OpenPGP_signature
Description: OpenPGP digital signature
Work-needing packages report for Jan 21, 2022
The following is a listing of packages for which help has been requested through the WNPP (Work-Needing and Prospective Packages) system in the last week. Total number of orphaned packages: 1223 (new: 5) Total number of packages offered up for adoption: 188 (new: 3) Total number of packages requested help for: 61 (new: 0) Please refer to https://www.debian.org/devel/wnpp/ for more information. The following packages have been orphaned: lqa (#1004030), orphaned yesterday Description: LAVA QA tool Installations reported by Popcon: 4 Bug Report URL: https://bugs.debian.org/1004030 slowmovideo (#1003730), orphaned 6 days ago Description: create slow-motion videos from your footage Installations reported by Popcon: 99 Bug Report URL: https://bugs.debian.org/1003730 snacc (#1004110), orphaned today Description: ASN.1 to C or C++ or IDL compiler Reverse Depends: libsnacc-dev snacc wireshark-dev Installations reported by Popcon: 143 Bug Report URL: https://bugs.debian.org/1004110 waylandpp (#1003739), orphaned 6 days ago Description: wayland compositor infrastructure - C++ bindings Reverse Depends: kodi-bin waylandpp-dev Installations reported by Popcon: 1890 Bug Report URL: https://bugs.debian.org/1003739 xmix (#1003910), orphaned 3 days ago Description: X11-based interface to the Linux sound driver mixer Installations reported by Popcon: 108 Bug Report URL: https://bugs.debian.org/1003910 1218 older packages have been omitted from this listing, see https://www.debian.org/devel/wnpp/orphaned for a complete list. The following packages have been given up for adoption: dvdtape (#1003908), offered 3 days ago Description: Create DVD master filesystems on DLT media Installations reported by Popcon: 19 Bug Report URL: https://bugs.debian.org/1003908 python-ppft (#1003846), offered 4 days ago Description: distributed and parallel Python library Installations reported by Popcon: 3 Bug Report URL: https://bugs.debian.org/1003846 xplanet (#1003911), offered 3 days ago Description: planetary body renderer Reverse Depends: pysatellites Installations reported by Popcon: 1865 Bug Report URL: https://bugs.debian.org/1003911 185 older packages have been omitted from this listing, see https://www.debian.org/devel/wnpp/rfa_bypackage for a complete list. For the following packages help is requested: apache2 (#910917), requested 1195 days ago Description: Apache HTTP Server Reverse Depends: apache2 apache2-ssl-dev apache2-suexec-custom apache2-suexec-pristine backuppc bfh-container-server courier-webadmin cvsweb debbugs-web doc-central (137 more omitted) Installations reported by Popcon: 97810 Bug Report URL: https://bugs.debian.org/910917 aufs (#963191), requested 579 days ago Description: driver for a union mount for Linux filesystems Reverse Depends: fsprotect Installations reported by Popcon: 9418 Bug Report URL: https://bugs.debian.org/963191 autopkgtest (#846328), requested 1877 days ago Description: automatic as-installed testing for Debian packages Reverse Depends: debci-worker sbuild-qemu Installations reported by Popcon: 1239 Bug Report URL: https://bugs.debian.org/846328 balsa (#642906), requested 3770 days ago Description: An e-mail client for GNOME Reverse Depends: balsa Installations reported by Popcon: 660 Bug Report URL: https://bugs.debian.org/642906 cargo (#860116), requested 1745 days ago Description: Rust package manager Reverse Depends: dh-cargo rust-all Installations reported by Popcon: 2749 Bug Report URL: https://bugs.debian.org/860116 courier (#978755), requested 385 days ago Description: Courier mail server Reverse Depends: courier-faxmail courier-filter-perl courier-imap courier-ldap courier-mlm courier-mta courier-pcp courier-pop courier-webadmin couriergrey (3 more omitted) Installations reported by Popcon: 917 Bug Report URL: https://bugs.debian.org/978755 cron (#984736), requested 319 days ago Description: new maintainer need Reverse Depends: apticron autolog backintime-common btrfsmaintenance buildd checksecurity clamtk cricket email-reminder exim4-base (20 more omitted) Installations reported by Popcon: 206941 Bug Report URL: https://bugs.debian.org/984736 cyrus-imapd (#921717), requested 1077 days ago Description: Cyrus mail system - IMAP support Reverse Depends: cyrus-admin cyrus-caldav cyrus-clients cyrus-dev cyrus-imapd cyrus-murder cyrus-nntpd cyrus-pop3d cyrus-replication In
Re: Next attempt to add Blends to Debian installer
On Tue, Jan 18, 2022 at 09:52:42AM +0100, Philip Hands wrote:
> 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 :-)
This sounds like you need someone with UX design experience to look at
this first, before you can actually implement things properly.
Perhaps this is something that could be posted as a "job" on the open
source design website? I've used them in the past to great effect for
the review interface of SReview, my video review system (we did a talk
about that process at FOSDEM 2019; you can see the video at
https://archive.fosdem.org/2019/schedule/event/open_source_design_in_trenches/)
You'd need someone who's willing and able to implement the required
changes to give feedback to the designer, and you'd need to commit to a
bit of time in order to do this properly (in my experience there were a
few iterations of back-and-forth improvements that did take some time to
get fleshed out), but I think the end result is worth it...
--
w@uter.{be,co.za}
wouter@{grep.be,fosdem.org,debian.org}
Bug#1004120: ITP: debianutils-tempfile -- tempfile from debianutils
Package: wnpp Severity: wishlist Owner: Johannes Schauer Marin Rodrigues X-Debbugs-Cc: debian-devel@lists.debian.org, jo...@debian.org * Package name: debianutils-tempfile Version : 4.11 Upstream Author : Johannes Schauer Marin Rodrigues * URL : https://salsa.debian.org/debian/debianutils-tempfile * License : GPL2+ Programming Lang: C Description : tempfile from debianutils debianutils is currently blocked from migrating to testing [1] due to its removal of tempfile from the Essential:yes set [2]. The debianutils maintainer would like to avoid reintroducing tempfile in debianutils but is willing to add a Depends relationship to another package that implements tempfile. I thus just packaged the last version of tempfile from debianutils in this new source package. The packaging can be found at [3]. This version of tempfile is the same as the last version of tempfile shipped by debianutils and thus includes the deprecation warning. The package is supposed to be temporary until all tools moved away from tempfile (famous last words). [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=996747 [2] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=992399#20 [3] https://salsa.debian.org/debian/debianutils-tempfile
