Bug 457210 - Review Request: dpkg - Package maintenance system for Debian Linux
Summary: Review Request: dpkg - Package maintenance system for Debian Linux
Keywords:
Status: CLOSED DUPLICATE of bug 550582
Alias: None
Product: Fedora
Classification: Fedora
Component: Package Review
Version: rawhide
Hardware: All
OS: Linux
low
medium
Target Milestone: ---
Assignee: Nobody's working on this, feel free to take it
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks: 456756 457211 470639 RussianFedoraRemix
TreeView+ depends on / blocked
 
Reported: 2008-07-30 09:35 UTC by leigh scott
Modified: 2009-12-26 19:50 UTC (History)
15 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2009-12-25 00:31:45 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)

Description leigh scott 2008-07-30 09:35:58 UTC
Spec URL: http://www.linux-ati-drivers.homecall.co.uk/dpkg.spec
SRPM URL: http://www.linux-ati-drivers.homecall.co.uk/dpkg-1.14.20-2.fc9.src.rpm
Description: 
This package contains the tools (including dpkg-source) required 
to unpack, build and upload Debian source packages.

This package also contains the programs dpkg which used to handle the 
installation and removal of packages on a Debian system.

This package also contains dselect, an interface for managing the 
installation and removal of packages on the system.

dependency for alien 456756 

https://bugzilla.redhat.com/show_bug.cgi?id=456756

I am also seeking a sponsor.

Comment 1 leigh scott 2008-07-30 09:52:58 UTC
I  had build debhelper against po4a 0.34 as it wouldn't build with 0.32.



