Re: pkg SAT_SOLVER bugs

[Baptiste Daroussin]

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


signature.asc
Description: PGP signature

Re: pkg SAT_SOLVER bugs

[Rodrigo OSORIO]

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

2016Q2 - no Mk/Uses/mysql.mk

[Dan Langille]

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.

Agreed?

-- 
Dan Langille - BSDCan / PGCon
d...@langille.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: USE_PACKAGE_DEPENDS_ONLY set - not building missing dependency from source

[Bryan Drewery]

On 6/27/2016 1:48 PM, Jan Beich wrote:
> Bryan Drewery  writes:
> 
>> On 6/26/16 5:00 AM, Jan Beich wrote:
>>
>>> pkg-fall...@freebsd.org writes:
>>>
 Ident: $FreeBSD: head/multimedia/vapoursynth/Makefile 415615
 2016-05-22 01:10:34Z jbeich $
 Log URL:
 http://beefy5.nyi.freebsd.org/data/101i386-default/417455/logs/vapoursynth-r32.log
 Build URL:  
 http://beefy5.nyi.freebsd.org/build.html?mastername=101i386-default&build=417455
 Log:

 build started at Sat Jun 25 02:32:41 UTC 2016
>>> [...]
 ===
 ===>   vapoursynth-r32 depends on executable: sphinx-build - not found
 ===>   vapoursynth-r32 depends on package: 
 /packages/All/py34-sphinx-1.4.4.txz - not found
 ===>   USE_PACKAGE_DEPENDS_ONLY set - not building missing dependency from 
 source
 *** Error code 1
>>>
>>> I'm starting to get failures for a port that hasn't changed for a month.
>>> Anyone got a clue? The regression appears to be from r417413 which landed
>>> without an exp-run suggesting any fallout is due to badly written ports.
>>>
>>
>> r417413 was the right fix either way as the old code before the
>> do-depends.sh conversion was also passing DEPENDS_ARGS:
>>
>> subpkgfile=`(cd $$dir; ${MAKE} $$depends_args -V PKGFILE)`; \
>>
>> The problem here is a bug in Poudriere not handling DEPENDS_ARGS
>> properly.  The port is forcing python3 as the default even though
>> packages are built with default 2.  Dependencies are only built for
>> python2 and this port wants a python3 dependency.
> 
> sphinx-build is called by gmake, not python, so any python version would
> work fine. Notice, the dependency line doesn't specify PYTHON_PKGNAMEPRIFX.
> 

~/svn/ports/multimedia/vapoursynth # make -V DEPENDS_ARGS
PYTHON_VERSION=python3.4

This means it will force any dependencies of python to build for 3.4.
This happens in any direct usage of ports, including portmaster and
portupgrade.  Poudriere is wrong here to not build a py34-sphynx.

If it really doesn't matter what version it is then the dependency could
be changed to the specific package name of the default python, but ...

PYTHON_USES=python:3.3-

This line forces vapoursynth to be built for 3.4.  Removing the :3.3-
fixes the problem:

~/svn/ports/multimedia/vapoursynth # make -V DEPENDS_ARGS
PYTHON_VERSION=python2.7


>> It's covered in
>> https://github.com/freebsd/poudriere/issues/259.  I've been working on a
>> fix lately and am close to having it complete, which is why I did
>> r417413, because the framework was doing the wrong thing.
> 
> I don't see how that issue would help here.

It helps because you need to understand the DEPENDS_ARGS feature to
understand what's going on here.  It's quite an old feature that
poudriere has failed to support, which causes these
USE_PACKAGE_DEPENDS_ONLY failures.

Note again that the fix I made in r417413 was fixing a regression from
when the dependency handling in Mk/bsd.port.mk was moved to
Mk/Scripts/do-depends.sh.

> 
> py27-sphinx, py34-sphinx, etc. cannot be installed at the same time due
> to a conflict in bin/sphinx-*. If something else installed the port

Right, nothing I'm working on allows installing multiple versions of the
same package at the same time.  I am fixing Poudriere to build multiple
versions of dependencies in its queue, rather then only building the
python2.7 version of dependencies and thus hitting the problem you
mailed about.

> using different python version vapoursynth would fail to build due to
> unsatisfied dependencies.
> 



-- 
Regards,
Bryan Drewery



signature.asc
Description: OpenPGP digital signature

Re: blanket portmgr approval vs. non-fixing changes

[Cy Schubert]

In message <57716d89.1050...@sorbs.net>, Michelle Sullivan writes:
> Kubilay Kocak wrote:
> >
> > All: How did you feel the first time you saw your email on a maintainer
> > line? That is priceless and shouldn't be confused with the 'bad' kind of
> > ownership.
> >
> 
> 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 have no problems with blanket approval as long as everyone understands 
the rules of engagement. I think the maintainer has final say on version 
updates and general structure such as supported options or anything that 
adds additional support requirements. For example, someone submits a PR to 
add option X. Adding option X should require maintainer approval whereas 
implementation of options helpers shouldn't require maintainer approval 
(but if anything breaks, the committer breaking the port should fix it). 
Anything else should be fair game.


-- 
Cheers,
Cy Schubert 
FreeBSD UNIX: Web:  http://www.FreeBSD.org

The need of the many outweighs the greed of the few.


___
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: MariaDB 10.1 doesn't supply my.cnf.* files

[scratch65535]

False alarm -- they're now named my-*.cnf rather than, as I seem
to remember, my.cnf.*  

>Just installed the MariaDB 10.1 package under 10.3, and
>discovered that there are no my.cnf.* files included as was
>standard in the past.  That seems like a regression of sorts.
>___
>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: USE_PACKAGE_DEPENDS_ONLY set - not building missing dependency from source

[Jan Beich]

Bryan Drewery  writes:

