RFH: lesstif2 -- OSF/Motif 2.1 implementation released under LGPL

[Paul Gevers]

Package: wnpp
Severity: normal

C (?) Programmers help wanted.

Upstream of lesstif is not active anymore and I have committed myself to
help as much as I can to improve the Debian package (also by committing
patches upstream). The popcon of this library is pretty high, currently
around 15694 installed. However, copy/pasting has been implemented in
the past in a way that worked internally, but apparently without the
proper ICCCM implementation. This has caused a lot of bugs and is
currently the main issue with this library. The problematic code can be
easily identified in the source (lib/Xm-2.1/CutPaste.c) by searching for
the text "FIX ME". Because my knowledge of C is not enough to fix
this myself (I will look at it with a friend thou) I ask for help from
programmers to have a look. See also http://lesstif.sourceforge.net/#help

Paul

The package description is:
 Contains runtime shared libraries for LessTif, the Hungry Programmers'
 version of OSF/Motif 2.1.
 .
 Contains runtime shared libraries for libXm and libMrm.

-- System Information:
Debian Release: 5.0
  APT prefers jaunty-updates
  APT policy: (500, 'jaunty-updates'), (500, 'jaunty-security'), (500,
'jaunty-proposed'), (500, 'jaunty')
Architecture: i386 (i686)



signature.asc
Description: OpenPGP digital signature

Bug#551864: ITP: xcowsay -- Graphical configurable talking cow

[Enrico Zini]

Package: wnpp
Severity: wishlist
Owner: Enrico Zini 

* Package name: xcowsay
  Version : 1.1
  Upstream Author : Nick Gasson 
* URL : http://www.doof.me.uk/xcowsay/
* License : GPL 3 or later
  Programming Lang: C
  Description : Graphical configurable talking cow
   A graphical configurable talking cow. It's a GTK+ version of the
   classic cowsay Perl script. It displays a cute pop-up cow on your
   desktop with a speech bubble and some customizable text. There's
   also a dream mode where the cow can display images. It comes
   with a fortune(6) wrapper script, xcowfortune, which you can cron
   to deliver periodic fortune cookies via the cow. It even has
   a daemon mode which lets you send the cow messages over DBus!



-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: Changes to libc affecting name resolution in chroots?

[Holger Levsen]

Hi,

On Dienstag, 20. Oktober 2009, Dominic Hargreaves wrote:
> One of my development sid chroots has mysteriously been unable to
> download apt lists since around the time of the last upgrade, which
> I noticed upgraded libc6.
>
> My best guess at this point is that something related to this upgrade
> has broken some forms of name resolution, although not completely:
>
> "  Something wicked happened resolving 'mirror.ox.ac.uk:http' (-5)"
>
> The host system is functioning normally, whilst the host(1) command
> both inside and outside the chroot works (with the same resolv.conf).
>
> Host system is lenny / 2.6.26-2-686
>
> Does this sound familiar to anyone?

Yes:

piupar...@piatti:/org/piuparts.debian.org/master/sid$ rgrep -l -e "Failed to 
fetch.*Something wicked happened resolving" fail/*|wc
237 2377713

I'm attaching one log like this to this mail, as I'll cleanup piuparts.d.o 
now... (though I assume piuparts runs will fail instantly again..)