Comment 2 leigh scott 2008-07-30 10:05:08 UTC
(In reply to comment #1)
> I  had build debhelper against po4a 0.34 as it wouldn't build with 0.32.
> 
> 
Please ignore this as it is wrong . 


Comment 3 Ralf Corsepius 2008-07-31 07:23:27 UTC
Some remarks:

* I would recommend to apply the same package split as Debian, i.e. to split
this package into dpkg, dpkg-dev and dselect. 

This tremendously helps with regard to "Debian" compatibility and also avoids
pulling-in quite an amount of deps.

* I would advise you to have a look into the package's "configure --help"
I comes along with several --with/--without options and environment variables
you'll likely will want to apply.


Comment 5 Rakesh Pandit 2008-08-16 13:24:24 UTC
GPLv2+ looks to me correct license.

[rpmbuild@rocky i386]$ rp dpkg-1.14.20-4.fc9.i386.rpm 
dpkg.i386: E: only-non-binary-in-usr-lib
1 packages and 0 specfiles checked; 1 errors, 0 warnings.

[rpmbuild@rocky i386]$ rp dpkg-dev-1.14.20-4.fc9.i386.rpm 
dpkg-dev.i386: E: only-non-binary-in-usr-lib
1 packages and 0 specfiles checked; 1 errors, 0 warnings.

[rpmbuild@rocky i386]$ rp dselect-1.14.20-4.fc9.i386.rpm 
dselect.i386: E: only-non-binary-in-usr-lib
1 packages and 0 specfiles checked; 1 errors, 0 warnings.


package does not own some directories 
1. /etc/dpkg/
2. /usr/lib/dpkg/
3. /usr/lib/perl5/vendor_perl/5.10.0/Dpkg/
4. /usr/share/dpkg/

It looks like SPEC file length can be reduced by using regular exp or some constructs which prevent similar patterns.

Comment 6 leigh scott 2008-08-16 14:56:59 UTC
How do I make the package own the directory ?

Comment 7 Rakesh Pandit 2008-08-16 15:15:53 UTC
e.g for /etc/dpkg/
in %files section use: %dir %{_sysconfdir}/%{name}

Comment 8 leigh scott 2008-08-16 16:25:49 UTC
Thanks for the info ( I will submit updated SPEC & SRPM later )

_______________________________________________________________


Is there anything I can do for these errors ( these are the correct file locations ) 


dpkg.i386: E: only-non-binary-in-usr-lib

dpkg-dev.i386: E: only-non-binary-in-usr-lib

dselect.i386: E: only-non-binary-in-usr-lib

Comment 9 Rakesh Pandit 2008-08-16 17:30:11 UTC
Snippet from output of:
[rpmbuild@rocky i386]$ rpmfile dpkg-1.14.20-4.fc9.i386.rpm  


-----------------
/usr/lib/dpkg/mksplit	100755	perl script text executable
/usr/lib/perl5/vendor_perl/5.10.0/Dpkg.pm	100644	ASCII English text
/usr/lib/perl5/vendor_perl/5.10.0/Dpkg/Gettext.pm	100644	perl script text executable
-----------------

It looks to me you can see Dpkg.pm is ASCII English txt.
It looks it has a missing sh-bang line:
#!/usr/bin/perl -w

if it works inform upstream.

Comment 10 Rakesh Pandit 2008-08-16 18:20:53 UTC
[rpmbuild@rocky i386]$ rp -i dpkg-1.14.20-4.fc9.i386.rpm 
dpkg.i386: E: only-non-binary-in-usr-lib
There are only non binary files in /usr/lib so they should be in /usr/share.


---
.pm files are are not intended to be run directly rather .pl files are and they don't generally don't need she-bang. So, most probably I am wrong.

But you will need to investigate why that one of these files most probably mksplit has an issue.

Comment 11 leigh scott 2008-08-16 19:26:44 UTC
(In reply to comment #10)
> [rpmbuild@rocky i386]$ rp -i dpkg-1.14.20-4.fc9.i386.rpm 
> dpkg.i386: E: only-non-binary-in-usr-lib
> There are only non binary files in /usr/lib so they should be in /usr/share.
> 
> 
> ---
> .pm files are are not intended to be run directly rather .pl files are and they
> don't generally don't need she-bang. So, most probably I am wrong.
> 
> But you will need to investigate why that one of these files most probably
> mksplit has an issue.


I have extracted the stable  dpkg_1.13.25_i386.deb package and looked at mksplit
 and it appear to be the same !

Comment 12 Ralf Corsepius 2008-08-19 01:19:38 UTC
(In reply to comment #11)
> (In reply to comment #10)

> > .pm files are are not intended to be run directly rather .pl files are and they
> > don't generally don't need she-bang.
These are perl-modules, which must NOT be executable nor do they need a she-bang.

> > But you will need to investigate why that one of these files most probably
> > mksplit has an issue.

No, it doesn't have one. mksplit is a script.


But there are other issues with your package:

1) It is wrong to rename install-info/cleanup-info. These are different tools than the ones in Fedora and must be installed to /usr/sbin, otherwise dpkg will not work.

2) Installing dpkg's (dpkg-)update-alternatives daemon doesn't make any sense on Fedora, because these are provided by other packages in Fedora.

3) Packaging (dpkg-)start-stop-daemon also hardly makes sense. I recommend to not building nor installing it. (%configure --without-start-stop-daemon)

Comment 13 leigh scott 2008-08-19 01:42:03 UTC
(In reply to comment #12)
> (In reply to comment #11)
> > (In reply to comment #10)
> 
> > > .pm files are are not intended to be run directly rather .pl files are and they
> > > don't generally don't need she-bang.
> These are perl-modules, which must NOT be executable nor do they need a
> she-bang.
> 
> > > But you will need to investigate why that one of these files most probably
> > > mksplit has an issue.
> 
> No, it doesn't have one. mksplit is a script.
> 
> 
> But there are other issues with your package:
> 
> 1) It is wrong to rename install-info/cleanup-info. These are different tools
> than the ones in Fedora and must be installed to /usr/sbin, otherwise dpkg will
> not work.
> 
> 2) Installing dpkg's (dpkg-)update-alternatives daemon doesn't make any sense
> on Fedora, because these are provided by other packages in Fedora.
> 
> 3) Packaging (dpkg-)start-stop-daemon also hardly makes sense. I recommend to
> not building nor installing it. (%configure --without-start-stop-daemon)

1) I didn't rename install-info/cleanup-info intentionally  and dpkg-install-info/dpkg-cleanup-info are installed to /usr/sbin and appear to work properly.

2) should I just add "rm $RPM_BUILD_ROOT%{_sbindir}/dpkg-update-alternatives" to the SPEC file to remove it ?

Comment 14 Ralf Corsepius 2008-08-19 02:29:02 UTC
(In reply to comment #13)

> 1) I didn't rename install-info/cleanup-info intentionally  and
> dpkg-install-info/dpkg-cleanup-info are installed to /usr/sbin and appear to
> work properly.

They can not work properly, because 

a) Many *.debs have /usr/sbin/install-info hard-coded, because this is the location Debian has used ever since they exist. It does not conflict with Fedora, because Fedora rpms use a hard-coded /sbin/install-info.