> On 6/26/16 5:00 AM, Jan Beich wrote:
>
>> pkg-fall...@freebsd.org writes:
>> 
>>> Ident: $FreeBSD: head/multimedia/vapoursynth/Makefile 415615
>>> 2016-05-22 01:10:34Z jbeich $
>>> Log URL:
>>> http://beefy5.nyi.freebsd.org/data/101i386-default/417455/logs/vapoursynth-r32.log
>>> Build URL:  
>>> http://beefy5.nyi.freebsd.org/build.html?mastername=101i386-default&build=417455
>>> Log:
>>>
>>> build started at Sat Jun 25 02:32:41 UTC 2016
>> [...]
>>> ===
>>> ===>   vapoursynth-r32 depends on executable: sphinx-build - not found
>>> ===>   vapoursynth-r32 depends on package: 
>>> /packages/All/py34-sphinx-1.4.4.txz - not found
>>> ===>   USE_PACKAGE_DEPENDS_ONLY set - not building missing dependency from 
>>> source
>>> *** Error code 1
>> 
>> I'm starting to get failures for a port that hasn't changed for a month.
>> Anyone got a clue? The regression appears to be from r417413 which landed
>> without an exp-run suggesting any fallout is due to badly written ports.
>> 
>
> r417413 was the right fix either way as the old code before the
> do-depends.sh conversion was also passing DEPENDS_ARGS:
>
> subpkgfile=`(cd $$dir; ${MAKE} $$depends_args -V PKGFILE)`; \
>
> The problem here is a bug in Poudriere not handling DEPENDS_ARGS
> properly.  The port is forcing python3 as the default even though
> packages are built with default 2.  Dependencies are only built for
> python2 and this port wants a python3 dependency.

sphinx-build is called by gmake, not python, so any python version would
work fine. Notice, the dependency line doesn't specify PYTHON_PKGNAMEPRIFX.

> It's covered in
> https://github.com/freebsd/poudriere/issues/259.  I've been working on a
> fix lately and am close to having it complete, which is why I did
> r417413, because the framework was doing the wrong thing.

I don't see how that issue would help here.

py27-sphinx, py34-sphinx, etc. cannot be installed at the same time due
to a conflict in bin/sphinx-*. If something else installed the port
using different python version vapoursynth would fail to build due to
unsatisfied dependencies.


signature.asc
Description: PGP signature

Re: blanket portmgr approval vs. non-fixing changes

[Michelle Sullivan]

Kubilay Kocak wrote:


All: How did you feel the first time you saw your email on a maintainer
line? That is priceless and shouldn't be confused with the 'bad' kind of
ownership.



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


Regards,

--
Michelle Sullivan
http://www.mhix.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"

PKG: MariaDB 10.1 doesn't supply my.cnf.* files

[scratch65535]

Just installed the MariaDB 10.1 package under 10.3, and
discovered that there are no my.cnf.* files included as was
standard in the past.  That seems like a regression of sorts.
___
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

[Kurt Jaeger]

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.

-- 
p...@opsec.eu+49 171 3101372 4 years to go !
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Maintaining mono/.net

[Russell Haley]

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!


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: USE_PACKAGE_DEPENDS_ONLY set - not building missing dependency from source

[Bryan Drewery]

On 6/26/16 5:00 AM, Jan Beich wrote:
> pkg-fall...@freebsd.org writes:
> 
>> Ident:  $FreeBSD: head/multimedia/vapoursynth/Makefile 415615 
>> 2016-05-22 01:10:34Z jbeich $
>> Log URL:
>> http://beefy5.nyi.freebsd.org/data/101i386-default/417455/logs/vapoursynth-r32.log
>> Build URL:  
>> http://beefy5.nyi.freebsd.org/build.html?mastername=101i386-default&build=417455
>> Log:
>>
>> build started at Sat Jun 25 02:32:41 UTC 2016
> [...]
>> ===
>> ===>   vapoursynth-r32 depends on executable: sphinx-build - not found
>> ===>   vapoursynth-r32 depends on package: 
>> /packages/All/py34-sphinx-1.4.4.txz - not found
>> ===>   USE_PACKAGE_DEPENDS_ONLY set - not building missing dependency from 
>> source
>> *** Error code 1
> 
> I'm starting to get failures for a port that hasn't changed for a month.
> Anyone got a clue? The regression appears to be from r417413 which landed
> without an exp-run suggesting any fallout is due to badly written ports.
> 

r417413 was the right fix either way as the old code before the
do-depends.sh conversion was also passing DEPENDS_ARGS:

subpkgfile=`(cd $$dir; ${MAKE} $$depends_args -V PKGFILE)`; \

The problem here is a bug in Poudriere not handling DEPENDS_ARGS
properly.  The port is forcing python3 as the default even though
packages are built with default 2.  Dependencies are only built for
python2 and this port wants a python3 dependency.  It's covered in
https://github.com/freebsd/poudriere/issues/259.  I've been working on a
fix lately and am close to having it complete, which is why I did
r417413, because the framework was doing the wrong thing.

net/tiny-network-utilities is another example where this is a problem
and PACKAGE_BUILDING was used to set IGNORE to avoid the problem for now.

-- 
Regards,
Bryan Drewery



signature.asc
Description: OpenPGP digital signature

Re: Latest MonoDevelop Progress

[Russell Haley]

On Mon, Jun 27, 2016 at 5:11 AM, Romain Tartière  wrote:
> On Sun, Jun 26, 2016 at 11:25:06PM -0700, Russell Haley wrote:
>> On Sat, Jun 25, 2016 at 2:48 PM, Carsten Larsen  wrote:
>> > On 25-06-2016, 20:56 Russell Haley wrote:
>> > > I'm unsure to where they get copied.
>> >
>> > [...]
>> >
>> > The Debian package consist of 955 files (and folders):
>> > http://pastebin.com/ATS2M4F7
>>
>> Thanks Carsten, that is the confirmation I needed. Great reference here:
>>
>> https://github.com/gentoo/dotnet/issues/111
>
> In case it helps, there is an old patch for adding
> devel/referenceassemblies-pcl to the ports tree (but installing binaries
> through the ports system is ugly, so I did not pushed it in the official
> ports):
> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=168589&action=edit

Awesome, thanks. Since most (or all) of the mono stuff is in GitHub, I
am liking the idea of creating a project in Github to control all the
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)


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: blanket portmgr approval vs. non-fixing changes (was: svn commit: r417590 - in head/databases/db6: . files and 417595 (revert))

[Cy Schubert]

