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: 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: Maintaining mono/.net

[Russell Haley]

On Tue, Jun 28, 2016 at 2:43 AM, Baptiste Daroussin  wrote:
> On Mon, Jun 27, 2016 at 11:06:02AM -0700, Russell Haley wrote:
>> Hello Ports Team,
>>
>> A couple of us on the freebsd-mono@ mailing list are having a
>> discussion on how best to maintain the mono ports/.net ports. One of
>> the things that has come up is maintaining the patches for "all this
>> stuff". The current paradigm in FreeBSD as I understand it is to use
>> the files directory and apply the patches to the port via svn/ports
>> tree. However, with the ubiquity of GitHub in opensource, it now seems
>> to be feesable to simply create a Github accound to maintain a bunch
>> of forked repositories (which is essentially a patched git
>> repository!). This makes it easier to create and apply patches and
>> gives us the natural path to push things back upstream. In the end, we
>> would just pull from the FreeBSD specific repository, which is no
>> different than, say, pulling from the mono project directly.
>>
>> This email is a request for response from anyone on the ports team (or
>> FreeBSD general) to give some input as to the acceptability of this
>> solution, as well as any "gotchas" we haven't thought of yet. Thanks
>> in advance!
>>
> There are absolutely nothing against this. Actually some ports were already
> doing that before the github era :D
>
> The only difficulty the history told us is : when active people get less 
> active
> for various reasons you need to make sure enough people continues to get 
> access
> to the said repo.
>
> Tracking upstream updates because more complicated for people not in the team
> (we already saw in the past ports stucked for more than 5/6 years actions 
> being
> taken (maintainer of the forked becoming mostly MIA)
>
> It also depends how many patches you end up with, I haven't checked the
> mono/.net ports but if that is just a bunch of small patches then the overhead
> is not worth the pain, if there are lots of patches then sure maintaining your
> repo is simpler.
>
> Depending on how active you (the team) are and how close to the upstream you 
> are
> one can also see those repositories as "temporary" until all the amount of
> patches are upstreamed and when done the ports can switch back to the official
> distfiles (this is always a goal for ports upstreaming all our patches so we 
> can
> remain as close as possible from the vanilla sources)
>
> That said I do applause the effort. As a conclusion do what ever you think is
> the easiest mechanism for you as long as things like monodevelop and friends 
> can
> be pushed in a working state again.
>
> Best regards,
> Bapt

Thanks for the input everyone. I think the overhead of keeping
volatile patches in a globally accessible area is worth while. One of
the things I struggled with historically is how to share my local
changes that I couldn't commit to the svn tree.

I have created an open source organization called FreeBSD-DotNet in
Github. I have differentiated from the Mono moniker because the
merging of the frameworks is inevitable with the purchase of Xamarian.

I went a little crazy and forked a whole bunch of stuff, which I now
think is a bad idea. The only thing that currently requires
customization would be the ports tree itself (MonoDevelop doesn't
build yet, but I haven't needed to change any code). However, I think
we can put a bunch of how-to and wiki stuff in there for the
development efforts.

SO, with that: Anyone wishing to join the FreeBSD-DotNet organization
can go to https://github.com/FreeBSD-DotNet and send a request. I'll
try to flesh out an outstanding items list that can be ratified
sometime in the next couple of weeks.

Thanks,

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

[Chris H]

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.
> 
> 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: Is there still broken lang/ruby23 ?

[Steve Wills]

Yes, I haven't looked at it yet, but if you want to take a look, I'd
welcome patches.

Steve

On 06/28/16 06:12 PM, KIRIYAMA Kazuhiko wrote:
> Hi,
> 
> Is there still broken lang/ruby23[1]. Or can build in latest
> 11.0-* ? 
> 
> [1] http://permalink.gmane.org/gmane.os.freebsd.devel.pkg-fallout/294364
> 
> ---
> KIRIYAMA Kazuhiko
> ___
> 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: Unexpected output from "pkg updating -d 20160626"

[David Wolfskill]

On Tue, Jun 28, 2016 at 09:19:04PM -0400, Jason Unovitch wrote:
> ...
> > The "pkg updating" command I issued was: pkg updating -d 20160626
> 
> Hello David,
> I did replicate this and it seemed related to a handful of recent
> UDPATING entries that were made without a trailing colon after the date.
> I normalized all the entries for consistency and am seeing `pkg updating
> -d 20160626` return the expected output for me. Please see if that
> resolved the issue for you as well.
> 
> Jason

Aye; it did -- thank you for figuring out what was catalyzing it! :-)

Oddly enough, my build machine (which I keep in lock-step with my
laptop, except that it runs a GENERIC kernel) hadn't experienced
the symptom; on the other hand, it has very few ports installed.

Peace,
david
-- 
David H. Wolfskill  da...@catwhisker.org
Those who would murder in the name of God or prophet are blasphemous cowards.

See http://www.catwhisker.org/~david/publickey.gpg for my public key.


signature.asc
Description: PGP signature

Re: Unexpected output from "pkg updating -d 20160626"

[Jason Unovitch]

On Tue, Jun 28, 2016 at 04:44:33AM -0700, David Wolfskill wrote:
> As part of my daily update of FreeBSD on my laptop, on the first reboot
> after installing the freshly-built kernel & world, I use portmaster to
> update any installed ports that have been updated since I last updated.
> 
> This morning, for the first time in ... months, I think, the "pkg
> updating -d ..." command I run to start the process actually generated
> some output -- quite a bit of it.
> 
> But I'm at a loss to understand why it did: only one of the ports it
> mentioned is installed, and that one didn't get updated by "portmaster
> -ad"; the others aren't installed at all.
> 
> My ports working copy is ports/head, at r417708.
> 
> I'm running:
> FreeBSD g1-252.catwhisker.org 10.3-STABLE FreeBSD 10.3-STABLE #406  
> r302244M/302246:1003505: Tue Jun 28 04:11:52 PDT 2016 
> r...@g1-252.catwhisker.org:/common/S1/obj/usr/src/sys/CANARY  amd64
> 
> now; when I ran "pkg updating -d ...", I was running:
> FreeBSD g1-252.catwhisker.org 10.3-STABLE FreeBSD 10.3-STABLE #405  
> r302220M/30:1003504: Mon Jun 27 04:03:47 PDT 2016 
> r...@g1-252.catwhisker.org:/common/S1/obj/usr/src/sys/CANARY  amd64
> 
> and pkg reports:
> g1-252(10.3-S)[2] pkg --version
> 1.8.6
> 
> The "pkg updating" command I issued was: pkg updating -d 20160626

Hello David,
I did replicate this and it seemed related to a handful of recent
UDPATING entries that were made without a trailing colon after the date.
I normalized all the entries for consistency and am seeing `pkg updating
-d 20160626` return the expected output for me. Please see if that
resolved the issue for you as well.

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

[Alfred Perlstein]

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?


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


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.


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.


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

Is there still broken lang/ruby23 ?

[KIRIYAMA Kazuhiko]

Hi,

Is there still broken lang/ruby23[1]. Or can build in latest
11.0-* ? 

[1] http://permalink.gmane.org/gmane.os.freebsd.devel.pkg-fallout/294364

---
KIRIYAMA Kazuhiko
___
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: blanket portmgr approval vs. non-fixing changes

[Baptiste Daroussin]

On Tue, Jun 28, 2016 at 11:15:56PM +0200, Matthias Andree wrote:
> Am 28.06.2016 um 11:17 schrieb Baptiste Daroussin:
> 
> > What you are asking is part of the blanket in particular when changing 
> > things in
> > individual ports, we expect committers to have a look at pending PR (yes I 
> > know
> > I have been guilty of individual port change without sometime checking about
> > pending PR which was wrong from my side)
> > 
> > For sweeping changes this is a bit different as when a change touches a 
> > large
> > portion of the tree we can not expect the committer to have a look at each
> > individual ports.
> 
> Baptiste,
> 
> to give you a provoking counter example:
> 
>   By that logic, I would not have been expected to notice that the
> bitcoin garbage insisted on db48, I could just have killed it off and
> moved the bitcoin ports onto db5.  (That's stretching it a bit because
> there was Peter Wemm's objection to the DEPRECATED= tag on record already.)
> 
> 
> Meaning that, in this thread: I beg to differ on sweeping changes.
> 
> These do need a thorough review, and often a series of -exp runs, to
> keep the number of casualties low.  If I had gone by this policy of
> sweeping changes, we'd nuked all DB2, DB3 and DB4 ports and had force
> moved all the bitcoin and openldap ports and whatnot onto db5 without
> consulting anyone, and I guess we'd heard a lot more screaming than with
> the approach I chose, meaning look at several dozen of ports before
> committing the breaking and sweeping changes.
> 
> And I do think we should, opposite to what you are proposing, make the
> committer spend extra time for high-profile ports that entail sweeping
> changes to chase down the breaking change to, say, a library port.
> 

I might have been not explicit enough, of course any changes should be tested,
and of course high profile ports breaking means special attention and prevent
the sweeping change to actually happen.

Read the context... here we were speaking of changes that adds extra works for 
maintainers on individual ports and the fact that someone should check for PR on
everysingle port that are going to be touched. In that case on a sweeping change
like what mat did for removal of ${PORTSDIR} you cannot expect the committer to
check everysingle ports for pending PR, but of course you can expect that for
every single change sweep or not the committer has to test all the ports touched
by the change to ensure they do not break.

Bapt


signature.asc
Description: PGP signature

Re: blanket portmgr approval vs. non-fixing changes

[Matthias Andree]

Am 28.06.2016 um 11:17 schrieb Baptiste Daroussin:

> What you are asking is part of the blanket in particular when changing things 
> in
> individual ports, we expect committers to have a look at pending PR (yes I 
> know
> I have been guilty of individual port change without sometime checking about
> pending PR which was wrong from my side)
> 
> For sweeping changes this is a bit different as when a change touches a large
> portion of the tree we can not expect the committer to have a look at each
> individual ports.

Baptiste,

to give you a provoking counter example:

  By that logic, I would not have been expected to notice that the
bitcoin garbage insisted on db48, I could just have killed it off and
moved the bitcoin ports onto db5.  (That's stretching it a bit because
there was Peter Wemm's objection to the DEPRECATED= tag on record already.)


Meaning that, in this thread: I beg to differ on sweeping changes.

These do need a thorough review, and often a series of -exp runs, to
keep the number of casualties low.  If I had gone by this policy of
sweeping changes, we'd nuked all DB2, DB3 and DB4 ports and had force
moved all the bitcoin and openldap ports and whatnot onto db5 without
consulting anyone, and I guess we'd heard a lot more screaming than with
the approach I chose, meaning look at several dozen of ports before
committing the breaking and sweeping changes.

And I do think we should, opposite to what you are proposing, make the
committer spend extra time for high-profile ports that entail sweeping
changes to chase down the breaking change to, say, a library port.

Cheers,
Matthias



signature.asc
Description: OpenPGP digital signature

Re: blanket portmgr approval vs. non-fixing changes

[Matthias Andree]

Am 27.06.2016 um 18:07 schrieb Cy Schubert:

> Mathias,

Cy,

Mind the double t please.

> I'm surprised at your position. I recall a commit you made to one of my 
> ports a few years ago, to which I objected. Your position now is a complete 
> reversal of your arguments then.

Quite possible.  Things and views change over time.  My day job has
changed (a few years ago already -- I've been working for a car part
supplier for the past almost five years), personal life has changed a
bit (less radically), and with it my experience and a sense of how I
priorize matters.

Some matters I would have found "urgent" earlier now lost this
attribute, and I figured that more haste often means more work to clear
up some unintended mess, and I value sustainability higher. "Touch
things less often."   I know some people subscribe to "release early,
release often" to get improvements deployed, and I'll consider that to
some extent, but not if it goes at the expense of quality or raises the
release efforts [1] beyond reason.

[1] this includes dealing with PRs, committing to ports, and similar.


[Which reminds me I still need to see to getting the self-tests for
sysutils/e2fsprogs sorted so that I can commit the upgrade to 1.43.1.
We've skipped 1.43 deliberately because it had a few regressions that
Ted Ts'o and I have sorted out before 1.43.1.]
___
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: blanket portmgr approval vs. non-fixing changes

[Matthias Andree]

Am 27.06.2016 um 12:02 schrieb Guido Falsi:

>> 2. What I was meaning to state was that (and I'll not pick at the
>> kind soul who has modernized the port) we should only apply the
>> blanket approval if ports have fallen into disrepair.
> 
> I'd say that it's a matter of urgency for the change. Need for
> urgency is evident for broken ports and also serious security
> issues.
> 
> It could be less evident for infrastructure changes which need to be 
> urgently deployed to a major number of ports, or changes to head
> which require patching a lot of ports (one good example could be the
> recent update to libc++ 3.8.0 in head, even if it could be accounted
> as "broken ports" case, so with a relatively high degree of
> urgency).

Yeah - but then again head or -CURRENT is a moving target and by
definition non-urgent and maintainers are encouraged, but not formally
required, to support it.

Generally you're raising a good point, but I'd wager the guess that most
of these changes do need more extensive planning anyways and portmgr@ or
whoever is driving such a sweeping infrastructure change will want to
seek the maintainer's assistance.

I'll normally be happy to help with such changes, only not under pressure.

[...]

> We are now in a much better situation and most changes are less
> urgent, and can wait some time. I'd say usually such changes should
> go through bugzilla or phabric review, with portmgr adding special
> case blankets for specific changes which should hit the tree as soon
> as possible, if this is not an excessive burden on portmgr.

On a related note, once in a while I am checking what's on Bugzilla's
table only to find that even the stuff that looks easy (maintainer port
submission or similar) breaks early or raises my suspicion.
Unfortunately that often means I drop a PR and don't really help getting
the ports PR cleared.  When Miwi and I think Kris proposed me for a
commits bit the deal used to be "if the project is find if I mostly tend
to my ports"... and not much has changed since.

> I'm not sure I agree on lowering the 14 days timeout for bug reports.
> I usually reply in a matter of hours if at all possible, 2-3 days
> when I take a long time, at least with a "going to test" message, but
> not all people can manage this, lowering timeouts could raise the bar
> on being a maintainer which is something I think we should avoid.

I concur with that. I'll normally respond within 72 hours, often within
24, and sometimes quicker if the urgency catches my eye.  A catchy
subject on a message Cc:d to my @FreeBSD.org address helps a lot.
"SECURITY" is sure to get my attention rather fast.

> I think it could be enough to state a list of make targets which one 
> must warrant keep working, it's obvious that make config, make
> install and make deinstall should work correctly, less obvious for
> other targets.

That would work for me, too, as a first step.

___
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: pkg SAT_SOLVER bugs

[Rodrigo OSORIO]

On 06/28/16 00:09, Baptiste Daroussin wrote:

On Mon, Jun 27, 2016 at 11:42:08PM +0200, Rodrigo OSORIO wrote:

On 06/27/16 12:38, Hans Petter Selasky wrote:

Hi,

I found some bugs in PKG with regard to the SAT_SOLVER environment
variable. Please find patch attached :-)

Issues fixed:
1) No need to use hash table when generating SAT rules for external
solver. Variables are already in a linear array. Fix encoding and
decoding of SAT data.
2) Endless variable loop caused pkg to crash.
3) it->inverse was checked for non-zero, while it should actually be
checked for -1 only. SAT rules produces were all negative.

