Bug#963971: [Pkg-samba-maint] Bug#963971: samba-libs: libndr.so.0 gone from latest version, breaks sssd-ad-common dependency

On Sat, Jul 04, 2020 at 03:21:03PM +0200, Mathieu Parent wrote: Le sam. 4 juil. 2020 à 15:15, Michael Stone a écrit : On Sat, Jul 04, 2020 at 07:28:32AM +0200, Mathieu Parent wrote: >clone 963971 -1 >tag 963971 + upstream >tag -1 + upstream fixed-upstream patch >reassign -1 ss

Bug#963971: [Pkg-samba-maint] Bug#963971: samba-libs: libndr.so.0 gone from latest version, breaks sssd-ad-common dependency

On Sat, Jul 04, 2020 at 07:28:32AM +0200, Mathieu Parent wrote: clone 963971 -1 tag 963971 + upstream tag -1 + upstream fixed-upstream patch reassign -1 sssd-ad-common Le lun. 29 juin 2020 à 14:48, Michael Stone a écrit : Package: samba-libs Version: 2:4.12.3+dfsg-2 Severity: critical

Bug#963971: [Pkg-samba-maint] Bug#963971: samba-libs: libndr.so.0 gone from latest version, breaks sssd-ad-common dependency

On Sat, Jul 04, 2020 at 07:28:32AM +0200, Mathieu Parent wrote: clone 963971 -1 tag 963971 + upstream tag -1 + upstream fixed-upstream patch reassign -1 sssd-ad-common Le lun. 29 juin 2020 à 14:48, Michael Stone a écrit : Package: samba-libs Version: 2:4.12.3+dfsg-2 Severity: critical

Re: Very old hardware...

On Fri, Jul 03, 2020 at 07:17:33PM +0200, Davide Lombardo wrote: Good evening Debian User, I have found an old PC with these specs: CPU: Pentium III 700 Mhz; DRAM: 64 MB SDDR GPU: RIVA TNT-2 HARDISK: 10 GB FLOPPY DISK DRIVE MODEM 56K In the receipt is written 3,000 Lire (1,500) Euro of today...

Bug#963971: samba-libs: libndr.so.0 gone from latest version, breaks sssd-ad-common dependency

On Tue, Jun 30, 2020 at 08:48:05AM +1200, Andrew Bartlett wrote: On Mon, 2020-06-29 at 08:46 -0400, Michael Stone wrote: Package: samba-libs Version: 2:4.12.3+dfsg-2 Severity: critical Justification: breaks the whole system The new samba-libs package changes the soname of libndr from libndr.so

Bug#963971: samba-libs: libndr.so.0 gone from latest version, breaks sssd-ad-common dependency

On Tue, Jun 30, 2020 at 08:48:05AM +1200, Andrew Bartlett wrote: On Mon, 2020-06-29 at 08:46 -0400, Michael Stone wrote: Package: samba-libs Version: 2:4.12.3+dfsg-2 Severity: critical Justification: breaks the whole system The new samba-libs package changes the soname of libndr from libndr.so

Bug#963971: samba-libs: libndr.so.0 gone from latest version, breaks sssd-ad-common dependency