In message <5770eed4.1070...@tu-dortmund.de>, Matthias Andree writes:
> [Sorry for this re-send, I feel we need to re-send thisto ports@ so the
> discussion goes to a public and archived list.]
> 
> Am 27.06.2016 um 10:16 schrieb Mathieu Arnold:
> > 
> > 
> > +--On 27 juin 2016 16:10:36 +0800 Marcelo Araujo 
> > wrote:
> > | 2016-06-27 16:02 GMT+08:00 Mathieu Arnold :
> > |> | Read here for reference:
> > |> | 
> > |> https://www.freebsd.org/doc/en/books/porters-handbook/makefile-maintaine
> r
> > |> | .html
> > |> 
> > |> That pages says, exactly the opposite of what you are trying to says:
> > |> 
> > | 
> > | No it doesn't!
> > | 
> > | And this is the normal workflow:
> > | 1) Port has a maintainer, and it needs update.
> > | 2) Open a PR with the patch.
> > | 3) After 2 weeks, and with timeout; anybody can commit it.
> > | 
> > | 
> > | And about the ownership and belong to the community, I do believe in that
> ,
> > | that is the basic in a legal point of view.
> > 
> > That page says that the maintainer has to be consulted, except for changes
> > covered by the blanket approval, where the change can be committed
> > immediately.
> > 
> > In this case, Sunpoet had every right to commit the thing he did without
> > asking or notifying the maintainer.
> 
> 
> TL;DR given at the very end.
> 
> 
> 1. Given the portmgr@ rules, that is our current policy, that portmgr@
> as the overseers of the ports system have delegated, by the blanket
> approval, part of their ultimate responsibility to the public.
> 
> 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.
> 
> 
> 2b. This was not the case with db6, the port wasn't known broken to me,
> so why do we permit and encourage going the fast path for changes that
> do not /repair/ a port (for instance, if it's not building, to fix
> misspellings), and I'm surprised because some two months ago, it has
> already gone through a modernization round after gahr's PR,
> , that also
> combined a feature addition and required a bit more work to get right,
> see changesets 415741 and 415743.
> 
> 
> 3. What would have been bad about filing a PR in this case?
> 
> The argument "maintainers aren't doing it" is covered by the maintainer
> timeout.  Anything that does not need the fast path should go through
> some form of review, most naturally through a PR filed to the port's
> maintainer.
> 
> 
> 4. Do we need to tighten up the set of required tests a committed does
> before committing non-maintainer updates?
> 
> I'm scratching my head over this one since the failure in r417590 that
> got remedied in r417595 was rather peculiar, and I'm not sure if anyone,
> including myself, would have figured that out.  It might have slipped
> through the cracks even if I'd reviewed it.
> 
> 4b. It's probably better to extend the committer's guide and/or porter's
> handbook and have a list of test recommendations where we list things
> that trigger a certain test requirement.  I. e. things to test IN
> ADDITION to the usual "poudriere testport" or "make DEVELOPER=yes clean
> all check-plist package" and portlint coverage.  Meaning that if someone
> tweaks any of the WRK* and *DIR/*SRC-related variables, "also test 'make
> clean extract do-patch makepatch' on a copy of the port directory" or
> thereabouts.
> 
> 
> There seem to be at least two distinct camps, in one camp, maintainers
> go along Marcelo's and my trains of thought, in the other, maintainers
> cherish fast and low-ceremony progress, marino has argued along these
> lines, and some other portmgr@ members have pushed for progress in the
> past.
> 
> I don't mean to bikeshed or split up our project here, just refine our
> existing policies.
> 
> 
> TL;DR:  I propose:
> 
> - the blanket approval should be tightened up a bit and encourage that
> non-trivial and non-urgent changes go through the PR and invoke
> mantainer timeout after the shortest possible period.
> 
> - we discuss about an assisting set of "change these variables
> foo.*regexp, and you also need to test 'make foo' and 'make bar'" rules
> in the form of a concise list.

Mathias,

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.


-- 
Cheers,
Cy Schubert 
FreeBSD UNIX: Web:  http://www.FreeBSD.org

The need of the many outweighs the greed of the few.


___
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

[Adam Weinberger]

> On 27 Jun, 2016, at 9:22, Kubilay Kocak  wrote:
> 
> On 28/06/2016 12:25 AM, Adam Weinberger wrote:
>>> On 27 Jun, 2016, at 3:27, Marcelo Araujo 
>>> wrote:
>>> 
>>> 
>>> 
>>> 2016-06-27 16:58 GMT+08:00 Matthias Andree
>>> : Am 27.06.2016 um 10:16 schrieb
>>> Mathieu Arnold:
 
 
 +--On 27 juin 2016 16:10:36 +0800 Marcelo Araujo
  wrote: | 2016-06-27 16:02 GMT+08:00
 Mathieu Arnold : |> | Read here for reference: 
 |> | |>
 https://www.freebsd.org/doc/en/books/porters-handbook/makefile-maintainer
 
 
> |> | .html
 |> |> That pages says, exactly the opposite of what you are
 trying to says: |> | | No it doesn't! | | And this is the normal
 workflow: | 1) Port has a maintainer, and it needs update. | 2)
 Open a PR with the patch. | 3) After 2 weeks, and with timeout;
 anybody can commit it. | | | And about the ownership and belong
 to the community, I do believe in that, | that is the basic in a
 legal point of view.
 
 That page says that the maintainer has to be consulted, except
 for changes covered by the blanket approval, where the change can
 be committed immediately.
 
 In this case, Sunpoet had every right to commit the thing he did
 without asking or notifying the maintainer.
>>> 
>>> 
>>> TL;DR given at the very end.
>>> 
>>> 
>>> 1. Given the portmgr@ rules, that is our current policy, that
>>> portmgr@ as the overseers of the ports system have delegated, by
>>> the blanket approval, part of their ultimate responsibility to the
>>> public.
>>> 
>>> 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.
>>> 
>>> 
>>> 2b. This was not the case with db6, the port wasn't known broken to
>>> me, so why do we permit and encourage going the fast path for
>>> changes that do not /repair/ a port (for instance, if it's not
>>> building, to fix misspellings), and I'm surprised because some two
>>> months ago, it has already gone through a modernization round after
>>> gahr's PR, 
>>> , that
>>> also combined a feature addition and required a bit more work to
>>> get right, see changesets 415741 and 415743.
>>> 
>>> 
>>> 3. What would have been bad about filing a PR in this case?
>>> 
>>> The argument "maintainers aren't doing it" is covered by the
>>> maintainer timeout.  Anything that does not need the fast path
>>> should go through some form of review, most naturally through a PR
>>> filed to the port's maintainer.
>>> 
>>> 
>>> 4. Do we need to tighten up the set of required tests a committed
>>> does before committing non-maintainer updates?
>>> 
>>> I'm scratching my head over this one since the failure in r417590
>>> that got remedied in r417595 was rather peculiar, and I'm not sure
>>> if anyone, including myself, would have figured that out.  It might
>>> have slipped through the cracks even if I'd reviewed it.
>>> 
>>> 4b. It's probably better to extend the committer's guide and/or
>>> porter's handbook and have a list of test recommendations where we
>>> list things that trigger a certain test requirement.  I. e. things
>>> to test IN ADDITION to the usual "poudriere testport" or "make
>>> DEVELOPER=yes clean all check-plist package" and portlint coverage.
>>> Meaning that if someone tweaks any of the WRK* and
>>> *DIR/*SRC-related variables, "also test 'make clean extract
>>> do-patch makepatch' on a copy of the port directory" or 
>>> thereabouts.
>>> 
>>> mat@ thanks for all the explanation and time.
>>> 
>>> Unfortunately, I still make things a bit manual at my side, but
>>> usually my testbed is: 1) Portlint. 2) Make and likes on i386 and
>>> amd64(clean vm).
>>> 
>>> I think, include more information about test recommendations is
>>> always good.
>>> 
>>> 
>>> 
>>> There seem to be at least two distinct camps, in one camp,
>>> maintainers go along Marcelo's and my trains of thought, in the
>>> other, maintainers cherish fast and low-ceremony progress, marino
>>> has argued along these lines, and some other portmgr@ members have
>>> pushed for progress in the past.
>>> 
>>> I don't mean to bikeshed or split up our project here, just refine
>>> our existing policies.
>>> 
>>> 
>>> TL;DR:  I propose:
>>> 
>>> - the blanket approval should be tightened up a bit and encourage
>>> that non-trivial and non-urgent changes go through the PR and
>>> invoke mantainer timeout after the shortest possible period.
>>> 
>>> Personally, I like the first option! And in addition, we have
>>> phabricator as an option too, at least for src, the reviews are
>>> made very quickly. So, could be defined a short timeout, at least
>>> for those that are active and would like to help make a review,
>>> seems something reasonable.
>>> 
>>> Also I do understand about all the modernization and definitely we
>>> need it, maybe 2 days timeou

Re: blanket portmgr approval vs. non-fixing changes

[Kubilay Kocak]

On 28/06/2016 12:25 AM, Adam Weinberger wrote:
>> On 27 Jun, 2016, at 3:27, Marcelo Araujo 
>> wrote:
>> 
>> 
>> 
>> 2016-06-27 16:58 GMT+08:00 Matthias Andree
>> : Am 27.06.2016 um 10:16 schrieb
>> Mathieu Arnold:
>>> 
>>> 
>>> +--On 27 juin 2016 16:10:36 +0800 Marcelo Araujo
>>>  wrote: | 2016-06-27 16:02 GMT+08:00
>>> Mathieu Arnold : |> | Read here for reference: 
>>> |> | |>
>>> https://www.freebsd.org/doc/en/books/porters-handbook/makefile-maintainer
>>>
>>> 
|> | .html
>>> |> |> That pages says, exactly the opposite of what you are
>>> trying to says: |> | | No it doesn't! | | And this is the normal
>>> workflow: | 1) Port has a maintainer, and it needs update. | 2)
>>> Open a PR with the patch. | 3) After 2 weeks, and with timeout;
>>> anybody can commit it. | | | And about the ownership and belong
>>> to the community, I do believe in that, | that is the basic in a
>>> legal point of view.
>>> 
>>> That page says that the maintainer has to be consulted, except
>>> for changes covered by the blanket approval, where the change can
>>> be committed immediately.
>>> 
>>> In this case, Sunpoet had every right to commit the thing he did
>>> without asking or notifying the maintainer.
>> 
>> 
>> TL;DR given at the very end.
>> 
>> 
>> 1. Given the portmgr@ rules, that is our current policy, that
>> portmgr@ as the overseers of the ports system have delegated, by
>> the blanket approval, part of their ultimate responsibility to the
>> public.
>> 
>> 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.
>> 
>> 
>> 2b. This was not the case with db6, the port wasn't known broken to
>> me, so why do we permit and encourage going the fast path for
>> changes that do not /repair/ a port (for instance, if it's not
>> building, to fix misspellings), and I'm surprised because some two
>> months ago, it has already gone through a modernization round after
>> gahr's PR, 
>> , that
>> also combined a feature addition and required a bit more work to
>> get right, see changesets 415741 and 415743.
>> 
>> 
>> 3. What would have been bad about filing a PR in this case?
>> 
>> The argument "maintainers aren't doing it" is covered by the
>> maintainer timeout.  Anything that does not need the fast path
>> should go through some form of review, most naturally through a PR
>> filed to the port's maintainer.
>> 
>> 
>> 4. Do we need to tighten up the set of required tests a committed
>> does before committing non-maintainer updates?
>> 
>> I'm scratching my head over this one since the failure in r417590
>> that got remedied in r417595 was rather peculiar, and I'm not sure
>> if anyone, including myself, would have figured that out.  It might
>> have slipped through the cracks even if I'd reviewed it.
>> 
>> 4b. It's probably better to extend the committer's guide and/or
>> porter's handbook and have a list of test recommendations where we
>> list things that trigger a certain test requirement.  I. e. things
>> to test IN ADDITION to the usual "poudriere testport" or "make
>> DEVELOPER=yes clean all check-plist package" and portlint coverage.
>> Meaning that if someone tweaks any of the WRK* and
>> *DIR/*SRC-related variables, "also test 'make clean extract
>> do-patch makepatch' on a copy of the port directory" or 
>> thereabouts.
>> 
>> mat@ thanks for all the explanation and time.
>> 
>> Unfortunately, I still make things a bit manual at my side, but
>> usually my testbed is: 1) Portlint. 2) Make and likes on i386 and
>> amd64(clean vm).
>> 
>> I think, include more information about test recommendations is
>> always good.
>> 
>> 
>> 
>> There seem to be at least two distinct camps, in one camp,
>> maintainers go along Marcelo's and my trains of thought, in the
>> other, maintainers cherish fast and low-ceremony progress, marino
>> has argued along these lines, and some other portmgr@ members have
>> pushed for progress in the past.
>> 
>> I don't mean to bikeshed or split up our project here, just refine
>> our existing policies.
>> 
>> 
>> TL;DR:  I propose:
>> 
>> - the blanket approval should be tightened up a bit and encourage
>> that non-trivial and non-urgent changes go through the PR and
>> invoke mantainer timeout after the shortest possible period.
>> 
>> Personally, I like the first option! And in addition, we have
>> phabricator as an option too, at least for src, the reviews are
>> made very quickly. So, could be defined a short timeout, at least
>> for those that are active and would like to help make a review,
>> seems something reasonable.
>> 
>> Also I do understand about all the modernization and definitely we
>> need it, maybe 2 days timeout is enough for an active maintainer to
>> reply that he is busy or he is working on that.
>> 
>> 
>> 
>> - we discuss about an assisting set of "change these variables 
>> foo

Re: blanket portmgr approval vs. non-fixing changes (was: svn commit: r417590 - in head/databases/db6: . files and 417595 (revert))

[Kurt Jaeger]

Hi!

[adamw]
> Maintainership too often means that change requests get ignored
> for two weeks before they're committed.

That is the case sometimes, yes.

But oftern maintainership provides identification with the project
and proud of achievement etc, which causes people to invest time
and skills in the project.

Maintainership also provides a point of contact that one can ask
for run-tests or for additional experience some potential port
user can contact. It provides 'community'.

> Aside from large, complex, interconnected systems, I think that
> we should do away with ports maintainership entirely. Maintainership
> serves absolutely no purpose that peer-review wouldn't do better.

If we add to the role of the maintainer the wish from the ports community
to the maintainer that she/he provides some run-test environment and
practical (daily?) experience with a port, that would definitly be
positive. Not all ports would need maintainers, if the role changes
like that.

> Any committer should be able to commit to any port. That used to
> be what po...@freebsd.org meant, that it was being maintained by
> everybody.

For complex ports, we do not always have committers that have
run-test resources.

For those it's good to have some maintainer.

> But somehow, in the last few years that turned into a
> message that it's being maintained by nobody, so now ports *have*
> to be maintained by somebody, even if that person never touches it
> again.

The queue of uncommitted ports PRs shows that it's not always
the maintainers that are the bottle-neck, sometimes it's the committers.

-- 
p...@freebsd.org +49 171 31013724 years to go !
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: blanket portmgr approval vs. non-fixing changes (was: svn commit: r417590 - in head/databases/db6: . files and 417595 (revert))

[Adam Weinberger]

> On 27 Jun, 2016, at 3:27, Marcelo Araujo  wrote:
> 
> 
> 
> 2016-06-27 16:58 GMT+08:00 Matthias Andree :
> Am 27.06.2016 um 10:16 schrieb Mathieu Arnold:
> >
> >
> > +--On 27 juin 2016 16:10:36 +0800 Marcelo Araujo 
> > wrote:
> > | 2016-06-27 16:02 GMT+08:00 Mathieu Arnold :
> > |> | Read here for reference:
> > |> |
> > |> https://www.freebsd.org/doc/en/books/porters-handbook/makefile-maintainer
> > |> | .html
> > |>
> > |> That pages says, exactly the opposite of what you are trying to says:
> > |>
> > |
> > | No it doesn't!
> > |
> > | And this is the normal workflow:
> > | 1) Port has a maintainer, and it needs update.
> > | 2) Open a PR with the patch.
> > | 3) After 2 weeks, and with timeout; anybody can commit it.
> > |
> > |
> > | And about the ownership and belong to the community, I do believe in that,
> > | that is the basic in a legal point of view.
> >
> > That page says that the maintainer has to be consulted, except for changes
> > covered by the blanket approval, where the change can be committed
> > immediately.
> >
> > In this case, Sunpoet had every right to commit the thing he did without
> > asking or notifying the maintainer.
> 
> 
> TL;DR given at the very end.
> 
> 
> 1. Given the portmgr@ rules, that is our current policy, that portmgr@
> as the overseers of the ports system have delegated, by the blanket
> approval, part of their ultimate responsibility to the public.
> 
> 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.
> 
> 
> 2b. This was not the case with db6, the port wasn't known broken to me,
> so why do we permit and encourage going the fast path for changes that
> do not /repair/ a port (for instance, if it's not building, to fix
> misspellings), and I'm surprised because some two months ago, it has
> already gone through a modernization round after gahr's PR,
> , that also
> combined a feature addition and required a bit more work to get right,
> see changesets 415741 and 415743.
> 
> 
> 3. What would have been bad about filing a PR in this case?
> 
> The argument "maintainers aren't doing it" is covered by the maintainer
> timeout.  Anything that does not need the fast path should go through
> some form of review, most naturally through a PR filed to the port's
> maintainer.
> 
> 
> 4. Do we need to tighten up the set of required tests a committed does
> before committing non-maintainer updates?
> 
> I'm scratching my head over this one since the failure in r417590 that
> got remedied in r417595 was rather peculiar, and I'm not sure if anyone,
> including myself, would have figured that out.  It might have slipped
> through the cracks even if I'd reviewed it.
> 
> 4b. It's probably better to extend the committer's guide and/or porter's
> handbook and have a list of test recommendations where we list things
> that trigger a certain test requirement.  I. e. things to test IN
> ADDITION to the usual "poudriere testport" or "make DEVELOPER=yes clean
> all check-plist package" and portlint coverage.  Meaning that if someone
> tweaks any of the WRK* and *DIR/*SRC-related variables, "also test 'make
> clean extract do-patch makepatch' on a copy of the port directory" or
> thereabouts.
> 
> mat@ thanks for all the explanation and time.
> 
> Unfortunately, I still make things a bit manual at my side, but usually my 
> testbed is:
> 1) Portlint.
> 2) Make and likes on i386 and amd64(clean vm).
> 
> I think, include more information about test recommendations is always good.
>  
> 
> 
> There seem to be at least two distinct camps, in one camp, maintainers
> go along Marcelo's and my trains of thought, in the other, maintainers
> cherish fast and low-ceremony progress, marino has argued along these
> lines, and some other portmgr@ members have pushed for progress in the
> past.
> 
> I don't mean to bikeshed or split up our project here, just refine our
> existing policies.
> 
> 
> TL;DR:  I propose:
> 
> - the blanket approval should be tightened up a bit and encourage that
> non-trivial and non-urgent changes go through the PR and invoke
> mantainer timeout after the shortest possible period.
> 
> Personally, I like the first option! And in addition, we have phabricator as 
> an option too, at least for src, the reviews are made very quickly.
> So, could be defined a short timeout, at least for those that are active and 
> would like to help make a review, seems something reasonable.
> 
> Also I do understand about all the modernization and definitely we need it, 
> maybe 2 days timeout is enough for an active maintainer to reply that he is 
> busy or he is working on that. 
>  
>  
> 
> - we discuss about an assisting set of "change these variables
> foo.*regexp, and you also need to test 'make foo' and 'make bar'" rules
> in the form of a concise list.

Maintainership too often mea

Re: ! mDNSResponder Port update Error

[Pietro Cerutti]

On 2016-06-27 14:19, JosC wrote:

[mDNSResponder-576.30.xx]


Can you please update your ports tree and try again? mDNSResponder has 
recently been updated to 625.41.2.




Dear portmaintainer,

Just got an error on installing latest version of DNSResponder:

../mDNSShared/dnsextd_lexer.l: In function 'yylex':
../mDNSShared/dnsextd_lexer.l:77: error: 'yylineno' undeclared (first
use in this function)
../mDNSShared/dnsextd_lexer.l:77: error: (Each undeclared identifier
is reported only once
../mDNSShared/dnsextd_lexer.l:77: error: for each function it appears 
in.)

gmake: *** [Makefile:527: objects/prod/dnsextd_lexer.l.o] Error 1
*** [do-build] Error code 1

Stop in /usr/ports/net/mDNSResponder.

--- cut ---

Can you advise how to solve this issue?

Thanksand keep up the good work!

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


--
Pietro Cerutti
g...@freebsd.org

PGP Public Key:
http://gahr.ch/pgp
___
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"

! mDNSResponder Port update Error

[JosC]

[mDNSResponder-576.30.xx]

Dear portmaintainer,

Just got an error on installing latest version of DNSResponder:

../mDNSShared/dnsextd_lexer.l: In function 'yylex':
../mDNSShared/dnsextd_lexer.l:77: error: 'yylineno' undeclared (first 
use in this function)
../mDNSShared/dnsextd_lexer.l:77: error: (Each undeclared identifier is 
reported only once

../mDNSShared/dnsextd_lexer.l:77: error: for each function it appears in.)
gmake: *** [Makefile:527: objects/prod/dnsextd_lexer.l.o] Error 1
*** [do-build] Error code 1

Stop in /usr/ports/net/mDNSResponder.

--- cut ---

Can you advise how to solve this issue?

Thanksand keep up the good work!

Jos Chrispijn
___
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 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

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 :-)

Nice! Can you report upstream @ https://github.com/freebsd/pkg if you
haven't already

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

pkg SAT_SOLVER bugs

[Hans Petter Selasky]

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
--- ./work/pkg-1.8.99.6/libpkg/pkg_solve.c.orig	2016-06-27 10:32:46.11981 +0200
+++ ./work/pkg-1.8.99.6/libpkg/pkg_solve.c	2016-06-27 12:28:07.901757000 +0200
@@ -118,8 +118,6 @@
 #define PKG_SOLVE_CHECK_ITEM(item)\
 	((item)->var->to_install ^ (item)->inverse)
 
-#define PKG_SOLVE_VAR_NEXT(a, e) ((e) == NULL ? &a[0] : (e + 1))
-
 /*
  * Utilities to convert jobs to SAT rule
  */