How to verify:

make -C /usr/ports/math/picosat all install clean

env SAT_SOLVER=picosat pkg upgrade

--HPS


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



Thanks! this patch saves my day, I was stuck reinstalling a computer in
current, and after few rounds using pkg the solver start complaining and
pretending missing packages was yet installed.

I apply you patch on top of the last version in ports and the patch work as
a charm. I'll keep testing it until a new version comes.

regards,
- rodrigo


that is unrelated, what saved you it that building from ports you switched form
1.8.5 to 1.8.6 his patch is to solve the use of an external SAT solver which I
admit I haven't tested for a while.

Pkg 1.8.6 is the default binary package for all release but head right now,
pending for the next build cycle.

Best regards,
Bapt



Ouch, that hurts but you're right ;)
sorry for the unnecessary noise

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

Independence Day Sale, starts right now.

[Hosiery Street]

This email newsletter was sent to you in graphical HTML format.
If you're seeing this version, your email program prefers plain text emails.
You can read the original version online:
http://ymlp48.com/zFdEBC



HAPPY INDEPENDENCE DAY!!! ( http://hosierystreet.com/&refer=em_716 )

SALE FREE SHIPPING FOR FREEDOM WEEKEND ON ALL ORDERS $25 AND
UP IN CONTIGUOUS US of A!

Dear Customer

Thank you so much for shopping at HosieryStreet.com

As in every email (just a few times a year) we would like to remind
you first and foremost that if you don't want to be on our sale list
please unsubscribe below and you will be removed from this email list
immediately. We do not want to SPAM anyone. PLEASE DO NOT REPORT THIS
AS SPAM.

The following is a few of our HOTTEST items you may be interested in:

5  HOTTEST DEALS FROM BESTFORM (
http://www.hosierystreet.com/system/scripts/search.cgi?&p=1&&Company=Bestform&Submit2=Search&action=search&per_page=90&sort_by=Brand#Search&refer=em_716
).

NOW ONLY: $8.99

Bestform
Double Lined Front Close Cotton Sport Bra. #6014

Click here for more info >>> (
http://www.hosierystreet.com/system/scripts/results_big.cgi?product=bef6014&refer=em_716
)NOW ONLY: $8.49

Bestform
INVISABRA Undewire# 6502

Click here for more info >>> (
http://www.hosierystreet.com/system/scripts/results_big.cgi?product=bf6502&refer=em_716
)

NOW ONLY: $6.99

Bestform
BodyCottons Softcup # 6715

Click here for more info >>> (
http://www.hosierystreet.com/system/scripts/results_big.cgi?product=bf6715&refer=em_716
)NOW ONLY: $10.99

Bestform
Shirred Front Sport Bra. #6040

Click here for more info >>> (
http://www.hosierystreet.com/system/scripts/results_big.cgi?product=bef6040&refer=em_716
)NOW ONLY: $6.99

Bestform
BodyCottons Softcup # 6825

Click here for more info >>> (
http://www.hosierystreet.com/system/scripts/results_big.cgi?product=bf6825&refer=em_716
)

or click here for more BestForm Bras at Greatly Discounted Prices...
(
http://www.hosierystreet.com/system/scripts/search.cgi?&p=1&&Company=Bestform&Submit2=Search&action=search&per_page=90&sort_by=Brand#Search&refer=em_716
)

6 MORE  GREAT DEALS FROM VASSARETTE (
http://www.hosierystreet.com/system/scripts/search.cgi?&p=1&&txtSearch=&search_type=in_all&category=21&Company=Vassarette&price_from=&price_to=&command=advance_search&action=search&cmdGetCustomers=Get+Result&per_page=90&sort_by=Brand#Search&refer=em_716
).

NOW ONLY: $3.99

Vassarette
Light Control Hi-Cut Brief

Click here for more info >>> (
http://www.hosierystreet.com/system/scripts/results_big.cgi?product=48-001&refer=em_716
)NOW ONLY: $3.99

Vassarette
Light Control Brief

Click here for more info >>> (
http://www.hosierystreet.com/system/scripts/results_big.cgi?product=40-001&refer=em_716
)NOW ONLY: $3.99

Vassarette
Light Control Brief

Click here for more info >>> (
http://www.hosierystreet.com/system/scripts/results_big.cgi?product=40-001&refer=em_716
)

NOW ONLY: $9.89

Vassarette
BodyCurves Microfiber Wireless Contour

Click here for more info >>> (
http://www.hosierystreet.com/system/scripts/results_big.cgi?product=72-239&refer=em_716
)NOW ONLY: $11.49

Vassarette
RealSexy Her Secret Push Up UW

Click here for more info >>> (
http://www.hosierystreet.com/system/scripts/results_big.cgi?product=75-320&refer=em_716
)

NOW ONLY: $12.99

Vassarette
BodyCurves Flir-T FF Contour UW. #75-818

Click here for more info >>> (
http://www.hosierystreet.com/system/scripts/results_big.cgi?product=75-818&refer=em_716
)

or click here for more ON SALE Vassarette Bras...  (
http://www.hosierystreet.com/system/scripts/search.cgi?&p=1&&txtSearch=&search_type=in_all&category=21&Company=Vassarette&price_from=&price_to=&command=advance_search&action=search&cmdGetCustomers=Get+Result&per_page=90&sort_by=Brand#Search&refer=em_716
)

-

PLEASE CHECK OUT OUR VANITY FAIR BRA LINE!!! (
http://www.hosierystreet.com/system/scripts/search.cgi?txtSearch=&search_type=in_all&category=21&Company=Vanity+Fair&price_from=&price_to=&command=advance_search&action=search&cmdGetCustomers=Get+Result&refer=em_716
)

MORE INFO >>> CLICK HERE >>> (
http://www.hosierystreet.com/system/scripts/search.cgi?txtSearch=&search_type=in_all&category=21&Company=Vanity+Fair&price_from=&price_to=&command=advance_search&action=search&cmdGetCustomers=Get+Result&refer=em_716
)

_
Unsubscribe / Change Profile: http://ymlp48.com/ugmjwyjqgsgymqesgbumgguwhwh
Powered by YourMailingListProvider

___
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: 2016Q2 - no Mk/Uses/mysql.mk

[Bernard Spil]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 2016-06-28 16:58, Mathieu Arnold wrote:
> +--On 28 juin 2016 10:30:10 -0400 Dan Langille  wrote:
> |> On Jun 28, 2016, at 7:56 AM, Mathieu Arnold  wrote:
> |>
> |>
> |>
> |> +--On 27 juin 2016 17:22:56 -0400 Dan Langille  wrote:
> |> | I've been working with the 2016Q2 branch with respect to FreshPorts.
> |> |
> |> | I tried running make -V on branches/2016Q2 and it failed with:
> |> |
> |> | Error message is: make: "/usr/local/repos/PORTS-2016Q2/Mk/bsd.port.mk"
> |> | line 1433: Cannot open /usr/local/repos/PORTS-2016Q2/Mk/Uses/mysql.mk
> |> |
> |> | It seems that recent changes to Mk also need to be backported to
> |> | branches if there is a commit on that branch.
> |>
> |> Well, no, people merging things are supposed to check what they are doing
> |> and not commit stupid patches, which is the case here.
> |>
> |> Which port has USES=mysql on 2016Q2 ?
> |
> | Log:
> |   MFH: r416066
> |
> |   net-mgmt/cacti: 0.8.8g -> 0.8.8h
> |
> | It appears to have already been fixed in Revision 416207:
> |
> | - no USES=mysql allowed in the quarterly branch
> |
> | re
> | https://svnweb.freebsd.org/ports/branches/2016Q2/net-mgmt/cacti/Makefile?
> | view=log
> |  | ?view=log>
> |
> | Ooops.  Sorry for the noise.  I'll look at the new commits on that port.
> | I was analyzing commits which FreshPorts had difficulty processing.
> |
> | Nothing to see here. Please move along...
> 
> Well, no, the noise is good, it should be reported to the committer that
> did the commit, like other breakage are, so that said committer knows and
> fixes the problem.

Just lucky that it wasn't me. Good thing to keep in mind with these
kinds of changes! Usually only the actual update is committed, not a
check for these kinds of changes to the ports framework!

I've got some Python patches in review that now have USES= ssl which
would break in Q2 as well! Luckily no security fixes in there afaik.

Cheers,

Bernard.
-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQIcBAEBAgAGBQJXctaeAAoJEHT7/r+FArC0rzsP/jx32UsjVtA8dgYHCf+gM7mt
gz55FCOT7XI+m13nAZWpI3VfsW2MuA99j/B/npXMfDSqixGSDfZyFq0Xr+MPP9UU
b48TGrXbEUVQvkG4dRy5WK/J0XcqwO2x+ajD29lJtHZE/2aTMrBoXRYYifQkx0ew
iDftQDlauGp8usNjgAVrZffRkj0q0v2cQGcepL8iqHuKXA63b9dsxV65BeIUFLPE
hnL+AneFqiaXa9zSc72/o3PS173Y8d3XaSxPjw4pRBBuD4mDDadAdebUz/ZCVwug
k6g+LsVs+iqjn8nq1O6wgqJHh7LKLU04WGSPYHSUl7ErzmBOlxKJleFM3gOur2Og
9qy/dLwvftlNtEZ/8aI00ZVcKd4kzyoYZxa215g3A+vd+zDOTSPOWE3VgNoyf4KK
NHrKkrKH3f7/5um4RBuJf69lFs1X7RNuPPCXONnO1t3xDDOeOFAseKrQodDqfTo2
nC9X/Kf1cHi/wU9aF0DqttJj10fXdjbkthcKlSZ+dwk6p+wEEwLorbXrGI00f/aG
R6UFa5XhdQxkBYGiBKwPaNTEsNoGo0BhK48z5oknt9rv6Psm8C7Sa99euCVFMxqY
FftKkp3Iy731AnrApWkzaDd9CNtkvomhYZklx1rG/cqOq+0Xz+clFV1BADSZS2T1
Bd+0Wkqzm5WA7FDgjNOP
=WchY
-END PGP SIGNATURE-
___
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: blanket portmgr approval vs. non-fixing changes

[Kubilay Kocak]

On 28/06/2016 9:03 PM, Alphons van Werven wrote:
> Maintainers are already notified by e-mail of commits resulting from PRs
> because they are put on the CC list. Maybe it's just me, but I think it
> would be very nice if maintainers were *always* automagically notified of
> *any* commits to their ports, including those subject to blanket approval.

Good idea, as long as people could opt-in/out as appropriate.

> With any luck, such notifications are received in time to prevent (or at
> least limit) wasted time such as in the above case. Moreover, keeping
> maintainers informed also eliminates having to wonder "Ey, what's this
> 'ere then?" the next time they look at their ports. And finally, I'd
> surmise it would also help keeping maintainers abreast of developments in
> the ports infrastructure in general.
> 
> I know that the PR notifications come from BugZilla and not from SVN, so
> what I don't know is how feasible it is rig up something like this, but I
> do know that I for one would quite appreciate something along these lines.

Quite feasible, hit me up off list and we can discuss further :)

