Re: Looking for a committer net-mgmt/prometheus

[Kurt Jaeger]

Hi!

> I just updated https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=212468 patch
> attachment to build the latest release of prometheus. It's now 1.2.1

Well, the version number in the patch was 1.1.3, but
changing that to 1.2.1 was easy, test-building was OK, so: done.

> Can I get a committer to review, and possibly commit? This new port request
> and my other one (node_exporter:
> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=212467) have both been
> open since Sep 9th.

Also done.

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

Looking for a committer net-mgmt/prometheus

[Jev Björsell]

Hi All,

I just updated https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=212468 patch
attachment to build the latest release of prometheus. It's now 1.2.1

Can I get a committer to review, and possibly commit? This new port request
and my other one (node_exporter:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=212467) have both been
open since Sep 9th.

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

Re: harder and harder to avoid pkg

[Dave Horsfall]

On Fri, 14 Oct 2016, David Demelier wrote:

> It's not writing a port that is complicated, it's the whole 
> infrastructure.

You should see the Macports infrastructure...  Fairly easy for the end 
user, but those developers sweat blood to make it so.

-- 
Dave Horsfall DTM (VK2KFU)  "Those who don't understand security will suffer."
___
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"

The Unique iMarketing Center app to send bulk SMS and email

[iMarketing Center]

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

Re: harder and harder to avoid pkg

[Julian Elischer]

On 14/10/2016 4:27 AM, Matthieu Volat wrote:

On Fri, 14 Oct 2016 13:05:35 +0200
David Demelier  wrote:


2016-10-14 11:22 GMT+02:00 Baptiste Daroussin :

It is imho doable in both sides.

We could imagine tagging the plist/manifest so pkg can allow a user to install
only the things tagged as runtime for exemple which would do the job. for what
Julian is asking for beside adding lots of complexity pkg(8) and adding a
nightmare in the solver.

That would "please" the people that want "hey keep the giant flat package as it
is better for dev given I don't have to install the -devel version something"
and the people wanting fine grain selection if they need to.

But on the ports side that would be a nightmare having to tag all the plist (and
this cannot be automated because there are to many corner cases.

IIRC, rpm builders have script that automate this by finding files in
standard directories. Probably by checking in the stage a include/
directory and "tag" it as the development part.

Unless things changed very recently, not quite : you have to pile subpackage 
declaration and files sections according to the subpackages you create. The 
only things it has to ease the burden is you can use wildcard patterns to 
select files.


It will be the most smart way of doing this but still require some
addition to pkg. Probably like:

- pkg install mylib
- pkg install -t dev mylib
- pkg install -t runtime mylib
- pkg install -t dev,runtime,doc mylib

Just thinking ;)

More options, then more options to `pkg info` to get what was installed when something 
cannot build, then more pkg search options and manpage because more "-t" flags 
will be added and we don't know what's needed?


I'm glad people are at least thinking about it...

I don't think there are so many categories.  Are we installing onto a 
development machine, user machine, or an appliance? appliances don't 
need man pages. User machines need man pages for programs but not for 
libraries and developer machines.. everything..



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

Re[2]: www/magento port outdated

[Alexander Liebau]

a new port would be quite nice.
i am pretty clueless about creating or maintaining one though :(

regards,

alex

-- Originalnachricht --
Von: "Torsten Zuehlsdorff" 
An: "Alexander Liebau" ; po...@freebsd.org
Gesendet: 14.10.2016 12:49:12
Betreff: Re: www/magento port outdated




On 14.10.2016 12:15, Torsten Zuehlsdorff wrote:



On 14.10.2016 11:13, Alexander Liebau wrote:

hello,

i would like to ask if it is possible to update the port www/magento 
to

its current version.
it is currently on version 1.8.1 which is more than 2 years old.
the most recent version would be 2.1.2 or 2.0.10 according to
https://www.magentocommerce.com/download


There is a PR for an update, but no work happend on it for long time.


Oh, i'm sorry, forgot the link:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=201709

As you can see there was already a try to bring it to a current (and 
supported) 1.9.x version, but it failed and the maintainership was 
dropped. :/


I could help in creating a new port with magento 2. But i have not this 
much time so it will take a while ;)


Greetings,
Torsten


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

Re: harder and harder to avoid pkg

[Matthieu Volat]

On Fri, 14 Oct 2016 13:05:35 +0200
David Demelier  wrote:

