Bug 245041 - sysutils/moosefs3-master: Update to 3.0.112
Summary: sysutils/moosefs3-master: Update to 3.0.112
Status: Closed FIXED
Alias: None
Product: Ports & Packages
Classification: Unclassified
Component: Individual Port(s) (show other bugs)
Version: Latest
Hardware: Any Any
: --- Affects Some People
Assignee: Tobias C. Berner
URL: https://github.com/moosefs/moosefs/re...
Keywords: buildisok, easy, patch, patch-ready
Depends on:
Blocks:
 
Reported: 2020-03-25 01:26 UTC by MooseFS FreeBSD Team
Modified: 2020-05-12 13:42 UTC (History)
4 users (show)

See Also:


Attachments
Update MooseFS to the latest stable version (3.0.112-1) (1.28 KB, patch)
2020-03-25 01:26 UTC, MooseFS FreeBSD Team
freebsd: maintainer-approval+
Details | Diff
v1 (1.16 KB, patch)
2020-04-05 17:20 UTC, Tobias C. Berner
no flags Details | Diff
MooseFS ports fix (1.49 KB, patch)
2020-04-10 01:30 UTC, MooseFS FreeBSD Team
no flags Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description MooseFS FreeBSD Team 2020-03-25 01:26:48 UTC
Created attachment 212687 [details]
Update MooseFS to the latest stable version (3.0.112-1)

The master port will upgrade all the moosefs3-* related ports as well.

This change in ports passes QA (portlint, poudriere).


Recent changes since MooseFS 3.0.111:

* MooseFS 3.0.112-1 (2020-03-24)

  - (cs) silence stupid compiler warning
  - (client) fixed handling LOCKED and EAGAIN status in readdata
  - (client) added handle info to oplog messages
  - (all) added support for disabling individual filesystem commands in exports
  - (client) added handling read/write/readdir disables on client side (better error messages)
  - (client) added session paramaters to '.params' file
  - (tools) fixed packet reallocation error
  - (master) changed syslog message for locked chunks
  - (client) added dentry invalidator (needed in Linux with kernel < 4.19 - EBUSY bug)
  - (master) fixed memory leaks in xattr and posixacl modules
  - (cs) when chunk can't be located always send to master info about lost chunk
  - (supervisor,master,cs) fixed buffer overrun in mastersupervisor code (HA only, intr. in 3.0.107)
  - (master) changed algorithm of reusing csid in chunk module (adding released csid to the end of free list)
  - (all) added support for STRICT and LOOSE mode in KEEP and ARCHIVE
  - (master) fixed segfault during appending chunks of file with positive length and no chunks
  - (metadump) fixed bugs introduced in verson 3.0.106
  - (master) added protection between neverending desyncing between newer LEADER and older FOLLOWER (HA only)
  - (master) fixed slices with 'to' set to 0 in mfsappendchunks
  - (master) removed starting protection time from client communication module
  - (man) fixed typo in mfsappendchunks man page
Comment 1 Automation User 2020-03-25 01:35:47 UTC
Build info is available at https://gitlab.com/swills/freebsd-ports/pipelines/129420786
Comment 2 Tobias C. Berner freebsd_committer 2020-04-04 18:04:18 UTC
Committed. Thanks
Comment 3 commit-hook freebsd_committer 2020-04-04 18:04:57 UTC
A commit references this bug:

Author: tcberner
Date: Sat Apr  4 18:04:14 UTC 2020
New revision: 530699
URL: https://svnweb.freebsd.org/changeset/ports/530699

Log:
  sysutils/moosefs3-master: Update to 3.0.112

  PR:		245041
  Submitted by:	MooseFS FreeBSD Team <freebsd@moosefs.pro> (maintainer)

Changes:
  head/sysutils/moosefs3-master/Makefile
  head/sysutils/moosefs3-master/distinfo