./koobs
___
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: pkg SAT_SOLVER bugs

[Baptiste Daroussin]

On Tue, Jun 28, 2016 at 05:52:32PM +0200, Hans Petter Selasky wrote:
> On 06/27/16 13:55, Baptiste Daroussin wrote:
> > On Mon, Jun 27, 2016 at 12:38:02PM +0200, Hans Petter Selasky wrote:
> > > Hi,
> > > 
> > > I found some bugs in PKG with regard to the SAT_SOLVER environment 
> > > variable.
> > > Please find patch attached :-)
> > > 
> > > Issues fixed:
> > > 1) No need to use hash table when generating SAT rules for external 
> > > solver.
> > > Variables are already in a linear array. Fix encoding and decoding of SAT
> > > data.
> > > 2) Endless variable loop caused pkg to crash.
> > > 3) it->inverse was checked for non-zero, while it should actually be 
> > > checked
> > > for -1 only. SAT rules produces were all negative.
> > > 
> > > How to verify:
> > > 
> > > make -C /usr/ports/math/picosat all install clean
> > > 
> > > env SAT_SOLVER=picosat pkg upgrade
> > > 
> > > --HPS
> > 
> > Thank you I will look into shortly
> > 
> 
> Hi Baptiste,
> 
> Are you handling this one or do you want me to create an issue at github.
> Thank you!
> 
I am handling it