Any hints welcome, unfortunatly I dont have time to dog into this myself 
atm... :(


regards,
Holger
Start: 2009-10-19 17:09:22 UTC

Package: mpich2-doc
Priority: extra
Section: doc
Installed-Size: 3568
Maintainer: Debian Science Maintainers 
Architecture: all
Source: mpich2
Version: 1.2-2
Conflicts: lam-mpidoc, lam4-dev, mpi-doc, openmpi-doc, openmpi-mpidoc
Filename: pool/main/m/mpich2/mpich2-doc_1.2-2_all.deb
Size: 1077398
MD5sum: 8a2d54e34eda47e6594db1a8cbb03e35
SHA1: d90cd38203339d14e79296099c88ce9c3f000496
SHA256: 9bef5b10a08ecba1054d1b6e24543f5eecc950fe1dcbbdb9d2c8a39ab0e7ac63
Description: Documentation for MPICH2
 MPICH2 is a high-performance and widely portable implementation of the
 Message Passing Interface (MPI) standard (both MPI-1 and MPI-2). It
 efficiently supports different computation and communication platforms
 including commodity clusters, SMPs, massively parallel systems, and
 high-speed networks.
 .
 This package includes the MPICH2 documentation.
Homepage: http://www.mcs.anl.gov/research/projects/mpich2/

Executing: sudo /org/piuparts.debian.org/sbin/piuparts --no-symlinks --skip-minimize --scriptsdir /etc/piuparts/scripts/ --tmpdir /org/piuparts.debian.org/tmp -ad sid -b sid.tar.gz --mirror http://piatti.debian.org/debian/ mpich2-doc
Guessed: debian
0m0.0s INFO: --
0m0.0s INFO: To quickly glance what went wrong, scroll down to the bottom of this logfile.
0m0.0s INFO: FAQ available at http://wiki.debian.org/piuparts/FAQ
0m0.0s INFO: --
0m0.0s INFO: piuparts version 0.37~20091019 starting up.
0m0.0s INFO: Command line arguments: /org/piuparts.debian.org/sbin/piuparts --no-symlinks --skip-minimize --scriptsdir /etc/piuparts/scripts/ --tmpdir /org/piuparts.debian.org/tmp -ad sid -b sid.tar.gz --mirror http://piatti.debian.org/debian/ mpich2-doc
0m0.0s INFO: Running on: Linux piatti 2.6.30.8-dsa-amd64 #1 SMP Thu Sep 24 23:43:40 CEST 2009 x86_64
0m0.0s DEBUG: Created temporary directory /org/piuparts.debian.org/tmp/tmppFHiXB
0m0.0s DEBUG: Unpacking sid.tar.gz into /org/piuparts.debian.org/tmp/tmppFHiXB
0m0.0s DEBUG: Starting command: ['tar', '-C', '/org/piuparts.debian.org/tmp/tmppFHiXB', '-zxf', 'sid.tar.gz']
0m3.1s DEBUG: Command ok: ['tar', '-C', '/org/piuparts.debian.org/tmp/tmppFHiXB', '-zxf', 'sid.tar.gz']
0m3.1s DEBUG: Created policy-rc.d and chmodded it.
0m3.1s DEBUG: Starting command: ['chroot', '/org/piuparts.debian.org/tmp/tmppFHiXB', 'apt-get', 'update']
0m5.4s DUMP: 
  Get:1 http://piatti.debian.org sid Release.gpg [835B]
  Get:2 http://piatti.debian.org sid Release [104kB]
  Ign http://piatti.debian.org sid/main Packages/DiffIndex
  Ign http://piatti.debian.org sid/contrib Packages
  Ign http://piatti.debian.org sid/non-free Packages
  Ign http://piatti.debian.org sid/main Packages
  Get:3 http://piatti.debian.org sid/contrib Packages [66.3kB]
  Get:4 http://piatti.debian.org sid/non-free Packages [128kB]
  Get:5 http://piatti.debian.org sid/main Packages [8195kB]
  Fetched 8494kB in 1s (6644kB/s)
  Reading package lists...
0m5.4s DEBUG: Command ok: ['chroot', '/org/piuparts.debian.org/tmp/tmppFHiXB', 'apt-get', 'update']
0m5.4s DEBUG: Starting command: ['chroot', '/org/piuparts.debian.org/tmp/tmppFHiXB', 'mount', '-t', 'proc', 'proc', '/proc']
0m5.4s DEBUG: Command ok: ['chroot', '/org/piuparts.debian.org/tmp/tmppFHiXB', 'mount', '-t', 'proc', 'proc', '/proc']
0m5.4s DEBUG: Starting command: ['chroot', '/org/piuparts.debian.org/tmp/tmppFHiXB', 'apt-get', '-yf', 'upgrade']
0m15.5s DUMP: 
  Reading package lists...
  Building dependency tree...
  The following packages will be upgraded:
bsdutils dhcp3-client dhcp3-common gcc-4.3-base gcc-4.4-base libblkid1
libc-bin libc6 libdevmapper1.02.1 libgcc1 libnewt0.52 libpopt0 libselinux1
libsepol1 libstdc++6 libuuid1 module-init-tools mount procps rsyslog
traceroute tzdata udev util-linux wget whiptail
 

Build logs from local builds

[Wesley W. Terpstra]

I find the buildd logs on https://buildd.debian.org/ to be extremely
useful. They are nicely organized and it's easy to look back in time
and see previous build problems and/or get a quick overview of the
current build status. However, I find there's one piece of data that
is sadly missing: the log from my local build!

debuild and friends generate a .build file along with the .changes
file, but ftp-master obviously doesn't do anything with said build
file. I think it would be quite useful if there were a way for a
maintainer to upload the build log from his own local system. This
would allow interested users to check the logs (in case they suspect
some sort of problem) as well as help maintainers out by giving them a
more complete record of version builds.

Of course, one could argue that the developer doesn't need his own
logs on buildd.debian.org, since he has them locally. However,
sometimes it might be nice to check the status from a different
machine via the web when confronted with an unusual problem. Also, the
buildd systems are more reliable and backed up than most developer's
private systems. Finally, as I mentioned, a user might want to see the
logs too.

What do other people think? Should this be possible? Should this be required?


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: Build logs from local builds

[Daniel Baumann]

Wesley W. Terpstra wrote:
> However, I find there's one piece of data that
> is sadly missing: the log from my local build!

why is the buildlog of the maintainers local build of interest to anyone
when it was announced that ftp-master is planning to throw away the
uploaded binaries from the maintainer anyway?

-- 
Address:Daniel Baumann, Burgunderstrasse 3, CH-4562 Biberist
Email:  daniel.baum...@panthera-systems.net
Internet:   http://people.panthera-systems.net/~daniel-baumann/


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: Build logs from local builds

[Paul Wise]

I've long thought that would be a good idea. However, IIRC the plan is
to drop the .debs built by developers and build each upload on the
buildds. That will mean that the build logs are available for all
architectures. In the meantime, or if this doesn't go ahead after all,
it would be nice if there was the possibility to upload maintainer
build logs.

-- 
bye,
pabs

http://wiki.debian.org/PaulWise


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: Build logs from local builds

[Samuel Thibault]

Wesley W. Terpstra, le Wed 21 Oct 2009 13:02:37 +0200, a écrit :
> What do other people think? Should this be possible? Should this be required?

I confirm that usually not having the i386 or amd64 log is often a
problem.

One idea that was floating around was to have buildd always recompile
the package, even on archs the uploader has provided a binary version
for, to make sure packages are clean.  That would somehow answer you
need (i.e. provide a build log for _all_ archs).

Samuel


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#551870: ITP: python-pytyrant -- Pure python client implementation of the Tokyo Tyrant protocol

[David Watson]

Package: wnpp
Severity: wishlist
Owner: David Watson 
X-Debbugs-CC: debian-devel@lists.debian.org

* Package name: python-pytyrant
  Version : 1.1.17
  Upstream Author : Bob Ippolito 
* URL : http://code.google.com/p/pytyrant/
* License : MIT
  Programming Lang: Python
  Description : Pure python client implementation of the Tokyo Tyrant 
protocol

 A pure python client implementation of the binary Tokyo Tyrant
 protocol. Tokyo Cabinet  is a "super
 hyper ultra database manager" written and maintained by Mikio Hirabayashi and
 released under the LGPL.
 .
 Tokyo Tyrant is the de facto database server for Tokyo Cabinet written and
 maintained by the same author. It supports a REST HTTP protocol, memcached,
 and its own simple binary protocol. This library implements the full binary
 protocol for the Tokyo Tyrant 1.1.17 in pure Python as defined here::
 .   
  http://tokyocabinet.sourceforge.net/tyrantdoc/


-- 
David Watson





-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

732868/450 Sugar ICUMSA45 Spot And High Seas Offer

Hello
1) We introduce ourselves as selling agents for sugar/cement/urea
2) For White Sugar ICUMSA 45 from Brazil;

