Re: [RFC] Why FreeBSD ports should have branches by OS version

[Grzegorz Junka]

On 27/06/2017 17:45, Mark Linimon wrote:

On Tue, Jun 27, 2017 at 09:24:31AM -0400, scratch65...@att.net wrote:

The number of ports to build a server-of-all-work is not large.

Now the problem is getting people to agree on exactly what that
subset is.


I think this part is fairly easy. We can start with ports for which 
maintainers agree to provide security fixes to the stable branch or 
artificially limit the number and ask people to vote for their 
favourites. Another point for consideration is to firstly consider ports 
with smaller amount of dependencies so that there is less work in 
maintaining them.

No one has ever done the work on "most minimal set of dependencies"
in the ports tree -- and that's because it's hard work.  Add to that
the fact that the technology has never supported partial checkouts
and it complicates things.


Yes, but you need to start somewhere. Otherwise it will remain as 
occasional rant. Clearly starting with 26,000 isn't an option. Then 
starting with small number of ports and learning how to overcome these 
difficulties is best we can do.



tl;dr: I do have long-time experience building subsets of the ports
tree and in my experience it's harder than people think, once you
get beyond a few dozen targets.



I think the hardest part is to agree on a set that is not too difficult 
to maintain but still useful so that people will try to actually install 
systems using them.


Grzegorz
___
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: [RFC] Why FreeBSD ports should have branches by OS version

[Mark Linimon]

On Tue, Jun 27, 2017 at 04:53:36PM -0400, scratch65...@att.net wrote:
> Since that's what I integrate for my dev use, I'd be happy to
> take a zero'th-order cut at defining it, if nobody else wants to.

Fine.  See http://www.lonesome.com/FreeBSD/poudriere/subsets/ for what
I use.  I'm not particularly interested in maintaining it as a general
set of files, but if someone can build on it, fine.

> By "unnecessary", Mark, I mean the fact that the bits are not
> controlled locally, and thus potentially change from moment to
> moment such that it's impossible to guarantee that two people
> building the same app with the same options on two different
> days, or even hours, will get the same result.

I don't understand this.

The distinfo mechanism is the solution for this problem for released
code.

If people are relying on "whatever is in git at the moment" to
mean "release", well then that's upstream not understanding what
is meant by "release".  Either educated them or fork their code
and become the new upstream.

> Switching to a central repository model, where the bits are
> fetched from around the globe only once per cycle, sanitised, and
> thereafter read only from the repository, would drop the number
> of file-not-founds and wrong-versions down pretty close to zero.

Again, I simply don't understand this.

> >No one has ever done the work on "most minimal set of dependencies"
> >in the ports tree -- and that's because it's hard work.  Add to that
> >the fact that the technology has never supported partial checkouts
> >and it complicates things.
> 
> No argument from me!   IMO a big contributor to the problem is
> that the bits haven't been normalised and integrated into
> libraries.  So the process is frankensteinean:  odds and bobs
> dredged up wherever they can be found and stuck together in hope
> that they'll cooperate.

And this is where the hard work lies.

By comparison, defining "which ports are canonical" is easy.

IMHO.

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

Re: [RFC] Why FreeBSD ports should have branches by OS version

[Mark Linimon]

On Tue, Jun 27, 2017 at 09:01:39PM +, Thomas Mueller wrote:
> raising the possibility of building for other targets.

Which is very much not hardly even the same as "they are being resistant
to change".  In fact, about as far away from it as is possible to get.

"techinically possible" != "feasible in the immediate future".

I feel like I'm repeating myself in this thread, again.

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

Re: [RFC] Why FreeBSD ports should have branches by OS version

[Thomas Mueller]

from Mark Linimon:

> Remember that NetBSD runs on dozens of targets*, of which only two support
> Ada AFAIK.

> mcl

> * http://ftp.netbsd.org/pub/NetBSD/NetBSD-7.1/

I follow http://releng.netbsd.org/cgi-bin/builds.cgi

which shows 72 targets for HEAD, 67 targets for netbsd-7 and netbsd-8, 60 
targets for netbsd-6.

Ada, developed by the US Department of Defense, was not originally for amd64 
and i386.

A large part of the problem is that building Ada requires a preexisting GNAT.