Package: samba-libs Version: 2:4.12.3+dfsg-2 Severity: critical Justification: breaks the whole system The new samba-libs package changes the soname of libndr from libndr.so.0 to libndr.so.1 without reflecting this change in the package name. sssd-ad-common has a dependency on samba-libs (>=

Bug#963971: samba-libs: libndr.so.0 gone from latest version, breaks sssd-ad-common dependency

Package: samba-libs Version: 2:4.12.3+dfsg-2 Severity: critical Justification: breaks the whole system The new samba-libs package changes the soname of libndr from libndr.so.0 to libndr.so.1 without reflecting this change in the package name. sssd-ad-common has a dependency on samba-libs (>=

Re: Advice on encrypted filesystem

On Fri, Jun 26, 2020 at 02:06:57PM -0500, David Wright wrote: Agreed. But I wouldn't be writing any sensitive information to an SSD in the first place without encrypting it. (Not that I own any yet.) SSDs are more common than not in new computers so it's probably best to assume that people

Re: Advice on encrypted filesystem

On Fri, Jun 26, 2020 at 08:25:49AM -0500, David Wright wrote: If encrypting an entire disk, scramble the disk first, then partition. If only encrypting a partition, partition the disk first. Alignments should be at least 2M (4096 x 512B sectors). Scramble any sensitive pre-existing contents: #

Bug#963752: exfat-fuse should not provide /sbin/mount.exfat

On Fri, Jun 26, 2020 at 03:36:02PM +0200, Sven Hoexter wrote: On Fri, Jun 26, 2020 at 09:08:27AM -0400, Michael Stone wrote

Bug#963752: exfat-fuse should not provide /sbin/mount.exfat

On Fri, Jun 26, 2020 at 09:08:27AM -0400, I wrote: Now that exfat is available as a kernel module, it would be nice if the /sbin/mount.exfat link were removed to make it easier for a user to choose either the exfat kernel module or the fuse module at runtime. Currently the link masks the kernel

Bug#963752: exfat-fuse should not provide /sbin/mount.exfat

Package: exfat-fuse Version: 1.3.0-1 Severity: wishlist Now that exfat is available as a kernel module, it would be nice if the /sbin/mount.exfat link were removed to make it easier for a user to choose either the exfat kernel module or the fuse module at runtime. Currently the link masks the

Bug#963513: Please restore LC_TIME symlinks

On Mon, Jun 22, 2020 at 09:41:20PM +0200, Jordi Mallach wrote: In #584837, it was requested that the symlinks from ...//LC_MESSAGES/coreutils.mo to ../LC_TIME/coreutils.mo were removed due to being pointless and unused. I'm unsure if that was the case at that point (it's been 10 years),

Re: Could RAM possibly be just 3-4 times faster than bare hdd writes and reads? or, is the Linux kernel doing its 'magic' in the bg? or, ...

On Thu, Jun 18, 2020 at 05:28:11PM +0300, Reco wrote: Hi. On Thu, Jun 18, 2020 at 08:57:48AM -0400, Michael Stone wrote: On Thu, Jun 18, 2020 at 08:50:49AM +0300, Reco wrote: > On Wed, Jun 17, 2020 at 05:54:51PM -0400, Michael Stone wrote: > > On Wed, Jun 17, 2020 at 11:45:5

Re: Could RAM possibly be just 3-4 times faster than bare hdd writes and reads? or, is the Linux kernel doing its 'magic' in the bg? or, ...

On Thu, Jun 18, 2020 at 08:50:49AM +0300, Reco wrote: Hi. On Wed, Jun 17, 2020 at 05:54:51PM -0400, Michael Stone wrote: On Wed, Jun 17, 2020 at 11:45:53PM +0300, Reco wrote: > Long story short, if you need a primitive I/O benchmark, you're better > with both dsync and n

Re: Could RAM possibly be just 3-4 times faster than bare hdd writes and reads? or, is the Linux kernel doing its 'magic' in the bg? or, ...

On Wed, Jun 17, 2020 at 11:45:53PM +0300, Reco wrote: Long story short, if you need a primitive I/O benchmark, you're better with both dsync and nocache. Not unless that's your actual workload, IMO. Almost nothing does sync i/o; simply using conv=fdatasync to make sure that the cache is

Re: Could RAM possibly be just 3-4 times faster than bare hdd writes and reads? or, is the Linux kernel doing its 'magic' in the bg? or, ...

On Wed, Jun 17, 2020 at 12:14:55PM +0200, Albretch Mueller wrote: HDDs have their internal caching mechanism and I have heard that the Linux kernel uses RAM very effitiently, but to my understanding RAM being only 3-4 times faster doesn't make much sense, so I may be doing or understanding

Re: using tar

On Mon, Jun 15, 2020 at 07:30:31PM +0100, mick crane wrote: yes I see that now but without hyphen "f" can be anywhere Yes and no: any of the keys can be in any location, but their arguments must follow the key list in the order that the keys appear. For example: tar cbf 20 foo.tar

Re: using tar

On Mon, Jun 15, 2020 at 02:34:24PM -0500, David Wright wrote: It appears you've also forgotten about man pages as well as google. The man page explains the difference between hyphenated and unhyphenated forms, and helpfully even gives a single example written in both forms: tar cfv a.tar

Re: [OT] Regular DKIM issues on this ML (was: Re: why !oh why Debian and application list)

On Fri, Jun 12, 2020 at 11:53:40PM +0300, Reco wrote: No, the body is not interesting at all here. What I'm interested in is the result of DKIM check, and that's might be written in e-mail headers. Or not. dkim=fail (2048-bit key) reason="fail (body has been altered)"

Re: [OT] Regular DKIM issues on this ML (was: Re: why !oh why Debian and application list)

On Fri, Jun 12, 2020 at 11:32:20PM +0300, Reco wrote: Hi. On Fri, Jun 12, 2020 at 04:16:23PM -0400, Michael Stone wrote: On Fri, Jun 12, 2020 at 12:36:29PM -0400, Michael Stone wrote: > On Fri, Jun 12, 2020 at 09:52:57AM -0400, Michael Stone wrote: > > On Fri, Jun 12, 2020

Re: [OT] Regular DKIM issues on this ML (was: Re: why !oh why Debian and application list)

On Fri, Jun 12, 2020 at 12:36:29PM -0400, Michael Stone wrote: On Fri, Jun 12, 2020 at 09:52:57AM -0400, Michael Stone wrote: On Fri, Jun 12, 2020 at 03:48:42PM +0200, l0f...@tuta.io wrote: My email below got a DKIM issue. It validated fine here, not a debian list issue. For the record, I

Re: [OT] Regular DKIM issues on this ML (was: Re: why !oh why Debian and application list)

On Fri, Jun 12, 2020 at 09:52:57AM -0400, Michael Stone wrote: On Fri, Jun 12, 2020 at 03:48:42PM +0200, l0f...@tuta.io wrote: My email below got a DKIM issue. It validated fine here, not a debian list issue. For the record, I looked at the wrong email. The right one did fail DKIM

Re: [OT] Regular DKIM issues on this ML (was: Re: why !oh why Debian and application list)

On Fri, Jun 12, 2020 at 03:48:42PM +0200, l0f...@tuta.io wrote: My email below got a DKIM issue. It validated fine here, not a debian list issue.

Re: How long will this take?

On Thu, Jun 11, 2020 at 08:52:10PM -0500, David Wright wrote: If you were preserving the disk contents (imagine there were proprietary encryption software on it), and performed a "read test" or ran badblocks on it, would that be sufficient to test the disk's performance, as it's merely reading

Re: [OT] How to help the OP? (was: How long will this take?)

On Thu, Jun 11, 2020 at 10:58:39AM +0200, deloptes wrote: There is nothing unpolite in the mentioned statement: "There is no dilemma at all: we are not paid help-desk technicians." I wasn't referring to that statement, I was referring to several other emails which were apparently being

Re: [OT] How to help the OP? (was: How long will this take?)

On Wed, Jun 10, 2020 at 09:51:37PM +0200, Nicolas George wrote: Michael Stone (12020-06-10): Interacting in a polite fashion shouldn't require a paycheck. What does politeness have to do with it? It helps create a positive community. Constantly attacking people because you think they're

Re: [OT] How to help the OP? (was: How long will this take?)

On Wed, Jun 10, 2020 at 09:24:08PM +0200, Nicolas George wrote: l0f...@tuta.io (12020-06-10): It's the usual dilemma on mailing-lists/forums: * Are the respondents supposed to answer the OP question directly without hindsight (potential XY problem sometimes - http://xyproblem.info/)? * Or are

Re: [OT] How to help the OP? (was: How long will this take?)

On Wed, Jun 10, 2020 at 09:20:50PM +0200, l0f...@tuta.io wrote: * Are the respondents supposed to answer the OP question directly without hindsight (potential XY problem sometimes - http://xyproblem.info/)? * Or are they expected to put the issue into perspective and challenge it? I know it

Re: How long will this take?

On Wed, Jun 10, 2020 at 12:02:13PM -0500, David Wright wrote: I tried to make clear that my use case differed from that of the OP, in case you missed that. Just before lockdown (=lockout). I borrowed an AIO computer and, to make room, returned a 2006 vintage tower that would no longer pass its

Re: How long will this take?

On Wed, Jun 10, 2020 at 05:53:17PM +0300, Andrei POPESCU wrote: On Mi, 10 iun 20, 10:00:48, Michael Stone wrote: IME performance peaks at 16-64k. Beyond that things don't improve, and can potentially get worse or cause other issues. Even so, bs=1M is easy to remember and type ;) I don't

Re: How long will this take?

On Mon, Jun 08, 2020 at 10:01:13PM -0500, David Wright wrote: On Mon 08 Jun 2020 at 20:22:39 (+), Matthew Campbell wrote: I bought a new 4 terrabyte hard drive that is connected with a USB cable using USB2. It took about 32 hours to read every sector on the drive to look for bad sectors.

Re: How long will this take?

On Mon, Jun 08, 2020 at 08:22:39PM +, Matthew Campbell wrote: I bought a new 4 terrabyte hard drive that is connected with a USB cable using USB2. It took about 32 hours to read every sector on the drive to look for bad sectors. I started blanking the sectors using /dev/zero last Friday

Re: Zoom- best practice?

On Wed, Jun 10, 2020 at 03:17:34PM +0200, Nicolas George wrote: Michael Stone (12020-06-10): Properly configured mailing list software does no such thing, since it's a misuse of the reply-to header. A misuse that works, Except for the things that it breaks, and the cases for which

Re: Zoom- best practice?

On Tue, Jun 09, 2020 at 12:51:00PM +0200, Nicolas George wrote: Instead of writing this periodically, you could include: Reply-To: debian-user@lists.debian.org in your headers just like I did. Properly configured mailing-list software does it by default for subscribed users, but Debian is an

Bug#961740: printf attempts to parse options and fails to print --help

On Thu, May 28, 2020 at 05:56:09PM +0200, Melvin Vermeeren wrote: On Thursday, 28 May 2020 17:50:20 CEST Michael Stone wrote: Yes, running printf with the single argument --help will print help. A portable and posix-compliant alternative would be to run "printf '%s' --help". This is

Bug#961215: blueman-manager no longer starts because blueman-applet.service not found

On Sat, May 23, 2020 at 02:08:47AM +0200, Tomasz Nitecki wrote: Hey, This issue seems to be caused by changes made in #950520 [1]. I've described the problem in more detail in that bug report [1]. To cut long story short, this bug (#961215) seems to be affecting non /usr merged systems.

Bug#961215: blueman-manager no longer starts because blueman-applet.service not found

More specifically, refer to systemd.unit(5) and you'll find that /lib/systemd/user is not defined.

Bug#961215: blueman-manager no longer starts because blueman-applet.service not found

Package: blueman Version: 2.1.3-1 Severity: normal Running blueman-manager from the command line results in this: > blueman-manager blueman-manager version 2.1.3 starting Stale PID, overwriting Blueman applet needs to be running In syslog is: May 21 09:16:48 annuminas dbus-daemon[2472]:

Re: 1Gbps Ethernet drops to 100Mbps

On Wed, May 13, 2020 at 08:58:16PM +0200, Nazar Zhuk wrote: I have a 1Gbps network port that correctly connects as 1Gbps full duplex on boot, then drops to 100Mbps 4 seconds later. I'd check that autonegotiation isn't disabled on the other end, then try another cable.

Re: Which sha sum is the fastest?

On Mon, Apr 27, 2020 at 09:55:32AM -0500, Peng Yu wrote: I got the following run time on a file of 116M. They are ranked in this order. Is this runtime order in general true? no; it will depend heavily on compile-time options and cpu-level optimizations.

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

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]

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

Re: Advice on upgrading to SSD

On Thu, Mar 05, 2020 at 10:11:55AM -0500, rhkra...@gmail.com wrote: On Thursday, March 05, 2020 03:27:09 AM to...@tuxteam.de wrote: On Wed, Mar 04, 2020 at 06:53:12PM -0500, Gene Heskett wrote: [...] > That is lieing to the user, and not nice at all. Disable your caches! now! What? Your

Re: Advice on upgrading to SSD

On Wed, Mar 04, 2020 at 06:53:12PM -0500, Gene Heskett wrote: On Wednesday 04 March 2020 18:49:06 Michael Stone wrote: On Wed, Mar 04, 2020 at 06:39:51PM -0500, Gene Heskett wrote: >On Wednesday 04 March 2020 12:48:57 rhkra...@gmail.com wrote: >>* I suspect most of us don't kno

Re: Advice on upgrading to SSD

On Wed, Mar 04, 2020 at 06:39:51PM -0500, Gene Heskett wrote: On Wednesday 04 March 2020 12:48:57 rhkra...@gmail.com wrote: * I suspect most of us don't know whether our disks are spinning 24/7 -- some of my computers are up 24/7, but I suspect the disks "spin down" when unused for some

Re: Advice on upgrading to SSD

On Wed, Mar 04, 2020 at 02:47:47PM +, Tony van der Hoff wrote: Gene didn't address my problem, but made the very useful observation that disks spinning 24/7 don't really die. Perhaps I shouldn't worry about replacing them. the speed advantages are such that I try to avoid spinning disks

Re: Advice on upgrading to SSD

On Mon, Mar 02, 2020 at 02:22:45PM -0500, Sarunas Burdulis wrote: On 3/2/20 2:19 PM, David Christensen wrote: On 2020-03-02 03:28, Tony van der Hoff wrote: Hi, I'm currently running Buster on a 5 year old GigaByte motherboard with a 10-year old Raid-1 array on 2 500GB disks. Although it is

Re: Best file system to use?

On Thu, Feb 13, 2020 at 01:57:49PM -0700, Tom Dial wrote: XFS is excellent, and so also is JFS. Yes on XFS, no on JFS. (XFS is very actively developed; JFS is moribund, has no really compelling benefits over other filesytems, and gets much less testing due to very low adoption. I don't

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

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

Bug#951134: postfix-policyd-spf-python: breaks due to lack of versioned dependency

Package: postfix-policyd-spf-python Version: 2.9.2-0+deb10u1 Severity: important postfix-policyd-spf-python has a dependency on python3-spf-engine, but does not specify a version. If the policyd package is upgraded but the engine package is not, then mail delivery halts on the system due to the

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: Anyone with experience scanning with Epson

On Fri, Feb 07, 2020 at 07:06:37PM +, Brian wrote: Like protocols, everyone can have their own set of defaults on buster. In which case, they can sort their own problems out. :) Or you just don't waste time complaining about something that's a no-op on a properly functioning system with a

Re: Anyone with experience scanning with Epson

On Fri, Feb 07, 2020 at 03:36:55PM +, Brian wrote: On Fri 07 Feb 2020 at 10:25:22 -0500, Michael Stone wrote: On Fri, Feb 07, 2020 at 03:05:31PM +, Brian wrote: > On Fri 07 Feb 2020 at 09:37:17 -0500, Michael Stone wrote: > > > On Fri, Feb 07, 2020 at 10:36:11AM +0800,

Re: Anyone with experience scanning with Epson

On Fri, Feb 07, 2020 at 03:05:31PM +, Brian wrote: On Fri 07 Feb 2020 at 09:37:17 -0500, Michael Stone wrote: On Fri, Feb 07, 2020 at 10:36:11AM +0800, kaye n wrote: > Hello Friends! > > I'm running: > Kernel: 4.19.0-6-amd64 x86_64 > bits: 64 > Desktop: Xfce 4.12.4 &g

Re: Anyone with experience scanning with Epson

On Fri, Feb 07, 2020 at 10:36:11AM +0800, kaye n wrote: Hello Friends! I'm running: Kernel: 4.19.0-6-amd64 x86_64 bits: 64 Desktop: Xfce 4.12.4 Distro: Debian GNU/Linux 10 (buster) My printer is an Epson L220.  It's connected to my laptop's USB port. The command lsusb shows: Bus 002 Device

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

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 > > A

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

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

Re: Why I don't like UUIDs (Re: can't mount sdf1 in stretch, gparted claims its fat32)

On Wed, Feb 05, 2020 at 07:33:38PM -0600, David Wright wrote: On Wed 05 Feb 2020 at 15:59:27 (-0500), Michael Stone wrote: On Wed, Feb 05, 2020 at 01:43:37PM -0600, David Wright wrote: > On Wed 05 Feb 2020 at 09:00:41 (-0500), Michael Stone wrote: > > On Tue, Feb 04, 2020 at 07:04:1

Re: package versions on the mirrors

On Wed, Feb 05, 2020 at 08:30:17PM -0500, Felix Miata wrote: How does one discover package versions on the mirrors? I know linux-image-* is there. How does one search for the versions of it hosted there? apt-show-versions linux-image-amd64 shows only one, and not which repo it comes from. Where

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"

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

Re: Why I don't like UUIDs (Re: can't mount sdf1 in stretch, gparted claims its fat32)

