freeBSD ports currency.

[Julian Elischer]

FreeBSd was just added to the survey of "how fresh are the packages on 
a distro" survey at:


  http://oswatershed.org/

I think we are doing ok..

it's preliminary data only and
one should not read too much into it.

julian

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

Re: recent change to ifconfig breaks OpenVPN?

[Julian Elischer]

Stefan Bethke wrote:

(Moving the discussion to -ports.)

Am 31.07.2009 um 00:57 schrieb Matthias Andree:

Am 31.07.2009, 00:36 Uhr, schrieb Bjoern A. Zeeb 
:



Yeah that is as great as we are or rather were.

So really, fix the openvpn scripts that assign the address to
interfaces to do something that would make sense from the ``man ip''
(not the literal command) point of view.  Just that it's "working"
somewhere or used to work elswhere neither means that it was correct
nor made sense at any time before.


It's actually in the C code where it was advertised as FreeBSD fix.
OpenVPN runs in 'topology subnet' mode here, which is documented as 
follows:


Use a subnet rather than a point-to-point topology by
   configuring the tun interface with a local IP address and subnet
   mask,  similar  to  the  topology used in --dev tap and ethernet
   bridging mode.  This mode allocates a single IP address per con-
   necting  client [... MS-Windows stuff here ...]
  When used on *nix, requires that the
   tun driver supports an ifconfig(8) command which sets  a  subnet
   instead of a remote endpoint IP address.

I wonder if TUNSIFMODE (see tun(4)) is somehow needed and if so, 
already done, and how the proper ifconfig call would look like in this 
case. Stefan already uttered some ideas in that direction.



Here's a first draft at a patch for OpenVPN.  With this, the tun 
interface gets set to IFF_BROADCAST mode.  One small piece is still 
missing: OpenVPN tries to install a route for the subnet, but that fails 
because now ifconfig has already inserted that route.  I'll try to look 
into that a bit later on.  I also haven't tested the server side yet, or 
any other mode.


I would have thought that the correct answer would be to set a 
different address for the remote end..

it is a p2p link so to make it look like an ethernet is a bit weird.



r...@freebsd-current:/usr/ports/security/openvpn-devel# cat 
files/patch-tun.c

--- tun.c.orig2009-05-30 23:34:13.0 +0200
+++ tun.c2009-07-31 14:22:31.0 +0200
@@ -863,11 +863,10 @@
   else {
 if (tt->topology == TOP_SUBNET)
 argv_printf (&argv,
-  "%s %s %s %s netmask %s mtu %d up",
+  "%s %s %s netmask %s mtu %d up",
   IFCONFIG_PATH,
   actual,
   ifconfig_local,
-  ifconfig_local,
   ifconfig_remote_netmask,
   tun_mtu
   );
@@ -1745,14 +1744,15 @@
 {
   open_tun_generic (dev, dev_type, dev_node, ipv6, true, true, tt);

-  if (tt->fd >= 0)
+  if (tt->fd >= 0 && tt->type == DEV_TYPE_TUN)
 {
   int i = 0;

-  /* Disable extended modes */
+  i = tt->topology == TOP_SUBNET ? IFF_BROADCAST : IFF_POINTOPOINT;
+  i |= IFF_MULTICAST;
+  ioctl (tt->fd, TUNSIFMODE, &i);
+  i = 0;
   ioctl (tt->fd, TUNSLMODE, &i);
-  i = 1;
-  ioctl (tt->fd, TUNSIFHEAD, &i);
 }
 }


Stefan



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

ports and PBIs

[Julian Elischer]

sorry for the cross-post..

Last night at the Bay Area FreeBSD Users Group meeting we had
a discussion about ports, and what is good about them and what
is bad about them. This has been a topic of discussion quite a
bit recently and we were looking for a solution that would
allow us to keep the good parts of the current ports system
but would allow us to give a better user experience for non
guru users.

The scheme we came up with involves a merging of the
ports tree and the PBI system, developed for PC-BSD.

Basically, the addition of a makepbi keyword in the .mk
files to allow the automatic generation of PBIs for 'simple'
ports such as 'cowsay' (the canonical simple app).
More complicated apps would need manual work in Makefile or
in a separate pbi-recipe file, but once the support was done
we could proceed one port at a time.  Not all ports make sense
in a PBI format. (e.g. libraries etc. may not)

One issue that was raised is the increase of storage
overhead when using PBI packages as they include a copy of
all required libraries and resources, which means that one would
very quickly get duplicate copies of things.

Our suggestions include the ability of the PBI management software
to resolve and (using hard links) eliminate duplicate items.
This is not as easy as it sounds but can be achieved using a
special variant of 'objcopy' (at least that is our theory).

The aim is to make all apps installed on a system much more
resilient to dependency problems.

In addition there was discussion on how builds need to be doable as 
non-root uids sometimes, and that users on a system should be

able to install packages (PBIs) as thie selves to get local
versions of apps for themselves.

Alfred Perlstein , Matt at ix systems Kris (Mr PBI), some
others and I, felt that these ideas seemed to make some sense
and so I put them here for comment.




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

Re: ports and PBIs

[Julian Elischer]

On 4/10/10 12:20 AM, Garrett Cooper wrote:

On Fri, Apr 9, 2010 at 11:28 PM, Sam Fourman Jr.  wrote:

On Fri, Apr 9, 2010 at 10:11 PM, Adam Vande More  wrote:

On Fri, Apr 9, 2010 at 8:31 PM, Julian Elischer  wrote:



Alfred Perlstein , Matt at ix systems Kris (Mr PBI), some
others and I, felt that these ideas seemed to make some sense
and so I put them here for comment.



FWIW, when I see these discussions I'm always left wondering what's the bad
part?  I do think there are problems, but there doesn't seem to be a clear
defined set of what is wrong.   IMO, there should be a defined set of goals
to judge possible implementations against.



Let me start by saying FreeBSD ports is by far the best system I have
used to date.
but as good as it is, there is room for improvement.

Being a FreeBSD user now for many years, one thing I think would be nice is:
being able to have easier access to development ports( Masked ports
kinda like Gentoo).


Masking ports and packages in general introduces all sorts of fun new
complexity for end users as well as maintainers. The last time I used
Gentoo (which was only a matter of months ago), a lot portage packages
were still masked even though they've been stable for months, years,
etc. This is very annoying for me as an end-user because bug blah
could be fixed in a later release but in order to unmask the pieces
for version blah, I had to unmask 10~15 other `unstable packages',
which greatly increased the chance of instability on my system (this
was particularly the case back several years ago, but Gentoo has
become more conservative over the years, and appears to be approaching
some level of equilibrium with Fedora, Ubuntu, etc in terms of
releases and package versioning).


right now is a GREAT example, currently there are new Gnome ,KDE and Xorg.
these are all MAJOR ports,dependencies run deeper and deeper with every release.
there can never be enough testing...but they all exist in random
subversion servers around the web...


ports isn't going to solve this. Post the Xorg modularization (which
needed to occur anyhow because Xorg and Xfree86 before that was were
monolithic beasts), I personally don't see that change in the amount
of  flux on a quarterly cycle, and the number of packages I install
today isn't that much greater than back 6 years ago when I started
using FreeBSD. So, while there might be some claim here to note, I
think it's mostly exaggerated.


I would very much like to help test these Major ports, but installing
them is a pain.
there should be some sort of overlay system in place, so I can just
build the development ports
after agreeing to a few well placed warnings of course. and Well if I
hose my system all to hell..
well then I could just click on a bunch of PBI's and I am back in business...


Ok, apart from the interface (click a PBI, and magically you have
packages installed)... how is this really different from binary
packages? Have you tried installing binary packages lately via
pkg_add? If not, I'd give it a shot instead of installing from ports.



yes but there are still dependency problems if you want to install a 
single package and you installed all the previous ones a year ago.

With PBIs each package is self standing, so you can install one
and not worry if it requires a different version of some library
to what you installed last year.





better still, make the development ports a PBI, I am just thinking out
loud here,but that may work, toughts?

one could say I could use merge scripts like marcusmerge for example,
or use Virtualbox...
but for large ports like Xorg and gnome or KDE, virtualbox doesn't cut it yet...
thinks like Nvidia Video cards, multiple monitors, USB devices, and
whatnot do not work on virtual box..
PBI's for development ports, with all the dependencies, wrapped in one package.


Ok, well here's the thing. Instead of having N shared dependencies and
libraries in /usr/local/lib, you'd have N**2 shared dependencies and
libraries in each and every package. Now, let's look at





$ ls -l irssi-0.8.14_1.tbz ~/Downloads/Irssi0.8.14_1-PV0.pbi
-rw-r--r--  1 gcooper  gcooper  6856203 Apr 10 00:05
/usr/home/gcooper/Downloads/Irssi0.8.14_1-PV0.pbi
-rw-r--r--  1 root wheel 517442 Apr 10 00:07 irssi-0.8.14_1.tbz

The .tbz file is a file created with pkg_create -b, and the other file
is the PBI I pulled off of http://www.pbidir.com/bt/download/210/2079
. Big difference in size (13.25 fold difference).


Yes but that is a worst case thing.  We are talking about making
a system where the PBIs contain all the libraries needed but that
only some of them are installed, when there is not already the
same one (i.e. identical) installed by a previous PBI.
so if you installed, say, 20 PBI from the same 'set' you woudl only
be installing one copy of the libraries that



PBIs only comprise a small set of packages in FreeBSD; if my
un

Re: ports and PBIs

[Julian Elischer]

On 4/10/10 10:36 AM, Sam Fourman Jr. wrote:




I do have a question, assuming PBI's were merged officially into the
FreeBSD ports tree,
say I had PostgreSQL Server installed, via PBI. then I wanted to tweak
a setting so I:

cd /usr/ports/databases/postgresql84-server/&&  make deinstall clean

would the PBI at this point be removed? or no because it is self contained?



to some extent that depends on what we do.
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: ports and PBIs

[Julian Elischer]

On 4/10/10 3:35 AM, Garrett Cooper wrote:

On Sat, Apr 10, 2010 at 1:45 AM, Julian Elischer  wrote:

On 4/10/10 12:20 AM, Garrett Cooper wrote:


On Fri, Apr 9, 2010 at 11:28 PM, Sam Fourman Jr.
  wrote:


On Fri, Apr 9, 2010 at 10:11 PM, Adam Vande More
  wrote:


On Fri, Apr 9, 2010 at 8:31 PM, Julian Elischer
  wrote:



Alfred Perlstein , Matt at ix systems Kris (Mr PBI), some
others and I, felt that these ideas seemed to make some sense
and so I put them here for comment.



FWIW, when I see these discussions I'm always left wondering what's the
bad
part?  I do think there are problems, but there doesn't seem to be a
clear
defined set of what is wrong.   IMO, there should be a defined set of
goals
to judge possible implementations against.



Let me start by saying FreeBSD ports is by far the best system I have
used to date.
but as good as it is, there is room for improvement.

Being a FreeBSD user now for many years, one thing I think would be nice
is:
being able to have easier access to development ports( Masked ports
kinda like Gentoo).


Masking ports and packages in general introduces all sorts of fun new
complexity for end users as well as maintainers. The last time I used
Gentoo (which was only a matter of months ago), a lot portage packages
were still masked even though they've been stable for months, years,
etc. This is very annoying for me as an end-user because bug blah
could be fixed in a later release but in order to unmask the pieces
for version blah, I had to unmask 10~15 other `unstable packages',
which greatly increased the chance of instability on my system (this
was particularly the case back several years ago, but Gentoo has
become more conservative over the years, and appears to be approaching
some level of equilibrium with Fedora, Ubuntu, etc in terms of
releases and package versioning).


right now is a GREAT example, currently there are new Gnome ,KDE and
Xorg.
these are all MAJOR ports,dependencies run deeper and deeper with every
release.
there can never be enough testing...but they all exist in random
subversion servers around the web...


ports isn't going to solve this. Post the Xorg modularization (which
needed to occur anyhow because Xorg and Xfree86 before that was were
monolithic beasts), I personally don't see that change in the amount
of  flux on a quarterly cycle, and the number of packages I install
today isn't that much greater than back 6 years ago when I started
using FreeBSD. So, while there might be some claim here to note, I
think it's mostly exaggerated.


I would very much like to help test these Major ports, but installing
them is a pain.
there should be some sort of overlay system in place, so I can just
build the development ports
after agreeing to a few well placed warnings of course. and Well if I
hose my system all to hell..
well then I could just click on a bunch of PBI's and I am back in
business...


Ok, apart from the interface (click a PBI, and magically you have
packages installed)... how is this really different from binary
packages? Have you tried installing binary packages lately via
pkg_add? If not, I'd give it a shot instead of installing from ports.



yes but there are still dependency problems if you want to install a single
package and you installed all the previous ones a year ago.
With PBIs each package is self standing, so you can install one
and not worry if it requires a different version of some library
to what you installed last year.


If I'm understanding you correctly you're saying it's an issue when I do:

pkg_add A B C

# 1 year passes

pkg_add D

# D depends on A, B, C, of different revisions. pkg_add barfs because
it can't find the applications, etc.

This is something that's been hashed over a number of times (a few of
which I've participated in in #bsdports). There needs to be a simple
update command which will handle the action of upgrading packages,
because there isn't a proper command that will do so today.

Unless PBIs are self-contained entities which have their own sets of
dependent utilities and libraries, etc (which you weren't suggesting
in the sentence above), or install into a common location with
versioned directories (which is a pain in the ass and involves a lot
of hardcoded pains dealing with libtool files, libraries, etc -- been
there, done that with Gentoo Linux -- there are hack scripts written
to work around several possible hardcoded version issue, and there are
a handful), AFAIK there's nothing positive and new that PBIs can bring
to the table in this regard that can't be implemented in pkg_install
as-is, other than the point-click-install user-friendly interface.


ok that's your opinion n the matter. I for one think htat hte default
ettin for PBIs to install all the dependencies, in this day of 1TB 
drives, makes sense and is a good capability for us to have, even if 
not everyone needs t

Re: ports and PBIs

[Julian Elischer]

On 4/10/10 12:07 PM, Tim Kientzle wrote:

Garrett Cooper wrote:

If I'm understanding you correctly you're saying it's an issue when I do:

pkg_add A B C

# 1 year passes

pkg_add D

# D depends on A, B, C, of different revisions. pkg_add barfs because
it can't find the applications, etc.

This is something that's been hashed over a number of times (a few of
which I've participated in in #bsdports). There needs to be a simple
update command which will handle the action of upgrading packages,
because there isn't a proper command that will do so today.


I'm not convinced that the "simple update command" you
mention is actually feasible, much less desirable.
(If I want to try out the new Firefox, why does that
imply that my year-old Gimp has to be upgraded?)

As for feasibility, here's the easy problem:
A2.7 requires B3.6
... one year passes ...
A4.8 now requires B7.2
But A4.8 is incompatible with B3.6 and A2.7 is
incompatible with B7.2. So neither A nor B
can be updated separately without breaking the system.

Here's the hard problem:
A2.7 requires B3.6
... one year passes ...
I want to install C1.0 which requires B7.2
but there hasn't been a new release of A that
works with B7.2.
So I now simply cannot have both C1.0 and A2.7
installed at the same time because they require
different versions of B.

PBI avoids both of these problems. It may
be unsuitable for embedded systems[1], but
I see no reason we should not extend the existing
ports/packages system with additional tools that
target certain use cases, and PBI seems a good
fit for the desktop case.

Tim

[1] Actually, PBI might work just fine even for
embedded if we address the disk bloat issue. One
approach would be to make
/Package/Bar/libfoo-2.8.7.so
a symlink or hardlink to
/Package/Shared/libfoo-2.8.7.so-
This gives easy sharing of identical files.
It's even easy to handle at install time:
* Installer writes libfoo-2.8.7.so to
/Package/Shared/libfoo-2.8.7.so-temp-
* Installer computes hash of file as it's written
* Installer renames file (delete if rename fails with EEXIST)
* Installer writes symlink or hardlink into /Package/Bar


yeah that's more or less what we were thinking..
hardlinks allow you to garbage collect when the last pbi that needs 
something is replaced/removed.
It's also to handle the cases where library A wants library B.  you 
don't want library A in the shared place looking for B back in the 
original PBI directory so there may need to be some patching up.




___
freebsd-curr...@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"


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

Re: ports and PBIs

[Julian Elischer]

On 4/10/10 5:43 PM, per...@pluto.rain.com wrote:

