Re: workflow question: how do you maintain the port in sync with upstream?

[Helen Koike]

On 08/14/2018 11:41 AM, blubee blubeeme wrote:
> On Tue, Aug 14, 2018 at 8:56 PM Helen Koike 
> wrote:
> 
>>
>>
>> On 08/13/2018 09:50 PM, blubee blubeeme wrote:
>>>
>>>
>>> On Tue, Aug 14, 2018, 08:26 Helen Koike >> <mailto:helen.ko...@collabora.com>> wrote:
>>>
>>>
>>>
>>> On 08/13/2018 08:00 PM, blubee blubeeme wrote:
>>> >
>>> >
>>> > On Tue, Aug 14, 2018, 06:30 Helen Koike >> <mailto:helen.ko...@collabora.com>
>>> > <mailto:helen.ko...@collabora.com
>>> <mailto:helen.ko...@collabora.com>>> wrote:
>>> >
>>> > Hello,
>>> >
>>> > I am new to the community, I am maintaining two packages and I
>>> would
>>> > like to check with you if there is a better workflow to do
>> this.
>>> >
>>> > The upstream project of the port I am maintaining is held in
>>> github, and
>>> > I also have patches in the /usr/ports/sysutils/myport/file/
>>> folder.
>>> >
>>> > So I keep a fork of the upstream project with a branch
>>> containing a
>>> > commit with the patches from the
>> /usr/ports/sysutils/myport/file/.
>>> >
>>> > Every time I need to update the port to a newer version, I do
>>> a git pull
>>> > in this branch, then I run a script [1] to re-generate the
>>> patches in
>>> > the /usr/ports/sysutils/myport/file/
>>
> This one is fairly straight forward, you can simply replace that string
> with a regex command;
> This is an example of running a replace command for strings after the patch
> phase of the build;
> 
> post-patch:
>   @${REINPLACE_CMD} -e 's|for Linux|for FreeBSD|g' ${WRKSRC}/README
> 
> 
> 
>>> >
>>> > This script basically generates a file.orig of all modified
>>> files in
>>> > git, then copy the modified file to WORK_DIR, then run make
>>> makepatch.
>>> >
>>> >
>>> > for file in ${CHANGES}; do
>>> > mv ${WORK_DIR}/${file} ${WORK_DIR}/${file}.orig
>>> > cp ${PROJECT_PATH}/${file} ${WORK_DIR}/${file}
>>> > done
>>> > make makepatch
>>
> Depending on how drastic the changes are, you can use the above command to
> simply replace strings;
> There's also binary alias, that allows to replace sed with gsed:
> https://www.freebsd.org/doc/en/books/porters-handbook/binary-alias.html
> 
> Speaking of which, FreeBSD has access to all the GNU tools such as;
> gmake [gnu make]
> gsed[gnu sed]
> 
> if it's only a few commands you can use binary alias.


Interesting, but unfortunately (if I understand correctly) this is only
for build time no? but I need to replace sed by gsed in the final
script, not just in the build time.

Thanks
Helen
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: workflow question: how do you maintain the port in sync with upstream?

[Helen Koike]

On 08/14/2018 01:09 PM, blubee blubeeme wrote:
> 
> 
> On Tue, Aug 14, 2018 at 11:33 PM Mathieu Arnold  > wrote:
> 
> On Tue, Aug 14, 2018 at 10:41:43PM +0800, blubee blubeeme wrote:
> > This one is fairly straight forward, you can simply replace that
> string
> > with a regex command;
> > This is an example of running a replace command for strings after
> the patch
> > phase of the build;
> >
> > post-patch:
> >       @${REINPLACE_CMD} -e 's|for Linux|for FreeBSD|g'
> ${WRKSRC}/README
> 
> Patching files in post-patch using sed SHOULD only be used to replace
> dynamic content, never static content.

I am not sure I understand what dynamic content means here in the
post-patch (as nothing was built, so no new file should be created). Is
the replacement used by mail/lbdb wrong?

from mail/lbdb/Makefile
post-patch:
${REINPLACE_CMD} -e 's/sed/gsed/' ${WRKSRC}/m_muttalias.sh.in

is it ok if I do the same?
It is not clear to me when I can use REINPLACE_CMD in the Makefile and
when I should do a patch.


> 
> This is missing the point of the email since you can call that command
> in any stage of the port build process.
> 
> Maybe we could append this info to the porters handbook.
> 
> 
> -- 
> Mathieu Arnold
> 

Helen
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: workflow question: how do you maintain the port in sync with upstream?

