Ticket #3553 (closed defect: fixed)

Opened 4 years ago

Last modified 4 years ago

make update-po fails

Reported by: onlyjob Owned by: zaytsev
Priority: minor Milestone: 4.8.16
Component: mc-core Version: 4.8.15
Keywords: Cc:
Blocked By: Blocking:
Branch state: no branch Votes for changeset:

Description

Running "make update-po" in "po" directory fails with

*** No rule to make target '../lib/vfs/dir/entry.c', needed by 'mc.pot-update'.  Stop.

There is no such problem in 4.8.14.

Attachments

update-po.patch (282 bytes) - added by onlyjob 4 years ago.
patch to revert POTFILES.in to 4.8.14 state

Change History

Changed 4 years ago by onlyjob

patch to revert POTFILES.in to 4.8.14 state

comment:1 follow-up: ↓ 2 Changed 4 years ago by andrew_b

Where did you get POTFILES.in from? It isn't in the source tree. It's create during build process.
In any case, we haven't lib/vfs/dir subdirectory at all.

comment:2 in reply to: ↑ 1 Changed 4 years ago by onlyjob

Replying to andrew_b:

Where did you get POTFILES.in from?


From release tarball v4.8.15 of course. :)

comment:3 in reply to: ↑ description Changed 4 years ago by zaytsev

Replying to onlyjob:

Running "make update-po" in "po" directory fails with

That's not nice, but what are the consequences for you? Why one would want to run update-po on a release tarball? I'm trying to understand if the problem is serious enough to warrant another release.

comment:4 Changed 4 years ago by onlyjob

That's not serious enough to warrant another release. I set priority "minor" to indicate that. Also patch is not a perfect fix but a sufficient workaround to build.
Running "update-po" is important to re-build pre-generated files in tarball.
Debian package runs "update-po" during build so this problem caused FTBFS.

comment:5 Changed 4 years ago by zaytsev

  • Blocked By 3547 added

comment:6 Changed 4 years ago by zaytsev

  • Milestone changed from Future Releases to 4.8.16

Ok, thanks! I've added this as a blocker for the next release.

I've checked the generated tarball from master on a clean VM and the problem is not there. So this must have something to do with how Slava generated the tarballs. All we need to do, is to check that the problem doesn't happen again for the next release.

comment:7 Changed 4 years ago by zaytsev

  • Status changed from new to accepted
  • Owner set to zaytsev

comment:8 Changed 4 years ago by andrew_b

  • Blocked By 3547 removed

comment:9 Changed 4 years ago by andrew_b

  • Blocking 3547 added

comment:10 Changed 4 years ago by zaytsev

  • Status changed from accepted to testing
  • Resolution set to fixed
  • Blocking 3547 removed

I've checked it with the new release tarball that I've just generated and it seems to work fine now.

comment:11 Changed 4 years ago by zaytsev

  • Status changed from testing to closed
Note: See TracTickets for help on using tickets.