On Wed, Feb 05, 2020 at 01:43:37PM -0600, David Wright wrote: On Wed 05 Feb 2020 at 09:00:41 (-0500), Michael Stone wrote: On Tue, Feb 04, 2020 at 07:04:16PM -0500, Stefan Monnier wrote: > While I'm sure this can be managed by explicitly setting UUIDs, I've > found it much more pl

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: Why I don't like UUIDs (Re: can't mount sdf1 in stretch, gparted claims its fat32)

On Tue, Feb 04, 2020 at 07:04:16PM -0500, Stefan Monnier wrote: Me too, so I usually label the permanent stuff at least. UUID's can and will change for no detectable reason. For those reading along or finding this in search results: no, filesystem UUIDs don't change for no detectable reason.

Re: can't mount sdf1 in stretch, gparted claims its fat32

On Tue, Feb 04, 2020 at 11:06:10AM -0500, Gene Heskett wrote: Me too, so I usually label the permanent stuff at least. UUID's can and will change for no detectable reason. For those reading along or finding this in search results: no, filesystem UUIDs don't change for no detectable reason.

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

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

Re: guys

On Sat, Feb 01, 2020 at 07:31:31PM +, mick crane wrote: I probably shouldn't post this. I see all these questions people trying to get their installations to work. It is supposed to be files with documentation what they do. Is there a reason things seem to get more complicated ? Because

