RFS: lesstif2 AND Questions about collab-maint

[Paul Gevers]

Hi mentors and mentees,

[Sorry for the long mail, there are several issues/questions.]

I am looking for a thourough check of my packaging and preferably a
sponsor for the new version 1:0.95.2-1 of my package "lesstif2" [0].
This new upstream version is only the incorporation of a lot of patches
already incorporated in the current version of lesstif2 in Debian.

Lesstif2 has been moved to collab-maint [1], because the original
maintainer, Sam Hocevar, agreed that I could co-maintain lesstif2 with
him. However, Sam Hocevar, hasn't responded to my last e-mails about
checking the packaging and uploading. He previously suggested mailing
the other collab-maint people in parallel, so that they could sponsor. I
tried the collab-maint-devel@... email address, but
that doesn't exist anymore. Now I am looking for the best way to ask for
a check of the packaging. Would anybody know the way to reach the
collab-maint people? Or is this list the most appropriate place anyway?
In the latter case, do I understand correctly that mentors still want an
upload to mentors.d.n? Just in case for the latter, I build the package
and uploaded to m.d.n [2]. I would appreciate comments (changelog at the
bottom of this mail [3]).

lesstif2 builds these binary packages:
lesstif-bin - user binaries for LessTif
lesstif-doc - documentation for LessTif
lesstif2   - OSF/Motif 2.1 implementation released under LGPL
lesstif2-dbg - lesstif2 debugging files
lesstif2-dev - development library and header files for LessTif 2.1

The upload would fix this bug: 409093

The package is NOT completely lintian free (39 times the next warning):
"""
W: lesstif-doc: manpage-has-errors-from-man
usr/share/man/man3/<man>.3.gz  around line <num>: table wider than line
width
"""
To solve this I need to re-arrange a lot of tables. Does anybody know a
nice way to order them? Currently it is like:
       Name                      Class                     Type
Default   Access

--------------------------------------------------------------------------------
       XtNx                      XtCPosition               Position
NULL      CSG
My suggestion would be something like (is this readable?):
       Name                      Class                     Type
                                                           Default
                                                           Access
       -------------------------------------------------------------
       XtNx                      XtCPosition               Position
                                                           NULL
                                                           CSG

With kind regards
Paul

[0] LessTif, made by the Hungry Programmers, is a free (LGPL-ed) version
of OSF/Motif; it aims ultimately at binary compatibility with Motif 2.1.

[1] http://svn.debian.org/viewsvn/collab-maint/deb-maint/lesstif2/

[2] The package can be found on mentors.debian.net:
- URL: http://mentors.debian.net/debian/pool/main/l/lesstif2
- Source repository: deb-src http://mentors.debian.net/debian unstable
main contrib non-free
- dget
http://mentors.debian.net/debian/pool/main/l/lesstif2/lesstif2_0.95.2-1.dsc