[Offer # 1]
3.a) Spot Offer [Asia / Africa] = us$ 455/MT

[Offer # 2]
4.b.i) High Sea Offer For Dubai/India/Egypt/Kuwait = us$ 500/MT 12500 MT
4.b.ii) Arrival in 8/10 days

5) Please inform your interest

Best Regards
Kashif Waheed
C&M Commodities And Mercantile
20-Saeed Colony # (1)
213 Faisalabad 38060
Pakistan
Tel: 00923008661624
Fax: 0092418730125



--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: Is it time to remove sun-java6?

[Wim De Smet]

Hi,

On Wed, Oct 21, 2009 at 2:34 AM, Matthias Klose  wrote:
> On 12.10.2009 15:25, Wim De Smet wrote:
>>
>> Hi,
>>
>> On Fri, Oct 9, 2009 at 10:33 PM, Florian Weimer  wrote:
>>>
>>> * Gabor Gombas:
>>>
 - start advertising that openjdk/icedtea is now supposed to be usable,
>>>
>>> Note that the non-applet stuff has been quite usable for a while.
>>> Even the openjdk-6 in lenny is not too bad (it's certainly possible to
>>> run various production loads on it).
>>
>> Last I checked (whatever ubuntu 9.04 used) there were still some major
>> holes in the main class library. Problems where the behaviour of the
>> API just wasn't right. I figured at the time openjdk was just still
>> trailing in functionality and this wasn't supposed to be a full
>> fledged java release. I guess I was wrong and should've bothered to
>> report bugs, but it's definitely not a given that lack of reported
>> bugs == release quality. Couldn't more be done to get users testing it
>> first?
>
> sorry, but that's not more than rants. No bug report, no test case. OpenJDK
> in Ubuntu 9.04 does pass the TCK; if you have trouble with your application
> you should check for uses of sun propriatary APIs.