BTW not that picosat is the one we use internally already :D

Best regards
Bapt


signature.asc
Description: PGP signature

Re: pkg SAT_SOLVER bugs

[Kubilay Kocak]

On 27/06/2016 8:38 PM, Hans Petter Selasky wrote:
> Hi,
> 
> I found some bugs in PKG with regard to the SAT_SOLVER environment
> variable. Please find patch attached :-)
> 
> Issues fixed:
> 1) No need to use hash table when generating SAT rules for external
> solver. Variables are already in a linear array. Fix encoding and
> decoding of SAT data.
> 2) Endless variable loop caused pkg to crash.
> 3) it->inverse was checked for non-zero, while it should actually be
> checked for -1 only. SAT rules produces were all negative.
> 
> How to verify:
> 
> make -C /usr/ports/math/picosat all install clean
> 
> env SAT_SOLVER=picosat pkg upgrade
> 
> --HPS
> 

Heads-up: Have just updated picosat to its latest version, enjoy!

___
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: pkg SAT_SOLVER bugs

[Hans Petter Selasky]

On 06/27/16 13:55, Baptiste Daroussin wrote:

On Mon, Jun 27, 2016 at 12:38:02PM +0200, Hans Petter Selasky wrote:

Hi,

I found some bugs in PKG with regard to the SAT_SOLVER environment variable.
Please find patch attached :-)

