On Fri, Mar 14, 2025 at 10:42:24PM +0100, Maximilian Engelhardt wrote:
> A fix [1] for the IO_PAGE_FAULT went into xen 4.20 which is now available in
> testing and unstable.
> The 4.20.0-1 Debian source package can also be compiled for bookworm if you
> have a bookworm system running and want to
It was suggested as a debugging step, but adding the option
"iommu=no-intremap" to Xen's command-line may work as a short-term
mitigation for #988477.
--
(\___(\___(\__ --=> 8-) EHM <=-- __/)___/)___/)
\BS (| ehem+sig...@m5p.com PGP 87145445 |)
Package: arcanist
Version: 0~git20200925-1
Severity: grave
If one has one or more commits in /some/repo one can create a
Phabricator diff by running `arc diff $oldver`. If there are are
untracked files in the directory the arcanist client gives the message:
8<
X-Debbugs-Cc: pkg-xen-de...@lists.alioth.debian.org
Guess we're finding out where everyone's update windows are. Some though
may report before resolving the issue or somewhat after.
Yet another reproducer of the issue here. I also observed the failure in
Xen's dmesg and confirm the issue occurs
On Fri, Nov 20, 2020 at 08:02:26PM +0100, Hans van Kranenburg wrote:
> So,
>
> On 9/21/20 4:16 PM, Hans van Kranenburg wrote:
> > [...]
> >
> > gcc-Wl,-z,relro -Wl,-z,now -pthread -Wl,-soname
> > -Wl,libxentoolcore.so.1 -shared -Wl,--version-script=libxentoolcore.map
> > -o libxentoolcore.so.
On Mon, Jun 15, 2020 at 10:50:35AM -0400, J. Bruce Fields wrote:
> Honestly I don't think I currently have a regression test for this so
> it's possible I could have missed something upstream. I haven't seen
> any reports, though
>
> ZFS's ACL implementation is very different from any in-tree
On Sat, Jun 13, 2020 at 02:54:31PM +0200, Salvatore Bonaccorso wrote:
> indicated this was specifically observed on ZFS on Linux only. Seth
> Arnold's answer seem to be inline with that that the issue is more on
> the ZFS on Linux side and the issue keeps biting people a bit
> unexpectedly. Why doe
Bit more experimentation on this issue.
I tried a very small C program meant to create files with fewer
permissions bits set. This succeeded which strengthens the theory of
the umask getting ignored.
I haven't seen anything hinting whether this is more a client or server
issue.
I can speculate
Control: tags 962254 +security -unreproducible
Control: severity 962254 grave
On Fri, Jun 05, 2020 at 08:36:31PM +0200, Salvatore Bonaccorso wrote:
> This now let some rings bell, the described scenario is very similar
> to what was reported in https://bugs.debian.org/934160
>
> Respectively
> ht
I've run into a problem which produces the same behavior as bug #934160,
but attributed it elsewhere due to other observations.
What are the version(s) of the Linux kernel being used on your server and
clients?
I've confirmed using a 4.9 kernel on a client instead of a 4.19 kernel
also works arou
severity 819705 critical
quit
`rm -rf` is a mighty tool, and must be wielded with extreme care.
firmware-b43-installer's use isn't too dangerous, but the fact remains
its use *must* be in *prerm* not *postrm*. A theoretical future package
which desired to replace firmware-b43-installer (something
Sorry to be the bearer of bad news, but:
$ wget
https://people.debian.org/~bartm/flashplugin-nonfree/D5C0FC14/fp.22.0.0.209.sha512.amd64.pgp.asc
--2016-08-08 16:48:41--
https://people.debian.org/~bartm/flashplugin-nonfree/D5C0FC14/fp.22.0.0.209.sha512.amd64.pgp.asc
Resolving people.debian.org (
The problem for flashplugin-nonfree is verifying the tarball that is
downloaded. Adobe isn't making this easy since they don't provide any
form of conventional signature (PGP). Thus Bart Martens had been doing
the rather unenviable job of having to approve Flash Player somehow. The
approach had
Okay now know what is going on. `update-flashplugin-nonfree --status`
retrieves the currently installed version from libflashplayer.so and
the available version by looking at adobe.com.
Meanwhile, `update-flashplugin-nonfree --install` retrieves a signature
from either
http://people.debian.org/~
The reports thus far seem to already suggest where to look for the
problem being pointed to here, notice 3 lines out of the logs provided
so far:
installed version = 11.2.202.616
upstream version = 11.2.202.621
downloading
https://fpdownload.adobe.com/get/flashplayer/pdc/11.2.202.616/install_flas
>From: Eugene V. Lyubimkin <[EMAIL PROTECTED]>
> Though, I think, severity of this bug can be downgraded (imho, to important)
> if it show itself rarely. And it's very hard to fix, yes.
No.
Have you looked at how many reports there are of the MMap problem and how
old they are?
A quick browse fou
This appears to be due to testing. Removing the binary line for it (or
rather the mirror) from /etc/apt/sources.list made this go away. Removing
any of the other repositories failed to make the problem disappear. I was
even able to produce core files (seems to suggest a bigger problem).
I must *st
Package: apt
Version: 0.6.46.4-0.1
Severity: grave
Justification: renders package unusable, conventional workaround doesn't work
Well, it's everyone's favorite bug with apt-get:
Reading package lists... Error!
E: Dynamic MMap ran out of room
E: Error occurred while processing rt73-modules-2.6.24-
Is this truely a /grave/ bug with /lilo/?
Certainly you were able to use the force option, and LILO did its job;
this is annoying but not unusable. Certainly it didn't cause data loss.
The verbose flag told you what was going on, it had incorrectly detected
the presence of an NT FS. Is there anyth
19 matches
Mail list logo
