https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=219687
--- Comment #9 from Helen Koike <helen.ko...@collabora.com> --- (In reply to Richard Gallamore from comment #7) >> But now it uses version 20170609 instead of 2.4.0, is this ok? I feel that >> 2.4.0 should be somewhere as it is the version used in setup.py, what do you >> think? >> I tried to use GH_TAGNAME=20170609 with PORTVERSION=2.4.0 but it doesn't >> seem to work the way I imagined > Yes, revert back to how it was previously. This was a better solution, just > needed to verify. > >> With these changes now portlint returns: >> # portlint -AC >> looks fine. > This is great. The problem to revert it back I get: # portlint -AC FATAL: Makefile: either PORTVERSION or DISTVERSION must be specified, not both. What is the best way to handle this? > Couple things with the poudriere log. > - Only the port listed in summary is required, in this case > net/google-compute-engine. > - Not sure how the build was invoked, but I usually use poudriere bulk -tC.(-t > is for extra testing and -C will clean the specified package before build) > I also want to note that poudriere bulk is not the recommended procedure. From > the porters handbook, testport is suggested method, details here[1]. Thanks, I'll regenerate the poudriere tests like you suggested. > > > When I initially went to the github repo, for some odd reason the README.md > did > not show up and was just blank with no information. Going back to it now, the > information I was expecting is shown, so this work perfectly for WWW. There > are > some other items that need to be will need to be looked at. > > - Portname. Usually this is the same as project name, but I don't think that > would be a good fit. google-compute-image would be a bit more accurate, but > more opinions would be best. The github project is called compute-image-packages but it provides 3 different packages as described at https://github.com/GoogleCloudPlatform/compute-image-packages#packaging. - google-compute-engine - google-compute-engine-init - google-config So I believe that we should have one port for each of them. google-compute-engine-init is not necessary, as it only provides init scripts but I already added rc scripts as .in files in the google-compute-engine package. google-config provide some udev rules, syslog configuration and bash scripts for hostname and dhcp that are not really required for google-compute-engine but I intend to port google-config latter. So as there are 3 packages under the github compute-image-packages project, I am porting just the google-compute-engine one, so I think it should keep this name. > - The comment should match the project comment on github minus "Linux". > Changing this however with the current portname is a violation of having the > portname in comment so waiting for portname feedback before deciding the > correct comment. Do you mean "Guest Environment for Google Compute Engine" ? It could be, I am just wondering which should be the Comment in the future google-config package > - pkg-message.in[2]. Can you please provide a simple setup guide. It doesn't > need to be long, just a simple how-to startup guide of procedures required > after installing the package for the first time. If configuration is required, > pointing to a url with more information would be great. The easier configuration is a reboot to make the init scripts to start, I'll write this in pkg-message and I can add a manual guide. > > One more bit of information, how was the port tested? or is the port currently > being used in production? I am testing it by hand in a virtual machine running at Google Cloud Engine platform. The available tests in the upstream project are just mock tests that verifies if the software calls the right functions in the right order, it doesn't really check if it works or not and it can be biased as it was derivated directly from the code. To enable the tests I'll also need to port each test, increasing the number of patches and the maintenance complexity. As I believe the mock tests are more important to the developer then to FreeBSD (as it is implemented in the project), I don't think we need to bother to port them. What do you think? --- (In reply to Kubilay Kocak from comment #8) Thank you Kubilay for reviewing this, I am updating the package with the suggested changes and I'll attach it soon. -- You are receiving this mail because: You are on the CC list for the bug. _______________________________________________ freebsd-python@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-python To unsubscribe, send any mail to "freebsd-python-unsubscr...@freebsd.org"