[3]
lesstif2 (1:0.95.2-1) unstable; urgency=low

  [Sam Hocevar]
  * Acknowledging past NMUs. Thanks to Aaron M. Ucko and Paul Gevers, who
    now co-maintains this package (Closes: #396199, #479779, #503361,
#314440,
    Closes: #43640, #87745, #356017, #496081, #330057, #439186).
  * debian/control:
    + Add Paul Gevers to the uploaders list.
    + Update Vcs fields.

  [Paul Gevers]
  * New upstream release (dropping deprecated patches)
    - 020_bad_integer_cast.diff (solved upstream)
    - 020_unsigned_int.diff (included upstream)
    - 021_xim_chained_list_crash.diff (included upstream)
    - 031_fix_inverted_scrollwheel.diff (included upstream)
    - 031_shutup_xtungrabbutton.diff (included upstream)
    - 040_fedora_accelkeys.diff (included upstream)
    - 040_fedora_c++fix.diff (included upstream)
    - 040_fedora_text.diff (included upstream)
    - 050_cvs_invalid_pointer.diff (was from upstream)
    - 050_cvs_1773603_invalid_pointer_TextOut.c.diff (was from upstream)
    - 050_cvs_1773603_invalid_pointer_List.c.diff (was from upstream)
    - 050_cvs_1773603_invalid_pointer_Label.c.diff (was from upstream)
    - 050_cvs_1773603_invalid_pointer_LabelG.c.diff (was from upstream)
    - 050_cvs_class_initialize_DialogS.c.diff (was from upstream)
    - 050_cvs_attachbottom_Form.c.diff (was from upstream)
    - 060_update_manpages (included upstream)
    - 071_fix_crash_on_ESC_Traversal.c (included upstream)
    Remaining patches (updated descriptions, conform current DEP3
    proposal):
    - 000_bootstrap_script.diff (updated, in sync with upstream CVSMake)
    - 000_libtool_linking.diff (leave as is, debian specific, path)
    - 010_rebootstrap (updated, see also 000_bootstrap_script.diff)
    - 020_missing_xm_h.diff (not included upstream yet)
    - 020_render_table_crash.diff (in upstream cvs)
    - 020_xpmpipethrough.diff (not included upstream yet)
    - 030_manpage.diff (not included upstream, debian specific, path)
    - 031_use_X11_Xtos_header.diff (in upstream cvs)
    - 040_fedora_XxxxProperty-64bit.diff updated to prevent segfault on
      i386 when copy/pasting. Updated with courtesy from Hans de Goede
      (Fedora) (in upstream cvs)
    - 080_fix_spelling-error-in-binary (not included upstream yet,
      updated)
    Added patches
    - 030_manpage_Virtualbindings to fix manpage-section-mismatch
      (lintian)
    - 005_libtool_LT_HAVE.diff to fix a libtool error:
      possibly undefined macro: LT_HAVE_FREETYPE and LT_HAVE_XRENDER
    - 005_libtool_obsolete.diff to fix autoconf warnings about obsolete
      MACRO's.
    - 040_fedora_PutPixel32.diff fixes PutPixel32 crashing on 64 bit
      completly, with courtesy from Hans de Goede (Fedora)
      (Closes: #409093) (in upstream cvs)
  * debian/control
    - Update policy to 3.8.3 (no changes needed)
    - Add ${misc:Depends} to all depends fields (lintian)
  * debian/rules
    - Add DEB_HOST_GNU_TYPE and DEB_BUILD_GNU_TYPE to CARGS in line with
      /usr/share/doc/autotools-dev/README.Debian.gz
    - Removed CARGS without-freetype-config without-fontconfig-config
      because freetype is a build depend and configure can't cope (bug?)
    - Removed deprecated dh_desktop call
  * Create debugging symbols for lesstif2 (-dbg package)
  * Added README.source to confirm to policy 4.14 (lintian)
  * Fixed categories in debian/lesstif-bin.desktop (copied by accident
    from an other package).

 -- Paul Gevers <paul@...>  Wed, 21 Oct 2009 08:58:30 +0200

[Sandro Tosi-4]

Hi Paul,
first of all, thanks for your work in Debian

On Wed, Oct 21, 2009 at 09:57, Paul Gevers <paul@...> wrote:
> Hi mentors and mentees,
>
> [Sorry for the long mail, there are several issues/questions.]
>
> I am looking for a thourough check of my packaging and preferably a
> sponsor for the new version 1:0.95.2-1 of my package "lesstif2" [0].

sorry, I'm short with free time now, but I'm going to aswer about collab-maint

> Lesstif2 has been moved to collab-maint [1], because the original
> maintainer, Sam Hocevar, agreed that I could co-maintain lesstif2 with
> him. However, Sam Hocevar, hasn't responded to my last e-mails about
> checking the packaging and uploading. He previously suggested mailing
> the other collab-maint people in parallel, so that they could sponsor. I
> tried the collab-maint-devel@... email address, but
> that doesn't exist anymore. Now I am looking for the best way to ask for
> a check of the packaging. Would anybody know the way to reach the
> collab-maint people?

I don't think contacting other people on collab-maint is the right
choice: collab-maint is a place where to collaboratively maintain
packages between more developers (but FWIW even for single-person
maintained packages) and have a common repository in the place
provided by debian for it: Alioth.

> Or is this list the most appropriate place anyway?

Yes, I think that debian-mentors is the right place to ask for such requests.

> In the latter case, do I understand correctly that mentors still want an
> upload to mentors.d.n? Just in case for the latter, I build the package
> and uploaded to m.d.n [2].

Ideally, the sponsor would take the source package uploaded to m.d.n,
build it in a clean&updated chroot (like pbuilder) and upload it
(well, there are several other checks, not worthing mention here)
without doing any modification to the source package. So, having that
already available on mentors is usually better then asking sponsor to
checkout the VCS, find somehow the tarball etc etc.

Of course, this is a per-sponsor decision :)

Cheers,
--
Sandro Tosi (aka morph, morpheus, matrixhasu)
My website: http://matrixhasu.altervista.org/
Me at Debian: http://wiki.debian.org/SandroTosi


--
To UNSUBSCRIBE, email to debian-mentors-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[Paul Gevers]

Hi mentors,

Paul Gevers wrote:
> I am looking for a thourough check of my packaging and preferably a
> sponsor for the new version 1:0.95.2-1 of my package "lesstif2" [0].
> This new upstream version is only the incorporation of a lot of patches
> already incorporated in the current version of lesstif2 in Debian.

Just one download of the package from mentors by a non-sponsor. I am
still interested in reviews and comments. Of course an upload would be
great. At the moment I am unemployed and have the time to work on
lesstif (upstream as well) but I prefer the 0.95.2 version to be in
Debian to work from.

<snip>

> lesstif2 builds these binary packages:
> lesstif-bin - user binaries for LessTif
> lesstif-doc - documentation for LessTif
> lesstif2   - OSF/Motif 2.1 implementation released under LGPL
> lesstif2-dbg - lesstif2 debugging files
> lesstif2-dev - development library and header files for LessTif 2.1
>
> The upload would fix this bug: 409093
>
> The package is NOT completely lintian free (39 times the next warning):
> """
> W: lesstif-doc: manpage-has-errors-from-man
> usr/share/man/man3/<man>.3.gz  around line <num>: table wider than line
> width
> """
> To solve this I need to re-arrange a lot of tables. Does anybody know a
> nice way to order them? Currently it is like:
>        Name                      Class                     Type
> Default   Access
>
> --------------------------------------------------------------------------------
>        XtNx                      XtCPosition               Position
> NULL      CSG
> My suggestion would be something like (is this readable?):
>        Name                      Class                     Type
>                                                            Default
>                                                            Access
>        -------------------------------------------------------------
>        XtNx                      XtCPosition               Position
>                                                            NULL
>                                                            CSG
>

With kind regards,
Paul

> [0] LessTif, made by the Hungry Programmers, is a free (LGPL-ed) version
> of OSF/Motif; it aims ultimately at binary compatibility with Motif 2.1.
>
> [1] http://svn.debian.org/viewsvn/collab-maint/deb-maint/lesstif2/
>
> [2] The package can be found on mentors.debian.net:
> - URL: http://mentors.debian.net/debian/pool/main/l/lesstif2
> - Source repository: deb-src http://mentors.debian.net/debian unstable
> main contrib non-free
> - dget
> http://mentors.debian.net/debian/pool/main/l/lesstif2/lesstif2_0.95.2-1.dsc
>
> [3]
> lesstif2 (1:0.95.2-1) unstable; urgency=low
>
>   [Sam Hocevar]
>   * Acknowledging past NMUs. Thanks to Aaron M. Ucko and Paul Gevers, who
>     now co-maintains this package (Closes: #396199, #479779, #503361,
> #314440,
>     Closes: #43640, #87745, #356017, #496081, #330057, #439186).
>   * debian/control:
>     + Add Paul Gevers to the uploaders list.
>     + Update Vcs fields.
>
>   [Paul Gevers]
>   * New upstream release (dropping deprecated patches)
>     - 020_bad_integer_cast.diff (solved upstream)
>     - 020_unsigned_int.diff (included upstream)
>     - 021_xim_chained_list_crash.diff (included upstream)
>     - 031_fix_inverted_scrollwheel.diff (included upstream)
>     - 031_shutup_xtungrabbutton.diff (included upstream)
>     - 040_fedora_accelkeys.diff (included upstream)
>     - 040_fedora_c++fix.diff (included upstream)
>     - 040_fedora_text.diff (included upstream)
>     - 050_cvs_invalid_pointer.diff (was from upstream)
>     - 050_cvs_1773603_invalid_pointer_TextOut.c.diff (was from upstream)
>     - 050_cvs_1773603_invalid_pointer_List.c.diff (was from upstream)
>     - 050_cvs_1773603_invalid_pointer_Label.c.diff (was from upstream)
>     - 050_cvs_1773603_invalid_pointer_LabelG.c.diff (was from upstream)
>     - 050_cvs_class_initialize_DialogS.c.diff (was from upstream)
>     - 050_cvs_attachbottom_Form.c.diff (was from upstream)
>     - 060_update_manpages (included upstream)
>     - 071_fix_crash_on_ESC_Traversal.c (included upstream)
>     Remaining patches (updated descriptions, conform current DEP3
>     proposal):
>     - 000_bootstrap_script.diff (updated, in sync with upstream CVSMake)
>     - 000_libtool_linking.diff (leave as is, debian specific, path)
>     - 010_rebootstrap (updated, see also 000_bootstrap_script.diff)
>     - 020_missing_xm_h.diff (not included upstream yet)
>     - 020_render_table_crash.diff (in upstream cvs)
>     - 020_xpmpipethrough.diff (not included upstream yet)
>     - 030_manpage.diff (not included upstream, debian specific, path)
>     - 031_use_X11_Xtos_header.diff (in upstream cvs)
>     - 040_fedora_XxxxProperty-64bit.diff updated to prevent segfault on
>       i386 when copy/pasting. Updated with courtesy from Hans de Goede
>       (Fedora) (in upstream cvs)
>     - 080_fix_spelling-error-in-binary (not included upstream yet,
>       updated)
>     Added patches
>     - 030_manpage_Virtualbindings to fix manpage-section-mismatch
>       (lintian)
>     - 005_libtool_LT_HAVE.diff to fix a libtool error:
>       possibly undefined macro: LT_HAVE_FREETYPE and LT_HAVE_XRENDER
>     - 005_libtool_obsolete.diff to fix autoconf warnings about obsolete
>       MACRO's.
>     - 040_fedora_PutPixel32.diff fixes PutPixel32 crashing on 64 bit
>       completly, with courtesy from Hans de Goede (Fedora)
>       (Closes: #409093) (in upstream cvs)
>   * debian/control
>     - Update policy to 3.8.3 (no changes needed)
>     - Add ${misc:Depends} to all depends fields (lintian)
>   * debian/rules
>     - Add DEB_HOST_GNU_TYPE and DEB_BUILD_GNU_TYPE to CARGS in line with
>       /usr/share/doc/autotools-dev/README.Debian.gz
>     - Removed CARGS without-freetype-config without-fontconfig-config
>       because freetype is a build depend and configure can't cope (bug?)
>     - Removed deprecated dh_desktop call
>   * Create debugging symbols for lesstif2 (-dbg package)
>   * Added README.source to confirm to policy 4.14 (lintian)
>   * Fixed categories in debian/lesstif-bin.desktop (copied by accident
>     from an other package).
>
>  -- Paul Gevers <paul@...>  Wed, 21 Oct 2009 08:58:30 +0200
>

[George Danchev]

> Hi mentors,

Hi,
 

> Paul Gevers wrote:
> > I am looking for a thourough check of my packaging and preferably a
> > sponsor for the new version 1:0.95.2-1 of my package "lesstif2" [0].
> > This new upstream version is only the incorporation of a lot of patches
> > already incorporated in the current version of lesstif2 in Debian.
>
> Just one download of the package from mentors by a non-sponsor. I am
> still interested in reviews and comments. Of course an upload would be
> great. At the moment I am unemployed and have the time to work on
> lesstif (upstream as well) but I prefer the 0.95.2 version to be in
> Debian to work from.

Since it seems you have put so much work and time into that package, I guess
you deserve at least an honest reply ;-)

I'm not familiar with the lesstif2 concepts and internals, which doesn't seem
to be trivial at all, so I wouldn't be able to properly review and upload, but
I think that, in general, before putting considerable amount of work into
whatever neglected or understaffed package, it is a good idea to sound the
interest and intentions of your prospective sponsors. That might eventually
avoid wasting sponsoree's own time. Otherwise, taking care of such packages is
very welcome, indeed, so I hope you find a proper sponsor!

--
pub 4096R/0E4BD0AB <people.fccf.net/danchev/key pgp.mit.edu>


--
To UNSUBSCRIBE, email to debian-mentors-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[Paul Gevers]

I had to let your message sink in....

George Danchev wrote:

> Since it seems you have put so much work and time into that package,
> I guess you deserve at least an honest reply ;-)

Thanks.

> I'm not familiar with the lesstif2 concepts and internals, which
> doesn't seem to be trivial at all, so I wouldn't be able to properly
> review and upload, but I think that, in general, before putting
> considerable amount of work  into whatever neglected or understaffed
> package, it is a good idea to sound the  interest and intentions of
> your prospective sponsors. That might eventually  avoid wasting
> sponsoree's own time. Otherwise, taking care of such packages is very
> welcome, indeed, so I hope you find a proper sponsor!

I do agree that the internals of lesstif2 are not trivial. However
according to popcon [1] it is a highly popular (if that can be said of a
library), which has received very little attention (both upstream and in
Debian). I am working, albeit slowly, together with the Fedora
maintainer of lesstif2, because he also thinks that the large distro's
should team up to resurrect lesstif. My maintenance work on upstream
(the new release) has been taken up by several distro's, but not by
Debian, where I started to do the work for. I agreed with Sam Hocevar,
the maintainer of lesstif2, that I could co-maintain, but he already
said that I should also seek elsewhere for uploads in case he did not
respond.

Now do I understand correctly that you mean that I should sorta search
for a sponsor in advance? As said, I basically have a sponsor, but he is
not very responsive. Furthermore, my sponsor for Nedit also promised
that he could have a look at it, but apparently he also has different
priorities. For those reasons I am looking on this list as well.

The changes with respect to the previous version of lesstif2 in Debian
are not that big (remember that most changes in upstream are already
applied in the current Debian version) and mainly two things:
"rebootstrapping", ie running
libtoolize/aclocal/autoconf/autoheader/automake again (script in
debian/patches/000_bootstrap_script.diff) and fixing several obsoleted
macro functions (005_libtool_obsolete.diff).

Next Sunday I will start working with a friend on a problematic part of
lesstif, which is related to bug 545672 [2]. Copy/paste is not very well
implemented and causes strange behavior when a clipboard manager is
working. Now, I don't know much yet about icccm, but we'll try to figure
it out. Apart from helping FOSS, I also consider this a learning
experience for myself, so I do not consider my time waisted.

Paul

[1] http://qa.debian.org/popcon.php?package=lesstif2
[2] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=545672

[George Danchev]

Hi,

> I had to let your message sink in....

Hm, did I write something weird or hard to grind? If so, I'd try to rephrase
my point.
 

> George Danchev wrote:
> > Since it seems you have put so much work and time into that package,
> > I guess you deserve at least an honest reply ;-)
>
> Thanks.
>
> > I'm not familiar with the lesstif2 concepts and internals, which
> > doesn't seem to be trivial at all, so I wouldn't be able to properly
> > review and upload, but I think that, in general, before putting
> > considerable amount of work  into whatever neglected or understaffed
> > package, it is a good idea to sound the  interest and intentions of
> > your prospective sponsors. That might eventually  avoid wasting
> > sponsoree's own time. Otherwise, taking care of such packages is very
> > welcome, indeed, so I hope you find a proper sponsor!
>
> I do agree that the internals of lesstif2 are not trivial. However
> according to popcon [1] it is a highly popular (if that can be said of a
> library), which has received very little attention (both upstream and in
> Debian).