Issues fixed:
1) No need to use hash table when generating SAT rules for external solver.
Variables are already in a linear array. Fix encoding and decoding of SAT
data.
2) Endless variable loop caused pkg to crash.
3) it->inverse was checked for non-zero, while it should actually be checked
for -1 only. SAT rules produces were all negative.

How to verify:

make -C /usr/ports/math/picosat all install clean

env SAT_SOLVER=picosat pkg upgrade

--HPS


Thank you I will look into shortly



Hi Baptiste,

Are you handling this one or do you want me to create an issue at 
github. Thank you!


--HPS

___
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: 2016Q2 - no Mk/Uses/mysql.mk

[Mathieu Arnold]

+--On 28 juin 2016 10:30:10 -0400 Dan Langille  wrote:
|> On Jun 28, 2016, at 7:56 AM, Mathieu Arnold  wrote:
|> 
|> 
|> 
|> +--On 27 juin 2016 17:22:56 -0400 Dan Langille  wrote:
|> | I've been working with the 2016Q2 branch with respect to FreshPorts.
|> | 
|> | I tried running make -V on branches/2016Q2 and it failed with:
|> | 
|> | Error message is: make: "/usr/local/repos/PORTS-2016Q2/Mk/bsd.port.mk"
|> | line 1433: Cannot open /usr/local/repos/PORTS-2016Q2/Mk/Uses/mysql.mk
|> | 
|> | It seems that recent changes to Mk also need to be backported to
|> | branches if there is a commit on that branch.
|> 
|> Well, no, people merging things are supposed to check what they are doing
|> and not commit stupid patches, which is the case here.
|> 
|> Which port has USES=mysql on 2016Q2 ?
| 
| Log:
|   MFH: r416066
| 
|   net-mgmt/cacti: 0.8.8g -> 0.8.8h
| 
| It appears to have already been fixed in Revision 416207:
| 
| - no USES=mysql allowed in the quarterly branch
| 
| re
| https://svnweb.freebsd.org/ports/branches/2016Q2/net-mgmt/cacti/Makefile?
| view=log
| 
| 
| Ooops.  Sorry for the noise.  I'll look at the new commits on that port.
| I was analyzing commits which FreshPorts had difficulty processing.
| 
| Nothing to see here. Please move along...

Well, no, the noise is good, it should be reported to the committer that
did the commit, like other breakage are, so that said committer knows and
fixes the problem.

-- 
Mathieu Arnold

pgpJZH35sANn1.pgp
Description: PGP signature

Re: 2016Q2 - no Mk/Uses/mysql.mk

[Dan Langille]

> On Jun 28, 2016, at 7:56 AM, Mathieu Arnold  wrote:
> 
> 
> 
> +--On 27 juin 2016 17:22:56 -0400 Dan Langille  wrote:
> | I've been working with the 2016Q2 branch with respect to FreshPorts.
> |
> | I tried running make -V on branches/2016Q2 and it failed with:
> |
> | Error message is: make: "/usr/local/repos/PORTS-2016Q2/Mk/bsd.port.mk"
> | line 1433: Cannot open /usr/local/repos/PORTS-2016Q2/Mk/Uses/mysql.mk
> |
> | It seems that recent changes to Mk also need to be backported to branches
> | if there is a commit on that branch.
> 
> Well, no, people merging things are supposed to check what they are doing
> and not commit stupid patches, which is the case here.
> 
> Which port has USES=mysql on 2016Q2 ?

Log:
  MFH: r416066

  net-mgmt/cacti: 0.8.8g -> 0.8.8h

It appears to have already been fixed in Revision 416207:

- no USES=mysql allowed in the quarterly branch

re 
https://svnweb.freebsd.org/ports/branches/2016Q2/net-mgmt/cacti/Makefile?view=log
 


Ooops.  Sorry for the noise.  I'll look at the new commits on that port. I was 
analyzing commits
which FreshPorts had difficulty processing.

Nothing to see here. Please move along...

--
Dan Langille - BSDCan / PGCon
d...@langille.org






signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: 2016Q2 - no Mk/Uses/mysql.mk

[Mathieu Arnold]

+--On 27 juin 2016 17:22:56 -0400 Dan Langille  wrote:
| I've been working with the 2016Q2 branch with respect to FreshPorts.
| 
| I tried running make -V on branches/2016Q2 and it failed with:
| 
| Error message is: make: "/usr/local/repos/PORTS-2016Q2/Mk/bsd.port.mk"
| line 1433: Cannot open /usr/local/repos/PORTS-2016Q2/Mk/Uses/mysql.mk
| 
| It seems that recent changes to Mk also need to be backported to branches
| if there is a commit on that branch.

Well, no, people merging things are supposed to check what they are doing
and not commit stupid patches, which is the case here.