A dpkg-cleanup|install-info won't ever be used by any package.

b) Debian's install-info is something very different than Fedora's install-info (They are incompatible).


> 2) should I just add "rm $RPM_BUILD_ROOT%{_sbindir}/dpkg-update-alternatives"
> to the SPEC file to remove it ?
That's what I am doing in my older (dkg-1.13.25) package :)

Comment 15 Patrice Dumas 2008-08-19 13:45:47 UTC
I think that it would be better to leave dpkg-cleanup|install-info in
if somebody wants to use them. As long as the name is clear and that
it will only be called on purpose I think it is better to leave it
in, no problem if nobody uses it, and if somebody wants to he can.

Comment 16 leigh scott 2008-08-19 14:09:07 UTC
Here's the new SPEC + SRPM with the suggested changes !

http://www.linux-ati-drivers.homecall.co.uk/dpkg.spec
http://www.linux-ati-drivers.homecall.co.uk/dpkg-1.14.20-5.fc9.src.rpm

Comment 17 leigh scott 2008-08-19 14:11:00 UTC
(In reply to comment #15)
> I think that it would be better to leave dpkg-cleanup|install-info in
> if somebody wants to use them. As long as the name is clear and that
> it will only be called on purpose I think it is better to leave it
> in, no problem if nobody uses it, and if somebody wants to he can.


I have left them in but I have renamed them to there original names as suggested !

Comment 18 Ralf Corsepius 2008-08-19 14:18:08 UTC
(In reply to comment #17)
> (In reply to comment #15)
> > I think that it would be better to leave dpkg-cleanup|install-info in
> > if somebody wants to use them.

Nobody will want to use them - They are useless, because Debian doesn't have them!

On the other hand /usr/sbin/cleanup-info and /usr/bin/install-info are mandatory for dpkg to work, because Debian has them.


> I have left them in but I have renamed them to there original names as
> suggested !

MUSTFIX:

- Remove dpkg-cleanup-info, dpkg-install-info
- Add /usr/sbin/cleanup-info , /use/sbin/install-info

Comment 19 leigh scott 2008-08-19 14:41:20 UTC
> MUSTFIX:
> 
> - Remove dpkg-cleanup-info, dpkg-install-info
> - Add /usr/sbin/cleanup-info , /use/sbin/install-info



I  have already done it ! 


[leigh05@localhost Alien_project]$ cd dpkg-1.14.20-5.fc9.x86_64/usr/sbin/
[leigh05@localhost sbin]$ ls
cleanup-info  dpkg-divert  dpkg-statoverride  install-info
[leigh05@localhost sbin]$

Comment 20 leigh scott 2008-08-19 14:52:24 UTC
> 
> MUSTFIX:
> 
> - Remove dpkg-cleanup-info, dpkg-install-info
> - Add /usr/sbin/cleanup-info , /use/sbin/install-info


Here's a link to my server ( on from 09.00GMT - 00.00GMT ) if you want to check the built RPM packages.


http://leigh123.homelinux.com/dpkg/

Comment 21 Patrice Dumas 2008-09-03 11:20:36 UTC
Definition of packagename as a macro is unuseful.

The description of the dpkg subpackage should be trimmed to
contain only what is relevant for that sub-package.

For dpkg-dev you should not use -n, but instead use dev, 
dpkg- will be automatically prepended.

A period is missing at the end of dpkg-dev %description.

Although the Group doesn't matter much, it seems to me that
dpkg-dev should better be Development/Tools.

There is a spurious space before the period of the 
dselect.

I suggest using a glob for the man pages extensions, such as not
to have to change the spec file when the compression scheme 
changes or there is no compression, like
%{_mandir}/man1/dpkg-deb.1*

It seems to me that %{_libdir}/dpkg/ should better be in 
%{_datadir} or %{_libexecdir} than in %{_libdir}. Maybe this 
could be reported upstream?

The admindir is /var/dpkg, it should be /var/lib/dpkg, you should pass
configure --with-admindir=%{_localstatedir}/lib/dpkg

Also the package should certainly own %{_sysconfdir}/dpkg, and have
%{_sysconfdir}/dpkg/dpkg.conf %config(noreplace). Also 
%{_sysconfdir}/dpkg/origin/ and /usr/share/dpkg/ are not owned.

Shouldn't dpkg-dev and dselect depend on dpkg?

To keep timestamps on iconved files, you can do

for file in  %{buildroot}%{_mandir}/*/man*/* ; do
  iconv -f latin1 -t utf8 $file -o $file.new
  touch -c -r $file $file.new
  mv -f $file.new $file
done

dpkg- prefixed executables are still there.


Regarding th euse of dpkg, my investigations show that, after doing
touch status
mkdir updates
touch available
mkdir info
dpkg is ready to install files, with --force-bad-path since the
executables renamed/not installed are not found.

This seems a bit dangerous to me. Maybe we could add an empty 
/etc/dpkg.conf
with
instdir=/var/lib/dpkg_installation
to avoid clobbering the rpm managed filesystem?

If we go down that way, maybe also we could ship a wrapper script that sets
a PATH within /var/lib/dpkg_installation and also sets LD_LIBRARY_PATH
to be able to install and run packages installed through dpkg. Maybe
it shouldn't be done since it is too dangerous and debian packages pre/post
scripts may harm the fedora installation?

Ralf, do you use dpkg to install dpkg package on a fedora?

Comment 22 Rakesh Pandit 2008-09-29 12:56:36 UTC
@leigh

ping? Any updates ?

Comment 23 Orcan Ogetbil 2008-12-13 19:08:18 UTC
re-ping?

Comment 24 leigh scott 2008-12-13 19:42:23 UTC
I haven't had time to do any work on dpkg lately , I hope to get some free time in the new year .

Comment 25 leigh scott 2008-12-16 00:00:29 UTC
I think I have implemented most of the recommended changes , it hasn't been possible to use glob for the man pages extensions as doing so would pack some man pages in the wrong packages .


Spec: http://www.linux-ati-drivers.homecall.co.uk/dpkg.spec


SRPM: http://www.linux-ati-drivers.homecall.co.uk/dpkg-1.14.23-1.fc10.src.rpm

Comment 26 Ralf Corsepius 2008-12-30 08:02:42 UTC
There are still several issues:

SHOULD:
- In dkg's %files, you are inconsistently using %name and dpkg.
  Please only use one of them. I recommend to use dpkg, only.

- You are still using %packagename. Please stop it.

- The latin1->utf8 transformation of the man-pages should be performed 
  in %build.

MUSTFIX:
- There is a circular dependency between the dpkg and dpkg-dev, introduced by
  the perl modules (dpkg can not be installed without dpkg-dev).

  I see 3 alternatives to work around this issue:
  a) package the perl modules as separate package (e.g. perl-Dpkg)
  b) move all perl modules into dpkg
  c) try to sort out the details of the perl module deps.
  I for one would choose alternative a). 
  b) is almost equivalent to a), while c) is likely difficult to implement, 
  if possible at all.