@@ -1302,45 +1300,23 @@
 	fprintf(file, "}\n");
 }
 
-struct pkg_solve_ordered_variable {
-	struct pkg_solve_variable *var;
-	int order;
-	UT_hash_handle hh;
-};
-
 int
 pkg_solve_dimacs_export(struct pkg_solve_problem *problem, FILE *f)
 {
-	struct pkg_solve_ordered_variable *ordered_variables = NULL, *nord;
-	struct pkg_solve_variable *var;
 	struct pkg_solve_rule *rule;
 	struct pkg_solve_item *it;
-	int cur_ord = 1;
-
-	/* Order variables */
-	var = NULL;
-	while ((var = PKG_SOLVE_VAR_NEXT(problem->variables, var))) {
-		nord = calloc(1, sizeof(struct pkg_solve_ordered_variable));
-		nord->order = cur_ord ++;
-		nord->var = var;
-		HASH_ADD_PTR(ordered_variables, var, nord);
-	}
 
 	fprintf(f, "p cnf %d %zu\n", (int)problem->nvars, kv_size(problem->rules));
 
 	for (unsigned int i = 0; i < kv_size(problem->rules); i++) {
 		rule = kv_A(problem->rules, i);
 		LL_FOREACH(rule->items, it) {
-			HASH_FIND_PTR(ordered_variables, &it->var, nord);
-			if (nord != NULL) {
-fprintf(f, "%s%d ", (it->inverse ? "-" : ""), nord->order);
-			}
+			size_t order = it->var - problem->variables;
+			if (order < problem->nvars)
+fprintf(f, "%ld ", (long)((order + 1) * it->inverse));
 		}
 		fprintf(f, "0\n");
 	}
-
-	HASH_FREE(ordered_variables, free);
-
 	return (EPKG_OK);
 }
 