All you've got is a couple test suites saying it works, but simply not
enough users to back you up on it. Had there been a functioning java
plugin, perhaps those users might not have switched away from openjdk.

As for a specific issue, there's one that comes to mind which is not
technical, but will probably have an impact on many users. Most apps
assume java fonts will just be available. OpenJDK doesn't include
these, so you'll probably end up breaking a great swath of java
desktop applications.

Another bug I remember is problems using fork(), where the jdk shows
completely different behaviour (and both are arguably "correct"). I
believe that one's known upstream and might be fixed by now.

regards,
Wim


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#551874: ITP: i18ndude -- performs various tasks related to ZPT's, Python Scripts and i18n

[TANIGUCHI Takaki]

Package: wnpp
Owner: tak...@debian.org
Severity: wishlist

* Package name: i18ndude
  Version : 3.0
  Upstream Author : Hanno Schlichting 
* URL or Web page : http://pypi.python.org/pypi/i18ndude
* License : GPL
  Description : performs various tasks related to ZPT's, Python Scripts and 
i18n

 i18ndude extracts pot files and performs some other tasks related to
 translating Zope Python and page template code.



-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#551886: ITP: python-anyjson -- Wraps the best available JSON implementation available in a common interface

[David Watson]

Package: wnpp
Severity: wishlist
Owner: David Watson 
X-Debbugs-CC: debian-devel@lists.debian.org

* Package name: python-anyjson
  Version : 0.2.2
  Upstream Author : Rune Halvorsen 
* URL : http://pypi.python.org/pypi/anyjson/
* License : BSD
  Programming Lang: Python
  Description : Wraps the best available JSON implementation available in a 
common interface

 Loads whichever is the fastest JSON module installed and provides
 a uniform API regardless of which JSON implementation is used.

-- 
David Watson







-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: piuparts-MBF: owned and unowned files after purge

[Theppitak Karoonboonyanan]

On Tue, Oct 20, 2009 at 5:11 PM, Holger Levsen  wrote:
>
> On Montag, 19. Oktober 2009, Julien Cristau wrote:
>> Please hold off on the xfonts-* ones.  These are most likely due to a
>> bug in xfonts-utils, so don't need to have individual bugs.

Please make sure to count this one in this category:

  Theppitak Karoonboonyanan 
thaixfonts

> Ok, will do. But http://piuparts.debian.org/sid/source/x/xfonts-utils.html was
> tested successfully?!

It's caused by the way an xfonts-utils script handles alias files.
And the script is called by xfonts packages' postrm via dh_installxfonts.
(See #543512)

Regards,
-- 
Theppitak Karoonboonyanan
http://linux.thai.net/~thep/


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: piuparts-MBF: owned and unowned files after purge

[Holger Levsen]

Hi Theppitak,

On Mittwoch, 21. Oktober 2009, Theppitak Karoonboonyanan wrote:
> It's caused by the way an xfonts-utils script handles alias files.
> And the script is called by xfonts packages' postrm via dh_installxfonts.
> (See #543512)

Thanks. I've raised that one to important now.


regards,
Holger


signature.asc
Description: This is a digitally signed message part.

Re: Changes to libc affecting name resolution in chroots?

[Julien Cristau]

On Wed, Oct 21, 2009 at 12:14:25 +0200, Holger Levsen wrote:

> piupar...@piatti:/org/piuparts.debian.org/master/sid$ rgrep -l -e "Failed to 
> fetch.*Something wicked happened resolving" fail/*|wc
> 237 2377713
> 
> I'm attaching one log like this to this mail, as I'll cleanup piuparts.d.o 
> now... (though I assume piuparts runs will fail instantly again..)
> 
> Any hints welcome, unfortunatly I dont have time to dog into this myself 
> atm... :(
> 
Random guess, your chroot is missing /etc/hosts? (#551760)

Cheers,
Julien


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: Changes to libc affecting name resolution in chroots?

[Holger Levsen]

Hi,

On Mittwoch, 21. Oktober 2009, Julien Cristau wrote:
> Random guess, your chroot is missing /etc/hosts? (#551760)

Yes, /etc/hosts is not there, just like debootstap created it.


regards,
Holger


signature.asc
Description: This is a digitally signed message part.

Bug#551911: ITP: libmoosex-traits-pluggable-perl -- Perl module providing class precedence search for traits

[Jonathan Yu]

Package: wnpp
Owner: Jonathan Yu 
Severity: wishlist
X-Debbugs-CC: debian-devel@lists.debian.org,debian-p...@lists.debian.org

* Package name: libmoosex-traits-pluggable-perl
  Version : 0.08
  Upstream Author : Rafael Kitover 
* URL : http://search.cpan.org/dist/MooseX-Traits-Pluggable/
* License : Artistic | GPL-1+
  Programming Lang: Perl
  Description : Perl module providing class precedence search for traits

 MooseX::Traits::Pluggable extends the functionality of MooseX::Traits (see
 libmoosex-traits-perl) by providing support for class precedence searching
 and some extra attributes.

NOTE: this is needed for libcatalyst-modules-perl (it is currently
FTBFS because of it)



-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

v4tunnel for ipv6: bug in ifupdown, ip or shorewall6 ?

[Vincent Danjean]

  Hi,

  I'm trying to setup a router with ipv6. I found a bug but I do not know
if this is a ifupdown bug, a ip bug, or a shorewall6 bug.

  I've two ipv6 tunnels (one 6to4 tunnel and one from sixxs). So I tried
to setup shorewall6 with two providers ( http://shorewall.net/MultiISP.html ).
With this kind of config, shorewall6 try to duplicate the main routing table
into another one (in fact, two other ones : one per provider).
  I do not know the shorewall6 internal, but it try to run:
ip -6 route add table 1 2002::::/64 via :: dev tun6to4 proto kernel 
metric 256 mtu 1480 advmss 1420 hoplimit 4294967295
In my opinion, this is due to this entry in the main routing table:
# ip -6 route ls
[...]
2002::::/64 via :: dev tun6to4  proto kernel  metric 256  mtu 1480 
advmss 1420 hoplimit 4294967295
[...]

Note here the strange "via ::"

This route is added by ifupdown with the following configuration:
iface tun6to4 inet6 v4tunnel
address 2002::::1
netmask 64
endpoint 192.88.99.1
local XX.XX.YY.YY
gateway ::192.88.99.1
post-up echo 1 > /proc/sys/net/ipv6/conf/all/forwarding

When setting up a static inet6 interface with the following config:
iface br0 inet6 static
address 2002:::1::1
netmask 64
I do not have this "via ::" in the generated route:
# ip -6 route ls
[...]
2002:::1::/64 dev br0  proto kernel  metric 256  mtu 1500 advmss 1440 
hoplimit 4294967295
[...]

If I manually remove the route and try to re-add it, I need to remove the "via 
::"
(but my ipv6 network is also working correctly without this "via ::"):
# ip -6 route del 2002::::/64 via :: dev tun6to4 proto kernel metric 
256 mtu 1480 advmss 1420 hoplimit 4294967295
# ip -6 route add 2002::::/64 via :: dev tun6to4 proto kernel metric 
256 mtu 1480 advmss 1420 hoplimit 4294967295
RTNETLINK answers: Invalid argument
# ip -6 route add 2002::::/64  dev tun6to4 proto kernel metric 256 mtu 
1480 advmss 1420 hoplimit 4294967295
# ip -6 route ls
[...]
2002::::/64 dev tun6to4  proto kernel  metric 256  mtu 1480 advmss 1420 
hoplimit 4294967295
[...]

So, my questions:
- is it a bug in ifupdown that adds this "via ::" when configuring v4tunnel ?
- is it a bug in the "ip" command that should accept the syntax it displays ?
- is it a bug in shorewall6 that should detect this syntax and register the
  route without the "via ::" (or with another syntax to keep "via ::" if this
  is correct) ?

  Regards,
Vincent

PS: there is the same problem with the route of the link-local address
# ip -6 route ls
[...]
fe80::/64 dev br0  proto kernel  metric 256  mtu 1500 advmss 1440 hoplimit 
4294967295
[...]
fe80::/64 via :: dev tun6to4  proto kernel  metric 256  mtu 1480 advmss 1420 
hoplimit 4294967295
[...]

-- 
Vincent Danjean   GPG key ID 0x9D025E87 vdanj...@debian.org
GPG key fingerprint: FC95 08A6 854D DB48 4B9A  8A94 0BF7 7867 9D02 5E87
Unofficial pacakges: http://moais.imag.fr/membres/vincent.danjean/deb.html
APT repo:  deb http://perso.debian.org/~vdanjean/debian unstable main


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: Submitting bugs for manpage improvements

[Simon Paillard]

On Wed, Oct 21, 2009 at 01:02:26AM +0200, Frank Lin PIAT wrote:
> On Tue, 2009-10-20 at 07:17 +0200, Frank Lin PIAT wrote:
> > I have written a small script to make it easy to submit manpage
> > improvements (it's attached).
> > I believe that it much more effective to submit a patch, rather than
> > explaining what needs to be improved. The tool works like quilt...
> [..]
> > There is one issue: most of the bugs will have to be forwarded
> > upstream.[..]
> > 
> > I would get your opinions on how to make this useful/convenient.

1/ l10n:
The current script fails when the manpage is available in both english
and $LANG, because it doesn't keep track for the whole filename

while it could be an opportunity to get feedback no either of
the languages, hence a patch proposal attached, which lets the user
select the exact manpage he wants to patch.

In case of translated manpage, the report may be sent to the right l10n
list instead ?

2/ Format:
One has to remember that such a patch will almost never be
usable as is, because of the source format used to generated this
manpage, either groff directly, or perldoc, po4a, etc.

> I have received some feedback from a developer who is concerned about
> having to deal with the contribution from "nitpickers". I must admit
> that I am concern with bikeshedding and nitpicking too.

I don't think that nitpickers did wait for such a tool to nitpick.

> I had a few ideas... (so far)
> 
> A. We could have a different work-flow for (non)-native package:
>  - For non-native package, we could instruct people to submit the
>diff-file to the upstream maintainer.

I guess that such a behaviour should actually be a warning in reportbug,
if ever the ideas in thread "Per-package link to upstreams bugtracker" #551386

>  - For native package, we could file a bug in Debian BTS.

Option A sound the better to me.

> B. We could provide a way so maintainer could declare whether
>the bug should be filed upstream or to the BTS.
> 
> C. We could ship the tool in a package that is usually installed
>by developers only (shipping the script in a package like 
>devscripts, rather than installing it by default)
> 
> Option A and C looks interesting...


-- 
Simon Paillard
--- man-reportbug.orig	2009-10-21 22:21:25.0 +0200
+++ man-reportbug	2009-10-22 00:50:03.0 +0200
@@ -124,32 +124,50 @@
 fi
 
 # Parse argument(s)
-file=
-COUNT=0
-for file in $(man -a -w $section $page); do
-	f="$(echo $file| xargs -r -n 1 basename | sed -e 's/\..z$//' -e's/\./|/')"
-	basename=$(basename $file | sed -e 's/\..z$//')
-	section=${f#*|}
-	name=${f%|*}
-	apropos -e -s $section $name | grep -E  "^$name\>\s*\($section\)"
-	COUNT=$(($COUNT + 1))
-done
+files=($(man -a -w $section $page))
+COUNT=(${#files[*]})
+
+LINE_INDEX=1
+if [ "$section" ]; then
+	man -f $page -s $section | while read LINE ; 
+		do echo -e "Result $LINE_INDEX:\t $LINE" ;
+		LINE_INDEX=$(($LINE_INDEX + 1))
+		done
+else
+	man -f $page | while read LINE ;
+		do echo -e "Result $LINE_INDEX:\t $LINE" ;
+		LINE_INDEX=$(($LINE_INDEX + 1))
+		done
+fi
 
 
 if [ $COUNT -eq 0 ]; then
 	# man would already print "No manual entry for "
 	quit 1
 elif [ $COUNT -gt 1 ]; then
-	echo "Aborting, there are more than one manpage matching your criteria." >&2
-	quit 1
+	MANPAGE_INDEX=-1
+	# TODO: check that MANPAGE_INDEX is actually a number
+	while [ $MANPAGE_INDEX -ge $COUNT -o $MANPAGE_INDEX -lt 0 ] ;
+		do 
+			echo "There are more than one manpage matching your criteria, select:"
+			read MANPAGE_INDEX
+			MANPAGE_INDEX=$(($MANPAGE_INDEX - 1))
+		done
 fi
 
+echo ${files[*]}
+file=${files[$MANPAGE_INDEX]}
+basename=$(basename $file | sed -e 's/\..z$//')
+section=${f#*|}
+name=${f%|*}
 
 # Searching for the package providing the manpage.
-if [ "$(dpkg-divert --listpackage $file)" ]; then
+if [ -e /usr/bin/dpkg-divert ]; then
+	if [ -a "$(dpkg-divert --listpackage $file)" ]; then
 	diverted=true
 	pkg=$(dpkg-divert --listpackage $file)
 	echo "This file is diverted by package $pkg"
+	fi
 else
 	diverted= ###false###
 	printf "Searching which package ships the file $f\r"
@@ -188,8 +206,11 @@
 MSG
 	(
 	cd $workdir
-	reportbug --offline --no-query-source --no-config-files \
-		-P 'Usertags: man-reportbug' --include=NOTE \
+	if [ ! $(dirname $(dirname $file)) = "/usr/share/man" ] ; then
+		tag="--tag=l10n"
+	fi
+	reportbug --offline --patch --no-query-source --no-config-files \
+		-P 'Usertags: man-reportbug' $tag --include=NOTE \
 		--attach=$diff --attach=$orig $pkg
 	)
 else
#!/bin/sh

# man-reportbug - A simple to contribute manpage improvement
#
## Copyright (C) 2009 Frank Lin PIAT 
##
## All rights reserved.
## 
## Redistribution and use in source and binary forms, with or without
## modification, are permitted provided that the following conditions
## are met:
## 1. Redistributions of source code must retain the above copyright
##notice, this list of conditions and the following disclaimer.
## 2. Redistributions in binary f

Re: Submitting bugs for manpage improvements

[Ben Finney]

Simon Paillard  writes:

> On Wed, Oct 21, 2009 at 01:02:26AM +0200, Frank Lin PIAT wrote:
> > A. We could have a different work-flow for (non)-native package:
> >  - For non-native package, we could instruct people to submit the
> >diff-file to the upstream maintainer.
> >  - For native package, we could file a bug in Debian BTS.
>
> Option A sound the better to me.

Why? Specifically, why should this type of “severity: minor” bug report
require a different workflow than other “severity: minor” bugs reports?
Why is it worth, in your opinion, the loss of the Debian BTS for
tracking the report?

-- 
 \  “Reichel's Law: A body on vacation tends to remain on vacation |
  `\unless acted upon by an outside force.” —Carol Reichel |
_o__)  |
Ben Finney


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#551965: ITP: eclipse-rse -- Eclipse Remote System Explorer (RSE)

[Niels Thykier]

Package: wnpp
Severity: wishlist
Owner: Niels Thykier 

* Package name: eclipse-rse
  Version : 3.1
  Upstream Author : DSDP TM Development Team 
* URL : http://www.eclipse.org/dsdp/tm/
* License : Eclipse Public License Version 1.0 ("EPL")
  Programming Lang: Java
  Description : Eclipse Remote System Explorer (RSE)

Remote System Explorer is a framework and toolkit in Eclipse Workbench 
that allows you to connect and work with a variety of remote systems.


Notes:
This is a Dependency for upgrading eclipse-cdt and also eclipse-dltk 
(and possible others)

~Niels



-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org