Which port has USES=mysql on 2016Q2 ?

-- 
Mathieu Arnold

pgphFHfhs_FFI.pgp
Description: PGP signature

Unexpected output from "pkg updating -d 20160626"

[David Wolfskill]

As part of my daily update of FreeBSD on my laptop, on the first reboot
after installing the freshly-built kernel & world, I use portmaster to
update any installed ports that have been updated since I last updated.

This morning, for the first time in ... months, I think, the "pkg
updating -d ..." command I run to start the process actually generated
some output -- quite a bit of it.

But I'm at a loss to understand why it did: only one of the ports it
mentioned is installed, and that one didn't get updated by "portmaster
-ad"; the others aren't installed at all.

My ports working copy is ports/head, at r417708.

I'm running:
FreeBSD g1-252.catwhisker.org 10.3-STABLE FreeBSD 10.3-STABLE #406  
r302244M/302246:1003505: Tue Jun 28 04:11:52 PDT 2016 
r...@g1-252.catwhisker.org:/common/S1/obj/usr/src/sys/CANARY  amd64

now; when I ran "pkg updating -d ...", I was running:
FreeBSD g1-252.catwhisker.org 10.3-STABLE FreeBSD 10.3-STABLE #405  
r302220M/30:1003504: Mon Jun 27 04:03:47 PDT 2016 
r...@g1-252.catwhisker.org:/common/S1/obj/usr/src/sys/CANARY  amd64

and pkg reports:
g1-252(10.3-S)[2] pkg --version
1.8.6

The "pkg updating" command I issued was: pkg updating -d 20160626

For each port in the resulting output, I ran "pkg info -o ...", with the
following results:

g1-252(10.3-S)[1] pkg info -o ftp/wget
wget-1.18  ftp/wget
g1-252(10.3-S)[2] pkg info -o databases/py-apsw
pkg: No package(s) matching databases/py-apsw
g1-252(10.3-S)[3] pkg info -o security/openssl\*
pkg: No package(s) matching security/openssl*
g1-252(10.3-S)[4] pkg info -o security/libressl\*
pkg: No package(s) matching security/libressl*
g1-252(10.3-S)[5] pkg info -o www/node\*
pkg: No package(s) matching www/node*
g1-252(10.3-S)[6] pkg info -o textproc/xmlroff
pkg: No package(s) matching textproc/xmlroff
g1-252(10.3-S)[7] pkg info -o databases/postgresql-repmgr
pkg: No package(s) matching databases/postgresql-repmgr
g1-252(10.3-S)[8] pkg info -o www/h2o
pkg: No package(s) matching www/h2o
g1-252(10.3-S)[9] pkg info -o security/libressl-devel
pkg: No package(s) matching security/libressl-devel
g1-252(10.3-S)[10] pkg info -o mail/opensmtpd-extras\*
pkg: No package(s) matching mail/opensmtpd-extras*
g1-252(10.3-S)[11]


When I actually ran "portmaster -ad" it reported:
===>>> The following actions will be taken if you choose to proceed:
Upgrade pcre-8.38_1 to pcre-8.39
Upgrade bash-4.3.42_1 to bash-4.3.46
Upgrade p5-DateTime-Locale-1.04 to p5-DateTime-Locale-1.05
Upgrade p5-IO-Socket-SSL-2.027 to p5-IO-Socket-SSL-2.029
Upgrade firefox-47.0_1,1 to firefox-47.0.1,1

===>>> Proceed? y/n [y]

and on completion, it reported:
===>>> The following actions were performed:
Upgrade of pcre-8.38_1 to pcre-8.39
Upgrade of bash-4.3.42_1 to bash-4.3.46
Upgrade of p5-DateTime-Locale-1.04 to p5-DateTime-Locale-1.05
Upgrade of p5-IO-Socket-SSL-2.027 to p5-IO-Socket-SSL-2.029
Upgrade of firefox-47.0_1,1 to firefox-47.0.1,1


Any ideas on why "pkg updating" produced such output?

I have attached a copy of the actual output itself.

Thanks!

Peace,
david
-- 
David H. Wolfskill  da...@catwhisker.org
Those who would murder in the name of God or prophet are blasphemous cowards.

See http://www.catwhisker.org/~david/publickey.gpg for my public key.
20160627:
  AFFECTS: users of ftp/wget
  AUTHOR: v...@freebsd.org

  Wget 1.18 fixes a security vulnerability (CVE-2016-4971) and the fix
  introduces a backward-incompatibility for HTTP->FTP redirects. Any script that
  relies on the old behaviour must use --trust-server-names in order to trust
  the HTTP response and redirect to the new filename.

20160619
  AFFECTS: users of databases/py-apsw
  AUTHOR: r...@freebsd.org

  SQLite 3.12 completely changed the semantics of VFS.xGetLastError() in an
  incompatible way. This required a rewrite of the relevant C, Python and test
  code. If you implement or use this method then you have to rewrite your code
  too. Also note that running the test suite from an earlier version of APSW
  against this or future SQLite versions will result in consuming all memory,
  swap or address space (an underlying integer changed meaning).

20160616
  AFFECTS: users of security/openssl*, security/libressl*
  AUTHOR: m...@freebsd.org

  Previously, to tell the ports tree, you needed to set:

  WITH_OPENSSL_PORT=yes
  
  And if you wanted a port that was not security/openssl, you needed to add,
  for example:

  OPENSSL_PORT= security/libressl

  Now, all you need to do is:

  DEFAULT_VERSIONS+=  ssl=libressl
  
  Valid values are base, openssl, openssl-devel, libressl, and libressl-devel.

20160614
  AFFECTS: users of www/node, www/node5, and www/node4
  AUTHOR: ad...@freebsd.org

  node now prefers a few libraries from ports to the versions bundled
  with node. However, node cannot use the libssl from LibreSSL. If you
  are using LibreSSL as your SSL provi

Re: blanket portmgr approval vs. non-fixing changes

[Alphons van Werven]

Kevin Golding wrote:

> and about the same time someone did a blanket update of RUN_DEPENDS in
> my ports. Including a PORTREVISION bump. It's easy to argue that's a
> very trivial change that doesn't needs maintainer involvement, but it
> also impacted my day.
[snip]
> Had I known about the blanket update I could've rolled that into my
> updates or something, but it was just suddenly there. There was no
> public warning of that change coming

Maintainers are already notified by e-mail of commits resulting from PRs
because they are put on the CC list. Maybe it's just me, but I think it
would be very nice if maintainers were *always* automagically notified of
*any* commits to their ports, including those subject to blanket approval.

With any luck, such notifications are received in time to prevent (or at
least limit) wasted time such as in the above case. Moreover, keeping
maintainers informed also eliminates having to wonder "Ey, what's this
'ere then?" the next time they look at their ports. And finally, I'd
surmise it would also help keeping maintainers abreast of developments in
the ports infrastructure in general.