@@ -1443,26 +1419,42 @@
 	return (EPKG_OK);
 }
 
+static bool
+pkg_solve_parse_sat_output_store(struct pkg_solve_problem *problem, const char *var_str)
+{
+	struct pkg_solve_variable *var;
+	ssize_t order;
+
+	order = strtol(var_str, NULL, 10);
+	if (order == 0)
+		return (true);
+	if (order < 0) {
+		/* negative value means false */
+		order = - order - 1;
+		if ((size_t)order < problem->nvars) {
+			var = problem->variables + order;
+			var->flags &= ~PKG_VAR_INSTALL;
+		}
+	} else {
+		/* positive value means true */
+		order = order - 1;
+		if ((size_t)order < problem->nvars) {
+			var = problem->variables + order;
+			var->flags |= PKG_VAR_INSTALL;
+		}
+	}
+	return (false);
+}
+
 int
 pkg_solve_parse_sat_output(FILE *f, struct pkg_solve_problem *problem)
 {
-	struct pkg_solve_ordered_variable *ordered_variables = NULL, *nord;
-	struct pkg_solve_variable *var;
-	int cur_ord = 1, ret = EPKG_OK;
+	int ret = EPKG_OK;
 	char *line = NULL, *var_str, *begin;
 	size_t linecap = 0;
 	ssize_t linelen;
 	bool got_sat = false, done = false;
 
-	/* Order variables */
-	var = NULL;
-	while ((var = PKG_SOLVE_VAR_NEXT(problem->variables, var))) {
-		nord = calloc(1, sizeof(struct pkg_solve_ordered_variable));
-		nord->order = cur_ord ++;
-		nord->var = var;
-		HASH_ADD_INT(ordered_variables, order, nord);
-	}
-
 	while ((linelen = getline(&line, &linecap, f)) > 0) {
 		if (strncmp(line, "SAT", 3) == 0) {
 			got_sat = true;
@@ -1474,22 +1466,8 @@
 /* Skip unexpected lines */
 if (var_str == NULL || (!isdigit(*var_str) && *var_str != '-'))
 	continue;
-cur_ord = 0;
-cur_ord = abs((int)strtol(var_str, NULL, 10));
-if (cur_ord == 0) {
+if (pkg_solve_parse_sat_output_store(problem, var_str))
 	done = true;
-	break;
-}
-
-HASH_FIND_INT(ordered_variables, &cur_ord, nord);
-if (nord != NULL) {
-	if (*var_str == '-') {
-		nord->var->flags &= ~PKG_VAR_INSTALL;
-	}
-	else {
-		nord->var->flags |= PKG_VAR_INSTALL;
-	}
-}
 			} while (begin != NULL);
 		}
 		else if (strncmp(line, "v ", 2) == 0) {
@@ -1499,23 +1477,8 @@
 /* Skip unexpected lines */
 if (var_str == NULL || (!isdigit(*var_str) && *var_str != '-'))
 	continue;
-cur_ord = 0;
-cur_ord = abs((int)strtol(var_str, NULL, 10));
-if (cur_ord == 0) {
+if (pkg_solve_parse_sat_output_store(problem, var_str))
 	done = true;
-	break;
-}
-
-HASH_FIND_INT(ordered_variables, &cur_ord, nord);
-
-if (nord != NULL) {
-	if (*var_str == '-') {
-		nord->var->flags &= ~PKG_VAR_INSTALL;
-	}
-	else {
-		nord->var->flags |= PKG_VAR_INSTALL;
-	}
-}
 			} while (begin != NULL);
 		}
 		else {
@@ -1531,7 +1494,6 @@
 		ret = EPK

Re: blanket portmgr approval vs. non-fixing changes

[Guido Falsi]

On 06/27/16 11:16, Matthias Andree wrote:
> [Sorry for this re-send, I feel we need to re-send thisto ports@ so the
> discussion goes to a public and archived list.]
> 
> Am 27.06.2016 um 10:16 schrieb Mathieu Arnold:
>>
>>
>> +--On 27 juin 2016 16:10:36 +0800 Marcelo Araujo 
>> wrote:
>> | 2016-06-27 16:02 GMT+08:00 Mathieu Arnold :
>> |> | Read here for reference:
>> |> | 
>> |> https://www.freebsd.org/doc/en/books/porters-handbook/makefile-maintainer
>> |> | .html
>> |> 
>> |> That pages says, exactly the opposite of what you are trying to says:
>> |> 
>> | 
>> | No it doesn't!
>> | 
>> | And this is the normal workflow:
>> | 1) Port has a maintainer, and it needs update.
>> | 2) Open a PR with the patch.
>> | 3) After 2 weeks, and with timeout; anybody can commit it.
>> | 
>> | 
>> | And about the ownership and belong to the community, I do believe in that,
>> | that is the basic in a legal point of view.
>>
>> That page says that the maintainer has to be consulted, except for changes
>> covered by the blanket approval, where the change can be committed
>> immediately.
>>
>> In this case, Sunpoet had every right to commit the thing he did without
>> asking or notifying the maintainer.
> 
> 
> TL;DR given at the very end.
> 
> 
> 1. Given the portmgr@ rules, that is our current policy, that portmgr@
> as the overseers of the ports system have delegated, by the blanket
> approval, part of their ultimate responsibility to the public.
> 
> 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).