[Helen Koike]

On 08/14/2018 12:05 AM, Adam Weinberger wrote:
> On Mon, Aug 13, 2018 at 4:28 PM Helen Koike  wrote:
>>
>> Hello,
>>
>> I am new to the community, I am maintaining two packages and I would
>> like to check with you if there is a better workflow to do this.
>>
>> The upstream project of the port I am maintaining is held in github, and
>> I also have patches in the /usr/ports/sysutils/myport/file/ folder.
>>
>> So I keep a fork of the upstream project with a branch containing a
>> commit with the patches from the /usr/ports/sysutils/myport/file/.
>>
>> Every time I need to update the port to a newer version, I do a git pull
>> in this branch, then I run a script [1] to re-generate the patches in
>> the /usr/ports/sysutils/myport/file/
>>
>> This script basically generates a file.orig of all modified files in
>> git, then copy the modified file to WORK_DIR, then run make makepatch.
>>
>>
>> for file in ${CHANGES}; do
>> mv ${WORK_DIR}/${file} ${WORK_DIR}/${file}.orig
>> cp ${PROJECT_PATH}/${file} ${WORK_DIR}/${file}
>> done
>> make makepatch
>>
>>
>> I would like to know if there is a better way to do this (some tool that
>> I am not aware of?).
> 
> IIUC, the process you're describing seems to be rebasing your changes
> and then generating diffs. You might have an easier time if you just
> do that: rebase, and then generate a diff (see the last point here)>
> Your script automates some of the routine Makefile changes, and while
> there are some tools in ports-mgmt/ that can automate that, we don't
> generally recommend them.
> 
> It's common for Makefiles to have a maintainer-update: target that
> keeps the repetitive update tasks in the Makefile (which also helps
> the next person to maintain the port).

I didn't know about this target, I'll take a look. Thanks.

> 
> Also, where many files are modified on a continually-changing basis,
> it's acceptable (though less systemically desirable) to put all your
> patches into one file. The benefit is that you can generate that one
> file with a single git diff, and it makes PR submission far, far
> simpler.