Eventually, such a popularity could be explained as 'past glory'; it was
popular once, but with the advent of more advanced windowing/widget/ui
toolkits it probably still stays on user machines largely unused and mostly
obsoleted.

> I am working, albeit slowly, together with the Fedora
> maintainer of lesstif2, because he also thinks that the large distro's
> should team up to resurrect lesstif. My maintenance work on upstream
> (the new release) has been taken up by several distro's, but not by
> Debian, where I started to do the work for.

Yeah, I see that human time has been invested and the result is left
unaddressed until that point for various reasons, including prosaic. Please,
don't get me wrong, taking care of existing packages and the packages
dependent on them is a good thing, however I personally have misgivings with
resurrecting already dead or bit rotten code bases which that implementation
of Motif appears to be. (and yes, I'm a former user of CDE and some other
Motif applications, but as of today I'd let them rest in piece, honestly ;-)

> I agreed with Sam Hocevar,
> the maintainer of lesstif2, that I could co-maintain, but he already
> said that I should also seek elsewhere for uploads in case he did not
> respond.

I suspect he is mostly interested in wxwidgets presently.
 
> Now do I understand correctly that you mean that I should sorta search
> for a sponsor in advance? As said, I basically have a sponsor, but he is
> not very responsive. Furthermore, my sponsor for Nedit also promised
> that he could have a look at it, but apparently he also has different
> priorities. For those reasons I am looking on this list as well.

Well, yes. Having sponsors interest nicely presented on your radar for an
ancient package like that, would certainly help you to adjust your priorities
soon. IMO, lesstif and dependents are far beyond their life cycle, and I'm not
at all sure if I personally want to see them in our next stable release. That
is my opinion, other might disagree.

> The changes with respect to the previous version of lesstif2 in Debian
> are not that big (remember that most changes in upstream are already
> applied in the current Debian version) and mainly two things:
> "rebootstrapping", ie running
> libtoolize/aclocal/autoconf/autoheader/automake again (script in
> debian/patches/000_bootstrap_script.diff) and fixing several obsoleted
> macro functions (005_libtool_obsolete.diff).

I don't know about security of release teams, but my eyes hurt badly when I
look at ancient code base like that, but that is just me ;-)