> 3. What would have been bad about filing a PR in this case?
> 
> The argument "maintainers aren't doing it" is covered by the maintainer
> timeout.  Anything that does not need the fast path should go through
> some form of review, most naturally through a PR filed to the port's
> maintainer.
> 

I agree with this, if there is no urgency there's no need to leverage a
blanket.

> TL;DR:  I propose:
> 
> - the blanket approval should be tightened up a bit and encourage that
> non-trivial and non-urgent changes go through the PR and invoke
> mantainer timeout after the shortest possible period.

I agree on adding a note on the blankets encouraging patches to go
through a PR whenever they are not urgent. This raises the problem of
having a good definition of urgent. I have stated above what I think is
urgent.

I'd like to add that changes to the ports infrastructure aren't always
urgent, the general blanket was created at a time when a lot of things
were changing in the ports tree and there was a need for a fast
application of those changes, since the state of the tree was hindering
progress.

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.


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.

> 
> - we discuss about an assisting set of "change these variables
> foo.*regexp, and you also need to test 'make foo' and 'make bar'" rules
> in the form of a concise list.

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.

-- 
Guido Falsi 
___
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
+-+
graphics/netpbm | 10.35.98| 10.47.62
+-+


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"

Re: blanket portmgr approval vs. non-fixing changes (was: svn commit: r417590 - in head/databases/db6: . files and 417595 (revert))