Full GCC suite includes Ada, and is capable of cross-compilation, raising the 
possibility of building for other targets.

I can not say with authority which targets would succeed.

Dragonlace.net shows a port for FreeBSD aarch64.

Tom

___
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: [RFC] Why FreeBSD ports should have branches by OS version

[scratch65535]

[Default] On Tue, 27 Jun 2017 12:45:34 -0500, Mark Linimon
 wrote:

>On Tue, Jun 27, 2017 at 09:24:31AM -0400, scratch65...@att.net wrote:
>> The number of ports to build a server-of-all-work is not large.
>
>Now the problem is getting people to agree on exactly what that
>subset is.

Since that's what I integrate for my dev use, I'd be happy to
take a zero'th-order cut at defining it, if nobody else wants to.

>
>If there is interest, I can provide the examples and code I use
>whenever I start up a new machine here at the house, e.g. powerpc64,
>sparc64, etc.  And we'll see how close to agreement people can get.

Sounds good t'me!  

>
>(Yes, I'm quite skeptical.)
>
>> Unnecessarily complex and a source of uncontrolled errors, yes,
>
>One person's "unnecessary" is another person's "necessary".

By "unnecessary", Mark, I mean the fact that the bits are not
controlled locally, and thus potentially change from moment to
moment such that it's impossible to guarantee that two people
building the same app with the same options on two different
days, or even hours, will get the same result.

Switching to a central repository model, where the bits are
fetched from around the globe only once per cycle, sanitised, and
thereafter read only from the repository, would drop the number
of file-not-founds and wrong-versions down pretty close to zero.

>
>> Specialist workstations such as sound/video editing?  Maybe.
>
>You'll immediately go from a few hundred ports to a few thousand ports.
>
I'm happy to take your word for it, because I've no clue.  I
wonder whether the most important subset could be determined by
survey.  Any views on that?

>No one has ever done the work on "most minimal set of dependencies"
>in the ports tree -- and that's because it's hard work.  Add to that
>the fact that the technology has never supported partial checkouts
>and it complicates things.

No argument from me!   IMO a big contributor to the problem is
that the bits haven't been normalised and integrated into
libraries.  So the process is frankensteinean:  odds and bobs
dredged up wherever they can be found and stuck together in hope
that they'll cooperate.  Just looking at the stuff that goes into
Firefox made my blood run cold, and completely explained (fsvo
explained) where all the problems come from with that app.

>
>tl;dr: I do have long-time experience building subsets of the ports
>tree and in my experience it's harder than people think, once you
>get beyond a few dozen targets.

I don't doubt that even  slightly.   But I do think the magnitude
could be at least reduced by moving toward normalised bits.
___
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: Should a package restart on upgrade itself

[Vlad K.]

On 2017-06-27 21:12, Miroslav Lachman wrote:


And this is another problem. Poudriere always rebuild whole dependency
chain but if package version stays the same then pkg upgrade will not
upgrade all packages in chain but just the one with different version
number.


Which is my point. pkg might not upgrade postgresql96-server because the 
version of THAT package didn't change, but you'll see in the output of 
Poudriere bulk that postgresql96-server was rebuilt because, say, libxml 
was updated or rebuilt because, in turn, some of its own dependency 
updated.


That's why Poudriere's bulk output is the best list to check what you 
might want to restart, IMHO.




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

Re: Should a package restart on upgrade itself

[Miroslav Lachman]

Vlad K. wrote on 2017/06/27 20:36:


Also worth noting is that if you build your pkg repo with Poudriere (and
I'm guessing Synth), as it rebuilds ALL packages in the dependency
chain, it's easy to see, on each bulk run, which of the packages with
services are or could be affected (because their packages are rebuilt),
and should therefore be restarted. That at least is how we do it for our
servers.


And this is another problem. Poudriere always rebuild whole dependency 
chain but if package version stays the same then pkg upgrade will not 
upgrade all packages in chain but just the one with different version 
number.
If OpenSSL was upgraded but Apache (depending on OpenSSL from ports) was 
not upgraded it is hard to say "restart Apache" from some pkg magick. So 
again sysadmin must know what and when to restart.


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: Should a package restart on upgrade itself

[Michael Gmelin]

> On 27. Jun 2017, at 20:11, Matthias Fechner  wrote:
> 
>> Am 27.06.2017 um 18:50 schrieb Vlad K.:
>> Will this cover libraries as well? Eg. Libre/Open SSL upgrades,
>> restart all services that depend on it?
>> 
>> Meanwhile, there's "lsop": 
> 
> thanks for this tool, that is indeed very helpful.
> 
> Maybe it is a good idea if pkg collects the information from each
> package what should be restarted if:
> 
> HANDLE_RC_SCRIPTS = true;
> 
> is set.
> In this case it is the responsibility of the package maintainer to mark which 
> service should be started if it was upgraded.
> And then do a single bulk restart operation at the end of the complete 
> upgrade.

As default behavior this is not good for admins - you really want to be able to 
control when a service restarts, especially when running many services, doing 
multiple updates etc.

-m


> 
> Gruß
> Matthias
> 
> -- 
> 
> "Programming today is a race between software engineers striving to
> build bigger and better idiot-proof programs, and the universe trying to
> produce bigger and better idiots. So far, the universe is winning." --
> Rich Cook
> 
> ___
> 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: Should a package restart on upgrade itself

[Miroslav Lachman]

Matthias Fechner wrote on 2017/06/27 20:11:

Am 27.06.2017 um 18:50 schrieb Vlad K.:

Will this cover libraries as well? Eg. Libre/Open SSL upgrades,
restart all services that depend on it?

Meanwhile, there's "lsop":


thanks for this tool, that is indeed very helpful.

Maybe it is a good idea if pkg collects the information from each
package what should be restarted if:

HANDLE_RC_SCRIPTS = true;

is set.
In this case it is the responsibility of the package maintainer to mark which 
service should be started if it was upgraded.
And then do a single bulk restart operation at the end of the complete upgrade.


It is not so easy to handle this on maintainer side. For example we have 
one machine with PHP + Apache + Lighttpd.
If some PHP extension is reinstalled, what should be restarted and how 
maintainer should know it? Is Apache using PHP? Is Lighttpd using PHP? 
Are there php-fpm running PHP?
Just because there is some package it doesn't mean it uses PHP and 
should be restarted. It depends on configuration made by sysadmin.


Sometimes the setup is so complex that it is better to let this on 
admins decision and not some automagick guess.


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: Should a package restart on upgrade itself

[Vlad K.]

Also worth noting is that if you build your pkg repo with Poudriere (and 
I'm guessing Synth), as it rebuilds ALL packages in the dependency 
chain, it's easy to see, on each bulk run, which of the packages with 
services are or could be affected (because their packages are rebuilt), 
and should therefore be restarted. That at least is how we do it for our 
servers.





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

Re: Should a package restart on upgrade itself

[Matthias Fechner]

Am 27.06.2017 um 18:50 schrieb Vlad K.:
> Will this cover libraries as well? Eg. Libre/Open SSL upgrades,
> restart all services that depend on it?
>
> Meanwhile, there's "lsop": 

thanks for this tool, that is indeed very helpful.

Maybe it is a good idea if pkg collects the information from each
package what should be restarted if:

HANDLE_RC_SCRIPTS = true;

is set.
In this case it is the responsibility of the package maintainer to mark which 
service should be started if it was upgraded.
And then do a single bulk restart operation at the end of the complete upgrade.

Gruß
Matthias

-- 

"Programming today is a race between software engineers striving to
build bigger and better idiot-proof programs, and the universe trying to
produce bigger and better idiots. So far, the universe is winning." --
Rich Cook

___
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: [RFC] Why FreeBSD ports should have branches by OS version

[Mark Linimon]

On Tue, Jun 27, 2017 at 07:37:22AM +, Thomas Mueller wrote:
> It seems NetBSD pkgsrc people are not catching on, preferring to stay
> with the clumsy pkgsrc tools: creatures of habit, reluctant to change.

Remember that NetBSD runs on dozens of targets*, of which only two support
Ada AFAIK.

mcl

* http://ftp.netbsd.org/pub/NetBSD/NetBSD-7.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: [RFC] Why FreeBSD ports should have branches by OS version

[Mark Linimon]

On Tue, Jun 27, 2017 at 09:24:31AM -0400, scratch65...@att.net wrote:
> The number of ports to build a server-of-all-work is not large.

Now the problem is getting people to agree on exactly what that
subset is.

If there is interest, I can provide the examples and code I use
whenever I start up a new machine here at the house, e.g. powerpc64,
sparc64, etc.  And we'll see how close to agreement people can get.

(Yes, I'm quite skeptical.)

> Unnecessarily complex and a source of uncontrolled errors, yes,

One person's "unnecessary" is another person's "necessary".

> Specialist workstations such as sound/video editing?  Maybe.

You'll immediately go from a few hundred ports to a few thousand ports.

No one has ever done the work on "most minimal set of dependencies"
in the ports tree -- and that's because it's hard work.  Add to that
the fact that the technology has never supported partial checkouts
and it complicates things.

tl;dr: I do have long-time experience building subsets of the ports
tree and in my experience it's harder than people think, once you
get beyond a few dozen targets.

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

Re: Should a package restart on upgrade itself

[Miroslav Lachman]

Matthias Fechner wrote on 2017/06/27 18:29:

Dear all,

it is always a pain if pkg upgrade a lot of packages to restart all
services to make sure update/security fixes are applied to all running
services.

Is there an option in pkg that it restart services automatically or is
it OK if I would add a post-install script to the packages (I maintain)
that will include a "service foo restart"?

What is best practice here?


Please don't do this.
Some ports did this in the past and this was really a pain during larger 
upgrades. It sometimes leave services stopped (hi MySQL).


The same bad practice is disabling / enabling Apache modules on upgrade.

pkg upgrade should just do it's work - upgrade packages on disk. But 
manipulating config files and restart of services is up to me - the 
Administrator (or my tools).


It would be nice to have some kind of "hooks" in pkg, which can be used 
to notify deployment tools that some services should be (re)started, or 
do restart in some simpler environment if user allows this (setup hooks 
for service restart).
But is must not be done automatically for individual ports / packages 
even if maintainer thinks it is Good Idea (tm)


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: Should a package restart on upgrade itself

[David Wolfskill]

On Tue, Jun 27, 2017 at 06:29:24PM +0200, Matthias Fechner wrote:
> Dear all,
> 
> it is always a pain if pkg upgrade a lot of packages to restart all
> services to make sure update/security fixes are applied to all running
> services.
> 
> Is there an option in pkg that it restart services automatically or is
> it OK if I would add a post-install script to the packages (I maintain)
> that will include a "service foo restart"?
> 
> What is best practice here?
> 

I do not claim that this is "best practice."  But what I do, during my
weekly updates of my "production" systems (at home) is:

* "Clone" the active slice to the other slice.
* Build the world & suitable kernels on the build machine.
* Mount /usr/src and /usr/obj from the build machine.
* Set DESTDIR to a suitable directory on the other slice.
* make installkernel ${DESTDIR} && \
  mergemaster -U -u 0022 -p && \
  make installworld ${DESTDIR} && \
  mergemaster -F -U -u 0022 -i && \ 
  make delete-old ${DESTDIR}
* reboot from the other slice.

* Mount /usr/src and /usr/obj from the build machine.
* Stop all services that depend on 3rd-party software (ports/packages).
* pkg upgrade
* make delete-old-libs
* reboot

(I elided a few minor embellishments; the above are the essential steps.)

It seems to work for me.

Peace,
david
-- 
David H. Wolfskill  da...@catwhisker.org
I look forward to voting against Trump again at the earliest opportunity.

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


signature.asc
Description: PGP signature

Re: Should a package restart on upgrade itself

[Vlad K.]

On 2017-06-27 18:35, Baptiste Daroussin wrote:


In the futur it is planed to move this into a trigger (executed at the 
end of
the entire upgrade process) which will solve the "dovecot" issue, but 
not the

one where upgrading requires a procedure.


Will this cover libraries as well? Eg. Libre/Open SSL upgrades, restart 
all services that depend on it?


Meanwhile, there's "lsop":

https://www.freshports.org/sysutils/lsop/


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

Re: Should a package restart on upgrade itself

[Baptiste Daroussin]

On Tue, Jun 27, 2017 at 06:29:24PM +0200, Matthias Fechner wrote:
> Dear all,
> 
> it is always a pain if pkg upgrade a lot of packages to restart all
> services to make sure update/security fixes are applied to all running
> services.
> 
> Is there an option in pkg that it restart services automatically or is
> it OK if I would add a post-install script to the packages (I maintain)
> that will include a "service foo restart"?
> 
> What is best practice here?
> 
A package self upgrading might cause issues: plugins not yet updated (hi
dovecot), or services requiring an upgrade procedure. So activating a self
restart of the service by default is a bad idea.

service -R command can simplify the procedure for the admin given it restarts
all services already started.

Another option is to activate an option of pkg(8) off by default:
HANDLE_RC_SCRIPTS = true;
in /usr/local/etc/pkg.conf

which will automatically restart the services on upgrade.

In the futur it is planed to move this into a trigger (executed at the end of
the entire upgrade process) which will solve the "dovecot" issue, but not the
one where upgrading requires a procedure.

Best regards,
Bapt


signature.asc
Description: PGP signature

Re: Should a package restart on upgrade itself

[Franco Fichtner]

Hi Matthias,

As far as I know, pkg package scripts' runaway processes are
reaped since a few versions, so you can't restart from there
anymore.

Maybe there is a way to detach correctly, I don't know.


Cheers,
Franco

> On 27. Jun 2017, at 6:29 PM, Matthias Fechner  wrote:
> 
> Dear all,
> 
> it is always a pain if pkg upgrade a lot of packages to restart all
> services to make sure update/security fixes are applied to all running
> services.
> 
> Is there an option in pkg that it restart services automatically or is
> it OK if I would add a post-install script to the packages (I maintain)
> that will include a "service foo restart"?
> 
> What is best practice here?
> 
> 
> Thanks
> Matthias
> 
> -- 
> 
> "Programming today is a race between software engineers striving to
> build bigger and better idiot-proof programs, and the universe trying to
> produce bigger and better idiots. So far, the universe is winning." --
> Rich Cook
> 
> ___
> 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"

Should a package restart on upgrade itself

[Matthias Fechner]

Dear all,

it is always a pain if pkg upgrade a lot of packages to restart all
services to make sure update/security fixes are applied to all running
services.

Is there an option in pkg that it restart services automatically or is
it OK if I would add a post-install script to the packages (I maintain)
that will include a "service foo restart"?

What is best practice here?


Thanks
Matthias

-- 

"Programming today is a race between software engineers striving to
build bigger and better idiot-proof programs, and the universe trying to
produce bigger and better idiots. So far, the universe is winning." --
Rich Cook

___
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 handle GCC version detection

[Dimitry Andric]

On 27 Jun 2017, at 17:39, Aryeh Friedman  wrote:
> 
> I have port I maintain that compiles fine under GCC 5 (or lower) but barfs
> on GCC 6.   A small modification will make it compile under 6 but the very
> same modification makes it incompatible with 5.   What is the best way to
> handle this and still allow USE_GCC=any ?

Something like:

#if __GNUC__ <= 5
   ...foo...
#else
   ...bar...
#endif

could maybe work?

-Dimitry



signature.asc
Description: Message signed with OpenPGP

best way to handle GCC version detection

[Aryeh Friedman]

I have port I maintain that compiles fine under GCC 5 (or lower) but barfs
on GCC 6.   A small modification will make it compile under 6 but the very
same modification makes it incompatible with 5.   What is the best way to
handle this and still allow USE_GCC=any ?

-- 
Aryeh M. Friedman, Lead Developer, http://www.PetiteCloud.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: [RFC] Why FreeBSD ports should have branches by OS version

[scratch65535]

[Default] On Mon, 26 Jun 2017 19:33:50 +, Grzegorz Junka
 wrote:

>we could 
>start small with a just a handful of ports in a stable LTS (Long Term 
>Support) branch. Develop processes around maintaining them, get some 
>feedback about the effort of applying only security fixes, then add more 
>ports as required or as viable from the resources point of view. How 
>does that sound?

It sounds excellent, at least to me.  

How many platform roles are seen as fbsd's metier?

Firewall?  Already handled.

Specialist workstations such as sound/video editing?  Maybe.  I
don't know enough about that to have an opinion.

Servers.  No question.  That's always been freebsd's best thing.
The number of ports to build a server-of-all-work is not large.
Unnecessarily complex and a source of uncontrolled errors, yes,
but not really *large* qua large.
___
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: PRs in need of some TLC

[Kurt Jaeger]

Hi!

> >> could someone have a look at these PRs (they are linked) and provide some 
> >> tender loving care? ;-)

> >> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=220177
> > 
> > This is missing a patch, isn't it ?

> You're right. I am sorry. But it seems you created one. Thanks for that.

Yes. I'm no user of that port, so: Can you test if the patch
works and add it to the PR ?

> >> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=220190
> >> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=220191
> > 
> > If possible, provide a link to the changelog ?
> 
> I added links to the respective Changelog.

Thanks!

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

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
+-+
math/giacxcas   | 1.2.2-57| 1.2.3-53
+-+


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: [RFC] Why FreeBSD ports should have branches by OS version

[Julian H. Stacey]

"Thomas Mueller" wrote:
> from Dewayne Geraghty:
> 
> > Synth is very good.  It builds upon pkg and is way less complicated that
> > poudriere.

I dont know the relative dependencies counts for both synth & poudriere,
but I suspect synth is bigger ?
  ( I have a messed up current here where loads of ports break, I
  tried to build synth to then recover other ports, but synth broke
  deep, building some gcc, & I have a working poudriere.)

If one has a good stable platform, then a nice maintainer that does
chroot/jail elegantly with lots of features is probably attractive,
& dependency count not a worry.

But if one stands on a broken system & needs to recover, some simple
stock cc & sh tool/procedure with no dependencies is attractive, even if
one has to coble something ones self.

Cheers,
Julian
-- 
Julian Stacey, Computer Consultant, BSD Linux Unix Systems Engineer
 Reply below, Prefix '> '. Plain text, No .doc, base64, HTML, quoted-printable.
 http://berklix.eu/brexit/#700k_stolen_votes
___
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: PRs in need of some TLC

[Martin Waschbüsch]

> Am 27.06.2017 um 00:33 schrieb Greg 'groggy' Lehey :
> 
> On Monday, 26 June 2017 at 21:48:14 +0200, Martin Waschbüsch wrote:
>> Hi all,
>> 
>> could someone have a look at these PRs (they are linked) and provide
>> some tender loving care? ;-)
>> 
>> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=220177
>> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=220190
>> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=220191
> 
> If you say which ports are involved, you're more likely to get
> attention.

Good point, Greg. Thanks. I’ll keep it in mind for next time.
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: PRs in need of some TLC

[Martin Waschbüsch]

> Am 27.06.2017 um 00:56 schrieb Kurt Jaeger :
> 
> Hi!
> 
>> could someone have a look at these PRs (they are linked) and provide some 
>> tender loving care? ;-)
>> 
>> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=220177
> 
> This is missing a patch, isn't it ?

You’re right. I am sorry. But it seems you created one. Thanks for that.

>> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=220190
>> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=220191
> 
> If possible, provide a link to the changelog ?

I added links to the respective Changelog.

Thanks,

Martin
___
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: [RFC] Why FreeBSD ports should have branches by OS version

[Thomas Mueller]

from Dewayne Geraghty:

> Synth is very good.  It builds upon pkg and is way less complicated that
> poudriere.
 
> Unfortunately John Marino was unceremoniously removed from committing to
> FreeBSD, and its is uncertain whether he'll continue to support synth on
> FreeBSD.  (He supports DragonflyBSD.  :)

I remember reading about this falling-out.  Are others in FreeBSD ports taking 
over and continuing support and updates for synth?

Does John Marino still support NetBSD pkgsrc with synth?  It seems NetBSD 
pkgsrc people are not catching on, preferring to stay with the clumsy pkgsrc 
tools: creatures of habit, reluctant to change.

I tried the live/installation DragonFlyBSD USB-stick image, but it had 
problems: no Internet access, drivers missing or nonworking, and my last try 
didn't boot.  Also it couldn't (previous tries) mount any FreeBSD or NetBSD 
partition, and FreeBSD and NetBSD couldn't mount/read the DragonFlyBSD USB 
stick even with UFS as opposed to Hammer file system.

Tom

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

Your Account Has Been Disabled

[Apple]

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