> Next Sunday I will start working with a friend on a problematic part of
> lesstif, which is related to bug 545672 [2]. Copy/paste is not very well
> implemented and causes strange behavior when a clipboard manager is
> working. Now, I don't know much yet about icccm, but we'll try to figure
> it out. Apart from helping FOSS, I also consider this a learning
> experience for myself, so I do not consider my time waisted.

Okay, I respect your point and your time. I just tried to give some pointers
eventually to explain the lack of interest of your prospective sponsors.

--
pub 4096R/0E4BD0AB <people.fccf.net/danchev/key pgp.mit.edu>


--
To UNSUBSCRIBE, email to debian-mentors-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[Paul Gevers]

>> I had to let your message sink in....
>
> Hm, did I write something weird or hard to grind? If so, I'd try to rephrase
> my point.

No, more about what it meant for me.

> Eventually, such a popularity could be explained as 'past glory'; it was
> popular once, but with the advent of more advanced windowing/widget/ui
> toolkits it probably still stays on user machines largely unused and mostly
> obsoleted.

Understood and exactly what I thought.

> IMO, lesstif and dependents are far beyond their life cycle, and I'm not
> at all sure if I personally want to see them in our next stable release. That
> is my opinion, other might disagree.

Absolutely fine with me. But maybe Debian should decide on that (lesstif
is specifically mentioned in the policy btw) and just request the
removal of the package (and it dependents). If so I won't need to pull a
dead horse, and move on to other things as well. My interest was with
Debian, not specifically with lesstif or any of its dependents. I do
have the time and the will to invest in FOSS/Debian, but maybe I decided
on the wrong project? I don't necessarily want to get new packages in so
I decided to adopt, but how to chose?