[Marcelo Araujo]

2016-06-27 16:58 GMT+08:00 Matthias Andree :

> Am 27.06.2016 um 10:16 schrieb Mathieu Arnold:
> >
> >
> > +--On 27 juin 2016 16:10:36 +0800 Marcelo Araujo <
> araujobsdp...@gmail.com>
> > wrote:
> > | 2016-06-27 16:02 GMT+08:00 Mathieu Arnold :
> > |> | Read here for reference:
> > |> |
> > |>
> https://www.freebsd.org/doc/en/books/porters-handbook/makefile-maintainer
> > |> | .html
> > |>
> > |> That pages says, exactly the opposite of what you are trying to says:
> > |>
> > |
> > | No it doesn't!
> > |
> > | And this is the normal workflow:
> > | 1) Port has a maintainer, and it needs update.
> > | 2) Open a PR with the patch.
> > | 3) After 2 weeks, and with timeout; anybody can commit it.
> > |
> > |
> > | And about the ownership and belong to the community, I do believe in
> that,
> > | that is the basic in a legal point of view.
> >
> > That page says that the maintainer has to be consulted, except for
> changes
> > covered by the blanket approval, where the change can be committed
> > immediately.
> >
> > In this case, Sunpoet had every right to commit the thing he did without
> > asking or notifying the maintainer.
>
>
> TL;DR given at the very end.
>
>
> 1. Given the portmgr@ rules, that is our current policy, that portmgr@
> as the overseers of the ports system have delegated, by the blanket
> approval, part of their ultimate responsibility to the public.
>
> 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.
>
>
> 2b. This was not the case with db6, the port wasn't known broken to me,
> so why do we permit and encourage going the fast path for changes that
> do not /repair/ a port (for instance, if it's not building, to fix
> misspellings), and I'm surprised because some two months ago, it has
> already gone through a modernization round after gahr's PR,
> , that also
> combined a feature addition and required a bit more work to get right,
> see changesets 415741 and 415743.
>
>
> 3. What would have been bad about filing a PR in this case?
>
> The argument "maintainers aren't doing it" is covered by the maintainer
> timeout.  Anything that does not need the fast path should go through
> some form of review, most naturally through a PR filed to the port's
> maintainer.
>
>
> 4. Do we need to tighten up the set of required tests a committed does
> before committing non-maintainer updates?
>
> I'm scratching my head over this one since the failure in r417590 that
> got remedied in r417595 was rather peculiar, and I'm not sure if anyone,
> including myself, would have figured that out.  It might have slipped
> through the cracks even if I'd reviewed it.
>
> 4b. It's probably better to extend the committer's guide and/or porter's
> handbook and have a list of test recommendations where we list things
> that trigger a certain test requirement.  I. e. things to test IN
> ADDITION to the usual "poudriere testport" or "make DEVELOPER=yes clean
> all check-plist package" and portlint coverage.  Meaning that if someone
> tweaks any of the WRK* and *DIR/*SRC-related variables, "also test 'make
> clean extract do-patch makepatch' on a copy of the port directory" or
> thereabouts.
>

mat@ thanks for all the explanation and time.

Unfortunately, I still make things a bit manual at my side, but usually my
testbed is:
1) Portlint.
2) Make and likes on i386 and amd64(clean vm).

I think, include more information about test recommendations is always good.


>
>
> There seem to be at least two distinct camps, in one camp, maintainers
> go along Marcelo's and my trains of thought, in the other, maintainers
> cherish fast and low-ceremony progress, marino has argued along these
> lines, and some other portmgr@ members have pushed for progress in the
> past.
>
> I don't mean to bikeshed or split up our project here, just refine our
> existing policies.
>

>
> TL;DR:  I propose:
>
> - the blanket approval should be tightened up a bit and encourage that
> non-trivial and non-urgent changes go through the PR and invoke
> mantainer timeout after the shortest possible period.
>

Personally, I like the first option! And in addition, we have phabricator
as an option too, at least for src, the reviews are made very quickly.
So, could be defined a short timeout, at least for those that are active
and would like to help make a review, seems something reasonable.

Also I do understand about all the modernization and definitely we need it,
maybe 2 days timeout is enough for an active maintainer to reply that he is
busy or he is working on that.



>
> - we discuss about an assisting set of "change these variables
> foo.*regexp, and you also need to test 'make foo' and 'make bar'" rules
> in the form of a concise list.
>
>

Thanks,
-- 

-- 
Marcelo Araujo(__)ara...@freebsd.org
\\\'',)http://www.FreeBSD.org 

blanket portmgr approval vs. non-fixing changes (was: svn commit: r417590 - in head/databases/db6: . files and 417595 (revert))

[Matthias Andree]

[Sorry for this re-send, I feel we need to re-send thisto ports@ so the
discussion goes to a public and archived list.]

Am 27.06.2016 um 10:16 schrieb Mathieu Arnold:
> 
> 
> +--On 27 juin 2016 16:10:36 +0800 Marcelo Araujo 
> wrote:
> | 2016-06-27 16:02 GMT+08:00 Mathieu Arnold :
> |> | Read here for reference:
> |> | 
> |> https://www.freebsd.org/doc/en/books/porters-handbook/makefile-maintainer
> |> | .html
> |> 
> |> That pages says, exactly the opposite of what you are trying to says:
> |> 
> | 
> | No it doesn't!
> | 
> | And this is the normal workflow:
> | 1) Port has a maintainer, and it needs update.
> | 2) Open a PR with the patch.
> | 3) After 2 weeks, and with timeout; anybody can commit it.
> | 
> | 
> | And about the ownership and belong to the community, I do believe in that,
> | that is the basic in a legal point of view.
> 
> That page says that the maintainer has to be consulted, except for changes
> covered by the blanket approval, where the change can be committed
> immediately.
> 
> In this case, Sunpoet had every right to commit the thing he did without
> asking or notifying the maintainer.


TL;DR given at the very end.


1. Given the portmgr@ rules, that is our current policy, that portmgr@
as the overseers of the ports system have delegated, by the blanket
approval, part of their ultimate responsibility to the public.

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.


2b. This was not the case with db6, the port wasn't known broken to me,
so why do we permit and encourage going the fast path for changes that
do not /repair/ a port (for instance, if it's not building, to fix
misspellings), and I'm surprised because some two months ago, it has
already gone through a modernization round after gahr's PR,
, that also
combined a feature addition and required a bit more work to get right,
see changesets 415741 and 415743.


3. What would have been bad about filing a PR in this case?

The argument "maintainers aren't doing it" is covered by the maintainer
timeout.  Anything that does not need the fast path should go through
some form of review, most naturally through a PR filed to the port's
maintainer.


4. Do we need to tighten up the set of required tests a committed does
before committing non-maintainer updates?

I'm scratching my head over this one since the failure in r417590 that
got remedied in r417595 was rather peculiar, and I'm not sure if anyone,
including myself, would have figured that out.  It might have slipped
through the cracks even if I'd reviewed it.

4b. It's probably better to extend the committer's guide and/or porter's
handbook and have a list of test recommendations where we list things
that trigger a certain test requirement.  I. e. things to test IN
ADDITION to the usual "poudriere testport" or "make DEVELOPER=yes clean
all check-plist package" and portlint coverage.  Meaning that if someone
tweaks any of the WRK* and *DIR/*SRC-related variables, "also test 'make
clean extract do-patch makepatch' on a copy of the port directory" or
thereabouts.


There seem to be at least two distinct camps, in one camp, maintainers
go along Marcelo's and my trains of thought, in the other, maintainers
cherish fast and low-ceremony progress, marino has argued along these
lines, and some other portmgr@ members have pushed for progress in the
past.

I don't mean to bikeshed or split up our project here, just refine our
existing policies.


TL;DR:  I propose:

- the blanket approval should be tightened up a bit and encourage that
non-trivial and non-urgent changes go through the PR and invoke
mantainer timeout after the shortest possible period.

- we discuss about an assisting set of "change these variables
foo.*regexp, and you also need to test 'make foo' and 'make bar'" rules
in the form of a concise list.


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