Is there a way to easily transform a git patch to the FreeBSD
file/*.patch format? Because I use make makepatch, and it will generate
several patches anyway.
Once I used "diff -Nur", but it doesn't seem to be the same exact format
as the one generated by make makepatch.

> 
> Do any of those help?
> 
> # Adam
> 
> 

Thanks
Helen
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: workflow question: how do you maintain the port in sync with upstream?

[Helen Koike]

On 08/13/2018 09:50 PM, blubee blubeeme wrote:
> 
> 
> On Tue, Aug 14, 2018, 08:26 Helen Koike  <mailto:helen.ko...@collabora.com>> wrote:
> 
> 
> 
> On 08/13/2018 08:00 PM, blubee blubeeme wrote:
> >
> >
> > On Tue, Aug 14, 2018, 06:30 Helen Koike  <mailto:helen.ko...@collabora.com>
> > <mailto:helen.ko...@collabora.com
> <mailto:helen.ko...@collabora.com>>> wrote:
> >
> >     Hello,
> >
> >     I am new to the community, I am maintaining two packages and I
> would
> >     like to check with you if there is a better workflow to do this.
> >
> >     The upstream project of the port I am maintaining is held in
> github, and
> >     I also have patches in the /usr/ports/sysutils/myport/file/
> folder.
> >
> >     So I keep a fork of the upstream project with a branch
> containing a
> >     commit with the patches from the /usr/ports/sysutils/myport/file/.
> >
> >     Every time I need to update the port to a newer version, I do
> a git pull
> >     in this branch, then I run a script [1] to re-generate the
> patches in
> >     the /usr/ports/sysutils/myport/file/
> >
> >     This script basically generates a file.orig of all modified
> files in
> >     git, then copy the modified file to WORK_DIR, then run make
> makepatch.
> >
> >
> >     for file in ${CHANGES}; do
> >             mv ${WORK_DIR}/${file} ${WORK_DIR}/${file}.orig
> >             cp ${PROJECT_PATH}/${file} ${WORK_DIR}/${file}
> >     done
> >     make makepatch
> >
> >
> >     I would like to know if there is a better way to do this (some
> tool that
> >     I am not aware of?).
> >
> >     [1]
> >   
>  
> https://github.com/helen-fornazier/bsd-update-patches/blob/master/freebsd-gce-update.sh
> >
> >     Thanks
> >     Helen
> >
> >     ___
> >     freebsd-ports@freebsd.org <mailto:freebsd-ports@freebsd.org>
> <mailto:freebsd-ports@freebsd.org
> <mailto:freebsd-ports@freebsd.org>> mailing
> >     list
> >     https://lists.freebsd.org/mailman/listinfo/freebsd-ports
> >     To unsubscribe, send any mail to
> >     "freebsd-ports-unsubscr...@freebsd.org
> <mailto:freebsd-ports-unsubscr...@freebsd.org>
> >     <mailto:freebsd-ports-unsubscr...@freebsd.org
> <mailto:freebsd-ports-unsubscr...@freebsd.org>>"
> >
> > Submit your patches upstream, once they get accepted your work on
> > FreeBSD is greatly simplified. 
> >
> > Best, 
> > Owen
> >
> 
> I am doing that, but there are some changes that I couldn't include in
> upstream yet.
> 
> Helen
> 
> Can you give an example of types of changes can't be upstream yet and
> their reasoning why not? 
> 
> Best, 
> Owen
> 

Sure, e.g. "service -e" vs "service --status-all", there is also sed vs
gsed (but it just came to mind that I could add this replacement inside
the Makefile)

[1]
https://github.com/freebsd/freebsd-ports/blob/master/sysutils/google-compute-engine-oslogin/files/patch-bin_google__oslogin__control#L54

Please, let me know if there is a better way to solve this, meanwhile I
am keeping this patch in the port and I always need to rebase my changes.

And as a general case, I sometimes implement a fix only for FreeBSD e.g.
[2], then I think in the better way to include in the upstream code e.g.
[3] while keeping portability with Linux, and sometimes it takes a while
for the patch to be merged in upstream, so meanwhile I need to rebase
the patch in every update of the ports.

[2]
https://github.com/freebsd/freebsd-ports/blob/master/sysutils/py-google-compute-engine/files/patch-google__compute__engine_networking_ip__forwarding_ip__forwarding__utils.py

[3] https://github.com/GoogleCloudPlatform/compute-image-packages/pull/622

Thanks
Helen
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: workflow question: how do you maintain the port in sync with upstream?

[Helen Koike]

On 08/13/2018 08:00 PM, blubee blubeeme wrote:
> 
> 
> On Tue, Aug 14, 2018, 06:30 Helen Koike  <mailto:helen.ko...@collabora.com>> wrote:
> 
> Hello,
> 
> I am new to the community, I am maintaining two packages and I would
> like to check with you if there is a better workflow to do this.
> 
> The upstream project of the port I am maintaining is held in github, and
> I also have patches in the /usr/ports/sysutils/myport/file/ folder.
> 
> So I keep a fork of the upstream project with a branch containing a
> commit with the patches from the /usr/ports/sysutils/myport/file/.
> 
> Every time I need to update the port to a newer version, I do a git pull
> in this branch, then I run a script [1] to re-generate the patches in
> the /usr/ports/sysutils/myport/file/
> 
> This script basically generates a file.orig of all modified files in
> git, then copy the modified file to WORK_DIR, then run make makepatch.
> 
> 
> for file in ${CHANGES}; do
>         mv ${WORK_DIR}/${file} ${WORK_DIR}/${file}.orig
>         cp ${PROJECT_PATH}/${file} ${WORK_DIR}/${file}
> done
> make makepatch
> 
> 
> I would like to know if there is a better way to do this (some tool that
> I am not aware of?).
> 
> [1]
> 
> https://github.com/helen-fornazier/bsd-update-patches/blob/master/freebsd-gce-update.sh
> 
> Thanks
> Helen
> 
> ___
> freebsd-ports@freebsd.org <mailto:freebsd-ports@freebsd.org> mailing
> list
> https://lists.freebsd.org/mailman/listinfo/freebsd-ports
> To unsubscribe, send any mail to
> "freebsd-ports-unsubscr...@freebsd.org
> <mailto:freebsd-ports-unsubscr...@freebsd.org>"
> 
> Submit your patches upstream, once they get accepted your work on
> FreeBSD is greatly simplified. 
> 
> Best, 
> Owen
> 

I am doing that, but there are some changes that I couldn't include in
upstream yet.

Helen
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: has a framework change broken sysutils/google-compute-engine-oslogin?

[Helen Koike]

Hi all,

On 08/08/2018 03:04 PM, Dmitri Goutnik wrote:
> On 18-08-09 01:16:51, Julian Elischer wrote:
>> On 8/8/18 6:30 pm, Jan Beich wrote:
>>> Julian Elischer  writes:
>>>
 g++ -O2 -pipe -DPANZURA_DEV -DPZ_LONGNAMES -fstack-protector -isystem
 /usr/local/include -fno-strict-aliasing -isystem /usr/local/include
 -fPIC -c pam_module/pam_oslogin_login.cc -o
 pam_module/pam_oslogin_login.o
 g++ -fstack-protector -I/usr/local/include/json-c -o
 google_authorized_keys authorized_keys/authorized_keys.cc
 utils/oslogin_utils.cc -lcurl -ljson-c
 g++ -fstack-protector -Wall -Wstrict-prototypes -fPIC -shared
 -Wl,-soname,libnss_cache_oslogin.so.2 -o
 libnss_cache_google-compute-engine-oslogin-1.3.0.so
 libnss_cache_oslogin/nss_cache_oslogin.o
 libnss_cache_oslogin/compat/getpwent_r.o
 utils/oslogin_utils.cc:16:23: error: curl/curl.h: No such file or
 directory
 utils/oslogin_utils.cc:16:23: error: curl/curl.h: No such file or
 directory
>>> - GCC 4.2.1 (patched) from base system is not a supported configuration
>>>on i386/amd64/aarch64/armv6/armv7
>>> - C*FLAGS aren't consistently respected, see
>>>https://wiki.freebsd.org/WarnerLosh/UsrLocal#Include_paths
>>>https://www.freebsd.org/doc/en/books/porters-handbook/dads-cflags.html
>>>
>>> $ g++7 -v -xc++ -
>>> [...]
>>> ignoring nonexistent directory 
>>> "/usr/local/lib/gcc7/gcc/x86_64-portbld-freebsd12.0/7.3.0/include-fixed"
>>> ignoring nonexistent directory 
>>> "/usr/local/lib/gcc7/gcc/x86_64-portbld-freebsd12.0/7.3.0/../../../../../x86_64-portbld-freebsd12.0/include"
>>> #include "..." search starts here:
>>> #include <...> search starts here:
>>>   /usr/local/lib/gcc7/include/c++/
>>>   /usr/local/lib/gcc7/include/c++//x86_64-portbld-freebsd12.0
>>>   /usr/local/lib/gcc7/include/c++//backward
>>>   /usr/local/lib/gcc7/gcc/x86_64-portbld-freebsd12.0/7.3.0/include
>>>   /usr/local/include <-- HERE is why pkg-fallout@ is silent
>> Sorry you are out of my area of knowledge..
>> All I know is that the port no longer compiles under amd64.
>> though It did some months back.
>> How it selects the compiler to use I have no clue..
>> I got my pkg using make.conf but that is not a sustainable answer.
>>
>>>   /usr/include
>>> End of search list.
>>>
>>
>> ___
>> freebsd-ports@freebsd.org mailing list
>> https://lists.freebsd.org/mailman/listinfo/freebsd-ports
>> To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
> 
> Hi Julian,
> 
> As Jan said, port's Makefile is broken in a sense that not all of its binary 
> targets respect CXXFLAGS. I took a stab at unbreaking the build, see 
> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=230466

Sorry to take so long to reply. Thanks a lot for the patch.

> 
> BTW, it compiles fine on 112a and 104i with base clang, not sure why original 
> Makefile had USE_GCC.
> 

Because of my lack of experience.


I couldn't reproduce the error with USE_GCC though https://paste.ee/p/FXNiv
Maybe it is something in my environment (g++6 maybe).

Thank you all
Helen
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Review of google-compute-engine for next quarterly ports branch

[Helen Koike]

Hi,

I understand that the release of the next quarterly branch is near, also 
the preparations for FreeBSD 11.2.


If possible, It would be nice to have an updated version of the GCE 
agents included in the next FreeBSD release for GCE (Google Cloud Engine).


I would appreciate if anyone could review the following patches for 
sysutils/py-google-compute-engine and also 
sysutils/google-compute-engine-oslogin before the next quarterly ports 
branch.


https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=226936
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=227114

Thank you
Helen
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: Question: How to add a configuration file with autoplist ?

[Helen Koike]

Hi,

On 2017-09-25 08:10 AM, Chris Rees wrote:
> On 2017-09-25 05:54, Kubilay Kocak wrote:
>> On 9/25/17 6:16 AM, Helen Koike wrote:
>>> Hi,
>>>
>>> According to
>>> https://www.freebsd.org/doc/en/books/porters-handbook/plist-config.html
>>> , I need to add a @sample macro in pkg-plist to add a configuration
>>> file.
>>>
>>> But I am also using USE_PYTHON= autoplist in my Makefile, so I don't
>>> have the pkg-plist file.
>>>
>>> Should I remove autoplist and generate the pkg-plist by hand? Or is
>>> there another way to do this?
>>>
>>> I'll need this to update the version of the package
>>> sysutils/py-google-compute-engine.
>>>
>>> Thanks
>>> Helen
>>
>> Hi Helen,
>>
>> As far as I'm aware, autoplist, PLIST_* definitions and pkg-plist
>> entries can be used cumulatively (in combination with each other) to
>> produce a correct and complete installed files lis>>

Thanks, I didn't know that.

> 
> Careful doing that!  If you do, you may find the sample file gets listed
> twice, or worse the actual config file gets listed.
> 
> If you want to view the final generated plist then in the normal ports
> directory:
> 
> % make package
> % less `make -VTMPPLIST`

Awesome, thanks a lot.

> 
> (those are backticks).
> 
> It's probably harmless to have a file listed twice, but if you list the
> actual config file it gets blown away on each update.
> 
> Cheers,
> 
> Chris
> 

Helen
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Question: How to add a configuration file with autoplist ?

[Helen Koike]

Hi,

According to
https://www.freebsd.org/doc/en/books/porters-handbook/plist-config.html
, I need to add a @sample macro in pkg-plist to add a configuration file.

But I am also using USE_PYTHON= autoplist in my Makefile, so I don't
have the pkg-plist file.

Should I remove autoplist and generate the pkg-plist by hand? Or is
there another way to do this?

I'll need this to update the version of the package
sysutils/py-google-compute-engine.

Thanks
Helen
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: review of google-compute-engine: better quality of the GCE image

[Helen Koike]

Hi,

On 2017-08-07 12:07 AM, Helen Koike wrote:
> 
> 
> On 2017-07-22 04:38 PM, Helen Koike wrote:
>> Hi,
>>
>> On 2017-06-28 08:25 PM, Helen Koike wrote:
>>> Hi,
>>>
>>> In order to increase the quality of the FreeBSD image for the Google
>>> Cloud Engine platform, having the package google-compute-engine would
>>> enable several features that allows the machine to be controlled by
>>> the GCE tools (web console or gcloud) and other security features, so
>>> FreeBSD wouldn't stay behind the other distributions on this.
>>>
>>> I would really appreciate if anyone could review this package so it
>>> can be included in the FreeBSD ports, please, see more details in the
>>> link below:
>>>
>>>  https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=219687
>>>
>>> Thanks
>>> LN Koike
>>> ___
>>> freebsd-ports@freebsd.org mailing list
>>> https://lists.freebsd.org/mailman/listinfo/freebsd-ports
>>> To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
>>
>>
>> I just updated the patch to version 2.4.1, I would appreciate if
>> anyone could review it.
>>
>>  https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=219687
>>
>> Thanks a lot
>> Helen
>> ___
>> freebsd-ports@freebsd.org mailing list
>> https://lists.freebsd.org/mailman/listinfo/freebsd-ports
>> To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
> 
> Hi,
> 
> I received good feedback from the last version that I sent. Could
> someone with access to freebsd-ports be my sponsor/mentor on this, take
> a quick (hopefully) last review and upload it to freebsd-ports please? I
> would appreciate it a lot.
> 
> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=219687
> Thanks
> Helen
> ___
> freebsd-ports@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-ports
> To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"


I added the following flag:
maintainer-approval+
Is it ok? Could anyone merge it please?

Thanks
Helen
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: review of google-compute-engine: better quality of the GCE image

[Helen Koike]

On 2017-07-22 04:38 PM, Helen Koike wrote:

Hi,

On 2017-06-28 08:25 PM, Helen Koike wrote:

Hi,

In order to increase the quality of the FreeBSD image for the Google 
Cloud Engine platform, having the package google-compute-engine would 
enable several features that allows the machine to be controlled by 
the GCE tools (web console or gcloud) and other security features, so 
FreeBSD wouldn't stay behind the other distributions on this.


I would really appreciate if anyone could review this package so it 
can be included in the FreeBSD ports, please, see more details in the 
link below:


 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=219687

Thanks
LN Koike
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"



I just updated the patch to version 2.4.1, I would appreciate if anyone 
could review it.


 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=219687

Thanks a lot
Helen
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"


Hi,

I received good feedback from the last version that I sent. Could 
someone with access to freebsd-ports be my sponsor/mentor on this, take 
a quick (hopefully) last review and upload it to freebsd-ports please? I 
would appreciate it a lot.


https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=219687
Thanks
Helen
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"