> Okay, I respect your point and your time. I just tried to give some pointers
> eventually to explain the lack of interest of your prospective sponsors.

Point taken. I will do what I want to do with lesstif next weekend/weeks
and if nobody steps up to sponsor I will leave it on mentors and on
Alioth and just provide a package at Launchpad [1] for a while.

A side note: I do have the feeling that Debian is not so well in
removing packages that are over age. Shouldn't there be a policy on that
as well? More than just RC bugs that warrant their removal around
release time? Getting a new package in when there already exist a
package which is similar is difficult, but removing one is apparently
not lightly done either.

Paul
[1] https://launchpad.net/~paul-climbing/+archive/lesstif+nedit

[Boyd Stephen Smith Jr.-3]

On Thursday 05 November 2009 11:16:08 Paul Gevers wrote:
> My interest was with
> Debian, not specifically with lesstif or any of its dependents. I do
> have the time and the will to invest in FOSS/Debian, but maybe I decided
> on the wrong project? I don't necessarily want to get new packages in so
> I decided to adopt, but how to chose?

In the order I think it is best to resolve them:

rc-alert -- Packages you have installed with release-critical bugs.  See
individual bugs or contact the maintainer(s) to see if you can help.

wnpp-alert -- Package you have installed that have open WNPP bugs.  See
individual bugs or contact the maintainer(s) to see how you can help.

