Re: suggested patch for bsd.ports.mk

[Julian Elischer]

Sometime ago I proposed the following change.

I got several "yes please" from members of the public,
but no actionable response from members of the ports group
So I am asking again.

As a src committer I don't feel qualified to do the commit myself and 
would like a guide/mentor for the task if I'm to do it myself.


Julian

On 13/05/2016 12:11 AM, Julian Elischer wrote:

This patch is pretty self explanatory.

it allows us to keep patches for various ports separately in a 
sparse hierarchy while not having to write to the ports tree itself.


In case the list scrubs hte text attachment (diff) here's the 
description part of the diff.


> //depot/bugatti/FreeBSD-ports-PZ/10.1/Mk/bsd.port.mk#2 (text) 



@@ -791,6 +791,11 @@
 #  The patches specified by this variable will be
 #  applied after the normal distribution patches but
 #  before those in ${PATCHDIR}.
+# EXTRA_PATCH_TREE - where to find extra 'out-of-tree' patches
+#  Points to a directory hierarchy with the same 
layout
+#  as the ports tree, where local patches can be 
found.

+#  This allows a third party to keep their patches in
+#  some other source control system if needed.
 # PATCH_WRKSRC- Directory to apply patches in.
 #  Default: ${WRKSRC}
 #

If anyone thinks this is a good idea, I'd like it to go in as we 
have to maintain it..

I could commit it myself but haven't had my ports wings awarded yet..



the actual patch is:


 //depot/bugatti/FreeBSD-ports-PZ/10.1/Mk/bsd.port.mk#2 (text) 

@@ -749,6 +749,11 @@
 #The patches specified by this variable will be
 #applied after the normal distribution patches 
but
 #before those in ${PATCHDIR}.
+# EXTRA_PATCH_TREE - where to find extra 'out-of-tree' patches
+#Points to a directory hierarchy with the same 
layout
+#as the ports tree, where local patches can be 
found.
+#This allows a third party to keep their 
patches in
+#some other source control system if needed.
 # PATCH_WRKSRC - Directory to apply patches in.
 #Default: ${WRKSRC}
 #
@@ -3145,6 +3150,36 @@
done; \
fi; \
fi
+.if defined(EXTRA_PATCH_TREE)
+   @set -e ;\
+   if [ -d ${EXTRA_PATCH_TREE}/${PKGORIGIN} ]; then \
+   if [ "`${ECHO_CMD} ${EXTRA_PATCH_TREE}/${PKGORIGIN}/patch-*`" != 
"${EXTRA_PATCH_TREE}/${PKGORIGIN}/patch-*" ]; then \
+   ${ECHO_MSG} "===>  Applying local patches for 
${PKGNAME}" ; \
+   PATCHES_APPLIED="" ; \
+   for i in ${EXTRA_PATCH_TREE}/${PKGORIGIN}/patch-*; do \
+   case $$i in \
+   *.orig|*.rej|*~|*,v) \
+   ${ECHO_MSG} "===>   Ignoring local 
patchfile $$i" ; \
+   ;; \
+   *) \
+   if [ ${PATCH_DEBUG_TMP} = yes 
]; then \
+   ${ECHO_MSG} "===>   Applying 
local patch $$i" ; \
+   fi; \
+   if ${PATCH} ${PATCH_ARGS} < $$i 
; then \
+   
PATCHES_APPLIED="$$PATCHES_APPLIED $$i" ; \
+   else \
+   ${ECHO_MSG} `${ECHO_CMD} "=> Local 
patch $$i failed to apply cleanly." | ${SED} "s|${EXTRA_PATCH_TREE}/${PKGORIGIN}/||"` ; 
\
+   if [ x"$$PATCHES_APPLIED" != x"" 
-a ${PATCH_SILENT} != "yes" ]; then \
+   ${ECHO_MSG} `${ECHO_CMD} "=> 
Patch(es) $$PATCHES_APPLIED applied cleanly." | ${SED} 
"s|${EXTRA_PATCH_TREE}/${PKGORIGIN}/||g"` ; \
+   fi; \
+   ${FALSE} ; \
+   fi; \
+   ;; \
+   esac; \
+   done; \
+   fi; \
+   fi
+.endif
 .endif
 
 .if !target(run-autotools-fixup)


___
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: suggested patch for bsd.ports.mk

[Vlad K.]

On 2017-01-03 11:31, Julian Elischer wrote:

Sometime ago I proposed the following change.

I got several "yes please" from members of the public,
but no actionable response from members of the ports group
So I am asking again.



I haven't checked the code in detail for correctness, but conceptually 
this is nice. I wanted to propose something like this last year, 
inspired by Gentoo's ability to just drop a patch in a directory in /etc 
which would be picked up automatically by portage.


However, I was convinced that it's unnecessary work because any custom 
patches can be added directly to the /files/ directory of the port and 
if using svn'd ports tree, it's easy to track and even push upstream.


But seeing that someone else now thinks this is good too, I'd like to 
cast my vote again for this. Yes, it's easy to do it with svn, but with 
something like this it should be possible to add an ability for 
Poudriere (and Synth?) to track multiple patches for multiple sets 
without the need to "pollute" the ports tree. Why? A/B testing, 
different arches - different patches, etc


So here: YES PLEASE.

Julian, did you put it up for comments on reviews.freebsd.org?


--
Vlad K.
___
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: suggested patch for bsd.ports.mk

[Julian Elischer]

On 3/01/2017 6:31 PM, Julian Elischer wrote:

Sometime ago I proposed the following change.

I got several "yes please" from members of the public,
but no actionable response from members of the ports group
So I am asking again.

As a src committer I don't feel qualified to do the commit myself 
and would like a guide/mentor for the task if I'm to do it myself.


see also:
 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=215726



Julian

On 13/05/2016 12:11 AM, Julian Elischer wrote:

This patch is pretty self explanatory.

it allows us to keep patches for various ports separately in a 
sparse hierarchy while not having to write to the ports tree itself.


In case the list scrubs hte text attachment (diff) here's the 
description part of the diff.


> //depot/bugatti/FreeBSD-ports-PZ/10.1/Mk/bsd.port.mk#2 (text) 



@@ -791,6 +791,11 @@
 #  The patches specified by this variable will be
 #  applied after the normal distribution patches but
 #  before those in ${PATCHDIR}.
+# EXTRA_PATCH_TREE - where to find extra 'out-of-tree' patches
+#  Points to a directory hierarchy with the same 
layout
+#  as the ports tree, where local patches can be 
found.

+#  This allows a third party to keep their patches in
+#  some other source control system if needed.
 # PATCH_WRKSRC- Directory to apply patches in.
 #  Default: ${WRKSRC}
 #

If anyone thinks this is a good idea, I'd like it to go in as we 
have to maintain it..

I could commit it myself but haven't had my ports wings awarded yet..



the actual patch is:


 //depot/bugatti/FreeBSD-ports-PZ/10.1/Mk/bsd.port.mk#2 (text) 

@@ -749,6 +749,11 @@
 #  The patches specified by this variable will be
 #  applied after the normal distribution patches but
 #  before those in ${PATCHDIR}.
+# EXTRA_PATCH_TREE - where to find extra 'out-of-tree' patches
+#  Points to a directory hierarchy with the same 
layout
+#  as the ports tree, where local patches can be 
found.

+#  This allows a third party to keep their patches in
+#  some other source control system if needed.
 # PATCH_WRKSRC- Directory to apply patches in.
 #  Default: ${WRKSRC}
 #
@@ -3145,6 +3150,36 @@
 done; \
 fi; \
 fi
+.if defined(EXTRA_PATCH_TREE)
+@set -e ;\
+if [ -d ${EXTRA_PATCH_TREE}/${PKGORIGIN} ]; then \
+if [ "`${ECHO_CMD} 
${EXTRA_PATCH_TREE}/${PKGORIGIN}/patch-*`" != 
"${EXTRA_PATCH_TREE}/${PKGORIGIN}/patch-*" ]; then \
+${ECHO_MSG} "===>  Applying local patches for 
${PKGNAME}" ; \

+PATCHES_APPLIED="" ; \
+for i in ${EXTRA_PATCH_TREE}/${PKGORIGIN}/patch-*; do \
+case $$i in \
+*.orig|*.rej|*~|*,v) \
+${ECHO_MSG} "===>   Ignoring local 
patchfile $$i" ; \

+;; \
+*) \
+if [ ${PATCH_DEBUG_TMP} = yes ]; then \
+${ECHO_MSG} "===>   Applying local 
patch $$i" ; \

+fi; \
+if ${PATCH} ${PATCH_ARGS} < $$i ; then \
+PATCHES_APPLIED="$$PATCHES_APPLIED $$i" 
; \

+else \
+${ECHO_MSG} `${ECHO_CMD} "=> Local 
patch $$i failed to apply cleanly." | ${SED} 
"s|${EXTRA_PATCH_TREE}/${PKGORIGIN}/||"` ; \
+if [ x"$$PATCHES_APPLIED" != x"" -a 
${PATCH_SILENT} != "yes" ]; then \
+${ECHO_MSG} `${ECHO_CMD} "=> 
Patch(es) $$PATCHES_APPLIED applied cleanly." | ${SED} 
"s|${EXTRA_PATCH_TREE}/${PKGORIGIN}/||g"` ; \

+fi; \
+${FALSE} ; \
+fi; \
+;; \
+esac; \
+done; \
+fi; \
+fi
+.endif
 .endif

 .if !target(run-autotools-fixup)

___
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"




___
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"

Nieuwe vacatures voor verkoper 2017-01-03

[alert]

___
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: suggested patch for bsd.ports.mk

[Julian Elischer]

On 3/01/2017 6:44 PM, Vlad K. wrote:

On 2017-01-03 11:31, Julian Elischer wrote:

Sometime ago I proposed the following change.

I got several "yes please" from members of the public,
but no actionable response from members of the ports group
So I am asking again.



I haven't checked the code in detail for correctness, but 
conceptually this is nice. I wanted to propose something like this 
last year, inspired by Gentoo's ability to just drop a patch in a 
directory in /etc which would be picked up automatically by portage.


However, I was convinced that it's unnecessary work because any 
custom patches can be added directly to the /files/ directory of the 
port and if using svn'd ports tree, it's easy to track and even push 
upstream.


But seeing that someone else now thinks this is good too, I'd like 
to cast my vote again for this. Yes, it's easy to do it with svn, 
but with something like this it should be possible to add an ability 
for Poudriere (and Synth?) to track multiple patches for multiple 
sets without the need to "pollute" the ports tree. Why? A/B testing, 
different arches - different patches, etc


So here: YES PLEASE.

Julian, did you put it up for comments on reviews.freebsd.org?

no I did not. I'm not sure how I would do that
clicking on the 'diff' button on the bug attachment gives  a nice view 
of the patch.








___
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"

Ports' tips and gotchas

[Vlad K.]

I've submitted a patch for Postgres server ports with a note about 
enabling checksumming 
(https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=214671). I'm now 
preparing to submit a patch with a similar "Nice to know" tip for 
Roundcube (changing default_host breaks the user profiles, and how to 
fix it).


Is pkg-message the right place for such tips and gotchas? Do we need a 
separate mechanism where users could collate and submit tips they find 
important when installing/upgrading/configuring the port (yeah, those 
three exact use cases, I'm sure pkg-message is not the best place for 
regular usage tips). Aside from UPDATING of course, which is just 
supposed to be important notes about one-time updates/upgrades.



--
Vlad K.
___
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: Ports' tips and gotchas

[mokhi]

Hi.
As far as i understood, `pkg-message` is a place for every point you
want people installing it to know.
maybe if you are adding a daemon/service you can mention some points
on error-cases in it.

Best wishes, Mokhi.
___
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: Ports' tips and gotchas

[Miroslav Lachman]

Vlad K. wrote on 2017/01/03 17:16:


I've submitted a patch for Postgres server ports with a note about
enabling checksumming
(https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=214671). I'm now
preparing to submit a patch with a similar "Nice to know" tip for
Roundcube (changing default_host breaks the user profiles, and how to
fix it).

Is pkg-message the right place for such tips and gotchas? Do we need a
separate mechanism where users could collate and submit tips they find
important when installing/upgrading/configuring the port (yeah, those
three exact use cases, I'm sure pkg-message is not the best place for
regular usage tips). Aside from UPDATING of course, which is just
supposed to be important notes about one-time updates/upgrades.


Until we have anything better I think pkg-message is the right place for 
these tips. Some ports already use pkg-message for some recommendations.


Miroslav Lachman
___
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: Ports' tips and gotchas

[Adam Weinberger]

> On 3 Jan, 2017, at 9:16, Vlad K.  wrote:
> 
> 
> I've submitted a patch for Postgres server ports with a note about enabling 
> checksumming (https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=214671). I'm 
> now preparing to submit a patch with a similar "Nice to know" tip for 
> Roundcube (changing default_host breaks the user profiles, and how to fix it).
> 
> Is pkg-message the right place for such tips and gotchas? Do we need a 
> separate mechanism where users could collate and submit tips they find 
> important when installing/upgrading/configuring the port (yeah, those three 
> exact use cases, I'm sure pkg-message is not the best place for regular usage 
> tips). Aside from UPDATING of course, which is just supposed to be important 
> notes about one-time updates/upgrades.

No, pkg-message is not the right place. pkg-message should be for "Where do I 
start?" or for FreeBSD-specific instructions. Tips, gotchas, interesting 
discoveries, bugs, foibles, shortcuts, etc. shouldn't go into the pkg-message. 
They should be on a blog, on a website, on a wiki, submitted upstream for 
inclusion in manpages or README files, etc.

pkg-message needs to contain only essential information, otherwise end-users 
will start to ignore them. I agree that tips should be shared, but putting it 
into SVN isn't the way to go.

# Adam


-- 
Adam Weinberger
ad...@adamw.org
https://www.adamw.org

___
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: Ports' tips and gotchas

[Vlad K.]

On 2017-01-03 17:43, Adam Weinberger wrote:


pkg-message needs to contain only essential information, otherwise
end-users will start to ignore them. I agree that tips should be
shared, but putting it into SVN isn't the way to go.



That's something along the lines of what I was thinking, but wasn't 
sure. Indeed if we start adding tips to pkg-message, where's the end of 
it.


However, in the case of my Postgres patch, it's something the user 
should be aware of BEFORE they do the initdb step, as once initialized, 
you can't change it for that cluster, without dumping the database, 
re-initializing and restoring, that's why I wanted to add it there.


Unfortunately, random blogs and websites are not good enough because the 
information is "out there" and not immediately presented. However, now 
that you mention it, adding wiki entries and then having a pkg-message 
contain something along the lines of "Please consult 
https://wiki.freebsd.org/Foo/Bar for important information before you 
init/start/configure/migrate/update, ..." is a valid alternative and I 
like it. In fact, I'll be reworking my Postgres patch to do just that, 
and create an entry for Roundcube.


However, what would be the best way to approach this via the FreeBSD 
wiki? I'm sure that random wiki pages in various users' namespaces is 
not quite the right thing to do. There currently are some ports Wiki 
pages but they're all over the place and not nicely organized.


Perhaps it is time we start a special Ports namespace that would allow 
us to collate and list in one place all the user submitted wisdom and 
important instructions?




--
Vlad K.
___
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: Ports' tips and gotchas

[Miroslav Lachman]

Adam Weinberger wrote on 2017/01/03 17:43:


pkg-message needs to contain only essential information,


But it is not true and never was. pkg-message always contains many other 
informations.

Or are these really essential?

Message from postgresql94-client-9.4.10_1:
The PostgreSQL port has a collection of "side orders":

postgresql-docs
  For all of the html documentation

p5-Pg
  A perl5 API for client access to PostgreSQL databases.

postgresql-tcltk
  If you want tcl/tk client support.

postgresql-jdbc
  For Java JDBC support.

postgresql-odbc
  For client access from unix applications using ODBC as access
  method. Not needed to access unix PostgreSQL servers from Win32
  using ODBC. See below.

ruby-postgres, py-PyGreSQL
  For client access to PostgreSQL databases using the ruby & python
  languages.

postgresql-plperl, postgresql-pltcl & postgresql-plruby
  For using perl5, tcl & ruby as procedural languages.

postgresql-contrib
  Lots of contributed utilities, postgresql functions and
  datatypes. There you find pg_standby, pgcrypto and many other cool
  things.




otherwise end-users will start to ignore them.


Yes, it applies for PHP extensions spam on each `pkg upgrade` where I 
get about 20 messages in a row like this:


Message from php56-zlib-5.6.29:


The following line has been added to your /usr/local/etc/php/ext-20-zlib.ini
configuration file to automatically load the installed extension:

extension=zlib.so

Totally useless messages taking about 150 lines...
Extensions were always automatically enabled on installation before 
converting from one php.ini file to many small files.


Miroslav Lachman
___
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: Ports' tips and gotchas

[Mel Pilgrim]

On 01/03/2017 08:33, Miroslav Lachman wrote:

Vlad K. wrote on 2017/01/03 17:16:


I've submitted a patch for Postgres server ports with a note about
enabling checksumming
(https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=214671). I'm now
preparing to submit a patch with a similar "Nice to know" tip for
Roundcube (changing default_host breaks the user profiles, and how to
fix it).

Is pkg-message the right place for such tips and gotchas? Do we need a
separate mechanism where users could collate and submit tips they find
important when installing/upgrading/configuring the port (yeah, those
three exact use cases, I'm sure pkg-message is not the best place for
regular usage tips). Aside from UPDATING of course, which is just
supposed to be important notes about one-time updates/upgrades.


Until we have anything better I think pkg-message is the right place for
these tips. Some ports already use pkg-message for some recommendations.


If the pkg-message addition covers a change introduced with an update to 
the port, considering adding it to UPDATING as well.

___
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: suggested patch for bsd.ports.mk

[G. Paul Ziemba]

jul...@freebsd.org (Julian Elischer) writes:

>Sometime ago I proposed the following change.

>I got several "yes please" from members of the public,
>but no actionable response from members of the ports group
>So I am asking again.

>> +# EXTRA_PATCH_TREE - where to find extra 'out-of-tree' patches
>> +#  Points to a directory hierarchy with the same 
>> layout
>> +#  as the ports tree, where local patches can be 
>> found.
>> +#  This allows a third party to keep their patches in
>> +#  some other source control system if needed.

> [...]

Thank you for raising this question. I may have given one of the
above-mentioned "yes" responses, and am still enthusiastically in
favor of this patch.

We have been discussing it for at least the last eight years (CF the
thread started at 
on Dec 1, 2008, which references this very patch from Dmitry Marakasov).
I have used it in my (admittedly very small) network since then, first
for building ports in situ and more recently with poudriere. It's been
invaluable in helping me manage site-local changes.
-- 
G. Paul Ziemba
FreeBSD unix:
10:11AM  up 135 days, 13:50, 17 users, load averages: 0.42, 0.28, 0.25
___
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: Ports' tips and gotchas

[Mark Linimon]

On Tue, Jan 03, 2017 at 06:16:26PM +0100, Vlad K. wrote:
> However, what would be the best way to approach this via the FreeBSD wiki?
> I'm sure that random wiki pages in various users' namespaces is not quite
> the right thing to do. There currently are some ports Wiki pages but they're
> all over the place and not nicely organized.

For right now I think your pages are fine.

The wiki doesn't have much of a "structure" right now.  I did some prototype
pages for a restructuring but it got bogged down due to internal politics.

It needs several months' worth of surgery.  I nibble at parts of it every
once in a while until I remember why I got frustrated :-)

mcl
___
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: Ports' tips and gotchas

[Vlad K.]

On 2017-01-03 19:55, Mark Linimon wrote:
The wiki doesn't have much of a "structure" right now.  I did some 
prototype
pages for a restructuring but it got bogged down due to internal 
politics.



I wanna hear all about it and see what you got, merge with my ideas.


--
Vlad K.
___
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: suggested patch for bsd.ports.mk

[Kurt Jaeger]

Hi!

> I got several "yes please" from members of the public,
> but no actionable response from members of the ports group
> So I am asking again.

I'd also like to have this patch.

If I look at the PR, mat is already working to integrate it.

-- 
p...@opsec.eu+49 171 3101372 3 years to go !
___
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"