Re: Ethernet trouble

On Sat, Feb 01, 2020 at 12:28:51AM +0300, Reco wrote: Hi. On Fri, Jan 31, 2020 at 03:57:44PM -0500, Michael Stone wrote: FWIW, I would never force something to use "eth0" because it makes it impossible to see at first glance that all of the default behavior has been

Re: How to configure e-net port again -- SOLVED (sort of)

On Fri, Jan 31, 2020 at 02:57:13PM -0600, Dennis Wicks wrote: Michael Stone wrote on 1/31/20 2:00 PM: Do you remember which one you used? Both can be used, but if you try to use both at the same time you'll have problems. I'd suggest uninstalling one of them, or at the very least make sure

Re: Ethernet trouble

On Fri, Jan 31, 2020 at 03:29:44PM -0500, Bob Weber wrote: On 1/31/20 1:41 PM, Michael Stone wrote: You went through more effort than you needed to. You can turn off predictable names by simply booting with net.ifnames=0 on the kernel command line (you can make that permanent by editing

Re: How to configure e-net port again

On Fri, Jan 31, 2020 at 11:27:06AM -0600, Dennis Wicks wrote: john doe wrote on 1/31/20 1:00 AM: On 1/31/2020 2:48 AM, Dennis Wicks wrote: I am running Debian Buster 10, upgrade within the past week. I tried to change my e-net to use dhcp, which I thought it was but it How did you try to

Re: Ethernet trouble

On Fri, Jan 31, 2020 at 01:31:43PM -0500, Bob Weber wrote: First I created  /etc/systemd/network/10-eth0.link using the MAC address and the name eth0.  If the MAC changes then there are other characteristics to add to the [Match] section to uniquely define the port (see above link). ---

Re: Ethernet trouble

On Fri, Jan 31, 2020 at 04:32:32PM +0100, to...@tuxteam.de wrote: On Fri, Jan 31, 2020 at 10:10:25AM -0500, Michael Stone wrote: because they don't need to know that. This is an issue mostly for people who know a little bit, want to tinker, and become irrationally angry when they need to learn

Re: Ethernet trouble

On Fri, Jan 31, 2020 at 04:32:32PM +0100, to...@tuxteam.de wrote: On Fri, Jan 31, 2020 at 10:10:25AM -0500, Michael Stone wrote: On Fri, Jan 31, 2020 at 10:01:23AM -0500, Greg Wooledge wrote: >The primary drawback of this method is that in the common case of a >single-user home desktop

Re: What is the difference between unlink and rm -f?

On Wed, Jan 29, 2020 at 08:42:20PM -0600, Peng Yu wrote: So a one-line summary is When the target can be delete, unlink and rm -f are the same; otherwise, unlink will complain about the error and exit with 1, but rm -f will do neither. No, rm -f will also exit with 1 if the file exists bug

Re: Ethernet trouble

On Fri, Jan 31, 2020 at 10:01:23AM -0500, Greg Wooledge wrote: The primary drawback of this method is that in the common case of a single-user home desktop system with a single NIC, the name "eth0" is expected to Just Work for whatever NIC happens to be in the system at the time. It's also

Re: Ethernet trouble

On Fri, Jan 31, 2020 at 09:39:37AM -0500, Dan Ritter wrote: Michael Stone wrote: As a programmer you should be concerned with making sure that the packets go in and out of the correct physical hardware. If the name doesn't relate to the physical harder that's a harder problem to solve. You

Re: Ethernet trouble

On Thu, Jan 30, 2020 at 11:58:47AM -0700, ghe wrote: I looked at dmesg a bit. I greped it for 'enp' and there was a funny joke in the first 2 lines (of the grep output): [2.181317] e1000e :08:00.0 enp8s0: renamed from eth1 [2.422105] e1000e :07:00.0 enp7s0: renamed from eth0 So

Re: Ethernet trouble

On Wed, Jan 29, 2020 at 03:18:13PM -0700, ghe wrote: But that had nothing to do with naming Ethernet interfaces. At least to a human it didn't. They're still on the same PCI bus (0, and soldered to the same places on MB, as I find I've said before). some motherboards are better than others

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

Re: apple mini

On Thu, Jan 09, 2020 at 09:22:09AM +0200, Andrei POPESCU wrote: On Jo, 09 ian 20, 17:03:57, Ben Caradoc-Davies wrote: On 09/01/2020 16:45, David Wright wrote: > No, don't mix degaussers and disks. If you want to reuse them, they're > likely too damaged. If you're concerned about data recovery,

Re: apple mini

On Thu, Jan 09, 2020 at 10:11:15AM +, Andy Smith wrote: Hello, On Thu, Jan 09, 2020 at 12:11:54PM +1300, Ben Caradoc-Davies wrote: If you need to protect against an attacker willing to examine your HDD with magnetic force microscopy, there is no substitute for physical destruction of the

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

Re: apple mini

On Wed, Jan 08, 2020 at 10:36:33PM +, Jonathan Dowland wrote: On Wed, Jan 08, 2020 at 03:21:08PM -0500, Michael Stone wrote: dd is certainly sufficient, but suggesting that someone use random data is to suggest slowing things down without providing any advantage. I think "cp&q

Re: apple mini

On Thu, Jan 09, 2020 at 12:11:54PM +1300, Ben Caradoc-Davies wrote: I use ATA secure erase ; I activate it with hdparm from a live usb drive (you may need to install hdparm). I do not know if ATA secure erase is supported by the mini bios

Re: apple mini

On Wed, Jan 08, 2020 at 02:43:54PM -0700, ghe wrote: According to the dban dox, multiple passes do make a difference. I've never understood why writing the same tracks over and over makes much difference, though. But I've seen it in more than one place. Yes, it's a wrong idea which has been

Re: apple mini

On Wed, Jan 08, 2020 at 12:53:15PM -0700, ghe wrote: On 1/8/20 11:59 AM, Michael Stone wrote: No, that's still an unnecesarily slow alternative Hence the suggestion to run it overnight, while asleep. And, I suspect, dd is plenty good enough to make the disk in a Mac Mini unreadable by a Mac

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

Re: apple mini

On Wed, Jan 08, 2020 at 01:55:45PM -0500, Greg Wooledge wrote: On Wed, Jan 08, 2020 at 01:45:28PM -0500, Michael Stone wrote: On Wed, Jan 08, 2020 at 11:41:00AM -0700, ghe wrote: > On 1/8/20 10:44 AM, Felix Miata wrote > > > If you're seriously concerned the next owner might try

Re: apple mini

On Mon, Jan 06, 2020 at 02:03:39AM -0700, ghe wrote: Or if you want a multi-pass DoD wipe, try DBAN: https://sourceforge.net/projects/dban/ There is no current guidance that anything more than a single pass of zeros is necessary or beneficial when wiping a magnetic disk. There are reasons

Re: apple mini

On Wed, Jan 08, 2020 at 11:41:00AM -0700, ghe wrote: On 1/8/20 10:44 AM, Felix Miata wrote If you're seriously concerned the next owner might try that, create a new file full of junk from /dev/random or from /dev/null that fills the existing freespace, then remove it. This is not at all a

Re: Debian Graphical Installer: why does it format swap?

This all dates from the days when 1) you might actually need swap to complete an install and 2) swap was utilized by partition name and not a UUID. It's reasonable to wonder if the installer still needs to be so aggressive about swap space. There's a bug (842409) dating from 2016 regarding

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?

<    1   2   3   4   5   6   7   8   9   10   >