I know that the PR notifications come from BugZilla and not from SVN, so
what I don't know is how feasible it is rig up something like this, but I
do know that I for one would quite appreciate something along these lines.

Fonz (bla bla bla, something about two cents, bla bla bla)

-- 
A.J. "Fonz" van Werven
mailsig: Ob technicas difficultates, lux in fine cuniculum non operatur.


signature.asc
Description: PGP signature

Re: How to change repository name of installed packages in local database?

[Miroslav Lachman]

Baptiste Daroussin wrote on 06/28/2016 12:33:

On Tue, Jun 28, 2016 at 12:16:17PM +0200, Miroslav Lachman wrote:

I searched the man pages but cannot find the answer.
If we have machine with packages installed from more than one repository and
one day we want to use some already installed packages from another
repository, is there any easy way of switching this packages to another
repo?


[...]


Now we need to switch all packages from testing repo "redmine320" to
production repo "codelab".

Is there any other way instead of manual deinstall and reinstall of all
those packages?



# remove the "repository" annotation
pkg annotate -D expat repository

# add the new one
pkg annotate -A expat repository codelab

For convenience we could allow to overrite an existing one, but we do not yet


Modification with pkg annotate -M works for me!

   # pkg annotate -M rubygem-web-console repository codelab
rubygem-web-console-2.3.0: Change annotation tagged: repository to new 
value: codelab? [y/N]: y

rubygem-web-console-2.3.0: Modified annotation tagged: repository

   # pkg annotate -S rubygem-web-console repository
rubygem-web-console-2.3.0: Tag: repository Value: codelab


I switched all repo "redmine320" packages to repository "codelab" with 
following command (not so elegant)


  # pkg query '%R %n' | awk '$1 == "redmine320" { print $2 }' | xargs 
-L1 -J % pkg annotate -y -M % repository codelab



Thank you Bapt and Franco!

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: How to change repository name of installed packages in local database?

[Baptiste Daroussin]

On Tue, Jun 28, 2016 at 12:16:17PM +0200, Miroslav Lachman wrote:
> I searched the man pages but cannot find the answer.
> If we have machine with packages installed from more than one repository and
> one day we want to use some already installed packages from another
> repository, is there any easy way of switching this packages to another
> repo?
> I am looking for something similar to "pkg set" but we do not want to change
> package name or package origin but package repository information recorded
> in sqlite.
> 
> Example:
> 
> # pkg query '%R %n' | sort
> codelab libiconv
> codelab mariadb55-server
> codelab p5-Error
> codelab p5-Term-ReadKey
> codelab p5-subversion
> codelab pkg-rmleaf
> codelab unzip
> codelab vim-lite
> redmine320 ImageMagick-nox11
> redmine320 ca_root_nss
> redmine320 curl
> redmine320 expat
> redmine320 fontconfig
> redmine320 freetype2
> redmine320 indexinfo
> ..
> ..
> 
> Now we need to switch all packages from testing repo "redmine320" to
> production repo "codelab".
> 
> Is there any other way instead of manual deinstall and reinstall of all
> those packages?
> 

# remove the "repository" annotation
pkg annotate -D expat repository

# add the new one
pkg annotate -A expat repository codelab

For convenience we could allow to overrite an existing one, but we do not yet

Best regards,
bapt


signature.asc
Description: PGP signature

Re: How to change repository name of installed packages in local database?

[Franco Fichtner]

> On 28 Jun 2016, at 12:16 PM, Miroslav Lachman <000.f...@quip.cz> wrote:
> 
> Now we need to switch all packages from testing repo "redmine320" to 
> production repo "codelab".

# pkg annotate -A ${PKG} repository ${REPO}


Cheers,
Franco
___
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"

How to change repository name of installed packages in local database?

[Miroslav Lachman]

I searched the man pages but cannot find the answer.
If we have machine with packages installed from more than one repository 
and one day we want to use some already installed packages from another 
repository, is there any easy way of switching this packages to another 
repo?
I am looking for something similar to "pkg set" but we do not want to 
change package name or package origin but package repository information 
recorded in sqlite.


Example:

# pkg query '%R %n' | sort
codelab libiconv
codelab mariadb55-server
codelab p5-Error
codelab p5-Term-ReadKey
codelab p5-subversion
codelab pkg-rmleaf
codelab unzip
codelab vim-lite
redmine320 ImageMagick-nox11
redmine320 ca_root_nss
redmine320 curl
redmine320 expat
redmine320 fontconfig
redmine320 freetype2
redmine320 indexinfo
..
..

Now we need to switch all packages from testing repo "redmine320" to 
production repo "codelab".


Is there any other way instead of manual deinstall and reinstall of all 
those packages?


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: Maintaining mono/.net

[Baptiste Daroussin]

On Mon, Jun 27, 2016 at 11:06:02AM -0700, Russell Haley wrote:
> Hello Ports Team,
> 
> A couple of us on the freebsd-mono@ mailing list are having a
> discussion on how best to maintain the mono ports/.net ports. One of
> the things that has come up is maintaining the patches for "all this
> stuff". The current paradigm in FreeBSD as I understand it is to use
> the files directory and apply the patches to the port via svn/ports
> tree. However, with the ubiquity of GitHub in opensource, it now seems
> to be feesable to simply create a Github accound to maintain a bunch
> of forked repositories (which is essentially a patched git
> repository!). This makes it easier to create and apply patches and
> gives us the natural path to push things back upstream. In the end, we
> would just pull from the FreeBSD specific repository, which is no
> different than, say, pulling from the mono project directly.
> 
> This email is a request for response from anyone on the ports team (or
> FreeBSD general) to give some input as to the acceptability of this
> solution, as well as any "gotchas" we haven't thought of yet. Thanks
> in advance!
> 
There are absolutely nothing against this. Actually some ports were already
doing that before the github era :D

The only difficulty the history told us is : when active people get less active
for various reasons you need to make sure enough people continues to get access
to the said repo.

