This bug was fixed in the package gdbm - 1.14.1-2ubuntu1
---
gdbm (1.14.1-2ubuntu1) bionic; urgency=medium
* Don't build using dietlibc (universe).
-- Matthias Klose Thu, 01 Feb 2018 13:02:01 +0100
** Changed in: gdbm (Ubuntu)
Status: Triaged => Fix Released
--
You rec
This bug was fixed in the package man-db - 2.6.1-2ubuntu1
---
man-db (2.6.1-2ubuntu1) precise-proposed; urgency=low
* Avoid fatal errors when opening a 64-bit GDBM database from a 32-bit
process (LP: #1001189).
* Link with -Wl,--enable-new-dtags, so that LD_LIBRARY_PATH can be
This all seems to be behaving correctly now, with the version in
precise-proposed: man falls back as specified. (accessdb still doesn't
work, but there's no way to make it work with the old gdbm and in any
case that's a relatively minor issue.)
** Tags removed: verification-needed
** Tags added:
Hello Paul, or anyone else affected,
Accepted man-db into precise-proposed. The package will build now and be
available at http://launchpad.net/ubuntu/+source/man-db/2.6.1-2ubuntu1
in a few hours, and then in the -proposed repository.
Please help us by testing this new package. See
https://wiki.
** Branch linked: lp:~ubuntu-branches/ubuntu/precise/man-db/precise-
proposed
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1001189
Title:
'man' command fails with lseek error opening cross-architec
** Description changed:
+ [Impact] Sharing a directory containing manual page databases between 32-bit
and 64-bit systems can cause man to crash.
+ [Test Case] Configure a local manual page hierarchy (in ~/.manpath or
otherwise), containing a single page. Run mandb over it from a 64-bit
enviro
** Branch linked: lp:debian/man-db
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1001189
Title:
'man' command fails with lseek error opening cross-architecture
index.db file (on network share)
To
This bug was fixed in the package man-db - 2.6.2-1
---
man-db (2.6.2-1) unstable; urgency=low
* New upstream release:
- Optimise apropos when given many arguments (LP: #927028).
- apropos prints an error message and returns non-zero when it finds no
matches (closes: #
Mon Jun 18 04:20:41 BST 2012 Colin Watson
Avoid fatal errors when opening a 64-bit GDBM database from a 32-bit
process (Ubuntu bug #1001189).
* libdb/db_gdbm.c (trap_error): New function.
(man_gdbm_open_wrapper): Rearrange interface to call gdbm_open
Not really. I don't want man-db to be in the business of knowing what's
local vs. not, and I very much want to preserve the property of having
one database per MANDB_MAP entry. I think it would actually be much
more complicated to attempt to unwind that - for instance there'd be
interesting effec
In the long run, migrating all of the DB files to newer ones that
identify the size/swap nature is the right approach, however, I wonder
if a simpler fix for 'man' which would be useful for current systems
would be to keep everything in the in local DB (say the
/var/cache/man/index.db file or simil
** Also affects: gdbm (Ubuntu)
Importance: Undecided
Status: New
** Changed in: gdbm (Ubuntu)
Status: New => Confirmed
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1001189
Title:
> Apparently "gdbm-1.9.1 (already in Rawhide) provides different magic values
> for 32 and 64 bits, so we can
> discover what system the file was created on if we use this new version"
Yes... for example, search for the string "Is the magic number good?" in
http://git.gnu.org.ua/cgit/gdbm.git
On Sun, May 20, 2012 at 21:02:42 -, Paul Crawford wrote:
> Trying to be positive, we have a possible work-around for our own
> system (drop /packages/local/bin from $PATH) but it is not really a
> decent fix.
Another option might be to simply delete/rename the index.db file from
that director
** Summary changed:
- 'man' command fails with lseek error
+ 'man' command fails with lseek error opening cross-architecture index.db file
(on network share)
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/
Status changed to 'Confirmed' because the bug affects multiple users.
** Changed in: man-db (Ubuntu)
Status: New => Confirmed
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1001189
Title:
'ma
On Sun, May 20, 2012 at 20:07:40 -, Paul Crawford wrote:
> But trying this on a 32-bit 10.04 machine (not normally with this file
> available) I get something vaguely familiar:
>
> $ /usr/sbin/accessdb /packages/local/share/man/index.db
> gdbm fatal: read error
>
> So it seems the underlying
Trying to be positive, we have a possible work-around for our own system (drop
/packages/local/bin from $PATH) but it is not really a decent fix. The
underlying problem is difficult in that all current 32-bit and 64-bit DB files
look similar, so work on an improved libgdbm3 is going to be diffic
It seems this dumbness has been recognised since 2005 according to this
bug report, but not taken seriously:
https://bugzilla.redhat.com/show_bug.cgi?id=162416
Apparently "gdbm-1.9.1 (already in Rawhide) provides different magic
values for 32 and 64 bits, so we can discover what system the file w
If I run the accessdb command on the 32-bit 12.04 machine it core dumps:
$ /usr/sbin/accessdb /packages/local/share/man/index.db
Segmentation fault (core dumped)
Doing the same on the 64-bit 10.04 machine produces something intelligible:
$ /usr/sbin/accessdb /packages/local/share/man/index.db
$
On Sun, May 20, 2012 at 18:27:11 -, Paul Crawford wrote:
> still seems to be an issue where the 12.04 system is not handling the
> network mounted index.db file correctly, or at least, not handling
> database/format errors in any sort of elegant manner.
Okay, moving on to this question... it
On Sun, May 20, 2012 at 18:27:11 -, Paul Crawford wrote:
> The $PATH variables are different, with the 12.04 (32-bit) system having
> /packages/local/bin included in the list. If I remove that from the
> 12.04 system it then avoids the /packages/local/share/man/index.db file
> and it works.
Co
The $PATH variables are different, with the 12.04 (32-bit) system having
/packages/local/bin included in the list. If I remove that from the
12.04 system it then avoids the /packages/local/share/man/index.db file
and it works.
However, if I add /packages/local/bin to the 10.04 system (64-bit, in
c
On Sun, May 20, 2012 at 16:47:21 -, Paul Crawford wrote:
> One thing I noticed that is different is $PATH but I expected that to be
> the search order for programs, not for mand pages and/or index.db files!
Actually, I see that man-db does do some mapping between $PATH and the
man-page directo
One thing I noticed that is different is $PATH but I expected that to be
the search order for programs, not for mand pages and/or index.db files!
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1001189
> As far as the first question: Does "/packages/local/share/man/" get opened
> and/or stat-ed in the strace when you run "man" on the Lucid box and from
> other accounts on the Precise box?
It seems not.
> Is $MANPATH set differently in the different accounts?
There is no $MANPATH variable set o
On Sat, May 19, 2012 at 13:15:48 -, Paul Crawford wrote:
> Actually it is slightly more bizarre, that NIS account (opr) is braking
> 'man' but another NIS account on the 12.04 machine is OK, while opr (and
> others) accounts are all OK on my 10.04 box, so maybe there is some
> environment value
There is no $HOME/.manpath file in any of the NIS accounts I have tried, or for
the local user accounts on my 10.04 box either.
Actually it is slightly more bizarre, that NIS account (opr) is braking 'man'
but another NIS account on the 12.04 machine is OK, while opr (and others)
accounts are al
Running it with strace produced this near the end:
open("/packages/local/share/man/index.db", O_RDONLY) = 3
fstat64(3, {st_mode=S_IFREG|0644, st_size=3208201, ...}) = 0
fcntl64(3, F_SETLK, {type=F_RDLCK, whence=SEEK_SET, start=0, len=0}) = 0
read(3,
"\316\232W\23\0\0\20\0\0\0\20\0\0\0\0\0\0\0\20\
I'm not particularly familiar with the inner workings of man-db, but as
far as I can see both versions of man-db use "libgdbm3 >= 1.8.3", so I
wouldn't expect there to be a .db-file format change between Lucid and
Precise, off hand. But it does seem like "extra" man files are in play,
somehow...
Given those files are readable, could it be some file format change
between the working-on-NIS version with 10.04 (2.5.7-2ubuntu1) and the
problem version of 12.04 (2.6.1-2), say if it is seeing extra man files
via the NIS/automount environment?
--
You received this bug notification because you a
The id command shows:
$ id
uid=xxx05(opr) gid=xxx00(local)
groups=xxx00(local),4(adm),20(dialout),109(lpadmin),501(operadores),502(vboxuser),xxx03(hrpt),xxx04(dosgroup),xxx07(vboxsf)
(with xxx replacing various numeric values that our sysadmin don't want
on a public forum)
The copy works withou
Similarly, do you get an error message if you say "cp
/var/cache/man/index.db /dev/null" (as the NIS user) ? (This just
checks to see if that user has read access to the man index database
file.)
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed t
When you are logged in as an NIS user, what does the "id" command show?
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1001189
Title:
'man' command fails with lseek error
To manage notifications abo
Just to add that 'man' works fine on 10.04 LTS using NIS user accounts,
so I am guessing it is something that has changed with 12.04 file
locations/permissions, and/or the NIS package for 12.04
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to U
Thanks for the package identification, result is:
$ apt-cache policy man-db
man-db:
Installed: 2.6.1-2
Candidate: 2.6.1-2
Version table:
*** 2.6.1-2 0
500 http://gb.archive.ubuntu.com/ubuntu/ precise/main i386 Packages
100 /var/lib/dpkg/status
It seems to be a permissions i
** Package changed: ubuntu => man-db (Ubuntu)
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1001189
Title:
'man' command fails with lseek error
To manage notifications about this bug go to:
https:/
37 matches
Mail list logo