<http://bugs.qa.debian.org/cgi-bin/base.cgi> -- Bugs in the base system.  See
individual bugs or contact the maintainer(s) to see if you can help.

<http://bugs.qa.debian.org/cgi-bin/standard.cgi> -- Bugs in the standard
system or tasks.  See individual bugs or contact the maintainer(s) to see if
you can help.

<http://bugs.debian.org/release-critical/> -- All release-critical bugs.  See
individual bugs of contact the maintainer(s) to see if you can help.

If you get dome with all of that, I have a immovable object that needs
relocated. ;)
--
Boyd Stephen Smith Jr.           ,= ,-_-. =.
bss@...             ((_/)o o(\_))
ICQ: 514984 YM/AIM: DaTwinkDaddy `-'(. .)`-'
http://iguanasuicide.net/            \_/

[George Danchev]

> >> I had to let your message sink in....
> >
> > Hm, did I write something weird or hard to grind? If so, I'd try to
> > rephrase my point.
>
> No, more about what it meant for me.
>
> > Eventually, such a popularity could be explained as 'past glory'; it was
> > popular once, but with the advent of more advanced windowing/widget/ui
> > toolkits it probably still stays on user machines largely unused and
> > mostly obsoleted.
>
> Understood and exactly what I thought.
>
> > IMO, lesstif and dependents are far beyond their life cycle, and I'm not
> > at all sure if I personally want to see them in our next stable release.
> > That is my opinion, other might disagree.
>
> Absolutely fine with me. But maybe Debian should decide on that (lesstif
> is specifically mentioned in the policy btw) and just request the
> removal of the package (and it dependents). If so I won't need to pull a
> dead horse, and move on to other things as well. My interest was with
> Debian, not specifically with lesstif or any of its dependents. I do
> have the time and the will to invest in FOSS/Debian, but maybe I decided
> on the wrong project? I don't necessarily want to get new packages in so
> I decided to adopt, but how to chose?

