[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Restoring the removed e16 package

On 08/28/2012 06:51 AM, Ian Jackson wrote:

The Wanderer writes ("Restoring the removed e16 package"):

I'm not positive whether this properly belongs here; if it would be more
appropriate on another mailing list, just let me know which one.

On this point, I've already been advised (by Bart Martens, in off-list mail)
that debian-mentors would probably be a more appropriate venue. The only reason
I haven't posted over there yet is that I'm still digging through the bugs and
trying to work out an appropriate starting point (especially given the nature of
some of those bugs), so that I know exactly what I want to post.

As e17 does not constitute a suitable replacement for e16 for my purposes,
I have an interest in seeing e16 continue to be available via Debian. What
would I need to do to get this package added back in?

Find someone (preferably a team) to be the maintainers, prepare a suitable
package, get someone to sponsor it, and reopen all the bugs which were closed
by the removal.

I'm a little surprised by this last point. Since I wouldn't have thought it
would seem appropriate to add (or re-add) a known-buggy package to the
repository, I would have thought getting the package restored would involve
finding fixes for all of those bugs first, and there wouldn't seem to be much
point in reopening bugs just to close them again - either because they're fixed
in the re-added package, or because the attempt to restore the package didn't
work out.

The only reason I can think of would be documentation - to record that the bug
has in fact been officially fixed, rather than simply lost in the shuffle. Is
that the only reason for that step, or is there more which I'm missing?

I would be willing to assume maintainership of the e16 Debian package if
that is what it would take, although I do not know whether I have the skill
to be able to do a good job of it.

If you aren't confident of your ability to do this yourself, you should see
if you can find other people to help.

While that's obviously good advice, it's also potentially easier said than done.

The only other people I currently know of who care about e16 and have any
technical skill are the former package maintainer, several members of my current
household (most of whom would be at least as inclined to just compile it
themselves), and the current upstream maintainer. I also haven't yet found any
e16-related communities or discussion forums in which to look for others (except
for the general Enlightenment mailing lists, which are mostly swamped with e17
these days).

While the upstream maintainer can probably help with the program itself, it
wouldn't be terribly nice to just try to dump everything on (her?), and the
packaging work is another question.

Overall, while I certainly wouldn't mind having help, I don't think I can in
good conscience take up the maintainer role without being able to handle it all
myself if I need to.

I am reading the Debian New Maintainers' Guide to educate myself on what
would be involved with maintaining a package, beyond the obvious, and on
how to go about getting a package added to Debian. However, since this
package was previously in the repository and has been removed, it seems
likely that there would be additional considerations beyond those
associated with a new package.

Yes.  The new upload should be prepared using the previously-removed package
as a starting point.

That's been my plan since the beginning. There is at least one bug that makes
doing this in the most straightforward way (reintroducing the removed package
version verbatim, then making changes off of that) questionably appropriate, but
that's what I've been working on in the interim since posting.

Given the previous removal of this package, the reasons cited for that
removal, and the (I infer) relative imminence of a new stable release, what
further requirements and/or deadlines would I need to keep in mind as I
work on this, and what possible further procedures (beyond those in the
new-package documentation) would I need to follow?

I think it is probably now too late to reintroduce e16 in wheezy.

Unfortunate, but not hugely surprising. I presume a later backport would still
be reasonable?

However your work on e16 probably won't interfere with the wheezy release so
you don't need to do anything special.

The toolchain-related bug seems to be (at least) this one:

Ah. No wonder I didn't find that one; I was looking at bugs against e16 and
e16-data, not the corresponding source package. (I hadn't even previously
realized that you *could* search for, or even file, bugs against a source
package separately.)

The description of the problem as reported in that bug is a little confusing
(the ld.bfd man page seems to match what the bug says is default for
binutils-gold, and the ld.gold man page seems to match the reverse), but the
symptoms do manifest as described.

Initial testing indicates that that bug seems to be fixed in the current
upstream version. Would it be more appropriate to update to that version (which
has other fixes, and which I want to update to as soon as appropriate anyway),
or to backport the fix to the packaged version?

      The Wanderer

Warning: Simply because I argue an issue does not mean I agree with any
side of it.

Every time you let somebody set a limit they start moving it.
  - LiveJournal user antonia_tiger

Reply to: