headers
Charles Plessy | 1 Sep 2009 02:49
Picon
Favicon

Re: Compiling libbam.a from libbam-dev with -fPIC?

Le Mon, Aug 31, 2009 at 01:23:39AM +0100, Stephen Gran a écrit :
> This one time, at band camp, Charles Plessy said:
> > Le Sat, Aug 29, 2009 at 08:06:09PM -0700, Steve Langasek a écrit :
> > > On Sun, Aug 30, 2009 at 11:56:58AM +0900, Charles Plessy wrote:
> > > > as per Policy § 10.2, I would like to know if everybody agrees if I change the
> > > > libbam-dev package to compile libbam.a with -fPIC.
> > 
> > > What are the reasons for not shipping a shared library?  That's always
> > > preferred over use of -fPIC for static libs, so we should examine the
> > > reasons for this first.
> > 
> > I forgot to mention that the upstream sources do not build a shared library.
> 
> Is there some reason you as a maintainer can't?  If the library has no
> API or ABI stability, that might be a good reason not to (although it's
> a better reason to talk to upstream about why they have to do so), but
> otherwise, why not just do it?

I started to write a message about to ask upstream why they do not make a
shared version of libbam, but I am blocked because I could not give good reason
of why Debian can not make -fPIC version of libbam. To my knowledge, libbam is
used by the samtools themselves, as well as the Bio::SamTools perl library. For
Bio::SamTools, -fPIC is definitely not a problem because the upstream README
mentions to use this option if necessary. For the samtools program, it will be
easy to prepare a version that is built against a non-fPIC libbam.a, but I fail
to understand why it is important since if upstream releases a shared version
of libbam, it will have to be compiled with -fPIC anyway, which makes little
difference between the situation we want to avoid and the situation we want to
recommend.
(Continue reading)

Permalink | Reply | 4 comments |
headers
Christine Spang | 1 Sep 2009 03:46
Picon
Favicon
Gravatar

Bug#544498: ITP: libterm-encoding-perl -- Perl module to detect encoding of the current terminal

Package: wnpp
Severity: wishlist
Owner: Christine Spang <christine <at> debian.org>

* Package name    : libterm-encoding-perl
  Version         : 0.02
  Upstream Author : Tatsuhiko Miyagawa <miyagawa <at> bulknews.net>
* URL             : http://search.cpan.org/dist/Term-Encoding/
* License         : Perl (Artistic | GPL-1+)
  Programming Lang: Perl
  Description     : Perl module to detect encoding of the current terminal

Term::Encoding is a simple module to detect an encoding the current terminal
expects, in various ways.
Permalink | Reply | 0 comments |
headers
Marco d'Itri | 1 Sep 2009 05:24
Picon
Favicon

udev and /usr

On May 31, md wrote:

> The issue was raised by the udev upstream maintainer along with the udev
> package maintainers of the major distributions, who all agreed that this
> configuration is not supported.
FYI, udev 146 ships usb-id and pci-id programs which read
/usr/share/misc/usb.ids and /usr/share/misc/pci.ids .
udev itself does not care about the results of these programs but other
programs which used to use HAL may do, leading to subtle breakage.

There are no obvious workarounds and I have no plan to fight against
this, if you need it to work on systems with a standalone /usr then
feel free to persuade the relevant maintainers to move the files.

I also opened #544503 because supporting a standalone /var looks like
a worthwhile effort, while supporting updating usb.ids with a script
instead of apt looks like a complete idiocy.

--

-- 
ciao,
Marco
Permalink | Reply | 543 comments |
headers
Michael Biebl | 1 Sep 2009 06:17
Picon
Favicon

Re: udev and /usr

Marco d'Itri wrote:
> On May 31, md wrote:
> 
>> The issue was raised by the udev upstream maintainer along with the udev
>> package maintainers of the major distributions, who all agreed that this
>> configuration is not supported.
> FYI, udev 146 ships usb-id and pci-id programs which read
> /usr/share/misc/usb.ids and /usr/share/misc/pci.ids .

Wouldn't make it sense then if udev had a recommends or at least suggests for
usbutils and pciutils?

> udev itself does not care about the results of these programs but other
> programs which used to use HAL may do, leading to subtle breakage.

How will usb-id and pci-id behave, if the ids files are not accessible?

> There are no obvious workarounds and I have no plan to fight against
> this, if you need it to work on systems with a standalone /usr then
> feel free to persuade the relevant maintainers to move the files.
> 
> I also opened #544503 because supporting a standalone /var looks like
> a worthwhile effort, while supporting updating usb.ids with a script
> instead of apt looks like a complete idiocy.

I agree with you. Given that I had more than once bug reports against hal due to
broken pci.ids or usb.ids files, I'd prefer if update-usbids and update-pciids
would go away.

Michael
(Continue reading)

Permalink | Reply | 15 comments |
headers
Giacomo A. Catenazzi | 1 Sep 2009 09:30
Picon
Favicon