I saw that Boyd Stephen Smith Jr. already gave useful pointers; to these I
would add that KDE and GNOME packaging teams would welcome more man power, as
they recently share here and there; I'm not sure if you could be interested in
their work, but if so, saying 'hi' in their packaging lists might be another
nice option for you to go for, and certainly for them.

> > Okay, I respect your point and your time. I just tried to give some
> > pointers eventually to explain the lack of interest of your prospective
> > sponsors.
>
> Point taken. I will do what I want to do with lesstif next weekend/weeks
> and if nobody steps up to sponsor I will leave it on mentors and on
> Alioth and just provide a package at Launchpad [1] for a while.

Sounds like a good plan to me.

> A side note: I do have the feeling that Debian is not so well in
> removing packages that are over age. Shouldn't there be a policy on that
> as well? More than just RC bugs that warrant their removal around
> release time? Getting a new package in when there already exist a
> package which is similar is difficult, but removing one is apparently
> not lightly done either.

Correct, package removals are not completely reciprocal to package additions,
though both must be performed with care and rigor. I don't think I have an
ultimate answer to these, so a broader discussion is certainly preferred and
it actually happens from time to time in BTS logs or debian-devel list.

> Paul
> [1] https://launchpad.net/~paul-climbing/+archive/lesstif+nedit

