Hi

Re: iconv

On 2/1/06, Thorsten Glaser <tg@...> wrote:
> Benny,
> Du bist ja gar nicht mehr da... wie soll man da
> wichtige Fragen klären...

Von daher mal schöne Grüsse aus Paris :)

> Was aber wichtig ist: soll ich libcitrus_iconv als libiconv
> installieren und in iconv.port.mk ein ICONV_TYPE setzen,
> was auf 'any' defaultet (matcht gnu libiconv / glibc, wenn
> vorhanden (mac?) und bsd libiconv), wo es auch noch 'base'
> (wie any), 'gnu' (matcht nicht bsd libiconv) und 'port'
> (forciert den port) gibt.

Hmm, gibt es Probleme, wenn man einen Teilk der Ports gegen die eine
und einen Teil gegen die andere baut?

Klingt prinzipiell aber mal nicht schlecht. Wie kommst du jetzt
plötzlich auf citrus? Ich dachte die wären evil ...

> Ja, sie sind 100% kompatibel. Nur mit irssi soll es angeblich
> Probleme geben, aber das liegt wohl an fehlenden charset
> aliases bei TNF.

OK, ich teste, sobald ich Zeit habe.

--Benny.

Re: [Lynx-dev] UTF-8 Japanese working, but display problems

On Tue, 31 Jan 2006, Thorsten Glaser wrote:

> Hi,
>
> as of Commit ID 10043DFBA8C7D31CD9C, MirOS BSD has a BSD licenced
> libiconv (from Citrus, stolen from NetBSD ;) in the base system,
> and Lynx happily uses it to display the Google Japan homepage...
> except for certain display problems.
>
> Probably due to us using ncurses? Would having wcslen() and
> wcswidth() implementations (which we currently don't, but YET)
> help to fix that problem?

probably - ncurses doesn't have a way to compensate for that lack,
and you couldn't build ncursesw without those functions.

--

-- 
Thomas E. Dickey
http://invisible-island.net
ftp://invisible-island.net

Re: [Lynx-dev] UTF-8 Japanese working, but display problems

Thomas Dickey dixit:

[ wcslen / wcswidth ]

> probably - ncurses doesn't have a way to compensate for that lack,
> and you couldn't build ncursesw without those functions.

Okay, thanks. I want to use these from Bruno Haible's libutf8,
which is GPL'd but he has promised (verbally) that we can use
it under BSD licence so it can be made part of libc. I need to
prod him again to give us the confirmation in writing...

Do you think there's more to do than "just" wchar functions?

tg <at> odem:/home/tg $ tic -V 
ncurses 5.2.20010224

bye,
//mirabile
--

-- 
I believe no one can invent an algorithm. One just happens to hit upon it
when God enlightens him. Or only God invents algorithms, we merely copy them.
If you don't believe in God, just consider God as Nature if you won't deny
existence.		-- Coywolf Qi Hunt

Re: Hi

MySHOP dixit:

> I am OpenBSD user. I know how to build openbsd code to openbsd system.
>
> But I do not know how to add more package  ( example ports tree in /usr/ports )

Hello,

if you're using OpenBSD the MirOS project is not normally the
correct place to ask such a question, but I'll point you to:

http://www.openbsd.org/faq/index.html

Especially chapter 15 should be of interest to you.

If you have any further questions, please direct them to the
OpenBSD newbies mailing list or misc@... or, for more
advanced questions, ports@... instead.

Good luck!
//mirabile
--

-- 
I believe no one can invent an algorithm. One just happens to hit upon it
when God enlightens him. Or only God invents algorithms, we merely copy them.
If you don't believe in God, just consider God as Nature if you won't deny
existence.		-- Coywolf Qi Hunt

Re: iconv

Benny Siegert dixit:

>Hmm, gibt es Probleme, wenn man einen Teilk der Ports gegen die eine
>und einen Teil gegen die andere baut?

Nein. Es gibt nur Probleme, wenn Du beide reinlinkst, aber ich
denke, das wird Dir ld schon sagen.

Wobei, nicht mal. "Unsere" libiconv hat alle externen Symbole
weak, das heißt, in so einem Fall wird die GNU verwendet, und
es gibt keinen Konflikt.

Ich hab' gerade noch 'ne Idee. Ich mache alle nicht publiken
Symbole 'hidden' (ELF visibility), wie die glibcxx Leute.

>Klingt prinzipiell aber mal nicht schlecht. Wie kommst du jetzt
>plötzlich auf citrus? Ich dachte die wären evil ...

Die Internationalisierung von denen ist evil, aber davon das
iconv (und genug vom base-i18n Zeug) rausreißen geht. Das
hatte ich eh von Anfang an vor.

Gruß,
//mirabile
--

-- 
I believe no one can invent an algorithm. One just happens to hit upon it
when God enlightens him. Or only God invents algorithms, we merely copy them.
If you don't believe in God, just consider God as Nature if you won't deny
existence.		-- Coywolf Qi Hunt

Re: CVS: herc.66h.42h.de: src

Thorsten Glaser dixit:

>Commit ID:	10043E0C82F27B079A6
>Log message:
>Install as libiconv.{a,so.4.4} because it's compatible with GNU libiconv,
>the functions are weak, and the internal functions are namespace'd with
>_citrus. For everything else, add a symbol versioning script which doesn't
>really version, just set visibility (global/local) of symbols.

Forgot to mention: agreed by bsiegert <at> 

//mirabile
--

-- 
I believe no one can invent an algorithm. One just happens to hit upon it
when God enlightens him. Or only God invents algorithms, we merely copy them.
If you don't believe in God, just consider God as Nature if you won't deny
existence.		-- Coywolf Qi Hunt

Re: CVS: herc.66h.42h.de: ports

Thorsten Glaser dixit:

>Commit ID:	10043E0EE085FAE1F2C
[...]
>Add instructions to point symbolic links, for upgraders (on Darwin
>and MirOS, recommend links to the base system libraries instead).

gaim is verified to work with the MirOS base libiconv.

//mirabile
--

-- 
I believe no one can invent an algorithm. One just happens to hit upon it
when God enlightens him. Or only God invents algorithms, we merely copy them.
If you don't believe in God, just consider God as Nature if you won't deny
existence.		-- Coywolf Qi Hunt

BUG in pkg_upgrade

Dependencies changed:

[...]
===>  Upgrading for flac-1.1.2-1
/usr/mpkg/sbin/pkg_upgrade -a /usr/ports/Packages/flac-1.1.2-1.cgz
pkg_upgrade: will remove flac-1.1.2-0 in favour of flac-1.1.2-1.cgz
===>  Cleaning for flac-1.1.2-1
[...]

tg <at> odem:/home/tg $ fgrep flac /usr/mpkg/db/pkg/libiconv-1.9.1-3/+REQUIRED_BY
flac-1.1.2-0
flac-1.1.2-0

tg <at> odem:/home/tg $ gzip -dc /usr/ports/Packages/flac-1.1.2-1.cgz | grep -a  <at> ...depend
 <at> libdepend flac-1.1.2-1:ogg.0.5:libogg-*:libogg-1.1.3-0

tg <at> odem:/home/tg $ gzip -dc /usr/ports/Packages/flac-1.1.2-0.cgz | grep -a  <at> ...depend 
 <at> libdepend flac-1.1.2-0:iconv.2.2:libiconv-*:libiconv-1.9.1-2
 <at> libdepend flac-1.1.2-0:ogg.0.5:libogg-*:libogg-1.1.3-0
 <at> newdepend flac-1.1.2-0:libiconv-*:libiconv-1.9.1-2

bye,
//mirabile
--

-- 
I believe no one can invent an algorithm. One just happens to hit upon it
when God enlightens him. Or only God invents algorithms, we merely copy them.
If you don't believe in God, just consider God as Nature if you won't deny
existence.		-- Coywolf Qi Hunt

root and non-root (MirPorts)

I've had trouble with php's pear subpackage, which installs
into /var/www, thus I had sudo pkg_add'd it (with one built
for AS_USER).

