Re: Is pkg quarterly really needed?

[Torfinn Ingolfsen]

On Thu, Apr 20, 2017 at 1:30 AM, Julian Elischer  wrote:
> quarterly however is broken because the pkg mirors discard it all at the
> time of update.
>

Do they have to?
Why couldn't pkg mirrors keep say, the four latest quarterly sets all the time?
This would increase the usability of quarterly packages, at users own
risk, with only more diskspace as the expense for the FreeBSD projects
/ pkg mirrors.
No extra work involved once the setup is configured and tested.
___
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: Is pkg quarterly really needed?

[Mark Linimon]

I understand that having the quarterlies is not meeting your use case.
You've said that.  We get it.

So you want some kind of running -quarterly branch.

But where are the N hours of work per week to QA all the patches to
the -quarterly branch, or a -stable branch, or whatever people seem
to demand, to come from?

This is a serious -- if very irritated -- request.

We've moved from a "we don't have enough person-power to manage a ports
branch" to "we kinda have enough person-power to manage both head and a
kinda-branch."  OK.  That isn't meeting all the use cases.  Understood.

Are you going to volunteer for a team to run that QA?  Who else do you
think should be on it?  Clearly the current volunteers don't have the
bandwidth.  It is hard enough just to kep ports-head building.  Where
do the hours come from?

You're comparing your expectations of the output of what a professional
QA team would do, to the work that N volunteers do.  Obviously the results
are not comparable.  It's crazy to think that they would be.

Honestly without some volunteers to do the _hard_, _unrewarding_, work
to QA the ports tree, this is all either a) just talk, or b) people
wanting volunteers to provide professional-level support, for free.

tl;dr: provide some resources, or don't.  I am getting to the point where
I don't care either way.  All I see is the people who are doing actual work
get poked in the eye.

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

Re: Is pkg quarterly really needed?

[Mark Linimon]

On Wed, Apr 19, 2017 at 04:37:05PM -0400, scratch65...@att.net wrote:
> (Right now, it's quite hard to resist the paranoid suspicion that
> maybe this crazy, anti-real-user behavior is a subtle way to kill
> freebsd altogether by driving away the non-hobbyists.)

That's one explanation.

The other, possible, explanation, is that the efforts of a group of
volunteers isn't adequate enough for every use case -- including your own.

But, of course, feel free to cast aspersions wherever and whenever.  We're
just machines, we have no feelings whatsoever.

Now if no one minds, I'm going to go back to contemplate the existential
question of "why do I even bother trying to fix things".

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

Re: Re: net-mgmt/prometheus update to 1.6.0, comitter requested

[ler]

  
  
Can you fill in the unknown stuff in the version package or should I just go 
ahead and do it?
  

  
  
  

  
  
  
  
  
>   
> On Apr 19, 2017 at 10:22 PM,wrote:
>   
>   
> Thanks Larry,  
>
>   
> I have updated the patch on the bug, because the upstream project has just 
> released a minor version/bug fix release. New patch updates us to 1.6.1.
>   
>
>   
> Thanks,
>   
> -Jev
>   
>   
>   
>   
> On Tue, Apr 18, 2017 at 1:22 PM Larry Rosenman    wrote:
>   
> > On 4/18/17, 2:41 PM, "Jev Björsell"   > behalf of  j...@ecadlabs.com>  wrote:
> >   
> >  Hi All,
> >   
> >  Could I get a committer to apply my latest update patch for net-mg
> >  mt/prometheus?
> >   
> >  Patch is available here:
> >   https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=218737
> >   
> >  Thanks so much,
> >  -Jev
> >   
> >  Waiting for my mentor to approve.
> >   
> >   
> >   
> 
 
___
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: net-mgmt/prometheus update to 1.6.0, comitter requested

[Jev Björsell]

Thanks Larry,

I have updated the patch on the bug, because the upstream project has just
released a minor version/bug fix release. New patch updates us to 1.6.1.

Thanks,
-Jev

On Tue, Apr 18, 2017 at 1:22 PM Larry Rosenman  wrote:

> On 4/18/17, 2:41 PM, "Jev Björsell"  behalf of j...@ecadlabs.com> wrote:
>
> Hi All,
>
> Could I get a committer to apply my latest update patch for net-mg
> mt/prometheus?
>
> Patch is available here:
> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=218737
>
> Thanks so much,
> -Jev
>
> Waiting for my mentor to approve.
>
>
>
>
___
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: Is pkg quarterly really needed?

[Julian Elischer]

On 20/4/17 6:29 am, Dewayne Geraghty wrote:

Scratch65535, I think your best solution is to use latest and upgrade when
you need to.  Unlike Freddie's comment re only desktop users using latest.
I ONLY upgrade my local svn of ports when there's a vulnerability or
significant (for users) functional improvement of a port.

It is a labour intensive exercise, monitoring CVE's for all
externally-facing applications.

Its a nice idea having a snapshot of ports, from the perspective of
consistency, but that model doesnt suite our risk appetite on multiple
levels; and in our view back-porting fixes to a quarterly snapshot - a good
idea from a security perspective it is a really bad idea from a
consistency/administrative/audit perspective.


We mirror the ports tree (and base) into p4 and also as svn, and use 
this to check out the head branch to whatever release we need.
Our scripts are capable of checking out a particular port at a 
(slightly) different rev to the default rev used for the rest, as 
sometimes we find we need a slightly newer rev of one port or 
another.  This sometimes doesn't work if there are framework changes 
that affect the port but mostly we find that it's ok if you just want 
to bump a port up a small amount to catch a bugfix,or take it back a 
bit to avoid a regression. We also do sparse checkouts of the ports 
tree ot save time, but that's another issue..


We therefore have all out pkgs (which we store with each release) at 
the same level of source tree so they all match.