Thanks for your interest in Debian distribution.
 
--
pub 4096R/0E4BD0AB <people.fccf.net/danchev/key pgp.mit.edu>


--
To UNSUBSCRIBE, email to debian-mentors-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[Charles Plessy-12]

Le Thu, Nov 05, 2009 at 06:16:08PM +0100, Paul Gevers a écrit :
>
> Point taken. I will do what I want to do with lesstif next weekend/weeks
> and if nobody steps up to sponsor I will leave it on mentors and on
> Alioth and just provide a package at Launchpad [1] for a while.

Dear Paul,

do not hesitate to ping the maintainers of packages that depend on lesstif for
this task. I am one of them, but I lack the competence for reviewing changes made
to a graphical toolkit library. But sometimes the changes are trivial or do not
go outsite the /debian directory. In that case, I can sponsor.

About removals, the most difficult is to keep momentum, because it often
implies a check for activity of the maintainer, and in the case of no answer,
it is usually preferred to wait a couple of weeks, and after that moment we end
up busy doing something else :)

If you help Debian to let lesstif dissapear smoothly, this would be a great
contribution.  You can look at the result of the command apt-cache rdepends
lesstif2. Maybe there are obsolete packages that can already be removed ?
For the others, you can as the upstream authors if they have plans to switch
to another toolkit. In the case of the packages I maintain, I have seen this
two times already, for seaview and clustalw.

Have a nice day,

--
Charles Plessy
Debian Med packaging team,
http://www.debian.org/devel/debian-med
Tsurumi, Kanagawa, Japan


--
To UNSUBSCRIBE, email to debian-mentors-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[Paul Gevers]

Charles Plessy wrote:
> do not hesitate to ping the maintainers of packages that depend on lesstif for
> this task.

Aaron M. Ucko was so kind to sponsor lesstif2. As the maintainer of a
dependent package he rather keeps lesstif2 in the archive. :)

Hopefully, I can get some long standing bugs out of lesstif so that it
can remain in Debian for those packages still depending on it.
Surprisingly to me, there are quite a lot of active packages depending
on it.

With kind regards
Paul