> 2016-10-14 11:22 GMT+02:00 Baptiste Daroussin :
> > It is imho doable in both sides.
> >
> > We could imagine tagging the plist/manifest so pkg can allow a user to 
> > install
> > only the things tagged as runtime for exemple which would do the job. for 
> > what
> > Julian is asking for beside adding lots of complexity pkg(8) and adding a
> > nightmare in the solver.
> >
> > That would "please" the people that want "hey keep the giant flat package 
> > as it
> > is better for dev given I don't have to install the -devel version 
> > something"
> > and the people wanting fine grain selection if they need to.
> >
> > But on the ports side that would be a nightmare having to tag all the plist 
> > (and
> > this cannot be automated because there are to many corner cases.
> 
> IIRC, rpm builders have script that automate this by finding files in
> standard directories. Probably by checking in the stage a include/
> directory and "tag" it as the development part.

Unless things changed very recently, not quite : you have to pile subpackage 
declaration and files sections according to the subpackages you create. The 
only things it has to ease the burden is you can use wildcard patterns to 
select files.

> It will be the most smart way of doing this but still require some
> addition to pkg. Probably like:
> 
> - pkg install mylib
> - pkg install -t dev mylib
> - pkg install -t runtime mylib
> - pkg install -t dev,runtime,doc mylib
> 
> Just thinking ;)

More options, then more options to `pkg info` to get what was installed when 
something cannot build, then more pkg search options and manpage because more 
"-t" flags will be added and we don't know what's needed?

-- 
Matthieu Volat 



pgpZY_aqAJ_bU.pgp
Description: OpenPGP digital signature

Re: harder and harder to avoid pkg

[Kurt Jaeger]

Hi!

> > This is an appliance class machine. It has 2G of storage and that has
> > to  include 2 copies for the OS so we can ping-pong for upgrades.
> 
> I can get > 2GB CPU cache per system (spread over 8+ sockets) these 
> days. Is it really reasonable to expect port maintainers to take up the 
> work and classify their maintained ports for you to save you an 
> additional 2GB of cheap flash storage?

Letting the appliance-market slip away to other platforms should be
avoided.

> At a certain scale those 
> trade-offs might make sense for you, but I suspect most FreeBSD port 
> maintainers and FreeBSD users don't mind a few 100 kB of documentation 
> and headers on their systems. Aren't there easier solutions which don't 
> require a lot of manual work?

Using the pkg-plist of packages by removing those files not in
bin/ or lib/ might solve approx. 80% of the problem. Someone's
willing to test this 8-} ?

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

Re: harder and harder to avoid pkg

[Jan Bramkamp]

On 14/10/2016 09:39, Julian Elischer wrote:

On 13/10/2016 10:33 AM, RW via freebsd-ports wrote:

On Tue, 11 Oct 2016 11:59:47 -0700
Julian Elischer wrote:


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


A simple example:   libxml2

This package installs include files and libraries and dicumentation
etc.

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

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

What practical problem does installing the include files and man pages
cause you?

I have to delete them from the appliance I'm building up.
So I need to get the manifest, remove the files I want from it, and
delete every other file mentioned.

This is an appliance class machine. It has 2G of storage and that has
to  include 2 copies for the OS so we can ping-pong for upgrades.


I can get > 2GB CPU cache per system (spread over 8+ sockets) these 
days. Is it really reasonable to expect port maintainers to take up the 
work and classify their maintained ports for you to save you an 
additional 2GB of cheap flash storage? At a certain scale those 
trade-offs might make sense for you, but I suspect most FreeBSD port 
maintainers and FreeBSD users don't mind a few 100 kB of documentation 
and headers on their systems. Aren't there easier solutions which don't 
require a lot of manual work?


 * Documentation and source code compresses well. Can you use a 
read-only lzma or gzip compressed filesystem with GEOM uncompress?


 * Can you use snapshots (and rerooting) to rollback failed updates 
instead of keeping two full copies around?


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

Re: harder and harder to avoid pkg

[David Demelier]