Tracking upstream updates because more complicated for people not in the team
(we already saw in the past ports stucked for more than 5/6 years actions being
taken (maintainer of the forked becoming mostly MIA)

It also depends how many patches you end up with, I haven't checked the
mono/.net ports but if that is just a bunch of small patches then the overhead
is not worth the pain, if there are lots of patches then sure maintaining your
repo is simpler.

Depending on how active you (the team) are and how close to the upstream you are
one can also see those repositories as "temporary" until all the amount of
patches are upstreamed and when done the ports can switch back to the official
distfiles (this is always a goal for ports upstreaming all our patches so we can
remain as close as possible from the vanilla sources)

That said I do applause the effort. As a conclusion do what ever you think is
the easiest mechanism for you as long as things like monodevelop and friends can
be pushed in a working state again.

Best regards,
Bapt


signature.asc
Description: PGP signature

Re: blanket portmgr approval vs. non-fixing changes

[Baptiste Daroussin]

On Tue, Jun 28, 2016 at 09:12:46AM +0100, Kevin Golding wrote:
> On Mon, 27 Jun 2016 21:21:31 +0100, Cy Schubert 
> wrote:
> 
> > In message <57716d89.1050...@sorbs.net>, Michelle Sullivan writes:
> 
> > > Don't forget that many people see their name/email in the maintainer
> > > line as being responsible for the port.. so someone goes makes blanket
> > > changes which actually breaks stuff.. that reflects on the person in the
> > > Maintainer line - whether you want it to do so or not, whether you
> > > believe it or not..
> > 
> > I think it's more than the maintainer perceives that they're responsible.
> > Getting that email from freebsd-pkg-fallout I think there was and maybe
> > still is a general impression that is had. I for one take the attitude,
> > you
> > break it, you fix it and I don't hesitate to email any committer who
> > made a
> > blanket change that broke something. It's only fair because fixing
> > breakage
> > caused by others also takes away from other productive work and projects,
> > as some of us do have time constraints and time pressure due to other
> > commitments.
> 
> I think it goes beyond just breakages though. Recently I had a couple of
> ports to update so I made sure my tree was current first thing in the
> morning, I went through and updated. Then I ran all the build logs etc.
> submitted my patches to bugzilla - and about the same time someone did a
> blanket update of RUN_DEPENDS in my ports. Including a PORTREVISION bump.
> It's easy to argue that's a very trivial change that doesn't needs
> maintainer involvement, but it also impacted my day.
> 
> So I updated my tree again and did the whole process again which was
> inconvenient, but I also found myself cringing at any users of the port
> perhaps updating on the PORTREVISION and then a couple of days later when my
> more complete update was committed having to do it again. I thought it
> looked bad as I was obsoleting the patches and build logs I submitted a
> couple of hours earlier too.
> 
> Had I known about the blanket update I could've rolled that into my updates
> or something, but it was just suddenly there. There was no public warning of
> that change coming (and I did search the relevant lists just to make sure I
> hadn't missed something). Luckily my ports are mostly trivial so the actual
> impact was fairly low, but it still annoyed me and made me feel that it made
> me look bad. It still took extra time to do these simple updates, especially
> once I started wondering what I'd missed to not catch this beforehand. I
> felt rather lucky that I'm quite a low volume maintainer in that regard
> because it could've easily sucked up a lot more of my time.
> 
> On the flipside blanket updates will logically come from people who give far
> more time to this stuff than me. Will they be happy with having to jump
> through hoops for the likes of me? If I'm unhappy about the extra time this
> caused me maybe I'm being unfair in asking them to spend time checking for
> pending updates before doing something. Maybe I just need to suck it up and
> let the big players do their thing.
> 

What you are asking is part of the blanket in particular when changing things in
individual ports, we expect committers to have a look at pending PR (yes I know
I have been guilty of individual port change without sometime checking about
pending PR which was wrong from my side)

For sweeping changes this is a bit different as when a change touches a large
portion of the tree we can not expect the committer to have a look at each
individual ports.

Best regards,
Bapt


signature.asc
Description: PGP signature

Re: blanket portmgr approval vs. non-fixing changes

[Kevin Golding]

On Mon, 27 Jun 2016 21:21:31 +0100, Cy Schubert   
wrote:



In message <57716d89.1050...@sorbs.net>, Michelle Sullivan writes:



Don't forget that many people see their name/email in the maintainer
line as being responsible for the port.. so someone goes makes blanket
changes which actually breaks stuff.. that reflects on the person in the
Maintainer line - whether you want it to do so or not, whether you
believe it or not..


I think it's more than the maintainer perceives that they're responsible.
Getting that email from freebsd-pkg-fallout I think there was and maybe
still is a general impression that is had. I for one take the attitude,  
you
break it, you fix it and I don't hesitate to email any committer who  
made a
blanket change that broke something. It's only fair because fixing  
breakage

caused by others also takes away from other productive work and projects,
as some of us do have time constraints and time pressure due to other
commitments.


I think it goes beyond just breakages though. Recently I had a couple of  
ports to update so I made sure my tree was current first thing in the  
morning, I went through and updated. Then I ran all the build logs etc.  
submitted my patches to bugzilla - and about the same time someone did a  
blanket update of RUN_DEPENDS in my ports. Including a PORTREVISION bump.  
It's easy to argue that's a very trivial change that doesn't needs  
maintainer involvement, but it also impacted my day.


So I updated my tree again and did the whole process again which was  
inconvenient, but I also found myself cringing at any users of the port  
perhaps updating on the PORTREVISION and then a couple of days later when  
my more complete update was committed having to do it again. I thought it  
looked bad as I was obsoleting the patches and build logs I submitted a  
couple of hours earlier too.


Had I known about the blanket update I could've rolled that into my  
updates or something, but it was just suddenly there. There was no public  
warning of that change coming (and I did search the relevant lists just to  
make sure I hadn't missed something). Luckily my ports are mostly trivial  
so the actual impact was fairly low, but it still annoyed me and made me  
feel that it made me look bad. It still took extra time to do these simple  
updates, especially once I started wondering what I'd missed to not catch  
this beforehand. I felt rather lucky that I'm quite a low volume  
maintainer in that regard because it could've easily sucked up a lot more  
of my time.


On the flipside blanket updates will logically come from people who give  
far more time to this stuff than me. Will they be happy with having to  
jump through hoops for the likes of me? If I'm unhappy about the extra  
time this caused me maybe I'm being unfair in asking them to spend time  
checking for pending updates before doing something. Maybe I just need to  
suck it up and let the big players do their thing.


--
Kevin
___
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: Maintaining mono/.net

[Ivan Radovanovic]

On 06/27/2016 20:21, Kurt Jaeger napisa:

Hi!


A couple of us on the freebsd-mono@ mailing list are having a
discussion on how best to maintain the mono ports/.net ports. One of
the things that has come up is maintaining the patches for "all this
stuff". The current paradigm in FreeBSD as I understand it is to use
the files directory and apply the patches to the port via svn/ports
tree. However, with the ubiquity of GitHub in opensource, it now seems
to be feesable to simply create a Github accound to maintain a bunch
of forked repositories (which is essentially a patched git
repository!).


 From my point of view, while not perfect, it sounds reasonable.



We are open for all (good) ideas (good in sense: easier to use, 
requiring less effort to maintain patches) :-)

___
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: Latest MonoDevelop Progress

[Ivan Radovanovic]

On 06/27/2016 18:10, Russell Haley napisa:

 ...
patches, instead of doing it through svn patches. It will make
everything WAY easier to push back upstream. Not that it matters, eh,
Ivan? :0)



I already see who is to be in charge of pushing everything upstream :-P
___
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"