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

Yury V. Zaytsev yury at shurup.com
Fri Feb 24 16:29:31 UTC 2012


On Sat, 2012-02-25 at 02:45 +1100, Dmitry Smirnov wrote:

> 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.

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.

> 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. 

> > 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 :-)

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.

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 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.

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.

> 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.

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.

> > 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)

Fine, let's go for 9 ATM then.

> > >   * 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.

> 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?

> 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.

> 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.

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

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).

> 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.

> 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...

> 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 :-) 

> ./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.

I see, so they have not fixed it, but disabled by default. Ok, let's
leave it like that then.

> 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.

Maybe it's time for some more lobbying again...

-- 
Sincerely yours,
Yury V. Zaytsev





More information about the Pkg-mc-devel mailing list