2016-10-14 11:22 GMT+02:00 Baptiste Daroussin :
> It is imho doable in both sides.
>
> We could imagine tagging the plist/manifest so pkg can allow a user to install
> only the things tagged as runtime for exemple which would do the job. for what
> Julian is asking for beside adding lots of complexity pkg(8) and adding a
> nightmare in the solver.
>
> That would "please" the people that want "hey keep the giant flat package as 
> it
> is better for dev given I don't have to install the -devel version something"
> and the people wanting fine grain selection if they need to.
>
> But on the ports side that would be a nightmare having to tag all the plist 
> (and
> this cannot be automated because there are to many corner cases.

IIRC, rpm builders have script that automate this by finding files in
standard directories. Probably by checking in the stage a include/
directory and "tag" it as the development part.

It will be the most smart way of doing this but still require some
addition to pkg. Probably like:

- pkg install mylib
- pkg install -t dev mylib
- pkg install -t runtime mylib
- pkg install -t dev,runtime,doc mylib

Just thinking ;)

-- 
Demelier David
___
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: www/magento port outdated

[Torsten Zuehlsdorff]

On 14.10.2016 12:15, Torsten Zuehlsdorff wrote:



On 14.10.2016 11:13, Alexander Liebau wrote:

hello,

i would like to ask if it is possible to update the port www/magento to
its current version.
it is currently on version 1.8.1 which is more than 2 years old.
the most recent version would be 2.1.2 or 2.0.10 according to
https://www.magentocommerce.com/download


There is a PR for an update, but no work happend on it for long time.


Oh, i'm sorry, forgot the link:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=201709

As you can see there was already a try to bring it to a current (and 
supported) 1.9.x version, but it failed and the maintainership was 
dropped. :/


I could help in creating a new port with magento 2. But i have not this 
much time so it will take a while ;)


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

Re: harder and harder to avoid pkg

[Matthew Seaman]

On 10/14/16 10:22, Baptiste Daroussin wrote:
> We could imagine tagging the plist/manifest so pkg can allow a user to install
> only the things tagged as runtime for exemple which would do the job. for what
> Julian is asking for beside adding lots of complexity pkg(8) and adding a
> nightmare in the solver.
> 
> That would "please" the people that want "hey keep the giant flat package as 
> it
> is better for dev given I don't have to install the -devel version something"
> and the people wanting fine grain selection if they need to.
> 
> But on the ports side that would be a nightmare having to tag all the plist 
> (and
> this cannot be automated because there are to many corner cases.

You still need something like this whichever way sub-packages are
implemented -- compiling and staging the port generates a whole load of
files and you somehow have to identify each of them as docs, examples,
whatever either for tagging in the plist or for turning into sub-packages.

Some of that you can do heuristically, but yeah -- this classification
job would be a thing that port maintainers get to enjoy.

It should be possible to create meta-packages that do nothing except
depend on commonly used combinations of sub-packages as a convenience
for people installing software at the command line.  For example one
that could have the same overall result as installing an all-in-one
package at the moment.  I believe something like this is planned for the
base system packages.

> Having the port that grows the feature would be really nice because no work
> would be needed on pkg :) and that would reduce cluster package building as we
> could merge qt, php etc into one port that builds multiple sub packages.

True, that would save a number of repetitive compilations.  Of course,
what you save by implementing sub-packages you'ld immediately lose (and
more) by implementing package flavours.

Cheers,

Matthew



signature.asc
Description: OpenPGP digital signature

Re: gcc5 dependency challenges

[Kubilay Kocak]

On 14/10/2016 6:48 PM, Dewayne Geraghty wrote:
> After some rudimentary performance testing I note that we get up
> around 3% improvement in application performance when we use gcc5 for
> our package builds.
> 
> However building ports with gcc results in gcc5 being a dependency. 
> Examining ldd, we find that rarely does anything require gcc5's
> shared libs for their execution.  Even simple things like ftp/wget
> and devel/ccache depend on gcc5 for building but NOT runtime.  As we
> aren't allowed to install compilers onto production systems, what is
> the best course of action to address? (We could just install gcc5 and
> then remove it but then of course, the base pkg wants to remove
> everything (600+ packages) that depends on gcc5!)
> 
> So the question is - how should we build our packages or install them
> so that gcc5 is not (unnecessarily) installed?
> 
> We've added to our /etc/make.conf USE_GCC=  5 but I wonder if there's
> something like a build_depends mechanism?
> 
> 
> Background: Our FreeBSD 10.3 Stable uses pkg 1.8.3; whereas ports
> uses 1.8.7_3, minor point.
> 
> Why gcc5? Well most ports use clang 3.4.1 to compile, some ports do
> use gcc 4.8.5; and if we move to FreeBSD11 then we also need to add
> llvm3.6 into the build/migrating equation.  So to aid our migration
> effort we "think" choosing gcc5 now is a good idea; particularly as
> /usr/ports/base/gcc uses gcc 5.4.0 (rather than /usr/ports/lang/gcc
> which is 4.8.5)
> 
> All production systems use local package repositories (as heimdal is
> widely used as are  non-default options).
> 
> Kind regards, Dewayne 