Re: udev and /usr

Marco d'Itri wrote:
> On May 31, md wrote:
> 
>> The issue was raised by the udev upstream maintainer along with the udev
>> package maintainers of the major distributions, who all agreed that this
>> configuration is not supported.
> FYI, udev 146 ships usb-id and pci-id programs which read
> /usr/share/misc/usb.ids and /usr/share/misc/pci.ids .
> udev itself does not care about the results of these programs but other
> programs which used to use HAL may do, leading to subtle breakage.
> 
> There are no obvious workarounds and I have no plan to fight against
> this, if you need it to work on systems with a standalone /usr then
> feel free to persuade the relevant maintainers to move the files.

I still think /usr standalone should be supported, but I agree with you
that it could be difficult to support it in actual way.

Thus: Are there any technical difficulties to mount usr in the standard
initramfs?
I don't think there are more "special" /usr environments as compared of /

ciao
	cate
Permalink | Reply | 7 comments |
headers
Asias He | 1 Sep 2009 09:50
Picon

Bug#544517: ITP: ibus-table-zhengma -- Zhengma input method based on table engine of ibus

Package: wnpp
Severity: wishlist
Owner: Asias He <asias.hejun <at> gmail.com>

* Package name    : ibus-table-zhengma
  Version         : 1.1.0.20090402
  Upstream Author : Caius "kaio" Chance <k at kaio.me>
* URL             : http://code.google.com/p/ibus
* License         : GPLv2
  Programming Lang: N/A
  Description     : Zhengma input method based on table engine of ibus

 IBus-Table is the IM Engine framework for table-based input methods,
 such as WuBi, ErBi, Cangjie and so on.
 .
 This package provides one input method: Zhengma.
 .
 Zhengma is a Chinese input method.
Permalink | Reply | 1 comment |
headers
Gerrit Pape | 1 Sep 2009 09:54

RFA's and RFH

Hi, I'm looking for new maintainers for

 bglibs -- BG Libraries Collection
  http://bugs.debian.org/544056
 matrixssl -- small SSL library optimized for embedded systems
  http://bugs.debian.org/544057
 libowfat -- A reimplementation of libdjb
  http://bugs.debian.org/544059
 libdjbdns -- DNS client library designed to replace the BIND res_*/dn_* library
  http://bugs.debian.org/544401

and for some help with

 dietlibc -- diet libc - a libc optimized for small size
  http://bugs.debian.org/544060

If you're interested, please followup to the bug report and await my
reply.

Thanks, Gerrit.
Permalink | Reply | 1 comment |
headers
Petter Reinholdtsen | 1 Sep 2009 10:32

Re: udev and /usr


[Giacomo A. Catenazzi]
> I still think /usr standalone should be supported, but I agree with
> you that it could be difficult to support it in actual way.
>
> Thus: Are there any technical difficulties to mount usr in the
> standard initramfs?
> I don't think there are more "special" /usr environments as compared
> of /

In Debian, /usr/ is allowed to be on NFS.  Mounting NFS volumes from
the initramfs is probably not worth the effort.  I recommend moving
the needed files from /usr/ to /, to get this working properly.  udev
need to start before /var/ and /usr/ is mounted when they are on
separate partitions, and thus should only need files on /.  If udev
need /, /var/ and /usr/ to be on the same partition, I believe udev
have a release critical bug that need to be fixed before Squeeze is
released.

Happy hacking,
--

-- 
Petter Reinholdtsen
Permalink | Reply | 6 comments |
headers
Josselin Mouette | 1 Sep 2009 10:43
Picon
Favicon

Re: Compiling libbam.a from libbam-dev with -fPIC?

Le mardi 01 septembre 2009 à 09:49 +0900, Charles Plessy a écrit : 
> I started to write a message about to ask upstream why they do not make a
> shared version of libbam, but I am blocked because I could not give good reason
> of why Debian can not make -fPIC version of libbam.

You can build a libbam_pic.a and that is really not a problem. However
it would be much better, for security support among other things, to
build a shared library instead.

--

-- 
 .''`.      Josselin Mouette
: :' :
`. `'   “I recommend you to learn English in hope that you in
  `-     future understand things”  -- Jörg Schilling
Permalink | Reply | 3 comments |
headers
Josselin Mouette | 1 Sep 2009 11:06
Picon
Favicon

Re: udev and /usr

Le mardi 01 septembre 2009 à 10:32 +0200, Petter Reinholdtsen a écrit : 
> In Debian, /usr/ is allowed to be on NFS.

So is /.

> Mounting NFS volumes from
> the initramfs is probably not worth the effort.

How do you make root on NFS work without this?

--

-- 
 .''`.      Josselin Mouette
: :' :
`. `'   “I recommend you to learn English in hope that you in
  `-     future understand things”  -- Jörg Schilling
Permalink | Reply | 5 comments |

Gmane