[Pkg-mc-devel] Midnight Comander 4.8.1 [RFS]

[Dmitry Smirnov]

Hi Yury,

Thank you for warm welcome. :)

On Sat, 25 Feb 2012 01:40:42 Yury V. Zaytsev wrote:
> I'm glad to see you on board! I will accept your request for joining the
> Alioth project in a minute.

Fantastic, thanks.

> 
> The only thing that bothers me is that at this point there are several
> disparate efforts to revive the package. Have you been following the
> mailing list recently?

No, I'm just subscribed yesterday. I've checked SVN repository, bug tracker 
before taking last uploaded 'mc' to work with.

> 
> To make to the long story short Ubuntu people are very interested in
> having mc updated to the latest version before they release their next
> LTS (Precise).
> 
> However, we all agree that it would be nice to have it uploaded to
> Debian first and then have it autosynced into Ubuntu, so that we can
> reduce the amount of duplication in our efforts.
> 
> Could you please coordinate with Maarten Bezemer, who seemed to be
> interested in actually making this happen? He seems to have a branch
> with updates uploaded to Launchpad already, is there anything you can
> pull from him into your package?

I'm not sure how they can be of help. Patches are always welcome, as usual.
I might peek into their repository eventually if I have time.
I would rather see Ubuntu people working on our BTS rather than discussing  
vague plans to do something on our side. And I have neither time nor will to 
chase them.


> Additionally, Andreas said he can possibly sponsor uploads and maybe
> provide reviews. I'll try to make a review as well if you wish, but I'm
> extremely overloaded ATM and not even a DD anyways, so...

Sponsoring would be very nice indeed. 
I'm quite confident with packaging so review would be nice but not necessary. 

 
> My last sponsor was Patrick Matthaei, but I hope Andreas can also help
> you with that.

Do you know if Patrick is subscribed here? Shall I email to him?


> > One more thing: I was thinking that nowadays more and more people prefer
> > git over subversion. What do you think about moving 'mc' packaging into
> > git repository at collab-maint? Perhaps more people might find it easier
> > to contribute then...
> 
> I have no clue about collab-maint, but I think I have created an empty
> repository on Alioth already. If you want to create a gbp-compatible
> layout and import your DSC there to start afresh you are more than
> welcome to do so.

I can dump what I did to current svn repository (with git-svn) but IMHO moving 
development to collab-maint would be the best. Of course I will just follow 
your lead...


> 
> > ########
> > 
> > mc (3:4.8.1-1) unstable; urgency=low
> 
> THIS LOOKS AWESOME!!!111

Thank you. :)


> 
> Few minor comments below:
> > * debian/watch
> > 
> >     • fixed and updated to fetch latest .tar.xz
> 
> Did you figure what is their latest take on stable / unstable branches?
> 4.7.0.x used to be stable, now 4.8.x is stable or unstable?

Until today I didn't have a reason to look at how 'mc' developers organise 
their work. Officially stable is 4.7.5.6 but 4.8.1 *feels* stable and I'm 
surprised how many issues they're managed to nail. Probably 4.7.5.6 don't 
recieve as much attention as 4.8.1 nowadays.

I reckon it's worth trying. If you have any doubts, confidence may came only 
from only using it. (Worst case, I'll package 4.7.5.6 if we find something 
really bad, but so far I like my new MC)

I think 4.8.1 is good enough and perhaps it can hardly be any worse that what 
we had beforehand.


> 
> Uhm, maybe go for 8, so that it can end up in backports?

I can make another branch for backports. 
9 is recommended version now, see debhelper(7)

> 
> >   * dh-autoreconf to update toolchain
> 
> Do we really need that?

I think we do. It is good to build with up-to-date toolchain. Why not?
Because of this I could drop one of the patches modifying file 'configure' 
(generated one!) which is not good. dh-autoreconf is quite reliable and I use 
if for other packages. It is available in backports, as far as I can remember.


> They have been generating the build system on latest Fedora for quite
> some time now, so I don't think it makes sense to re-generate it anymore
> since build system being outdated is no longer a problem as they no
> longer generate it on RHEL5.

Yet it may not be well integrated with Debian toolchain. If you're not 
regenerating it, how would you know? It is a good packaging practice.

And after all upstream not using latest toolchain - they have files generated 
by autoconf 1.11.1 when ours is 1.11.3.

> 
> > * debian/control
> > 
> >       + 'autopoint' (used by autoreconf)
> 
> See above...

The same arguments apply... It is recommended practice to build *all* the 
files from source even if upstream ship precompiled ones.
Always better in order to prevent future FTBFS problems and it helps to 
understand build system more.

 
> > * configure options
> > 
> >     - --without-samba (obsolete)
> 
> Do you know whether they just dropped it or it was finally re-written so
> that it is no longer susceptible to the CVEs due to which it was
> disabled in the first place?
 
./configure no longer understand this parameter. There is another one: 
--enable-vfs-smb which is disabled by default. I wasn't following upstream 
development so that's all I know.


> > * patchworks:
> >     • disabled, to drop later:
> >       * 99_detect_alt_editor.patch
> 
> Why? Did they upstream it or you want to go back to wrappers?

It doesn't apply so as I did with other patches I tried to find where this 
code goes and I couldn't find it. Apparently the original code to patch 
disappear so I'm not sure this patch is valid for new version. 
It is still there to investigate and decide if we can drop it completely.

It looks like it's not needed anymore.


> 
> >   * architecture-independent files are separated to 'mc-data' package
> 
> Yay!


I'm very glad you like the changes. :)


Regards,
Dmitry.