This (in progress thing) may help:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=211154

See dependent Bugzilla issue:

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=211079

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

Re: www/magento port outdated

[Torsten Zuehlsdorff]

On 14.10.2016 11:13, Alexander Liebau wrote:

hello,

i would like to ask if it is possible to update the port www/magento to
its current version.
it is currently on version 1.8.1 which is more than 2 years old.
the most recent version would be 2.1.2 or 2.0.10 according to
https://www.magentocommerce.com/download


There is a PR for an update, but no work happend on it for long time.

Also: Magento 2 it nearly completely incompatible with all 1.x versions. 
It would be wise to create a new port for this! Otherwise all existing 
users will be in great trouble, especially if the use modules besides 
the core installation.


Greetings,
Torsten
___
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: www/magento port outdated

[Kurt Jaeger]

Hi!

> i would like to ask if it is possible to update the port www/magento to 
> its current version.
> it is currently on version 1.8.1 which is more than 2 years old.
> the most recent version would be 2.1.2 or 2.0.10 according to 
> https://www.magentocommerce.com/download

Can you provide a patch ? Or run-testing, if a patch is provided ?
A link to the changelog ?

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

Re: harder and harder to avoid pkg

[Baptiste Daroussin]

On Fri, Oct 14, 2016 at 09:54:07AM +0200, Mathieu Arnold wrote:
> Le 14/10/2016 à 09:34, Julian Elischer a écrit :
> > On 13/10/2016 5:42 AM, David Demelier wrote:
> >> 2016-10-12 10:04 GMT+02:00 Andrea Venturoli :
> >>> On 10/12/16 09:24, Matthieu Volat wrote:
> >>>
>  And GNU/Linuxes can be a PITA when you have to track -dev(el) packages
>  (which sometimes really requires -bin, -app or whatever), or worst,
>  describe
>  to people how they are supposed to build your software with weird
>  subpackage
>  names.
> 
>  I really like that ports provides the software project as intended by
>  upstream (modulo options).
> >>>
> >>> Just a "me too" here!
> >> Could not agree more.
> >>
> >> Please forget that idea.
> >>
> >> I just hate having to install libfoo, libfoo-dev, libfoo-dbg,
> >> libfoo-doc, libfoo-whatever each time I need to develop on Linux.
> >> Please do not transform FreeBSD as a Linux distribution :)
> >>
> >> I love the way FreeBSD and some very sparse Linux distributions
> >> provide the packages exactly how it would be installed by hand (=
> >> vanilla).
> >>
> >> FreeBSD offers some options and very few changes for better
> >> integration but packages are provided vanilla. You want a package? You
> >> install /packagename/ nothing more, nothing less. I really would like
> >> to see simple vanilla packages for the next 10 years.
> >>
> >> The FreeBSD ports is already extremely complicated, do not make it
> >> even harder :(
> > The suggestion is not for ports, but for packages..
> > a single package could be unpacked in 'runtime only' or 'everything'
> > mode.
> > basically one package, two manifests.  So no "foo-devel" or "foo-runtime"
> > just 'foo'
> 
> It is for ports, because packages are built using ports, and ports would
> need to grow the feature.
> 

It is imho doable in both sides.

We could imagine tagging the plist/manifest so pkg can allow a user to install
only the things tagged as runtime for exemple which would do the job. for what
Julian is asking for beside adding lots of complexity pkg(8) and adding a
nightmare in the solver.

That would "please" the people that want "hey keep the giant flat package as it
is better for dev given I don't have to install the -devel version something"
and the people wanting fine grain selection if they need to.

But on the ports side that would be a nightmare having to tag all the plist (and
this cannot be automated because there are to many corner cases.

Having the port that grows the feature would be really nice because no work
would be needed on pkg :) and that would reduce cluster package building as we
could merge qt, php etc into one port that builds multiple sub packages.

Best regards,
Bapt


signature.asc
Description: PGP signature

www/magento port outdated

[Alexander Liebau]

hello,

i would like to ask if it is possible to update the port www/magento to 
its current version.

it is currently on version 1.8.1 which is more than 2 years old.
the most recent version would be 2.1.2 or 2.0.10 according to 
https://www.magentocommerce.com/download


kind regards,

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

Re: gcc5 dependency challenges

[Julian Elischer]

On 14/10/2016 12:48 AM, Dewayne Geraghty wrote:

After some rudimentary performance testing I note that we get up around 3%
improvement in application performance when we use gcc5 for our package
builds.

However building ports with gcc results in gcc5 being a dependency.
Examining ldd, we find that rarely does anything require gcc5's shared libs
for their execution.  Even simple things like ftp/wget and devel/ccache
depend on gcc5 for building but NOT runtime.  As we aren't allowed to
install compilers onto production systems, what is the best course of
action to address?
(We could just install gcc5 and then remove it but then of course, the base
pkg wants to remove everything (600+ packages) that depends on gcc5!)

So the question is - how should we build our packages or install them so
that gcc5 is not (unnecessarily) installed?
This is a topic I have been discussing in this list over the last few 
weeks.
My understanding is that the compiler should not be a dependency for 
the package.


I have been suggesting that packages should be installable in two 
manners,  runtime or developement.
In runtie mode they would only unpack the binary results (and not the 
man pages or .a files or .h files)
and would only give library dependancies as depends.. In devel mode 
they woudl be sort of like now..



We've added to our /etc/make.conf
USE_GCC=  5
but I wonder if there's something like a build_depends mechanism?


Background:
Our FreeBSD 10.3 Stable uses pkg 1.8.3; whereas ports uses 1.8.7_3, minor
point.

Why gcc5? Well most ports use clang 3.4.1 to compile, some ports do use gcc
4.8.5; and if we move to FreeBSD11 then we also need to add llvm3.6 into
the build/migrating equation.  So to aid our migration effort we "think"
choosing gcc5 now is a good idea; particularly as /usr/ports/base/gcc uses
gcc 5.4.0 (rather than /usr/ports/lang/gcc which is 4.8.5)

All production systems use local package repositories (as heimdal is widely
used as are  non-default options).

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



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

Re: harder and harder to avoid pkg

[Mathieu Arnold]

Le 14/10/2016 à 09:34, Julian Elischer a écrit :
> On 13/10/2016 5:42 AM, David Demelier wrote:
>> 2016-10-12 10:04 GMT+02:00 Andrea Venturoli :
>>> On 10/12/16 09:24, Matthieu Volat wrote:
>>>
 And GNU/Linuxes can be a PITA when you have to track -dev(el) packages
 (which sometimes really requires -bin, -app or whatever), or worst,
 describe
 to people how they are supposed to build your software with weird
 subpackage
 names.

 I really like that ports provides the software project as intended by
 upstream (modulo options).
>>>
>>> Just a "me too" here!
>> Could not agree more.
>>
>> Please forget that idea.
>>
>> I just hate having to install libfoo, libfoo-dev, libfoo-dbg,
>> libfoo-doc, libfoo-whatever each time I need to develop on Linux.
>> Please do not transform FreeBSD as a Linux distribution :)
>>
>> I love the way FreeBSD and some very sparse Linux distributions
>> provide the packages exactly how it would be installed by hand (=
>> vanilla).
>>
>> FreeBSD offers some options and very few changes for better
>> integration but packages are provided vanilla. You want a package? You
>> install /packagename/ nothing more, nothing less. I really would like
>> to see simple vanilla packages for the next 10 years.
>>
>> The FreeBSD ports is already extremely complicated, do not make it
>> even harder :(
> The suggestion is not for ports, but for packages..
> a single package could be unpacked in 'runtime only' or 'everything'
> mode.
> basically one package, two manifests.  So no "foo-devel" or "foo-runtime"
> just 'foo'

It is for ports, because packages are built using ports, and ports would
need to grow the feature.

-- 
Mathieu Arnold




signature.asc
Description: OpenPGP digital signature

gcc5 dependency challenges

[Dewayne Geraghty]

After some rudimentary performance testing I note that we get up around 3%
improvement in application performance when we use gcc5 for our package
builds.

However building ports with gcc results in gcc5 being a dependency.
Examining ldd, we find that rarely does anything require gcc5's shared libs
for their execution.  Even simple things like ftp/wget and devel/ccache
depend on gcc5 for building but NOT runtime.  As we aren't allowed to
install compilers onto production systems, what is the best course of
action to address?
(We could just install gcc5 and then remove it but then of course, the base
pkg wants to remove everything (600+ packages) that depends on gcc5!)

So the question is - how should we build our packages or install them so
that gcc5 is not (unnecessarily) installed?

We've added to our /etc/make.conf
USE_GCC=  5
but I wonder if there's something like a build_depends mechanism?


Background:
Our FreeBSD 10.3 Stable uses pkg 1.8.3; whereas ports uses 1.8.7_3, minor
point.

Why gcc5? Well most ports use clang 3.4.1 to compile, some ports do use gcc
4.8.5; and if we move to FreeBSD11 then we also need to add llvm3.6 into
the build/migrating equation.  So to aid our migration effort we "think"
choosing gcc5 now is a good idea; particularly as /usr/ports/base/gcc uses
gcc 5.4.0 (rather than /usr/ports/lang/gcc which is 4.8.5)

All production systems use local package repositories (as heimdal is widely
used as are  non-default options).

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

Re: harder and harder to avoid pkg

[Julian Elischer]

On 13/10/2016 10:33 AM, RW via freebsd-ports wrote:

On Tue, 11 Oct 2016 11:59:47 -0700
Julian Elischer wrote:


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


A simple example:   libxml2

This package installs include files and libraries and dicumentation
etc.

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

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

What practical problem does installing the include files and man pages
cause you?

I have to delete them from the appliance I'm building up.
So I need to get the manifest, remove the files I want from it, and 
delete every other file mentioned.


This is an appliance class machine. It has 2G of storage and that has 
to  include 2 copies for the OS so we can ping-pong for upgrades.



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



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

Re: harder and harder to avoid pkg

[Julian Elischer]

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

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

On 10/12/16 09:24, Matthieu Volat wrote:


And GNU/Linuxes can be a PITA when you have to track -dev(el) packages
(which sometimes really requires -bin, -app or whatever), or worst, describe
to people how they are supposed to build your software with weird subpackage
names.

I really like that ports provides the software project as intended by
upstream (modulo options).


Just a "me too" here!

Could not agree more.

Please forget that idea.

I just hate having to install libfoo, libfoo-dev, libfoo-dbg,
libfoo-doc, libfoo-whatever each time I need to develop on Linux.
Please do not transform FreeBSD as a Linux distribution :)

