Re: Checklist for Package Sponsors

[Petter Reinholdtsen]

Great to have a checklist to help me with my sponsoring.  Thanks for
creating it. :)

Seemed mostly sensible, except for this:

[Don Armstrong]
>   Make sure that the package can be distributed by Debian
[...]
>  * Are there significant patents which the work infringes which are known
>to be enforced?

I'm not going to do this.  Knowing what is patented make you more
liable to punishment if you use a patent without a license than doing
it by accident without knowing it, so it do not make sense to keep
track of what the horribly broken patent systems around the world
decide to grant software patents for.

Perhaps the item should be adjusted?

Happy hacking,
-- 
Petter Reinholdtsen


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Debian on the Desktop - plans for Lenny?

[Wouter Verhelst]

On Fri, Aug 10, 2007 at 05:11:07AM +0100, Matthew Garrett wrote:
> Ben Hutchings <[EMAIL PROTECTED]> wrote:
> > This means that when draining the battery we do not allow the CPU to run
> > at full speed, so CPU-bound tasks take longer.  This tends to extend
> > battery life but reduces the processing work derived from the battery,
> > since other components then take a higher share of power.  And when
> > running on AC, we just waste power, though with a slight performance
> > gain.
> 
> If you're using the computer at all, it's not even likely to increase 
> battery life. A CPU at 600MHz and in C0 will draw significantly more 
> power than a CPU at 1.2GHz but in C4. It's more important to finish 
> whatever the CPU is doing quickly than it is to keep it at a low speed.