- Several directories are unowned, e.g.
  /etc/dpkg/origins
  /usr/lib/perl5/vendor_perl/5.10.0/Dpkg/Source
  /usr/lib/perl5/vendor_perl/5.10.0/Dpkg/Shlibs
  
- Files below %{_mandir} automatically receive %doc
  => the %doc inside of your 
  %lang(xx) %doc %{_mandir} ...
  lists are superfluous. Please remove them.

Comment 27 Ralf Corsepius 2008-12-30 09:01:29 UTC
(In reply to comment #26)

> MUSTFIX:
> - There is a circular dependency between the dpkg and dpkg-dev, introduced by
>   the perl modules (dpkg can not be installed without dpkg-dev).
> 
>   I see 3 alternatives to work around this issue:
I missed something: The cause of this issue is you incorrectly 
packaging the applications in %{_bindir}/.

Correctly stuffing those applications into dpkg rsp. dpkg-dev, like debian does, automatically resolves this issue.

Comment 28 leigh scott 2008-12-30 20:47:31 UTC
Spec: http://www.linux-ati-drivers.homecall.co.uk/dpkg.spec


SRPM: http://www.linux-ati-drivers.homecall.co.uk/dpkg-1.14.23-3.fc10.src.rpm



> - Several directories are unowned, e.g.
>  /etc/dpkg/origins
>  /usr/lib/perl5/vendor_perl/5.10.0/Dpkg/Source
>  /usr/lib/perl5/vendor_perl/5.10.0/Dpkg/Shlibs


dpkg does own these files 


%dir %{_sysconfdir}/dpkg

%dir %{perl_vendorlib}/Dpkg

Comment 29 Orcan Ogetbil 2009-01-31 06:10:37 UTC
Is there anyone doing this review?

leigh, do you still need sponsorship?

Comment 30 leigh scott 2009-01-31 09:21:10 UTC
(In reply to comment #29)
> Is there anyone doing this review?
> 
> leigh, do you still need sponsorship?

Yes I do still need sponsorship .

Comment 31 Rahul Sundaram 2009-04-20 05:24:03 UTC
IIRC, you have subsequently been sponsored. Can you put in a cvs request?

Comment 32 Orcan Ogetbil 2009-04-20 05:52:58 UTC
I see that you are now sponsored. Can you update this to the latest upstream version before we do a complete review?

Meanwhile I found some issues that you may want to fix while you are there:

? The group that for the dev package seems wrong. This is not a library, or is it?
See /usr/share/doc/rpm-*/GROUPS file for possible candidates.

* There are some files in the source that refer to /usr/local/, /usr/lib/ etc. These need probably be patched, or sedded:
   lib/dpkg.h
   scripts/t/200_Dpkg_Shlibs.t
   scripts/t/200_Dpkg_Shlibs/ld.so.conf.d/normal.conf
   scripts/t/200_Dpkg_Shlibs/objdump.glib-ia64
   scripts/t/200_Dpkg_Shlibs/objdump.dbd-pg
   scripts/Dpkg/Changelog.pm
   many files in man/*/*

? Can't this fix be done in %prep?:
   # ugly fix to get the translated man pages in utf-8
   chmod 766 %{buildroot}%{_mandir}/*/man*/*
   for file in  %{buildroot}%{_mandir}/*/man*/* ; do
   ...


-------------

Rahul,
WOW! What is the probability of having a "mid-air collision" for a bug that was idle for 3 months?

Comment 33 Andrew Colin Kissa 2009-07-06 09:29:12 UTC
Ping.

This is quite a useful package to have, Leigh are you still going to bump it to the latest upstream ?

Comment 34 Jason Tibbitts 2009-07-17 18:13:57 UTC
Policy says that this should have been closed already.  I'll give it a couple more days but then I'll go ahead and close it along with the alien and debhelper tickets that depend on this one.

Comment 35 Andrew Colin Kissa 2009-07-17 18:21:06 UTC
I am willing to take over in case Leigh is no longer interested in maintaining this package as it is useful to me.

Comment 36 Itamar Reis Peixoto 2009-07-17 18:26:17 UTC
(In reply to comment #34)

Can Andrew Colin Kissa continue the work ?

Comment 37 Jason Tibbitts 2009-07-17 18:39:01 UTC
If this gets closed, anyone else is welcome to open their own review ticket.  If that happens, please mark this one as a duplicate of the new one.

Comment 38 leigh scott 2009-07-17 18:57:38 UTC
(In reply to comment #35)
> I am willing to take over in case Leigh is no longer interested in maintaining
> this package as it is useful to me.  


Free feel to take it over.

Comment 39 Till Maas 2009-09-16 20:38:06 UTC
Please remove NotReady from the Whiteboard if you have sorted out who wants to submit this review and when the issues from comment:32 are resolved.

Comment 40 Orcan Ogetbil 2009-11-07 07:14:06 UTC
Andrew? Did you give up too?

In case no one steps forward to work on this I may be able to find time to work  around new year's. That's 2 months from now.

Comment 41 Andrew Colin Kissa 2009-11-07 07:45:46 UTC
I can work on this sometime next week, i totally forgot about it.

Comment 42 Andrew Colin Kissa 2009-11-10 12:06:00 UTC
The changes requested have been made and i have bumped to the latest upstream version.

http://www.topdog-software.com/oss/SRPMS/fedora/dpkg/dpkg.spec
http://www.topdog-software.com/oss/SRPMS/fedora/dpkg/dpkg-1.15.4.1-1.fc11.src.rpm

Comment 43 Stefan Seidel 2009-12-01 10:08:31 UTC
Here are my 0.02 - I added build dependencies of gcc and gcc-c++, because it won't build without them. Maybe also need to add make, I'm not sure.

Also, iconv {} -o {} gives a bunch of 0 byte files -> not what is intented I think. So I took the easy way out and used recode.

I was building this on CentOS 5.4, and with these changes and the removal of "lzma" (package is not available here) and "perl(extra)" from the final dependencies I was able to build and install and run 'dpkg -h' just fine.

--- dpkg.spec.latest    2009-12-01 10:56:33.000000000 +0100
+++ dpkg.spec   2009-12-01 10:59:48.000000000 +0100
@@ -11,7 +11,7 @@
 Patch1:         fedora-fix-paths.patch
 BuildRoot:      %{_tmppath}/%{name}-%{version}-%{release}-root-%(%{__id_u} -n)

-BuildRequires:  zlib-devel, bzip2-devel, libselinux-devel, gettext, ncurses-devel
+BuildRequires:  zlib-devel, bzip2-devel, libselinux-devel, gettext, ncurses-devel, gcc, gcc-c++, recode

 %description

@@ -61,7 +61,7 @@
 chmod +x %{__perl_requires}

 # fix to get man pages translated to utf-8
-find man -type f -exec /usr/bin/iconv -f latin1 -t utf8 {} -o {} ';'
+find man -type f -exec /usr/bin/recode latin1..utf8 {} ';'

 %build
 %configure LDFLAGS='-lselinux' \
@@ -215,6 +215,10 @@


 %changelog
+* Tue Dec 1 2009 Stefan Seidel <bugzilla-rh> - 1.15.4.1-2
+- add required build dependencies
+- fix wrong use of iconv
+
 * Tue Nov 10 2009 Andrew Colin Kissa <andrew.net> - 1.15.4.1-1
 - Upgrade to latest upstream
 - review changes

Comment 44 Andrew Colin Kissa 2009-12-01 10:19:28 UTC
- The dependencies are not required. - http://fedoraproject.org/wiki/Packaging/Guidelines#Exceptions_2

I will test the other changes on fedora and update.

Comment 45 Ralf Corsepius 2009-12-01 13:33:04 UTC
(In reply to comment #43)

> Also, iconv {} -o {} gives a bunch of 0 byte files -> not what is intented I
> think.
Correct. It's a classic beginner's mistake to redirect a program's output to 
its input. You need to use a temporary file.

> So I took the easy way out and used recode.
Please don't. Use iconv.

Comment 46 Mamoru TASAKA 2009-12-01 15:56:45 UTC
(In reply to comment #43)
> Also, iconv {} -o {} gives a bunch of 0 byte files -> not what is intented I
> think. So I took the easy way out and used recode.

[tasaka1@localhost TEMP]$ echo "漢字が入った例文です" > kanji.txt 
[tasaka1@localhost TEMP]$ ls -al kanji.txt 
-rw------- 1 tasaka1 tasaka1 31 2009-12-02 00:52 kanji.txt
[tasaka1@localhost TEMP]$ iconv -f UTF-8 -t EUC-JP kanji.txt -o kanji.txt 
[tasaka1@localhost TEMP]$ ls -la kanji.txt 
-rw------- 1 tasaka1 tasaka1 21 2009-12-02 00:52 kanji.txt
[tasaka1@localhost TEMP]$ iconv -f EUC-JP -t UTF-8 kanji.txt -o kanji.txt 
[tasaka1@localhost TEMP]$ ls -al kanji.txt 
-rw------- 1 tasaka1 tasaka1 31 2009-12-02 00:53 kanji.txt

Comment 47 Andrew Colin Kissa 2009-12-01 16:07:03 UTC
In rely to comment #46, #43

That's exactly what i thought, I have double checked on my fedora build machine, i do not get any 0 byte files.

Comment 48 Stefan Seidel 2009-12-01 17:30:36 UTC
Probably the effects of http://sourceware.org/git/?p=glibc.git;a=commitdiff;h=ca668b298e9b8c2c191eae259fddfed5e03a8dd4

Someone complained at http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=439720

On my Debian Etch, Lenny and CentOS 5.4 Systems with glibc versions ranging from 2.3.6 to 2.7 it gives 0 bytes, but not on Ubuntu glibc 2.10.1. Anyway, here's the glibc-independent version:

+find man -type f -exec /usr/bin/iconv -f latin1 -t utf8 {} -o {}._utf8 ';' -exec mv -f {}._utf8 {} ';'

Comment 49 Thomas Spura 2009-12-25 00:31:45 UTC
What's the state on this?

Leigh does not want to package this anymore (see comment #38), so it's the choice of oget or Andrew to take it over, but please do the following:


(In reply to comment #37)
> If this gets closed, anyone else is welcome to open their own review ticket. 
> If that happens, please mark this one as a duplicate of the new one.  

Closing till someone else opens an own review request and closes this as duplicate.

Comment 50 Andrew Colin Kissa 2009-12-26 06:17:23 UTC

*** This bug has been marked as a duplicate of bug 550582 ***


Note You need to log in before you can comment on or make changes to this bug.