I love the way FreeBSD and some very sparse Linux distributions
provide the packages exactly how it would be installed by hand (=
vanilla).

FreeBSD offers some options and very few changes for better
integration but packages are provided vanilla. You want a package? You
install /packagename/ nothing more, nothing less. I really would like
to see simple vanilla packages for the next 10 years.

The FreeBSD ports is already extremely complicated, do not make it
even harder :(

The suggestion is not for ports, but for packages..
a single package could be unpacked in 'runtime only' or 'everything' mode.
basically one package, two manifests.  So no "foo-devel" or "foo-runtime"
just 'foo'



Regards,



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

Re: harder and harder to avoid pkg

[David Demelier]

2016-10-14 8:14 GMT+02:00 Loïc BLOT :
> FreeBSD ports are complicated ?
> Does someone of you tryed to do a Debian package, it's even more
> complicated as you should modify many path, split package in multiple
> packages, do the service engineering with systemV or systemD, etc ?

It's not writing a port that is complicated, it's the whole infrastructure.

-- 
Demelier David
___
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: Alternatives to rsync

[Dewayne Geraghty]

On 14 October 2016 at 17:01, Franco Fichtner  wrote:

>
> > On 14 Oct 2016, at 7:54 AM, Eduardo Morras via freebsd-ports <
> freebsd-ports@freebsd.org> wrote:
> >
> >
> > Sorry for commenting on this reply to Greg to answer Shane Ambler, I
> > joined maillist today.
> >
> > On Fri, 14 Oct 2016 09:26:03 +1100
> > Greg 'groggy' Lehey  wrote:
> >
> >> On Thursday, 13 October 2016 at 18:13:39 +1030, Shane Ambler wrote:
> >>> On 13/10/2016 15:09, reko.turja--- via freebsd-ports wrote:
>  One of my users is needing rsync like functionality to transfer
>  changed contents of some directories between couple of machines.
>  As rsync 3 isn't open source, but GPL3 it's out of question in
>  order to keep the system untainted.
> 
>  The software should be relatively lightweight - no fullblown
>  mirroring/backup is needed. Also hints how to achieve similar ends
>  using maybe tar/ssh might do.
> >>>
> >>> sysutils/cpdup provides similar functionality to rsync and is bsd
> >>> licensed.
> >
> > cpdup in ports comes from old matt dillon pages and is version1.18.
> > DragonflyBSD has version 1.32 at [1][2] and compiles with low effort on
> > FreeBSD.
>
> If there is interest in updating the port we should do it.  I can talk
> to Matt, see if he is willing to release an updated portable version
> with required build fixes (if any).
>
>
> Cheers,
> Franco
> ___
> freebsd-ports@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-ports
> To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
>


Franco, That's probably a good idea as the cpdup homepage has source for
1.09.

Could we be so lucky to include extended attributes and MAC labels in cpdup?
Regards, Dewayne
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: harder and harder to avoid pkg

[Loïc BLOT]

FreeBSD ports are complicated ?
Does someone of you tryed to do a Debian package, it's even more
complicated as you should modify many path, split package in multiple
packages, do the service engineering with systemV or systemD, etc ?
-- 
Best regards,
Loïc BLOT, 
UNIX systems, security and network engineer
http://www.unix-experience.fr


Le jeudi 13 octobre 2016 à 18:08 +0200, Miroslav Lachman a écrit :
> David Demelier wrote on 2016/10/13 14:42:
> > 2016-10-12 10:04 GMT+02:00 Andrea Venturoli :
> > > On 10/12/16 09:24, Matthieu Volat wrote:
> > > 
> > > > And GNU/Linuxes can be a PITA when you have to track -dev(el)
> > > > packages
> > > > (which sometimes really requires -bin, -app or whatever), or
> > > > worst, describe
> > > > to people how they are supposed to build your software with
> > > > weird subpackage
> > > > names.
> > > > 
> > > > I really like that ports provides the software project as
> > > > intended by
> > > > upstream (modulo options).
> > > 
> > > 
> > > Just a "me too" here!
> > 
> > Could not agree more.
> > 
> > Please forget that idea.
> > 
> > I just hate having to install libfoo, libfoo-dev, libfoo-dbg,
> > libfoo-doc, libfoo-whatever each time I need to develop on Linux.
> > Please do not transform FreeBSD as a Linux distribution :)
> > 
> > I love the way FreeBSD and some very sparse Linux distributions
> > provide the packages exactly how it would be installed by hand (=
> > vanilla).
> > 
> > FreeBSD offers some options and very few changes for better
> > integration but packages are provided vanilla. You want a package?
> > You
> > install /packagename/ nothing more, nothing less. I really would
> > like
> > to see simple vanilla packages for the next 10 years.
> > 
> > The FreeBSD ports is already extremely complicated, do not make it
> > even harder :(
> 
> +1 for this!
> 
> Miroslav Lachman
> 
> ___
> freebsd-ports@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-ports
> To unsubscribe, send any mail to "freebsd-ports-unsubscribe@freebsd.o
> rg"
___
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: Alternatives to rsync

[Franco Fichtner]

> On 14 Oct 2016, at 7:54 AM, Eduardo Morras via freebsd-ports 
>  wrote:
> 
> 
> Sorry for commenting on this reply to Greg to answer Shane Ambler, I
> joined maillist today.
> 
> On Fri, 14 Oct 2016 09:26:03 +1100
> Greg 'groggy' Lehey  wrote:
> 
>> On Thursday, 13 October 2016 at 18:13:39 +1030, Shane Ambler wrote:
>>> On 13/10/2016 15:09, reko.turja--- via freebsd-ports wrote:
 One of my users is needing rsync like functionality to transfer
 changed contents of some directories between couple of machines.
 As rsync 3 isn't open source, but GPL3 it's out of question in
 order to keep the system untainted.
 
 The software should be relatively lightweight - no fullblown
 mirroring/backup is needed. Also hints how to achieve similar ends
 using maybe tar/ssh might do.
>>> 
>>> sysutils/cpdup provides similar functionality to rsync and is bsd
>>> licensed.
> 
> cpdup in ports comes from old matt dillon pages and is version1.18.
> DragonflyBSD has version 1.32 at [1][2] and compiles with low effort on
> FreeBSD.

If there is interest in updating the port we should do it.  I can talk
to Matt, see if he is willing to release an updated portable version
with required build fixes (if any).


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