Except that a PowerPC processor (as found in Gustavo's ibook) simply
doesn't *have* C states. On my PowerBook G4, I noticed that when I
started running this crude hack[0]...

--
#!/bin/bash

modprobe cpufreq_userspace
echo $$ > /var/run/mycpufreqd
echo userspace > /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor
while true
do
if expr $(uptime|cut -d',' -f3|cut -d':' -f2) '>' 0.75 > /dev/null
then
echo 133 > 
/sys/devices/system/cpu/cpu0/cpufreq/scaling_setspeed
else
if expr $(uptime | cut -d',' -f4) '<' 0.75 > /dev/null
then
echo 66 > 
/sys/devices/system/cpu/cpu0/cpufreq/scaling_setspeed
fi
fi
sleep 10
done
--

... battery life would double[1]. A PowerPC running at its full
speed produces a *lot* more heat, which it needs to get rid of. When I
run the above script, my PowerBook is capable of running with its fan
shut off when idle, but not when running at high speed with a busy
CPU...

Moral: power management is an architecture-specific business.

[0] Yes, I should probably patch it to use /proc/loadavg rather than
uptime. Whatever.
[1] Approximately, that is. Not like I used a timer or anything.

-- 
 Home is where you have to wash the dishes.
  -- #debian-devel, Freenode, 2004-09-22


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Considerations for 'xmms' removal from Debian

[Andre Offringa]

David Lopez Zajara (Er_Maqui  darkbolt.net> writes:

> ..
> I doesn't have more for this, but a comment:
> 
> I've read on this thread, on a critical for audacious "as xmms
> replacement", I've pointed who audacious doesn't have many features
> present on xmms.

Hello everyone,

I'm a regular Debian user, and I have followed this rather intense discussion
about the removal of Xmms, and like to add two things:

First of all, I think Audacious is really good and mature enough to replace
Xmms. I have been using Xmms until some weeks ago, when I first read this
discussion. Then I gave Audacious a try, and I like it even better then Xmms,
and I think I am rather picky. I use Debian testing, and I think all stories
about millions of huge bugs in Audacious are exaggerated. Audacious looks much
better (partly because it uses the newer gtk I think), text is much better
readable and from what I see it is at least evenly configurable. It also has
quite some plugins available.

Second, from my point of view, Xmms is unmaintained upstream. There's no active
community that is improving Xmms, the site is rather dead and the previous
mentioned list of 'future improvements' has not been updated for at least three
years, see http://web.archive.org/web/*/http://www.xmms.org/next_version.php .
Periodically, something does change, but it cannot be considered as maintaining
IMHO.

So what I'm saying; I would understand the removal of Xmms.

Regards,
Andre Offringa


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Debian on the Desktop - plans for Lenny?

[Petter Reinholdtsen]

[Wouter Verhelst]
> Except that a PowerPC processor (as found in Gustavo's ibook) simply
> doesn't *have* C states. On my PowerBook G4, I noticed that when I
> started running this crude hack[0]...
>
> --
> #!/bin/bash
>
> modprobe cpufreq_userspace
> echo $$ > /var/run/mycpufreqd
> echo userspace > /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor

I suspect you will get almost the same behavior by using this hack and
leaving it to the kernel to scale it:

  #!/bin/bash
 
  modprobe cpufreq_userspace
  echo $$ > /var/run/mycpufreqd
  echo ondemand > /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor

It will jump to the highest frequency when the load is high, and drop
to the lowest frequency when there is less load.

See for example
http://www.mjmwired.net/kernel/Documentation/cpu-freq/governors.txt >
for documentation on the various governors.

Happy hacking,
-- 
Petter Reinholdtsen


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#437261: ITP: perlconsole -- interactive Perl code interpreter

[Alexis Sukrieh]

Package: wnpp
Severity: wishlist
Owner: Alexis Sukrieh <[EMAIL PROTECTED]>


* Package name: perlconsole
  Version : 0.1
  Upstream Author : Alexis Sukrieh <[EMAIL PROTECTED]>
* URL : http://www.sukria.net/perlconsole.html
* License : GPL
  Programming Lang: Perl
  Description : interactive Perl code interpreter

Perl Console is an interactive Perl code evaluator designed to help
Perl developers testing their code or their module.
.
It uses readline for grabbing the user's input and provides completion
with all the Perl keywords available in the namespace of the session.
.
Users can load any module they like in the session and use exported functions
in the console.

-- System Information:
Debian Release: 4.0
  APT prefers stable
  APT policy: (500, 'stable')
Architecture: i386 (i686)
Shell:  /bin/sh linked to /bin/bash
Kernel: Linux 2.6.16-2-vserver-k7
Locale: LANG=fr_FR, LC_CTYPE=fr_FR (charmap=ISO-8859-1) (ignored: LC_ALL set to 
fr_FR)


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: adduser/deluser on postinst

[Marc Haber]

On Tue, 7 Aug 2007 23:57:23 +0200, Javier Fernández-Sanguino Peña
<[EMAIL PROTECTED]> wrote:
>I think that we should standarise user creation/deletion in maintainer
>scripts.

Yes. The tool for doing so is adduser.

>For some code examples which do work (and are used in several
>packages) see:
>
>http://www.debian.org/doc/manuals/securing-debian-howto/ch9.en.html#s-bpp-lower-privs

Why does this HOWTO suggest replicating code that is already in
adduser (or should be there) in gazillion of maintainer scripts, which
surely introduces a maintenance nightmare?

Greetings
Marc

-- 
-- !! No courtesy copies, please !! -
Marc Haber |   " Questions are the | Mailadresse im Header
Mannheim, Germany  | Beginning of Wisdom " | http://www.zugschlus.de/
Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 621 72739834

wireless-tools marked non-for-us on S390, blocking other packages from entering testing

[Guus Sliepen]

Hello,

Several people have emailed me that their packages, which depend on
wireless-tools, can't enter testing because wireless-tools is
out-of-date on S390. It appears that at some point, the wireless-tools
package was marked not-for-us on S390. Newer versions have been uploaded
since then, but since the S390 autobuilders did not build them, and an
older S390 package was still in the archive, the new versions are not
being considered to move to testing.

Now, the S390 architecture may be different enough from other
architectures that it does not have the ability to connect a wireless
network card to. I can see why you would want to block wireless-tools
from being autobuilt on S390 then. But if you follow the reverse
dependencies of the wireless-tools and libiw29 packages, you see that
blocking these packages means that you end up making KDE and GNOME
uninstallable.

The wireless-tools packages are very small, and have in the past been
autobuilt for S390 without any problems. Please choose whether you want
to include wireless-tools on S390, even if the only functionality on
S390 would be to say "no, this interface has no wireless capabilities",
or to exclude wireless-tools on S390, and consequently want to deal with
the rather large problem of reverse dependencies.

-- 
Met vriendelijke groet / with kind regards,
  Guus Sliepen <[EMAIL PROTECTED]>


signature.asc
Description: Digital signature

Re: Seeking new maintainer(s) for HPLIP and amavisd-new

[Daniel Baumann]

Henrique de Moraes Holschuh wrote:
> But what about HPLIP?  No volunteers for it? 

i do have a lot of various models using hplip.. but i'm not actually in
search for new packages.. what about torsten, doesn't he want to take over?

-- 
Address:Daniel Baumann, Burgunderstrasse 3, CH-4562 Biberist
Email:  [EMAIL PROTECTED]
Internet:   http://people.panthera-systems.net/~daniel-baumann/


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Seeking new maintainer(s) for HPLIP and amavisd-new

[Henrique de Moraes Holschuh]

On Sat, 11 Aug 2007, Daniel Baumann wrote:
> Henrique de Moraes Holschuh wrote:
> > But what about HPLIP?  No volunteers for it? 
> 
> i do have a lot of various models using hplip.. but i'm not actually in
> search for new packages.. what about torsten, doesn't he want to take over?

I wouldn't mind if he did, but it has been a LONG time since I heard from
Torsten anything about hplip...

-- 
  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique Holschuh


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: UTF-8 man pages

[Roger Leigh]

David Given <[EMAIL PROTECTED]> writes:

> I'm trying to package a simple tool that wants a Japanese string in its man
> page. It would appear that currently, man pages use fixed encodings that vary
> depending on which locale's man page is being looked up; English uses
> ISO-8859-1, so it's not possible to use kanji in one.
>
> Various people on -mentors suggested that this was wrong as there was a plan
> in place to convert to using UTF-8 throughout, and that I should bring this up
> here; I can't find any references to such a plan on the 'net --- is there one?
> What's its status? And what should I do to get my man page working?

Unless things have changed recently, groff is still fixed to using
8-bit encodings.  Until it can actually process UTF-8 input, using
UTF-8 encoding would (IMO) create more problems than it solves.

I would personally like to see this happen, but until it does we are
limited (I believe) to the glyphs described in groff_char(7).  I am
not aware of any Japanese support at all except in specially-patched
versions.


Regards,
Roger

-- 
  .''`.  Roger Leigh
 : :' :  Debian GNU/Linux http://people.debian.org/~rleigh/
 `. `'   Printing on GNU/Linux?   http://gutenprint.sourceforge.net/
   `-GPG Public Key: 0x25BFB848   Please GPG sign your mail.


pgpamaZT06IUj.pgp
Description: PGP signature

Re: UTF-8 man pages

[David Given]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Roger Leigh wrote:
[...]
> I would personally like to see this happen, but until it does we are
> limited (I believe) to the glyphs described in groff_char(7).  I am
> not aware of any Japanese support at all except in specially-patched
> versions.

I do know that Debian uses EUC-JP encoded man pages if you're in the Japanese
locale, so multibyte support does work (install man-db and do:

  man -l /usr/share/man/ja/man1/manpath.1.gz

), but that doesn't help me much in my English locale.

- --
┌── ｄｇ＠ｃｏｗｌａｒｋ．ｃｏｍ ─── http://www.cowlark.com ───
│
│ "There does not now, nor will there ever, exist a programming language in
│ which it is the least bit hard to write bad programs." --- Flon's Axiom
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFGve2df9E0noFvlzgRAgZkAKCX5G1VEBhExnOaCnK3rY/6ugdUtwCgoSl1
OuDvvxdikIQYB73G2dD+hXc=
=+Ht0
-END PGP SIGNATURE-

Re: Checklist for Package Sponsors

[Don Armstrong]

On Sat, 11 Aug 2007, Petter Reinholdtsen wrote:
> [Don Armstrong]
> >   Make sure that the package can be distributed by Debian
> [...]
> >  * Are there significant patents which the work infringes which are 
> > known
> >to be enforced?
> 
> I'm not going to do this.  Knowing what is patented make you more
> liable to punishment if you use a patent without a license than doing
> it by accident without knowing it, so it do not make sense to keep
> track of what the horribly broken patent systems around the world
> decide to grant software patents for.

It just makes you liable for treble damages instead of normal damages
in the US, at least.

That said, note that it says "are known to be enforced". If there are
press releases about enforcing specific patents, we should avoid
knowingly distributing software that infringes them. It's not asking
for developers to search the patent databases in all countries that
Debian is distributed looking for patents.


Don Armstrong

-- 
One day I put instant coffee in my microwave oven and almost went back
in time.
 -- Steven Wright

http://www.donarmstrong.com  http://rzlab.ucr.edu


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#437316: ITP: opencbm -- Utilities for communicating with Commodore IEC serial bus devices

[Frédéric Brière]

Package: wnpp
Severity: wishlist
Owner: "Frédéric Brière" <[EMAIL PROTECTED]>

* Package name: opencbm
  Version : 0.4.0
  Upstream Author : Spiro Trikaliotis <[EMAIL PROTECTED]>
Michael Klein <[EMAIL PROTECTED]>
(and others)
* URL : 
* License : GPL
  Programming Lang: C
  Description : Utilities for communicating with Commodore IEC serial bus 
devices

Taken from the blurb I just wrote as description for the main package
(the source package also produces lib, -dev and -source packages):

 OpenCBM is a collection of utilities, a library and a kernel driver that
 allows for communicating with and controlling devices via the Commodore
 (CBM) IEC serial bus.  This bus was used by such computers as the Commodore
 VIC-20 and the Commodore 64 for connecting disk drives and printers through
 a round 6-pin DIN connector.
 .
 This package provides a generic utility for controlling serial devices
 (cbmctrl), as well as others to perform specific tasks such as formatting
 a floppy or copying a file to/from a disk drive.


-- System Information:
Debian Release: lenny/sid
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: i386 (i686)

Kernel: Linux 2.6.21-2-k7 (SMP w/1 CPU core)
Locale: LANG=en_CA.UTF-8, LC_CTYPE=en_CA.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Re: Debian on the Desktop - plans for Lenny?

[Wouter Verhelst]

On Sat, Aug 11, 2007 at 01:07:39PM +0200, Petter Reinholdtsen wrote:
> 
> [Wouter Verhelst]
> > Except that a PowerPC processor (as found in Gustavo's ibook) simply
> > doesn't *have* C states. On my PowerBook G4, I noticed that when I
> > started running this crude hack[0]...
> >
> > --
> > #!/bin/bash
> >
> > modprobe cpufreq_userspace
> > echo $$ > /var/run/mycpufreqd
> > echo userspace > /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor
> 
> I suspect you will get almost the same behavior by using this hack and
> leaving it to the kernel to scale it:
> 
>   #!/bin/bash
>  
>   modprobe cpufreq_userspace
>   echo $$ > /var/run/mycpufreqd
>   echo ondemand > /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor
> 
> It will jump to the highest frequency when the load is high, and drop
> to the lowest frequency when there is less load.

Except that the kernel refuses to do this on PowerPC, since the
'ondemand' governor wants a CPU to switch speed so ridiculously quickly.

Been there, tried that.

Anyway, the point wasn't to demonstrate how to do processor speed
scaling; rather, the point was to demonstrate that what happens to be
correct for i386 and family isn't necessarily correct for everything
else.

-- 
 Home is where you have to wash the dishes.
  -- #debian-devel, Freenode, 2004-09-22


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#437350: ITP: hunspell-ar -- Arabic dictionary for hunspell

[Mohammed Sameer]

Package: wnpp
Severity: wishlist
Owner: Mohammed Sameer <[EMAIL PROTECTED]>

* Package name: hunspell-ar
  Version : beta1
  Upstream Author : Mohamed Kebdani <[EMAIL PROTECTED]>
* URL : http://perso.menara.ma/~kebdani/ayaspell-dic/
* License : (GPL, LGPL, MPL)
  Programming Lang: N/A
  Description : Arabic dictionary for hunspell

 Arabic dictionary for hunspell. This is the dictionary files by the 
ayaspell-dic project. 

-- System Information:
Debian Release: lenny/sid
  APT prefers testing
  APT policy: (500, 'testing'), (50, 'unstable'), (1, 'experimental')
Architecture: i386 (i686)

Kernel: Linux 2.6.18-4-486
Locale: LANG=en_US, LC_CTYPE=en_US (charmap=ISO-8859-1)
Shell: /bin/sh linked to /bin/bash

-- 
GPG-Key: 0xA3FD0DF7 - 9F73 032E EAC9 F7AD 951F  280E CB66 8E29 A3FD 0DF7
Debian User and Developer.
Homepage: www.foolab.org


signature.asc
Description: Digital signature

Re: Considerations for 'xmms' removal from Debian

[Josselin Mouette]

Le samedi 11 août 2007 à 12:25 +0900, Charles Plessy a écrit :
> Le Fri, Aug 10, 2007 at 04:00:18PM +0200, Josselin Mouette a écrit :
> > 
> > As you don't seem to have understood at all, let me repeat it: XMMS is
> > unmaintained.
> 
> Dear Josselin,
> 
> why do you write this while it has been said the contrary and that
> visiting www.xmms.org strongly supports the fact that it is not
> abandonned?

I don't want to play on words, but I won't call a software that hasn't
been updated to the new GTK+ API after more than five years
"maintained".

-- 
 .''`.
: :' :  We are debian.org. Lower your prices, surrender your code.
`. `'   We will add your hardware and software distinctiveness to
  `-our own. Resistance is futile.


signature.asc
Description: Ceci est une partie de message	numériquement signée

Re: Considerations for 'xmms' removal from Debian

[Josselin Mouette]

Le samedi 11 août 2007 à 06:57 +0200, David Lopez Zajara (Er_Maqui) a
écrit :
> You are saying to the mantainers who if they doesnt work
> on a GTK+ 1.2 -> 2.0 port their packages will go out of debian now? 

I don't have any power to remove their packages from Debian, but I urge
every maintainer of a package depending on GTK+ 1.2 to either start the
work on GTK2 porting it or consider its removal. And now is more than
the time to start this.

-- 
 .''`.
: :' :  We are debian.org. Lower your prices, surrender your code.
`. `'   We will add your hardware and software distinctiveness to
  `-our own. Resistance is futile.


signature.asc
Description: Ceci est une partie de message	numériquement signée

Re: UTF-8 man pages

[Osamu Aoki]

Hi,

On Sat, Aug 11, 2007 at 06:10:53PM +0100, David Given wrote:
> Roger Leigh wrote:
> [...]
> > I would personally like to see this happen, but until it does we are
> > limited (I believe) to the glyphs described in groff_char(7).  I am
> > not aware of any Japanese support at all except in specially-patched
> > versions.
> 
> I do know that Debian uses EUC-JP encoded man pages if you're in the Japanese
> locale, so multibyte support does work (install man-db and do:
> 
>   man -l /usr/share/man/ja/man1/manpath.1.gz
> 
> ), but that doesn't help me much in my English locale.

Yes.

Basically, unless you push restructuring of man in Debian, you are out
of lack, I think.  Please think about documenting in README.Debian,
README.UTF-8, HTML or somthing other than ...

For HTML if Japanese text is short, embeding gif/png file is better than
using UTF-8 characters.  Then you can read it from any configuration.

> --
> ┌── ｄｇ＠ｃｏｗｌａｒｋ．ｃｏｍ ─── http://www.cowlark.com ───
> │
> │ "There does not now, nor will there ever, exist a programming language in
> │ which it is the least bit hard to write bad programs." --- Flon's Axiom
> 
> 


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: conflicting gssapi libraries

[Brian May]

> "Russ" == Russ Allbery <[EMAIL PROTECTED]> writes:

Russ> My preference would be to dump the UMich GSSAPI library and
Russ> link nfs-common directly against MIT Kerberos, which doesn't
Russ> conflict with Heimdal.

So should I make the Heimdal GSSAPI library conflict with the UMich
GSSAPI library?

It which case, does the UMich library also have to conflict with the
Heimdal GSSAPI library?

I had a feeling I was told the conflicts had to appear in both
packages, but I can't remember why right now.

Anyway, I see that MIT Kerberos has named their library:

/usr/lib/libgssapi_krb5.so.2

Wouldn't this be a better solution then getting rid of the UMich
library?
-- 
Brian May <[EMAIL PROTECTED]>


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Considerations for 'xmms' removal from Debian

[Carl Fürstenberg]

On 8/12/07, Josselin Mouette <[EMAIL PROTECTED]> wrote:
> Le samedi 11 août 2007 à 06:57 +0200, David Lopez Zajara (Er_Maqui) a
> écrit :
> > You are saying to the mantainers who if they doesnt work
> > on a GTK+ 1.2 -> 2.0 port their packages will go out of debian now?
>
> I don't have any power to remove their packages from Debian, but I urge
> every maintainer of a package depending on GTK+ 1.2 to either start the
> work on GTK2 porting it or consider its removal. And now is more than
> the time to start this.
>
> --
>  .''`.
> : :' :  We are debian.org. Lower your prices, surrender your code.
> `. `'   We will add your hardware and software distinctiveness to
>   `-our own. Resistance is futile.
>
>

Just because I had nothing to do, I generated a list on the wiki on
all packages that depends on gtk+ 1.2; see:
http://wiki.debian.org/GTK+_1%2e2_leftovers

-- 
/Carl Fürstenberg <[EMAIL PROTECTED]>

Re: conflicting gssapi libraries

[Aníbal Monsalve Salazar]

On Sun, Aug 12, 2007 at 10:40:40AM +1000, Brian May wrote:
>Russ Allbery <[EMAIL PROTECTED]> writes:
>>My preference would be to dump the UMich GSSAPI library and
>>link nfs-common directly against MIT Kerberos, which doesn't
>>conflict with Heimdal.

No. There is a better solution, Brian has found that the MIT
kerberos library was renamed.

>So should I make the Heimdal GSSAPI library conflict with the UMich
>GSSAPI library?
>
>It which case, does the UMich library also have to conflict with the
>Heimdal GSSAPI library?
>
>I had a feeling I was told the conflicts had to appear in both
>packages, but I can't remember why right now.
>
>Anyway, I see that MIT Kerberos has named their library:
>
>/usr/lib/libgssapi_krb5.so.2

So, we only need versioned conflicts. Right?

>Wouldn't this be a better solution then getting rid of the UMich
>library?

Yes.

>-- 
>Brian May <[EMAIL PROTECTED]>

Best Regards,

Aníbal Monsalve Salazar
-- 
http://v7w.com/anibal


signature.asc
Description: Digital signature

Re: conflicting gssapi libraries

[Russ Allbery]

Aníbal Monsalve Salazar <[EMAIL PROTECTED]> writes:
> On Sun, Aug 12, 2007 at 10:40:40AM +1000, Brian May wrote:

>> Wouldn't this be a better solution then getting rid of the UMich
>> library?

> Yes.

Why?  Could you explain what the UMich indirection library practically
adds for our users?  Why would we want to continue using it rather than
linking directly against an appropriate GSSAPI implementation?

Also, since it was the UMich library that took over a library name that
was already in use by Heimdal, if we're going to be renaming upstream
libraries (which I think is a little dubious), which library to rename is
pretty obvious to me, and it's not the Heimdal one.

-- 
Russ Allbery ([EMAIL PROTECTED])   

Re: conflicting gssapi libraries

[Aníbal Monsalve Salazar]

On Sat, Aug 11, 2007 at 07:13:01PM -0700, Russ Allbery wrote:
>Why?  Could you explain what the UMich indirection library practically
>adds for our users?  Why would we want to continue using it rather than
>linking directly against an appropriate GSSAPI implementation?

I agree with all that. However, nfs-utils has been developed with
the UMich gssapi iplementation. I don't know why they decided no to
use the MIT library.

Is it worth it to try to get both upstream authors to unify the
libraries? Maybe Brian and me could try that.

>Also, since it was the UMich library that took over a library name that
>was already in use by Heimdal, if we're going to be renaming upstream
>libraries (which I think is a little dubious), which library to rename is
>pretty obvious to me, and it's not the Heimdal one.

Why the MIT folks renamed their library? I doubt it was because the UMich
folks used the same library name.

Best Regards,

Aníbal Monsalve Salazar
-- 
http://v7w.com/anibal


signature.asc
Description: Digital signature

Re: conflicting gssapi libraries

[Russ Allbery]

Aníbal Monsalve Salazar <[EMAIL PROTECTED]> writes:
> On Sat, Aug 11, 2007 at 07:13:01PM -0700, Russ Allbery wrote:

>> Why?  Could you explain what the UMich indirection library practically
>> adds for our users?  Why would we want to continue using it rather than
>> linking directly against an appropriate GSSAPI implementation?

> I agree with all that. However, nfs-utils has been developed with the
> UMich gssapi iplementation. I don't know why they decided no to use the
> MIT library.

It may be that they were trying to provide an indirection layer between
MIT and Heimdal so that people could choose whichever they want at
runtime.  I'm not sure of another reason for it.  The UMich library
doesn't actually implement GSSAPI at all; it requires that another
implementation (MIT or Heimdal) be available and just calls into the other
library.

There are some advantages to having an indirection layer when you want to
experiment with different libraries and see which works better (for
OpenLDAP, for instance, Heimdal has better performance characteristics
than MIT Kerberos), but it causes a lot of problems, particularly with the
same library name as Heimdal's.

I *think* that because it's an indirection layer, the NFS code would work
the same linked directly with a GSSAPI implementation like MIT's or
Heimdal's, but it's possible that they have some bits of code that aren't
purely indirection.  This is what I'd need to experiment with to see what
the implications are.  Unfortunately, I'm not going to have an opportunity
to set up an NFSv4 test environment to really experiment in the near
future.  :/

> Is it worth it to try to get both upstream authors to unify the
> libraries? Maybe Brian and me could try that.

I think that UMich is currently working with MIT to unify their
implementation with MIT's, although I don't know how fast that's going.
My understanding is that they don't want to maintain that indirection
layer going forward.

> Why the MIT folks renamed their library? I doubt it was because the
> UMich folks used the same library name.

It's always been called libgssapi_krb5 so far as I know.  krb5 was the
only GSSAPI mechanism that it provided (now it also provides SPNEGO), so
originaly the name made sense from that perspective.

I don't know the thought process that went into the original name.  The
MIT library also provides an indirection layer so that multiple GSSAPI
mechs can be used (and the UMich library ends up calling that indirection
layer and going through multiple indirections).

I'm not sure where this is all going in the long run.

-- 
Russ Allbery ([EMAIL PROTECTED])   

Re: Arch-independent parts of binary modules of interpreted languages

[Joey Hess]

Raphael Hertzog wrote:
> The rationale is simply that it's not always easily doable while using the
> official installation methods, and that changing it manually is
> error-prone and can be confusing in some cases.
>
> While it's important that all files in /usr/share be arch-independent
> (because one might want to share that between several machines),
> it's not that important that /usr/lib contains only arch-dependent stuff.
> In fact, in most cases it's convenient (if not required) to have the
> arch-indep glue around the binary part in the same directory than the
> binary part.

Another reason: I'd much rather get an error message like "Can't locate
Foo.pm in @INC" when trying to use a module Foo that isn't installed,
than "Can't locate loadable object for module Foo in @INC". The latter
is what you get if Foo.pm is there but the Foo.so  that it's a wrapper
for is missing. It's a much less common error, and so harder to debug.
Much better that any available perl modules be usable, and any with a
arch-dep binary part that's not installed not be visible on the
filesystem at all.

Of course this is all hypothetical, since I've never heard of /usr/share
actually being shared amoung machines of differing architectures.

-- 
see shy jo


signature.asc
Description: Digital signature

Re: UTF-8 man pages

[Steinar H. Gunderson]

On Sun, Aug 12, 2007 at 09:09:07AM +0900, Osamu Aoki wrote:
> For HTML if Japanese text is short, embeding gif/png file is better than
> using UTF-8 characters.  Then you can read it from any configuration.

...except a text-mode one?

/* Steinar */
-- 
Homepage: http://www.sesse.net/


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: UTF-8 man pages

[Mike Hommey]

On Sun, Aug 12, 2007 at 09:09:07AM +0900, Osamu Aoki <[EMAIL PROTECTED]> wrote:
> Hi,
> 
> On Sat, Aug 11, 2007 at 06:10:53PM +0100, David Given wrote:
> > Roger Leigh wrote:
> > [...]
> > > I would personally like to see this happen, but until it does we are
> > > limited (I believe) to the glyphs described in groff_char(7).  I am
> > > not aware of any Japanese support at all except in specially-patched
> > > versions.
> > 
> > I do know that Debian uses EUC-JP encoded man pages if you're in the 
> > Japanese
> > locale, so multibyte support does work (install man-db and do:
> > 
> >   man -l /usr/share/man/ja/man1/manpath.1.gz
> > 
> > ), but that doesn't help me much in my English locale.
> 
> Yes.
> 
> Basically, unless you push restructuring of man in Debian, you are out
> of lack, I think.  Please think about documenting in README.Debian,
> README.UTF-8, HTML or somthing other than ...
> 
> For HTML if Japanese text is short, embeding gif/png file is better than
> using UTF-8 characters.  Then you can read it from any configuration.

Erm, for HTML, it'd be better to use entities, such as 日本

Mike


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]