New (technically; resurrected) port for/from comms/ category. Prot name: sms_client Version: 3.02 Description: A simple UNIX client allowing you to send SMS messages to mobile phones and pagers. The software currently supports a number of providers and protocols from various countries. Using an unlisted provider that allows TAP access should be pretty straight forward. There are a large number of services that do not appear to use TAP, but instead, simple user interfaces for interactive use by a user dialing up with a modem. For several UK based services such as these drivers have been written, note that providers often offer more that one service and as such you may require a different driver for each one. Please see attached sms_client.shar which contains the entire port, as perscribed by Porters Handbook. :) --Chris Fix: Add the attached port. Patch attached with submission follows: How-To-Repeat: N/A
ugh, I can't stand patches with the old-style names "patch-[a-z][a-z]". Can you rename these to indicate paths, which has been in vogue for several years now?
Will do! Sorry, and thank you for all your attention to this. --Chris
Hi Chris, As you surely have seen by my numerous running commentaries that these ports have to meet today's standards. Just reviving how they were back when they get deleted is not nearly enough. A couple of your ports were not staged (a sin big enough to immediately reject nowadays) Also check that it builds on both FreeBSD 10 as well as FreeBSD 8 and 9. The former have gcc as the base compiler, the later is of course, clang. It's common for ports to build on 8, 9 but not 10,11. So it's worth checking that. portlint helps a lot too.
also, I meant to say if you have some unclaimed ports pending that violate those things, you might want to flag them and say an updated version is coming.
(In reply to John Marino from comment #3) > Hi Chris, > As you surely have seen by my numerous running commentaries that these ports > have to meet today's standards. Just reviving how they were back when they > get deleted is not nearly enough. > > A couple of your ports were not staged (a sin big enough to immediately > reject nowadays) > > Also check that it builds on both FreeBSD 10 as well as FreeBSD 8 and 9. > The former have gcc as the base compiler, the later is of course, clang. > It's common for ports to build on 8, 9 but not 10,11. So it's worth > checking that. > > portlint helps a lot too. Hello, John, and thank you VERY much for all of your work regarding some of these latest ports. I'm afraid these were some of my first attempts at getting involved in port maintenance. My port-fu was sorely lacking. I think you'll (and others) find my current, and future contributions, more inline with current standards/requirements. Again, thank you for all your hard work, and attention to all of these. --Chris
status? I'm waiting on a new submission per comment 2
Created attachment 143959 [details] sms_client UPDATE - OBSOLETES previous file(s) (In reply to John Marino from comment #6) > status? I'm waiting on a new submission per comment 2 Understood, and sorry for the delay. $life got very un(expectedly|pleasantly) complicated. :/ OK. Just addressed Makefile, and "old style patches", then ran it through portlint(1). Which passed. I then performed make fetch, make patch && make. Which passed. As to "Also check that it builds on both FreeBSD 10 {...}" I track stable on ~60 servers. Which currently equates to RELENG_8 && RELENG_9. I fond 10 too "wobbly". But am staging to roll all servers forward to 11 soon(ish). At which point I'll be able to dedicate one box to FreeBSD development, and one to Ports development. So at this [very] moment I am unable to [effectively] test against Clang && LLVM. Going forward; I'll merge files/Makefile.config with Makefile. Which I (hope|should) be complete today. None the less; please see attached (sms_client.shar). Lastly, Thank you just doesn't cut it, for all your help, and tolerance. If I can ever catch up with you (BSDcon, {...}) Breakfast|Lunch|Dinner, and all the pints you can hoist, are on me. --Chris
okay, great. I can't recommend that you immerse yourself into poudriere as soon as convenience. Basically if if passes poudriere testport, you'll always be covered. From your description, I'm a little confused about "sms_client.shar" though. Is that a snapshot of work in progress? I interpret that you are still working on this port. Did I misunderstand your intent?
(In reply to John Marino from comment #8) > okay, great. I can't recommend that you immerse yourself into poudriere as > soon as convenience. Basically if if passes poudriere testport, you'll > always be covered. So _VERY_ understood. It won't come soon enough for me, and perhaps even more so, for you. :) > > From your description, I'm a little confused about "sms_client.shar" though. > Is that a snapshot of work in progress? I interpret that you are still > working on this port. Did I misunderstand your intent? There's nothing wrong with it, as it is provided in the update. The _only_ objection I can imagine, might be with "style". Where files/Makefile.config is concerned. It builds just fine, otherwise. Meaning, it all builds just fine. So if you're OK with it. I'm OK with it. :) Thank you very much, for your continued help/work/tolerance. --Chris
The original makefile has weird indentation (too many tabs). Easy to fix. The main problem is MAN1 is defined. That macro is never defined for staged ports. Also, I've changed this repeatedly, but "Created by: " always listed the original author of the revived port, not you. :)
staging fails completely: https://redports.org/buildarchive/20140621140901-6470/ The files are installed directly to the system, not in the stage directory. Do you fully understand what staging is and what it does? Looking to see if there is an easy fix.
i have everything working except the spool directories. will work on it when I get back
Chris, Please review the changed pkg-plist here: https://redports.org/browser/jmarino/comms/sms_client I couldn't make the empty directory generation work. I finally used a hack to create an empty ".keep" file each each desired directory. The probably is that I don't know if this is harmless to put a .keep file in the spool directories. Can you review the change and the associated "do-install:" target on Makefile and tell me if this is kosher? Ideally testing that it actually works? It passes package requirements fine, I'm just worried about how it actually operates.
(In reply to John Marino from comment #13) > Chris, > Please review the changed pkg-plist here: > https://redports.org/browser/jmarino/comms/sms_client > > I couldn't make the empty directory generation work. > I finally used a hack to create an empty ".keep" file each each desired > directory. > > The probably is that I don't know if this is harmless to put a .keep file in > the spool directories. > > Can you review the change and the associated "do-install:" target on > Makefile and tell me if this is kosher? > > Ideally testing that it actually works? > It passes package requirements fine, I'm just worried about how it actually > operates. Hello, John. Your generosity seems limitless. I'm speechless. Thank you! The ".keep file HACK" seems acceptable. I'm familiar with it's use in other ports, as well. Re-examining the source makes me think I should _probably_ choose /var/spool/lock in stead of lock(s). But if I do, that'll have to wait for the next version. As to the ".keep file HACK". If I had examined it more closely [as I should have], I probably would have chosen mtree(8). sysutils/hal seems a good example. As it too creates empty directories/folders. I'll test your current submission, and report back later today. Thanks again! --Chris
no mtree is deprecated and will be removed. The "correct" way is "@exec mkdir -p" with "@unexec rmdir" but I tried 50 ways and I kept getting QA errors saying it was missing a bunch of @dirrmtry which was not true. I suspect var is a special directory and it's tickling a QA bug. The ".keep" approach isn't that hacky. It's actually cleaner than a bunch of "@exec" "@unexec" entries. I was mainly concerned that the port wouldn't function properly with them. (small chance)
(In reply to John Marino from comment #15) > no mtree is deprecated and will be removed. VERY interesting to hear. I was porting a DNS replacement for the bind (named) ~3 months ago, and was told to use mtree(8) as the method to create the system tree. I was using something along the lines you used. But was told I should mtree(8). Thank you very much for the information. I will drop mtree(8) for any of my future work. In fact, I'm somewhat relieved. As I found mtree(8) somewhat cumbersome to use anyway. :) > The "correct" way is "@exec mkdir -p" with "@unexec rmdir" but I tried 50 > ways and I kept getting QA errors saying it was missing a bunch of @dirrmtry > which was not true. Good to hear. Much easier too. > > I suspect var is a special directory and it's tickling a QA bug. > > The ".keep" approach isn't that hacky. It's actually cleaner than a bunch > of "@exec" "@unexec" entries. I was mainly concerned that the port wouldn't > function properly with them. (small chance) I agree. It's a small chance. I'll be able to fully test it sometime today, or tomorrow. I'm building an 11-RELEASE development box ahead of schedule. As I can't bear to see you performing so much work, as I can't work effectively with the environment I'm working with now. Thanks a million, John. Your help has been tremendously valuable. --Chris
Created attachment 144106 [details] UPDATES - OBSOLETES previous attachment(s) modifications to sms_client source, which changes distinfo. Extensive testing, and modifications, resulted in success. make fetch make extract make patch make make install make deinstall make clean There were some harmless warnings emitted during the make process. All related to the sms_client code itself. I will correct them in the next version. But they don't prevent this port from running as anticipated. This all wouldn't have been possible so soon, without your MOST appreciated help, John. Thank you! As far as I can see, this port is good for commit. Thanks, again, John. --Chris
I wasn't expecting a new submission. The link I gave you is what I tested that is ready to go (pending confirmation that .keep is okay). Do I understand correctly that you want to obsolete that tested port? What does the new submission buy over the tested one?
(In reply to John Marino from comment #18) > I wasn't expecting a new submission. > The link I gave you is what I tested that is ready to go (pending > confirmation that .keep is okay). > > Do I understand correctly that you want to obsolete that tested port? What > does the new submission buy over the tested one? A few modifications to the sms_client source, itself. Which, where the FreeBSD port is concerned, changes distinfo. Due note; as you probably noticed, I used your addition(s) to Makefile. Is that what you're asking? Thanks. --Chris
so the distfile is the only visible change? At this point changes to baseline (represented by the contents of redports) are easier to digest than complete submissions.
(In reply to John Marino from comment #20) > so the distfile is the only visible change? > At this point changes to baseline (represented by the contents of redports) > are easier to digest than complete submissions. Yep. From a FreeBSD port context; the only change worth mentioning is the distinfo. Assuming your (redports) Makefile == true. :) Thanks a million, John. --Chris
(In reply to C Hutchinson from comment #21) > (In reply to John Marino from comment #20) > > so the distfile is the only visible change? > > At this point changes to baseline (represented by the contents of redports) > > are easier to digest than complete submissions. > > Yep. From a FreeBSD port context; the only change worth mentioning is > the distinfo. Assuming your (redports) Makefile == true. :) > > Thanks a million, John. > > --Chris Just for complete clarity; I tested against your redports version. I changed some of sms_client's source during my testing. Which required modifying the distinfo (also from your redports version). Meaning: If all you do is change the distinfo file in your redports dist, to the one I included in the most recent sms_client.shar. Everything will be perfect. distinfo: SHA256 (sms_client-3.0.2.tar.xz) = 8db9e51e1a80080dde0245738cf68542199e5da87d7e19bacb5a5384ee9d4e72 SIZE (sms_client-3.0.2.tar.xz) = 113428 Thanks again. --Chris
A commit references this bug: Author: marino Date: Wed Jun 25 21:52:46 UTC 2014 New revision: 359308 URL: http://svnweb.freebsd.org/changeset/ports/359308 Log: Revive comms/sms_client with stage support and a new maintainer This port was removed August 2011 for lack of a public distfile. It's been cleaned up and the distfile has a new home. Pass maintainership to submitter. PR: 188971 Submitted by: Chris Hutchinson Changes: head/comms/Makefile head/comms/sms_client/ head/comms/sms_client/Makefile head/comms/sms_client/distinfo head/comms/sms_client/files/Makefile.config head/comms/sms_client/files/patch-aa head/comms/sms_client/files/patch-ab head/comms/sms_client/files/patch-ac head/comms/sms_client/files/patch-ad head/comms/sms_client/files/patch-docs-Makefile head/comms/sms_client/files/patch-format.c head/comms/sms_client/files/patch-server-Makefile head/comms/sms_client/files/patch-sms-services-att_web head/comms/sms_client/files/patch-src-client-Makefile head/comms/sms_client/files/patch-src-queue-Makefile head/comms/sms_client/pkg-descr head/comms/sms_client/pkg-plist
Okay, thanks. It's been revived. I assume that you were confused about staging before, but now you get it? In any case, poudriere will make sure you get it once you set up that tool and start using it.