Bug 188971 - [NEW PORT] revive port comms/sms_client : simple UNIX client allowing you to send SMS messages to mobile phones and pagers
[NEW PORT] revive port comms/sms_client : simple UNIX client allowing you to ...
Status: Closed FIXED
Product: Ports & Packages
Classification: Unclassified
Component: Individual Port(s)
Latest
Any Any
: Normal Affects Only Me
Assigned To: John Marino
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2014-04-24 20:10 UTC by Chris Hutchinson
Modified: 2014-06-25 21:58 UTC (History)
2 users (show)

See Also:


Attachments
file.shar (13.75 KB, text/plain)
2014-04-24 20:10 UTC, Chris Hutchinson
no flags Details
sms_client UPDATE - OBSOLETES previous file(s) (13.83 KB, text/shar)
2014-06-20 14:48 UTC, Chris Hutchinson
no flags Details
UPDATES - OBSOLETES previous attachment(s) (18.70 KB, text/shar)
2014-06-24 19:17 UTC, Chris Hutchinson
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Chris Hutchinson 2014-04-24 20:10:00 UTC
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
Comment 1 John Marino freebsd_committer 2014-06-10 23:02:28 UTC
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?
Comment 2 Chris Hutchinson 2014-06-10 23:59:36 UTC
Will do!
Sorry, and thank you for all your attention to this.

--Chris
Comment 3 John Marino freebsd_committer 2014-06-11 13:34:09 UTC
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.
Comment 4 John Marino freebsd_committer 2014-06-11 13:34:54 UTC
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.
Comment 5 Chris Hutchinson 2014-06-11 13:44:13 UTC
(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
Comment 6 John Marino freebsd_committer 2014-06-20 10:24:26 UTC
status?  I'm waiting on a new submission per comment 2
Comment 7 Chris Hutchinson 2014-06-20 14:48:21 UTC
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
Comment 8 John Marino freebsd_committer 2014-06-20 18:29:10 UTC
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?
Comment 9 Chris Hutchinson 2014-06-20 20:33:23 UTC
(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
Comment 10 John Marino freebsd_committer 2014-06-21 14:05:36 UTC
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. :)
Comment 11 John Marino freebsd_committer 2014-06-21 14:14:46 UTC
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.
Comment 12 John Marino freebsd_committer 2014-06-21 15:01:57 UTC
i have everything working except the spool directories.  will work on it when I get back
Comment 13 John Marino freebsd_committer 2014-06-22 12:18:45 UTC
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.
Comment 14 Chris Hutchinson 2014-06-23 18:23:24 UTC
(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
Comment 15 John Marino freebsd_committer 2014-06-23 21:34:03 UTC
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)
Comment 16 Chris Hutchinson 2014-06-24 00:53:58 UTC
(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
Comment 17 Chris Hutchinson 2014-06-24 19:17:57 UTC
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
Comment 18 John Marino freebsd_committer 2014-06-24 20:14:56 UTC
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?
Comment 19 Chris Hutchinson 2014-06-24 20:49:28 UTC
(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
Comment 20 John Marino freebsd_committer 2014-06-24 21:12:45 UTC
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.
Comment 21 Chris Hutchinson 2014-06-24 21:46:16 UTC
(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
Comment 22 Chris Hutchinson 2014-06-24 21:51:42 UTC
(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
Comment 23 commit-hook freebsd_committer 2014-06-25 21:52:58 UTC
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
Comment 24 John Marino freebsd_committer 2014-06-25 21:58:29 UTC
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.