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

Dmitry Smirnov onlyjob at member.fsf.org
Fri Feb 24 17:32:51 UTC 2012

Hi Yuri,

On Sat, 25 Feb 2012 03:29:31 Yury V. Zaytsev wrote:
> Well, so far, they have been chasing *me*, so I definitively can't blame
> them for this. I've seen Maarten working on BTS, I'm just not sure of
> what his plans currently are.

They will nocite uploaded package soon enouth after it will be sponsored and 
this might be a good signal to them to think how they can be of help.

There is nothing I could ask them to do.

> > Sponsoring would be very nice indeed. I'm quite confident with
> > packaging so review would be nice but not necessary.
> Ok, it seems that review would still be in order :-) See below.

Much appreciated, thanks.

> > > 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?
> I am not sure if he is subscribed or not. I think Andreas is quite
> active, so he will respond in a couple of days, otherwise please do
> e-mail him.


> > 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...
> Hey, as I said, I don't know what collab-maint is in the first place :-)

O, I'm sorry. It is an Alioth project for collaborative package maintenance.
Great many packages are hosted there, have a look:


> What I was trying to say is that AFAIK there is already a git repository
> that I have created for mc on Alioth, so you could use that. If
> collab-maint is a shared Debian git repository service for packaging
> that I can also have access to, fine with me.

I couldn't find your git repository. But if you say it's empty, we may better 
start from scratch at collab-maint. 

> Let's pick either of those and declare svn obsolete & left online only
> for reference purposes.
> > Until today I didn't have a reason to look at how 'mc' developers
> > organise their work. Officially stable is but 4.8.1 *feels*
> > stable and I'm surprised how many issues they're managed to nail.
> > Probably don't recieve as much attention as 4.8.1 nowadays.
> Ok, my impression from 4.7.5 vs. 4.7.0.x days was that 4.7.5 was too
> much of a bleeding edge, full of bugs and barely usable, so I was doing
> stable instead.

According to


4.7.0.x is a most conservative branch,
4.7.N.x is a version with roughly 2 months turnover
4.8.x is a next stable release like out 'testing/unstable'

But stability is really depends on upstream workflow. So far 4.8 looks good 
because it fixed some long standing problems whis is immediately noticeable.

Maybe you're right, but I would give 4.8 a try but wouldn't rush to follow 
upstream releases as soon as they publish 'em.

> > I reckon it's worth trying. If you have any doubts, confidence may came
> > only from only using it. (Worst case, I'll package 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.
> Fine, let's do it then. I have never tried 4.8.1, if you think it's
> stable enough or at least more stable than 4.7.0.x, let's go for it.

Great. I'm just getting my first experience with is but soon I will know more 
because I'm using it very actively.

> > > >   * 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?
> Well, let me ask you how much radiation you have already received while
> working with autotools so far? >;-) I would not expect to hear that from
> someone who has been exposed to autoconf 2.66 / 2.67 at least.

I'm not sure I understand that metaphor well enough...
I certainly don't have much exposure to development with autoconf, but so far 
I like it. I would put it before alternatives like CMake.

> > Because of this I could drop one of the patches modifying file
> > 'configure' (generated one!) which is not good.
> Did we actually need it in the first place?
> I remember that was quite an ancient problem (back when the bs was
> generated on RHEL) which has been solved long time ago... And also,
> what's the status of the awk patch?

Not needed if you generate 'configure' with autoconf.
By the way, I hope you could spread some light on why awk patch was there in 
first place? What was it doing? It didn't have DEP3 header and I'm not too 
sure about it's purpose.

> > dh-autoreconf is quite reliable and I use
> > if for other packages. It is available in backports, as far as I can
> > remember.
> It's as reliable as non-deterministic regeneration of the build system
> can get. The purpose of dh-autoreconf is not to blindly regenerate the
> build systems for the sake of it, but to avoid hand-generated bs patches
> due to changes in *.ac-files by packagers etc.

I can see your point but from packaging prospective regeneration have benefits 
and it can help to identify problems.
There might be little risk associated, as you say, but the benefits are 
generally outweight it.

> > 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.
> It is a very *bad* packaging practice unless (1) you are a Gentoo
> developer or (2) autotools stack that upstream is using is *grossly*
> outdated and causing problems.

It is not only common sense to regenerate everything from source but also 

> Re.: Debian toolchain; there is no such thing as "Debian toolchain" and
> subsequently there is nothing to integrate with.

please read "debian toolchain" as toolchain currently available in debian.
Sorry if I wasn't clear enough.

> Ok, I would have referred you to the discussion on debian-devel@
> involving Joey on the subject, but (a) I can't remember when it took
> place and (b) there is a shallow possibility that they might have
> concluded on something that is actually against my religious beliefs,
> because I didn't follow it until the end :-)
> In short, I would definitively recommend you to not to mess with the
> build system unless there is a really good reason for it (or at least if
> you are not one of the autotools maintainers).

dh-autoconf can be very helpful to deal with proper application of --as-needed 

Autoconf makes a lot of sense if you keep in mind the number of architectures  
we're building for. Today I was building 'mc' in GNU Hurd, and just recently I 
was troubleshooting problems upstream (non mc) introduce due to lack of 
understanding how automake works. They didn't notice the problem because they 
only managed to break Hurd and MacOS build. My point is, if it works, it is 
better than to trust upstream with tools of which they have little 

> > And after all upstream not using latest toolchain - they have files
> > generated by autoconf 1.11.1 when ours is 1.11.3.
> It's not autoconf, it's automake.

it is autoconf *and* automake. Remember, autoconf refresh most of *.m4 files 
as well?

> > The same arguments apply... It is recommended practice to build *all* the
> > files from source even if upstream ship precompiled ones.
> Did it actually make into Policy (I haven't read the latest one)? Oh my
> god, that's not the Debian GNU/Linux as I used to know it anymore...

No it's not in policy but even during my little exposure to debian development 
I've seen enough people embracing this practice for reason.

> > Always better in order to prevent future FTBFS problems and it helps to
> > understand build system more.
> Autotools practitioners book from Calcote is what helps to understand
> the build system more and why you shouldn't mess with it :-)


> > 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.
> See src/args.c line 433.
> > It is still there to investigate and decide if we can drop it completely.
> > It looks like it's not needed anymore.
> No, it's still necessary.
> If you drop it, mcedit will fail to start when invoked through the
> editor symlink from alternatives. I tried to upstream it a year ago or
> so, but got refused on the grounds that it's too Debian-specific and
> there is little value in that for other distributions.

I'm very glad you clarified this. 
Could you help to update the patch please?

It is hard for me, I don't quite understand it.
At the moment I'm unable to update this patch myself.

> Maybe it's time for some more lobbying again...
Good luck!


More information about the Pkg-mc-devel mailing list