Re: Debian openssh option review: considering splitting out GSS-API key exchange
On Tue, Apr 02, 2024 at 01:30:10AM +0100, Colin Watson wrote: * add dependency-only packages called something like openssh-client-gsskex and openssh-server-gsskex, depending on their non-gsskex alternatives * add NEWS.Debian entry saying that people need to install these packages if they want to retain GSS-API key exchange support * add release note saying the same * for Debian trixie+1 (or maybe after the next Ubuntu LTS, depending on exact timings): * add separate openssh-gsskex source package, carrying gssapi.patch in addition to whatever's in openssh, and whose binary packages Conflicts/Replaces/Provides the corresponding ones from openssh * add some kind of regular CI to warn about openssh-gsskex being out of date relative to openssh * drop gssapi.patch from openssh, except for small patches to configuration file handling to accept the relevant options with some kind of informative warning (compare https://bugs.debian.org/152657) To speed things up for those who really want it, perhaps make openssh-client/server dependency-only packages on openssh-client/server-nogss? People can choose the less-compatible version for this release if they want to, and the default can change next release. Pushing back the ability to install the unpatched version for a few more years seems suboptimal.
Re: Linking coreutils against OpenSSL
On Sat, Nov 11, 2023 at 11:50:31AM +0100, Andreas Metzler wrote:
you seem to have missed/deleted the paragraph where Ansgar suggested how
to do this *without* tradeoff. ("explicitly disable/enable build options
per arch")
No, I didn't. That was in my original email and is one of the
possibilities for future versions depending on the feedback from people
testing to guide whether it makes sense to make this per-arch rather
than global.
Re: Linking coreutils against OpenSSL
On Fri, Nov 10, 2023 at 03:10:42PM +0100, Ansgar wrote: Please avoid producing different results depending on the build environment. That just results in non-reproducible issues in unclean environments (suddenly different dependencies, different features, ...). I think that is an acceptable tradeoff at this time; the only difference will be the dependencies, but that is the intent. Automated buildd packages should be stable. Based on further experience and feedback, one of the other options could be chosen instead. (I'm particularly interested in hearing from people who compare the different builds on arm, as that is where there's been an assertion of a performance regression.)
Re: Linking coreutils against OpenSSL
On Fri, Nov 10, 2023 at 10:38:13AM +, Luca Boccassi wrote: Per-architecture dependencies are possible though, so maybe starting to add the libssl dependency only on amd64 is a good starting point, and then users of other architectures can request to be added too if it is beneficial for them. I haven't seen any objections to the basic idea, so I'm starting here: coreutils 9.4-2 will link to libcrypto if there's a gpl-compatible version available at build time, but I've added the build-dependency as linux-amd64 only for now. That should make it fairly straightforward for people to control the linking on other architectures by controlling their build environment. Going forward, depending on feedback, I can roll this back, expand the build-dep, and/or make the configure option also depend on the arch.
Re: Potential MBF: packages failing to build twice in a row
On Mon, Aug 14, 2023 at 09:40:52PM +0100, Wookey wrote: On 2023-08-14 10:19 -0400, Michael Stone wrote: On Thu, Aug 10, 2023 at 02:38:17PM +0200, Lucas Nussbaum wrote: > On 08/08/23 at 10:26 +0200, Helmut Grohne wrote: > > Are we ready to call for consensus on dropping the requirement that > > `debian/rules clean; dpkg-source -b` shall work or is anyone interested > > in sending lots of patches for this? > > My reading of the discussion is that there's sufficient interest for > ensuring that building-source-after-successful-binary-build works. my reading said that there was interest in making sure that binary builds work repeatedly, and almost no interest in making sure that building source from a rules/clean works. certainly not thousands of packages worth of busy work level of interest. Yes. You are right. I (and most of the others who expressed an interest in having this working) mostly care about doing a binary build repeatedly. But doesn't this amount to much the same thing? no, not really. a lot of benign changes (like copying in new autoconf stuff) can happily be made multiple times, which doesn't affect building at all but causes busy work to undo. dpkg-source will moan if the source has changed and tell you about the nice patch it has made. OK, it will let some things slide as just warnings, so 'builds binary twice' is a somewhat less stringent target than 'leaves exactly the original pristine source'. I would have to check the details, but I'm not sure how much difference this makes in practice? we don't know, since the test was "regenerate source"--a thing very few people care about--rather than "build twice" which is the thing people do seem to care about. It seems likely that the difference is thousands of packages. I'm somewhat concerned we magically went from "should we do an MBF" to "I just did an MBF" without any real consensus in the middle. This being so painfully obvious that the MBF itself basically says there's no consensus.
Re: Potential MBF: packages failing to build twice in a row
On Thu, Aug 10, 2023 at 02:38:17PM +0200, Lucas Nussbaum wrote: On 08/08/23 at 10:26 +0200, Helmut Grohne wrote: Are we ready to call for consensus on dropping the requirement that `debian/rules clean; dpkg-source -b` shall work or is anyone interested in sending lots of patches for this? My reading of the discussion is that there's sufficient interest for ensuring that building-source-after-successful-binary-build works. my reading said that there was interest in making sure that binary builds work repeatedly, and almost no interest in making sure that building source from a rules/clean works. certainly not thousands of packages worth of busy work level of interest.
Re: Proposed MBF - removal of pcre3 by Bookworm
On Sat, Jul 01, 2023 at 09:44:27AM -0400, Michael Stone wrote: On Thu, Jun 29, 2023 at 08:55:11PM +0100, Matthew Vernon wrote: Bookworm is now out; I will shortly be increasing the severity of the outstanding bugs to RC, with the intention being to remove src:pcre3 from Debian before the trixie release. You don't think that marking packages for removal two weeks after the bug is filed is a little much? Apologies, the original bug report apparently slipped under the radar.
Re: Proposed MBF - removal of pcre3 by Bookworm
On Thu, Jun 29, 2023 at 08:55:11PM +0100, Matthew Vernon wrote: Bookworm is now out; I will shortly be increasing the severity of the outstanding bugs to RC, with the intention being to remove src:pcre3 from Debian before the trixie release. You don't think that marking packages for removal two weeks after the bug is filed is a little much?
Re: OpenMPI 5.0 to be 32-bit only ?
On Wed, Feb 15, 2023 at 11:29:25AM +, Alastair McKinstry wrote: The counterpoint is if someone does a high-core-count 32-bit arch for HPC; x32 could (have been) such an architecture, but its development looks stalled. That may have been a possibility 15-20 years ago, but today anything calling itself "HPC" is working with datasets large enough that trying to use 32 bit pointers would be far more trouble than it's worth; x32 is of interest to container services far more than HPC, IMO. (Even the GPUs have working sets above 4GB currently--the days of a viable 32 bit architecture in this space are entirely in the rear view mirror.) I personally think it makes far more sense to excise MPI from architectures where it will never realistically be used than it does to try to keep it going just to have it.
Re: Firmware GR result - what happens next?
On Fri, Oct 14, 2022 at 10:52:01AM +0200, Santiago Ruano Rincón wrote: 5. transitional packages along with a helper package (that fails or success during install) to prompt the user so they add non-free-firmware section when needed. Is there any reason why you are not considering 5.? The danger we're trying to avoid is that a system with a working "something" (say, networking) gets upgraded, user reboots (or machine crashes, or there's a power failure, etc, etc.), the working "something" is now a not-working "something", and fixing it is really hard for the user who has no idea what happened and maybe doesn't have a network or a console or whatever any more. A package that fails during install will prevent the upgrade from completing, but will leave things in an in-between state until some action is taken, the upgrade restarted, and the upgrade manages to finish successfully. What happens if the reboot/crash/powercycle/etc happens during that in-between state? How do you make a firmware helper package that reliably prevents a kernel installation when the kernel doesn't have any dependencies on the firmware package, and also doesn't yank out the old working firmware, etc. I'm sure you can make the install explode, but making it reliably explode at just the right time seems harder. I guess this could all work, but I'm seeing a lot of potential for partial installs/failures with this approach and I suspect this would require transition code in a number of packages' preinsts, not a discrete "helper package".
Re: Firmware GR result - what happens next?
On Sun, Oct 02, 2022 at 08:21:31PM +0100, Steve McIntyre wrote: Plus, as Shengjing Zhu points out: we already expect people to manage the sources.list anyway on upgrades. We also try to avoid silent install problems that might or might not result in a system that doesn't boot properly.
Re: Firmware GR result - what happens next?
On Sun, Oct 02, 2022 at 03:53:00PM +0100, Steve McIntyre wrote: On Sun, Oct 02, 2022 at 04:43:47PM +0200, Michael Biebl wrote: What's the plan for upgraded systems with an existing /etc/apt/sources.list. Will the new n-f-f section added on upgrades automatically(if non-free was enabled before)? So this is the one bit that I don't think we currently have a good answer for. We've never had a specific script to run on upgrades (like Ubuntu do), so this kind of potentially breaking change doesn't really have an obvious place to be fixed. Is there a reason to not continue to make the packages available in non-free? I don't see a reason to force any change on existing systems.
Re: Switch default from PulseAudio to PipeWire (and WirePlumber) for audio
On Thu, Sep 29, 2022 at 04:26:45PM +0200, Vincent Bernat wrote: On 2022-09-29 15:01, Michael Stone wrote: On Wed, Sep 28, 2022 at 09:02:15PM -0600, Sam Hartman wrote: * Finally, I can use bluetooth on linux with reasonably good audio quality! Aren't they both using the same backend? ldac/aptx weren't in pulseaudio for a long time, but they are now. Or is there something else? Pipewire has AAC, but not in Debian because libfdk-aac is still considered non-free by us while everyone else, including the FSF, consider it free. but that wouldn't be a distinction between pulseaudio and pipewire in debian, right?
Re: Switch default from PulseAudio to PipeWire (and WirePlumber) for audio
On Wed, Sep 28, 2022 at 09:02:15PM -0600, Sam Hartman wrote: * Finally, I can use bluetooth on linux with reasonably good audio quality! Aren't they both using the same backend? ldac/aptx weren't in pulseaudio for a long time, but they are now. Or is there something else?
Re: Switch default from PulseAudio to PipeWire (and WirePlumber) for audio
On Thu, Sep 15, 2022 at 06:13:35PM +0530, Nilesh Patra wrote: As far as I can see, the latest "new upstream" upload to unstable was in "2021-08-25" which is more than an year from now, post which there have been few bug fix uploads. More notable upload has been the one that enables gstreamer support I'm not sure if this is what you are pointing towards with "hasn't stood still" https://tracker.debian.org/news/1306307/accepted-pulseaudio-150dfsg1-4-source-into-unstable/ Ofcourse the maintainers of this package are doing an excellent job but from upstream release pov, it is still kind of standing still. So from the user perspective it's gained new functionality and also not broken what works. I can think of worse problems.
Re: Switch default from PulseAudio to PipeWire (and WirePlumber) for audio
On Tue, Sep 13, 2022 at 07:25:12PM +0200, Michael Biebl wrote: Am 13.09.22 um 18:17 schrieb Antoine Beaupré: I also have the feeling that pipewire has already gone beyond what pulseaudio is capable of in terms of Bluetooth support, but I might be mistaken on that. Interesting. What do you have in mind here? Supported codecs? AptX? I had more success with PA in the past here, but that experience is anecdotal. PA also hasn't stood still, and PA+bluetooth is now working much better than it did even a few months ago.
Re: RFC: Switch default from netkit-telnet(d) to inetutils-telnet(d)
On Wed, Jul 20, 2022 at 05:15:07PM +0200, Adam Borowski wrote: Available in the archive yes, installed by default no way. That makes this current thread mostly moot, as when not installed by default (or a metapackage) you don't need any particular implementation to be blessed. I think the original email outlined why dicussion was necessary: determining which source package provides the "telnet" and "telnetd" packages. Regardless of whether they're installed by default, changing the implementation behind a binary package does warrant notice/discussion. This got derailed by additional commentary about whether they deserve to exist at all, but that's incidental to the original question. (For which, I think, there has been consensus.)
Re: RFC: Switch default from netkit-telnet(d) to inetutils-telnet(d)
On Sun, Jul 17, 2022 at 01:49:53AM -0400, Timothy M Butterworth wrote: Telnet is old, insecure and should not be used any more. What is the point of packaging a Telnet daemon when everyone should be using SSH. Telnet Client I can see because a person may need to connect to a router or switch that is still using telnet or hasn't had SSH Certificates generated yet. I personally use telnet to connect to systems whose ssh implementations are old enough that they are no longer interoperable with current ssh. Every system will eventually become an old system, and telnet has a much better record of working over the long term than does ssh. Security concerns have a place in determining defaults, but not in banning software that other people find useful in a context that might not matter to you.
ifupdown/dhcp
[apologies to package aliases getting this twice due to autocomplete fail] I've been trying to make sense of the NEWS item in isc-dhcp-client (that alternatives are needed) in combination with the functionality of ifupdown and what the implications are for debian upgrades generally. isc-dhcp-client as of the last upgrade is telling users to stop using it (the default dhcp client for debian). ifupdown (the traditional tool for managing networking on debian systems) has a Recommends on "isc-dhcp-client | dhcp-client". "dhcp-client" is a virtual package provided by "dhcpcanon" (version 0.8.5, which hasn't been touched in 4 years), "isc-dhcp-client", and "dhcpcd5" (which will trash a working configuration managed by ifupdown if installed, as it will try to take over interfaces currently set, e.g., to manual). This seems suboptimal at best. I believe that ifupdown will attempt to use udhcpd if installed, which should be a mostly-transparent change (except for the potential loss of lease information and any customization of dhclient scripts) but it isn't even on the ifupdown recommends list. ifupdown also (used to?) use pump, but that package went away a long time ago. So what's the path forward, maintaining compatibility and not breaking systems upgrading from current stable? Do we come up with a dhcpcd5 variant that *only* touches interfaces it is directed to touch via /etc/network/interfaces? Do we add udhcpcd to the "dhcp-client" virtual package and/or make it the default for ifupdown? Do we fork isc's dhcp suite and just continue to use dhclient? Revive pump? Something else?
Re: Seeking consensus for some changes in adduser
On Sun, Mar 13, 2022 at 11:09:24AM +0100, Marc Haber wrote: On Sat, 12 Mar 2022 14:41:35 -0500, Michael Stone wrote: And remember, there are existing real-world debian systems that have users with dots (regardless of local adduser policy; think ldap/ad for example) so these are already issues that either need to be fixed or don't really matter. Yes, they need to be fixed, but it's a different can of beer if we cannot say "hey, you changed our default, so you get to keep the pieces of what got broken" but have to say "oops". I don't think we can say that now, unless we also say that all the tools we have for integrating with external directory services shouldn't be used, and also retroactively change the documentation for adduser.conf to say that you shouldn't use the characters that the man page says you can. In general debian doesn't just say "hey, you changed our default, so you get to keep the pieces of what got broken" for configurations documented as valid.
Re: Q: systemd-timer vs cron
On Sat, Mar 12, 2022 at 03:19:52PM +0800, Paul Wise wrote: Hideki Yamane wrote: Is there any suggestion or guideline for pacakges that contain both systemd-timer unit setting and cronjob? Don't they conflict or not Do what apt does; make the cron job exit successfully without doing anything when run on systemd, move most of what is being run into a script or program in /usr, then call that from the timer and cron job. Alternatively, make the cron job exit successfully without doing anything when run on systemd, then have the timer call the cron job with a --run-on-systemd argument that makes it run under systemd. These are still somewhat annoying in practice because of the log entries for CRON running something pointlessly.
Re: Seeking consensus for some changes in adduser
On Fri, Mar 11, 2022 at 10:16:24PM +0100, Marc Haber wrote: [^[:alpha:]]chown[[:space:]][^[:space:]]+\.[^[:space:]] is found 829 times in Debian, mostly in docs and comments, but also in a few live scripts. I think that we still have some way to go until we get rid of the dot notation in chown calls. It also has to be a variable; if it's "root.root" or such, it doesn't matter. I did a similar search, mostly found false positives (e.g., perl or ruby scripts not actually calling chown(1). The one real example I found in a cursory glance is from /usr/bin/humfsify in uml-utilities...but it's also an example of my point about "so many ways to break shell scripts if you don't follow every semi-documented rule every time": find file_metadata -type d | xargs chown $user.$group so, yeah, that'll break if $user has a dot--but it's already broken if there's a file/directory with a space. So are dots the straw that breaks the camel's back? And remember, there are existing real-world debian systems that have users with dots (regardless of local adduser policy; think ldap/ad for example) so these are already issues that either need to be fixed or don't really matter.
Re: Seeking consensus for some changes in adduser
On Thu, Mar 10, 2022 at 09:33:00PM +0100, Marc Haber wrote: On Wed, 9 Mar 2022 17:29:01 -0500, Michael Stone wrote: On Tue, Mar 08, 2022 at 12:29:43PM -0700, Sam Hartman wrote: I don't think it makes sense to move toward 0700 home directories and to loosen the umask for usergroups. Those are actually unrelated--the big reason for the more permissive umask is to allow people to seamlessly work with other people in a group, especially within setgid shared directories. Those shared directories can be anywhere, and are likely *not* in a single user's home. Hence, no change needed in adduser? Or is that an argument for having DIR_MODE=0700 in default? It's simply a statement that the default mode for home directories and the default umask are separate decisions. This was changed in coreutils to be posix-compliant more than 20 years ago. The spec is that chown accepts user:group syntax, and chown will always first attempt to split on ":". If there is no :, chown will try to resolve the whole argument as a username (that is, regardless of whether there's a "."). If the username isn't resolvable *and* it contains a ".", it will try to split on the first "." and use the left side as the username and the right side as the group. So *only if* someone attempts to use a dot-containing username in chown without a : and the dot-containing username is invalid, then it might be interpreted as a user.group spec. Now, if someone is trying to actually use user.group syntax rather than the user:group syntax that's been standard for 20+ years, that will definitely break in the presence of dot-containing usernames. ... but just in the case that the same string exists both as the last component of a dot-containing user name AND as a group name. All other cases are defined. How would the spec listed above behave for user names with more than one dot? It splits on the first dot, which is why scripts could break. E.g., if you use user.group syntax and user happens to be us.er, then you end up trying to use us.er.group and that will fail. Semi-randomly, for whichever users happen to have dots, so it'll be a pain to debug. Given how common such usernames are on other systems, I'd expect the breakage to be minimal by now, and a bug in anything still using that syntax. We could make coreutils print a deprecation warning, but that's never really been useful in the past; probably better to just error out any time a . is used for something other than a valid username and drop the 20+ year old compatability code. Do you want a coreutils bug to error out in the case of user.group notation in chown? I guess it's due time. Would we go alone in Debian or would you prefer that we try convincing upstream to finally go that way? I am not convinced that Debian should derive from standard behavior here, but you have the coreutils hat on and I would support either decision. I don't have a really strong preference either way. Maybe carry a patch until just before freeze to bubble stuff up during testing? Maybe allow an environment variable to override (either way?) to facilitate testing? The problem is that the systems most likely to blow up (because they're using ancient scripts) are also really unlikely to suddenly start using dot usernames, so breaking them for the sake of correctness on other systems seems gratuitous. If there isn't already, maybe some kind of lintian script check (though that seems probably challenging for static analysis)? In the end, there are already so many ways to shoot yourself in the foot with shell scripts if you don't follow all the disorganized rules every single time that letting this be the reason to disallow dot usernames seems extreme.
Re: Seeking consensus for some changes in adduser
On Thu, Mar 10, 2022 at 06:28:57PM +0100, Vincent Bernat wrote: ❦ 10 March 2022 11:34 -05, Michael Stone: It was always configurable, but was enabled out of the box in hamm... My system was installed on Potato if I remember correctly (or maybe Woody, but definitely not older than Potato). But maybe my home was imported from a SuSE installation and I tweaked something. Likely--a number of other distributions went with a common user group as I recall.
Re: Seeking consensus for some changes in adduser
On Thu, Mar 10, 2022 at 05:06:32PM +0100, Vincent Bernat wrote: ❦ 10 March 2022 11:21 +01, Philip Hands: On systems that don't use usergroups for all/some users, doesn't this change make all files writable by other users by default? That would seem like a very unsecure change on upgrades (or as a default). AFAIK systems that don't use usergroups are already not running in standard Debian configuration, since we default to USERGROUPS_ENAB being 'yes' in login.defs (and likewise USERGROUPS 'yes' in adduser.conf). Has it always been the case? On my oldest system, my primary group is "users". It was always configurable, but was enabled out of the box in hamm...
Re: Seeking consensus for some changes in adduser
On Thu, Mar 10, 2022 at 12:04:38AM +0100, Ansgar wrote: On Wed, 2022-03-09 at 17:29 -0500, Michael Stone wrote: Those are actually unrelated--the big reason for the more permissive umask is to allow people to seamlessly work with other people in a group, especially within setgid shared directories. Those shared directories can be anywhere, and are likely *not* in a single user's home. Setting a default ACL on project directories seems a technical better solution for this problem. Not really--that requires ACL support, and ACL management tends to be a PITA for actual people. It would only affect permissions of files that should intentionally be group-readable, not all files created anywhere. With usergroups, group-readable is a no-op unless you've done something to change the group.
Re: Seeking consensus for some changes in adduser
On Tue, Mar 08, 2022 at 12:29:43PM -0700, Sam Hartman wrote:
I don't think it makes sense to move toward 0700 home directories and to
loosen the umask for usergroups.
Those are actually unrelated--the big reason for the more permissive
umask is to allow people to seamlessly work with other people in a
group, especially within setgid shared directories. Those shared
directories can be anywhere, and are likely *not* in a single user's
home.
On Wed, Mar 09, 2022 at 09:00:14PM +0100, Marc Haber wrote:
On Tue, 8 Mar 2022 17:02:06 -0600, Richard Laager
wrote:
I think the idea of dot in a username is perfectly reasonable on its
own. For some people this is very desirable. My wife, for example, uses
a dot in her email username as her first name plus my-now-her last
initial makes a word that is awkward. (This sort of problem is not
uncommon in usernames, especially at companies that make them via some
algorithm.)
I always use colon for chown, which is what is documented, but I'm aware
it takes dot too. Is there any code in chown to handle the dot case
intelligently?
How would chown handle the dot case intelligently? At the moment, the
chown manpage doesn't contain the words "dot" or "period", but chown
root.root some-file will do the same like chown root:root some-file,
changing user and group.
This was changed in coreutils to be posix-compliant more than 20 years
ago. The spec is that chown accepts user:group syntax, and chown will
always first attempt to split on ":". If there is no :, chown will try to
resolve the whole argument as a username (that is, regardless of whether
there's a "."). If the username isn't resolvable *and* it contains a
".", it will try to split on the first "." and use the left side as the
username and the right side as the group. So *only if* someone attempts
to use a dot-containing username in chown without a : and the
dot-containing username is invalid, then it might be interpreted as a
user.group spec. Now, if someone is trying to actually use user.group
syntax rather than the user:group syntax that's been standard for 20+
years, that will definitely break in the presence of dot-containing
usernames. Given how common such usernames are on other systems, I'd
expect the breakage to be minimal by now, and a bug in anything still
using that syntax. We could make coreutils print a deprecation warning,
but that's never really been useful in the past; probably better to just
error out any time a . is used for something other than a valid username
and drop the 20+ year old compatability code.
On Wed, Mar 09, 2022 at 02:35:52PM -0600, Richard Laager wrote:
Something along the lines of see if the user exists.
If I was to take a stab at an implementation (Python-ish pseudocode
here; yes I know chown is C):
group = None
if ':' in arg:
(user, group) = arg.split(':')
elif '.' in arg:
# This could be:
# user.group
# us.er.group
# user.gr.oup
# us.er.gr.oup
# Or user and/or group could have multiple dots.
# Idea A) Exactly one dot can mean either user.group or us.er
arg_split = arg.split(',', 2)
if len(arg_split) == 3:
# There was more than one dot.
user = arg
else:
# Split on dot.
(user, group) = arg.split('.')
if not getent(user):
# Treat the whole thing as a username.
user = arg
group = None
# Idea B) Loop over each possible split and see if any work.
I think this is much more fragile/less predictable than the current
behavior as the results will be dramatically different depending on the
exact combination of valid users & groups. Better to just make sure
you stick with the standard user:group representation.
Re: Legal advice regarding the NEW queue
On Wed, Feb 02, 2022 at 10:16:36PM +0500, Andrey Rahmatullin wrote: On Wed, Feb 02, 2022 at 12:12:30PM -0500, Michael Stone wrote: On Wed, Feb 02, 2022 at 11:39:11AM -0500, The Wanderer wrote: > Doesn't that, then, lead to the suggestion that any package entering > unstable without having undergone NEW review (which, in the revised > model, might be every new package) should automatically have a bug filed > against it requesting suitable review, and that bug should be treated as > a blocker for entering testing? Not really, since anyone in the world could close said bug (including the uploader). This applies to any RC bug. Yes, but in this case it means that we wouldn't have that minimal standard of at least one person other than the uploader having ever reviewed the package--which I think is a fairly low bar that we should meet. (It would be even better if we could add reviews for changes, but at any rate I don't think we should go backward here.)
Re: Legal advice regarding the NEW queue
On Wed, Feb 02, 2022 at 11:39:11AM -0500, The Wanderer wrote: Doesn't that, then, lead to the suggestion that any package entering unstable without having undergone NEW review (which, in the revised model, might be every new package) should automatically have a bug filed against it requesting suitable review, and that bug should be treated as a blocker for entering testing? Not really, since anyone in the world could close said bug (including the uploader).
Re: Legal advice regarding the NEW queue
On Wed, Feb 02, 2022 at 09:39:02AM -0600, John Goerzen wrote: On Tue, Feb 01 2022, Russ Allbery wrote: I would hate to entirely lose the quality review that we get via NEW, but I wonder if we could regain many those benefits by setting up some sort of peer review system for new packages that is less formal and less bottlenecked on a single team than the current NEW processing setup. This is a fantastic idea. In fact, it wouldn't have to bottleneck packages at all. I mean, if a quality issue is found in NEW, wouldn't the same be an RC bug preventing a transition to testing? I'm not sure "nobody ever looked at this" is a suitable criteria for inclusion in a stable release. We sort of have that problem now in crusty corners of the archive if someone uploads a bad change, but at least there's been one review at some point in the package's lifetime.
Re: Future of /usr/bin/which in Debian?
On Tue, Sep 21, 2021 at 09:00:52AM +0100, Jonathan Dowland wrote: On Mon, Sep 20, 2021 at 11:02:49AM -0400, Michael Stone wrote: It seems to install to /usr/bin/which.gnu, implying that you could upload /usr/bin/which.bsd if you so desire; what's the issue? I think we should have just one which implementation in the archive. We should (have) pick(ed) the best one for Debian. I believe (perhaps unfairly... I'd love to be proven wrong) that the GNU implementation was uploaded very quickly, without the BSD implementation being considered. Perhaps the GNU one is the best fit for our needs. It would have been nice to see that there was an evaluation. I think it doesn't matter how many which implementations are in debian. If you want something with specific portable semantics, just use command -v. The remaining consumers of which are either programs that (ipso facto) don't care about semantic corner cases or are humans who want to use which just because, and probably have strong opinions on how it should behave (as, apparently, you do). We can't satisfy everybody with one implementation, and I see no technical reason that we'd even try to do so.
Re: Future of /usr/bin/which in Debian?
On Mon, Sep 20, 2021 at 02:38:06PM +0100, Jonathan Dowland wrote: On Fri, Aug 20, 2021 at 11:03:50AM +0800, YunQiang Su wrote: For such a simple tool, do we really need such many versions? At least you've asked the question. I'd love to think that there was a proper evaluation of BSD which versus GNU which prior to the latter being uploaded to NEW, and there's a compelling reason that the GNU one was chosen; but if so there's no evidence of that on -devel. :( It seems to install to /usr/bin/which.gnu, implying that you could upload /usr/bin/which.bsd if you so desire; what's the issue?
Re: Epoch bump request for ksh
On Fri, Sep 10, 2021 at 10:04:08PM +0530, Anuradha Weeraman wrote: > 2) If you do go ahead with switching to the community distribution, then > "93u+m" is part of the name, not the version number, so I'd suggest: [...] Correction: rushed the last email, I meant to say that I agree that 93u+m is not part of the version per se. I just thought that it would be good to include, just for specificity. However, amending the proposed version as suggested since it makes sense: 1:1.0.0~beta.1-1 Hmm. If the project refers to itself as 93u+m does it make sense to package it as ksh instead of something like ksh93u+m? This reminds me of when debian first packaged openssh as "ssh" because that's what the predecessor package and the binary were called but in the long run renamed it to "openssh". (And with a new name the version/epoch question is moot.)
Re: Bug#992692: general: Use https for {deb,security}.debian.org by default
On Fri, Sep 10, 2021 at 08:02:42PM +0200, David Kalnischkies wrote: On Fri, Sep 10, 2021 at 11:08:38AM -0400, Michael Stone wrote: On Fri, Sep 10, 2021 at 04:33:42PM +0200, David Kalnischkies wrote: > On Thu, Sep 09, 2021 at 08:53:21AM -0400, Michael Stone wrote: > > The only thing I could see that would be a net gain would be to generalizes > > sources.list more. Instead of having a user select a specific protocol and > > path, allow the user to just select high-level objects. Make this a new > > pseudo-protocol for backward compatibility, and introduce something like > > deb apt:// suite component[s] > > so the default could be something like > > deb apt:// bullseye main > > deb apt:// bullseye/updates main > > then the actual protocols, servers, and paths could be managed by various > > plugins and overridden by configuration directives in apt.conf.d. For > > In this scheme the Debian bullseye main repo has the same 'URI' as the > Darts bullseye main repo. So, you would need to at least include an > additional unique identifier of the likes of Debian and Darts, but > who is to assign those URNs? > (Currently we are piggybacking on the domain name system for this) I have no idea what darts is, so I don't have an answer. :) "Darts" was just a play on "bullseye". It is not hard to imagine a repository which has the same suite and component(s) but is not Debian itself. As a pseudo-random [= its in an other topic here] real example you can take Wine (https://dl.winehq.org/wine-builds/debian/). So to what is "deb apt:// bullseye main" referring? Debian or Wine? And to pre-empt the most common response: As an apt dev I can assure you that we won't accept a solution involving "I am on Debian, so it means Debian" as that is impossible to correctly guess programmatically (for example on derivatives using a small overlay repo). I'd considered adding a scope to the model, e.g., apt://debian.org but removed it for simplicity. If that was a desired feature then there'd either have to be some sort of well-known path or such a distribution would need to provide a policy plugin for that scope. Alternatively, they could just use the existing http/https/whatever syntax in sources.list for their overlay if they didn't want to bother. Same for third party repos. > > their thing, and a plugin like auto-apt-proxy can override defaults to do > > something more complicated, using more policy-friendly .d configurations > > rather than figuring out a way to rewrite some other package's configuration > > file. > > JFTR: auto-apt-proxy has nothing to do with sources. It is true that > apt-cacher-ng (and perhaps others) have a mode of operation in which you > prefix the URI of your (in that case caching) proxy to the URI of the > actual repo, but that isn't how a proxy usually operates and/or is > configured. I have no idea what you're saying here. And I have no idea if you know what you are talking about. auto-apt-proxy already uses an interface apt provides to configure the proxy at runtime. It isn't in the business of modifying sources.list nor has it any interest in that. So you using it as an example for a plugin who could use your proposed scheme to modify the sources at runtime makes no sense. The concern I was responding to was that switching to https breaks the case of using auto-apt-proxy to cache the transaction. Just turning the proxy on and off isn't sufficient if the default sources.list uses https instead of http--you'd currently have to both turn the proxy on *and* change sources.list from http to https. Hence my musings on whether it's possible/desirable to separate the configuration of what to use as a transport from the configuration of what repository is desired. More generally, if we're talking about changing the default way that people interact with debian it just seems like a good time to ponder whether specifying sources the same way we did in 1998 makes sense given how many changes there have been to expectations about how we use internet resources. Maybe the answer is yes, and I'm not arguing that there has to be a change or that what I threw out as a possibility is the right answer, but it does seem worth considering.
Re: Bug#992692: general: Use https for {deb,security}.debian.org by default
On Fri, Sep 10, 2021 at 04:33:42PM +0200, David Kalnischkies wrote: On Thu, Sep 09, 2021 at 08:53:21AM -0400, Michael Stone wrote: The only thing I could see that would be a net gain would be to generalizes sources.list more. Instead of having a user select a specific protocol and path, allow the user to just select high-level objects. Make this a new pseudo-protocol for backward compatibility, and introduce something like deb apt:// suite component[s] so the default could be something like deb apt:// bullseye main deb apt:// bullseye/updates main then the actual protocols, servers, and paths could be managed by various plugins and overridden by configuration directives in apt.conf.d. For In this scheme the Debian bullseye main repo has the same 'URI' as the Darts bullseye main repo. So, you would need to at least include an additional unique identifier of the likes of Debian and Darts, but who is to assign those URNs? (Currently we are piggybacking on the domain name system for this) I have no idea what darts is, so I don't have an answer. :) Also, but just as an aside, whatever clever system you think of apt could be using, you still need a rather simple system for the likes of tools which come before apt like the installers/bootstrappers as they are not (all) using apt, especially not in the very early stages, and a mapping between them. I'm not sure why you think I need that? The goal of my musings is to separate the definition of what set of debian packages to use from the decision of how to get those packages *when using apt*, so that there are fewer things to consider in the common case, and to allow new capabilities in uncommon cases. If someone's using some other tool, why would anyone assume that the same configuration syntax would work? Just use the same configuration file you use now, and ignore all of this. If you want configurations to match across tools, then ignore all of this again and keep the same sources.list syntax you're already using that presumably does what you want. If someone wants to use tor by default but fall back to https if it's unreachable, they can do that. If someone wants to use a local proxy via http but https if they're not on their local network, they can do that. New installations could default to https, existing installations can keep doing You can do most of the fallback part with the mirror method backed by a local file. It is of no concern to apt how that file comes to be, so you could create it out of a massive amount of options or simply by hand. I do think if the creation is tool-based it shouldn't be apt as I envision far too many unique snowflakes for a one-size-fits-all approach. The intent would be to make it easier to plug other tools into apt, not to have the apt codebase do everything. their thing, and a plugin like auto-apt-proxy can override defaults to do something more complicated, using more policy-friendly .d configurations rather than figuring out a way to rewrite some other package's configuration file. JFTR: auto-apt-proxy has nothing to do with sources. It is true that apt-cacher-ng (and perhaps others) have a mode of operation in which you prefix the URI of your (in that case caching) proxy to the URI of the actual repo, but that isn't how a proxy usually operates and/or is configured. I have no idea what you're saying here.
Re: Bug#992692: general: Use https for {deb,security}.debian.org by default
On Fri, Sep 10, 2021 at 09:33:56AM +0200, Helmut Grohne wrote: Laptops of end-user systems are the target, but also developers. When people gather at a place (conference, hackspace, private meetup, etc.) downloading of .debs should just work quickly by default. Many such sites could easily provide a local cache and a number even do. BSPs tend to have a blackboard with information including the local mirror to use. Seriously, how many people change their mirror when they go to a BSP? If we installed auto-apt-proxy by default, much of the local caching would just work. I think you'd get a lot of pushback on installing auto-apt-proxy by default. If that's a proposal, make it seperately and not in this thread. The thing we seem to be disagreeing on is what is more important? https by default or quick and efficient downloads? Some may think that our CDN can handle the load just fine and the effects of caching are peanuts. I can attest that those peanuts are 4TB/year (equivalent to 8 days waiting for downloads) for me. I see that we've given up on a global network of independently-managed mirrors and that CDNs are way easier at this time. While initially CDNs had bad reliability issues, those have completely vanished in my experience. On the other hand, local caching still outperforms CDNs by a factor of 10 or so. I'd love to make it the default. I use a cache out of habit and to be a good netizen, but my internet connection is fast enough these days that it's basically a noop at best and a slight slowdown at worst. I had to move the cache from slow/cheap spinning disk to reasonably fast SSD to get to that point. If you're downloading the same stuff over and over (e.g., for testing or somesuch) it can be a big win, especially for VMs on a virtualized network connection, or if you're managing a large infrastructure, but for normal use with a couple of instances? It's just not worth the trouble.
Re: Bug#992692: general: Use https for {deb,security}.debian.org by default
On Fri, Sep 10, 2021 at 12:00:57PM +0200, Timo Röhling wrote: * Michael Stone [2021-09-08 19:25]: I think the issue isn't certificate validation, it's that https proxy requests are made via CONNECT rather than GET. You could theoretically rewrite the proxy mechanism to MITM the CONNECT, but that wouldn't be a drop-in replacement. I suppose you could instead add an apt option to pass the https request to the proxy via GET instead of using CONNECT, but I think that also won't necessarily work on an existing proxy. apt-cacher-ng has a second mode of operation where you can prefix the source URL with the proxy URL, i.e. deb http://proxyhost:3142/deb.debian.org/debian unstable main Maybe we could introduce this as an "official" APT proxy mode, where http(s)://REPO gets replaced by http://PROXY_URL/REPO (and the proxy can decide whether or not to fetch via HTTPS as an implementation detail)? I'd much rather see something more like I proposed earlier (splitting the selection of what suites/components to install from the policy of how to obtain them) rather than further layering+confusing these two concepts within sources.list.
Re: Bug#992692: general: Use https for {deb,security}.debian.org by default
On Thu, Sep 09, 2021 at 02:54:21PM +0200, Timo Röhling wrote: * Michael Stone [2021-09-09 08:32]: I'm honestly not sure who the target audience for auto-apt-proxy is--apparently someone who has an infrastructure including a proxy, possibly the ability to set dns records, etc., but can't change defaults at install time or via some sort of runtime configuration management? The same reason you might want to deploy WPAD instead of preconfiguring proxy settings in web browsers: flexibility. For example, we use auto-apt-proxy for laptops which roam between different networks. It's simple to configure, has virtually no maintenance overhead and degrades gracefully. None of that speaks to whether an organization that deploys such a thing has the ability to manage other configuration settings, even if for some settings there's a desire for additional flexibility. I don't understand your point. You asked for a target audience for auto-apt-proxy. I gave you a legitimate (and real-world) example for such a deployment. Why should it matter whether or not an organization has other configuration facilities? Because the controversy concerning changing the default is over whether it's reasonable for someone using auto-apt-proxy to have to manage additional configuration settings. If the target audience is someone who has the ability to manage the infrastructure required by auto-apt-proxy but not the ability to manage anything else then I guess it's a valid criticism (but I have trouble envisioning that). If the auto-apt-proxy target audience can manage both the proxy infrastructure *and* sources.list (either at install time or run time) then the criticism is basically academic and not generally a real-world issue.
Re: Bug#992692: general: Use https for {deb,security}.debian.org by default
On Thu, Sep 09, 2021 at 11:54:44AM +0530, Pirate Praveen wrote: Why can't auto-apt-proxy ask this as a debconf question? I also like auto-apt-proxy but I agree with this, someone needing auto-apt-proxy should be able to change the default as well. I don't really see why adding another debconf question would be better than just preseeding the existing one. The only thing I could see that would be a net gain would be to generalizes sources.list more. Instead of having a user select a specific protocol and path, allow the user to just select high-level objects. Make this a new pseudo-protocol for backward compatibility, and introduce something like deb apt:// suite component[s] so the default could be something like deb apt:// bullseye main deb apt:// bullseye/updates main then the actual protocols, servers, and paths could be managed by various plugins and overridden by configuration directives in apt.conf.d. For existing configurations it's a no-op but it allows more flexibility & new plugins/protocols in the future without having to micromanage sources.list. If someone wants to use tor by default but fall back to https if it's unreachable, they can do that. If someone wants to use a local proxy via http but https if they're not on their local network, they can do that. New installations could default to https, existing installations can keep doing their thing, and a plugin like auto-apt-proxy can override defaults to do something more complicated, using more policy-friendly .d configurations rather than figuring out a way to rewrite some other package's configuration file.
Re: Bug#992692: general: Use https for {deb,security}.debian.org by default
On Thu, Sep 09, 2021 at 08:36:28AM +0200, Timo Röhling wrote: * Michael Stone [2021-09-08 19:12]: Why not simply automate setting it at install time using preseed? I'm honestly not sure who the target audience for auto-apt-proxy is--apparently someone who has an infrastructure including a proxy, possibly the ability to set dns records, etc., but can't change defaults at install time or via some sort of runtime configuration management? The same reason you might want to deploy WPAD instead of preconfiguring proxy settings in web browsers: flexibility. For example, we use auto-apt-proxy for laptops which roam between different networks. It's simple to configure, has virtually no maintenance overhead and degrades gracefully. None of that speaks to whether an organization that deploys such a thing has the ability to manage other configuration settings, even if for some settings there's a desire for additional flexibility.
Re: Bug#992692: general: Use https for {deb,security}.debian.org by default
On Wed, Sep 08, 2021 at 03:56:14PM +0200, Ansgar wrote: On Wed, 2021-09-08 at 15:41 +0200, Helmut Grohne wrote: On Wed, Sep 08, 2021 at 02:01:03PM +0200, Ansgar wrote: > So what do you suggest then? Tech-ctte as with merged-/usr? Or a > GR? Or > something else? I propose that the proponents pay the cost. In this case, it is a bit unclear what that means precisely (which likely is the reason they haven't done it already). At the very least though, apt install auto-apt-proxy should continue to work on a default installation in a sensible way. I can file a bug for auto-apt-proxy to include an apt.conf snippet saying Acquire::https::Verify-Peer false; That clearly makes it work again I think the issue isn't certificate validation, it's that https proxy requests are made via CONNECT rather than GET. You could theoretically rewrite the proxy mechanism to MITM the CONNECT, but that wouldn't be a drop-in replacement. I suppose you could instead add an apt option to pass the https request to the proxy via GET instead of using CONNECT, but I think that also won't necessarily work on an existing proxy. If we're imagining apt options, something like Acquire::https::Force-Proxy-HTTP true; would probably be more useful for this specific case (not that I think it's a great idea--too much potential for surprise).
Re: Bug#992692: general: Use https for {deb,security}.debian.org by default
On Wed, Sep 08, 2021 at 01:09:13PM +0200, Helmut Grohne wrote: Enabling https by default quite simply breaks the simple recipe of installing auto-apt-proxy. Would you agree with auto-apt-proxy's postinst automatically editing your sources.list to drop the s out of https? The answer repeatedly given in this thread to do so manually is very unsatisfying. Why not simply automate setting it at install time using preseed? I'm honestly not sure who the target audience for auto-apt-proxy is--apparently someone who has an infrastructure including a proxy, possibly the ability to set dns records, etc., but can't change defaults at install time or via some sort of runtime configuration management?
Re: Realtek RTL8723DE, RTL8821CE, RTL8822BE and RTL8822CE chipsets
On Sat, Apr 03, 2021 at 08:03:23PM +0500, Andrey Rahmatullin wrote: On Sat, Apr 03, 2021 at 10:37:37AM -0400, Michael Stone wrote: > > > Not sure what hardware you are talking about but the majority of WiFI > > > hardware is supported by the mainline kernels, at least after you load > > > their firmware. > > > > I assume you haven't tried very much wifi hardware. Realistically, the state > > of wifi support is still terrible. The best thing to do is try to buy > > something known to be supported, but that's relatively difficult for most > > people because the name on the box generally has nothing to do with the > > chips inside the box. > Can you please list some unsupported chips in addition to these specific > Realtek ones? It would be easier for you to list ones that you've actually tested and know work. OK, whatever. It's a serious request. In 20 years of trying different wireless devices I've had just one that's completely reliable under linux (atheros qca6174 chipset) even if it's a little slow (only 2x2 mimo, and possibly hampered by the laptop's antenna configuration). It's older 802.11ac; I haven't ever seen a working 802.11ax. (Not saying it doesn't exist, just that I haven't seen it--hence the question!) I've seen lots of reports of reliable devices, but they tend to be things that are either ancient, or hard to find, or simply don't work as well for me as for others (apparently). I've personally used a lot of devices that mostly worked, until they hung or started going really slow or in some other way behaved much worse than the phone sitting next to the laptop (ironically running linux). I've heard good things about the intel adapters, but AFAIK they aren't available in USB so if someone didn't happen to get a laptop with that solution integrated it's not a simple end-user addition. IMO, wifi is the last major pain point to a fully functional linux sytem. Most other things these days you can just buy a something off the shelf at the local electronics store and odds are all the pieces will work out of the box. But wifi still requires a good bit of research, and isn't something a novice will find simple unless they get lucky on their components or bought something from a specialty retailer that focuses on linux systems.
Re: Realtek RTL8723DE, RTL8821CE, RTL8822BE and RTL8822CE chipsets
On Thu, Apr 01, 2021 at 11:52:46AM +0500, Andrey Rahmatullin wrote: On Wed, Mar 31, 2021 at 10:38:11PM -0400, Michael Stone wrote: On Tue, Mar 30, 2021 at 10:20:03PM +0500, Andrey Rahmatullin wrote: > Not sure what hardware you are talking about but the majority of WiFI > hardware is supported by the mainline kernels, at least after you load > their firmware. I assume you haven't tried very much wifi hardware. Realistically, the state of wifi support is still terrible. The best thing to do is try to buy something known to be supported, but that's relatively difficult for most people because the name on the box generally has nothing to do with the chips inside the box. Can you please list some unsupported chips in addition to these specific Realtek ones? It would be easier for you to list ones that you've actually tested and know work.
Re: Realtek RTL8723DE, RTL8821CE, RTL8822BE and RTL8822CE chipsets
On Tue, Mar 30, 2021 at 10:20:03PM +0500, Andrey Rahmatullin wrote: Not sure what hardware you are talking about but the majority of WiFI hardware is supported by the mainline kernels, at least after you load their firmware. I assume you haven't tried very much wifi hardware. Realistically, the state of wifi support is still terrible. The best thing to do is try to buy something known to be supported, but that's relatively difficult for most people because the name on the box generally has nothing to do with the chips inside the box.
Re: How should we handle greenbone-security-assistant?
On Fri, Dec 18, 2020 at 09:11:42AM +0100, Raphael Hertzog wrote: And at least anyone that is not installing the latest version can have an idea of whether it's important/urgent for them to upgrade or not. I think the software in question is a good example where there's basically no value in having an old version packaged. Who the heck wants to know if something has year old vulnerabilities but doesn't care about current vulnerabilities?
Re: Release status of i386 for Bullseye and long term support for 3 years?
On Wed, Dec 16, 2020 at 02:47:22PM -0500, Devops PK Carlisle LLC wrote: I understand your point about 32 bit being updated forever, and perhaps it does not need to be. Perhaps the happy medium would be to freeze it at some point, but leave it available as-is so that legacy software with 32 bit dependencies can still be installed and run. In other words, no longer developing for 32 bit does not mean that it cannot be found. Perhaps a different repository, with disclaimer(?) so that users can enable it if desired? http://archive.debian.org/ :)
Re: Release status of i386 for Bullseye and long term support for 3 years?
On Sun, Dec 13, 2020 at 11:40:29AM -0500, Devops PK Carlisle LLC wrote: Being philosophically opposed to throwing a good machine into a landfill, I tend to hang on to equipment for a long time. My play/experimentation and last-ditch backup box is a 10 year old laptop. I hear that, but at least around here it's literally possible to grab machines that are less than 10 years old that are on their way to the landfill. So scratch your itch by saving a machine less than 10 years old, then throw the really old one away instead. I'm unconvinced that running a stable of unneeded old machines is either great from a waste standpoint or something that should dictate the direction of the project. Debian isn't devoted specifically to supporting functionally obsolete hardware indefinitely, and when obsolete hardware makes it hard to move forward we need to just drop it. There are other projects which do strive to support old hardware indefinitely, and I highly recommend looking at one of those if hardware you want to use is no longer supported by debian. I personally run netbsd on some of my nostalgia hardware, but there are other options that may work better for you depending on what you're trying to do.
Re: What to do when DD considers policy to be optional? [kubernetes]
On Wed, Apr 08, 2020 at 10:36:17PM +0200, Thomas Goirand wrote: I don't agree with this *at all*. It is not in the interest of our users to be forced to update the software they use for their infrastructure every few months. Isn't that the user's decision, when they decided to adopt a tool that requires this deployment model? Or, if they're not clear about what adopting this tool means, I agree that isn't in their interest for them to see that there's a debian package and be fooled into thinking it doesn't require this deployment model just because there's a zombie package in debian stable which will be essentially unsupported and will completely cut them off from the tool's community. Putting it into debian provides zero benefit, and they could get the same "stability" guarantee by just keeping a copy of a two year old third party .deb and never updating it.
Re: Epoch version for google-authenticator
On Sun, Mar 01, 2020 at 01:06:13PM +0800, SZ Lin (林上智) wrote: Hi all, I'm working on fixing bugs (including RC) on google-authenticator[1] which name should be "google-authenticator-libpam" instead. [1] https://packages.debian.org/source/sid/google-authenticator [2] https://github.com/google/google-authenticator-libpam I intend to import the new upstream release, but the current upstream version changed the versioning scheme and thus epoch is needed to avoid the latest version lower than the previous one, as shown below. = Previous version: 20170702-2 Proposed version: 1:1.08-1 = Have you considered something like 20200301+1.08-1 ?
Re: Y2038 - best way forward in Debian?
On Fri, Mar 06, 2020 at 07:46:26AM +0100, Eduard Bloch wrote: So, wouldn't a restart of the i386 architecture under a different name give an excelent opportunity to get rid of many of such workarounds? In theory, sure...but I don't see that there's any actual demand for a new/clean i386 architecture in 2038.
Re: Y2038 - best way forward in Debian?
On Thu, Feb 13, 2020 at 04:08:22PM +0100, Andrej Shadura wrote:
On Thu, 13 Feb 2020, 10:40 YunQiang Su, wrote:
just redefine time_t to 64bit may also cause a problem:
a bad designed and old network protocol which aims only target 32bit
system,
a binary data packet, may contain time_t:
struct {
int a;
time_t b;
}
just define time_t to 64 will break this protocol, although it is bad
designed.
Currently, the major task of 32bit ports is to keep compatible with
old system/binary.
Should we really want to break them?
Aren't such things already broken on amd64?
If they're trying to talk, then yes. On-disk structures are probably
much more common than network protocols and not necessarily already
addressed. Even stuff like last(1) or who(1) would need changes if you
redefine the size of a time_t. And these aren't simple changes--files
which weren't intended to be portable don't generally store anything
about how big their time_t is, so you need heuristics to figure that out
and then make some tough decisions about how to proceed. (E.g., in the
case of wtmp you'd probably not want to just start writing larger
records halfway through a file, but you also have a very large number of
programs that can potentially write those records and upgrading them
simultaneously is impossible. A file with mixed record sizes is probably
not 100% recoverable.)
Re: Y2038 - best way forward in Debian?
On Thu, Feb 13, 2020 at 10:29:35AM +0100, Ansgar wrote: For arm* and mips*, we mostly seem to be talking about special-purpose systems where just switching to a new architecture/port doesn't seem to be that much as a problem as for i386. I think rebuilding the world and breaking ABI might thus be acceptable there. Historically those systems have had major issues with upgrades due to things like proprietary kernel patches that aren't available for newer releases. In practical terms, would trying to avoid a new architecture provide much benefit (especially in terms of the amount of work it would take)? I suspect that if you have a 25 year old embedded system in 2038, the availability of a 64 bit time interface in the C library of a general purpose linux distribution that's compiled for your CPU's instruction set is going to be the least of your maintenance problems. i386 seems different. i386 should just stay a relic. I don't see any use case for i386 in 2038 that doesn't involve trying to run a binary that can't be recompiled, and the only solution for that involves virtualization of the old ABI in a time-shifted environment.
Re: Debian With Alternate Init Systems
On Mon, Feb 10, 2020 at 06:27:55PM +0100, Svante Signell wrote: Not much space for other init systems than systemd within Debian. I was hoping for too much. Let's move on with our lives. I think we'd all appreciate if you would do that and stop sending messages about systemd!
Re: Y2038 - best way forward in Debian?
On Fri, Feb 07, 2020 at 02:46:19PM +0200, Wouter Verhelst wrote: On Fri, Feb 07, 2020 at 10:31:16AM +, Simon McVittie wrote: On Fri, 07 Feb 2020 at 09:28:24 +0200, Wouter Verhelst wrote: > Why not? This seems like the type of problem that SONAMEs are made for. > What am I missing? SONAMEs are set by the upstream developer in their build system Yes, I am aware of that, thank you. I meant to say that this feels like something upstream could do a SONAME bump for. I'm wondering why they chose not to. You'd have to bump the soname for almost every library on the system.
Re: Heads up: persistent journal has been enabled in systemd
On Thu, Feb 06, 2020 at 08:09:13PM +0100, Svante Signell wrote: On Thu, 2020-02-06 at 13:41 -0500, Michael Stone wrote: On Thu, Feb 06, 2020 at 07:22:07PM +0100, Svante Signell wrote: > On a Debian sytem _not_ running systemd: > > du -sh /var/log > 74M/var/log > > And the binary logs from systemd would of course be much smaller > since > they are binary. Any numbers? It looks like you just proved that this discussion doesn't matter for your use case. Can we stop this now? Of course it matters. It is about the _default_ setting, or have Iunderstood this thread wrongly? You seem to have misunderstood this thread wrongly in many ways. It's not clear what you hope to accomplish by continuing. If you just want everyone to know that you dislike systemd, congratulations: you've accomplished that. Now please move on. Numbers for systemd installations, please! No, you're wasting everyone's time with this irrelevant digression.
Re: Heads up: persistent journal has been enabled in systemd
On Thu, Feb 06, 2020 at 07:22:07PM +0100, Svante Signell wrote: On a Debian sytem _not_ running systemd: du -sh /var/log 74M /var/log And the binary logs from systemd would of course be much smaller since they are binary. Any numbers? It looks like you just proved that this discussion doesn't matter for your use case. Can we stop this now?
Re: Heads up: persistent journal has been enabled in systemd
On Thu, Feb 06, 2020 at 04:49:31PM +0100, Simon Richter wrote: I'd expect servers and embedded systems to be vastly underrepresented in both of these statistics, but that doesn't mean these use cases are in any way uninteresting to the project. Please stop beating the dead horse of whether debian is going to use systemd. FWIW, I find it even more useful on servers than on single-user machines and have it installed on orders of magnitude more servers than single-user machines. IOW, you're simply projecting your own prejudices and continuing to derail this thread into another pointless discussion about the merits of systemd.
Re: Heads up: persistent journal has been enabled in systemd
On Thu, Feb 06, 2020 at 09:50:36AM +1100, Dmitry Smirnov wrote: On Thursday, 6 February 2020 9:04:33 AM AEDT Michael Stone wrote: Nobody said "exclusively" except you! It was suggested that default will change and I'm concerned about that. And yet you said "exclusively" and generally argued in a confrontational manner that seems unwilling to accept a minor change because you just don't want to consider use cases other than your own habits. Either option has benefits and disadvantages, but for some reason you're arguing as though 1) only your particular use cases matter Nonsense. It is not "my case" but established default that remained stable for as long as I can remember. That would be for about a decade. Well, my memory goes back more than twice as long and I remember it changing before. I remember not being particularly happy with rsyslog when it became the default, but it didn't really matter that much so it didn't particularly bother me either. rsyslog was (and is) one of *several* alternatives, and has advantages and disadvantages compared to each of them. and 2) continuing to use rsyslog isn't an option if the default changes. No. I just don't want default to change. Nothing is worse for the debian project than for every single suggestion that something change be met with opposition that boils down to opposition to change. Things have changed before, they will change again, and honestly the impact of most of those changes is very small (for either better or worse) and certainly they are not things that should be met with the level of emotional response that they are. If anything has changed for the worse in the project it's this sense we aren't allowed to change things anymore.
Re: Heads up: persistent journal has been enabled in systemd
On Thu, Feb 06, 2020 at 08:40:29AM +1100, Dmitry Smirnov wrote: On Thursday, 6 February 2020 6:59:38 AM AEDT Nikolaus Rath wrote: I would venture that for every user who is grateful that /var/log/mail.log collects all the various mail-related logs, there is another user that curses about non being able to separate (out of the box) the logs from all the programs that consider themselves mail-related, and another user who struggles to remember in which logfile $DIFFICULT_TO_CLASSIFY_PROGRAM might be writing its logs. There are log readers like "lnav" and "multitail" that will become useless without traditional log files. "lnav" tails multiple logs by default and IMHO provides a very useful interface. Exclusively relying on systemd logging facilities limits ways in which we can analyse logs. Nobody said "exclusively" except you! Either option has benefits and disadvantages, but for some reason you're arguing as though 1) only your particular use cases matter and 2) continuing to use rsyslog isn't an option if the default changes.
Re: Heads up: persistent journal has been enabled in systemd
On Wed, Feb 05, 2020 at 01:32:41PM +, Scott Kitterman wrote: My impression so far is that the journalctl interface is a regression from what we have now in every way I care about. Great! Good thing you can just keep using rsyslogd.
Re: Y2038 - best way forward in Debian?
On Tue, Feb 04, 2020 at 03:17:50PM +0100, Ansgar wrote: At least for i386, I expect it to be used mostly for legacy applications (and legacy installations). So breaking ABI by switching to a "new" architecture or by just changing major libraries like libc6 probably diminishes its value so much that there would no longer be any use for it: one could just switch to amd64 instead of i386t. Yes, for x86 in particular I don't see any reason to try to rebuild x86-2038 vs x32 for whatever niche might be filled by a 32 bit ILP.
Re: Heads up: persistent journal has been enabled in systemd
On Sun, Feb 02, 2020 at 02:35:19PM +, Anthony DeRobertis wrote: On February 2, 2020 12:02:33 PM UTC, Simon khng wrote: Why was rsyslog used as the persistent storage instead of journald for previous Debian distribution? rsyslog has been the default Debian log storage since before switching to systemd, possibly since before systemd existed (it was syslogd, but would have to check if it was rsyslog or some other implementation). Way back at the beginning there was syslogd, that got combined early on with klogd into the sysklogd package, rsyslogd replaced it on default installs in lenny (released 2009). So yes, the reason is that it predates systemd. :)
Re: migration from cron.daily to systemd timers
On Wed, Jan 08, 2020 at 07:12:17PM -0800, Russ Allbery wrote: Michael Stone writes: On Thu, Jan 09, 2020 at 02:09:12AM +, Paul Wise wrote: This is the main reason I haven't switched to systemd timers for my personal crontab, I have some jobs that generate output (diffs of various things mostly) but don't fail. There doesn't appear to be any tool to monitor a tool and send a mail if it generates output or fails, in the way that cron does. mail -E ? Specifically: ExecStart=/bin/sh -c '/path/to/job | /usr/bin/mail -E' in the service unit triggered by the timer unit should work, I think. (I've not tested it.) May need something like (job || echo Job failed) 2>&1 | mail -E or even (job 2>&1 || echo Job failed) | tee /dev/stderr | mail -E depending on the specific requirements, but in general this should be pretty straightforward
Re: migration from cron.daily to systemd timers
On Thu, Jan 09, 2020 at 02:09:12AM +, Paul Wise wrote: This is the main reason I haven't switched to systemd timers for my personal crontab, I have some jobs that generate output (diffs of various things mostly) but don't fail. There doesn't appear to be any tool to monitor a tool and send a mail if it generates output or fails, in the way that cron does. mail -E ?
Re: migration from cron.daily to systemd timers
On Wed, Jan 08, 2020 at 10:36:02AM -0800, Russ Allbery wrote: Could you be specific about what you prefer about a cron job over a systemd timer unit? If it's just that you are familiar with cron jobs and not systemd timer units, I'm sympathetic but I don't think that's a very strong argument for the additional complexity you're asking for. Other software in Debian is already using systemd timer units, so you're likely to have to become familiar with them at some point regardless. But if there is some other concrete use case, I'd love to talk about it in specific detail rather than just in generalities. As a third party with no particular ax to grind on this, I do wonder what the advantage is to adding another mechanism for this particular use case, given the need to somehow handle upgrades involving an existing (presumably working?) solution.
Re: migration from cron.daily to systemd timers
On Wed, Jan 08, 2020 at 05:15:36PM +0100, Daniel Leidert wrote: It seems I misread this part at first. So maybe you should slow down on the emails?
Re: TZ=UTC wrong?
On Wed, Oct 30, 2019 at 05:01:56PM +0100, Guillem Jover wrote: This indeed works in Debian, but I think it's strictly speaking incorrect according to POSIX, and as such is non-portable. It's non portable in a way which hasn't been relevant in more than 20 years and as such isn't worth wasting time over. The POSIX TZ spec is irrelevant to real systems except insofar as it can be used to explain unexpected behavior when people make a typo.
Re: Bypassing the 2/3/4GB virtual memory space on 32-bit ports
On Tue, Aug 20, 2019 at 04:21:43PM +0100, Luke Kenneth Casson Leighton wrote: that 32-bit hardware is consigned to landfill. debian has a far higher impact (as a leader, due to the number of ports) than i think anyone realises. if debian says "we're dropping 32 bit hardware", that's it, it's done. That's their decision, but I think the correct answer is that 32 bit hardware is rapidly moving to a place where it's not applicable to a general purpose operating system. From your long list of hardware, there's not much that I'd want to run firefox on, for example. So, if your hardware isn't right for a general purpose OS...run a specialized OS. netbsd still has a vax port... to give you some idea of how influential debian really is: one of *the* most iconic processors that AMD, bless 'em, tried desperately for about a decade to End-of-Life, was the AMD Geode LX800. the reason why it wouldn't die is because up until around 2013, *debian still supported it* out-of-the-box. IMO, debian wasn't what kept geode going. Long term contracts involving embedded devices (which don't usually run debian) are more influential then the state of OS support. In fact, the geode EoL has been pushed back to 2021, regardless of the lack of debian support. Considering how many of these embedded boards are still running windows XP, having an up to date general purpose OS simply doesn't seem to be a major factor.
Re: Making mailcap optional ?
On Thu, Aug 15, 2019 at 08:29:45AM +0900, Charles Plessy wrote: Please let me know your thoughts (perhaps after waiting a day or two to let your thoughts mature). I don't really see a benefit to this. A system capable of running a "modern desktop environment" isn't going to notice the "overhead" of mailcap.
Re: Please stop hating on sysvinit (was Re: do packages depend on lexical order or {daily,weekly,monthly} cron jobs?)
On Thu, Aug 08, 2019 at 01:08:41PM -0700, Russ Allbery wrote: Simon Richter writes: In the same way, we could have had automatic restart of services through sysvinit easily: an include mechanism that allows additional inittab lines to be pulled from /etc/inittab.d/* would be trivial to implement. That it hasn't been done is not because no one has thought about it in the last thirty years, but because its use is rather limited. Er, well... speaking as someone who tried to keep daemons running via inittab and then gave up and tried using monit for a while, and then switched to djb daemontools (all back before systemd existed), I'm not sure this is quite right. Those who tried to use this facility quickly discovered that sysvinit was rather bad at it, and therefore started using something else. Yup. Regardless of those who keep insisting that systemd doesn't add anything to a server environment, people happily using it for servers disagree. I assume those who insist that sysvinit did everything right simply either forget the problems it had or just accepted its limitations. Note that this is not a statement about Linux sysvinit specifically -- my experiences were originally on Solaris. The flaws in using inittab to keep services running were universal among UNIX implementations. And until we got rid of legacy limitations, there was no way forward because everything was met with "but this is how its always worked and you'll never manage to change things on those other systems".
Re: Generating new IDs for cloning
On Thu, Aug 08, 2019 at 06:16:31PM +0200, Marc Haber wrote: On Thu, 8 Aug 2019 11:50:07 -0400, Michael Stone wrote: On Thu, Aug 08, 2019 at 11:41:52AM -0400, Marvin Renich wrote: * Michael Stone [190808 08:42]: On Thu, Aug 08, 2019 at 08:37:16AM -0400, Marvin Renich wrote: > Does anyone know what applications use this file for what purpose? Is > this a systemd-ism? man machine-id The man page says what it is (a unique, random ID for the machine) and how to initialize it, but says nothing about why it exists. What applications expect it to be there? From the man page: The machine ID does not change based on local or network configuration or when hardware is replaced. Due to this and its greater length, it is a more useful replacement for the gethostid(3) call that POSIX specifies. [...] When a machine is booted with systemd(1) the ID of the machine will be established. If systemd.machine_id= or --machine-id= options (see first section) are specified, this value will be used. Otherwise, the value in /etc/machine-id will be used. If this file is empty or missing, systemd will attempt to use the D-Bus machine ID from /var/lib/dbus/machine-id, the value of the kernel command line option container_uuid, the KVM DMI product_uuid (on KVM systems), and finally a randomly generated UUID. What Marvin says: That doesn't explain anything. I guess I need you to say what's confusing. It's an ID that doesn't change. You can look up gethostid to get a little more background. If you need an ID for a host it's useful. If you don't need an ID for a host, then it's not so useful. Once upon a time (gethostid(3) alludes to this) it was thought that an IPv4 would be a good unique ID, but with the rise of NAT it quickly became useless and hence the search for an alternative. The second paragraph is pretty clear that machine-id is one of a number of possible seeds for systemd to set the machine's ID. The rest of the file talks about how applications can use an API to get a constant ID based on the machine ID and that applications should generally not use the contents of the machine-id file directly. So to find out what applications use the file you'd have to look for references to the various APIs (such as sd_id128_get_machine_app_specific or dbus-uuidgen) which themselves use /etc/machine-id
Re: Generating new IDs for cloning
On Thu, Aug 08, 2019 at 11:41:52AM -0400, Marvin Renich wrote: * Michael Stone [190808 08:42]: On Thu, Aug 08, 2019 at 08:37:16AM -0400, Marvin Renich wrote: > Does anyone know what applications use this file for what purpose? Is > this a systemd-ism? man machine-id The man page says what it is (a unique, random ID for the machine) and how to initialize it, but says nothing about why it exists. What applications expect it to be there? From the man page: The machine ID does not change based on local or network configuration or when hardware is replaced. Due to this and its greater length, it is a more useful replacement for the gethostid(3) call that POSIX specifies. [...] When a machine is booted with systemd(1) the ID of the machine will be established. If systemd.machine_id= or --machine-id= options (see first section) are specified, this value will be used. Otherwise, the value in /etc/machine-id will be used. If this file is empty or missing, systemd will attempt to use the D-Bus machine ID from /var/lib/dbus/machine-id, the value of the kernel command line option container_uuid, the KVM DMI product_uuid (on KVM systems), and finally a randomly generated UUID.
Re: Generating new IDs for cloning
On Thu, Aug 08, 2019 at 08:37:16AM -0400, Marvin Renich wrote: Does anyone know what applications use this file for what purpose? Is this a systemd-ism? man machine-id
Re: duplicate popularity-contest ID
On Wed, Aug 07, 2019 at 04:02:14PM +0100, Ian Jackson wrote:
Michael Stone writes ("Re: duplicate popularity-contest ID"):
I guess the question is what is the point of the popcon statistics.
Insofar as they're used to determine defaults, skewing them toward
custom images (which likely do not care about defaults) is probably a
mistake.
popcon is a really bad way to determine defaults because it is so
heavily skewed by existing defaults.
More useful uses of popcon include: estimating the downside, if some
package is (or may become) broken or removed; and, maybe, estimating
the user preferences between different non-default leaf packages.
For me, if I were doing (say) RC bugfixing and was considering asking
for a removal, even a moderate popcon figure would give me pause.
Conversely, a low popcon figure would encourage me to consult on
removing the package.
I don't think popcon is a good reason to pause if there are valid
concerns suggesting removal is a good thing, for the exact reason that
it's skewed to propagating existing practice. I'm not sure there's any
really good use for popcon, but I'll continue to believe that any value
it does have is more related to how many unique configurations it
reflects rather than how many duplicate instances it can hold.
Re: duplicate popularity-contest ID
On Wed, Aug 07, 2019 at 09:31:34AM +0200, Marc Haber wrote: On Tue, 6 Aug 2019 11:33:42 +, Bill Allombert wrote: Yesterday I received the same popcon ID 2600 times, and 4700 differents ID were received two times and 22000 ID were received exactly once. I understand the need for totally identical systems, but then probably it does not make sense for them to report to popcon. Why? Does a node in a cluster count less than a desktop installation? If so, why do we not value the input of our biggest users while putting so much focus on installations in a market segment that we're losing anyway? I guess the question is what is the point of the popcon statistics. Insofar as they're used to determine defaults, skewing them toward custom images (which likely do not care about defaults) is probably a mistake.
Accepted argus-clients 1:3.0.8.2-5 (source amd64) into unstable
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Format: 1.8 Date: Tue, 06 Aug 2019 11:18:50 -0400 Source: argus-clients Binary: argus-client argus-client-dbgsym Architecture: source amd64 Version: 1:3.0.8.2-5 Distribution: unstable Urgency: low Maintainer: Michael Stone Changed-By: Michael Stone Description: argus-client - IP network transaction auditing tool Changes: argus-clients (1:3.0.8.2-5) unstable; urgency=low . * update debhelper dependencies Checksums-Sha1: 0ada104af2916b3d06bf76405d29e99a86a5871d 1921 argus-clients_3.0.8.2-5.dsc 03aa066585bff865edb2b9659230fd20633d299a 22964 argus-clients_3.0.8.2-5.debian.tar.xz 783da1c5e6e72d64711a2a094a1420eefca51cdc 26949400 argus-client-dbgsym_3.0.8.2-5_amd64.deb 0afed548c4b9c7ef592fd85003f6f73606503b8d 3420908 argus-client_3.0.8.2-5_amd64.deb c268695e66dfdf244977abb849a9228372c31d9f 7619 argus-clients_3.0.8.2-5_amd64.buildinfo Checksums-Sha256: d7c7a1901f1b22b6bb51b0ba398b93da939fce4da86344cce6868856b26c9274 1921 argus-clients_3.0.8.2-5.dsc fddb17a98246e68b611bb917405451fe20675861f1499935b98f535f79981b08 22964 argus-clients_3.0.8.2-5.debian.tar.xz 4c2b98b56e884ea1facff941b1f9b7b42740500df434615e133c39d7ba2bbc07 26949400 argus-client-dbgsym_3.0.8.2-5_amd64.deb 4324cda66a0e9334de3a06cb5ac7cf2fedd10f126fd307c6e0d9c5d6468637e4 3420908 argus-client_3.0.8.2-5_amd64.deb eac0a58640e82b6b628c2b9244ba1cc36caa68952631e562cbbb676880e23c5a 7619 argus-clients_3.0.8.2-5_amd64.buildinfo Files: aaf2f53f1c897198447d1657a0c5bd52 1921 utils optional argus-clients_3.0.8.2-5.dsc d9b567b1d859bda61bbed418d514bf42 22964 utils optional argus-clients_3.0.8.2-5.debian.tar.xz bd324b84aab21ec45d30c8e37d8507c0 26949400 debug optional argus-client-dbgsym_3.0.8.2-5_amd64.deb 1cb4516fdf4d3410322ceb55b20f9325 3420908 utils optional argus-client_3.0.8.2-5_amd64.deb cedbff36a276e505ab9fe8f6f054 7619 utils optional argus-clients_3.0.8.2-5_amd64.buildinfo -BEGIN PGP SIGNATURE- iQIzBAEBCgAdFiEEAtUxX/EfDh4C9hqs3PoR/94FAl1JmsIACgkQ9hqs3PoR /97G0w/+NsonDO52ZwatipvOx5OxErVLdKW+DQ2n2s4GJZt8YXTEwu5f5chlvsSe JcLKtkg3HtFd9I5UIq3OSSnsG+VOadTubUahKCDXv2wxnI51VslQkosj19GdY91t BajOLquIZC+Mi+/EsXTdtAC2RjM+BlPCi4VQCkKW5IeL1zslyRgM44BRyG0TA0Lo UAgtXF4zvgcjKIPtJ+5STXIC9yCr41dbxBRntOpdfl9GrRm2/2iHXWXZyBheXyNE JehpnEWPzbAqFySaqakmP4xvgiko23cwZ7U9JJj2snmYu0XikeuXt5/BUEOwbBgW L9THU1YP/qhUhFCiERRIHeusgwFSZnphflYI8jnZU9Ejzr7bOE3thmW96h2IUyxw 9oT1zNPBxWd4Ob1v7cm0xNh6eh/uwybUBlr3QVLem8GbeWZTy55jXeTRe5U9QtUn D1nEp9iQZlPMj3c6XlWhnXVndZ1Yi05ZdQnOK0knKyiIYJZ9gua2NdSDElYGdJyb /vuHwGlZTRqwzY7+xketcEv4ooYJxmImsYMHMU9PHRjav9dp92Tu+WaUv0j3zYiy GOo1l1y2YD2tvPCJ43zmZz0M9bhq2iVKPt9jSZAqPmO0SbKi8NCSWPB5AGG/L37z gz7YfldI2HtynTtcvAMbQrsrz0vtJrO1wyOzOO5QoRzDs3bTEKY= =sW0k -END PGP SIGNATURE-
Accepted argus-clients 1:3.0.8.2-4 (source amd64) into unstable
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Format: 1.8 Date: Tue, 06 Aug 2019 10:33:16 -0400 Source: argus-clients Binary: argus-client argus-client-dbgsym Architecture: source amd64 Version: 1:3.0.8.2-4 Distribution: unstable Urgency: low Maintainer: Michael Stone Changed-By: Michael Stone Description: argus-client - IP network transaction auditing tool Closes: 932984 933029 Changes: argus-clients (1:3.0.8.2-4) unstable; urgency=low . * updated debhelper systemd boilerplate (Closes: #933029) * fix hardcoded path to rabins (Closes: #932984) * Update standards-version to 4.4.0 Checksums-Sha1: 6b5ff70290139aafaff0709a3eeb75554748d691 1941 argus-clients_3.0.8.2-4.dsc 808df65ab7c90ea74a8215fcd77d6b8d46ccb4e2 22956 argus-clients_3.0.8.2-4.debian.tar.xz 3d6ebee3414db0e76e07a2f7c1251ce6595ff7c6 26949660 argus-client-dbgsym_3.0.8.2-4_amd64.deb 31056cf10770e56ff7d52dcefa9b04235838fb91 3422644 argus-client_3.0.8.2-4_amd64.deb 578c381e5e5075313ba594592164f7b9f5108c41 7643 argus-clients_3.0.8.2-4_amd64.buildinfo Checksums-Sha256: 6dbb65d21fd00d9fc2dc091f818c19af70eb9e53593088fbad1c8b1eac6f2032 1941 argus-clients_3.0.8.2-4.dsc 9dc07a78ec46078702f8dcd7a65edff4731fec54bb64e61dd6c4473f6f47105f 22956 argus-clients_3.0.8.2-4.debian.tar.xz 0c8060f54c5cf20646595f5444e9e2b618f4417e2100576d4d21caead1655e8c 26949660 argus-client-dbgsym_3.0.8.2-4_amd64.deb 967cce3870ea4380de0e2cba67e212d2d5cbafc46c8bd9c976474f65112d511b 3422644 argus-client_3.0.8.2-4_amd64.deb c25c5296dc006855ffd64e4b1f5c272c007830a035256fc1bf41278f15da7502 7643 argus-clients_3.0.8.2-4_amd64.buildinfo Files: 8d1253ce8a2dc23971d5789426699c4f 1941 utils optional argus-clients_3.0.8.2-4.dsc 9ba07da9b6a4bee3618b2847258b2449 22956 utils optional argus-clients_3.0.8.2-4.debian.tar.xz 6d4a9b6ffc9310856c74ed4b27abaa93 26949660 debug optional argus-client-dbgsym_3.0.8.2-4_amd64.deb 62c1b12f11734679d9b669d70313c7e4 3422644 utils optional argus-client_3.0.8.2-4_amd64.deb fafd048d3c4622093acc66f6715a3b28 7643 utils optional argus-clients_3.0.8.2-4_amd64.buildinfo -BEGIN PGP SIGNATURE- iQIzBAEBCgAdFiEEAtUxX/EfDh4C9hqs3PoR/94FAl1JlsAACgkQ9hqs3PoR /97IRQ//cn0kRKq67Pof9SIWQut95nhWB1XrCwzQcPQ16x3ds2c27QqtcSZNTghI DHfS2SJY+l+KIlZrYxPicOP9f7SyG5i3UKZ1if0+ffTZAshbLkXNvDp8fEmEqlis q2+od4apFpWu2flfyjO1W486cgtD9YEgm5IOGHYJqXrAlJk/PslejQIgmmFz5Kj0 /ViuL+a2o+dSCPK74An+zV8NTfbJl8S+GyUbLBuk59dd6Qev22NIkIKVnsnLxSkE hh+AeuiBuv98k2/RqEe34CqJ7mKTqI5y+fZySbmeHjOE9SZ4Or+E6OyqNFxPK+cD Gv0vzc9TAmbT/He2oYJA5HC5ITwEAt+Zbc27PQLPHjznyFQiY0LucYF9QVI9Rb4A 5JOCxLzGeZb6etpZBvavuPBUWtr4NPrgY/L1sA63lhs/hddGoizhCxFETJlftt5P QAgZFA2Mr0DFiVZTkFWNAWj+2rEXqTwhAPFUQfRduijx2mJakEKe932DgNxq45gI OP5FCJ5BQhDEWbqnH/WZFJpd69clS6uBjnhKVFiKrIK5/ULY+DLc2mk/n9Q8dqul ur0orVZ2CjDnscHpOkcjeqqCa5ImB7HrHUG4+IIt4Tb70RXJN3lWwMDkksvp5Y9r vZNLCB5wty2TU0A0UcoixNucICustfFtpCFxa6V2lnwCtWPngmQ= =rFEX -END PGP SIGNATURE-
Re: getting rid of "testing"
On Wed, Jun 26, 2019 at 02:23:40PM -0500, Andrej Shadura wrote: On Wed, 26 Jun 2019 at 14:13, Michael Stone wrote: On Wed, Jun 26, 2019 at 03:10:27PM +0200, Philip Hands wrote: >I'm perfectly capable of typing slink when I meant stretch. The coming >era of b* releases is going to be a right pain for me. FWIW, I still confuse bo and buzz. :) How about buzz and buzzter? :) They're all terrible. I routinely say squeeze when I mean stretch, and then when I log in somewhere and see stretch I wonder why it's running such an old release. :(
Re: getting rid of "testing"
On Wed, Jun 26, 2019 at 03:10:27PM +0200, Philip Hands wrote: I'm perfectly capable of typing slink when I meant stretch. The coming era of b* releases is going to be a right pain for me. FWIW, I still confuse bo and buzz. :)
Re: getting rid of "testing"
On Wed, Jun 26, 2019 at 01:29:44PM -0300, Antonio Terceiro wrote: As a data point, having "stable" and "testing" stay around is very useful for CI purposes. For example on ci.debian.net all our setup uses "stable" and "testing" instead of the release codenames, and it's useful to have a system that does not need manual intervention when the meaning of "stable" and "testing" changes. Ideally, a mapping of what is currently "stable" or "testing" or at other levels of support would be easy to determine programatically, so you could avoid manual intervention for those cases and make it easy to support other cases without having to either manually configure things *or* make a bunch of new ugly symlinks.
Re: getting rid of "testing"
On Wed, Jun 26, 2019 at 04:13:00PM +0100, Ian Jackson wrote:
Andreas Tille writes ("Re: getting rid of "testing""):
I never really understood why we need these codenames.
Simon McVittie wrote:
| Back when the release team decided on a per-release basis whether
| this was a "major" or "minor" release, we had the excuse that we had
| to use a codename for testing because we didn't know whether etch
| would be released as Debian 3.2 or Debian 4.0
I was around at the time and I have a vague recollection which roughly
matches Simon's.
Not just that: after the faux-release debacle there was a push to avoid
numbers in case someone polluted one. We're much less dependent on CD
vendors these days, of course.
Re: getting rid of "testing"
On Wed, Jun 26, 2019 at 09:01:03AM +0800, Paul Wise wrote: I also should mention that I use all of stable stable-updates proposed-updates and the equivalents for old/oldold. I have them in the apt sources of a chdist so I can easily look up old versions, do apt-file searches on old versions, look up non-amd64 architecture info etc. Wouldn't it be nicer to have a reliable and simple source of version ordering rather than relying on ugly names and symlinks? As a bonus, it would be useful for a lot more things and for more than n-2 calculations.
Re: getting rid of "testing"
On Tue, Jun 25, 2019 at 09:43:02PM +0500, Andrey Rahmatullin wrote: On Tue, Jun 25, 2019 at 12:40:01PM -0400, Michael Stone wrote: > and so on - i take the older releases only as reference. I just do something like look at https://packages.debian.org/ssh Or, if I'm really curious about versions, then something like http://snapshot.debian.org/package/openssh/ rmadison(1) and https://tracker.debian.org/ are probably better. Those are also good options for additional use cases. :) At any rate, putting every release ever into sources.list is generally not the best available mechanism.
Re: getting rid of "testing"
On Tue, Jun 25, 2019 at 06:28:13PM +0200, Alf Gaida wrote: On 25.06.19 17:48, Michael Stone wrote: oldoldstable has the value of demonstrating some of what's wrong with the current system Can you please explain, i don't get it - maybe i to new at this. For me file like /etc/apt/sources.lists.d/debian.list: wow, that slows down every package operation on the system as you download or search 6+ versions of everything. and so on - i take the older releases only as reference. I just do something like look at https://packages.debian.org/ssh Or, if I'm really curious about versions, then something like http://snapshot.debian.org/package/openssh/ If you've got some kind of weird requirement to have everything local, I'd still rather see something like "debian8" in the output than "oldoldstable"--a name that changes over time and is therefore relative to both a reference system and a specific system at the time that entry was created. If I want a specific version of a package, it will only be in "oldoldstable" up until "oldoldstable" is something entirely different. I'm still not understanding a use case where that's an advantage.
Re: getting rid of "testing"
On Tue, Jun 25, 2019 at 06:06:55PM +0200, Benjamin Drung wrote: Am Dienstag, den 25.06.2019, 11:48 -0400 schrieb Michael Stone: On Tue, Jun 25, 2019 at 05:01:48PM +0200, Alf Gaida wrote: > Only a few remarks as former simple user and now maintainer: > * Please don't mix things: release names has a value, distribution > names like oldoldstable, oldstable, stable, testing, unstable has > their value too oldoldstable has the value of demonstrating some of what's wrong with the current system Then running wheezy will be fine once buster is released, because oldoldstable will point to jessie and wheezy won't have a release name any more? Some admins ask: "How many reboots until the next Debian release?" Others ask: "How many Debian releases until the next reboot?" I can images systems that are getting bought, setup, and after several years shutdown and retired without rebooting or dist-upgrading them. I have no idea what you're trying to say, sorry.
Re: getting rid of "testing"
On Tue, Jun 25, 2019 at 05:01:48PM +0200, Alf Gaida wrote: Only a few remarks as former simple user and now maintainer: * Please don't mix things: release names has a value, distribution names like oldoldstable, oldstable, stable, testing, unstable has their value too oldoldstable has the value of demonstrating some of what's wrong with the current system
Re: getting rid of "testing"
On Tue, Jun 25, 2019 at 02:38:43PM +0200, Bastian Blank wrote: On Tue, Jun 25, 2019 at 08:03:49AM -0400, Michael Stone wrote: Having "stable" in sources.list is broken, because one day stuff goes from working to not working, which requires manual intervention, at which point someone could have just changed the name. Once I had unattended-upgrades do the upgrade to the new stable for me over night on quite a few systems, almost everything still worked. "almost" covers quite a lot of territory, and is the reason it's best not to have the upgrade happen accidentally.
Re: getting rid of "testing"
On Tue, Jun 25, 2019 at 08:07:51PM +0800, Paul Wise wrote: On Tue, Jun 25, 2019 at 8:04 PM Michael Stone wrote: Having "stable" in sources.list is broken, because one day stuff goes from working to not working, which requires manual intervention, at which point someone could have just changed the name. Having codenames in sources.list is broken, because even people who have been developers for two decades can't remember which release is which without looking it up. (Which is harder than it should be; maybe we should have had /etc/debian-releasenames or somesuch from the beginning. lsb_release -a is helpful when available but doesn't have context, and many users don't know it exists.) Personally, I can remember the names and their order much better than which version goes with which codename or suite :) Well, every problem domain has its rainman :) For the rest of us, there's google.
Re: getting rid of "testing"
On Tue, Jun 25, 2019 at 11:09:06AM +0100, Ian Jackson wrote:
~Ansgar writes ("getting rid of "testing""):
Related to that I would like to be able to write something like
deb http://deb.debian.org/debian debian11 main
deb http://security.debian.org/debian-security debian11-security main
in sources.list as codenames confuse people.
Yes, please, absolutely. And this should be the default.
+1
Having "stable" in sources.list is broken, because one day stuff goes
from working to not working, which requires manual intervention, at
which point someone could have just changed the name. Having codenames
in sources.list is broken, because even people who have been developers
for two decades can't remember which release is which without looking it
up. (Which is harder than it should be; maybe we should have had
/etc/debian-releasenames or somesuch from the beginning. lsb_release -a
is helpful when available but doesn't have context, and many users don't
know it exists.)
Re: .deb format: let's use 0.939, zstd, drop bzip2
On Fri, May 10, 2019 at 05:42:45PM +0200, Marc Haber wrote: On Fri, 10 May 2019 07:42:52 -0400, Michael Stone wrote: This is really not a property worth preserving. I disagree. I frequently unpack .debs on .rpm Systems, especially when I want to see how the rather nice behavior that I find in Debian is implemented to see whether I can implant that hotness into the .rpm world. And there are easily installed tools which I have every confidence will be updated to work with any new format so your ability to do so won't be diminished in the least. Just like I can unpack rpms on a deb system.
Re: .deb format: let's use 0.939, zstd, drop bzip2
On Fri, May 10, 2019 at 05:18:18AM +0200, Guillem Jover wrote: be updated anyway to support any new format. It also destroys some of the nice properties of the 2.x format, namely: - Not requiring special tools to build/extract. This is really not a property worth preserving. I think it would be fairly easy to get significant performance improvements if we dropped the archive nesting, and all it would cost is losing a bullet point that nobody really cares about all that much. I remember when this was one of the "reasons" to advocate .deb over .rpm but in the real world people just apt install rpm and the anecdotes about this one time somebody wanted to unpack a deb on an ancient sunos box aren't worth slowing down every install until the end of time.
Re: .deb format: let's use 0.939, zstd, drop bzip2
On Thu, May 09, 2019 at 07:37:55AM +0800, Paul Wise wrote: On Thu, May 9, 2019 at 1:38 AM Adam Borowski wrote: Thus, even though we'd want to stick with xz for the official archive, speed gains from zstd are so massive that it's tempting to add support for it, at least for non-official uses, possibly also for common Build-Depends. Could we use custom zstd dictionaries on a per-architecture basis to further reduce the size of zstd packages, possibly allowing it to beat xz? In theory, sure. Have any test results? My gut tells me that wouldn't buy much but numbers matter more.
Re: Please drop anacron from task-desktop
On Sat, Mar 09, 2019 at 12:02:05AM +0200, Adrian Bunk wrote: On Fri, Mar 08, 2019 at 02:38:07PM -0500, Michael Stone wrote: On Fri, Mar 08, 2019 at 08:01:35PM +0100, Christian Kastner wrote: > I intended to post a transition proposal here soon, but it's not ready > yet... but long story short: I believe we would be far better off moving > to cronie than maintaining our old fork. One question worth asking is which distributions plan to maintain cron moving forward--will some of the systemd-focused ones start dropping it in favor of timers? (No point in migrating to fedora's cronie, for example, if they stop using it in a year or two.) Upstream systemd lacks crontab support, and 3rd party systemd-based replacements are not 100% compatible with cron/cronie/bcron/... What does that have to do with whether other distributions stop supporting crontabs?
Re: Please drop anacron from task-desktop
On Fri, Mar 08, 2019 at 08:01:35PM +0100, Christian Kastner wrote: I intended to post a transition proposal here soon, but it's not ready yet... but long story short: I believe we would be far better off moving to cronie than maintaining our old fork. One question worth asking is which distributions plan to maintain cron moving forward--will some of the systemd-focused ones start dropping it in favor of timers? (No point in migrating to fedora's cronie, for example, if they stop using it in a year or two.)
Re: Please drop anacron from task-desktop
On Thu, Mar 07, 2019 at 09:02:23PM +0100, Holger Wansing wrote: I'm actually wondering if this is a good idea.. There are lot of other packages installing cronjobs and people, I would assume, expect that they will run. I would personally revert his patch as long as all the cronjobs have not a corresponding systemd .timer Any thoughts on this? What's the downside to having anacron there if a .timer supersedes the cron job?
Accepted coreutils 8.30-3 (source amd64) into unstable
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Format: 1.8 Date: Thu, 28 Feb 2019 10:30:31 -0500 Source: coreutils Binary: coreutils coreutils-dbgsym Architecture: source amd64 Version: 8.30-3 Distribution: unstable Urgency: medium Maintainer: Michael Stone Changed-By: Michael Stone Description: coreutils - GNU core utilities Closes: 923420 Changes: coreutils (8.30-3) unstable; urgency=medium . * Fix renameat2 patch (Closes: #923420) Checksums-Sha1: 7a110d042666df380eaf2338d6e324a42fdf8d55 1861 coreutils_8.30-3.dsc 09a9761b2c781fee706833bc99e40c9cdc41689f 32808 coreutils_8.30-3.debian.tar.xz 34e12929f616575f998aa86d557712ab1b251123 7168128 coreutils-dbgsym_8.30-3_amd64.deb 8317de329a7ba1c6148b66b7f00fbaeb4f5b12df 7078 coreutils_8.30-3_amd64.buildinfo df3e8007a3bcb8db05ac55277676936ccb1c9435 2707932 coreutils_8.30-3_amd64.deb Checksums-Sha256: 106031a57a2ab2ba46b61083035e2ccb438c85a2b3506a8198b67868dde1546d 1861 coreutils_8.30-3.dsc 9179d45fb51d07a8743c4d58464459330eb6d4b489d59641d70c3bd9f579b694 32808 coreutils_8.30-3.debian.tar.xz 44409552e5699b21b6a55443d6115cd5b9bf5b6e2c2bdfab71d213a0f0a6354c 7168128 coreutils-dbgsym_8.30-3_amd64.deb fd5f9230ea263fc763537c86d6a296f778345ced6d80ed973fb985f47b2b96dd 7078 coreutils_8.30-3_amd64.buildinfo ae6e5cd6e9aaf74d66edded3931a7a6c916625b8b890379189c75574f6856bf4 2707932 coreutils_8.30-3_amd64.deb Files: 8e7167ff50149c83192535df18eee396 1861 utils required coreutils_8.30-3.dsc f68506bc07552eee03c7652cb38431e8 32808 utils required coreutils_8.30-3.debian.tar.xz da01e2c62a06720f9ec4da1a47d65d54 7168128 debug optional coreutils-dbgsym_8.30-3_amd64.deb b8c27d1c7c86c979cb75a4f4cd9e427f 7078 utils required coreutils_8.30-3_amd64.buildinfo 4a658a39c2810530df6642d22f65ddd1 2707932 utils required coreutils_8.30-3_amd64.deb -BEGIN PGP SIGNATURE- iQIzBAEBCgAdFiEEAtUxX/EfDh4C9hqs3PoR/94FAlx3/2QACgkQ9hqs3PoR /94EjQ//XzQ+HSACRp6qUgGPgbupZJdVws23alDnslDki/GcZFu8MMNjVZYMWKWI a2YKLHLArHi1/WWSBn60hQrZ46bPvdvH2xfDQCEpGUAspbL6g2XP2yTtOisxBAbm HMey1WCzsL/oRw2jhsUxOkVO+i9Wdd/ijf8Y27XTUCtZ9jDrldbJQo7j+5NiIQcA NfCye/ehQve2ckYbow7va4KJYAnM9eoSpW9CnNSQQAKuNGJMN1/Z+GwGDHyaHV4b 2nrSUitH1/Xy8ohzfye25jScPuEV+wajb3W5A5xQ8CnIKBFT/Pt8dooDsBRq3ZgT n8tIsWS2ARFzFMaKdEthcINu1J2d6NIMWuLNAiAYPlo3xdbKjdr34L7j+PoLaAFG rXk4nEJgbfAJzRCRA7jENpBfIJQWvdOd6DgJklkhyXrfEo2AaftCs0AM379Cbe/S FdIu5yvaFxPJpGomBVpwJ3f0UjVaVANnpF2SRlBve0OFv0ojcyzrnt9U3em1ugm4 mmOyzb+2f5yCjxXUnNs/DdnrRRw55ASHmUH9yel9ua+PdSNJPoV27FxPf6bvBM06 dycDyl2Sub7qx5biKr5cKrwbqNmPyou/4ZNgXHT7U+nUZjC5bgoUU3o6uwYfzA34 s1UxjPSmoIF/IEQ9k9pX2OFJDPafS5MFe7sZ+5cfPC6+RSFZNgg= =cBft -END PGP SIGNATURE-
Accepted coreutils 8.30-2 (source amd64) into unstable
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Format: 1.8 Date: Tue, 26 Feb 2019 07:15:19 -0500 Source: coreutils Binary: coreutils coreutils-dbgsym Architecture: source amd64 Version: 8.30-2 Distribution: unstable Urgency: medium Maintainer: Michael Stone Changed-By: Michael Stone Description: coreutils - GNU core utilities Closes: 915559 Changes: coreutils (8.30-2) unstable; urgency=medium . * Use renameat glibc function that can be intercepted by fakechroot (Closes: #915559) * Above requires autoreconf turned on again Checksums-Sha1: 07343587915d2976873e066fed2284a58260c50e 1861 coreutils_8.30-2.dsc 74c27198720a3025d3caa5504c4d13e9e1e7d72e 32368 coreutils_8.30-2.debian.tar.xz 86cefd574b3891e00b1ba49c21a885ed1df1a6c1 7164580 coreutils-dbgsym_8.30-2_amd64.deb 4d9378ddfeb4f3b9f1ef4dbca0c87d4b5cd7df52 7078 coreutils_8.30-2_amd64.buildinfo 35863c2c0ae6275d6d3f30dc637608bf336d859a 2706740 coreutils_8.30-2_amd64.deb Checksums-Sha256: 450506ba6b417a827344d2083b1d0e00dfef2ca9546a1eec645652f068b84aeb 1861 coreutils_8.30-2.dsc 58bea49dc60fcbc89fcdf86c46dd3ebd2cba0c15b92daf699dc9f5c3c78bd362 32368 coreutils_8.30-2.debian.tar.xz a4284a0094e197e5aea0561b22c8ab6ce2f6e634d91cbb6a1ce021ea8ab7bbf5 7164580 coreutils-dbgsym_8.30-2_amd64.deb 45cd84262a4b6d5b3057130c8437d32deb08dfab6a4d2537d49bb400aec29cca 7078 coreutils_8.30-2_amd64.buildinfo 1d1fbed93b80b4ed2b236ea33a49bfbad3a110de46479bb10f6722eda620a994 2706740 coreutils_8.30-2_amd64.deb Files: df8f803183d6783726fbc47eb06e75fe 1861 utils required coreutils_8.30-2.dsc efce4b43803d108ad4a65f3c16ce4643 32368 utils required coreutils_8.30-2.debian.tar.xz f563a47f7ff3b5c7043f7bc5feb0f6d7 7164580 debug optional coreutils-dbgsym_8.30-2_amd64.deb 2ad479e422aee83e1c71dda4ac51321c 7078 utils required coreutils_8.30-2_amd64.buildinfo 35f4d378eafcc91e413354cd81ec6b12 2706740 utils required coreutils_8.30-2_amd64.deb -BEGIN PGP SIGNATURE- iQIzBAEBCgAdFiEEAtUxX/EfDh4C9hqs3PoR/94FAlx1MawACgkQ9hqs3PoR /97pBBAAwIVbhBn4MVnAeUx2RWRTp/dJDZInxX/zy+b9hYsPAlZW6C0ik6+3njzu dnjXUdFMllIp2ox/suqHhm+p0osJJjzf4L57H1cI25f4LM9ny3xg+AggBz5Lb1Ls +3fstZPh1902kiZtLGtqXEjQ+Eb0BZaM9r4XS8BuYxDtwBgd+t667hrNDclLoNKB urMtHOLaX0MxRYvGEpgf9JYjT9uCNbgvJEUvqjaaWcNjuqjco2iboCc818wC+KjA YkCFLvSfKxEpbJUTO8hiTIteoTITWvhX/fUagZsO+80Wr9FuvTDjeEO53p4NilHP Dor3Leycf0UKU5tUfiapaTSm4S7qz3xvEkOHbC2rK4bV95sH3ySKIv3nZmYzhY3e ChO4lnaiXVCBbWxcMlstwwhyCuzjYywNu8wuT9yoRNvLNTdlkw0Imvf1sGKOoyhM CrPNqXNgmqiM1LA1scDE7247ysv9eLQUUhQbTHF7WDh/4cVMaKLOTEauPF5y85DG Rsf/gkygMQEoC7TunZWuBAaNrXnpmdZM6x8lf3VaKBNbchW3F3hIVNNKlP5zR/ek aZN+6MSobKpPIw0fMun4iwZyaAjev2CF3cA41d4VTJRDpHv0Uo3uJuLL1nXQyMk5 vunpFKoW5WRB4IK3IOz+Zja3jpLz68Iw27+fwSDIJnroZBS9yHg= =skoj -END PGP SIGNATURE-
Re: FYI/RFC: early-rng-init-tools
On Mon, Feb 25, 2019 at 03:53:09PM +, Ben Hutchings wrote: The major input into the new seed file contents is the old seed file contents. Yes, I'd just drop the seed file once used, then have a scheduled job write a new one at some point in the future if the random quality is high enough. If you reboot twice in a row the second boot won't get seeded, but that's better than a package that introduces potentially insecure random seeding by default. Maybe add a non-default option to allow seed reuse with a lot of warnings, but don't do it by default.
Re: Bug#877900: How to get 24-hour time on en_US.UTF-8 locale now?
On Thu, Feb 07, 2019 at 10:21:49PM +0100, Ansgar wrote: (And you get 24-hour time, but very strange Endian in C.UTF-8: WEEKDAY MMM DD HH:MM:SS TZ while en_US.UTF-8 has at least DD MMM ... Having -MM-DD HH:MM:SS[+] instead would be much nicer if we were to create an arbitrary set of new rules for a new universal "en" locale ;-) ) Exactly: using "C" implies compatability with the old POSIX rules, "en" implies you can do whatever you want. :)