[dropped current@ since it doesn't take non-member posts]

Tim Kientzle  wrote:


The LD_LIBRARY_PATH issue is the most interesting
problem here.  I don't immediately see a solution that
doesn't include teaching ld-elf.so.1 about some form
of per-application library path.


Maybe install PBI executables with a wrapper of some
sort which would set LD_LIBRARY_PATH and exec the
real executable, or build similar functionality into
a specialized variant of /usr/lib/crt1.o (which BTW
seems not to have a manpage)?

Nah, that would be too easy.  There must be some lethal
flaw in it.



PBIs already do something like this I believe.

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

Re: ports and PBIs

[Julian Elischer]

On 4/10/10 10:06 PM, Garrett Cooper wrote:



It's more than just diskspace though. Consider the fact that now
you're going to lose a lot of the memory sharing between shared libs
and what-not, and now you'd have to be running N number of daemons .
Take PCBSD for instance -- do they really revision packages with
unshared dependencies, or are all of the dependencies updated at once?
This becomes a big issue as you can't have dissimilar applications
like dbus, gamin, openssh, etc running on the same system at one time.
How does the PBI layout plan to deal with this kind of conflict --
apart from jails, which would greatly increase the required
footprint...?



It's a pitty that you didn't read the original post where it was 
stated that doing this would depend on a scheme that is under 
discussion for common components to be shared WHEN POSSIBLE.





If you can do this with package code, Maybe you will supply the packages..


Not quite sure what you meant here.


I meant. get involved and do some of the work if you can see such an 
easy answer.



why?
As people have said before.. embedded folks usually want to compile
everyrthing for themselves anyhow.


Not necessarily. You have folks in embedded rolling their own stuff,
sure, but then you have groups like Montavista (now owned by Cavium
Networks) repackaging Linux for customers, providing a nominal fee for
the packages, support, and the tools, and there are large companies
(like Cisco) buying into this. It's not to say that people are going
to not roll their own solution, but many [intelligent] folks are going
towards an externally supported model instead of rolling their own
stuff. Thus, whatever the community decides is sane is what gets
adopted (unless the developers or management for the group are really
foolhardy / ignorant of what exists in the outside world, they're
steeped in existing methods that can't be easily transitioned to the
new model, or they have expendable resources to toss towards a custom
solution for specific needs).

If you guys think PBIs are so great... tell ya what -- make me and
other folks believers:


You know young fellow, your attitude is kind of annoying for a
topic that is just up for discussion.


1. Produce a port with the magic PBI producing tool.


I hope to be able to do this soon.


2. Produce directions on how to use said tool.


the goal is:
cd /usr/ports/misc/cowsay (or whereever cowsay is)
make pbi


3. Make sure said tool and install method doesn't conflict with what
exists in base.


PBIs already don't conflict. Hav eyou ever tried PC-BSD?


4. Capture statistics of how many people download this stuff and use


well we would start with the number of people using PC-BSD
because if we did this they would use our stuff.



5. Come back when you have data proving how many people care for your
solution so portmgr and core can make an informed decision on whether
or not it should be a part of base.


that's not how it's ever worked and I doubt it's going to start now.



Oh, and think about this too: whoever produces the tool, eats the
support costs.




The project shouldn't eat the support costs until it's
a part of base, if that ever happens. Definitely take this point into
consideration because good support is not only `my package/port/PBI is
broken .. help me!' -- it's also having QA engineers on hand and
staffed to validate that the packages or PBIs are valid and functional
-- in the very least from a DoA / smoke test perspective. I realize
that this is lacking in packages / ports today, but it's something
that many folks volunteering in the project (cross-functional in bugs
area and also in ports) have wanted for a long time.


Sorry, but you've really pissed me off and as most people will tell 
you. that's not easy to do.


This all has the ring of a desperate person looking for excuses to 
complain about something.


Every thing you have mentioned occurred to those of us having the 
original discussion in about the oh, say FIRST 10 SECONDS of

the conversation.

Might I suggest that when you have been in the project another decade 
or so you might learn some manners and stop trying to teach you 
grandmother to suck eggs.


If you are trying to tell me about project dynamics or how things
work of need to work I put it to you that I've been doing this when 
you were about minus 10 years old. I do Not need a lecture from a wet 
behind the ears puppy about how I should handle a discussion with

interested parties on possibly improving FreeBSD's user experience.

When you were born I was decoding network traces.
When you were giving you mother heart attacks by eating the crayons
I was writing disk and network drivers for BSD and
long haul protocols.
When you were learning to read I was playing with the MACH
VM system and kerle build process.
When you were learning to do multiplication of small numbers I
trying to forget the Windows NT internals classes I had been sent to.

Do you think we are so stupid that we 

Re: ports and PBIs

[Julian Elischer]

On 4/11/10 3:27 AM, Kostik Belousov wrote:


I already pointed in the other reply in this thread, $ORIGIN dynamic
token should solve the issue. See
http://docs.sun.com/app/docs/doc/817-1984/chapter3-13312?l=en&a=view


yes, teh question I have since I am not alinker expert is do we 
support it?  the link you give is for Solaris I think..




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

Re: ports and PBIs

[Julian Elischer]

On 4/11/10 11:44 AM, Kostik Belousov wrote:

On Sun, Apr 11, 2010 at 11:23:33AM -0700, Julian Elischer wrote:

On 4/11/10 3:27 AM, Kostik Belousov wrote:


I already pointed in the other reply in this thread, $ORIGIN dynamic
token should solve the issue. See
http://docs.sun.com/app/docs/doc/817-1984/chapter3-13312?l=en&a=view


yes, teh question I have since I am not alinker expert is do we
support it?  the link you give is for Solaris I think..


It is in three for HEAD, RELENG_8 and RELENG_7.



thank you.

This will I think as you suggest, make a significant difference.

the question I have is "is it re-evaluated for each library"?

So, to recap:

what we were thinking is something along the lines of the following:


an example with 2 PBI apps created at the same time
(part of the same set)

application 1 > libraryA - - (originally) - - ->library B
  |  / |
  |link /  |link
  |  /---(y)---/   |
  v /  v
 common area dd-mm-yy   library A --(x)>library B
  ^^
  |link|link
  ||
  ||
application 1 > libraryA - - (originally) - - - ->library B

library A and B in app 2 are deleted

the idea that all the PBIs developed as part of a release set
(labeled as set dd-mm-yy in this example, would
have identical libraries in them and would thus be candidates for
"library consolidation".
The question is and  I guess it's not really that important, whether
satisfaying a dependency in library A due to application 1 will use 
path  (x) or path (y).


certainly we would need to label the versions of the libraries in the
common area with a hash or something, or maybe some other unique
label.  (port sequence number plus build args?) so that we don't
use a copy of the library that is not really suitable for that app.

A really top class effort would be ab;e to know hte set of build
options on a library that would make the outcome "acceptable".
but I doubt that we want to go that far.

if a person takes PBIS from set "01-01-2011" hey will tend to find
common libraries. butit for some reason they need to take something
from set "01-01-2009" (i.e. an old PBI, for some compatibility reason)
it is guaranteed to work, despite the fact that there may well be
collisions between library versions, because it will not be linked
with those in the common area that do not match and will instead be
linked with its own copies.


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

Re: ports and PBIs

[Julian Elischer]

On 4/11/10 12:20 PM, Kostik Belousov wrote:

On Sun, Apr 11, 2010 at 12:13:12PM -0700, Julian Elischer wrote:

On 4/11/10 11:44 AM, Kostik Belousov wrote:

On Sun, Apr 11, 2010 at 11:23:33AM -0700, Julian Elischer wrote:

On 4/11/10 3:27 AM, Kostik Belousov wrote:


I already pointed in the other reply in this thread, $ORIGIN dynamic
token should solve the issue. See
http://docs.sun.com/app/docs/doc/817-1984/chapter3-13312?l=en&a=view


yes, teh question I have since I am not alinker expert is do we
support it?  the link you give is for Solaris I think..


It is in three for HEAD, RELENG_8 and RELENG_7.



thank you.

This will I think as you suggest, make a significant difference.

the question I have is "is it re-evaluated for each library"?


You interpreted the question correctly.


I am not sure what exactly you are asking there. $ORIGIN is substituted
for each object invividually, taking the object path as a substitution
target. That is, if main executable A references dso $ORIGIN/X/libA.so,
then libA.so is looked up in the subdirectory X of directory containing
A. If libA.so references $ORIGIN/Y/libB.so, then libB.so is looked up
in X/Y subdirectory of directory containing A.


If there is an LDPATH set then if the library A is to be found
at $SOMEWHERE-ELSE which is in the LDPATH, rather
than in $ORIGIN/X, will it still be found?

if the answer to the above is yes, then If it is then found
in $SOMEWHERE-ELSE/X somewhere, will it then look for libB.so
in $ORIGIN(A)  or in $SOMEWHERE-ELSE ?

If the library is actually somewhere else (via symlink) is $origin 
reevaluated to the actual destination? (that would be cool).








So, to recap:

what we were thinking is something along the lines of the following:


an example with 2 PBI apps created at the same time
(part of the same set)

application 1 >  libraryA - - (originally) - - ->library B
   |  / |
   |link /  |link
   |  /---(y)---/   |
   v /  v
  common area dd-mm-yy   library A --(x)>library B
   ^^
   |link|link
   ||
   ||
application 1 >  libraryA - - (originally) - - - ->library B

library A and B in app 2 are deleted


and libraries A and B in "common area" can be updated for security 
reasons by a special kind of PBI or package should it be required.


It sounds to me that link 'y' is followed, i.e. the linker continues
to think it is working in $ORIGIN(A).

either way this is sounding very doable..  Kris is thinking about a 
single sysutils/pbimanager port and a /mk diff that would allow

"make pbi" (once the port was installed).

I think it actually looks quite feasible.

Is there someone out there in ports-land who really inderstands the 
ports mk framework who could help us (because we'll need a local guide 
to make sure we don't dig inn any local burial grounds) and who can 
help with testing etc?


Similarly if we need to do anything funny with regards to hashing 
parts of .so files, or deciding how to version things, is there an

elf specialist in the house who can help?

Kris said can do the pbi tools part if he has help with these
two areas

Julian

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

Re: ports and PBIs

[Julian Elischer]

On 4/13/10 12:09 AM, Lucas Holt wrote:

On 4/10/2010 3:18 PM, k...@pcbsd.org wrote


However for my more hard-core friends, nothing stopping you from
running your own ports down
the road, more power to ya! For doing something like embedded work or
a server this makes total
sense and I think it is a huge positive for FreeBSD, no reason to
trash that or break it in any way.
For the other 99.9% of society who want something "that just works"
for day-to-day computing,
something like PBI is very attractive. It would be great to have an OS
that offers best of both worlds.

--
Kris Moore


There are only two possibilities with any package system. Either give
the user self packaged binaries containing all shared libraries or make
them update everything. Both have positives and negatives. We've been
working on a new package system in MidnightBSD for some time. When we
weighed this issue, it was decided that letting users have old binaries
sitting around was a bad idea. It encourages a user to sit on a package
for a year and not install security updates. The larger package size
also deters users from downloading updates in parts of the world which
have slow Internet connections. Remember the GDI+ update to windows
awhile back? There were many applications that had to be updated and
Microsoft had to release a scanner to search the drive for uses. There
side isn't always rosy.

Obviously, there are also advantages to the larger PBI packages for
users. PC-BSD is certainly easy to use.

At the end of the day, I think creating packages more frequently during
releases and pushing updates like many linux distros do makes more sense
in terms of security. FreeBSD has ten times the number of ports to build
than we do so obviously it's a problem to build packages that frequently.

I don't want to butt in any more on this because it's not my place, but
I just felt it was important to bring another perspective.


It may be thaat part of the answer is to do both.

For me I want to have PBIs for the actual tools I use on the machine..
things like wine, openoffice, gimp, etc. I don't care if these are 
'bleeding edge'. I just want them to work, and to keep working no 
matter what I do in my development environment.


On the other had for stuff I'm working on, I want ot be able to get 
the newest libraries etc and keep them up to date. This means I run
the dependency problem but I'm willing to upgrade everything and if it 
breaks occasionally, I'll fix it. regardless of whether my development 
environment is current;y broke or not, the tools I actually use on the 
machine will not be affected.


So for me I see a reason tehat we should use BOTH schemes.






Lucas
___
freebsd-curr...@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"


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

port for sysutils/fio update?

[Julian Elischer]

The upstream source for sysutils/fio has been updated specifically to 
fix some problems with FreeBSD and now compiles with no required patches,

(and also works better on FreeBSD)

It would be a very simple update for anyone who knows the ports system.

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

Re: port for sysutils/fio update?

[Julian Elischer]

On 10/24/10 1:59 PM, Ruslan Mahmatkhanov wrote:

25.10.2010 00:16, Julian Elischer пишет:

The upstream source for sysutils/fio has been updated specifically to
fix some problems with FreeBSD and now compiles with no required
patches,
(and also works better on FreeBSD)

It would be a very simple update for anyone who knows the ports system.

Julian


Please try attached patch:
cd /usr/ports/sysutils
patch -p0 < /path/to/fio-1.44.1.diff
cd fio
make install

I set port maintainer into cc:.


looks good
though the patch doesn't actually remove the patch file so the
ports complain about an empty patch file..
(not sure how one DOES remove a file using patch)

thanks!



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

Re: sysutils/sge6[012]: Sun Grid Engine - still broklen due to utmpx?

[Julian Elischer]

On 9/23/11 12:04 AM, Hartmann, O. wrote:

I was wondering if the SUN Grid Engine, located in port
sysutils/sge6[012] is still broken due to utmpx.

My department uses this GRID engine on Linux and since a long time I
wish to use it also on FreeBSD.

Are there alternatives? What are people using on HPC FreeBSD?


so how broken is it?
Since almost none of the active developers use SGE it is up to the 
users to help us get it fixed..



Greetings,
Oliver
___
freebsd-performa...@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-performance
To unsubscribe, send any mail to "freebsd-performance-unsubscr...@freebsd.org"



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

Re: [HEADSUP][CFT] pkgng beta1 is out

[Julian Elischer]

On 1/30/12 4:39 AM, Baptiste Daroussin wrote:

Hi,

pkgng has just reached the beta phase, and has now found its way to the
ports tree (disabled by default).

1/ Why pkgng?


the name sucks though
it would be good to fix it before it's built in everywhere.

like windows NT, which it is no longer NT.


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

Re: freebsd-ports Digest, Vol 391, Issue 10

[Julian Elischer]

On 11/21/10 4:00 AM, freebsd-ports-requ...@freebsd.org wrote:


deprecated because: has not been developed for 10 years



but is this a reason for deprecation  if it still works?

Julian

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

snort port

[Julian Elischer]

I notice that a sourcefire person is offering to take on the snort 
port..  That's an offer worth investigating.. maybe the current 
maintainer can work with him..


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

Re: Transferring ports

[Julian Elischer]

Peter Pentchev wrote:

On Fri, Mar 14, 2008 at 12:02:42AM +0300, Dmitry Marakasov wrote:




The purpose is similar - creating jails out of host system in fast
and easy way, possibility to strip everything unneeded (useful for
secure minimal jails or flash/livecd/embedded installations of
minimal size) and add something extra, like stuff from /usr/local
without installing full packages in a jail, or, say, copying over
additional tree of jail-specific changes (mostly stuff under /etc
and /usr/local/etc).

Such an utility is something I still might start working on.


I don't use the host system..
I keep a special pristine jail just for that purpose (to act as
a source for other jails). sometimes I also use null=mounts, and 
sometimes if the jails are on one big partition, I hardlink some 
stuff.. e.g binaries in /bin etc betweem teh jails.. saves memory and 
disk.. Of course that is only when I basically trust the jail user

(me).

___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: request for a new port + package

[Julian Elischer]

On 7/5/18 7:03 am, Mateusz Piotrowski wrote:

On Fri, 20 Apr 2018 04:22:32 +0800
Julian Elischer  wrote:


On 9/4/18 7:15 pm, Eugene Grosbein wrote:

On 09.04.2018 14:16, Mayuresh Kathe wrote:


how do i place a request for a new port + package?
the sources for my requested tool are available at
http://www.t3x.org/files/zenlisp.zip and the author of that tool has
granted permission to move it from the existing "public domain"
license to any "bsdl" license.

The package is created automatically once new port is created and
added to FreeBSD Ports collection. You can create and submit new
port yourself, just read
https://www.freebsd.org/doc/en_US.ISO8859-1/books/porters-handbook/

It seems to me that the description of what to do to make a port
is somewhat recursive by which I mean you need to understand
what it says before you read it. if you don't already know the jargon,
it is all Greek. (Apologies to any Greeks on the list).
I think it would be a pretty cool project to write a tool that asks
lots of questions and then eventually spits out a port Makefile.
it could allow the user to browse to places and then analyse the
links used etc.
I think the port writer's handbook is a bit intimidating to new ports
submitters.

You might be interested in this: https://reviews.freebsd.org/D12921

Cheers :)

MP

great.. when I read it before it was hard to read but 
http://envirobotics.ca/portershb/tools-introduction.html


makes it readable.


___
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: Practice of "Sponsored by" in commit messages

[Julian Elischer]

On 15/5/18 7:40 am, John W. O'Brien wrote:

Hello FreeBSD Ports,

The Committer's Guide section on Commit Log Messages [0], doesn't cover
the use of the "Sponsored by" key word. As a non-committer contributor,
it only recently occurred to me to wonder what work that credit is
intended to represent, and whether some light definition would be
helpful to reduce ambiguity.

When a committer credits a sponsor of theirs, from which the contributor
received no sponsorship, the portrayal feels a little awkward. Does this
strike the list as a problem, and if so, how ought it be solved?

To make this concrete, allow me to illustrate the situation.

Alice, working on her own time, prepares and contributes a patch. Bob,
who works for Acme Corp, reviews and commits the patch on company time.
The commit message includes "Sponsored by: Acme Corp". Alice eagerly
awaits her check from Acme Corp. Should the commit message have read
"Sponsored by: Acme Corp (Bob)"?


Probably not for just a review, unless it was pretty in depth and took 
many hours.

However we want to give some sort of acknowledgement
to companies that do allow their work to be incorporated, and who allow
their employees to do some FreeBSD work as part of their duties.
It also makes their name familiar to the readers of the commit emails
and often results in others seeking work there etc.
 "Sponsored by:"  generally means "some (maybe small) part of this 
work was developed
by someone being paid". It does not specify how much, and it is 
generally left to the committer
to decide if it was meaningful.   In some cases it is deliberately NOT 
entered despite
the developer being paid. (e.g. when a company is in stealth mode, or 
when some political

issue is relevant and people don't want to draw attention).



This could be extensible to multiple sponsorships. If, instead, Alice
prepares the patch having received a grant to do so from Best Sys Dev,
the commit message could state "Sponsored by: Acme Corp (Bob), Best Sys
Dev (Alice)".

[0]
https://www.freebsd.org/doc/en_US.ISO8859-1/articles/committers-guide/article.html#commit-log-message

PS: I realize that this issue transcends ports, but it's not clear where
I should send this instead, and this list seems like it would have a
reasonably high concentration of people with a stake in the discussion.



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

anyone know how to shut these ports up?

[Julian Elischer]

several ports, when compiled output a MASS of stuff that looks like:

 No recipe for '../gnulib/m4/stdio_h.m4' and no prerequisites 
actually changed.

 No need to remake target '../gnulib/m4/stdio_h.m4'.
 Considering target file '../gnulib/m4/stdlib_h.m4'.
  Looking for an implicit rule for '../gnulib/m4/stdlib_h.m4'.
  Trying pattern rule with stem 'stdlib_h.m4'.
  Trying implicit prerequisite '../gnulib/m4/stdlib_h.m4,v'.
  Trying pattern rule with stem 'stdlib_h.m4'.
  Trying implicit prerequisite '../gnulib/m4/RCS/stdlib_h.m4,v'.
  Trying pattern rule with stem 'stdlib_h.m4'.
  Trying implicit prerequisite '../gnulib/m4/RCS/stdlib_h.m4'.
  Trying pattern rule with stem 'stdlib_h.m4'.
  Trying implicit prerequisite '../gnulib/m4/s.stdlib_h.m4'.
  Trying pattern rule with stem 'stdlib_h.m4'.
  Trying implicit prerequisite '../gnulib/m4/SCCS/s.stdlib_h.m4'.
  No implicit rule found for '../gnulib/m4/stdlib_h.m4'.
  Finished prerequisites of target file '../gnulib/m4/stdlib_h.m4'.
 No recipe for '../gnulib/m4/stdlib_h.m4' and no prerequisites 
actually changed.

 No need to remake target '../gnulib/m4/stdlib_h.m4'.
 Considering target file '../gnulib/m4/stpcpy.m4'.
  Looking for an implicit rule for '../gnulib/m4/stpcpy.m4'.

...  except for about 20 minutes (my connection to the machine doing 
the work is not that fast)



I suspect print/texinfo is one (it's kind of hard to tell exactly when 
they go off to do dependencies..)


Does anyone know the secret to shutting up all this debug stuff?

It literally pumps out so much crap that the rest of he family gets 
bumped off the internet connection..


(including any other session I may have running)


___
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: anyone know how to shut these ports up?

[Julian Elischer]

On 30/5/18 12:38 am, Brooks Davis wrote:

On Sat, May 26, 2018 at 02:07:43PM +0800, Julian Elischer wrote:

several ports, when compiled output a MASS of stuff that looks like:

   No recipe for '../gnulib/m4/stdio_h.m4' and no prerequisites
actually changed.
   No need to remake target '../gnulib/m4/stdio_h.m4'.
   Considering target file '../gnulib/m4/stdlib_h.m4'.
  ?? Looking for an implicit rule for '../gnulib/m4/stdlib_h.m4'.
  ?? Trying pattern rule with stem 'stdlib_h.m4'.
  ?? Trying implicit prerequisite '../gnulib/m4/stdlib_h.m4,v'.
  ?? Trying pattern rule with stem 'stdlib_h.m4'.
  ?? Trying implicit prerequisite '../gnulib/m4/RCS/stdlib_h.m4,v'.
  ?? Trying pattern rule with stem 'stdlib_h.m4'.
  ?? Trying implicit prerequisite '../gnulib/m4/RCS/stdlib_h.m4'.
  ?? Trying pattern rule with stem 'stdlib_h.m4'.
  ?? Trying implicit prerequisite '../gnulib/m4/s.stdlib_h.m4'.
  ?? Trying pattern rule with stem 'stdlib_h.m4'.
  ?? Trying implicit prerequisite '../gnulib/m4/SCCS/s.stdlib_h.m4'.
  ?? No implicit rule found for '../gnulib/m4/stdlib_h.m4'.
  ?? Finished prerequisites of target file '../gnulib/m4/stdlib_h.m4'.
   No recipe for '../gnulib/m4/stdlib_h.m4' and no prerequisites
actually changed.
   No need to remake target '../gnulib/m4/stdlib_h.m4'.
   Considering target file '../gnulib/m4/stpcpy.m4'.
  ?? Looking for an implicit rule for '../gnulib/m4/stpcpy.m4'.

...?? except for about 20 minutes (my connection to the machine doing
the work is not that fast)

That is very weird output.  It looks like gmake is being called with -d
which certainly shouldn't be the case.


I suspect print/texinfo is one (it's kind of hard to tell exactly when
they go off to do dependencies..)

Does anyone know the secret to shutting up all this debug stuff?

It literally pumps out so much crap that the rest of he family gets
bumped off the internet connection..

If you must run interactive, run tmux or screen and switch virtual
terminals.  I find the latter to be really helpful when I've got a high
bandwidth-delay product connection (e.g.  Washington, USA to the UK).
I can get back to the prompt much faster after a build success/failure
then if I have to wait for everything to clear the pipe.
Unfortunately, running tmux, the data comes out of tmux so fast that I 
can not get a "switch windows" signal down to tmux.
in actuality the process has probably finushed, but I have quite a few 
minutes of solid data queued up between the Server and me in AUS.
for example, if I hit ^Z it eventually stops..  after that make has 
completed..  same thing with attempts to switch windows on tmux or screen.




-- Brooks



___
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: Archives of last quarterly package builds?

[Julian Elischer]

On 22/7/18 5:59 am, grarpamp wrote:

Packages are delivered via a single quarterly label here

https://pkg.freebsd.org/FreeBSD:11:amd64/quarterly/

which corresponds to the latest quarterly branch label here

https://svnweb.freebsd.org/ports/branches/?sortby=date#dirlist


However, similar to how the tags here

https://svnweb.freebsd.org/ports/tags/?sortby=date#dirlist

are archived here

https://pkg.freebsd.org/FreeBSD:11:amd64/
as these
https://pkg.freebsd.org/FreeBSD:11:amd64/release_[n]


The last "ie: final" builds of each quarterly branch before they
roll over should also be moved off into their own archived
quarterly directories as


I've asked for this but the answer is "no we don't do that..  and have 
no plans to".
Which is a putty as it means you need to make your own snapshots if 
you want to have any reproducability.
It no linger matters to me as we now roll all our own packages from 
source (we have private OS changes

that make this a requirement), but it was a sore point for many years.




https://pkg.freebsd.org/FreeBSD:11:amd64/Q[n]

For example /quarterly/ should be repointed from 2018Q2
to 2018Q3, leaving 2018Q2 as a live "pkg" accessible archive.


Eventually all such archives could be moved to historical
archive server under typical release support expiry periods.


This would also serve critical purpose as an independant
original remote repository for validating local package / file
signatures against compromise, corruption, loss.


For example, does the last 2018Q2 (or older ones) still exist
anywhere for users to reference and use?

no.


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

Automake creation error.. generic or just me?

[Julian Elischer]

I'm not exactly sure where the error come from.. possibly the find, if 
stderr and stdout are not synchronous.


Has anyone else seen this?  or understand it?


===>  Building for automake-1.16.1
--- doc/aclocal.1 ---
--- doc/automake.1 ---
--- bin/automake ---

[...]ls pkg/All

/usr/bin/make  install-data-hook
 chmod +x 
'/usr/ports/devel/automake/work/stage/usr/local/share/automake-1.16/config.guess'
 chmod +x 
'/usr/ports/devel/automake/work/stage/usr/local/share/automake-1.16/config.sub'
 chmod +x 
'/usr/ports/devel/automake/work/stage/usr/local/share/automake-1.16/install-sh'
 chmod +x 
'/usr/ports/devel/automake/work/stage/usr/local/share/automake-1.16/mdate-sh'
 chmod +x 
'/usr/ports/devel/automake/work/stage/usr/local/share/automake-1.16/missing'
 chmod +x 
'/usr/ports/devel/automake/work/stage/usr/local/share/automake-1.16/mkinstalldirs'
 chmod +x 
'/usr/ports/devel/automake/work/stage/usr/local/share/automake-1.16/ylwrap'
 chmod +x 
'/usr/ports/devel/automake/work/stage/usr/local/share/automake-1.16/depcomp'
 chmod +x 
'/usr/ports/devel/automake/work/stage/usr/local/share/automake-1.16/compile'
 chmod +x 
'/usr/ports/devel/automake/work/stage/usr/local/share/automake-1.16/py-compile'
 chmod +x 
'/usr/ports/devel/automake/work/stage/usr/local/share/automake-1.16/ar-lib'
 chmod +x 
'/usr/ports/devel/automake/work/stage/usr/local/share/automake-1.16/test-driver'
 chmod +x 
'/usr/ports/devel/automake/work/stage/usr/local/share/automake-1.16/tap-driver.sh'
find: 
/usr/ports/devel/automake/work/stage/usr/local/lib/perl5/site_perl: No 
such file or directory

> Compressing man pages (compress-man)
===>  Installing for automake-1.16.1
===>   Registering installation for automake-1.16.1 as automatic
*** Error code 70

[...]


___
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: Reproducibility packages

[Julian Elischer]

On 4/8/18 7:44 am, Yuet-nan Wong via freebsd-ports wrote:

Are FreeBSD ports supposed to change version numbers when a change is made?
Issue is reproducibility is void when packages have changed like suricata or 
the many changes to binutils. Some removing package content but version not 
changed. Need to diff Makefile is inefficient.
___
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"


yes and no.

When any change is made to a port (or any component of it) at least 
the last digit (after the '_') should be changed.


However if it has a dependency on another package, and THAT package 
changes it's version number, then the dependency information in the 
first package will reflect the new dependency, but the name of that 
package will not be changed.. so you could say it is imperfect in 
noting any external changes. I don't see a way around that at the 
current time.



___
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: Archives of last quarterly package builds?

[Julian Elischer]

On 3/8/18 11:17 am, Kurt Jaeger wrote:

Hi!


I've asked for this but the answer is
"no we don't do that..  and have no plans to".

What is the rationale?

I don't know, but as the setup of your own package builder box
is simple enough -- wouldn't that be an alternative for you ?
If the answer is always "don't use the quarterly packages but create 
your own, then why have them at all?"


Think about it.. Every three months we spend time adding bug fixes and 
stability fixes to a branch.
then just as it's getting good..    we delete all the pkgs.  It makes 
no sense at all.



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

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

[Julian Elischer]

It says it can not find the file curl/curl.h which IS PRESENT as 
/usr/local/include/curl/curl.h


There are Makefile BROKEN annotations for this error in mips etc but 
I'm seeing it now on amd64.


I would think that all ports should have /usr/local/include in their 
Include list but maybe not?


is this something that is supplied by the framework?


ports tree checked out from a week ago and today... same issue.


there is no /usr/local/include in the failing command line...

gmake[1]: Entering directory 
'/usr/ports/sysutils/google-compute-engine-oslogin/work/compute-image-packages-20180611/google_compute_engine_oslogin'
g++ -O2 -pipe  -fstack-protector  -fPIC -I/usr/local/include/json-c -c 
utils/oslogin_utils.cc -o utils/oslogin_utils.o
utils/oslogin_utils.cc:16:23: error: curl/curl.h: No such file or 
directory



I'm guessing there should be but who's responsibility is it to put it 
there?


(and where/how?)


Julian



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

[Julian Elischer]

On 8/8/18 1:02 pm, Julian Elischer wrote:
It says it can not find the file curl/curl.h which IS PRESENT as 
/usr/local/include/curl/curl.h


There are Makefile BROKEN annotations for this error in mips etc but 
I'm seeing it now on amd64.


I would think that all ports should have /usr/local/include in their 
Include list but maybe not?


is this something that is supplied by the framework?


ports tree checked out from a week ago and today... same issue.


there is no /usr/local/include in the failing command line...

gmake[1]: Entering directory 
'/usr/ports/sysutils/google-compute-engine-oslogin/work/compute-image-packages-20180611/google_compute_engine_oslogin'
g++ -O2 -pipe  -fstack-protector  -fPIC -I/usr/local/include/json-c 
-c utils/oslogin_utils.cc -o utils/oslogin_utils.o
utils/oslogin_utils.cc:16:23: error: curl/curl.h: No such file or 
directory



I'm guessing there should be but who's responsibility is it to put 
it there?


I got past it by adding (temporarily) the following to make.conf

for some faiign g++ commands
CFLAGS+-I /usr/local/include

and for others
LDFLAGS+=-L/usr/local/lib -I /usr/local/include

but that stinks

better suggestions welcome..



(and where/how?)


Julian



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

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

[Julian Elischer]

On 8/8/18 1:59 pm, Fernando Apesteguía wrote:

On Wed, Aug 8, 2018 at 7:40 AM Julian Elischer  wrote:

On 8/8/18 1:02 pm, Julian Elischer wrote:

It says it can not find the file curl/curl.h which IS PRESENT as
/usr/local/include/curl/curl.h

There are Makefile BROKEN annotations for this error in mips etc but
I'm seeing it now on amd64.

I would think that all ports should have /usr/local/include in their
Include list but maybe not?

is this something that is supplied by the framework?


ports tree checked out from a week ago and today... same issue.


there is no /usr/local/include in the failing command line...

gmake[1]: Entering directory
'/usr/ports/sysutils/google-compute-engine-oslogin/work/compute-image-packages-20180611/google_compute_engine_oslogin'
g++ -O2 -pipe  -fstack-protector  -fPIC -I/usr/local/include/json-c
-c utils/oslogin_utils.cc -o utils/oslogin_utils.o
utils/oslogin_utils.cc:16:23: error: curl/curl.h: No such file or
directory


I'm guessing there should be but who's responsibility is it to put
it there?

I got past it by adding (temporarily) the following to make.conf

for some faiign g++ commands
CFLAGS+-I /usr/local/include

and for others
LDFLAGS+=-L/usr/local/lib -I /usr/local/include

but that stinks

better suggestions welcome..

Is this what you are looking for?

USES=localbase

https://www.freebsd.org/doc/en/books/porters-handbook/uses-localbase.html


yeah that would help for  libs but not for the includes..  actually 
maybe it would't help because I'd still want /lib in the path.
the link you give says that LIBS would be replaced?  what does that 
actually mean?





(and where/how?)


Julian



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



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

[Julian Elischer]

On 8/8/18 1:59 pm, Fernando Apesteguía wrote:

On Wed, Aug 8, 2018 at 7:40 AM Julian Elischer  wrote:

On 8/8/18 1:02 pm, Julian Elischer wrote:

It says it can not find the file curl/curl.h which IS PRESENT as
/usr/local/include/curl/curl.h

There are Makefile BROKEN annotations for this error in mips etc but
I'm seeing it now on amd64.

I would think that all ports should have /usr/local/include in their
Include list but maybe not?

is this something that is supplied by the framework?


ports tree checked out from a week ago and today... same issue.


there is no /usr/local/include in the failing command line...

gmake[1]: Entering directory
'/usr/ports/sysutils/google-compute-engine-oslogin/work/compute-image-packages-20180611/google_compute_engine_oslogin'
g++ -O2 -pipe  -fstack-protector  -fPIC -I/usr/local/include/json-c
-c utils/oslogin_utils.cc -o utils/oslogin_utils.o
utils/oslogin_utils.cc:16:23: error: curl/curl.h: No such file or
directory


I'm guessing there should be but who's responsibility is it to put
it there?

I got past it by adding (temporarily) the following to make.conf

for some faiign g++ commands
CFLAGS+-I /usr/local/include

and for others
LDFLAGS+=-L/usr/local/lib -I /usr/local/include

but that stinks

better suggestions welcome..

Is this what you are looking for?

USES=localbase

https://www.freebsd.org/doc/en/books/porters-handbook/uses-localbase.html


nope..
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



(and where/how?)


Julian



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



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

[Julian Elischer]

On 8/8/18 2:30 pm, Julian Elischer wrote:

On 8/8/18 1:59 pm, Fernando Apesteguía wrote:
On Wed, Aug 8, 2018 at 7:40 AM Julian Elischer  
wrote:

On 8/8/18 1:02 pm, Julian Elischer wrote:

It says it can not find the file curl/curl.h which IS PRESENT as
/usr/local/include/curl/curl.h

There are Makefile BROKEN annotations for this error in mips etc but
I'm seeing it now on amd64.

I would think that all ports should have /usr/local/include in their
Include list but maybe not?

is this something that is supplied by the framework?


ports tree checked out from a week ago and today... same issue.


there is no /usr/local/include in the failing command line...

gmake[1]: Entering directory
'/usr/ports/sysutils/google-compute-engine-oslogin/work/compute-image-packages-20180611/google_compute_engine_oslogin' 


g++ -O2 -pipe  -fstack-protector  -fPIC -I/usr/local/include/json-c
-c utils/oslogin_utils.cc -o utils/oslogin_utils.o
utils/oslogin_utils.cc:16:23: error: curl/curl.h: No such file or
directory


I'm guessing there should be but who's responsibility is it to put
it there?

I got past it by adding (temporarily) the following to make.conf

for some faiign g++ commands
CFLAGS+-I /usr/local/include

and for others
LDFLAGS+=-L/usr/local/lib -I /usr/local/include

but that stinks

better suggestions welcome..

Is this what you are looking for?

USES=localbase

https://www.freebsd.org/doc/en/books/porters-handbook/uses-localbase.html 



nope..
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


seems that --system is being inconsistently applied

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



(and where/how?)


Julian



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



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

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

[Julian Elischer]

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"

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

[Julian Elischer]

On 13/8/18 9:16 pm, Helen Koike wrote:

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.

Ok so thanks to everyone.  It's been educational.
Will the change in the bug be checked in?

Every few months I recompile all the packages we need at $JOB and each 
time the hope is that we can get all the way through,
tough there is nearly always one that falls over in some new way.. (we 
install a couple of hundred packages.
this time it was sysutils/google-compute-engine-oslogin (and a couple 
of others..)
Hopefully the fixes that go in this time will give me (false) hope of 
a clean run next time  :-)








Because of my lack of experience.


Ah but you did do the port, for which I thank you!.




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"

Re: [HEADSUP] Removing DESTDIR support (aka chroot not staging)

[Julian Elischer]

On 10/2/19 11:47 AM, Baptiste Daroussin wrote:

Hello,

As far as I know, the chroot support in the ports tree, is not used by anyone
(and is broken in many areas) this is the feature called DESTDIR.

If anyone is using it, can you please raise your voice, in order to understand
your use case and see if we should juste remove the support for it, or fix it to
turn it into a usable sate?

Best regards,
Bapt


I can not check now but I may have used it int he build system at 
Panzura..


please check with Josh Paetzel who has access to the scripts.

___
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: fetch is tarpitted by Texas Instruments and/or Akamai and can not download distfiles for TI-related ports.

[Julian Elischer]

On 4/3/20 7:39 AM, Lev Serebryakov wrote:

On 03.04.2020 16:47, Kurt Jaeger wrote:


  I don't know, is it generic for Akamai or TI-specific.

  I think, somebody with official hat (FreeBSD Foundation speakperson?)
should contact TI and Akamai about this situation. Faking User-Agent
could be only temporary solution!

I've opened a case with ti.com, CS0177749.

I guess this will take some time to resolve. Someone from akamai
suggests that it might be some mis-selected option selected
for the CDN from akamai and that TI should get in touch with
the akamai support to get it sorted.

Let's see the efficiency of the free markets at work 8-)

  Thank you very much!



I've brought this up with a friend at akamai..

He's looking into it..

Julian


___
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: fetch is tarpitted by Texas Instruments and/or Akamai and can not download distfiles for TI-related ports.

[Julian Elischer]

On 4/5/20 11:11 AM, Julian Elischer wrote:

On 4/3/20 7:39 AM, Lev Serebryakov wrote:

On 03.04.2020 16:47, Kurt Jaeger wrote:


  I don't know, is it generic for Akamai or TI-specific.

  I think, somebody with official hat (FreeBSD Foundation 
speakperson?)

should contact TI and Akamai about this situation. Faking User-Agent
could be only temporary solution!

I've opened a case with ti.com, CS0177749.

I guess this will take some time to resolve. Someone from akamai
suggests that it might be some mis-selected option selected
for the CDN from akamai and that TI should get in touch with
the akamai support to get it sorted.

Let's see the efficiency of the free markets at work 8-)

  Thank you very much!



I've brought this up with a friend at akamai..

He's looking into it..


Ok I see it's fixed.. called him off.




Julian


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

patch to bsd.ports.mk to support out-of-tree patches.

[Julian Elischer]

Hi, I've a need to keep soe changes outside of the ports tree, to 
allow me to tailor
our installs. I could use the "EXTRA_PATCHES" setting, but I'd have to 
outline the

patches every time and keep track of them one by one.

Instead, I have adde dhte following to bsd.ports.mk:



diff -u bsd.port.mk.orig bsd.port.mk
--- bsd.port.mk.orig2015-03-23 21:55:47.498891000 -0700
+++ bsd.port.mk2015-03-23 22:15:16.757385000 -0700
@@ -834,6 +834,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}
 #
@@ -3523,6 +3528,37 @@
 esac | ${PATCH} ${PATCH_DIST_ARGS} `patch_dist_strip $$i` ; \
 done )
 .endif
+.if defined(EXTRA_PATCH_TREE)
+@set -e ;\
+if [ -d ${EXTRA_PATCH_TREE} ]; 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 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} "=> 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
 .if defined(EXTRA_PATCHES)
 @set -e ; \
 for i in ${EXTRA_PATCHES}; do \





this allows me to keep as many patches as I require in a separate 
"out-of-tree"
repository, that I can change at will, allowing the actual ports tree 
to be

updated as needed with no chances of file collisions etc.

Basically I keep a second parallel 'shadow' tree containing nothing 
but patches, and

the ports tree remains unchanged.

Is there any interest on taking this onboard?


Julian




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

Re: patch to bsd.ports.mk to support out-of-tree patches.

[Julian Elischer]

On 3/24/15 1:45 PM, Chris H wrote:

On Tue, 24 Mar 2015 13:33:15 +0800 Julian Elischer  wrote


Hi, I've a need to keep soe changes outside of the ports tree, to
allow me to tailor
our installs. I could use the "EXTRA_PATCHES" setting, but I'd have to
outline the
patches every time and keep track of them one by one.

Instead, I have adde dhte following to bsd.ports.mk:



diff -u bsd.port.mk.orig bsd.port.mk
--- bsd.port.mk.orig2015-03-23 21:55:47.498891000 -0700
+++ bsd.port.mk2015-03-23 22:15:16.757385000 -0700
@@ -834,6 +834,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}
   #
@@ -3523,6 +3528,37 @@
   esac | ${PATCH} ${PATCH_DIST_ARGS} 'patch_dist_strip $$i' ; \
   done )
   .endif
+.if defined(EXTRA_PATCH_TREE)
+@set -e ;\
+if [ -d ${EXTRA_PATCH_TREE} ]; 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 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} "=> 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
   .if defined(EXTRA_PATCHES)
   @set -e ; \
   for i in ${EXTRA_PATCHES}; do \





this allows me to keep as many patches as I require in a separate
"out-of-tree"
repository, that I can change at will, allowing the actual ports tree
to be
updated as needed with no chances of file collisions etc.

Basically I keep a second parallel 'shadow' tree containing nothing
but patches, and
the ports tree remains unchanged.

Is there any interest on taking this onboard?

Thank you for this, Julian!
Absolutely interested in seeing this. I've been forced
to kludge a similar approach. This would be wonderful.
Well, we'll see what the regular ports people think.. I am not a ports 
committer :-)




Please do.

--Chris




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

Re: patch to bsd.ports.mk to support out-of-tree patches.

[Julian Elischer]

On 3/25/15 9:50 AM, Bryan Drewery wrote:

On 3/24/2015 5:32 AM, Marcus von Appen wrote:

Julian Elischer :

[...]

  esac | ${PATCH} ${PATCH_DIST_ARGS} `patch_dist_strip $$i` ; \
  done )
  .endif
+.if defined(EXTRA_PATCH_TREE)

[...]

+.endif
  .if defined(EXTRA_PATCHES)
  @set -e ; \
  for i in ${EXTRA_PATCHES}; do \




Nice. I'd however change the patch behaviour to the following:

- patch-* from FreeBSD
- EXTRA_PATCHES from FreeBSD
- local patches

Your patch looks like it appleis the out-of-tree patches prior
to any EXTRA_PATCHES defined by the port itself. This should not be
the case, in my opinion. Locally managed patches should always come
last to ensure that all FreeBSD/maintainer-specific bits have been
applied and the local changes are just added on top of those.

Cheers
Marcus


Agreed. The local patches are intended to avoid touching the port. If
they are not last then you may have to go tweaking some of the other
ports patches to fix your own.


that makes sense..  it just means shifting the code down a bit..

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

compiling ports with --sysroot= and -isystem

[Julian Elischer]

How can I add entries (like the above) to a port compile?
I want to ADD things to CFLAGS.
If I add 'CFLAGS=...' to the build (for example, of lsof)  it actually 
replaces all the CFLAGS already there.
lsof (as the example) uses configure, so I would need to feed the 
added stuff into configure. Is there a standard way to do this?
In the environment I'm using, I'm building for a machine that is not 
the build machine, but an appliance.
It has a small number of differences in the include file contents, so 
I want it to compile using a different set of includes than those in 
/usr/include.


On the other hand I'm building a bunch of tools that do have t orun on 
the build machine and they need to use the regular /usr/include so I 
don't really want to replace them..



Julian

p.s. usual "please reply directly" comment applies.. I'm on this list 
but get it in digest form..


___
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: compiling ports with --sysroot= and -isystem

[Julian Elischer]

On 22/04/2016 11:18 AM, olli hauer wrote:

On 2016-04-22 04:04, Julian Elischer wrote:

How can I add entries (like the above) to a port compile?
I want to ADD things to CFLAGS.
If I add 'CFLAGS=...' to the build (for example, of lsof)  it actually replaces 
all the CFLAGS already there.
lsof (as the example) uses configure, so I would need to feed the added stuff 
into configure. Is there a standard way to do this?
In the environment I'm using, I'm building for a machine that is not the build 
machine, but an appliance.
It has a small number of differences in the include file contents, so I want it 
to compile using a different set of includes than those in /usr/include.

On the other hand I'm building a bunch of tools that do have t orun on the 
build machine and they need to use the regular /usr/include so I don't really 
want to replace them..


Julian

p.s. usual "please reply directly" comment applies.. I'm on this list but get 
it in digest form..


Use the '+=' notation, e.g.

# Makefile
...
CFLAGS+="--sysroot="
...


sorry I wasn't clear..

I want to add something to the make command, not edit Makefiles.

I could add something to bsd.autotools.mk or some similar Makefile 
include. but really I want to do it on a case by case basis.

there is an averall Makefile (using gmake)  that effectively does:
cd /usr/ports/$(PORT_DIR); $(BMAKE) $(ARGS) install clean

(except it does a lot of them)

I want to know what to add to $(ARGS) to make it use the correct 
include files.  my current "work-around" is to do:


mv /usr/include /usr/include.hold; ln -s $(STAGING_DIR)/usr/include 
/usr/include

cd /usr/ports/$(PORT_DIR); $(BMAKE) $(ARGS) install clean
rm /usr/include; mv /usr/include.hold /usr/include

this is *NOT* a clean solution :-)





___
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 for both ports and current

[Julian Elischer]

In a move to support real krenel threads doing work in the kernel,
the code that creates kerel processes has been renamed kthread_xxx to 
kproc_xxx


teh following ports seem to reference the renamed functions in kld 
modules they create.


I'm not a ports export so I'm not sure how to get a port to
change it's behaviour in 8.0 as opposed to 7.0

these are the ports (in fact the lines in the ports) that
will fail at this time..

# find . -name "*.[ch]" |xargs grep kthread
./audio/emu10kx/work/emu10kx-2005-10-21/emu10kx-dev.c:#include 



not sure why this  is needed as it doesn;t seem to use it..

./devel/sdl12/work/SDL-1.2.11/src/thread/dc/SDL_systhread_c.h:typedef 
struct kthread* SYS_ThreadHandle;


seems to be a namespace collision.

./emulators/snespp/work/snespp-1.0/snespp.c:#include 
./emulators/snespp/work/snespp-1.0/snespp.c:/* kthread to poll the 
controllers.

./emulators/snespp/work/snespp-1.0/snespp.c:kthread_exit(error);
./emulators/snespp/work/snespp-1.0/snespp.c:
kthread_suspend_check(snespp_eventq_proc);

./emulators/snespp/work/snespp-1.0/snespp.c:kthread_exit(0);
./emulators/snespp/work/snespp-1.0/snespp.c:error = 
kthread_create(snespp_updateeventq, (void *)sc,
./emulators/snespp/work/snespp-1.0/snespp.c:
device_printf(sc->device, "timeout on eventq kthread.\n");


snespp seems to really need some of the entries replaced..


./misc/zaptel/work/zaptel-bsd-1.4.6/wcfxs/wcfxs.c:#include 
./misc/zaptel/work/zaptel-bsd-1.4.6/wcfxs/wcfxs.c:  /* struct proc  
*kthread; */

./misc/zaptel/work/zaptel-bsd-1.4.6/zaptel/zaptel.c:#include 
./misc/zaptel/work/zaptel-bsd-1.4.6/zaptel/zaptel.c:static struct 
proc*kthread;
./misc/zaptel/work/zaptel-bsd-1.4.6/zaptel/zaptel.c:static 
intkthread_must_exit;

./misc/zaptel/work/zaptel-bsd-1.4.6/zaptel/zaptel.c:wakeup(kthread);
./misc/zaptel/work/zaptel-bsd-1.4.6/zaptel/zaptel.c:if 
(kthread_must_exit) {
./misc/zaptel/work/zaptel-bsd-1.4.6/zaptel/zaptel.c:
kthread_exit(0);
./misc/zaptel/work/zaptel-bsd-1.4.6/zaptel/zaptel.c:
tsleep(kthread, PZERO, "waitdata", 10);
./misc/zaptel/work/zaptel-bsd-1.4.6/zaptel/zaptel.c:
kthread_must_exit = 0;
./misc/zaptel/work/zaptel-bsd-1.4.6/zaptel/zaptel.c:if 
(kthread_create(selwakeup_thread_handler, (void *)toselwakeup, &kthread, 
0, 0, "zt_selwakeup_thread"))
./misc/zaptel/work/zaptel-bsd-1.4.6/zaptel/zaptel.c:
printf("Failed to create kthread\n");
./misc/zaptel/work/zaptel-bsd-1.4.6/zaptel/zaptel.c:if 
(kthread) {
./misc/zaptel/work/zaptel-bsd-1.4.6/zaptel/zaptel.c:
kthread_must_exit = 1;
./misc/zaptel/work/zaptel-bsd-1.4.6/zaptel/zaptel.c:
wakeup(kthread);


zaptel seems real. needs to be handled.

./net/p54u/work/p54u-0.8/driver/devnode.c:#include 

this seems unused..

I'm not sure how I go about patching these two ports to  handle the 
kthread->kproc

for 8.0

rename. Any help appreciated.


julian


___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

question for both ports and current

[Julian Elischer]

## resend as the original seems to have gotten hung up somewhere...

In a move to support real krenel threads doing work in the kernel,
the code that creates kerel processes has been renamed kthread_xxx to 
kproc_xxx


teh following ports seem to reference the renamed functions in kld 
modules they create.


I'm not a ports export so I'm not sure how to get a port to
change it's behaviour in 8.0 as opposed to 7.0

these are the ports (in fact the lines in the ports) that
will fail at this time..

# find . -name "*.[ch]" |xargs grep kthread
./audio/emu10kx/work/emu10kx-2005-10-21/emu10kx-dev.c:#include 



not sure why this  is needed as it doesn;t seem to use it..

./devel/sdl12/work/SDL-1.2.11/src/thread/dc/SDL_systhread_c.h:typedef 
struct kthread* SYS_ThreadHandle;


seems to be a namespace collision.

./emulators/snespp/work/snespp-1.0/snespp.c:#include 
./emulators/snespp/work/snespp-1.0/snespp.c:/* kthread to poll the 
controllers.

./emulators/snespp/work/snespp-1.0/snespp.c:kthread_exit(error);
./emulators/snespp/work/snespp-1.0/snespp.c:
kthread_suspend_check(snespp_eventq_proc);

./emulators/snespp/work/snespp-1.0/snespp.c:kthread_exit(0);
./emulators/snespp/work/snespp-1.0/snespp.c:error = 
kthread_create(snespp_updateeventq, (void *)sc,
./emulators/snespp/work/snespp-1.0/snespp.c:
device_printf(sc->device, "timeout on eventq kthread.\n");


snespp seems to really need some of the entries replaced..


./misc/zaptel/work/zaptel-bsd-1.4.6/wcfxs/wcfxs.c:#include 
./misc/zaptel/work/zaptel-bsd-1.4.6/wcfxs/wcfxs.c:  /* struct proc  
*kthread; */

./misc/zaptel/work/zaptel-bsd-1.4.6/zaptel/zaptel.c:#include 
./misc/zaptel/work/zaptel-bsd-1.4.6/zaptel/zaptel.c:static struct 
proc*kthread;
./misc/zaptel/work/zaptel-bsd-1.4.6/zaptel/zaptel.c:static 
intkthread_must_exit;

./misc/zaptel/work/zaptel-bsd-1.4.6/zaptel/zaptel.c:wakeup(kthread);
./misc/zaptel/work/zaptel-bsd-1.4.6/zaptel/zaptel.c:if 
(kthread_must_exit) {
./misc/zaptel/work/zaptel-bsd-1.4.6/zaptel/zaptel.c:
kthread_exit(0);
./misc/zaptel/work/zaptel-bsd-1.4.6/zaptel/zaptel.c:
tsleep(kthread, PZERO, "waitdata", 10);
./misc/zaptel/work/zaptel-bsd-1.4.6/zaptel/zaptel.c:
kthread_must_exit = 0;
./misc/zaptel/work/zaptel-bsd-1.4.6/zaptel/zaptel.c:if 
(kthread_create(selwakeup_thread_handler, (void *)toselwakeup, &kthread, 
0, 0, "zt_selwakeup_thread"))
./misc/zaptel/work/zaptel-bsd-1.4.6/zaptel/zaptel.c:
printf("Failed to create kthread\n");
./misc/zaptel/work/zaptel-bsd-1.4.6/zaptel/zaptel.c:if 
(kthread) {
./misc/zaptel/work/zaptel-bsd-1.4.6/zaptel/zaptel.c:
kthread_must_exit = 1;
./misc/zaptel/work/zaptel-bsd-1.4.6/zaptel/zaptel.c:
wakeup(kthread);


zaptel seems real. needs to be handled.

./net/p54u/work/p54u-0.8/driver/devnode.c:#include 

this seems unused..

I'm not sure how I go about patching these two ports to  handle the 
kthread->kproc

for 8.0

rename. Any help appreciated.


julian



___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

perforce port fails on 10.0

[Julian Elischer]

Gordon, I don't know if you have seen this but the p4 port fails on 
10.0 unless you have the compat9 (or 8 or 7) port loaded first, as it 
is linked on 7.0 and requires libstdc++ which is no longer present.


I don't know how dependencies are done  on ports but I guess there 
should be some depedency added if it's 10 or later.




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

Re: poudriere: setting up jail failes

[Julian Elischer]

On 8/9/14, 2:43 AM, Bryan Drewery wrote:

On 8/8/2014 11:46 AM, Matthias Apitz wrote:

Hello,

I'm setting up a jail with poudriere(8) to compile my ports; after some
hours it is crashing with:

# poudriere jail -c -j freebsd-head -m svn+http -v head ; date

[...]

mtree: illegal option -- N
usage: mtree [-LPUcdeinqruxw] [-f spec] [-f spec] [-K key] [-k key] [-p
path] [-s seed]
 [-X excludes]
*** Error code 1

[...]


The host where poudriere is running is:

# uname -a
FreeBSD vm-tiny-r255948 10.0-ALPHA4 FreeBSD 10.0-ALPHA4 #1: Fri Oct 18
12:10:57 CEST 2013 g...@aurora.sisis.de:/usr/obj/usr/src/sys/GENERIC
i386

i.e. a CURRENT from Oct 2013 (r255948). Does this mean I should update
the host where poudriere is running before?

Yes. For you it is fixed in stable/10 r257460 (which was in before 10.0
release) which added -N to mtree. There was a lot of polish at the end
of 10.0 so you should probably upgrade to at least 10.0 either way.

It could be that older releases building 10 and head for Poudriere may
be an issue still. I'll have to test more. Specifically the call of
'make distrib-dirs DB_FROM_SRC=1' seemingly not using the itools version
of mtree.

Also note that running a head jail on a 10.0 system is not really
supported. You may run into many weird issues building packages. It's
supported to have your host be newer than the jails but not the other
way around.

Regards,
Bryan Drewery

I had to do
cd /usr/src/{mumble}/mtree; make ; make install
before  I could upgrade from where I was in the current branch to 
where I wanted to get the 10 branch.

similar for install.



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

Re: [HEADSUP] pkg(8) is now the only package management tool

[Julian Elischer]

On 9/1/14, 6:39 PM, Sam Fourman Jr. wrote:

And for the portsnap users?



In short, this change doesn't directly effect portsnap users.

Portsnap is a tool that used to obtain a copy of the ports tree.

Portsnap is only one way, another way to get a copy of the ports tree is by
using subversion and checking it out by using the svn command.

pkg(8) is a package management tool, and to make use of most packages
having a copy of the ports tree is not required.

But it is if you don't want the options that a pkg is built with.
We need to do a lot of pkg munging for that reason, generating
our own versions (which is ok, that's not a complaint, just a fact of 
life).


I've warmed to pkg after using it a bit, and many of its initial
shortcomings have been fixed.
But one thing I'd like to request (a very minor thing)..
Could the packing list have some newlines inserted into it to make it 
more humanly readable? Our old tools for auditing and controlling (old 
style) packages would print out that information.

The new tools we need to write will need to do similar.
We did an experiment at work here and wrote a small script that parsed
it and then rewrote it back to the package with newlines added and
pkg handled it just fine, so it should be a very minor thing to add
some newlines when generating it in the first place.
I don't think anything else needs to be changed.




--
Michelle Sullivan
http://www.mhix.org/

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






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

Re: [HEADSUP] pkg(8) is now the only package management tool

[Julian Elischer]

On 9/1/14, 7:16 PM, Andrew Berg wrote:

On 2014.09.01 20:51, Michelle Sullivan wrote:

And for the portsnap users?
 

In short, this change doesn't directly effect portsnap users.
   

Sure about that?

I'm sure of it. Your issue is with the tree itself, not the tool used to fetch 
it.


Correct, take a 9.2 install disk, install it, portsnap and then install
pkg on it...  Oh wait, you can't.. pkg_install is broken, and 9.2
install disks don't have pkg in the BaseOS

Use the ports tree tarball included, or fetch it (either during or after
installation). It is not impossible to get an old version of the ports tree
with only the 9.2 base system. I don't see how this is anything more than an
inconvenience.
Also, 9.3 is out and the 9.2 EOL is not far away. Not sure why you would be
doing a new install with 9.2.


sigh..  when are we as a project, all going to learn that reality in 
business is
that you often need to install stuff that is old. Its not always your 
choice.

The custommers require it..
You should try arguing with someone like Bank of Americas security and 
operations
department some day about whether they want to suddenly upgrade 300 
machines

for no real reason (from their perspective).

On that topic, 10.0 is slightly broken from that perspective because
as you install it, it upgrades pkg to a new version that was not in 10.0,
so you can no longer build a 10.0 machine that matches the 10.0 
machines you

installed at the custommer site when 10.0 first came out, that they
qualified as acceptible..  Well you MAY get the mostly same result, but
the 'pkg' you have is a different one so the image checks out as
different' (Imaginary hooters sound and theoretical security alerts 
trigger etc.)
(oh and it interacts badly with the installer designed to run with the 
previous version..

The first part of the install works fine, and then half way
through the install, things go strange when pkg upgrades itself.)
10.0 is past but we should think about how to prevent that in 10.1 etc.
I guess the pkg config file in the install needs to be locked down to 
the release
until the install is completed. We should make sure the base install 
only installs

the pkg in the release and doesn't upgrade itself without asking first...

(luckily that last issue doesn't affect most business customers who 
use their own

install schemes).


___
freebsd-curr...@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"




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

Re: [HEADSUP] pkg(8) is now the only package management tool

[Julian Elischer]

On 9/1/14, 7:59 PM, Michelle Sullivan wrote:

Julian Elischer wrote:

You should try arguing with someone like Bank of Americas security and
operations
department

You work for the same company as me?

in a past life, they were a customer.



some day about whether they want to suddenly upgrade 300 machines
for no real reason (from their perspective).



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

Re: [HEADSUP] pkg(8) is now the only package management tool

[Julian Elischer]

On 9/1/14, 8:03 PM, Andrew Berg wrote:

On 2014.09.01 21:39, Julian Elischer wrote:

sigh..  when are we as a project, all going to learn that reality in
business is
that you often need to install stuff that is old. Its not always your
choice.
The custommers require it..
You should try arguing with someone like Bank of Americas security and
operations
department some day about whether they want to suddenly upgrade 300
machines
for no real reason (from their perspective).

FreeBSD minor version upgrades are meant to be non-disruptive. However, I will
admit that I have not performed any such upgrades in a critical environment, so
if you think they are disruptive, please enlighten me with the details.
Also, there are options out there for getting support for extended periods if
you need it. Some companies are built around providing support for things that
the original developers have long abandoned because some businesses need it.


It's not how disruptive they are technically.
it's how many months of shakedown testing you have to go through 
before they

allow you to put new software on any production system.

___
freebsd-sta...@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"



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

old ports/packages

[Julian Elischer]

Hi guys,

ok so I see:

2014-04-30 ports-mgmt/pkg_install: Replaced by ports-mgmt/pkg


So now how do enterprises maintaining appliances etc. generate packages for old 
systems?

(yeah I know about chroot/jails etc.) but we have it embedded into several 
workflows
that deliver stuff that is not 'regular packages'.
 
pkg_install is still available in 10.x, but when we move to 11 (we will lose that).

Can we please have a port made of the last pkg_install from the 10 branch so 
that
it is still available when we move to 10?

There WAS such a port but it was removed for some odd reason around the same 
time
it was removed from -current. (By rene)
The standard procedure for removing something from base usually includes making 
sure it is still available in ports.
Removing it from ports at the same time is a pretty bad breakage of POLA.

It is true that new machines will not need it but not all the world is a new 
machine.


___
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: old ports/packages

[Julian Elischer]

On 2/05/2016 8:39 PM, Mathieu Arnold wrote:

+--On 2 mai 2016 18:39:57 +0800 Julian Elischer  wrote:
| Hi guys,
|
| ok so I see:
|
| 2014-04-30 ports-mgmt/pkg_install: Replaced by ports-mgmt/pkg
|
|
| So now how do enterprises maintaining appliances etc. generate packages
| for old systems?

There is a tag, https://svnweb.freebsd.org/ports/tags/PKG_INSTALL_EOL/ that
gives you the last version to support pkg_install.  Anything after that
will not work with it.  At all.

I'm not looking to produce old packages of the ports tree.. I know the 
ports crew would hate me for that.


What I object to is not having the tools needed to generate MY OWN 
PACKAGES in ports.



___
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: old ports/packages

[Julian Elischer]

On 3/05/2016 2:31 PM, Mathieu Arnold wrote:


+--On 3 mai 2016 12:02:13 +0800 Julian Elischer  wrote:
| On 2/05/2016 8:39 PM, Mathieu Arnold wrote:
|> +--On 2 mai 2016 18:39:57 +0800 Julian Elischer 
|> wrote:
|> | Hi guys,
|> |
|> | ok so I see:
|> |
|> | 2014-04-30 ports-mgmt/pkg_install: Replaced by ports-mgmt/pkg
|> |
|> |
|> | So now how do enterprises maintaining appliances etc. generate packages
|> | for old systems?
|>
|> There is a tag, https://svnweb.freebsd.org/ports/tags/PKG_INSTALL_EOL/
|> that gives you the last version to support pkg_install.  Anything after
|> that will not work with it.  At all.
|>
| I'm not looking to produce old packages of the ports tree.. I know the
| ports crew would hate me for that.
|
| What I object to is not having the tools needed to generate MY OWN
| PACKAGES in ports.

You can generate your own packages from the ports tree, just not with
pkg_install, it was deprecated three or four years ago, and remove 19
months ago.
The best way to generate packages is with ports-mgmt/poudriere, it will
generate a very nice pkg repository.

Of course I can create NEW packages..  I want to generate OLD style 
packages..


what's so hard to understand about that?  if a company has old 
packages build into it's infrastructure


and has to create old style packages of "proprietary stuff" to send 
out to appliances out in the field then you are breaking them.



___
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: old ports/packages

[Julian Elischer]

On 4/05/2016 1:54 AM, Kevin Oberman wrote:
On Mon, May 2, 2016 at 11:31 PM, Mathieu Arnold <mailto:m...@freebsd.org>> wrote:




+--On 3 mai 2016 12:02:13 +0800 Julian Elischer
mailto:jul...@freebsd.org>> wrote:
| On 2/05/2016 8:39 PM, Mathieu Arnold wrote:
|> +--On 2 mai 2016 18:39:57 +0800 Julian Elischer
mailto:jul...@elischer.org>>
|> wrote:
|> | Hi guys,
|> |
|> | ok so I see:
|> |
|> | 2014-04-30 ports-mgmt/pkg_install: Replaced by ports-mgmt/pkg
|> |
|> |
|> | So now how do enterprises maintaining appliances etc.
generate packages
|> | for old systems?
|>
|> There is a tag,
https://svnweb.freebsd.org/ports/tags/PKG_INSTALL_EOL/
|> that gives you the last version to support pkg_install. 
Anything after

|> that will not work with it.  At all.
|>
| I'm not looking to produce old packages of the ports tree.. I
know the
| ports crew would hate me for that.
|
| What I object to is not having the tools needed to generate MY OWN
| PACKAGES in ports.

You can generate your own packages from the ports tree, just not
with
pkg_install, it was deprecated three or four years ago, and
remove 19
months ago.
The best way to generate packages is with ports-mgmt/poudriere,
it will
generate a very nice pkg repository.

--
Mathieu Arnold


You might also look at ports-mgmt/synth. It is far simpler than 
poudriere. While lacking any of the enterprise capabilities of 
poudriere, it is a simple tool to support a modern, local pkg 
repository of packages for distribution or to support locally 
modified ports or ports that need to be built with non-standard options.


From synth(1):
"The synth program is an advanced concurrent ports building tool 
aimed at
 system administrators that prefer or require the building of 
packages
 from source rather than installing official binary packages.  
synth will
 build packages in a clean environment exactly mirrors the 
system that
 they are built on, it will create local package repositories 
and install
 pkg(8) repository configuration file that causes locally built 
packages
 to be used with the highest priority, all while allowing the 
system to

 fully upgraded with a single command."

Its major issue with some is that it is written in Ada, but I just 
install the package for synth and never bother with building the Ada 
compiler.

--
Kevin Oberman, Part time kid herder and retired Network Engineer
E-mail: rkober...@gmail.com <mailto:rkober...@gmail.com>
PGP Fingerprint: D03FB98AFA78E3B78C1694B318AB39EF1B055683


SO if I have an infrastructure that uses old style packages to deliver 
data and configuration information to appliances in the field,


how does synth help me?

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

suggested patch for bsd.ports.mk

[Julian Elischer]

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..


Change 47442 by jelischer@jre-porridge-1 on 2015/03/25 08:30:42

Add suport for local patches

Affected files ...

... //depot/bugatti/FreeBSD-ports-PZ/10.1/Mk/bsd.port.mk#2 edit

Differences ...

 //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}
 #
@@ -3397,6 +3402,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

[Julian Elischer]

On 13/05/2016 3:19 AM, Julian H. Stacey wrote:

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.

Nice idea ! I'll have a look.
BTW I've had something somewhat similar for maybe a decade or so
http://berklix.com/~jhs/bin/.csh/customise
mine does:
- src + ports,
- generic + personal diffs as 2 parallel patch trees (cos some of my patches
   I hope may appeal generaly but some probaly only I will ever want),
- targets a load of different release levels inc current
- only does a one off pass, installing files & applying diffs to a virgin
   tree.

Your approach will be nicer than mine for tracking current ports.
I look forward to trying it, & if necessary perhaps bending my patch
trees to fit your macros :-)


thanks.. It works for us and allows us to slide stuff forwards, only 
stopping occasionally to fix a broken patch.


For a "Release"  we check out a snapshot of the ports tree, and branch 
the patches tree in case we want to change or add a patch to that 
snapshot of ports.

 anyone (in ports) think this is a BAD idea?





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

The MIME enclosure made it through mailman unscathed :-)

Cheers,
Julian
--
Julian Stacey, BSD Linux Unix Sys Eng Consultant Munich http://berklix.eu/jhs/
  Mail plain text,  No quoted-printable, HTML, base64, MS.doc.
  Prefix old lines '> '  Reply below old, like play script.  Break lines by 80.
  Britain denies 700,000+ Brits in EU a vote. http://www.berklix.eu/brexit/



___
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 13/05/2016 3:26 PM, Andrzej Tobola wrote:

On Fri, May 13, 2016 at 12:11:47AM +0800, 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.

>From a long time I am using unionfs - it simpler and allows also
to modyfy/mask all port files - e.g:

   mount -t nullfs -o ro  /pub/FreeBSD/SVN/ports /usr/ports
   mount -t unionfs -o ro /usr/local/ports   /usr/ports

-a

that is cool but it is not really suitable for use in a company's 
build farm.



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

destination of makepatch target

[Julian Elischer]

The makepatch target makes the patches in FILESDIR.

should it not make them in PATCHDIR?

they are defined by default to be the same thing:

PATCHDIR?=  ${MASTERDIR}/files
FILESDIR?=  ${MASTERDIR}/files

but it would seem to make more sense to have them appear in PATCHDIR 
if it's set differently.



Julian

___
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 13/05/2016 12:11 AM, Julian Elischer wrote:

so who or what decides if I can put this in?  As a long term committer 
from before there were ports, do I have access to it?
do I need to get a ports mentor? (seems likely and would make sense).. 
do I apply somewhere? Or should I look for soemone in ports to do it 
for me?




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..




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

best way to tune ports to add a CLFAGS entry

[Julian Elischer]

At work I am doing various cross compiles in order to make a product 
under freebsd that actually will run under a modified FreeBSD that 
runs on an appliance. We want to get away from hand rolling everything 
to leverage all teh work in getting ports working well on FreeBSD.


We have some extra syscalls and some structures have different sizes, 
so we need to compile/link agains an alternate set of 
includes/libraries and not those in /usr/include or /usr/lib.


Ideally I want to use the "--sysroot" and "-isystem" options to the 
compiler/linker or failing that, add a -I or -L entries to make it 
look at the correct includes and libraries, not those in the base system.



In many ports CFLAGS etc. are sent in via the arguments to ./configure 
or environment vars, but there are many other ports that have other 
ways to specify these.


Does the ports framework have any standard way to do this? 
LDEXTRA_ARGS or EXTRA_CFLAGS or similar?


I've looked around and can't really see anything.  Best would be a 
single file to which I could add these things but adding them to the 
environment would also work.


yours in ports ignorance..


Julian


___
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: best way to tune ports to add a CLFAGS entry

[Julian Elischer]

On 29/06/2016 8:43 AM, Alfred Perlstein wrote:



On 6/28/16 9:52 AM, Julian Elischer wrote:
At work I am doing various cross compiles in order to make a 
product under freebsd that actually will run under a modified 
FreeBSD that runs on an appliance. We want to get away from hand 
rolling everything to leverage all teh work in getting ports 
working well on FreeBSD.


We have some extra syscalls and some structures have different 
sizes, so we need to compile/link agains an alternate set of 
includes/libraries and not those in /usr/include or /usr/lib.


Ideally I want to use the "--sysroot" and "-isystem" options to the 
compiler/linker or failing that, add a -I or -L entries to make it 
look at the correct includes and libraries, not those in the base 
system.



In many ports CFLAGS etc. are sent in via the arguments to 
./configure or environment vars, but there are many other ports 
that have other ways to specify these.


Does the ports framework have any standard way to do this? 
LDEXTRA_ARGS or EXTRA_CFLAGS or similar?


I've looked around and can't really see anything.  Best would be a 
single file to which I could add these things but adding them to 
the environment would also work.


yours in ports ignorance..


Sounds like a decent idea to override includedirs, but I wouldn't 
trust it.  :)


Why not do what NANOBSD/FreeNAS do and compile inside a chroot (or 
even VM) with the proper includes and such installed?
we DO compile in a chroot. but that still requires that the local 
binaries use one set of .so files and the generated ones use a 
different set..
I do have ways around it.. like "rm -rf /usr/include/sys; ln -sfh 
/usr/product/sys/sys /usr/include/sys"


It sounds like a big sledgehammer to use a chroot or a VM, but in 
reality it's MUCH safer than some port accidentally pulling 
something from the wrong /usr/include and then you spending hours, 
days, etc tracking it down.  Trust me, I've seen the fallout and 
it's NOT FUN!!!


oh I have too.. tha't why I'm using a chroot, bur we dont' want to 
generate a new chroot for every sub-point-release, and have to store 
it away forever, so I'm making the chroots be "semi permanent" which 
means that differences arize between them and the sources as we 
diverge, and before we build another chroot..




For FreeNAS we made it so that you could run the FreeNAS OS (trueos) 
as the actual build server and that saved us a huge number of 
headaches.


yes I agree that would be nice but there are a large number of legacy 
issues at play so a cross-build style work flow is what I can get to.


If you're very, very against the idea of VM or chroot then you could 
just make /usr/include actually contain YOUR includes as you 
probably shouldn't need them otherwise on a build server.
yeah I'm kind of doing that already.. IN the chroot..  wish I didn't 
have to. the chroot system binaries are pretty much -RELEASE binaries. 
but we use them to generare FOO-OS binaries which have to link to 
other .so files.

-Alfred




-Alfred



___
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: best way to tune ports to add a CLFAGS entry

[Julian Elischer]

On 29/06/2016 12:01 PM, Chris H wrote:

On Wed, 29 Jun 2016 00:52:51 +0800 Julian Elischer  wrote


At work I am doing various cross compiles in order to make a product
under freebsd that actually will run under a modified FreeBSD that
runs on an appliance. We want to get away from hand rolling everything
to leverage all teh work in getting ports working well on FreeBSD.

We have some extra syscalls and some structures have different sizes,
so we need to compile/link agains an alternate set of
includes/libraries and not those in /usr/include or /usr/lib.

Ideally I want to use the "--sysroot" and "-isystem" options to the
compiler/linker or failing that, add a -I or -L entries to make it
look at the correct includes and libraries, not those in the base system.


In many ports CFLAGS etc. are sent in via the arguments to ./configure
or environment vars, but there are many other ports that have other
ways to specify these.

Does the ports framework have any standard way to do this?
LDEXTRA_ARGS or EXTRA_CFLAGS or similar?

I've looked around and can't really see anything.  Best would be a
single file to which I could add these things but adding them to the
environment would also work.

yours in ports ignorance..


Hi Julian.
While I can't answer your question directly.
Maybe a USES=FAKE_INCLUDE, USES=FAKE_LIB?
No. I haven't implemented it. Just throwing it out there, while
it occurs to me. If someone doesn't beat me to it. I'd like
to look into the feasibility of something like this, to
accommodate something along the lines of what you're asking about.
I often shy away from tasks I'd like to undertake, because it seems
like too much work to cobble up just the right environment to
accomplish it. But if I could make a universal convenience knob
like I mention above. It'd be perfect. Tho I haven't thought it
completely through. I like the sound of it. :-)

Apologies, for stepping on your thread. Hope you don't mind.


USES_SYSROOT=/foo/bar
would be the way to describe it

feedable from the environment, and interpretted by each package as it 
suits it.

(or taken from /etc/ports.conf) .
Is there a file like that? seems that /etc/make.conf is still 
controlling it.



Julian



--Chris





___
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: [SOLVED] Segfault in OpenSSL even though ports GnuTLS demanded (irssi and loudmouth)

[Julian Elischer]

On 2/08/2016 5:16 AM, Bertram Scharpf wrote:

On Thursday, 28. Jul 2016, 17:56:46 -0400, Jung-uk Kim wrote:

On 07/28/16 05:37 PM, Bertram Scharpf wrote:

On Thursday, 28. Jul 2016, 15:37:00 -0400, Jung-uk Kim wrote:

On 07/28/16 02:02 PM, Bertram Scharpf wrote:

   Program received signal SIGSEGV, Segmentation fault.
   [Switching to Thread 29403080 (LWP 101275/mcabber)]
   0x285c1245 in OPENSSL_ia32_cpuid () from /usr/local/lib/libcrypto.so.8

Try "ldd /usr/local/lib/libloudmouth-1.so.0.1.0".  It looks like a
Kerberos issue.

So, how could I resolve this?

You may ask its maintainer (gn...@freebsd.org) to add USES+=gssapi and
add an option to select GSS-API from ports.

I looked at the other 4(!) projects that set something like
USES+=gssapi and copied that to loudmouth, and I even had to
copy it to irssi. Now the segfault has gone away.

The patch is below.

I will not write a problem report as long as my running
problem reports aren't deemed worthy of an answer.what Are your current reports?


hmmm  do I sense frustration? :-/

Please DO at least drop it into a bug report..
what are your other bug reports?  I find the best way to get bug 
reports handled is to look in the history of the module concerned,

e.g. https://svnweb.freebsd.org/ports/head/irc/irssi/
 or 
https://svnweb.freebsd.org/ports/head/net-im/loudmouth/Makefile?view=log


and see who has been working on it recently and email them directly 
with a pointer to the bug


The bad part of how the project works is that there is no "manager" 
correlating bugs with people directly, so it's really easy to miss bug 
reports that you should be aware of.


In this case I've cc'd the people who may best be able to evaluate 
your patch, and since it is simple and you've done he work one hopes 
that one of them  will be able to comment and maybe even commit.


Julian



Bertram




diff --git a/irc/irssi/Makefile b/irc/irssi/Makefile
index d9a89fe..f7f9e45 100644
--- a/irc/irssi/Makefile
+++ b/irc/irssi/Makefile
@@ -43,6 +43,7 @@ TRUECOLOR_CONFIGURE_ENABLE=   true-color
  CONFIGURE_ARGS+=   --disable-ssl
  .else
  USE_OPENSSL=   yes
+USES+=gssapi:base,flags
  .endif

  post-patch:
diff --git a/net-im/loudmouth/Makefile b/net-im/loudmouth/Makefile
index ead1d4e..0a86d13 100644
--- a/net-im/loudmouth/Makefile
+++ b/net-im/loudmouth/Makefile
@@ -29,6 +29,8 @@ OPTIONS_DEFAULT=GNUTLS
  OPTIONS_RADIO= SSL
  OPTIONS_RADIO_SSL= GNUTLS OPENSSL

+USES+=gssapi:base,flags
+
  .include 

  .if ${PORT_OPTIONS:MGNUTLS}




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

Fwd: ipfw divert filter for IPv4 geo-blocking (port?)

[Julian Elischer]

Is there a ports committer who could take this in?
Since this announcement, he's made several fixes and enhancements, 
including the ability

to directly populate ipfw tables with country ranges etc.

Very useful, and we should have it in ports, probably in net-mgmt/
I've kicked the tires and it performs as advertised .

The Makefiles work well for installing on FreeBSD-current and 11 but 
someone who knows ports makefiles better than I could probably knock 
up a port for it in about 3 minutes flat.


I'm not sure what name he would like it to go under..  the geoip 
program (which I find more interesting) came later,

but as a better name I think.
Can we import directly from github?  do we keep a copy in our cache if 
we do? (I guess we could get the zip file..)



Julian

 Forwarded Message 

I have written a ipfw divert filter daemon for IPv4 geo-blocking. It is working 
flawlessly on two server installations since a week.

Anyway, I am still in doubt whether I do the blocking in the correct way. Once 
the filter receives a packet from the respective divert socket it looks up the 
country code of the source IP in the IP-Ranges database, and if the country 
code shall be allowed then it returns the unaltered packet via said socket, 
otherwise, the filter does no further processing, so the packet is effectively 
gone, lost, dropped, discarded, or whatever would be the correct terminology. 
Is this the really the correct way of denying a packet, or is it necessary to 
inform ipfw somehow about the circumstances, so it can run a proper dropping 
procedure?

I uploaded the filter + accompanying tools to GitHub

   https://github.com/cyclaero/ipdb

Many thnaks for any advices in advance.

Best regards

Rolf

 
___

freebsd-i...@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ipfw
To unsubscribe, send any mail to "freebsd-ipfw-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"

Re: freebsd-update and portsnap users still at risk of compromise

[Julian Elischer]

On 11/08/2016 1:11 AM, Mail Lists via freebsd-security wrote:



sorry but this is blabla and does not come even near to answering the real 
problem:

It appears that freebsd and the US-government is more connected that some of us 
might like:

Not publishing security issues concerning update mechanisms - we all can think 
WHY freebsd is not eager on this one.

Just my thoughts...


this has been in discussion a lot in private circles within FreeBSD.
It's not being ignored and a "correct" patch is being developed.

from one email I will quote just a small part..
===

As of yet, [the] patches for the libarchive vulnerabilities have not been 
released
upstream to be pulled into FreeBSD. In the meantime, HardenedBSD has created
patches for some of the libarchive vulnerabilities, the first[3] is being
considered for inclusion in FreeBSD, at least until a complete fix is
committed upstream, however the second[4] is considered too brute-force and
will not be committed as-is. Once the patches are in FreeBSD and updated
binaries are available, a Security Advisory will be issued.

===
so expect something soon.
I will go on to say that the threat does need to come from an advanced 
MITM actor,

though that does not make it a non threat..





Tuesday, August  9, 2016 8:21 PM UTC from Matthew Donovan 
:

You mean operating system as distribution is a Linux term. There's not much
different between HARDENEDBSD and FreeBSD besides that HardenedBSD fixes
vulnerabilities and has a an excellent ASLR system compared to the proposed
one for FreeBSD.

On Aug 9, 2016 3:10 PM, "Roger Marquis" < marq...@roble.com > wrote:


Timely update via Hackernews:

  

Note in particular:

  "FreeBSD is still vulnerable to the portsnap, freebsd-update, bspatch,
  and libarchive vulnerabilities."

Not sure why the portsec team has not commented or published an advisory
(possibly because the freebsd list spam filters are so bad that
subscriptions are being blocked) but from where I sit it seems that
those exposed should consider:

  cd /usr/ports
  svn{lite} co  https://svn.FreeBSD.org/ports/head /usr/ports
  make index
  rm -rf /usr/sbin/portsnap /var/db/portsnap/*

I'd also be interested in hearing from hardenedbsd users regarding the
pros and cons of cutting over to that distribution.

Roger



On 2016-07-29 09:00, Julian Elischer wrote:

not sure if you've been contacted privately, but  I believe the answer is
"we're working on it"


My concerns are as follows:

1. This is already out there, and FreeBSD users haven't been alerted that
they should avoid running freebsd-update/portsnap until the problems are
fixed.

2. There was no mention in the bspatch advisory that running
freebsd-update to "fix" bspatch would expose systems to MITM attackers who
are apparently already in operation.

3. Strangely, the "fix" in the advisory is incomplete and still permits
heap corruption, even though a more complete fix is available. That's
what prompted my post. If FreeBSD learned of the problem from the same
source document we all did, which seems likely given the coincidental
timing of an advisory for a little-known utility a week or two after that
source document appeared, then surely FreeBSD had the complete fix
available.

___

  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-secur...@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-security
To unsubscribe, send any mail to " freebsd-security-unsubscr...@freebsd.org "


Best regards,
Mail Lists
mli...@mail.ru
___
freebsd-secur...@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-security
To unsubscribe, send any mail to "freebsd-security-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"

Re: Passwordless accounts vi ports!

[Julian Elischer]

On 11/08/2016 1:16 PM, Ngie Cooper wrote:

On Aug 10, 2016, at 22:05, O. Hartmann  wrote:

I just checked the security scanning outputs of FreeBSD and found this
surprising result:

[...]
Checking for passwordless accounts:
polkitd::565:565::0:0:Polkit Daemon User:/var/empty:/usr/sbin/nologin
pulse::563:563::0:0:PulseAudio System User:/nonexistent:/usr/sbin/nologin
saned::194:194::0:0:SANE Scanner Daemon:/nonexistent:/bin/sh
clamav::106:106::0:0:Clamav Antivirus:/nonexistent:/usr/sbin/nologin
bacula::910:910::0:0:Bacula Daemon:/var/db/bacula:/usr/sbin/nologin
[...]

Obviously, some ports install accounts but do not secure them as there is an
empty password.

I consider this not a feature, but a bug.

saned is the only one that might concern me because the login shell isn't 
nologin(1).


but other tools use the password database.. e.g. ftp



Cheers,
-Ngie
___
freebsd-curr...@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-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"

dependency explosions

[Julian Elischer]

Hi ports people.

It seems to me that there has been an explosion in ports dependencies 
recently.
Things that used to need a few dependencies are now pulling in things 
one would never imagine.
We just had to add the openjdk7 port to something and the number of 
dependencies is at 120 and rising still.

(mostly due to an *undocumented* dependency on a cups include file).

I needed to add glib2 and I got over 20 dependencies. (and then it 
failed to compile).


12 ports I've been adding to my systems for years have now resulted in 
135 unexpected ports being built.

Some issues I've noted:

There is a need for a "minimum" install of a lot of packages.

Such a 'minimum' install should probably be the default when coming in 
as a dependency, as
there is an increasing tendency to configure things with all the bells 
and whistles.


anyone have any thought as to 1/ why the recent explosion, and 2/ what 
to do about it?


___
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: dependency explosions

[Julian Elischer]

On 3/10/2016 5:14 AM, Mathieu Arnold wrote:

Le 01/10/2016 à 04:35, Julian Elischer a écrit :

There is a need for a "minimum" install of a lot of packages.

Some dependencies are often optional, and can be unchecked by running
make config.

but you can never really know the effect.
there should be a use minimum environment variable and as I said, the 
minimum is usually what is required for build dependencies.
And the minimum install may require less "other" packages thus 
reducing the explosion.





Such a 'minimum' install should probably be the default when coming in
as a dependency, as
there is an increasing tendency to configure things with all the bells
and whistles.

The bare minimum will never be the default.  The default is what will
fit most people, so that they can use our packages out of the box.



___
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: dependency explosions

[Julian Elischer]

On 3/10/2016 5:14 AM, Mathieu Arnold wrote:

Le 01/10/2016 à 04:35, Julian Elischer a écrit :

There is a need for a "minimum" install of a lot of packages.

Some dependencies are often optional, and can be unchecked by running
make config.


Such a 'minimum' install should probably be the default when coming in
as a dependency, as
there is an increasing tendency to configure things with all the bells
and whistles.

The bare minimum will never be the default.  The default is what will
fit most people, so that they can use our packages out of the box.

I didn't say it should be the default, I said it should be an easy to 
request option,

(without using the config screen on each of 25000 ports)
e.g. setting PORTS_CONFIG_MINIMUM before making everything.
Most ports and packages are installed not because people want them,
but because they are forced to do so by dependencies.
Giving a way to reduce the number of unrequested packages, in a simple 
way would be of great use to many many people

___
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: dependency explosions

[Julian Elischer]

On 4/10/2016 11:38 PM, Mathieu Arnold wrote:

Le 05/10/2016 à 05:18, Julian Elischer a écrit :

On 3/10/2016 5:14 AM, Mathieu Arnold wrote:

Le 01/10/2016 à 04:35, Julian Elischer a écrit :

There is a need for a "minimum" install of a lot of packages.

Some dependencies are often optional, and can be unchecked by running
make config.


Such a 'minimum' install should probably be the default when coming in
as a dependency, as
there is an increasing tendency to configure things with all the bells
and whistles.

The bare minimum will never be the default.  The default is what will
fit most people, so that they can use our packages out of the box.


I didn't say it should be the default, I said it should be an easy to
request option,
(without using the config screen on each of 25000 ports)
e.g. setting PORTS_CONFIG_MINIMUM before making everything.
Most ports and packages are installed not because people want them,
but because they are forced to do so by dependencies.
Giving a way to reduce the number of unrequested packages, in a simple
way would be of great use to many many people

Feel free to open PR/provide patches for ports which you think need to
provide more options.

I think it would be a framework change.
not  so much a per-port change.
By default, when the variable is set you take the list of options for 
the package, and set them all to 'unset'.


The only packages that would need work would be those for which that 
is not a valid configuration, in which case you would supply some 
precanned list of options to set to unset (or similar)  e.g. 
MIN_SETTINGS="bla foo bar"


the point is that if I'm including a port becuase it's just a prereq. 
then I probably want almost no options set..  The port itself can 
probably know what options are likely to be needed by things that need 
it adn can possibly supply a sensible setting but if it doesn't it 
might be possible to just do it automatically. It's ridiculous that a 
single small port can pull in python, perl and TCL (I forget which it 
was) along with some 40 or so other packages.


Another thing that might be good woudl be a way to tell ports "remove 
all the ports that were just build dependencies".









___
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: dependency explosions

[Julian Elischer]

On 5/10/2016 1:39 PM, Miroslav Lachman wrote:

Julian Elischer wrote on 10/05/2016 22:04:

On 4/10/2016 11:38 PM, Mathieu Arnold wrote:

Le 05/10/2016 à 05:18, Julian Elischer a écrit :

On 3/10/2016 5:14 AM, Mathieu Arnold wrote:

Le 01/10/2016 à 04:35, Julian Elischer a écrit :

There is a need for a "minimum" install of a lot of packages.
Some dependencies are often optional, and can be unchecked by 
running

make config.

Such a 'minimum' install should probably be the default when 
coming in

as a dependency, as
there is an increasing tendency to configure things with all 
the bells

and whistles.
The bare minimum will never be the default.  The default is what 
will

fit most people, so that they can use our packages out of the box.

I didn't say it should be the default, I said it should be an 
easy to

request option,
(without using the config screen on each of 25000 ports)
e.g. setting PORTS_CONFIG_MINIMUM before making everything.
Most ports and packages are installed not because people want them,
but because they are forced to do so by dependencies.
Giving a way to reduce the number of unrequested packages, in a 
simple

way would be of great use to many many people
Feel free to open PR/provide patches for ports which you think 
need to

provide more options.

I think it would be a framework change.
not  so much a per-port change.
By default, when the variable is set you take the list of options for
the package, and set them all to 'unset'.

The only packages that would need work would be those for which 
that is
not a valid configuration, in which case you would supply some 
precanned
list of options to set to unset (or similar)  e.g. 
MIN_SETTINGS="bla foo

bar"

>

the point is that if I'm including a port becuase it's just a prereq.
then I probably want almost no options set..  The port itself can
probably know what options are likely to be needed by things that need
it adn can possibly supply a sensible setting but if it doesn't it 
might

be possible to just do it automatically. It's ridiculous that a single
small port can pull in python, perl and TCL (I forget which it was)
along with some 40 or so other packages.



There is one more problem - port A needs port B as dependency, port 
B can be compiled with 4 options [W,X,Y,Z], port A needs port B with 
option X which pull port C as dependency.
So this needs to be set somewhere or else default minimal options 
would break some ports.
any non-minimum port would trump a minimum port I would think. (and 
replace it?)


it's just an idea. Born from frustration of not being able to do thigs 
because htey call in too many other things.
If you call in too many other things the chance of one of them 
breaking gets higher. (approaches unity in some cases I think).



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: dependency explosions

[Julian Elischer]

On 5/10/2016 2:20 PM, Mathieu Arnold wrote:

Le 05/10/2016 à 22:04, Julian Elischer a écrit :

Another thing that might be good woudl be a way to tell ports "remove
all the ports that were just build dependencies".

pkg autoremove
hmm I didn't know that would remove build deps for packages that are 
still installed.. if so .. good!






___
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 capable of coping with --relocate?

[Julian Elischer]

for packages I'm using :

* PKG_DBDIR=/$(FOO)/var/db/pkg pkg add --relocate /$(FOO) $(PKGNAME)*

to build up an image in location "$FOO"  that I can tar up and install 
onto a machine.


however some other ports fail to find that a dependency has been 
installed..


e.g.

libglib2 is installed in the manner above, but then 
open-vm-tools-nox11 fails with:


*checking for glib-2.0 >= 2.6.0 (via pkg-config)... no**
**configure: error: glib >= 2.6.0 is required.**
*

is there  away to make the vmware port look in $FOO, or do I need to 
install libglib into the base system before vmware-tools will find it?



Julian

___
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 capable of coping with --relocate?

[Julian Elischer]

On 9/10/2016 10:35 PM, Julian Elischer wrote:


for packages I'm using :

* PKG_DBDIR=/$(FOO)/var/db/pkg pkg add --relocate /$(FOO) $(PKGNAME)*

to build up an image in location "$FOO"  that I can tar up and 
install onto a machine.


however some other ports fail to find that a dependency has been 
installed..


e.g.

libglib2 is installed in the manner above, but then 
open-vm-tools-nox11 fails with:


*checking for glib-2.0 >= 2.6.0 (via pkg-config)... no**
**configure: error: glib >= 2.6.0 is required.**
*

is there  away to make the vmware port look in $FOO, or do I need to 
install libglib into the base system before vmware-tools will find it?



I just noticed that
   glib-2.46.2Some useful routines of C 
programming (current stable version)

IS already on the base system..  how can I get past this?



Julian



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

harder and harder to avoid pkg

[Julian Elischer]

As the number of dependencies between packages get ever higher, it 
becomes more and more difficult to compile packages and the dependence 
on binary precompiled packages is increased. However binary packages 
are unsuitable for some situations.  We really need to follow the lead 
of some of the Linux groups and have -runtime and -devel versions of 
packages,  OR  we what woudlbe smarter, woudl be to have several "sub 
manifests" to allow unpacking in different environments.



A simple example:   libxml2

This package installs include files and libraries and dicumentation etc.

yet if I build an appliance , I want it to only install a singe file.

/usr/local/lib/libxml2.so.2


The presence of this file will satisfy any runtime dependencies of 
packages that require it.


Unfortunately there is no way to install just this file, and still 
report that we have the package loaded, so


pkg will always try to reinstall it leading to a huge mess.

My current scheme is to unpack all packages into a larger staging 
area, and *manually* (scripted) copy out only the files I need, and 
then copy the pkg database, so that when run on the running appliance, 
pkg THINKS all the packages are loaded on the appliance, even though 
only the runtime files are installed. This is what we in the industry 
call "a hack"  :-) It is also not robust in the face of changing pkg 
versions.


It would be a lot better it pkg knew it was being asked to install 
only the runtime set, and coudl accurately  store this information in 
its database, allowing it to satisfy the needs of other packages that 
need that dependnency only in a runtime manner.


Is any of this possible at the moment?

suggestions from the ports/pkg community are appreciated..

Julian


___
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: harder and harder to avoid pkg

[Julian Elischer]

On 11/10/2016 12:51 PM, olli hauer wrote:

On 2016-10-11 20:59, Julian Elischer wrote:

As the number of dependencies between packages get ever higher, it becomes more and more 
difficult to compile packages and the dependence on binary precompiled packages is 
increased. However binary packages are unsuitable for some situations.  We really need to 
follow the lead of some of the Linux groups and have -runtime and -devel versions of 
packages,  OR  we what woudlbe smarter, woudl be to have several "sub 
manifests" to allow unpacking in different environments.


A simple example:   libxml2

This package installs include files and libraries and dicumentation etc.

yet if I build an appliance , I want it to only install a singe file.

/usr/local/lib/libxml2.so.2


The presence of this file will satisfy any runtime dependencies of packages 
that require it.

Unfortunately there is no way to install just this file, and still report that 
we have the package loaded, so

pkg will always try to reinstall it leading to a huge mess.

My current scheme is to unpack all packages into a larger staging area, and *manually* 
(scripted) copy out only the files I need, and then copy the pkg database, so that when 
run on the running appliance, pkg THINKS all the packages are loaded on the appliance, 
even though only the runtime files are installed. This is what we in the industry call 
"a hack"  :-) It is also not robust in the face of changing pkg versions.

It would be a lot better it pkg knew it was being asked to install only the 
runtime set, and coudl accurately  store this information in its database, 
allowing it to satisfy the needs of other packages that need that dependnency 
only in a runtime manner.

Is any of this possible at the moment?

suggestions from the ports/pkg community are appreciated..

Julian


Hm, do you build your own packages or using pre build packages?

yes we build them, for simple ones, but
for java or some of the more complicated ones, we PREFER to use the 
precompiled ones.
This is because (as mentioned in the email) the explosion of 
dependencies means that compiling our own is getting less and less 
feasible.

Especially if we have our own changes in some of the prerequisite modules.



just for interest and testing the following hack will do what you want, but 
results in duplicate category and some other minor errors (needs some better 
hacking ...)

$ cat libxml2/Makefile.local
post-stage:
@${RM} -rf ${STAGEDIR}${PREFIX}/include/libxml2
@${ECHO} 'lib/libxml2.so.2' > ${TMPPLIST}
That's true and in fact we have the technology in house to do that, 
but it's a very messy solution, and not terribly reproducible, 
requiring lots of human intervention in the long run.  it also 
produces accounting issues as now we need to have two versions of each 
pkg (with the same name),
One that we need to install into the build environment (with include 
files, etc) and one for installing into the target appliance image.





A better method would be to use a tool like portsharker together with 
ports-mgmt/poudriere(-devel)
A really short hint how to use it can be found here:
  https://github.com/freebsd/poudriere/blob/release-3.1/doc/portshaker.wiki

Anyway, until now should be possible with some effort, perhaps it is possible 
to get for such purpose an additional make target that is running after stage 
but before the package is created.




___
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: harder and harder to avoid pkg

[Julian Elischer]

On 11/10/2016 5:34 PM, Alfred Perlstein wrote:

Make a slave port with an abbreviated pkg-plist bruh. ;)
yeeess, good idea, but that won't satisfy the dependency requirements 
of other packages... you need to fool other packages, and that's the 
hard part. The way to do this is I think for pkg to have the ability 
to have two manifests.


We are doing similar to what Roger says, but it's just so much work...



-Alfred


On 10/11/16 11:59 AM, Julian Elischer wrote:
As the number of dependencies between packages get ever higher, it 
becomes more and more difficult to compile packages and the 
dependence on binary precompiled packages is increased. However 
binary packages are unsuitable for some situations.  We really need 
to follow the lead of some of the Linux groups and have -runtime 
and -devel versions of packages, OR  we what woudlbe smarter, woudl 
be to have several "sub manifests" to allow unpacking in different 
environments.



A simple example:   libxml2

This package installs include files and libraries and dicumentation 
etc.


yet if I build an appliance , I want it to only install a singe file.

/usr/local/lib/libxml2.so.2


The presence of this file will satisfy any runtime dependencies of 
packages that require it.


Unfortunately there is no way to install just this file, and still 
report that we have the package loaded, so


pkg will always try to reinstall it leading to a huge mess.

My current scheme is to unpack all packages into a larger staging 
area, and *manually* (scripted) copy out only the files I need, and 
then copy the pkg database, so that when run on the running 
appliance, pkg THINKS all the packages are loaded on the appliance, 
even though only the runtime files are installed. This is what we 
in the industry call "a hack"  :-) It is also not robust in the 
face of changing pkg versions.


It would be a lot better it pkg knew it was being asked to install 
only the runtime set, and coudl accurately  store this information 
in its database, allowing it to satisfy the needs of other packages 
that need that dependnency only in a runtime manner.


Is any of this possible at the moment?

suggestions from the ports/pkg community are appreciated..

Julian


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

Re: harder and harder to avoid pkg

[Julian Elischer]

On 12/10/2016 1:13 AM, Vlad K. wrote:

On 2016-10-11 20:59, Julian Elischer wrote:

are unsuitable for some situations.  We really need to follow the lead
of some of the Linux groups and have -runtime and -devel versions of
packages,  OR  we what woudlbe smarter, woudl be to have several "sub
manifests" to allow unpacking in different environments.


Is as adding a "HEADERS" or whatever you want to call the option to 
ports, a solution? Like we have DOC for documentation, an option 
that could be PLIST sub'd and switch installation of 
include/whatever.h and friends?
what I really need is a RUNTIME option that produces a package with 
only those files needed to satisfy external run-time depdencies, or 
the actual demands of the user itself. However since those files are 
all in the regular package, It'd make sense to just apply the regular 
package to some filter that only allowed those files to be extracted. 
For many packages the whole output would be a single file. (This would 
be true for any package that produces a single .so such as libjpeg or 
libtiff etc. ). The pkg database would however report the package 
being installed, thus satisfying other packages that look in the 
database for dependencies.  Giving it another name (e.g. 
foo-runtime-3.2 ) would make the dependencies not match it.







Yes it's a ton of work requiring to go through many ports, but 
looking at a random sample, it could be scripted and manual labor 
reduced.


To me something like this sounds very much consistent what other 
options, like DOC and MANPAGES, already do. And with individual 
options you don't presume package roles like -dev or -runtime or 
-whatever and you can combine as you want them.


And eventually if, hopefully when, package variants are implemented, 
maybe the official pkg repo can include all the variants, but then, 
I think, that's only a matter of logistics and resource available to 
build all those combinations and store them. But the basic mechanism 
for it should be a port option, imho.






___
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: harder and harder to avoid pkg

[Julian Elischer]

On 13/10/2016 5:42 AM, David Demelier wrote:

2016-10-12 10:04 GMT+02:00 Andrea Venturoli :

On 10/12/16 09:24, Matthieu Volat wrote:


And GNU/Linuxes can be a PITA when you have to track -dev(el) packages
(which sometimes really requires -bin, -app or whatever), or worst, describe
to people how they are supposed to build your software with weird subpackage
names.

I really like that ports provides the software project as intended by
upstream (modulo options).


Just a "me too" here!

Could not agree more.

Please forget that idea.

I just hate having to install libfoo, libfoo-dev, libfoo-dbg,
libfoo-doc, libfoo-whatever each time I need to develop on Linux.
Please do not transform FreeBSD as a Linux distribution :)

I love the way FreeBSD and some very sparse Linux distributions
provide the packages exactly how it would be installed by hand (=
vanilla).

FreeBSD offers some options and very few changes for better
integration but packages are provided vanilla. You want a package? You
install /packagename/ nothing more, nothing less. I really would like
to see simple vanilla packages for the next 10 years.

The FreeBSD ports is already extremely complicated, do not make it
even harder :(

The suggestion is not for ports, but for packages..
a single package could be unpacked in 'runtime only' or 'everything' mode.
basically one package, two manifests.  So no "foo-devel" or "foo-runtime"
just 'foo'



Regards,



___
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: harder and harder to avoid pkg

[Julian Elischer]

On 13/10/2016 10:33 AM, RW via freebsd-ports wrote:

On Tue, 11 Oct 2016 11:59:47 -0700
Julian Elischer wrote:


As the number of dependencies between packages get ever higher, it
becomes more and more difficult to compile packages and the
dependence on binary precompiled packages is increased. However
binary packages are unsuitable for some situations.  We really need
to follow the lead of some of the Linux groups and have -runtime and
-devel versions of packages,  OR  we what woudlbe smarter, woudl be
to have several "sub manifests" to allow unpacking in different
environments.


A simple example:   libxml2

This package installs include files and libraries and dicumentation
etc.

yet if I build an appliance , I want it to only install a singe file.

/usr/local/lib/libxml2.so.2

What practical problem does installing the include files and man pages
cause you?

I have to delete them from the appliance I'm building up.
So I need to get the manifest, remove the files I want from it, and 
delete every other file mentioned.


This is an appliance class machine. It has 2G of storage and that has 
to  include 2 copies for the OS so we can ping-pong for upgrades.



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

Re: gcc5 dependency challenges

[Julian Elischer]

On 14/10/2016 12:48 AM, Dewayne Geraghty wrote:

After some rudimentary performance testing I note that we get up around 3%
improvement in application performance when we use gcc5 for our package
builds.

However building ports with gcc results in gcc5 being a dependency.
Examining ldd, we find that rarely does anything require gcc5's shared libs
for their execution.  Even simple things like ftp/wget and devel/ccache
depend on gcc5 for building but NOT runtime.  As we aren't allowed to
install compilers onto production systems, what is the best course of
action to address?
(We could just install gcc5 and then remove it but then of course, the base
pkg wants to remove everything (600+ packages) that depends on gcc5!)

So the question is - how should we build our packages or install them so
that gcc5 is not (unnecessarily) installed?
This is a topic I have been discussing in this list over the last few 
weeks.
My understanding is that the compiler should not be a dependency for 
the package.


I have been suggesting that packages should be installable in two 
manners,  runtime or developement.
In runtie mode they would only unpack the binary results (and not the 
man pages or .a files or .h files)
and would only give library dependancies as depends.. In devel mode 
they woudl be sort of like now..



We've added to our /etc/make.conf
USE_GCC=  5
but I wonder if there's something like a build_depends mechanism?


Background:
Our FreeBSD 10.3 Stable uses pkg 1.8.3; whereas ports uses 1.8.7_3, minor
point.

Why gcc5? Well most ports use clang 3.4.1 to compile, some ports do use gcc
4.8.5; and if we move to FreeBSD11 then we also need to add llvm3.6 into
the build/migrating equation.  So to aid our migration effort we "think"
choosing gcc5 now is a good idea; particularly as /usr/ports/base/gcc uses
gcc 5.4.0 (rather than /usr/ports/lang/gcc which is 4.8.5)

All production systems use local package repositories (as heimdal is widely
used as are  non-default options).

Kind regards, Dewayne
___
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"

Re: harder and harder to avoid pkg

[Julian Elischer]

On 14/10/2016 4:27 AM, Matthieu Volat wrote:

On Fri, 14 Oct 2016 13:05:35 +0200
David Demelier  wrote:


2016-10-14 11:22 GMT+02:00 Baptiste Daroussin :

It is imho doable in both sides.

We could imagine tagging the plist/manifest so pkg can allow a user to install
only the things tagged as runtime for exemple which would do the job. for what
Julian is asking for beside adding lots of complexity pkg(8) and adding a
nightmare in the solver.

That would "please" the people that want "hey keep the giant flat package as it
is better for dev given I don't have to install the -devel version something"
and the people wanting fine grain selection if they need to.

But on the ports side that would be a nightmare having to tag all the plist (and
this cannot be automated because there are to many corner cases.

IIRC, rpm builders have script that automate this by finding files in
standard directories. Probably by checking in the stage a include/
directory and "tag" it as the development part.

Unless things changed very recently, not quite : you have to pile subpackage 
declaration and files sections according to the subpackages you create. The 
only things it has to ease the burden is you can use wildcard patterns to 
select files.


It will be the most smart way of doing this but still require some
addition to pkg. Probably like:

- pkg install mylib
- pkg install -t dev mylib
- pkg install -t runtime mylib
- pkg install -t dev,runtime,doc mylib

Just thinking ;)

More options, then more options to `pkg info` to get what was installed when something 
cannot build, then more pkg search options and manpage because more "-t" flags 
will be added and we don't know what's needed?


I'm glad people are at least thinking about it...

I don't think there are so many categories.  Are we installing onto a 
development machine, user machine, or an appliance? appliances don't 
need man pages. User machines need man pages for programs but not for 
libraries and developer machines.. everything..



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

private ports and pkgs versioning

[Julian Elischer]

Is there a standard way of naming a pkg that is locally compiled 
(maybe with a different set of options, or a local patch) so that it 
doesn't get confused with generic ports that are from freeBSD.org?


I want to use mostly standard pkgs but need to compile a few myself 
(this can't be an uncommon requirement).


How can I name my variant pkgs so the the pkg program (and ports) can 
still know that it is a satisfactory supplier of prerequisite components?


e.g.  if a pkg wants a specific rev of libxml2 how much does it use of 
the name libxml2-2.9.2_2 ?


Can (should) I add stuff after the '_'?  If I do will it still 
recognise my pkg file and if I do are there any rules regarding *WHAT* 
I can put there.


lastly is there somewhere I should be looking to read all this 
information rather than pestering the mailing list?


What I'd like to have is my own depot with something like:

===

libsmi-0.4.8_1.txz
libxcb-1.11.1.txz
libxml2-2.9.2_2-mumble.3.txz
lsof-4.88,8.txz
lsof-4.90.b,8.txz
m4-1.4.17_1,1.txz

===

where 'mumble.3' is a locally defined addition, but all the rest of 
the pkgs are straight from pkg.freebsd.org, (or at least compile in 
default form).


This "kind-of" works, but the rules of play are not defined anyhere I 
have read, so I don't know if it's going to suddenly fail one day.


Also it's be really nice if there were a variable I could set to 
"mumble.3" so that I don't have to do a manual rename, because between 
the time that the package is made and it is renamed there is a 
'misnamed' package sitting around acting as a potential source of 
confusion.


thanks,


Julian





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

really to pkg people

[Julian Elischer]

Is it at all possible for the ports/pkg people to QUIT DELETING STUFF!

It's most disconcerting when a quarterly collection of packages 
disappears and one has nowhere to get new packages that match all the 
ones out in the field. Since 10.3 is the latest 10 release and the 
release_3 collection is gettign soemwhat dated, it would be nice to 
have a stable quarterly set to refer to  that is not going to 
disappear in 3 months!


machines get shipped.. they go to customers. They are frozen in time.  
If debugging requires a new package, we have to have copied the entire 
quarterly set  "just in case". because the originals from freebsd have 
done a runner.  Are they archived somewhere?


yours


grumpy

p.s get off my lawn!

___
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: jython on FreeBSD 10 ports

[Julian Elischer]

On 3/12/2016 12:46 AM, Ruslan Makhmatkhanov wrote:

Julian Elischer wrote on 12/02/2016 17:19:

On 29/11/2016 1:57 PM, Ruslan Makhmatkhanov wrote:

Julian Elischer wrote on 11/29/2016 08:34:
Ruslan, I'm just wondering if the 404 is supposed to be removed 
from the

email address




I have it running but it insists on installing the entire JDK. Is it
possible to use just the JRE?


If I understand correctly there is no way to depend just upon JRE in 
Mk/bsd.java.mk, so this is the reason why it depends upon the whole 
JDK. But you may try something like
that would seem odd  there must be hundreds of packages that just want 
the runtime.

Maybe someone in ports@ can comment?  (CC'd)


-USE_JAVA=   yes
-JAVA_VERSION=   1.7+
+JAVA=/usr/local/openjdk7/bin/java
+BUILD_DEPENDS+=java/openjdk7-jre
+RUN_DEPENDS+=java/openjdk7-jre

to build a local package that only depends upon JRE 1.7.


also the 1.7+ in effect means 1.8.   even if 1.7 is installed the pkg 
will force an install of 1.8.





Afaik the address is correct. I was able to google some of his 
mailing

list submissions from that email:
https://marc.info/?a=137339713800014&r=1&w=4

If there would be no response from Sergey till the end of the week,
I'll try to answer myself. Maybe jython port just needs some
actualization in respect of JRE version. As far I understand, the
problem you are expecting was introduced into ports infrastructure at
some point after the jython update.

Btw, has you tried to just build the port itself with enforcing
version 1.7? I'm not yet sure, but it looks like java 1.8 is now
default java version in ports tree. This is why pkg insisting on
installation of 1.8




On 29/11/2016 1:24 AM, Julian Elischer wrote:

On 23/11/2016 5:32 AM, Ruslan Makhmatkhanov wrote:

Hi Julian,

Julian Elischer wrote on 11/22/2016 09:46:

Firstly thanks for having done hte last jython update
  you say in the notes that it should work with the 1.7 java. 
but hte

pkg wants the openJDK8.0 as a dependency.

so a couple of questions:
 Firstly do we need the entire JDK? is the JRE not enough?
Secondly, how do we make it use the openJDK7-JRE that is already
installed on the machine?

we don't have the room for the full JDK, and certainly not for 
two

whole
copies (7 and 8).

thanks

Julian jul...@freebsd.org  with $JOB hat on.


while I committed the update, the patch wasn't mine: I just 
checked
the build etc. I added original submitter to cc in hope he'll 
be able

to clarify the situation.

Sergey, would you elaborate on JDK/JRE and 1.7/1.8 questions? 
Thank

you!


Hi Sergey,

thanks..
I guess my question is: will pkg complain if 7 is installed and not
8?  (or do I need both?) and do I need to do anything special to 
make

it work with 7?

Julian





___
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: FOCAL

[Julian Elischer]

Some friends and I have a pdp8 here.. we replaed the bulbs with leds 
about 25 years ago, but
last time we tried it, it still ran.. model number escapes me.. its 
currently at a friend's place.
It was the controller for a DISTEC (?)  display, the predecessor for 
the wonderful gt40 and used as a frontend for teh pdp10 (KA10, serial # 6)



On 3/12/2016 12:07 PM, Larry Rosenman wrote:

On 2016-12-02 22:02, Kevin Oberman wrote:

On Fri, Dec 2, 2016 at 5:59 PM, Greg 'groggy' Lehey 
wrote:


On Saturday,  3 December 2016 at 11:40:36 +1100, Dave Horsfall wrote:
> Be there an implementation of FOCAL?  I have a hankering to get 
back to

my
> early programming days :-)

Heh.  I have a paper tape from my first year at uni somewhere in the
mess on my desk.  It's been there for at least 10 years, and it's
short enough for it to be practical to read it in by eye, but I
haven't got more than a third of the way through.  It's in FOCAL-69,
and does some world-shattering calculations like mean and standard
deviation.  It would be fun to run it again--once.

Greg



Wow! Have not thought of FOCAL in years. Used to write a bit both 
when in
college and, using FOCAL-11, in my early years at LLNL. Unlike 
FOCAL on a
PDP-8, FOCAL-11 ran on top of DOS-11. (No relation to Microsoft 
DOS.) The

PDP-8L was the only solid state computer in the lab. All of the others
still had vacuum tubes and drum memory, though the Univac Athena 
had both

drum and core.

In college I wrote a simple craps game and, it it caught you trying to
cheat, it zeroed your account and gave you the finger on the 
ASR-33. My
computer logic prof (and department head) saw that trivial ASCII 
art and
chewed me a new one for putting code to generate that gesture on a 
school

computer. That was about 45 years ago. Memories!


Brings back memories for me as well from high school.  Back in 1972.

PDP-8/L in the Levittown (NY) School District.



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

what is the purpose of the quarterly ports branches?

[Julian Elischer]

they are effectively useless because the results are not archived, and 
the quarterly pkg branch actually changes day by day, so making two 
machines from the same quarterly branch can give you different 
machines (making it useless for paying work)


not to mention that if you use the quarterly pkg branch you run he 
risk of it completely changing if you happen to be unlucky enough to 
be doing it across a quarterly boundary. then you end up with a 
completely messed up system. (from experience).



SO a couple of things.. new quarterly pkg releases should have 
different names and be pointed to by a symlink or something. Other 
wise you can't avoid the smashed system problem. (half the pkgs from 
one quarter and the other half from the previous one, which you can't 
find any more.



But the big question still remains..

What do you think you are solving and why are they changing? shouldn't 
a snapshot be stable?




___
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: The ports collection has some serious issues

[Julian Elischer]

On 8/12/2016 6:05 PM, Vlad K. wrote:

On 2016-12-08 06:16, Daniil Berendeev wrote:


I mean, they are the FIRST landing point of a change. And the only 
QA we ask for that change is a confirmation that poudriere and 
portlint have been run, the rest is at liberty of committers how far 
they'll go with own testing before they commit. For many, only 
builds against -CURRENT or latest -RELEASE are done because it's 
very time consuming to test against all supported FreeBSD versions, 
and not just versions but various permutations like different 
pythons etc... When it comes to some defaults like OpenSSL (or any 
kind of dependency on it), all of those tests are required.


The problem is, FreeBSD doesn't have a STABLE repo that would 
receive gradual updates from HEAD as they prove themselves stable. 
QUARTERLY != STABLE, it's just a snapshot of whatever state HEAD is 
in, with a loose promise the ports in it will receive "security and 
bugfixes only" but that's a separate set of issues.


The problem I get hit by is that the quarterly packages are deleted 
immediately on the creation of the next quarterly set.
so by definition, when you've spent 3 months getting the quarterly pkg 
collection reliable and correct, it gets deleted.
I think there should be two quarterly pkg collections available at any 
time:
The one we are stabilising, and the previous stable set (called beta 
and stable or something like that).

the stable one is basically read-only except for security fixes.
As it is when you get the new quarterly packages, they are straight 
off head, because the branch was just made.




There are some solutions and we don't have to NIH or reinvent the 
wheel. Just looking at what other open source projects do with, say, 
GitHub and continuous integration testing, every pull request gets 
an automated test. Why don't we do that? Is it difficult to 
implement it?


I am also convinced that such testing can be automated and a true 
"STABLE" repo can be made instead of manual QUARTERLY that breaks 
promises.
I think this is heading in the right direction..  at the end of the 3 
month stabilisation it goes to stable.



8) ports with vulnerabilities.
They exist in the tree and on build attempt they shout that they won't
build without DISABLE_VULNERABILITIES=yes. The catch is that there is
always a bunch of ports with vulnerabilities. So if you are doing a


That's just a nature of it, and the consequence of VuXML being a 
separate port that gets often updated first, as it's better to 
announce the vuln before it was fixed. And fixing is bound to 
maintainer timeouts, poor issue tracking via Bugzilla, etc...




I hope that my mail will produce a productive discussion that will 
lead

to some good decisions for fixing these problems.


Probably not. I've already posted about issues with head/quarterly, 
hoping for a discussion, never happened. Others have complained 
about the same problem, but no constructive discussion ensued. Is my 
frustration coming through, yet? :)


yeah it's not working well at the moment.  The procedures could do 
with some tuning for sure.










___
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: The ports collection has some serious issues

[Julian Elischer]

On 8/12/2016 8:28 PM, Baptiste Daroussin wrote:

On Thu, Dec 08, 2016 at 05:16:24AM +, Daniil Berendeev wrote:

Hello guys!

First of all, it's not a hate mail, I appreciate all the work done on
the system and I enjoy using FreeBSD every day.

But after some recent experience I'd like to point out some problems
that make using the ports collection uncomfortable and painful.

Some overview before we start:
* Why I use ports over pkg?
Because, generally, packages are built with poor default options, for
example moc isn't able to play .alac/.mod and that's frustrating.

Lot's of work has been done over the last years improve the default options for
general pupose cases. Have you open an issue about that one?


but we still need a way to specify "minimum options please" to stop 
dependency fanout from going too wild.
I touched a port last week that required about 200 others, a lot of 
which would not have been needed for what I would call a common 
functionality configuration.





Have you considered using things like poudriere that would allow you to build
your own repository with your own set of packages and options.

You will benefit:
- ability to use pkg for your upgrades
- ability to use customize your packages
- safe rebuild process (in case of broken ABI)

Best regards,
Bapt
I'm actually slowly moving to this if I can work out how to specify my 
own chroot image, and a few other things I need to tweak. (my own sets 
of patches to add).



___
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: what is the purpose of the quarterly ports branches?

[Julian Elischer]

On 7/12/2016 10:12 PM, George Mitchell wrote:

On 12/06/16 21:59, Jason Unovitch wrote:

On Mon, Dec 05, 2016 at 10:48:20PM +, Ben Woods wrote:

On Tue., 6 Dec. 2016 at 4:44 am, Julian Elischer  wrote:


they are effectively useless because the results are not archived, and
the quarterly pkg branch actually changes day by day, so making two
machines from the same quarterly branch can give you different
machines (making it useless for paying work)

not to mention that if you use the quarterly pkg branch you run he
risk of it completely changing if you happen to be unlucky enough to
be doing it across a quarterly boundary. then you end up with a
completely messed up system. (from experience).


If you are handling the burden of support for a customer then perhaps
Poudriere and building internally is the best option. Then if you want
to stay on an older quarterly because none of what you deploy to
customers is impacted by security issues you can roll them at your own
pace.


But the big question still remains..

What do you think you are solving and why are they changing? shouldn't
a snapshot be stable?


Think releng compared to stable in the src repo rather than
release/stable.  They change in the same fashion to get SA (in the form
of VuXML) and errata worthy fixes.
[...]

If only!  At least the current base releng does not arbitrarily
disappear every three months. -- George


so I think there is a simple partial fix to stop SOME of the worst 
problems.
Name the package quarterly sets the same as the ports branches, Use a 
symlink to point to them.
and keep them around for 6 months, so there are always 2, one of which 
has pretty much stopped changing.
(and provide an EASY way to snarf the lot. currently it's done via an 
index.html or something that screws it up.








___
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: (In)Stability of the Quarterly Branch

[Julian Elischer]

Please add my voice to this..
It's not really that much that needs to be done.
lets just call it 'learning from experience'

Also, the quarterly PACKAGES should be kept around a bit longer too.
and the pkg archives need to be in a layout that the system installer 
can be pointed at them in 4 years time when you want to rebuild a 
legacy machine.


On 16/11/2016 8:17 PM, Vlad K. wrote:
The quarterly branch (Q) is intended to provide a set of "stable" 
packages that in the lifetime of such a branch, receive only bug and 
security fixes. That is the theory and intent behind the branch. In 
practice, however:


1. The Q branch is cut off at predetermined dates (ie. not when it's 
stable and ready), and it is cut off from HEAD, thus including the 
state of ports at that moment. This breaks the promise of stability 
and guarantees that every 3 months there will be uncertainty as to 
whether the fresh new versions are working or not. There is no such 
thing as a "Pre-Quarterly repo" which would receive all updates for 
the NEXT Q branch-off, and which would freeze and stabilize for some 
time before branch-off. And even if it did, 3 months would be too 
short.


It is effectively not much different from tracking HEAD and doing 
updates only every three months, with the added benefit that SOME 
security updates will come down sooner. But:


2. Unfortunately not all "security or bug-only fixes" are MFH'd, and 
as a bugzilla triager I've had the opportunity to observe this in 
practice. It can be as simple as accepting a minor upstream version 
bump, or as complex as requiring cherry-picking and backporting code 
if upstream mixes security, bug fixes with new features. It is 
none-the-less a manual work requiring ports-secteam to review and 
accept the patches. It is not clear who is supposed to do 
cherry-picked backporting if the patches to HEAD cannot be MFH'd as 
they are. It is also additional burden to the ports-secTEAM which at 
the moment is, effectively, one person.


In out current build environment at $JOB we check out every package we 
need in ports at it's own SVN revision.
Usually that is defined to be a default, but sometimes in order to get 
a fully working set we need to slide a port or two forwards or 
backwards  a bit. (and hope it doesn't hit a ports API change). (this 
means we really need to stay on head though)




As it is obvious that the promise of a stable repo in its current 
form requires manpower and manual work which we do not have, my 
proposal is to abandon the promise of "security/bugfix" only changes 
and adopt the approach not unlike Gentoo's, in which a "STABLE" 
repository receives ALL the updates from HEAD, but only after 
certain criteria has been met, like minimal age of changes, no open 
issues, a certain battery of regression/integration/unit tests is 
performed, etc...


The key, I believe, is in automation which we can achieve with this, 
and with that offer at least SOME level of stability without broken 
promises. The key to this automation is no manual review, which can 
only be achieved if we accept ALL changes, but stabilized to certain 
degree.


The idea of a "stable" repository is a valiant one, we definitely 
need it if we want to increase the usage of FreeBSD in production as 
more than just a base OS that does routing and ZFS storage -- namely 
production use of stable ports. And IMHO we only need to balance 
between how stable we can provide/guarantee it and what resources 
and manpower we have available to do so.



What are the community's thoughts on this?




___
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: (In)Stability of the Quarterly Branch

[Julian Elischer]

On 15/12/2016 9:43 PM, Torsten Zuehlsdorff wrote:

On 15.12.2016 14:16, David Demelier wrote:

[...]


What I want: a ports tree that matches the FreeBSD version like
OpenBSD. You have FreeBSD 11.0? You get a ports tree for that version
specifically. No major update, no breaking changes. Just bug fixes.
That will also simplify a lot FreeBSD ports by not having thousands of
conditional checking the FreeBSD version.


That what i really, really, really NOT want. I have regular problems 
with our admins because of that. You want a specific version of an 
software? No problem: just install a specific version of your 
operation system. Need two of them, but they are not in this bundle? 
To bad, than you need a new server. This is an daily-base scenario i 
really don't want to port to FreeBSD.


  the problem I have is that on the one machine the UI people want 
node-x.y and the VM configuration people need boto-a.b, but boto-a.b 
and node-x.y don't exist at the same time in the ports tree and there 
is no snapshot of packages when they exist..  it's like saying "that 
dinosaur and this dinosaur never met because one was Jurassic and the 
other was Triassic. To make it worse the packages taken from different 
times insist on installing different versions of some other package, 
so I can't just take packages from different times (because they 
OVERSPECIFY their dependencies,, it may work but I don't get the 
chance because the install balks).


So I'm left with compiling..
If I use poudriere I need otmake a synthetic tree with different 
revisions, bus the API for the ports tree moves so fast that often you 
cant; even do that because one requires mk/uses/python.mumble and 
theother wants some incompatible other  change.


So the problems I see are
1/ over specification of dependencies, leading to artificial 
requirements to upgrade things.
2/ leaf dependencies having too many options, leading to exponential 
fan-out of dependencies.
3/ API changes too frequent, and not enough care taken thinking about 
what happens if one needs to get a back-rev version of something.
4/ ports not always noticing when a dependency package is installed 
and compiling the dependency anyhow.


here's an example;
'tracker' is a simple package.
but requires the following makefiles to be in sync API wise.

# Build dependencies
TRACKER_DEP_PORTS:= devel/desktop-file-utils devel/gettext-tools 
devel/gmake graphics/gtk-update-icon-cache
TRACKER_DEP_PORTS+= print/indexinfo textproc/intltool devel/gettext 
lang/perl5.20 lang/python27 graphics/poppler
TRACKER_DEP_PORTS+= devel/gobject-introspection textproc/libxslt 
devel/pkgconf multimedia/gstreamer1-plugins
TRACKER_DEP_PORTS+= devel/xdg-utils converters/o3read 
graphics/poppler-utils www/w3m
TRACKER_DEP_PORTS+= devel/desktop-file-utils 
graphics/gtk-update-icon-cache multimedia/gstreamer1-plugin
TRACKER_DEP_PORTS+= devel/dbus-glib mail/gmime26 sysutils/hal 
textproc/raptor sysutils/e2fsprogs
TRACKER_DEP_PORTS+= misc/e2fsprogs-libuuid devel/icu 
multimedia/libmediaart devel/librest
TRACKER_DEP_PORTS+= multimedia/totem-pl-parser audio/flac 
audio/libvorbis textproc/libcue
TRACKER_DEP_PORTS+= audio/libogg audio/taglib graphics/poppler-glib 
graphics/libgxps
TRACKER_DEP_PORTS+= devel/libgsf textproc/exempi textproc/wv 
graphics/libexif
TRACKER_DEP_PORTS+= graphics/giflib graphics/png graphics/tiff 
devel/gettext-runtime
TRACKER_DEP_PORTS+= accessibility/atk graphics/gdk-pixbuf2 
devel/glib20 x11-toolkits/gtk30
TRACKER_DEP_PORTS+= textproc/libxml2 x11-toolkits/pango 
archivers/libarchive databases/sqlite3
TRACKER_DEP_PORTS+= devel/libffi devel/pcre converters/libiconv 
graphics/cairo devel/bison
TRACKER_DEP_PORTS+= lang/python2 x11/libXext x11/libXrender x11/libX11 
x11/libXinerama
TRACKER_DEP_PORTS+= x11/libXi x11/libXrandr x11/libXcursor 
x11/libXfixes x11/libXdamage
TRACKER_DEP_PORTS+= x11/libXcomposite x11-toolkits/libXt 
graphics/jasper graphics/jbigkit graphics/jpeg-turbo
TRACKER_DEP_PORTS+= x11-fonts/fontconfig x11-fonts/libXft 
print/freetype2 print/harfbuzz x11-fonts/xorg-fonts-truetype
TRACKER_DEP_PORTS+= x11-fonts/encodings misc/shared-mime-info 
misc/hicolor-icon-theme textproc/p5-XML-Parser security/libgcrypt
TRACKER_DEP_PORTS+= multimedia/gstreamer1 misc/iso-codes devel/orc 
devel/dbus multimedia/v4l_compat
TRACKER_DEP_PORTS+= sysutils/policykit devel/libvolume_id 
sysutils/consolekit misc/pciids sysutils/gnome_subr
TRACKER_DEP_PORTS+= sysutils/dmidecode ftp/curl textproc/gtk-doc 
lang/vala security/ca_root_nss
TRACKER_DEP_PORTS+= devel/libsoup-gnome multimedia/libquvi09 
textproc/expat2 devel/cmake graphics/lcms2
TRACKER_DEP_PORTS+= graphics/openjpeg15 graphics/poppler-data 
graphics/libwmf accessibility/at-spi2-atk graphics/libepoxy
TRACKER_DEP_PORTS+= graphics/colord print/cups 
x11-themes/adwaita-icon-theme textproc/xmlto x11/xprop

TRACKER_DEP_PORTS+= x11/xset devel/boehm-gc
TRACKER_DEP_PORTS+= misc/dejagnu x11/xcb-util-renderutil 
graphics/libGL graphics/libEGL x11/glproto

Re: what is the purpose of the quarterly ports branches?

[Julian Elischer]

On 16/12/2016 4:01 PM, Dave Cottlehuber wrote:


On Tue, 13 Dec 2016, at 23:14, Grzegorz Junka wrote:

I heard that ports' SVN is mirrored to Github. Isn't it enough to just
create a branch or tag for each quarterly release? Even if quarterly
packages are deleted, re-building packages from such branch/tag should
allow to recreate those packages as required since the same code would
give the same packages?

These branches already exist BTW:

https://github.com/freebsd/freebsd-ports/tree/branches/2016Q3


the trouble is that the packages are deleted as soon as they are stable.



A+
Dave
___
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"

Re: The ports collection has some serious issues

[Julian Elischer]

On 18/12/2016 10:16 AM, John Marino wrote:

On 12/17/2016 19:35, Peter Jeremy wrote:

$ cd /usr/ports/ports-mgmt/synth/ && make
[ about an hour of grinding away elided ]
===>   ini_file_manager-03_2 depends on file: 
/usr/local/gcc6-aux/bin/ada - not found
===>  gcc6-aux-20160822 is only for amd64 i386, while you are 
running armv6.


Overall, a total failure.

OTOH, portmaster installs in a minute or so and runs perfectly 
well.  I fail
to see why you are so insistant on replacing it with something that 
doesn't

work at all.



Real smooth there, Slick.

It's been mentioned several times in this thread alone that Ada is 
only available for i386 and amd64.  I think you already knew that 
and thus this is a pure troll.


Use poudriere for non-x86 platforms.  armv6 packages are built with 
poudriere + QEMU, but I suspect you already knew this as well.


or use  portmaster, which works really well



John

---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus

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

Re: New 2017Q1 branch

[Julian Elischer]

On 2/01/2017 10:39 PM, Mathieu Arnold wrote:

can we ask the server admins to not delete the 1016Q4 pkg collection 
immediately?

it is stable and works while 2017Q1 is not yet in that state.


Hi,

The 2017Q1 branch has been created. It means that the next update on the
quarterly packages will be on the 2017Q1 branch.

A lot of things happened in the last three months:
- pkg 1.9.4
- New USES: lxqt, varnish
- Default version of GCC switched to 4.8 to 4.9
- Default version of Perl switched to 5.20 to 5.24
- Default version of Python 3 switched to 3.4 to 3.5
- New default version, Varnish at 4
- Firefox 50.1.0
- Firefox-esr 45.6.0
- Chromium 54.0.2840.100
- Ruby 2.1.0, 2.2.6 and 2.3.3
- gcc 4.9.4
- Gnome 3.18.0
- KDE 4.14.3
- Xorg 7.7

Next quarterly package builds will start in the next couple of days and
should be available on your closest mirrors few days later.

For those stat nerds out there, here's what happened during the last 3 months 
on head:
Number of commits: 6871
Number of committers:  161
Most active committers:
1049  sunpoet
  538  amdmi3
  404  jbeich
  305  swills
  200  antoine
  180  wen
  180  mat
  166  marino
  159  pi
  158  linimon
Diffstat: 18409 files changed, 419461 insertions(+), 234188 deletions(-)

and on the 2016Q4 branch:
Number of commits: 290
Number of committers:   51
Most active committers:
   67  jbeich
   31  feld
   12  junovitch
   11  antoine
   10  tijl
9  tz
9  riggs
8  koobs
8  ehaupt
8  cpm
Diffstat: 1090 files changed, 56829 insertions(+), 16225 deletions(-)

Regards,



___
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: FreeBSD Port: samba43-4.3.11_1 and 44 and 45

[Julian Elischer]

On 23/12/2016 3:10 AM, Jane wrote:'
what this requires is someone to track it..

how about *you* :-)
tracking a port and sending in Makefile updates is not too hard if you 
keep on top of it..




Hi,

  


Is it me or is it lately impossible to keep samba ports updated to their
latest security releases?

I hope you can find time to update the samba ports more regular.

  


Also when do we see samba 45 in ports?

Samba 4.5 = current stable release! I believe we are not updated proper yet.

This worries me a lot.

  



series

   git branch

status

started

maintenance

security

discontinued (EOL)


4.6 ( 
details)

   master

  
new upcoming release series



4.5 ( 
details)

  
v4-5-test

  
 current stable release series

2016-09-07



4.4 ( 
details)

  
v4-4-test

  
maintenance mode

2016-03-22

2016-09-07



4.3 ( 
details)

  
v4-3-test

  
 security fixes only

2015-09-08

2016-03-22

2016-09-07



  

  


I really do hope samba can get some more attention to keep our servers more
secured and patched.

  


Thanks for you hard work and hope for a reply of this message.

  


Signed by

Kater

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

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

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

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"