How the ports infrastructure can meet many conflicting objectives is
something that we (the consumers of the ports service) must decide for our
circumstance.  The use-the-latest paradigm suits individuals that manage
their individual machine, but when you manage multiple clients' servers,
the requirements are different (try meeting a SAS70-II/SAE16-SOC2, ISO27001
SOA, NIST 800-53r5, etc)

On a non-audit level, Microsoft might hold to monthly updates/fixes ("patch
Tuesday") but bad guys don't.
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: Is pkg quarterly really needed?

[Julian Elischer]

On 20/4/17 4:37 am, scratch65...@att.net wrote:

[Default] On Tue, 18 Apr 2017 15:57:02 +0100, krad
 wrote:


quarterly does seem very cautious, maybe a monthly might be a good
alternative.

I have to STRONGLY disagree.

Right now, pkg isn't smart enough not to use version-skewed bits.
Which means that, for those of us trying to use freebsd and the
ports/pkgs as *tools* wherewith to do other work, we have to run
pkg upgrade -fy every cursëd quarter, not just when the minor
number changes.  With crappy access to the inet (something true
of most of the USA and Canada outside Really Big Cities) that
costs half a day or more.

If it were every month, I'd with unconsolable regret abandon
freebsd for linux (ptui!).  (Right now, it's quite hard to resist
the paranoid suspicion that maybe this crazy, anti-real-user
behavior is a subtle way to kill freebsd altogether by driving
away the non-hobbyists.)

I have to agree with you. It is most frustrating
The only way to sanity is to totally ignore the quarterly releases, 
and if you have changes, use poudriere to build what you need yourself 
once a month or whatever, or if you don't have changes, take snapshots 
of the entire pkg tree every now and then. (we do both for different 
reasons).. My snapshot is kept out on an amazon machine we have, as 
it's purpose is to "freeze in time" the head branch of the pkg tree. 
This means we can come back in a week and get  a new pkg that we now 
need and know it is compatible with the other ones we have. I don't 
have to download the entire collection through my crappy link. just 
the ones I need.
The trouble is that the people doing ports and pkg management really 
don't really have production systems in mind and rarely really 
understand the requirements of such. (reproducible builds from 
scratch, and the ability to append to an existing  frozen-in-time 
release (for debug or bug-fix reasons). They ESPECIALLY don't 
understand the requirement to have access to old sets of packages, so 
you need to do it yourself.

___
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: poudriere: crossbuilding for arm64 fails: pkg-static: No package files have been found

[Jan Beich]

"O. Hartmann"  writes:

> Trying to build a repository via poudriere fails on recent 12-CURRENT (FreeBSD
> 12.0-CURRENT #2 r317090: Tue Apr 18 15:32:23 CEST 2017 amd64) initially with
> failing to build ports-mgmt/pkg.
>
> poudriere's log reports:
>
> [...]
> configure: error: in `/wrkdirs/usr/ports/ports-mgmt/pkg/work/pkg-1.10.1':
> configure: error: C compiler cannot create executables

Probably https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=217189
___
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: Is pkg quarterly really needed?

[Julian Elischer]

On 19/4/17 12:13 am, Freddie Cash wrote:

On Tue, Apr 18, 2017 at 7:57 AM, krad  wrote:


quarterly does seem very cautious, maybe a monthly might be a good
alternative. I can understand people being hesitant about latest though. I
guess these are not the people who ask though. Maybe the real answer though
is to have a specific repo for that port for the bleeding edge people  much
like launchpad on ubuntu. It might get complicated though for big
dependency trees though.


​latest/ is good for desktop users who only care about running the very
latest versions of everything.

quarterly/ is good for server users who want to make sure that installing a
new piece of software won't require an upgrade of all the currently
installed software (repo hasn't changed since the last install).  And for
desktop users who prefer to use their computers for doing work instead of
spending all their time chasing after the "latest" flashy bling bling.  :)

quarterly/ also gets security fixes back-ported into it (on a
per-maintainer basis so it's not 100% coverage yet), so you can stay secure
without chasing new software versions.

IOW, don't change the infrastructure, it's working nicely.  Just educate
the users.  :D


quarterly however is broken because the pkg mirors discard it all at the time 
of update.
meaning you can not come back later to get one you forgot..
and sometimes you can get half way through, and everything breaks becuase you 
happened to select  teh wrong date to do your work.





On 18 April 2017 at 14:54, qjail1  wrote:


I maintain a port and I have users complaining that the pkg system takes
many months before the updated version of my port shows up in the pkg
system.

My response is I tell them to change a line in their

/etc/pkg/FreeBSD.conf

file
from url: "pkg+http://pkg.Freebsd.org/${ABI}/quarterly;,
to   url: "pkg+http://pkg.Freebsd.org/${ABI}/latest;,

The old pkg system never had this quarterly update cycle and I see no
reason to have it now when its so easy to over ride the default.

Why not just change the default to "latest" and save on all the overhead
of the quarterly cycle?
___
freebsd-questi...@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to "freebsd-questions-unsubscribe
@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: Is pkg quarterly really needed?

[Dewayne Geraghty]

Scratch65535, I think your best solution is to use latest and upgrade when
you need to.  Unlike Freddie's comment re only desktop users using latest.
I ONLY upgrade my local svn of ports when there's a vulnerability or
significant (for users) functional improvement of a port.

It is a labour intensive exercise, monitoring CVE's for all
externally-facing applications.

Its a nice idea having a snapshot of ports, from the perspective of
consistency, but that model doesnt suite our risk appetite on multiple
levels; and in our view back-porting fixes to a quarterly snapshot - a good
idea from a security perspective it is a really bad idea from a
consistency/administrative/audit perspective.

How the ports infrastructure can meet many conflicting objectives is
something that we (the consumers of the ports service) must decide for our
circumstance.  The use-the-latest paradigm suits individuals that manage
their individual machine, but when you manage multiple clients' servers,
the requirements are different (try meeting a SAS70-II/SAE16-SOC2, ISO27001
SOA, NIST 800-53r5, etc)

On a non-audit level, Microsoft might hold to monthly updates/fixes ("patch
Tuesday") but bad guys don't.
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"

Re: Is pkg quarterly really needed?

[scratch65535]

[Default] On Tue, 18 Apr 2017 15:57:02 +0100, krad
 wrote:

>quarterly does seem very cautious, maybe a monthly might be a good
>alternative. 

I have to STRONGLY disagree.  

Right now, pkg isn't smart enough not to use version-skewed bits.
Which means that, for those of us trying to use freebsd and the
ports/pkgs as *tools* wherewith to do other work, we have to run
pkg upgrade -fy every cursëd quarter, not just when the minor
number changes.  With crappy access to the inet (something true
of most of the USA and Canada outside Really Big Cities) that
costs half a day or more.  

If it were every month, I'd with unconsolable regret abandon
freebsd for linux (ptui!).  (Right now, it's quite hard to resist
the paranoid suspicion that maybe this crazy, anti-real-user
behavior is a subtle way to kill freebsd altogether by driving
away the non-hobbyists.)
___
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: Writing a port that needs to download a large number of files

[Dmytro Bilokha]

On 19.04.2017 19:27, Xavi Garcia wrote:

Hi all,

We are writing a port for a Java software that downloads a large number 
of
jar files (around 200) with Gradle (https://gradle.org/), that is 
similar

to other package managers like Pip or Ruby Gems but for Java projects.

What would be the best practice in this scenario? I am aware that we 
can
only download files in the fetch phase but I am not sure if my solution 
is

clean enough.

We will be deploying this port in our servers via Portshaker and 
Poudriere

but we would also like to commit it to the ports tree.


In short, I am using the 'pre-fetch' phase together with FETCH_DEPENDS  
to

drop the Gradle wrapper in ${DISTDIR}/${PORTNAME} and then I use the
'dependencies' task to download all the dependencies.

The 'do-build' stage will run again the Gradle wrapper to build the
software, but using the offline mode.

You can find attached the Makefile.

Kind regards,

Xavier Garcia


Hi!
If you need examples of the "best practice",
probably, you can take a look at already exsisting
ports of Java software.

For example, I've checked the Glassfish port and
it was made with different approach:
1. During fetch phase distribution zip-file with
already compiled Java classes is downloaded.
2. Then it is unzipped to some directory, like
/usr/local/glassfish.
3. Some scripts put, package registered, etc.

So here there is no building of Java app from sources,
mostly fetching already built, some tweaking and putting
to the right place.
I saw similar procedure for some another ports
of Java software.

I am not sure, but it seems because of such reasons:
1. With Java you won't gain a lot with building application
from sources. If OS has JVM you can just run already
compiled -- it should work.
2. For port its better to have as least dependencies,
as possible. So, making your port dependent on
Gradle (which fast evolving itself) and/or another
Java build tooling can make port fragile and not
very stable.
3. Building the big Java project from sources could be
time and traffic consuming task. Usualy users
don't like this.

---
Best regards,
Dmytro Bilokha
___
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: databases/mariadb101-client upgraded in wrong order, resulted in missing files

[Bernard Spil]

On 2017-04-18 21:45, Miroslav Lachman wrote:

Miroslav Lachman wrote on 2017/03/31 15:31:

I don't know if it was "pkg" fault or mariadb101-server and
mariadb101-client conflict.

I did standard "pkg upgrade" and at the end I have half files of
mariadb101-client missing:

# pkg check -Ba
Checking all packages: ...
pkg: fstat() failed for(/usr/local/bin/msql2mysql): No such file or
directory
pkg: fstat() failed for(/usr/local/bin/mysql_find_rows): No such file 
or

directory
pkg: fstat() failed for(/usr/local/bin/mysqlaccess): No such file or
directory
pkg: fstat() failed for(/usr/local/include/mysql/big_endian.h): No 
such

file or directory
pkg: fstat() failed 
for(/usr/local/include/mysql/byte_order_generic.h):

No such file or directory
pkg: fstat() failed
for(/usr/local/include/mysql/byte_order_generic_x86.h): No such file 
or

directory
pkg: fstat() failed
for(/usr/local/include/mysql/byte_order_generic_x86_64.h): No such 
file

or directory
pkg: fstat() failed for(/usr/local/include/mysql/client_plugin.h): No
such file or directory
pkg: fstat() failed for(/usr/local/include/mysql/decimal.h): No such
file or directory
pkg: fstat() failed for(/usr/local/include/mysql/errmsg.h): No such 
file

or directory
pkg: fstat() failed for(/usr/local/include/mysql/handler_ername.h): No
such file or directory
pkg: fstat() failed for(/usr/local/include/mysql/handler_state.h): No
such file or directory
pkg: fstat() failed for(/usr/local/include/mysql/keycache.h): No such
file or directory
pkg: fstat() failed for(/usr/local/include/mysql/little_endian.h): No
such file or directory
pkg: fstat() failed for(/usr/local/include/mysql/m_ctype.h): No such
file or directory
pkg: fstat() failed for(/usr/local/include/mysql/ma_dyncol.h): No such
file or directory
pkg: fstat() failed for(/usr/local/include/mysql/my_alloc.h): No such
file or directory
pkg: fstat() failed for(/usr/local/include/mysql/my_attribute.h): No
such file or directory
pkg: fstat() failed for(/usr/local/include/mysql/my_byteorder.h): No
such file or directory
pkg: fstat() failed for(/usr/local/include/mysql/my_compiler.h): No 
such

file or directory
pkg: fstat() failed for(/usr/local/include/mysql/my_dbug.h): No such
file or directory
pkg: fstat() failed for(/usr/local/include/mysql/my_dir.h): No such 
file

or directory
pkg: fstat() failed for(/usr/local/include/mysql/my_getopt.h): No such
file or directory
pkg: fstat() failed for(/usr/local/include/mysql/my_list.h): No such
file or directory
pkg: fstat() failed for(/usr/local/include/mysql/my_net.h): No such 
file

or directory
pkg: fstat() failed for(/usr/local/include/mysql/my_pthread.h): No 
such

file or directory
pkg: fstat() failed for(/usr/local/include/mysql/my_xml.h): No such 
file

or directory
pkg: fstat() failed for(/usr/local/include/mysql/mysql_com.h): No such
file or directory
pkg: fstat() failed for(/usr/local/include/mysql/mysql_com_server.h): 
No

such file or directory
pkg: fstat() failed for(/usr/local/include/mysql/mysql_embed.h): No 
such

file or directory
pkg: fstat() failed for(/usr/local/include/mysql/mysql_time.h): No 
such

file or directory
pkg: fstat() failed for(/usr/local/include/mysql/mysqld_ername.h): No
such file or directory
pkg: fstat() failed for(/usr/local/include/mysql/mysqld_error.h): No
such file or directory
pkg: fstat() failed for(/usr/local/include/mysql/plugin_audit.h): No
such file or directory
pkg: fstat() failed 
for(/usr/local/include/mysql/plugin_auth_common.h):

No such file or directory
pkg: fstat() failed for(/usr/local/include/mysql/plugin_encryption.h):
No such file or directory
pkg: fstat() failed for(/usr/local/include/mysql/plugin_ftparser.h): 
No

such file or directory
pkg: fstat() failed
for(/usr/local/include/mysql/plugin_password_validation.h): No such 
file

or directory
pkg: fstat() failed for(/usr/local/include/mysql/psi/mysql_idle.h): No
such file or directory
pkg: fstat() failed for(/usr/local/include/mysql/psi/mysql_socket.h): 
No

such file or directory
pkg: fstat() failed for(/usr/local/include/mysql/psi/mysql_stage.h): 
No

such file or directory
pkg: fstat() failed 
for(/usr/local/include/mysql/psi/mysql_statement.h):

No such file or directory
pkg: fstat() failed for(/usr/local/include/mysql/psi/mysql_table.h): 
No

such file or directory
pkg: fstat() failed for(/usr/local/include/mysql/psi/mysql_thread.h): 
No

such file or directory
pkg: fstat() failed 
for(/usr/local/include/mysql/service_debug_sync.h):

No such file or directory
pkg: fstat() failed 
for(/usr/local/include/mysql/service_encryption.h):

No such file or directory
pkg: fstat() failed
for(/usr/local/include/mysql/service_encryption_scheme.h): No such 
file

or directory
pkg: fstat() failed
for(/usr/local/include/mysql/service_kill_statement.h): No such file 
or

directory
pkg: fstat() failed for(/usr/local/include/mysql/service_md5.h): No 
such

file or directory
pkg: fstat() failed 
for(/usr/local/include/mysql/service_my_snprintf.h):

No such file or directory

Re: iocage port

[Sebastian Schwarz]

On 2017-04-19, Vick Khera wrote:
> Can the original iocage port be restored?

I believe the old code has been forked and preserved under the
name iocell (https://github.com/bartekrutkowski/iocell) and is
available in pkg/ports under sysutils/iocell.
___
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"

Writing a port that needs to download a large number of files

[Xavi Garcia]

Hi all,

We are writing a port for a Java software that downloads a large number of
jar files (around 200) with Gradle (https://gradle.org/), that is similar
to other package managers like Pip or Ruby Gems but for Java projects.

What would be the best practice in this scenario? I am aware that we can
only download files in the fetch phase but I am not sure if my solution is
clean enough.

We will be deploying this port in our servers via Portshaker and Poudriere
but we would also like to commit it to the ports tree.


In short, I am using the 'pre-fetch' phase together with FETCH_DEPENDS  to
drop the Gradle wrapper in ${DISTDIR}/${PORTNAME} and then I use the
'dependencies' task to download all the dependencies.

The 'do-build' stage will run again the Gradle wrapper to build the
software, but using the offline mode.

You can find attached the Makefile.

Kind regards,

Xavier Garcia


Makefile
Description: Binary data
___
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: databases/mariadb101-client upgraded in wrong order, resulted in missing files

[scratch65535]

[Default] On Wed, 19 Apr 2017 14:52:56 +0200, Miroslav Lachman
<000.f...@quip.cz> wrote:

>scratch65...@att.net wrote on 2017/04/19 14:05:
>> [Default] On Wed, 19 Apr 2017 13:45:54 +0200, Miroslav Lachman
>> <000.f...@quip.cz> wrote:
>>
>>> scratch65...@att.net wrote on 2017/04/19 12:45:
 [Default] On Tue, 18 Apr 2017 21:45:47 +0200, Miroslav Lachman
 <000.f...@quip.cz> wrote:

> Miroslav Lachman wrote on 2017/03/31 15:31:
>> I don't know if it was "pkg" fault or mariadb101-server and
>> mariadb101-client conflict.
>>
>> I did standard "pkg upgrade" and at the end I have half files of
>> mariadb101-client missing:
>>
>> # pkg check -Ba
>> Checking all packages: ...
>> pkg: fstat() failed for(/usr/local/bin/msql2mysql): No such file or
>> directory
>> pkg: fstat() failed for(/usr/local/bin/mysql_find_rows): No such file or
>> directory
>>>
>>> [...]
>>>
>> pkg: fstat() failed for(/usr/local/man/man1/mysqlimport.1.gz): No such
>> file or directory
>> pkg: fstat() failed for(/usr/local/man/man1/mysqlshow.1.gz): No such
>> file or directory
>> pkg: fstat() failed for(/usr/local/man/man1/mysqlslap.1.gz): No such
>> file or directory
>> Checking all packages.. done
>>
>>
>> I think this is the root cause
>>
>> Checking integrity... done (2 conflicting)
>>  - mariadb101-server-10.1.22 conflicts with mariadb101-client-10.1.21
>> on /usr/local/share/mysql/maria_add_gis_sp.sql
>>>
>>> [...]
>>>

 I couldn't tell you whether you're the only one (probably not!)
 but I did a pkg upgrade on everything yesterday to recover from
 pkg's quarterly version skew, and mariadb *seems* to be all there
 and working correctly.  I haven't done any work yet this morning,
 so I'm keeping my fingers crossed.
>>>
>>> Do you use MariaDB version 10.1?
>>>
>>> MariaDB server is running without problems, only some "mysql client"
>>> libraries are missing, but if you use only PHP to connect to "mysql
>>> server" then you will not notice any problem, because PHP uses internal
>>> mysql client.
>>> So first time I overlooked this issue because MariaDB was running fine
>>> and webserver was on separate machine - PHP website was still running.
>>>
>>> Can you check this?
>>>
>>> ls -l /usr/local/lib/mysql/libmysqlclient_r.so.18
>>>
>>> I see "ls: /usr/local/lib/mysql/libmysqlclient_r.so.18: No such file or
>>> directory" on each upgraded server until i run *pkg upgrade -f
>>> mariadb101-client*
>>
>> Yes, I do have that file. Could the difference in our results be
>> due to my having used the -f switch, which forces upgrade of
>> EVERYthing instead of just those bits that pkg thinks want
>> upgrading?
>
>I tried it on next machine with pkg upgrade -f but the result is the same:
>
>pkg check -Ba
>
>Checking all packages
>(p5-DBD-mysql-4.042) 
>/usr/local/lib/perl5/site_perl/mach/5.24/auto/DBD/mysql/mysql.so - 
>required shared library libmysqlclient.so.18 not found
>Checking all packages
>(sphinxsearch-2.2.11_1) /usr/local/bin/indexer - required shared library 
>libmysqlclient.so.18 not found
>(sphinxsearch-2.2.11_1) /usr/local/bin/indextool - required shared 
>library libmysqlclient.so.18 not found
>(sphinxsearch-2.2.11_1) /usr/local/bin/spelldump - required shared 
>library libmysqlclient.so.18 not found
>(sphinxsearch-2.2.11_1) /usr/local/bin/wordbreaker - required shared 
>library libmysqlclient.so.18 not found
>(sphinxsearch-2.2.11_1) /usr/local/sbin/searchd - required shared 
>library libmysqlclient.so.18 not found

That's odd.  You're upping the 64-bit version, right?
___
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"

iocage port

[Vick Khera]

Can the original iocage port be restored? The replacements of py-iocage and
py3-iocage are not yet feature complete, and the original one still works
just great.

Thanks!
___
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: databases/mariadb101-client upgraded in wrong order, resulted in missing files

[Miroslav Lachman]

scratch65...@att.net wrote on 2017/04/19 14:05:

[Default] On Wed, 19 Apr 2017 13:45:54 +0200, Miroslav Lachman
<000.f...@quip.cz> wrote:


scratch65...@att.net wrote on 2017/04/19 12:45:

[Default] On Tue, 18 Apr 2017 21:45:47 +0200, Miroslav Lachman
<000.f...@quip.cz> wrote:


Miroslav Lachman wrote on 2017/03/31 15:31:

I don't know if it was "pkg" fault or mariadb101-server and
mariadb101-client conflict.

I did standard "pkg upgrade" and at the end I have half files of
mariadb101-client missing:

# pkg check -Ba
Checking all packages: ...
pkg: fstat() failed for(/usr/local/bin/msql2mysql): No such file or
directory
pkg: fstat() failed for(/usr/local/bin/mysql_find_rows): No such file or
directory


[...]


pkg: fstat() failed for(/usr/local/man/man1/mysqlimport.1.gz): No such
file or directory
pkg: fstat() failed for(/usr/local/man/man1/mysqlshow.1.gz): No such
file or directory
pkg: fstat() failed for(/usr/local/man/man1/mysqlslap.1.gz): No such
file or directory
Checking all packages.. done


I think this is the root cause

Checking integrity... done (2 conflicting)
 - mariadb101-server-10.1.22 conflicts with mariadb101-client-10.1.21
on /usr/local/share/mysql/maria_add_gis_sp.sql


[...]



I couldn't tell you whether you're the only one (probably not!)
but I did a pkg upgrade on everything yesterday to recover from
pkg's quarterly version skew, and mariadb *seems* to be all there
and working correctly.  I haven't done any work yet this morning,
so I'm keeping my fingers crossed.


Do you use MariaDB version 10.1?

MariaDB server is running without problems, only some "mysql client"
libraries are missing, but if you use only PHP to connect to "mysql
server" then you will not notice any problem, because PHP uses internal
mysql client.
So first time I overlooked this issue because MariaDB was running fine
and webserver was on separate machine - PHP website was still running.

Can you check this?

ls -l /usr/local/lib/mysql/libmysqlclient_r.so.18

I see "ls: /usr/local/lib/mysql/libmysqlclient_r.so.18: No such file or
directory" on each upgraded server until i run *pkg upgrade -f
mariadb101-client*


Yes, I do have that file. Could the difference in our results be
due to my having used the -f switch, which forces upgrade of
EVERYthing instead of just those bits that pkg thinks want
upgrading?


I tried it on next machine with pkg upgrade -f but the result is the same:

pkg check -Ba

Checking all packages
(p5-DBD-mysql-4.042) 
/usr/local/lib/perl5/site_perl/mach/5.24/auto/DBD/mysql/mysql.so - 
required shared library libmysqlclient.so.18 not found

Checking all packages
(sphinxsearch-2.2.11_1) /usr/local/bin/indexer - required shared library 
libmysqlclient.so.18 not found
(sphinxsearch-2.2.11_1) /usr/local/bin/indextool - required shared 
library libmysqlclient.so.18 not found
(sphinxsearch-2.2.11_1) /usr/local/bin/spelldump - required shared 
library libmysqlclient.so.18 not found
(sphinxsearch-2.2.11_1) /usr/local/bin/wordbreaker - required shared 
library libmysqlclient.so.18 not found
(sphinxsearch-2.2.11_1) /usr/local/sbin/searchd - required shared 
library libmysqlclient.so.18 not found


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"

poudriere: crossbuilding for arm64 fails: pkg-static: No package files have been found

[O. Hartmann]

Trying to build a repository via poudriere fails on recent 12-CURRENT (FreeBSD
12.0-CURRENT #2 r317090: Tue Apr 18 15:32:23 CEST 2017 amd64) initially with
failing to build ports-mgmt/pkg.

poudriere's log reports:

[...]
configure: error: in `/wrkdirs/usr/ports/ports-mgmt/pkg/work/pkg-1.10.1':
configure: error: C compiler cannot create executables

Well, I'm running "home brewn jail" which means that I successfully cross
compiled the 12-CURRENT sources as "TARGET=arm64" and having the obj tree
resulting from this build installed as jail. While installing the jail, I also
included the knob "-x" to "poudriere jail -c -a arm64.aarch64".

The port emulators/qemu-user-static is installed and the kernel module is
loaded successfully.

Ports tree and /usr/src are up to date as of today, additinally, I rebuilt the
qemu emulator and reloaded the kernel module to ensure nothing goes wrong there.

When starting the poudriere build, QEMU reports no issues, but after starting
to build ports-mgmt/pkg, I receive the error shown above.

By the way, CROSS_BINUTILS_PREFIX is not set anywhere in poudriere's config
files, nor do I set this variable in the environment as I think this is set via
the .mk scripts according to settings of "TARGET=" for ARM/ARM64 cross
compiling.

So, what is going wrong here?

Does anyone have an idea?

Thanks in advance,

Oliver

p.s.

Please CC 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"

Re: databases/mariadb101-client upgraded in wrong order, resulted in missing files

[scratch65535]

[Default] On Wed, 19 Apr 2017 13:45:54 +0200, Miroslav Lachman
<000.f...@quip.cz> wrote:

>scratch65...@att.net wrote on 2017/04/19 12:45:
>> [Default] On Tue, 18 Apr 2017 21:45:47 +0200, Miroslav Lachman
>> <000.f...@quip.cz> wrote:
>>
>>> Miroslav Lachman wrote on 2017/03/31 15:31:
 I don't know if it was "pkg" fault or mariadb101-server and
 mariadb101-client conflict.

 I did standard "pkg upgrade" and at the end I have half files of
 mariadb101-client missing:

 # pkg check -Ba
 Checking all packages: ...
 pkg: fstat() failed for(/usr/local/bin/msql2mysql): No such file or
 directory
 pkg: fstat() failed for(/usr/local/bin/mysql_find_rows): No such file or
 directory
>
>[...]
>
 pkg: fstat() failed for(/usr/local/man/man1/mysqlimport.1.gz): No such
 file or directory
 pkg: fstat() failed for(/usr/local/man/man1/mysqlshow.1.gz): No such
 file or directory
 pkg: fstat() failed for(/usr/local/man/man1/mysqlslap.1.gz): No such
 file or directory
 Checking all packages.. done


 I think this is the root cause

 Checking integrity... done (2 conflicting)
 - mariadb101-server-10.1.22 conflicts with mariadb101-client-10.1.21
 on /usr/local/share/mysql/maria_add_gis_sp.sql
>
>[...]
>
>>
>> I couldn't tell you whether you're the only one (probably not!)
>> but I did a pkg upgrade on everything yesterday to recover from
>> pkg's quarterly version skew, and mariadb *seems* to be all there
>> and working correctly.  I haven't done any work yet this morning,
>> so I'm keeping my fingers crossed.
>
>Do you use MariaDB version 10.1?
>
>MariaDB server is running without problems, only some "mysql client" 
>libraries are missing, but if you use only PHP to connect to "mysql 
>server" then you will not notice any problem, because PHP uses internal 
>mysql client.
>So first time I overlooked this issue because MariaDB was running fine 
>and webserver was on separate machine - PHP website was still running.
>
>Can you check this?
>
>ls -l /usr/local/lib/mysql/libmysqlclient_r.so.18
>
>I see "ls: /usr/local/lib/mysql/libmysqlclient_r.so.18: No such file or 
>directory" on each upgraded server until i run *pkg upgrade -f 
>mariadb101-client*

Yes, I do have that file. Could the difference in our results be
due to my having used the -f switch, which forces upgrade of
EVERYthing instead of just those bits that pkg thinks want
upgrading?
___
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: databases/mariadb101-client upgraded in wrong order, resulted in missing files

[Miroslav Lachman]

scratch65...@att.net wrote on 2017/04/19 12:45:

[Default] On Tue, 18 Apr 2017 21:45:47 +0200, Miroslav Lachman
<000.f...@quip.cz> wrote:


Miroslav Lachman wrote on 2017/03/31 15:31:

I don't know if it was "pkg" fault or mariadb101-server and
mariadb101-client conflict.

I did standard "pkg upgrade" and at the end I have half files of
mariadb101-client missing:

# pkg check -Ba
Checking all packages: ...
pkg: fstat() failed for(/usr/local/bin/msql2mysql): No such file or
directory
pkg: fstat() failed for(/usr/local/bin/mysql_find_rows): No such file or
directory


[...]


pkg: fstat() failed for(/usr/local/man/man1/mysqlimport.1.gz): No such
file or directory
pkg: fstat() failed for(/usr/local/man/man1/mysqlshow.1.gz): No such
file or directory
pkg: fstat() failed for(/usr/local/man/man1/mysqlslap.1.gz): No such
file or directory
Checking all packages.. done


I think this is the root cause

Checking integrity... done (2 conflicting)
- mariadb101-server-10.1.22 conflicts with mariadb101-client-10.1.21
on /usr/local/share/mysql/maria_add_gis_sp.sql


[...]



I couldn't tell you whether you're the only one (probably not!)
but I did a pkg upgrade on everything yesterday to recover from
pkg's quarterly version skew, and mariadb *seems* to be all there
and working correctly.  I haven't done any work yet this morning,
so I'm keeping my fingers crossed.


Do you use MariaDB version 10.1?

MariaDB server is running without problems, only some "mysql client" 
libraries are missing, but if you use only PHP to connect to "mysql 
server" then you will not notice any problem, because PHP uses internal 
mysql client.
So first time I overlooked this issue because MariaDB was running fine 
and webserver was on separate machine - PHP website was still running.


Can you check this?

ls -l /usr/local/lib/mysql/libmysqlclient_r.so.18

I see "ls: /usr/local/lib/mysql/libmysqlclient_r.so.18: No such file or 
directory" on each upgraded server until i run *pkg upgrade -f 
mariadb101-client*


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: Any hope of compiling firefox port on ARM?

[Dimitry Andric]

On 19 Apr 2017, at 00:17, bob prohaska  wrote:
> 
> On Tue, Apr 18, 2017 at 09:43:23PM +0200, Jan Beich wrote:
>> 
>> See bug 211069 which was duped against bug 203989 that triggered a
>> different assertion. The above error did show up on armv6 buildbot[1]
>> but nowadays is blocked by other ports.
>> 
> What is meant by the term "blocked by other ports"? The error still
> comes up with firefox and -current as of yesterday.

How is that even possible?  I committed the fix on Oct 12, 2016:

  https://svnweb.freebsd.org/changeset/ports/423893

then merged it to the 2016Q4 quarterly branch on Oct 14, 2016:

  https://svnweb.freebsd.org/changeset/ports/423974

Maybe you are seeing a different problem altogether?  Or your ports tree
has no been updated?

-Dimitry



signature.asc
Description: Message signed with OpenPGP

Re: databases/mariadb101-client upgraded in wrong order, resulted in missing files

[scratch65535]

[Default] On Tue, 18 Apr 2017 21:45:47 +0200, Miroslav Lachman
<000.f...@quip.cz> wrote:

>Miroslav Lachman wrote on 2017/03/31 15:31:
>> I don't know if it was "pkg" fault or mariadb101-server and
>> mariadb101-client conflict.
>>
>> I did standard "pkg upgrade" and at the end I have half files of
>> mariadb101-client missing:
>>
>> # pkg check -Ba
>> Checking all packages: ...
>> pkg: fstat() failed for(/usr/local/bin/msql2mysql): No such file or
>> directory
>> pkg: fstat() failed for(/usr/local/bin/mysql_find_rows): No such file or
>> directory
>> pkg: fstat() failed for(/usr/local/bin/mysqlaccess): No such file or
>> directory
>> pkg: fstat() failed for(/usr/local/include/mysql/big_endian.h): No such
>> file or directory
>> pkg: fstat() failed for(/usr/local/include/mysql/byte_order_generic.h):
>> No such file or directory
>> pkg: fstat() failed
>> for(/usr/local/include/mysql/byte_order_generic_x86.h): No such file or
>> directory
>> pkg: fstat() failed
>> for(/usr/local/include/mysql/byte_order_generic_x86_64.h): No such file
>> or directory
>> pkg: fstat() failed for(/usr/local/include/mysql/client_plugin.h): No
>> such file or directory
>> pkg: fstat() failed for(/usr/local/include/mysql/decimal.h): No such
>> file or directory
>> pkg: fstat() failed for(/usr/local/include/mysql/errmsg.h): No such file
>> or directory
>> pkg: fstat() failed for(/usr/local/include/mysql/handler_ername.h): No
>> such file or directory
>> pkg: fstat() failed for(/usr/local/include/mysql/handler_state.h): No
>> such file or directory
>> pkg: fstat() failed for(/usr/local/include/mysql/keycache.h): No such
>> file or directory
>> pkg: fstat() failed for(/usr/local/include/mysql/little_endian.h): No
>> such file or directory
>> pkg: fstat() failed for(/usr/local/include/mysql/m_ctype.h): No such
>> file or directory
>> pkg: fstat() failed for(/usr/local/include/mysql/ma_dyncol.h): No such
>> file or directory
>> pkg: fstat() failed for(/usr/local/include/mysql/my_alloc.h): No such
>> file or directory
>> pkg: fstat() failed for(/usr/local/include/mysql/my_attribute.h): No
>> such file or directory
>> pkg: fstat() failed for(/usr/local/include/mysql/my_byteorder.h): No
>> such file or directory
>> pkg: fstat() failed for(/usr/local/include/mysql/my_compiler.h): No such
>> file or directory
>> pkg: fstat() failed for(/usr/local/include/mysql/my_dbug.h): No such
>> file or directory
>> pkg: fstat() failed for(/usr/local/include/mysql/my_dir.h): No such file
>> or directory
>> pkg: fstat() failed for(/usr/local/include/mysql/my_getopt.h): No such
>> file or directory
>> pkg: fstat() failed for(/usr/local/include/mysql/my_list.h): No such
>> file or directory
>> pkg: fstat() failed for(/usr/local/include/mysql/my_net.h): No such file
>> or directory
>> pkg: fstat() failed for(/usr/local/include/mysql/my_pthread.h): No such
>> file or directory
>> pkg: fstat() failed for(/usr/local/include/mysql/my_xml.h): No such file
>> or directory
>> pkg: fstat() failed for(/usr/local/include/mysql/mysql_com.h): No such
>> file or directory
>> pkg: fstat() failed for(/usr/local/include/mysql/mysql_com_server.h): No
>> such file or directory
>> pkg: fstat() failed for(/usr/local/include/mysql/mysql_embed.h): No such
>> file or directory
>> pkg: fstat() failed for(/usr/local/include/mysql/mysql_time.h): No such
>> file or directory
>> pkg: fstat() failed for(/usr/local/include/mysql/mysqld_ername.h): No
>> such file or directory
>> pkg: fstat() failed for(/usr/local/include/mysql/mysqld_error.h): No
>> such file or directory
>> pkg: fstat() failed for(/usr/local/include/mysql/plugin_audit.h): No
>> such file or directory
>> pkg: fstat() failed for(/usr/local/include/mysql/plugin_auth_common.h):
>> No such file or directory
>> pkg: fstat() failed for(/usr/local/include/mysql/plugin_encryption.h):
>> No such file or directory
>> pkg: fstat() failed for(/usr/local/include/mysql/plugin_ftparser.h): No
>> such file or directory
>> pkg: fstat() failed
>> for(/usr/local/include/mysql/plugin_password_validation.h): No such file
>> or directory
>> pkg: fstat() failed for(/usr/local/include/mysql/psi/mysql_idle.h): No
>> such file or directory
>> pkg: fstat() failed for(/usr/local/include/mysql/psi/mysql_socket.h): No
>> such file or directory
>> pkg: fstat() failed for(/usr/local/include/mysql/psi/mysql_stage.h): No
>> such file or directory
>> pkg: fstat() failed for(/usr/local/include/mysql/psi/mysql_statement.h):
>> No such file or directory
>> pkg: fstat() failed for(/usr/local/include/mysql/psi/mysql_table.h): No
>> such file or directory
>> pkg: fstat() failed for(/usr/local/include/mysql/psi/mysql_thread.h): No
>> such file or directory
>> pkg: fstat() failed for(/usr/local/include/mysql/service_debug_sync.h):
>> No such file or directory
>> pkg: fstat() failed for(/usr/local/include/mysql/service_encryption.h):
>> No such file or directory
>> pkg: fstat() failed
>> for(/usr/local/include/mysql/service_encryption_scheme.h): No such file
>> 

Pkg or dbus should create /etc/machine-id when not found

[scratch65535]

Not only that, but pkg should not delete things until AFTER it
successfully replaces them!

I finally broke down and did a pkg upgrade yesterday, which cost
me the whole afternoon.  I had to do it because pkg wasn't smart
enough not to use the current quarter's bits to install a package
on a machine that was using the original 10.3 RELEASE bits.  (If
that's to be considered normal behavior, then not only are we all
forced to update every time the minor version changes, we have to
disruptively update every quarter unless we forego installing
anything new.  I realise that, when you're up to your arse in
alligators draining the swamp isn't uppermost in your mind, but
there really are people for whom freebsd is a *tool*, not a hobby
or a way to commit suicide by exhaustion.) 

This disruption involved pkg deleting Firefox (why?) because I
was trying to install VLC (which turned out to be broken).  When
I tried to restore Firefox, I got bitten by quarterly version
skew.

So this morning, despite the sacrifice of the half-day yesterday,
X failed to start because dbus couldn't find /etc/machine-id, a
file it never wanted to find before now.  Since the fix seems
easy enough:  call dbus-uuidgen --ensure=/etc/machine-id, it's
hard to know why pkg or dbus doesn't generate it when it can't
find it.  I filed a bug.
___
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: Packaging Go Libs

[Derek (freebsd lists)]

Agree with previous sentiments, and:

On 17-04-18 10:59 PM, Christopher Hall wrote:

You should use built in golang vendoring to ensure these
dependencies, as their is no guarantee that someone won't update the
library port and your app would break, so doing that is very fragile


Currently the GH_TUPLE method is working as it specifies exact
dependency versions or specific git hashes.

but we made several attempts at submodules in vendor dir
but have had problems building and go get -u breaks things.

I am wondering if you might suggest a tool or do any other programs in
ports use such a dependency tool.  Last time I searched ports tree I
only saw GH_TUPLE used so I just followed that method.



From my point of view, the only thing that should be in the 
vendor directory on checkout is the version-lock file.  This is 
different for different tools.


I have been using gb, as it makes the most sense to me:

https://getgb.io/

sysutils/hfm uses this

godep is also popular, from what I understand:

https://godoc.org/github.com/tools/godep

Vendoring changed internally in go with a GO15VENDOREXPERIMENT 
build environment variable (and then default in 1.6), although I 
have not yet played with it:


https://docs.google.com/document/d/1Bz5-UB7g2uPBdOx-rw5t9MxJwkfpx90cqG9AFL0JAYo/edit

... from the docs, it sounds like it would be compatible with gb 
from a build standpoint - and you simply could use gb to track, 
fetch and lock versions in development - the same thing the ports 
GH_TUPLE covers.  What you do when it's not hosted at github, 
well


Derek

___
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 you maintain which are out of date

[portscout]

Dear port maintainer,

The portscout new distfile checker has detected that one or more of your
ports appears to be out of date. Please take the opportunity to check
each of the ports listed below, and if possible and appropriate,
submit/commit an update. If any ports have already been updated, you can
safely ignore the entry.

You will not be e-mailed again for any of the port/version combinations
below.

Full details can be found at the following URL:
http://portscout.freebsd.org/po...@freebsd.org.html


Port| Current version | New version
+-+
devel/log4cpp   | 1.1.1   | 1.1.2
+-+


If any of the above results are invalid, please check the following page
for details on how to improve portscout's detection and selection of
distfiles on a per-port basis:

http://portscout.freebsd.org/info/portscout-portconfig.txt

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