It seems like pluginloader.tar.gz.sig was rerolled. Index: distinfo =================================================================== --- distinfo (revision 408918) +++ distinfo (working copy) @@ -2,5 +2,5 @@ SIZE (pipelight/v0.2.8.2.tar.gz) = 153877 SHA256 (pipelight/pluginloader.tar.gz) = eba80a1afe6b9a4de34070dfec27d358036326c7dbd487830d0616dd33f37c4d SIZE (pipelight/pluginloader.tar.gz) = 809672 -SHA256 (pipelight/pluginloader.tar.gz.sig) = ef5346c698c0889d28c2d28358461bfa95f7b343bd0c6c00e4ea73db07c90625 +SHA256 (pipelight/pluginloader.tar.gz.sig) = e00c657ba0a7351e08dd66e91ba3f2125c50b4e66af7a66ca1881a4038453e9c SIZE (pipelight/pluginloader.tar.gz.sig) = 543
pluginloader.tar.gz itself looks different too: => Attempting to fetch http://repos.fds-team.de/pluginloader/v0.2.8.2/pluginloader.tar.gz fetch: http://repos.fds-team.de/pluginloader/v0.2.8.2/pluginloader.tar.gz: size mismatch: expected 809672, actual 1107980 The tarball seems to contain only binary blobs, so it's hard to see what changed. Do you have any additional information?
(In reply to Raphael Kubo da Costa from comment #1) Unfortunately, no. I'm just a user who tried to build that port :) I didn't look at pluginloader.tar.gz because it was downloaded from distcache so I didn't get any error about that, but it seems it was rerolled too.
Sorry if this sounds obvious to you, but is there a mailing list or a way to contact the people creating the pluginloader tarball to ask what happened? Rerolling tarballs like that is generally a bad idea, and rerolling signatures and a tarball with binary files sounds suspicious.
*** Bug 207835 has been marked as a duplicate of this bug. ***
Created attachment 168871 [details] Corrected distinfo file for the port Corrected distfile for emulators/pipelight. SHA256 has been updated according to the file SHA256SUMS in this folder: http://repos.fds-team.de/pluginloader/v0.2.8.2/ which contains the tarballs that the port requires for compilation.
Can we please have this issue resolved somehow? The port has been broken for over a month now. If you don't want to use the new tarballs from http://repos.fds-team.de/pluginloader/v0.2.8.2/ then please rollback the source for this port back to v0.2.8.1 so that it can be compiled with the older tarballs. Otherwise please update SHAs in the distinfo so that it can be compiled. I have attached to this ticket an updated distinfo that contains the newer SHA values if you choose the later option - I verified that with that update the port compiles with poudriere correctly (however I haven't tested the port after it has been compiled).
One more note to my previous comment, the pipelight project reports that the latest released version is 0.2.8.1, see: http://pipelight.net/cms/install/compile-pipelight.html However it seems that a new version has been created in October https://bitbucket.org/mmueller2012/pipelight/commits/tag/v0.2.8.2 which could have caused the recompilation of the pluginloader and uploading a new version of it to the previously mentioned folder. However, the official pipelight page still doesn't mention the new release: http://pipelight.net/cms/install/compile-pipelight.html Someone should make the decision, either FreeBSD updates the distfile to pull correct pluginloader for that version so that the port can be compiled or the port is reverted to version 0.2.8.1? Other suggestions?
(In reply to Grzegorz Junka from comment #7) > One more note to my previous comment, the pipelight project reports that the > latest released version is 0.2.8.1, see: > http://pipelight.net/cms/install/compile-pipelight.html However it seems > that a new version has been created in October > https://bitbucket.org/mmueller2012/pipelight/commits/tag/v0.2.8.2 which > could have caused the recompilation of the pluginloader and uploading a new > version of it to the previously mentioned folder. I think this solves the mystery. pipelight's lack of communication really sucks :/ I'll land this change to distinfo with an attempt at explaining what's going on. Have you considered taking over this port in the future and trying to build the Windows binaries instead of fetching them? Thanks for working on this!
A commit references this bug: Author: rakuco Date: Sun Apr 3 13:20:22 UTC 2016 New revision: 412468 URL: https://svnweb.freebsd.org/changeset/ports/412468 Log: Re-roll pluginloader entries in distinfo. The port broke in the beginning of February when upstream uploaded a new pluginloader tarball to MASTER_SITES. Since the tarball is unversioned and only contains prebuilt Windows binaries, here's an attempt at explaining what happened (thanks to Grzegorz Junka for the investigation): - Pipelight seems to be really bad at communication. The "News" section on the website says 0.2.8 is the latest version. - The "Compile Pipelight" section says 0.2.8.1 is the latest version. - 0.2.8.2 was tagged in BitBucket in October 2015 but was never announced anywhere on the website, and the project does not seem to have a mailing list. - The pluginloader tarballs, which contain prebuilt Windows binaries for Pipelight's src/windows directory, were not updated at the time 0.2.8.2 was tagged (the SHA256 checksums match those in the 0.2.8.1 directory in MASTER_SITES). This only happened in February 2016, which broke our distinfo. Note that it is unclear why the pluginloader tarballs were not generated in October, and since those are binary blobs it is still possible that they do not correspond to their respective source files. In the future, it would be good to build those binaries with our MinGW ports instead of relying on those blobs. PR: 207210 Submitted by: Piotr Kubaj <pkubaj@anongoth.pl>, Grzegorz Junka <list1@gjunka.com> MFH: 2016Q2 Changes: head/emulators/pipelight/distinfo
Thanks, guys!
A commit references this bug: Author: rakuco Date: Sun Apr 3 13:25:48 UTC 2016 New revision: 412470 URL: https://svnweb.freebsd.org/changeset/ports/412470 Log: MFH: r412468 Re-roll pluginloader entries in distinfo. The port broke in the beginning of February when upstream uploaded a new pluginloader tarball to MASTER_SITES. Since the tarball is unversioned and only contains prebuilt Windows binaries, here's an attempt at explaining what happened (thanks to Grzegorz Junka for the investigation): - Pipelight seems to be really bad at communication. The "News" section on the website says 0.2.8 is the latest version. - The "Compile Pipelight" section says 0.2.8.1 is the latest version. - 0.2.8.2 was tagged in BitBucket in October 2015 but was never announced anywhere on the website, and the project does not seem to have a mailing list. - The pluginloader tarballs, which contain prebuilt Windows binaries for Pipelight's src/windows directory, were not updated at the time 0.2.8.2 was tagged (the SHA256 checksums match those in the 0.2.8.1 directory in MASTER_SITES). This only happened in February 2016, which broke our distinfo. Note that it is unclear why the pluginloader tarballs were not generated in October, and since those are binary blobs it is still possible that they do not correspond to their respective source files. In the future, it would be good to build those binaries with our MinGW ports instead of relying on those blobs. PR: 207210 Submitted by: Piotr Kubaj <pkubaj@anongoth.pl>, Grzegorz Junka <list1@gjunka.com> Approved by: ports-secteam (junovitch) Changes: _U branches/2016Q2/ branches/2016Q2/emulators/pipelight/distinfo
(In reply to Raphael Kubo da Costa from comment #8) Thank you Raphael for looking into this. I haven't considered taking over this port (didn't come to my mind) but I might in the future if there is a need for that. I am fairly new to building ports with Poudriere and ever more newbie to all wine related stuff, including pipelight. I haven't even used pipelight yet (because I couldn't compile it) so taking it over now may be a bit too early. When you mentioned building the port with MinGW did you mean building it with poudriere as part of building pipelight or in some sort of separate build chain on Windows?
I meant the former: I took a brief look at the build instructions in Pipelight's website and Pipelight's configure script, and it looks like if mingw is present it's possible to build src/windows instead of using the prebuilt tarballs we currently use.
(In reply to Raphael Kubo da Costa from comment #13) OK, that makes sense. There is still a lot for me to learn before I could build a custom port with MinGW and commit to maintaining the build, but I will keep pipelight in mind. I will get back to you if only I am successful in building pipelight as you proposed if that's OK.
Absolutely; if you hit any roadblocks we're always willing to help in the freebsd-ports mailing list. Thanks!
(In reply to Raphael Kubo da Costa from comment #15) Is it this one https://forums.freebsd.org/ or you mean a different list? I couldn't get much response for my ports-related questions on that forum.
I mean this mailing list: https://lists.freebsd.org/mailman/listinfo/freebsd-ports The forums might also work, but I believe many more committers are subscribed to the mailing list than the forums.
Thanks, I will subscribe to that.
(In reply to Grzegorz Junka from comment #18) (In reply to Raphael Kubo da Costa from comment #17) Or maybe not, what's this? freebsd-ports Subscription results The hidden token didn't match. Did your IP change?
(In reply to Grzegorz Junka from comment #19) (In reply to Raphael Kubo da Costa from comment #17) All is fine, the subscription worked this time after retrying.