t.
And that is still 88. Okay, thank you for explaining, I learned
something today :)
Am Sa., 4. Sept. 2021 um 15:02 Uhr schrieb Anssi Saari :
>
> "Daniel M." writes:
>
> > The debian package tracker (https://tracker.debian.org/pkg/firefox)
> > states that version 9
To my understanding, unstable has 91.0.1-1 and experimental has
91.0.1-2 as seen in https://tracker.debian.org/pkg/firefox.
Hi everyone,
I'm running debian testing ("bookworm" at the moment) and have firefox
88 installed from unstable. My sources.list contains testing and
unstable main, contrib and non-free lines and I have pinning set up to
900 testing, 500 unstable. Default-Release is set to "testing".
The debian pa
Huh. I wonder how it got that way in the first place, then.
Thanks, that fixed it.
Daniel
On Thu, Jul 11, 2013 at 1:10 PM, Dan Ritter wrote:
> On Thu, Jul 11, 2013 at 12:44:24PM -0400, Daniel M. Drucker wrote:
> > When I run apt-get update, I get:
> >
> > W: Fai
/debian/ squeeze-updates main
deb http://backports.debian.org/debian-backports squeeze-backports main
I have tried running apt-get clean and autoremove; no change.
--
Daniel M. Drucker, Ph.D.
d...@3e.org
At risk of being shot at at sunrise, I had rekall working without any problems
in Gentoo a few days back. Does the following help you at all?
I don't think it is going to help - all the required dependencies are seemed to
be fully met, but nontheless the problem still exists.
Maybe gdb backtrace
A month ago, I found a .deb for Rekall, version 2.2.0-beta4-2.
I can't seem to find the package again, but the maintainer listed
through apt-cache show is:
Maintainer: Edgar Jasper < develop at edgar dot org dot uk >
I can't say much about the program because I haven't used it
extensively. Hopefu
Hello everybody,
I successfully compiled and instaled rekall 2.2.1 on Debian unstable (rekall is
a database front-end, similar to Microsoft's Access, see
http://www.rekallrevealed.org/), but the program is virtually unusable, since
it crashes with a segfault every couple of minutes when you try to
Hello everybody,
I have the following lines in ~/.bash_prompt (for all users):
--
# set prompt and window title (if running in X terminal)
case $TERM in
xterm*)
PS1="\[\033]0;\$\w/\007\]\$\w/: "
;;
>I didn't see it yesterday, but it seems that is is always the write bit
>that does not get set properly. The umask values that work are only
>those that do /not/ allow writing to all files.
>
>Is it possible that the files have been marked "read-only" in Windows
>and that mount respects that sett
>VFAT doesn't support unix-style file permissions. What you're seeing
>is a unix-style system trying to do the best it can on a crappy
>filesystem. It won't get any better than what you've got.
I know all that, but *why* permissions on some files cannot be set properly -
that is my initial quest
Hello everybody,
According to the man page for 'mount', 'umask=value' is used as follows:
"umask=value
Set the umask (the bitmask of the permissions that are not
present). The default is the umask of the current process. The
value is given in oc
Hi all,
I am getting the strangest behavior from apt-get install. It yields
the following message:
dpkg: /build/buildd/dpkg-1.8.3.1/main/packages.c:191: process_queue:
Assertion `dependtry <= 4' failed.
One of those times I was also given instructions to try
dpkg --configure -a
but it yie
13 matches
Mail list logo