tg <at> odem:/home/tg $ pkg_delete php-pear 
pkg_delete(php-pear): unable to completely remove directory '/var/www/pear'
pkg_delete(php-pear): couldn't entirely delete package (perhaps the packing list is
incorrectly specified?)
override rwxr-xr-x  root/tg for /usr/mpkg/db/pkg/php-pear-5.0.5-0? y
override rw-r--r--  root/tg for /usr/mpkg/db/pkg/php-pear-5.0.5-0/+CONTENTS? y
rm: /usr/mpkg/db/pkg/php-pear-5.0.5-0/+CONTENTS: Permission denied
rm: /usr/mpkg/db/pkg/php-pear-5.0.5-0/+DESC: Permission denied
rm: /usr/mpkg/db/pkg/php-pear-5.0.5-0/+COMMENT: Permission denied
rm: /usr/mpkg/db/pkg/php-pear-5.0.5-0: Directory not empty
pkg_delete(php-pear): couldn't remove log entry in /usr/mpkg/db/pkg/php-pear-5.0.5-0, deinstall failed
tg <at> odem:/home/tg $ rm -rf /usr/mpkg/db/pkg/php-pear-5.0.5-0
rm: /usr/mpkg/db/pkg/php-pear-5.0.5-0/+CONTENTS: Permission denied
rm: /usr/mpkg/db/pkg/php-pear-5.0.5-0/+DESC: Permission denied
rm: /usr/mpkg/db/pkg/php-pear-5.0.5-0/+COMMENT: Permission denied
rm: /usr/mpkg/db/pkg/php-pear-5.0.5-0: Directory not empty
tg <at> odem:/home/tg $ sudo rm -rf /usr/mpkg/db/pkg/php-pear-5.0.5-0

That's understandable (we should do something to prevent the
installation/deinstallation of such packages as non-root, though.
PREFER_INSTALL_SUBPKGS still defaults to yes).

But now it comes:

tg <at> odem:/home/tg $ pkg_delete php-core 
pkg_delete(php-core): package 'php-core-5.0.5-0' is required by these other packages
and may not be deinstalled:
php-pear-5.0.5-0
tg <at> odem:/home/tg $ pkg_delete -f php-core
pkg_delete(php-core): package 'php-core-5.0.5-0' is required by these other packages
and may not be deinstalled (but I'll delete it anyway):
php-pear-5.0.5-0
pkg_delete(php-core): attempting to delete non-existent directory '/usr/mpkg/lib/php/modules'
this packing list is incorrect - ignoring delete request
override rw-r--r--  root/tg for /usr/mpkg/db/pkg/php-core-5.0.5-0/+REQUIRED_BY? y

The errors:
- I had deinstalled php-pear
- "attempting to delete..." - the  <at> exec bug assigned to bsiegert <at> 
- override...

On the "override" thing: we should implement a privdrop in pkg_add
so that, if called by sudo but compiled for AS_USER, it only writes
the files outside of the packaging database as root (they are still
owned by $BINOWN btw) and accesses the database as regular user. It
also should add something like  <at> option needroot to +CONTENTS so that
pkg_delete as regular user will exit immediately, too.

bye,
//mirabile
--

-- 
I believe no one can invent an algorithm. One just happens to hit upon it
when God enlightens him. Or only God invents algorithms, we merely copy them.
If you don't believe in God, just consider God as Nature if you won't deny
existence.		-- Coywolf Qi Hunt