On Sat, Sep 24, 2022 at 03:17:31PM +0200, hede wrote:
> Am 21.09.2022 14:46, schrieb Emanuel Berg:
> > Maybe related to the '-o f f' part as your imagination
> > tells you ...
>
> The "-o" means: "Write output image to FILE". And it does so, as far as I
> can see.
The question is whether specifyi
Am 21.09.2022 14:46, schrieb Emanuel Berg:
I don't know what the intended behaviof of "exif --remove -o
file file" is. I'm imagining [...]
exif(1) which says on line 57 that --remove
Remove the tag or (if no tag is specified) the entire IFD.
"Idempotent" means, that a task with the same in
got a reference to that somewhere? After all (some) man pages
have a HISTORY section for historical information.
In the case of the bash(1) page, it's actually followed by a BUG REPORTS
section, telling you how to submit bug reports to the upstream maintainer.
That's not common in man
On 2022-09-23 at 12:02, Emanuel Berg wrote:
> The Wanderer wrote:
>
>> That's maintainership history, with E-mail addresses attached.
>
> There should be no history entries in the man pages that relates to
> practical aspects that are no longer operational.
The E-mail address doesn't relate to
> Brian Fox has not been involved with bash development for
> decades. Nevertheless, removing Brian's email address from
> the AUTHORS section is neither necessary nor desirable.
> Everyone knows it's a historical section.
I think it's wrong to include tech informatio
The Wanderer wrote:
> That's maintainership history, with E-mail
> addresses attached.
There should be no history entries in the man pages that
relates to practical aspects that are no longer operational.
Commands, examples that once worked but are now removed,
options that are obsolete/deprecat
ne knows it's a historical section.
>
> In the case of the bash(1) page, it's actually followed by a BUG
> REPORTS section, telling you how to submit bug reports to the
> upstream maintainer. That's not common in man pages, but clearly not
> unheard of either.
>
&
bash maintainer. Brian Fox has not
been involved with bash development for decades. Nevertheless, removing
Brian's email address from the AUTHORS section is neither necessary nor
desirable. Everyone knows it's a historical section.
In the case of the bash(1) page, it's act
ight © 2002-2012 Thomas Pircher,
>>Dan Fandrich and others.
>>
>> This isn't a contact address for bug reports.
>> It's a historical note.
>
> Indeed, that e-mail belongs to history, which is why it should
> be removed from actively deployed documentation c
Greg Wooledge wrote:
> https://manpages.debian.org/bullseye/exif/exif.1.en.html
>
>AUTHOR
>exif was written by Lutz Mueller
> and numerous contributors.
>This man page is Copyright © 2002-2012 Thomas Pircher,
>Dan Fandrich and others.
>
> This isn&
AUTHOR
exif was written by Lutz Mueller and
numerous contributors. This man page is Copyright © 2002-2012 Thomas
Pircher, Dan Fandrich and others.
This isn't a contact address for bug reports. It's a historical note.
David Wright wrote:
>> But: isn't it still a bug in the distribution man page to
>> refer to mail address that bounces?
>
> I hope the maintainers (Debian's) have better things to do
Are you saying incorrect information in the man pages are OK
in Debian?
> than t
x27;d, let's see what they say.
>
> But: isn't it still a bug in the distribution man page to
> refer to mail address that bounces?
I hope the maintainers (Debian's) have better things to do than trawl
through email addresses in man pages. The man page has its origin
Greg Wooledge wrote:
> According to the package metadata, the Debian maintainer of
> exif is:
OK, cool.
> Maintainer: Debian PhotoTools Maintainers
>
They are CC'd, let's see what they say.
But: isn't it still a bug in the distribution man page to
refer t
ove that from the man page then, i.e. exif(1)
Remove what? Perhaps what you actually want is additional clarity
about how the --remove option (or the -o option) works.
In any case, if you want to file a Debian bug report, see
<https://www.debian.org/Bugs/>.
>From IRC ...
vengeance, you the exif(1) guy here, right, how
can it be it isn't idempotent? I just run it for
every jpg on the HDD and after done, it does the
same thing again upon a 2nd invocation
I'll mail Lutz Mueller as well
fo
Steve McIntyre wrote:
...
> I'm building a new unstable package (2.06-4) right now with Valentin's
> patch applied, and once I've uploaded that I'll do a new bullseye
> package too.
that's great! thank you! :)
songbird
ed from the version in stable
>rather than backported from unstable, but in this case there were no
>intermediate versions in unstable and it was probably thought safer to
>use the package which had been tested in unstable rather than starting
>over and potentially introducing a new bug. That
> On Aug 30, 2022, at 1:12 PM, Casey Deccio wrote:
>
> I am having trouble tracking down a bug in my monitoring setup. It all
> happened when I upgraded the monitored host (host B in my example below) to
> bullseye. Note that Host A is also running bullseye, but the problem
On 9/12/2022 11:36 AM, Tim Woodall wrote:
> On Mon, 12 Sep 2022, David Wright wrote:
>
> >
> > AFAICT it had two months in testing without this problem being
> > hit and reported.
> >
>
> Unfortunately, g-x-h is probably mostly used on stable or oldstable with
> guests running testing.
>
> I'm not
ut in this case there were no
intermediate versions in unstable and it was probably thought safer to
use the package which had been tested in unstable rather than starting
over and potentially introducing a new bug. That probably was even true,
as the problem was identified during the test period o
have been higher.
I think in this case the package was already present in testing and
stable-proposed-updates before the bug was found. It was reported as
"grave" and bounced between that and "serious".
No, it wasn't; as far as I can tell, the bug didn't become &
On Mon, 12 Sep 2022, David Wright wrote:
On Mon 12 Sep 2022 at 14:20:59 (+0100), Tim Woodall wrote:
The same version also went to oldstable - where it turns out it works
fine - so I can see how it could be missed but this was a bug that I
feel would have, if necessary, justified delaying the
sense. "Should bugs make it into Debian releases"?
> >
> > Ah, sorry, I think I misunderstood - you are literally asking if the
> > presence of a severity "serious" bug in Grub should have prevented
> > the whole 11.5 point release happening?
> >
&
he package was already present in testing and
stable-proposed-updates before the bug was found. It was reported as
"grave" and bounced between that and "serious".
Also I am not sure if there are the same processes around this for
packages going in to stable-proposed-updates. Th
On Mon, Sep 12, 2022 at 02:20:59PM +0100, Tim Woodall wrote:
Agreed. While I tend to try to file bugs at the lowest severity that can
be justified, I know that others go the other way. This is one I'd
probably have filed as Grave or even Critical. (I see it's now been
bumped to Grave)
If it's s
On Mon, 12 Sep 2022, David wrote:
On Mon, 12 Sept 2022 at 23:21, Tim Woodall wrote:
It just felt wrong to me that this bug (and version bump of the
package) could go to stable without someone at least acknowleging the
bug. AFAICT there's no fundamental reason it needed to go out. If i
"Should bugs make it into Debian releases"?
> >
> > Ah, sorry, I think I misunderstood - you are literally asking if the
> > presence of a severity "serious" bug in Grub should have prevented
> > the whole 11.5 point release happening?
> >
> > I don&#
u are literally asking if the
presence of a severity "serious" bug in Grub should have prevented
the whole 11.5 point release happening?
I don't know. The only documentation I can find on the matter is
about full Debian releases and even that says the bugs would have to
be apmrked &q
resence of a severity "serious" bug in Grub should have prevented
the whole 11.5 point release happening?
I don't know. The only documentation I can find on the matter is
about full Debian releases and even that says the bugs would have to
be apmrked "release-critical" (RC) to
On Sun, Sep 11, 2022 at 09:23:17PM +0100, Tim Woodall wrote:
> Should https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1017944 have
> made it into debian 11.5? I thought serious bugs shouldn't make it into
> stable?
I'm trying to read your email charitably in the sense that yo
On Mon 12 Sep 2022 at 03:36:46 (+0100), Tim Woodall wrote:
> On Sun, 11 Sep 2022, Greg Wooledge wrote:
> > On Sun, Sep 11, 2022 at 09:23:17PM +0100, Tim Woodall wrote:
> > > Should https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1017944 have
> > > made it into debian 1
On Sun, 11 Sep 2022, Greg Wooledge wrote:
On Sun, Sep 11, 2022 at 09:23:17PM +0100, Tim Woodall wrote:
Should https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1017944 have
made it into debian 11.5? I thought serious bugs shouldn't make it into
stable?
Bugs have to be discovered and rep
On Sun, Sep 11, 2022 at 09:23:17PM +0100, Tim Woodall wrote:
> Should https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1017944 have
> made it into debian 11.5? I thought serious bugs shouldn't make it into
> stable?
Bugs have to be discovered and reported. If nobody found t
Should https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1017944 have
made it into debian 11.5? I thought serious bugs shouldn't make it into
stable?
I'm not sure this should be merely serious, it broke absolutely
everything for me and took me a while to track down.
Although the
1.3.0-5) 11.3.0, GNU
ld (GNU Binutils for Debian) 2.38.90.20220713) #1 SMP PREEMPT_DYNAMIC
Debian 5.18.16-1 (2022-08-10)
The kernel running is from backports, I assume.
Kernels from backports may function different than release packages. You
can test whether it is a kerl bug or not, with insta
On 9/10/22 19:46, Maximiliano Estudies wrote:
Hi,
I seem to have hit a bug with the wireless card driver of my laptop.
This happened twice already, my laptop became unresponsive and I
couldn't issue any sudo commands. After hard rebooting the laptop I
see this entries in the syslog:
Sep
Hi,
I seem to have hit a bug with the wireless card driver of my laptop.
This happened twice already, my laptop became unresponsive and I
couldn't issue any sudo commands. After hard rebooting the laptop I
see this entries in the syslog:
Sep 10 14:51:50 user-thinkpad kernel: mt7921e :03
On Thu, Sep 08, 2022 at 06:22:47PM -0400, José Eduardo Niño wrote:
> Hola. Soy José Niño.
Hola, José
esta lista comunica en inglés. Por consecuencia, la mayoría aquí
no podrá ayudarte.
En caso que prefieras comunicar en castellano: hay una lista en
castellano por aquí:
https://lists.debian.or
Hola. Soy José Niño.
Tengo un problema particular con el hardware de mi computadora,
específicamente con la ranura lectora de memorias SD y microSD.
Con Debian 11.0 funciona perfectamente. Pero, al actualizar con apt upgrade
comienza a fallar.
Con Debian 11.4, al insertar la memoria SD en la ranu
dress by inserting
a space after the @ in the debian-user address.
I forgot about that, clicked send, and the email actually got sent, but the
From: was shown as "Undisclosed recipients".
I don't know whether I should consider that a bug or a feature ;-) But I'll
disable e
> On Aug 30, 2022, at 1:40 PM, Nicholas Geovanis wrote:
>
> When you run check_dns by hand on Host B, you don't say who you are logged-in
> as. That can make a difference. Nagios runs its scripts in a known
> environment which may be different than you expect.
>
Thanks for the question. I
On Tue, Aug 30, 2022, 2:13 PM Casey Deccio wrote:
> Hi all,
>
> I am having trouble tracking down a bug in my monitoring setup. It all
> happened when I upgraded the monitored host (host B in my example below) to
> bullseye. Note that Host A is also running bullseye, but the p
Hi all,
I am having trouble tracking down a bug in my monitoring setup. It all
happened when I upgraded the monitored host (host B in my example below) to
bullseye. Note that Host A is also running bullseye, but the problem didn't
show itself until Host B was upgraded.
Here is the
On 05/08/2022 00:35, Mid Mes Fair wrote:
There is a big bug in auto update in debian 11.
I have turned off the auto checking feature but it still checking and
appear on the notification section in the software
ok.
--
With kindest regards, Piotr.
⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁ Debian - The universal
On Thu, Aug 4, 2022 at 7:51 PM Mid Mes Fair wrote:
> There is a big bug in auto update in debian 11.
> I have turned off the auto checking feature but it still checking and
> appear on the notification section in the software
>
We need more info. To start with:
What Desktop Environ
Richmond writes:
> This bug:
>
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=895378
>
> sky2: sky2: did not recover correctly after waking up from S3
>
> seems to be fixed on Ubuntu here:
>
> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1798921
>
&g
Hi list,
I've been having a problem with reading local email (like Cron reports
etc.) and I tracked it down to either Evolution or WebKitWebProcess.
I've opened bugs with both and have been talking with the Evolution
mailing list. Milan Crha from that list had me run some backtraces and
all he can
Hi,
Description of problem:
After suspend only one screen activates (dual screen system) and the mouse
seems to be unresponsive.
Basic System
Using AMD cards (Radeon 5600XT and 5500XTY)
My system is setup as a mult-seat system with one seat having two monitors
and the other with one monitor.
Usin
Anders Andersson (12022-05-04):
> On this note, I've always found it annoying that debian (and likely
> others) don't put /sbin in the normal user's $PATH. A lot of the tools
> there have uses other than modifying the system.
I have to unpack Zip files rather often, I use unzip in command-line. It
On Wed, May 04, 2022 at 07:04:52AM -0600, Charles Curley wrote:
> On Wed, 4 May 2022 05:23:31 +0200
> Anders Andersson wrote:
>
> > On this note, I've always found it annoying that debian (and likely
> > others) don't put /sbin in the normal user's $PATH. A lot of the tools
> > there have uses ot
On Wed, 4 May 2022 05:23:31 +0200
Anders Andersson wrote:
> On this note, I've always found it annoying that debian (and likely
> others) don't put /sbin in the normal user's $PATH. A lot of the tools
> there have uses other than modifying the system.
It can be annoying, but for good reason. In
On Wed, May 04, 2022 at 05:23:31AM +0200, Anders Andersson wrote:
[on sbin]
> On this note, I've always found it annoying that debian (and likely
> others) don't put /sbin in the normal user's $PATH. A lot of the tools
> there have uses other than modifying the system.
I've grown accustomed to t
On Mon, May 2, 2022 at 8:19 PM wrote:
> On Mon, May 02, 2022 at 07:58:12PM +0200, Michael Lange wrote:
> > On Mon, 2 May 2022 10:17:06 -0500
> > Richard Owlett wrote:
> > > I'm using Debian 10.7 with MATE DE [will be updated later this week]
> > > The machine is a Lenovo T510 and is setup to logi
On Mon, May 02, 2022 at 07:58:12PM +0200, Michael Lange wrote:
> Hi,
>
> On Mon, 2 May 2022 10:17:06 -0500
> Richard Owlett wrote:
>
> > I'm using Debian 10.7 with MATE DE [will be updated later this week]
> > The machine is a Lenovo T510 and is setup to login as either "richard"
> > or "root".
Hi,
On Mon, 2 May 2022 10:17:06 -0500
Richard Owlett wrote:
> I'm using Debian 10.7 with MATE DE [will be updated later this week]
> The machine is a Lenovo T510 and is setup to login as either "richard"
> or "root".
>
> If logged in as "richard" I can execute su {+ password} and receive a
>
on its size, it decides where it's going to write it,
> ie which block group. Only then does it create the file's inode,
> so that it can keep file contents and inode close together.
That actually makes sense. It would be surprising behaviour,
but at least whithin reach; whether it
On Mon, May 02, 2022 at 03:43:41PM +, Andrew M.A. Cater wrote:
> Not bug - feature.
I disagree. Strongly. It is a CHANGE, but it is not a feature.
> See also su -
>
> It's in the release notes, I'm fairly sure.
It's also at <https://wiki.debian.org/NewInBust
" I can execute su {+ password} and receive a prompt
> indicating I'm "root".
>
> However if I then enter "update-grub", the response is
> "bash: update-grub: command not found"
> as if I were the unprivileged user "richard".
>
Il 02/05/22 17:17, Richard Owlett ha scritto:
If logged in as "richard" I can execute su {+ password} and receive a
prompt indicating I'm "root".
"bash: update-grub: command not found"
Bug?
No, it's only an effect of the PATH variable. Try "su -".
root".
However if I then enter "update-grub", the response is
"bash: update-grub: command not found"
as if I were the unprivileged user "richard".
All is normal if I had initially been "root" or had become "root" via
System -> Log Out richard .
Bug?
ndering whether the data are transferred from the VFS to ext4
> necessarily within the same openat system call or could just be kept
> in the VFS as long as they are not needed elsewhere, i.e. the VFS
> behaving like a cache. In the latter case, since the VFS doesn't
> have a notion
On Mon, May 02, 2022 at 01:10:04AM +0200, Vincent Lefevre wrote:
> On 2022-04-30 14:06:53 +0200, to...@tuxteam.de wrote:
[...]
> > It sure looks like a bug. But it would be a bug at a spot where one would
> > expect that it should have bitten oodles of other people by now, so t
ving like a cache. In the latter case, since the VFS doesn't
> have a notion of birth timestamp (from the code I've read), a bug
> in the VFS code could explain the behavior I had observed. This is
> the only explanation I could have.
At this point, you should seriously consider
in the VFS as long as they are not needed elsewhere, i.e. the VFS
behaving like a cache. In the latter case, since the VFS doesn't
have a notion of birth timestamp (from the code I've read), a bug
in the VFS code could explain the behavior I had
On 2022-04-30 14:06:53 +0200, to...@tuxteam.de wrote:
> On Sat, Apr 30, 2022 at 10:33:34AM +0200, Thomas Schmitt wrote:
> > I understand that Vincent Lefevre suspects these discrepancies to be a bug
> > in the ext4 driver. I rather suspect that ext4 is ok and that we observe
>
Hi,
Curt wrote:
> What does the following mean, then, in that light:
> Because of delayed allocation and other performance optimizations, ext4's
> behavior of writing files to disk is different from ext3. In ext4, when a
> program writes to the file system, it is not guaranteed to be on-disk
On Sat, Apr 30, 2022 at 12:31:07PM -, Curt wrote:
> On 2022-04-30, Thomas Schmitt wrote:
> >
> > Indeed. With normal filesystem operations there should be no need to call
> > something like sync(2) in order to get a consistent representation of the
> > current filesystem state.
> >
>
> What d
On 2022-04-30, Thomas Schmitt wrote:
>
> Indeed. With normal filesystem operations there should be no need to call
> something like sync(2) in order to get a consistent representation of the
> current filesystem state.
>
What does the following mean, then, in that light:
Because of delayed allo
th via the operating
system facilities is the cache's view. The disk's view will become
consistent with that at some time in the future (at least we hope
that).
[...]
> I understand that Vincent Lefevre suspects these discrepancies to be a bug
> in the ext4 driver. I rather susp
en, write, and
close the file.
The file content indicates that it was written shortly after the script
began.
I understand that Vincent Lefevre suspects these discrepancies to be a bug
in the ext4 driver. I rather suspect that ext4 is ok and that we observe
the effects of some other glitch which cause
On Fri, Apr 29, 2022 at 09:41:23PM +0200, sp...@caiway.net wrote:
> On Fri, 29 Apr 2022 13:45:15 -0400
>
> > linux caches file system pages in memory
>
> how does one force to refresh this memory with a command?
What do you mean by "refresh"? What's in the cache is always
the "freshest" version:
On Fri, 29 Apr 2022 13:45:15 -0400
> linux caches file system pages in memory
how does one force to refresh this memory with a command?
Thanks!
On 4/29/2022 10:20 AM, duh wrote:
On 4/27/22 11:05 PM, Greg Wooledge wrote:
Having skimmed over a number of the replies, and really not being
qualified, may I just
toss out a probably useless ideas to use the "sync" command. Looking at
the 'man sync'
shows at the bottom several variant
On 4/27/22 11:05 PM, Greg Wooledge wrote:
On Wed, Apr 27, 2022 at 10:45:09PM -0400, Stefan Monnier wrote:
Another option might be that your system's time was "reset".
This shouldn't happen, but it can happen if your NTP was down, the
machine got out-of-sync over time and you restart the NTP se
of a possible hardware problem, but
they were common and unrelated. They are triggered by Wine, which is
executed by my script (as I also test MPFR under Wine).
My bug report:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1010209
(either the kernel is really doing silly things, or th
written back to the
actual FS.
When I did
tail -n 30 mpfrtests.*.out; ll mpfrtests.*.out
this had the effect to look at the entries in the current directory.
For some reason (a bug occurring under some particular conditions?),
the dirty state due to the data written above to the VFS was ignor
Hi,
Vincent Lefevre wrote:
> and one with
> openat(AT_FDCWD, "….out", O_WRONLY|O_CREAT|O_APPEND, 0666
> <... openat resumed>) = 3
> about 30 seconds later.
Oh. So the script was still running when the file finally appeared to lt,
tail, and ll ?
Is the text snippet " <... openat resumed>" l
On 2022-04-27 22:45:09 -0400, Stefan Monnier wrote:
> Another option might be that your system's time was "reset".
> This shouldn't happen, but it can happen if your NTP was down, the
> machine got out-of-sync over time and you restart the NTP server at
> which point it may(!) decide to jump the cl
On Wed, Apr 27, 2022 at 10:45:09PM -0400, Stefan Monnier wrote:
> Another option might be that your system's time was "reset".
> This shouldn't happen, but it can happen if your NTP was down, the
> machine got out-of-sync over time and you restart the NTP server at
> which point it may(!) decide to
my shell history for 6 years.
This was the first time I noticed such an issue. But if this is a
kernel bug, it may be a new bug.
> If so, you could set up a script that sometimes reproduces, and run it
> in a loop until you get the erroneous behavior.
I'll try to do that.
> Of c
On Wed, Apr 27, 2022 at 03:11:22PM +0200, Vincent Lefevre wrote:
> So, perhaps there were no issues with openat, but when reading
> the directory, the file could not be found because some internal
> structures might have been incomplete.
If so, this is a bug at the kernel level, perha
e RAM.
I was thinking of a potentially specific FS cache. But perhaps this
is not related to the CPU at all. It could be that a potential bug
(either in the kernel code or in the compiler) would affect some
system calls but not others. So, the ">> $out" done in the script
would work, bu
Hi,
Vincent Lefevre wrote:
> the issue [...] is probably unlikely to occur again.
In this case we will hardly be able to find an explanation.
> However, there's also the fact that the birth time was 30 seconds
> ahead of the actual file creation, while there was no lockup.
Yes, your observatio
ible that the file would not show up in stat(1)
> or ls(1) but the script can happily do
> ... >> "$out"
> Each of these lines is supposed to do a name lookup of the file.
unless there is some caching bug. The script is likely to run on
the same CPU core, so that the file
Hi,
i wrote:
> > So if it got created by the script, maybe it was deleted or renamed
> > shortly afterwards and created again 30 seconds later ?
Vincent Lefevre wrote:
> The script doesn't do that. The file is created with
> echo "* $fqdn ($(${1:-.}/config.guess) / ${line#PROC:})" > "$out"
> [.
On 2022-04-26 14:18:58 -0400, Stefan Monnier wrote:
> > On an ext4 filesystem, I got a file born 30 seconds after its
> > actual creation. Is this a bug?
>
> I doubt it.
> Note that a file's atime/mtime/ctime is a property of the file itself,
> whereas "appe
On 2022-04-26 12:47:53 -0500, Nicholas Geovanis wrote:
> On Tue, Apr 26, 2022 at 12:37 PM Nicholas Geovanis
> wrote:
>
> > On Tue, Apr 26, 2022 at 8:45 AM Vincent Lefevre
> > wrote:
> >
> >> On an ext4 filesystem, I got a file born 30 seconds after its
On 2022-04-26 19:01:26 +0200, Thomas Schmitt wrote:
> It looks as if the file indeed does not exist when you inquire it.
> So if it got created by the script, maybe it was deleted or renamed
> shortly afterwards and created again 30 seconds later ?
The script doesn't do that. The file is created w
On Tue, Apr 26, 2022 at 01:31:02PM +, Schwibinger Michael wrote:
>
> Good afternoon.
> Thank You
>
> We dont use WIFI.
>
> Desktops
>
> We do
> connect with cable to the WWW.
> Also mouse and keyboard is with cable.
>
OK: in many ways that makes it easier. I would still suggest the firmwa
On Tue, Apr 26, 2022 at 12:37 PM Nicholas Geovanis
wrote:
> On Tue, Apr 26, 2022 at 8:45 AM Vincent Lefevre
> wrote:
>
>> On an ext4 filesystem, I got a file born 30 seconds after its
>> actual creation. Is this a bug?
>>
>
> Only experimentation can really bac
On Tue, Apr 26, 2022 at 8:45 AM Vincent Lefevre wrote:
> On an ext4 filesystem, I got a file born 30 seconds after its
> actual creation. Is this a bug?
>
Only experimentation can really back me up on this, but consider the
following:
Every time you use the "|" operator or t
Hi,
Vincent Lefevre wrote:
> This script creates a file mpfrtests.cventin.lip.ens-lyon.fr.out
> very early. But the first attempts to look at this file failed:
It looks as if the file indeed does not exist when you inquire it.
So if it got created by the script, maybe it was deleted or renamed
sh
On Tue, 26 Apr 2022 09:32:23 -0400
Greg Wooledge wrote:
...
> Firmware is executable code that runs inside of a device (such as a
> network interface) rather than in your CPU.
>
> Many modern devices require some non-free firmware in order to perform
> their duties correctly. This is *especial
On Tue, Apr 26, 2022 at 01:41:07PM +, Schwibinger Michael wrote:
> What does mean
>
> firmware is free
> firmware is not free?
Firmware can be free OR non-free.
Firmware for wireless interfaces is ALMOST ALWAYS non-free, because of
proprietary secrets that the wireless chip manufacturer is f
: AW: AW: Here Newbie---Amateur in Linux...Problem: Debian LXDE
cannot boot.. Is it destroyed?//Second try Hotmail bug Sorry
On Mon, Apr 25, 2022 at 07:18:48PM +0100, Brian wrote:
> On Mon 25 Apr 2022 at 17:24:29 +, Andrew M.A. Cater wrote:
>
> > On Mon, Apr 25, 2022 at 06:15:40PM
---Amateur in Linux...Problem: Debian LXDE
cannot boot.. Is it destroyed?//Second try Hotmail bug Sorry
Am Montag, 25. April 2022, 12:58:48 CEST schrieb Schwibinger Michael:
Best version, if you do not want to have administration work, would be
Debian-11 (which is bullseye). You should choose "s
On an ext4 filesystem, I got a file born 30 seconds after its
actual creation. Is this a bug?
I know that such issues can be observed with NFS, but here this
is just a local ext4 filesystem.
Here are the details.
I started a shell script:
cventin:~> ps -p 667828 -o lstart,
: Debian LXDE
cannot boot.. Is it destroyed?//Second try Hotmail bug Sorry
On Tue, Apr 26, 2022 at 01:27:39PM +, Schwibinger Michael wrote:
> What is firmware?
> Do I need it?
> Is it dangerous?
Firmware is executable code that runs inside of a device (such as a
network interface) rathe
: Here Newbie---Amateur in Linux...Problem: Debian LXDE
cannot boot.. Is it destroyed?//Second try Hotmail bug Sorry
Hello Sophie,
>
>
> >
> >
> >
> > Good afternoon.
> >
> > Thank You.
> >
> > We do backup eve
401 - 500 of 1942 matches
Mail list logo