Comment 4 MooseFS FreeBSD Team 2020-04-05 14:57:53 UTC
(In reply to Tobias C. Berner from comment #2)
(In reply to commit-hook from comment #3)

It seems that the commit differs from the patch I sent.
Committed "PORTREVISION" is set to "0" (instead of "1" as in the patch) and it causes builds to fail since sources tarball name depends on this variable.

I received email:

"[package - head-amd64-default][sysutils/moosefs3-cgi] Failed for moosefs3-cgi-3.0.112 in fetch"
 
Please compare Makefile from:

https://bugs.freebsd.org/bugzilla/attachment.cgi?id=212687&action=diff

with:

https://svnweb.freebsd.org/ports/head/sysutils/moosefs3-master/Makefile?r1=530699&r2=530698&pathrev=530699

Thanks,
Piotr

Build errorlog from email:

=======================<phase: fetch-depends  >============================
===========================================================================
=======================<phase: fetch          >============================
===>  License GPLv2 accepted by the user
=> moosefs-3.0.112-0.tar.gz is not in /usr/ports/sysutils/moosefs3-cgi/../moosefs3-master/distinfo.
=> Either /usr/ports/sysutils/moosefs3-cgi/../moosefs3-master/distinfo is out of date, or
=> moosefs-3.0.112-0.tar.gz is spelled incorrectly.
*** Error code 1

Stop.
make: stopped in /usr/ports/sysutils/moosefs3-cgi
Comment 5 Tobias C. Berner freebsd_committer 2020-04-05 17:08:10 UTC
(In reply to MooseFS FreeBSD Team from comment #4)

First of all, sorry for that :) 

Second of all: that's not what the PORTREVISON is for. You should set the whole version in PORT- or DISTVERSION (or its -SUFFIX). PORTREVISION [1] is for when you have a package change with constant versioning.
(Say plist changes due to further feature activiation).



mfg Tobias

[1] https://www.freebsd.org/doc/en_US.ISO8859-1/books/porters-handbook/makefile-naming.html#makefile-portrevision
Comment 6 Tobias C. Berner freebsd_committer 2020-04-05 17:20:52 UTC
Created attachment 213101 [details]
v1

Could you test if this fixes your problem?


mfg Tobias
Comment 7 MooseFS FreeBSD Team 2020-04-05 19:22:00 UTC
(In reply to Tobias C. Berner from comment #6)

Thanks for a prompt reply.

Well, this a little bit more complicated and let me give you some background / story regarding it. MooseFS itself doesn't have extra "-1" suffix in the version name (see: https://github.com/moosefs/moosefs/releases). It means that MooseFS's components internally communicate with each other using the version without any suffix, i.e. 3.0.112 for example.

IIRC, long time ago, when we were submitting MooseFS ports to the FreeBSD ports tree, the "-1" suffix in the DISTNAME was necessary for some reason (I can't recall why), hence we added it as just "-1" to the ports. Then, in order to maintain the consistency across various OSes (mainly _beacuse_ of FreeBSD), we decided to add the same suffix to all our package builders (for FreeBSD and other OSes), including the sources tarball name, since DISTNAME defines the sources tarball name. It lasted like this for a few years.

Then, last year, "PORTREVISION = 1" was added to our port as a part of some larger update (?) in the revision 507372.

(see: https://svnweb.freebsd.org/ports/head/sysutils/moosefs3-master/Makefile?r1=495300&r2=507372&pathrev=530699)

We decided to use it as the suffix for port revision in the following commit:

https://svnweb.freebsd.org/ports/head/sysutils/moosefs3-master/Makefile?r1=523354&r2=526885&pathrev=530699

because when there is any change (either in the port itself or MooseFS sources), port / package version must somehow be bumped.

In most cases PORTREVISION will always be set to 1, however last time we had to make a change in the port itself (as promised to the user here: https://github.com/moosefs/moosefs/issues/334#issuecomment-591592936) – and it was changed by the following revision: https://svnweb.freebsd.org/ports?view=revision&revision=528042

This was actually an exception – MooseFS sources tarball didn't change at all and "moosefs-3.0.111-2.tar.gz" is actually a symlink to "moosefs-3.0.111-1.tar.gz" on our server at http://ppa.moosefs.com/src/ and it was symlinked only because of the change in FreeBSD ports.


Note that there are much more MooseFS ports than just moosefs3-master and moosefs3-cgi. Moreover, moosefs{2,3}-master (MooseFS Master Server) is a master port for the rest. After some discussion here on BugZilla we decided to go in the following fashion:

moosefs3-cgi
moosefs3-cgiserv
moosefs3-chunkserver
moosefs3-cli
moosefs3-client
moosefs3-master
moosefs3-metalogger
moosefs3-netdump

moosefs2-cgi
moosefs2-cgiserv
moosefs2-chunkserver
moosefs2-cli
moosefs2-client
moosefs2-master
moosefs2-metalogger
moosefs2-netdump

... and make space for future moosefs4-* release (see more: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=210306).

I'm not sure if I was able to describe everything clearly, but anyway I believe that (at least for now) we could just change

"PORTREVISION" to "1"

or

"PORTREVISION" to "0" and rollback "DISTNAME" to "moosefs-${PORTVERSION}-1" in order to let the ports be built (and users could upgrade to the latest version) and then maybe, if necessary, discuss it further if you believe that some more changes in ports are necessary or recommended.

Thanks,
Piotr
Comment 8 commit-hook freebsd_committer 2020-04-06 17:47:42 UTC
A commit references this bug:

Author: tcberner
Date: Mon Apr  6 17:47:17 UTC 2020
New revision: 530913
URL: https://svnweb.freebsd.org/changeset/ports/530913

Log:
  sysutils/moosefs3-master: fix fetch

  Technically wrong is better than litterally broken.

  - The port uses PORTREVISION as part of the distname at the moment.
    Until a proper fix for this is provided, quickly make it work again.

  PR:		245041

Changes:
  head/sysutils/moosefs3-master/Makefile
Comment 9 Tobias C. Berner freebsd_committer 2020-04-06 17:48:37 UTC
Moin moin 

I added the PORTREVISION again to make it fetch.

Could you please work on the port, to no longer misuse that  variable for this purpose (check for example my patch). Or you could even set the DISTVERISON=3.0.112-1



mfg Tobias
Comment 10 MooseFS FreeBSD Team 2020-04-06 17:57:20 UTC
(In reply to Tobias C. Berner from comment #9)

Thanks Tobias,

We'll work on the port and propose the update. It will probably happen along with MooseFS 3.0.113 release that is close (since there is already a number of fixes, see: https://github.com/moosefs/moosefs/blob/master/NEWS).

I'll CC you anyway so you could review it if you don't mind.

Best,
Piotr
Comment 11 MooseFS FreeBSD Team 2020-04-10 01:30:42 UTC
Created attachment 213237 [details]
MooseFS ports fix

Tobias,
what do you think on proposed solution? If you believe it is fine, we can close this Bug and I'll submit it separately as an update to MooseFS 3.0.113 version.

Best regards,
Piotr
Comment 12 Tobias C. Berner freebsd_committer 2020-04-12 17:40:42 UTC
(In reply to MooseFS FreeBSD Team from comment #11)
Sure, sounds good to me.

mfg Tobias
Comment 13 MooseFS FreeBSD Team 2020-05-12 13:42:14 UTC
(In reply to Tobias C. Berner from comment #12)

Hello Tobias,

I have opened a new issue with MooseFS ports update:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=246416

Apart from updating MooseFS version itself, it fixes the ports issue mentioned here, as promised. Please have a look if you have a moment.

Thank you,
Piotr