Re: Is pkg quarterly really needed?

[Kurt Jaeger]

Hi!

> >> I understand that the main problem with quarterly branches is that they
> >> start from an unstable edge and mature with time, then after three
> >> months at the most mature point they are being deleted and replaced with
> >> a new unstable edge. So, there is no good point of reference to use as a
> >> source of packages.
[how stable the repos appear for the users]

> I hardly remember a single upgrade to 
> the longest set that didn't result in some packages being broken. [...]
> most of those breakages resulted from me selecting non-standard options 

Ah, options. Leads to exploding complexity.

> So, my experience is quite different to yours...

Indeed.

> If the whole repository builds doesn't it mean by default that any 
> subset also builds?

If we defined a repo build only as valid if everything builds,
the whole repo is never valid, because approx. 10% of
the ports tree breaks at any given time. More, if you add options.

> My assumption was that only version 
> upgrades are progressed from CURRENT to STABLE to RELEASE.

Leads to a stagnating tree downstream, if you find maintainers for it.
That's the model Debian is using, and it has other issues. Especially
the load for the maintainers is huge, and users are unhappy
that the packages are getting old. Debian has approx. 6 times
more committers than we have, when I last looked, and more maintainers.

If we take from that that we have to grow our committer base, yes.
Can we reason that unless we have that base, we can't follow that
model ? Maybe.

> On the other hand developers would be more inclined to do changes in 
> CURRENT if they know that they are not going to break ports for the 
> majority of users who should use STABLE or RELEASE.

This fear to break something is not a big issue in general.
This is covered by build-tests using poudriere, most of the time.

It is an issue for those ports where lots of things depend on a
port, because of changes to that port that lead to cascading
failures.

> > It's just that asking the team that's barely keeping up
> > to do that *on top*, that will probably not work.

> That was supposed to be more like *instead* rather than *on top*.

As long as we're not plundering countries, we normally do not burn
the ships until it's safe to proceed 8-}

> >> From that short description it should be more or less
> >> obvious if that approach is better/doable when opposed to quarterly
> >> branches?

> > There's a way to find out: Try it.

> Not the best way TBH. I would rather hear some opinions first as I am 
> sure there are plenty of conditions and requirements I haven't even 
> imagined myself yet.

It's a good approach to learn about the requirements etc. Most
of the knowledge is, from what I understand, not documented
in a way that helps to write a requirements document. It's in
the code of the currently running system, like layers of
ashes in old cities. Reading those layers requires a certain mindset.

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

Re: manpath change for ports ?

[Mathieu Arnold]

Le 21/04/2017 à 00:21, Baptiste Daroussin a écrit :
> On Fri, Apr 21, 2017 at 12:18:53AM +0200, Mathieu Arnold wrote:
>> Le 21/04/2017 à 00:16, Baptiste Daroussin a écrit :
>>> On Fri, Apr 21, 2017 at 12:13:52AM +0200, Mathieu Arnold wrote:
 Le 20/04/2017 à 23:21, Baptiste Daroussin a écrit :
> On Thu, Apr 20, 2017 at 11:18:14PM +0200, Koop Mast wrote:
>> On Tue, 2017-03-07 at 00:56 +0100, Baptiste Daroussin wrote:
>>> Hi all,
>>>
>>> I would like to propose a change in the localbase hier for ports
>>>
>>> I think we should add /usr/local/share/man in the manpath along with
>>> at first
>>> and maybe instead of in long term.
>>>
>>> The reason is:
>>> - /usr/local/share/man seems more consistent to me with base which
>>> have:
>>>   /usr/share/man
>>> - It will remove lots of patches from the ports tree where were we
>>> need to patch
>>>   upstream build system to install in a non usual path.
>>>
>>> My proposal is to add to the manpath /usr/local/share/man in default
>>> man(1)
>>> command in FreeBSD 12 (MFCed to 11-STABLE)
>>>
>>> and either provide an errata for 11.0/10.3 or a
>>> /usr/local/etc/man.d/something.conf via a port or something like that
>>> for those
>>> two, what do you think?
>>>
>>> For the same reason I would like to allow porters to stop patching
>>> (with pathfix
>>> or anything else) the path for pkgconfig files and allow
>>> /usr/local/lib/pkgconfig along with the current
>>> /usr/local/libdata/pkgconfig:/usr/libdata/pkgconfig
>>>
>>> Which will also remove tons of hacks from the ports tree.
>>>
>>> What do you think?
>>>
>>> Best regards,
>>> Bapt
>> Hello,
>>
>> I recently committed the USES for the meson build system to ports. This
>> USES configures the meson build system with some default variables
>> which includes the location of the man pages. This setting is just a
>> flag to the meson command so it easy to change.
>>
>> Meson also handles the generation and installation of pkg-config files
>> that a port wants. The problem is that this is handled by the script
>> itself and there is no way to configure it, so we need to hack the
>> meson port to change it from lib/pkg-config to libdata/pkg-config like
>> we currently are using. (1) Or add a hack to meson.mk to move the pkg-
>> config to the right location (evil++ imho).
>>
>> My point I want to make is that currently there is only 1 port build
>> via the meson system (graphics/graphene). Should we change man/pkg-
>> config file locations now, it very easy. If we want to change them
>> later we will need to mass bump every meson build port. It is important
>> to note that GStreamer and GNOME are moving over to using meson instead
>> of autotools and that Wayland, Xorg en Mesa are exploring want is
>> needed to make the switch. So I think it important that the decision
>> what to do is done now and that we stick with it.
>>
>> Reading the rest of the thread it seems nobody is really against the
>> proposed change of man and pkg-config path's. So how does one submit a
>> policy change like this? I'm also not sure I'm the right person to push
>> this, I just got back from a break and I don't want to really deal with
>> something super high profile right away.
>>
>> -Koop
>>
>> (1) I would like to see lib/pkg-config back in the search path of
>> pkgconf since that means I don't have to do a crash course python
>> programming.
> Would be nice is portmgr can step on this, let's reduce this discussion 
> for now
> on pkgconf.
 I am waiting on an exp-run to fix this once and for all.

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

 When that is committed, anything can be added to the path pkgconfig
 searches, ports will always install it in the right place.

>>> Sorry but why? why not moving libdata/pkgconfig to lib/pkgconfig? what is 
>>> the
>>> rationale?
>> Because a lot of build software know that on FreeBSD, the .pc file go in
>> libdata/pkgconfig. If we move to some other place, we'll have a
>> USES=pathfixmore for the next 25 years until everyone understands we
>> moved it some place else.
>>
> ok a point for you there :)

I have no problems having lib/pkgconfig added to the search path so that
people who build stuff manually have their .pc files in a place where
pkg-config can read them, but I really do not want the ports to install
them in more than one place.
My PR solves that problem, all the ports will forcibly end up in
libdata/pkgconfig, we could even drop USES=pathfix.

-- 
Mathieu Arnold




signature.asc
Description: OpenPGP digital signature

Re: manpath change for ports ?

[Baptiste Daroussin]

On Fri, Apr 21, 2017 at 12:18:53AM +0200, Mathieu Arnold wrote:
> Le 21/04/2017 à 00:16, Baptiste Daroussin a écrit :
> > On Fri, Apr 21, 2017 at 12:13:52AM +0200, Mathieu Arnold wrote:
> >> Le 20/04/2017 à 23:21, Baptiste Daroussin a écrit :
> >>> On Thu, Apr 20, 2017 at 11:18:14PM +0200, Koop Mast wrote:
>  On Tue, 2017-03-07 at 00:56 +0100, Baptiste Daroussin wrote:
> > Hi all,
> >
> > I would like to propose a change in the localbase hier for ports
> >
> > I think we should add /usr/local/share/man in the manpath along with
> > at first
> > and maybe instead of in long term.
> >
> > The reason is:
> > - /usr/local/share/man seems more consistent to me with base which
> > have:
> >   /usr/share/man
> > - It will remove lots of patches from the ports tree where were we
> > need to patch
> >   upstream build system to install in a non usual path.
> >
> > My proposal is to add to the manpath /usr/local/share/man in default
> > man(1)
> > command in FreeBSD 12 (MFCed to 11-STABLE)
> >
> > and either provide an errata for 11.0/10.3 or a
> > /usr/local/etc/man.d/something.conf via a port or something like that
> > for those
> > two, what do you think?
> >
> > For the same reason I would like to allow porters to stop patching
> > (with pathfix
> > or anything else) the path for pkgconfig files and allow
> > /usr/local/lib/pkgconfig along with the current
> > /usr/local/libdata/pkgconfig:/usr/libdata/pkgconfig
> >
> > Which will also remove tons of hacks from the ports tree.
> >
> > What do you think?
> >
> > Best regards,
> > Bapt
>  Hello,
> 
>  I recently committed the USES for the meson build system to ports. This
>  USES configures the meson build system with some default variables
>  which includes the location of the man pages. This setting is just a
>  flag to the meson command so it easy to change.
> 
>  Meson also handles the generation and installation of pkg-config files
>  that a port wants. The problem is that this is handled by the script
>  itself and there is no way to configure it, so we need to hack the
>  meson port to change it from lib/pkg-config to libdata/pkg-config like
>  we currently are using. (1) Or add a hack to meson.mk to move the pkg-
>  config to the right location (evil++ imho).
> 
>  My point I want to make is that currently there is only 1 port build
>  via the meson system (graphics/graphene). Should we change man/pkg-
>  config file locations now, it very easy. If we want to change them
>  later we will need to mass bump every meson build port. It is important
>  to note that GStreamer and GNOME are moving over to using meson instead
>  of autotools and that Wayland, Xorg en Mesa are exploring want is
>  needed to make the switch. So I think it important that the decision
>  what to do is done now and that we stick with it.
> 
>  Reading the rest of the thread it seems nobody is really against the
>  proposed change of man and pkg-config path's. So how does one submit a
>  policy change like this? I'm also not sure I'm the right person to push
>  this, I just got back from a break and I don't want to really deal with
>  something super high profile right away.
> 
>  -Koop
> 
>  (1) I would like to see lib/pkg-config back in the search path of
>  pkgconf since that means I don't have to do a crash course python
>  programming.
> >>> Would be nice is portmgr can step on this, let's reduce this discussion 
> >>> for now
> >>> on pkgconf.
> >>
> >> I am waiting on an exp-run to fix this once and for all.
> >>
> >> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=218067
> >>
> >> When that is committed, anything can be added to the path pkgconfig
> >> searches, ports will always install it in the right place.
> >>
> > Sorry but why? why not moving libdata/pkgconfig to lib/pkgconfig? what is 
> > the
> > rationale?
> Because a lot of build software know that on FreeBSD, the .pc file go in
> libdata/pkgconfig. If we move to some other place, we'll have a
> USES=pathfixmore for the next 25 years until everyone understands we
> moved it some place else.
> 
ok a point for you there :)

Bapt


signature.asc
Description: PGP signature

Re: manpath change for ports ?

[Mathieu Arnold]

Le 21/04/2017 à 00:16, Baptiste Daroussin a écrit :
> On Fri, Apr 21, 2017 at 12:13:52AM +0200, Mathieu Arnold wrote:
>> Le 20/04/2017 à 23:21, Baptiste Daroussin a écrit :
>>> On Thu, Apr 20, 2017 at 11:18:14PM +0200, Koop Mast wrote:
 On Tue, 2017-03-07 at 00:56 +0100, Baptiste Daroussin wrote:
> Hi all,
>
> I would like to propose a change in the localbase hier for ports
>
> I think we should add /usr/local/share/man in the manpath along with
> at first
> and maybe instead of in long term.
>
> The reason is:
> - /usr/local/share/man seems more consistent to me with base which
> have:
>   /usr/share/man
> - It will remove lots of patches from the ports tree where were we
> need to patch
>   upstream build system to install in a non usual path.
>
> My proposal is to add to the manpath /usr/local/share/man in default
> man(1)
> command in FreeBSD 12 (MFCed to 11-STABLE)
>
> and either provide an errata for 11.0/10.3 or a
> /usr/local/etc/man.d/something.conf via a port or something like that
> for those
> two, what do you think?
>
> For the same reason I would like to allow porters to stop patching
> (with pathfix
> or anything else) the path for pkgconfig files and allow
> /usr/local/lib/pkgconfig along with the current
> /usr/local/libdata/pkgconfig:/usr/libdata/pkgconfig
>
> Which will also remove tons of hacks from the ports tree.
>
> What do you think?
>
> Best regards,
> Bapt
 Hello,

 I recently committed the USES for the meson build system to ports. This
 USES configures the meson build system with some default variables
 which includes the location of the man pages. This setting is just a
 flag to the meson command so it easy to change.

 Meson also handles the generation and installation of pkg-config files
 that a port wants. The problem is that this is handled by the script
 itself and there is no way to configure it, so we need to hack the
 meson port to change it from lib/pkg-config to libdata/pkg-config like
 we currently are using. (1) Or add a hack to meson.mk to move the pkg-
 config to the right location (evil++ imho).

 My point I want to make is that currently there is only 1 port build
 via the meson system (graphics/graphene). Should we change man/pkg-
 config file locations now, it very easy. If we want to change them
 later we will need to mass bump every meson build port. It is important
 to note that GStreamer and GNOME are moving over to using meson instead
 of autotools and that Wayland, Xorg en Mesa are exploring want is
 needed to make the switch. So I think it important that the decision
 what to do is done now and that we stick with it.

 Reading the rest of the thread it seems nobody is really against the
 proposed change of man and pkg-config path's. So how does one submit a
 policy change like this? I'm also not sure I'm the right person to push
 this, I just got back from a break and I don't want to really deal with
 something super high profile right away.

 -Koop

 (1) I would like to see lib/pkg-config back in the search path of
 pkgconf since that means I don't have to do a crash course python
 programming.
>>> Would be nice is portmgr can step on this, let's reduce this discussion for 
>>> now
>>> on pkgconf.
>>
>> I am waiting on an exp-run to fix this once and for all.
>>
>> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=218067
>>
>> When that is committed, anything can be added to the path pkgconfig
>> searches, ports will always install it in the right place.
>>
> Sorry but why? why not moving libdata/pkgconfig to lib/pkgconfig? what is the
> rationale?
Because a lot of build software know that on FreeBSD, the .pc file go in
libdata/pkgconfig. If we move to some other place, we'll have a
USES=pathfixmore for the next 25 years until everyone understands we
moved it some place else.


-- 
Mathieu Arnold




signature.asc
Description: OpenPGP digital signature

Re: manpath change for ports ?

[Baptiste Daroussin]

On Fri, Apr 21, 2017 at 12:13:52AM +0200, Mathieu Arnold wrote:
> Le 20/04/2017 à 23:21, Baptiste Daroussin a écrit :
> > On Thu, Apr 20, 2017 at 11:18:14PM +0200, Koop Mast wrote:
> >> On Tue, 2017-03-07 at 00:56 +0100, Baptiste Daroussin wrote:
> >>> Hi all,
> >>>
> >>> I would like to propose a change in the localbase hier for ports
> >>>
> >>> I think we should add /usr/local/share/man in the manpath along with
> >>> at first
> >>> and maybe instead of in long term.
> >>>
> >>> The reason is:
> >>> - /usr/local/share/man seems more consistent to me with base which
> >>> have:
> >>>   /usr/share/man
> >>> - It will remove lots of patches from the ports tree where were we
> >>> need to patch
> >>>   upstream build system to install in a non usual path.
> >>>
> >>> My proposal is to add to the manpath /usr/local/share/man in default
> >>> man(1)
> >>> command in FreeBSD 12 (MFCed to 11-STABLE)
> >>>
> >>> and either provide an errata for 11.0/10.3 or a
> >>> /usr/local/etc/man.d/something.conf via a port or something like that
> >>> for those
> >>> two, what do you think?
> >>>
> >>> For the same reason I would like to allow porters to stop patching
> >>> (with pathfix
> >>> or anything else) the path for pkgconfig files and allow
> >>> /usr/local/lib/pkgconfig along with the current
> >>> /usr/local/libdata/pkgconfig:/usr/libdata/pkgconfig
> >>>
> >>> Which will also remove tons of hacks from the ports tree.
> >>>
> >>> What do you think?
> >>>
> >>> Best regards,
> >>> Bapt
> >> Hello,
> >>
> >> I recently committed the USES for the meson build system to ports. This
> >> USES configures the meson build system with some default variables
> >> which includes the location of the man pages. This setting is just a
> >> flag to the meson command so it easy to change.
> >>
> >> Meson also handles the generation and installation of pkg-config files
> >> that a port wants. The problem is that this is handled by the script
> >> itself and there is no way to configure it, so we need to hack the
> >> meson port to change it from lib/pkg-config to libdata/pkg-config like
> >> we currently are using. (1) Or add a hack to meson.mk to move the pkg-
> >> config to the right location (evil++ imho).
> >>
> >> My point I want to make is that currently there is only 1 port build
> >> via the meson system (graphics/graphene). Should we change man/pkg-
> >> config file locations now, it very easy. If we want to change them
> >> later we will need to mass bump every meson build port. It is important
> >> to note that GStreamer and GNOME are moving over to using meson instead
> >> of autotools and that Wayland, Xorg en Mesa are exploring want is
> >> needed to make the switch. So I think it important that the decision
> >> what to do is done now and that we stick with it.
> >>
> >> Reading the rest of the thread it seems nobody is really against the
> >> proposed change of man and pkg-config path's. So how does one submit a
> >> policy change like this? I'm also not sure I'm the right person to push
> >> this, I just got back from a break and I don't want to really deal with
> >> something super high profile right away.
> >>
> >> -Koop
> >>
> >> (1) I would like to see lib/pkg-config back in the search path of
> >> pkgconf since that means I don't have to do a crash course python
> >> programming.
> > Would be nice is portmgr can step on this, let's reduce this discussion for 
> > now
> > on pkgconf.
> 
> 
> I am waiting on an exp-run to fix this once and for all.
> 
> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=218067
> 
> When that is committed, anything can be added to the path pkgconfig
> searches, ports will always install it in the right place.
> 
Sorry but why? why not moving libdata/pkgconfig to lib/pkgconfig? what is the
rationale?

Bapt


signature.asc
Description: PGP signature

Re: manpath change for ports ?

[Mathieu Arnold]

Le 20/04/2017 à 23:21, Baptiste Daroussin a écrit :
> On Thu, Apr 20, 2017 at 11:18:14PM +0200, Koop Mast wrote:
>> On Tue, 2017-03-07 at 00:56 +0100, Baptiste Daroussin wrote:
>>> Hi all,
>>>
>>> I would like to propose a change in the localbase hier for ports
>>>
>>> I think we should add /usr/local/share/man in the manpath along with
>>> at first
>>> and maybe instead of in long term.
>>>
>>> The reason is:
>>> - /usr/local/share/man seems more consistent to me with base which
>>> have:
>>>   /usr/share/man
>>> - It will remove lots of patches from the ports tree where were we
>>> need to patch
>>>   upstream build system to install in a non usual path.
>>>
>>> My proposal is to add to the manpath /usr/local/share/man in default
>>> man(1)
>>> command in FreeBSD 12 (MFCed to 11-STABLE)
>>>
>>> and either provide an errata for 11.0/10.3 or a
>>> /usr/local/etc/man.d/something.conf via a port or something like that
>>> for those
>>> two, what do you think?
>>>
>>> For the same reason I would like to allow porters to stop patching
>>> (with pathfix
>>> or anything else) the path for pkgconfig files and allow
>>> /usr/local/lib/pkgconfig along with the current
>>> /usr/local/libdata/pkgconfig:/usr/libdata/pkgconfig
>>>
>>> Which will also remove tons of hacks from the ports tree.
>>>
>>> What do you think?
>>>
>>> Best regards,
>>> Bapt
>> Hello,
>>
>> I recently committed the USES for the meson build system to ports. This
>> USES configures the meson build system with some default variables
>> which includes the location of the man pages. This setting is just a
>> flag to the meson command so it easy to change.
>>
>> Meson also handles the generation and installation of pkg-config files
>> that a port wants. The problem is that this is handled by the script
>> itself and there is no way to configure it, so we need to hack the
>> meson port to change it from lib/pkg-config to libdata/pkg-config like
>> we currently are using. (1) Or add a hack to meson.mk to move the pkg-
>> config to the right location (evil++ imho).
>>
>> My point I want to make is that currently there is only 1 port build
>> via the meson system (graphics/graphene). Should we change man/pkg-
>> config file locations now, it very easy. If we want to change them
>> later we will need to mass bump every meson build port. It is important
>> to note that GStreamer and GNOME are moving over to using meson instead
>> of autotools and that Wayland, Xorg en Mesa are exploring want is
>> needed to make the switch. So I think it important that the decision
>> what to do is done now and that we stick with it.
>>
>> Reading the rest of the thread it seems nobody is really against the
>> proposed change of man and pkg-config path's. So how does one submit a
>> policy change like this? I'm also not sure I'm the right person to push
>> this, I just got back from a break and I don't want to really deal with
>> something super high profile right away.
>>
>> -Koop
>>
>> (1) I would like to see lib/pkg-config back in the search path of
>> pkgconf since that means I don't have to do a crash course python
>> programming.
> Would be nice is portmgr can step on this, let's reduce this discussion for 
> now
> on pkgconf.


I am waiting on an exp-run to fix this once and for all.

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

When that is committed, anything can be added to the path pkgconfig
searches, ports will always install it in the right place.


-- 
Mathieu Arnold




signature.asc
Description: OpenPGP digital signature

Re: manpath change for ports ?

[Baptiste Daroussin]

On Thu, Apr 20, 2017 at 11:18:14PM +0200, Koop Mast wrote:
> On Tue, 2017-03-07 at 00:56 +0100, Baptiste Daroussin wrote:
> > Hi all,
> > 
> > I would like to propose a change in the localbase hier for ports
> > 
> > I think we should add /usr/local/share/man in the manpath along with
> > at first
> > and maybe instead of in long term.
> > 
> > The reason is:
> > - /usr/local/share/man seems more consistent to me with base which
> > have:
> >   /usr/share/man
> > - It will remove lots of patches from the ports tree where were we
> > need to patch
> >   upstream build system to install in a non usual path.
> > 
> > My proposal is to add to the manpath /usr/local/share/man in default
> > man(1)
> > command in FreeBSD 12 (MFCed to 11-STABLE)
> > 
> > and either provide an errata for 11.0/10.3 or a
> > /usr/local/etc/man.d/something.conf via a port or something like that
> > for those
> > two, what do you think?
> > 
> > For the same reason I would like to allow porters to stop patching
> > (with pathfix
> > or anything else) the path for pkgconfig files and allow
> > /usr/local/lib/pkgconfig along with the current
> > /usr/local/libdata/pkgconfig:/usr/libdata/pkgconfig
> > 
> > Which will also remove tons of hacks from the ports tree.
> > 
> > What do you think?
> > 
> > Best regards,
> > Bapt
> 
> Hello,
> 
> I recently committed the USES for the meson build system to ports. This
> USES configures the meson build system with some default variables
> which includes the location of the man pages. This setting is just a
> flag to the meson command so it easy to change.
> 
> Meson also handles the generation and installation of pkg-config files
> that a port wants. The problem is that this is handled by the script
> itself and there is no way to configure it, so we need to hack the
> meson port to change it from lib/pkg-config to libdata/pkg-config like
> we currently are using. (1) Or add a hack to meson.mk to move the pkg-
> config to the right location (evil++ imho).
> 
> My point I want to make is that currently there is only 1 port build
> via the meson system (graphics/graphene). Should we change man/pkg-
> config file locations now, it very easy. If we want to change them
> later we will need to mass bump every meson build port. It is important
> to note that GStreamer and GNOME are moving over to using meson instead
> of autotools and that Wayland, Xorg en Mesa are exploring want is
> needed to make the switch. So I think it important that the decision
> what to do is done now and that we stick with it.
> 
> Reading the rest of the thread it seems nobody is really against the
> proposed change of man and pkg-config path's. So how does one submit a
> policy change like this? I'm also not sure I'm the right person to push
> this, I just got back from a break and I don't want to really deal with
> something super high profile right away.
> 
> -Koop
> 
> (1) I would like to see lib/pkg-config back in the search path of
> pkgconf since that means I don't have to do a crash course python
> programming.

Would be nice is portmgr can step on this, let's reduce this discussion for now
on pkgconf.

Best regards,
Bapt


signature.asc
Description: PGP signature

Re: How to use cached packages

[Miroslav Lachman]

Freddie Cash wrote on 2017/04/20 22:39:

On Thu, Apr 20, 2017 at 1:36 PM, Miroslav Lachman <000.f...@quip.cz
>wrote:

Freddie Cash wrote on 2017/04/20 22:17:

On Thu, Apr 20, 2017 at 11:58 AM, Patrick Powell
>
wrote:

I ran into a problem where I needed to reinstall a package.
However,  I
did not have network access to the pkg repository.  I did
have a system
which had all of the pkgs which I needed in the pkg cache.
I can easily
copy these to the system,  as well as the pkg database, etc.

So:  is there a SIMPLE way to have pkg check to see if a pkg
is already in
the pkg cache and use that before trying to go to the
repository?

Is there a SIMPLE way to prevent pkg from trying to check
the pkg
repository for an update?

I strongly suspect that something like:

pkg --do_not_check_for_latest_version --use_cached_pkg
install firefox

Any help on this before I tear out the three strands of hair
I have left
would be appreciated.



​If you have the .txz/.tbz package file, then it's a simple:

# pkg install /path/to/firefox-versions-blahblah.txz


I think it is "pkg add /var/cache/pkg/firefox-versions-blahblah.txz"


​Both work.  "pkg add" is there for backward compat with the old way
(pkg_add).  "pkg install" can install from remote repos or local files.
From the man pages:

​DESCRIPTION
  pkg install is used for installation of packages from package
reposito-
  ries or local archives.  Multiple package names can be specified
on the
  command line, either explicitly orby matching against package
names (or
  origins) in the repositorycatalogues using shell globbingor regular
  expressions.


DESCRIPTION
  pkg add installs packages from either a local source or a remote one.

  When installing from a remote source you need to specify the
protocol to
  use when fetching the package.


​For ease of use, "pkg install" works for everything.  :)​


I do not remember exactly why I am using pkg add. Maybe pkg install did 
not work for me in the past (when downgrading from /var/cache/pkg) or 
maybe because pkg add will not try to fetch from repo defined in 
/usr/local/etc/


Anyway good to know both works :)

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: Is pkg quarterly really needed?

[Grzegorz Junka]

Hi :)

On 20/04/2017 19:57, Kurt Jaeger wrote:

Hi!


I understand that the main problem with quarterly branches is that they
start from an unstable edge and mature with time, then after three
months at the most mature point they are being deleted and replaced with
a new unstable edge. So, there is no good point of reference to use as a
source of packages.

First, let me say that for my use cases, the pkg tree is in consistent
state most of the time. We have a set of approx. 2500 pkg's build etc,
so roughly 10% of the full repo. We update the ports tree and build the
repo every week, just to see if all is fine, and we update
and build, if we need a package we do not yet have in our repo.
For the thrills, look at our repo at https://repo.nepustil.net


I am maintaining four sets of pkg's for my desktop, laptop and server 
(in two variants) - anything between 100 to 1300 pkg's resulted from 
selecting around 10-200 ports depending on the set. I usually first 
build for my desktop, then if everything is fine I rebuild the set for 
my laptop, and finally the server. I hardly remember a single upgrade to 
the longest set that didn't result in some packages being broken. Sure, 
most of those breakages resulted from me selecting non-standard options 
(but if I wanted standard options then I would simply install from the 
official distribution, wouldn't I?). Only last weekend I filled two bugs 
against ports that didn't compile when either non-default options were 
selected in those packages or in some of their dependent packages.


So, my experience is quite different to yours...


Hmm, let's try this thought experiment.

For each package, keep the whole repo when it was last build sucessfully
(Note: we're not yet discussing whether it runs!)

Worst case: We have n ports and n repos. The question is:
what would be the average case ? Would that be a sustainable model ?

Now, the next question: Even if we have all the repos,
would we find *one* repo where *two* packagew we'd like to have
are in a consistent (build-!)state ? What about the 250+
that are normally needed for a small server ? Or the 1200+
for a multi-role server (some will say: "nah, don't do it, use
container/jails/ whatever virtualisiation").


If the whole repository builds doesn't it mean by default that any 
subset also builds? All packages are build incrementally, the packages 
that don't depend on any other packages are build first, then any 
packages that depend on them, and so on. Sure, it doesn't mean that they 
also run properly, but that's a different story. If packages are build 
then people can install them and fill bugs. That would be the reason for 
having CURRENT, STABLE and RELEASE where fixes would be gradually 
progressed between them.



What I described is taking the good points (maturing the code through
progressing version upgrades from CURRENT, through STABLE to RELEASE)

Now, if we have ports-HEAD, and changes to that (especially fixes and
features to the ports infrastructure), it's getting more and more difficult
to backport fixes from ports-HEAD to the ports-STABLE versions, because
those do not contain dependencies and infrastructure changes.
If we backport those, we have to roll forward some other
changes. This gets out of hand very quickly.


I see where you are getting at. My assumption was that only version 
upgrades are progressed from CURRENT to STABLE to RELEASE. If a port 
can't be progressed because it requires infrastructure change then, 
well, it won't. STABLE and then RELEASE are meant to be more stable so 
we would prefer older versions that work rather than new versions that 
break. Infrastructure changes would have to be progressed eventually but 
that could be done in batches where most fixes in more edge branches 
have been fixed.



So:

If we take the sum of the brain time our maintainers and committers
deliver to keep HEAD in a moving (different from a stagnating) state,
and try to estimate how much *more* time would be needed to
keep additional trees in working conditions, only updating
what is needed, under the assumption that infrastructure changes
*need* to happen ? What would that additional brain time be ?
My inituition tells me that it would probably break the model.


On the other hand developers would be more inclined to do changes in 
CURRENT if they know that they are not going to break ports for the 
majority of users who should use STABLE or RELEASE. According to the 
principle "Failing by design 
". They would be also more 
confident when porting changes to more stable branches knowing that they 
have been tested by many users and if something could have gone wrong 
most likely already did.




Now, if someone wants to *experiment* with that, we
already have quite a few people doing that: By setting up
our own repo boxes, where we build the trees to our liking.


I am not trying to solve the problem for myself. I already have my own 
repo box. I 

Re: manpath change for ports ?

[Koop Mast]

On Tue, 2017-03-07 at 00:56 +0100, Baptiste Daroussin wrote:
> Hi all,
> 
> I would like to propose a change in the localbase hier for ports
> 
> I think we should add /usr/local/share/man in the manpath along with
> at first
> and maybe instead of in long term.
> 
> The reason is:
> - /usr/local/share/man seems more consistent to me with base which
> have:
>   /usr/share/man
> - It will remove lots of patches from the ports tree where were we
> need to patch
>   upstream build system to install in a non usual path.
> 
> My proposal is to add to the manpath /usr/local/share/man in default
> man(1)
> command in FreeBSD 12 (MFCed to 11-STABLE)
> 
> and either provide an errata for 11.0/10.3 or a
> /usr/local/etc/man.d/something.conf via a port or something like that
> for those
> two, what do you think?
> 
> For the same reason I would like to allow porters to stop patching
> (with pathfix
> or anything else) the path for pkgconfig files and allow
> /usr/local/lib/pkgconfig along with the current
> /usr/local/libdata/pkgconfig:/usr/libdata/pkgconfig
> 
> Which will also remove tons of hacks from the ports tree.
> 
> What do you think?
> 
> Best regards,
> Bapt

Hello,

I recently committed the USES for the meson build system to ports. This
USES configures the meson build system with some default variables
which includes the location of the man pages. This setting is just a
flag to the meson command so it easy to change.

Meson also handles the generation and installation of pkg-config files
that a port wants. The problem is that this is handled by the script
itself and there is no way to configure it, so we need to hack the
meson port to change it from lib/pkg-config to libdata/pkg-config like
we currently are using. (1) Or add a hack to meson.mk to move the pkg-
config to the right location (evil++ imho).

My point I want to make is that currently there is only 1 port build
via the meson system (graphics/graphene). Should we change man/pkg-
config file locations now, it very easy. If we want to change them
later we will need to mass bump every meson build port. It is important
to note that GStreamer and GNOME are moving over to using meson instead
of autotools and that Wayland, Xorg en Mesa are exploring want is
needed to make the switch. So I think it important that the decision
what to do is done now and that we stick with it.

Reading the rest of the thread it seems nobody is really against the
proposed change of man and pkg-config path's. So how does one submit a
policy change like this? I'm also not sure I'm the right person to push
this, I just got back from a break and I don't want to really deal with
something super high profile right away.

-Koop

(1) I would like to see lib/pkg-config back in the search path of
pkgconf since that means I don't have to do a crash course python
programming.
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: How to use cached packages

[Freddie Cash]

On Thu, Apr 20, 2017 at 1:36 PM, Miroslav Lachman <000.f...@quip.cz> wrote:

> Freddie Cash wrote on 2017/04/20 22:17:
>
>> On Thu, Apr 20, 2017 at 11:58 AM, Patrick Powell 
>> wrote:
>>
>> I ran into a problem where I needed to reinstall a package. However,  I
>>> did not have network access to the pkg repository.  I did have a system
>>> which had all of the pkgs which I needed in the pkg cache.  I can easily
>>> copy these to the system,  as well as the pkg database, etc.
>>>
>>> So:  is there a SIMPLE way to have pkg check to see if a pkg is already
>>> in
>>> the pkg cache and use that before trying to go to the repository?
>>>
>>> Is there a SIMPLE way to prevent pkg from trying to check the pkg
>>> repository for an update?
>>>
>>> I strongly suspect that something like:
>>>
>>> pkg --do_not_check_for_latest_version --use_cached_pkg install firefox
>>>
>>> Any help on this before I tear out the three strands of hair I have left
>>> would be appreciated.
>>>
>>
>>
>> ​If you have the .txz/.tbz package file, then it's a simple:
>>
>> # pkg install /path/to/firefox-versions-blahblah.txz
>>
>
> I think it is "pkg add /var/cache/pkg/firefox-versions-blahblah.txz"
>

​Both work.  "pkg add" is there for backward compat with the old way
(pkg_add).  "pkg install" can install from remote repos or local files.
From the man pages:

​DESCRIPTION
 pkg install is used for installation of packages from package reposito-
 ries or local archives.  Multiple package names can be specified on the
 command line, either explicitly or by matching against package names
(or
 origins) in the repository catalogues using shell globbing or regular
 expressions.


DESCRIPTION
 pkg add installs packages from either a local source or a remote one.

 When installing from a remote source you need to specify the protocol
to
 use when fetching the package.


​For ease of use, "pkg install" works for everything.  :)​

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

Re: How to use cached packages

[Miroslav Lachman]

Freddie Cash wrote on 2017/04/20 22:17:

On Thu, Apr 20, 2017 at 11:58 AM, Patrick Powell 
wrote:


I ran into a problem where I needed to reinstall a package. However,  I
did not have network access to the pkg repository.  I did have a system
which had all of the pkgs which I needed in the pkg cache.  I can easily
copy these to the system,  as well as the pkg database, etc.

So:  is there a SIMPLE way to have pkg check to see if a pkg is already in
the pkg cache and use that before trying to go to the repository?

Is there a SIMPLE way to prevent pkg from trying to check the pkg
repository for an update?

I strongly suspect that something like:

pkg --do_not_check_for_latest_version --use_cached_pkg install firefox

Any help on this before I tear out the three strands of hair I have left
would be appreciated.



​If you have the .txz/.tbz package file, then it's a simple:

# pkg install /path/to/firefox-versions-blahblah.txz


I think it is "pkg add /var/cache/pkg/firefox-versions-blahblah.txz"


​I believe you can specify multiple packages on the command-line and it
will install them all.  If there are required dependencies, you'll have to
specify them on the command-line as well.  If you specify all the packages
on the CLI, then it won't check the remote repo.

There's also a flag you can add to prevent it from doing a
behind-the-scenes "pkg upgrade" before the​ install.  Ah yes, it's -U or
--no-repo-update.


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: net-mgmt/prometheus update to 1.6.0, comitter requested

[Jev Björsell]

Great, thank you! Any feedback on port structure is welcome by me :)

-Jev

On Thu, Apr 20, 2017 at 11:43 AM Larry Rosenman  wrote:

> Indeed.  I’m working with my Mentor (adamw@, and swills@(of portmgr@))
> and they had the issue with unknown.
>
>
>
> I’ll get this done. ☺
>
>
>
>
>
> --
>
> Larry Rosenman http://www.lerctr.org/~ler
>
> Phone: +1 214-642-9640 <(214)%20642-9640> E-Mail:
> l...@lerctr.org
>
> US Mail: 17716 Limpia Crk, Round Rock, TX 78664-7281
>
>
>
>
>
>
>
> *From: *Jev Björsell 
> *Date: *Thursday, April 20, 2017 at 1:39 PM
> *To: *Larry Rosenman , "freebsd-ports@freebsd.org" <
> freebsd-ports@freebsd.org>
> *Subject: *Re: Re: net-mgmt/prometheus update to 1.6.0, comitter requested
>
>
>
> Hi Larry,
>
>
>
> I presume you are referring the the strings 'unknown' that appear in the
>  do-build: portion of the Makefile.
>
>
>
> These are set to 'unknown' on purpose, because we do not have a way of
> finding out that information unless we do it dynamically at build time.
> Doing dynamically is not recommended for several reasons.
>
>
>
> This data gets displayed when a user runs `prometheus -version`, and most
> of the fields are only really relevant to dev builds anyway.
>
>
>
> The crucial information is the software version number which is set.
>
>
>
> You can see me exchange on the subject in the ports mailing list archive
> here:
>
>
>
> https://lists.freebsd.org/pipermail/freebsd-ports/2017-March/107833.html
>
>
>
> -Jev
>
>
>
>
>
> On Wed, Apr 19, 2017 at 9:23 PM ler  wrote:
>
> Can you fill in the unknown stuff in the version package or should I just
> go ahead and do it?
>
>
>
> On Apr 19, 2017 at 10:22 PM, > wrote:
>
> Thanks Larry,
>
>
>
> I have updated the patch on the bug, because the upstream project has just
> released a minor version/bug fix release. New patch updates us to 1.6.1.
>
>
>
> Thanks,
>
> -Jev
>
>
>
> On Tue, Apr 18, 2017 at 1:22 PM Larry Rosenman  wrote:
>
> On 4/18/17, 2:41 PM, "Jev Björsell"  behalf of j...@ecadlabs.com> wrote:
>
> Hi All,
>
> Could I get a committer to apply my latest update patch for net-mg
> mt/prometheus?
>
> Patch is available here:
> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=218737
>
> Thanks so much,
> -Jev
>
> Waiting for my mentor to approve.
>
>
>
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: How to use cached packages

[Freddie Cash]

On Thu, Apr 20, 2017 at 11:58 AM, Patrick Powell 
wrote:

> I ran into a problem where I needed to reinstall a package. However,  I
> did not have network access to the pkg repository.  I did have a system
> which had all of the pkgs which I needed in the pkg cache.  I can easily
> copy these to the system,  as well as the pkg database, etc.
>
> So:  is there a SIMPLE way to have pkg check to see if a pkg is already in
> the pkg cache and use that before trying to go to the repository?
>
> Is there a SIMPLE way to prevent pkg from trying to check the pkg
> repository for an update?
>
> I strongly suspect that something like:
>
> pkg --do_not_check_for_latest_version --use_cached_pkg install firefox
>
> Any help on this before I tear out the three strands of hair I have left
> would be appreciated.


​If you have the .txz/.tbz package file, then it's a simple:

# pkg install /path/to/firefox-versions-blahblah.txz
​
​I believe you can specify multiple packages on the command-line and it
will install them all.  If there are required dependencies, you'll have to
specify them on the command-line as well.  If you specify all the packages
on the CLI, then it won't check the remote repo.

There's also a flag you can add to prevent it from doing a
behind-the-scenes "pkg upgrade" before the​ install.  Ah yes, it's -U or
--no-repo-update.


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

Re: Is pkg quarterly really needed?

[Kurt Jaeger]

Hi!

> I understand that the main problem with quarterly branches is that they 
> start from an unstable edge and mature with time, then after three 
> months at the most mature point they are being deleted and replaced with 
> a new unstable edge. So, there is no good point of reference to use as a 
> source of packages.

First, let me say that for my use cases, the pkg tree is in consistent
state most of the time. We have a set of approx. 2500 pkg's build etc,
so roughly 10% of the full repo. We update the ports tree and build the
repo every week, just to see if all is fine, and we update
and build, if we need a package we do not yet have in our repo.
For the thrills, look at our repo at https://repo.nepustil.net

Hmm, let's try this thought experiment.

For each package, keep the whole repo when it was last build sucessfully
(Note: we're not yet discussing whether it runs!)

Worst case: We have n ports and n repos. The question is:
what would be the average case ? Would that be a sustainable model ?

Now, the next question: Even if we have all the repos,
would we find *one* repo where *two* packagew we'd like to have
are in a consistent (build-!)state ? What about the 250+
that are normally needed for a small server ? Or the 1200+
for a multi-role server (some will say: "nah, don't do it, use
container/jails/ whatever virtualisiation").

> What I described is taking the good points (maturing the code through 
> progressing version upgrades from CURRENT, through STABLE to RELEASE) 

Now, if we have ports-HEAD, and changes to that (especially fixes and
features to the ports infrastructure), it's getting more and more difficult
to backport fixes from ports-HEAD to the ports-STABLE versions, because
those do not contain dependencies and infrastructure changes.
If we backport those, we have to roll forward some other
changes. This gets out of hand very quickly.

Do we need frequent infrastructure changes ? Yes, because right now
we would not be able to build the tree, if we did not change
some knobs to cope with the newest craziness that upstreams
throw at us. We repeatedly needed relevant infrastructure changes just
to keep up with that outside world. I'm still speechless that
tz@ got php71 into the tree without so few defects. Or the parallel
mysql-variants. We still fail to provide a working maven-mechanism.
Or go-dependencies. Think of it, go apps more and more bring
their own dependencies, because that is somehow unsolved in the go
world. Some folks worked wonders with the multi-arch and cross-build
things. I can build ARM pkg repos on my amd64, that is unheard
of in most parts of the IT universe 8-} We are almost tracking
firefox, even after they added a new language (rust) to their
infrastructure.

So:

If we take the sum of the brain time our maintainers and committers
deliver to keep HEAD in a moving (different from a stagnating) state,
and try to estimate how much *more* time would be needed to
keep additional trees in working conditions, only updating
what is needed, under the assumption that infrastructure changes
*need* to happen ? What would that additional brain time be ? 
My inituition tells me that it would probably break the model.

Now, if someone wants to *experiment* with that, we
already have quite a few people doing that: By setting up
our own repo boxes, where we build the trees to our liking.

The FreeBSD svn commits are public. So, if someone wants
to use it, and select and pick to provide a stable repo,
we would all welcome the effort. If it's a sustained effort over
some time, clusteradm etc would probably add that repo
to the infrastructure. We can even call it the 'caveat'-repo.

It's just that asking the team that's barely keeping up
to do that *on top*, that will probably not work.

[...]
> From that short description it should be more or less 
> obvious if that approach is better/doable when opposed to quarterly 
> branches?

There's a way to find out: Try it.

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

64-bit inodes (ino64) Status Update and Call for Testing

[Konstantin Belousov]

Inodes are data structures corresponding to objects in a file system,
such as files and directories. FreeBSD has historically used 32-bit
values to identify inodes, which limits file systems to somewhat under
2^32 objects. Many modern file systems internally use 64-bit identifiers
and FreeBSD needs to follow suit to properly and fully support these
file systems.

The 64-bit inode project, also known as ino64, started life many years
ago as a project by Gleb Kurtsou (gleb@).  After that time several
people have had a hand in updating it and addressing regressions, after
mckusick@ picked up and updated the patch, and acted as a flag-waver.

Sponsored by the FreeBSD Foundation I have spent a significant effort
on outstanding issues and integration -- fixing compat32 ABI, NFS and
ZFS, addressing ABI compat issues and investigating and fixing ports
failures.  rmacklem@ provided feedback on NFS changes, emaste@ and
jhb@ provided feedback and review on the ABI transition support. pho@
performed extensive testing and identified a number of issues that
have now been fixed.  kris@ performed an initial ports investigation
followed by an exp-run by antoine@. emaste@ helped with organization
of the process.

This note explains how to perform useful testing of the ino64 branch,
beyond typical smoke tests.

1. Overview.

The ino64 branch extends the basic system types ino_t and dev_t from
32-bit to 64-bit, and nlink_t from 16-bit to 64-bit.  The struct dirent
layout is modified due to the larger size of ino_t, and also gains a
d_off (directory offset) member. As ino64 implies an ABI change anyway
the struct statfs f_mntfromname[] and f_mntonname[] array length
MNAMELEN is increased from 88 to 1024, to allow for longer mount path
names.

ABI breakage is mitigated by providing compatibility using versioned
symbols, ingenious use of the existing padding in structures, and by
employing other tricks.  Unfortunately, not everything can be fixed,
especially outside the base system.  For instance, third-party APIs
which pass struct stat around are broken in backward and forward-
incompatible way.

2. Motivation.

The main risk of the ino64 change is the uncontrolled ABI breakage.
Due to expansion of the basic types dev_t, ino_t and struct dirent,
the impact is not limited to one part of the system, but affects:
- kernel/userspace interface (syscalls ABI, mostly stat(2), kinfo
  and more)
- libc interface (mostly related to the readdir(3), FTS(3))
- collateral damage in other libraries that happens to use changed types
  in the interfaces.  See, for instance, libprocstat, for which compat
  was provided using symbol versioning, and libutil, which shlib version
  was bumped.

3. Quirks.

We handled kinfo sysctl MIBs, but other MIBs which report structures
depended on the changed type, are not handled in general.  It was
considered that the breakage is either in the management interfaces,
where we usually allow ABI slip, or is not important.

Struct xvnode changed layout, no compat shims are provided.

For struct xtty, dev_t tty device member was reduced to uint32_t.  It
was decided that keeping ABI compat in this case is more useful than
reporting 64bit dev_t, for the sake of pstat.

4. Testing procedure.

The ino64 project can be tested by cloning the project branch from
GitHub or by applying the patch  to a working tree.  The authorative source is the
GitHub, I do not promise to update the review for each update.

To clone from GitHub:
% git clone -b ino64 https://github.com/FreeBSDFoundation/freebsd.git ino64

To fetch the patch from Phabricator:
- Visit https://reviews.freebsd.org/D10439
- Click "Download Raw Diff" at the upper right of the page

Or
% arc patch D10439

After that, in the checkout directory do
% (cd sys/kern && touch syscalls.master && make sysent)
% (cd sys/compat/freebsd32 && touch syscalls.master && make sysent)
If you use custom kernel configuration, ensure that
options COMPAT_FREEBSD11
is included into the config.  Then build world and kernel in the
usual way, install kernel, reboot, install new world.  Do not make
shortcuts in the update procedure.

4.1 New kernel, old world.

Build and install pristine HEAD world, apply patch and only build and
install updated kernel. The system must work same as with the pristine
kernel.

4.2 New kernel, new world, old third-party applications.

Build and install patched kernel and world.  Applications compiled on the
pristine HEAD (e.g. installed by pkg from the regular portmgr builds) must
work without a regression.

4.3 32bit compat.

Same as 4.1 and 4.2, but for 32bit (i386) binaries on the amd64 host.
Note that big-endian host, like powerpc, might expose additional
bugs in the 32bit compat with the patch, but the testing is too cumbersome
to arrange.

4.4 Targeted tests.

Useful programs to check items 4.1, 4.2 and 4.3 are versions of the
following programs, taken from the pristine system:

  stat(8). Use it on regular file, file in /dev, socket, pipe and 

How to use cached packages

[Patrick Powell]

I ran into a problem where I needed to reinstall a package. However,  I 
did not have network access to the pkg repository.  I did have a system 
which had all of the pkgs which I needed in the pkg cache.  I can easily 
copy these to the system,  as well as the pkg database, etc.


So:  is there a SIMPLE way to have pkg check to see if a pkg is already 
in the pkg cache and use that before trying to go to the repository?


Is there a SIMPLE way to prevent pkg from trying to check the pkg 
repository for an update?


I strongly suspect that something like:

pkg --do_not_check_for_latest_version --use_cached_pkg install firefox

Any help on this before I tear out the three strands of hair I have left 
would be appreciated.


--
Patrick Powell Astart Technologies
papow...@astart.com1530 Jamacha Rd, Suite X
Network and System San Diego, CA 92019
  Consulting   Cell 858-518-7581 FAX 858-751-2435
Web: papowell at astart dot com

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

Re: Is pkg quarterly really needed?

[Grzegorz Junka]

On 20/04/2017 17:11, Kurt Jaeger wrote:

Hi!


Fine, but would that be a good approach? Doesn't it look more like a
process change than a code change?

For me, it does not look like a process-change only.

I haven't thought through all the details, I'm going with my
intuition here (because thinking it through takes a long time).

One number: I made approx. 40 commits to quarterly trees in 2 years,
and broke it one least once, probably more often. Go to

https://secure.freshbsd.org/search?committer=pi

and then limit the view to the 8 quarterlies and check those commits.
It might as well be my sloppiness, but...


Surely, some code would need to be
changed but then again, wouldn't that be mostly configuration?

My gut feeling says it's more than a little change and a bit
of configuration.



I understand that the main problem with quarterly branches is that they 
start from an unstable edge and mature with time, then after three 
months at the most mature point they are being deleted and replaced with 
a new unstable edge. So, there is no good point of reference to use as a 
source of packages.


What I described is taking the good points (maturing the code through 
progressing version upgrades from CURRENT, through STABLE to RELEASE) 
while keeping good builds as reference points (monthly in CURRENT since 
it changes more often and partial builds may be too often for the server 
to handle, fortnightly in STABLE, and weekly in RELEASE since it is 
expected to contain least breaking changes and full builds are preferred 
over partial builds). Only X last builds would be kept for each of these 
three branches. From that short description it should be more or less 
obvious if that approach is better/doable when opposed to quarterly 
branches?


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: net-mgmt/prometheus update to 1.6.0, comitter requested

[Larry Rosenman]

Indeed.  I’m working with my Mentor (adamw@, and swills@(of portmgr@)) and they 
had the issue with unknown.

 

I’ll get this done. ☺ 

 

 

-- 

Larry Rosenman http://www.lerctr.org/~ler

Phone: +1 214-642-9640 E-Mail: l...@lerctr.org

US Mail: 17716 Limpia Crk, Round Rock, TX 78664-7281

 

 

 

From: Jev Björsell 
Date: Thursday, April 20, 2017 at 1:39 PM
To: Larry Rosenman , "freebsd-ports@freebsd.org" 

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

 

Hi Larry,

 

I presume you are referring the the strings 'unknown' that appear in the  
do-build: portion of the Makefile.

 

These are set to 'unknown' on purpose, because we do not have a way of finding 
out that information unless we do it dynamically at build time. Doing 
dynamically is not recommended for several reasons.

 

This data gets displayed when a user runs `prometheus -version`, and most of 
the fields are only really relevant to dev builds anyway.

 

The crucial information is the software version number which is set.

 

You can see me exchange on the subject in the ports mailing list archive here:

 

https://lists.freebsd.org/pipermail/freebsd-ports/2017-March/107833.html

 

-Jev

 

 

On Wed, Apr 19, 2017 at 9:23 PM ler  wrote:

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



On Apr 19, 2017 at 10:22 PM,  wrote: 

Thanks Larry,

 

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

 

Thanks,

-Jev

 

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

On 4/18/17, 2:41 PM, "Jev Björsell"  wrote:

Hi All,

Could I get a committer to apply my latest update patch for net-mg
mt/prometheus?

Patch is available here:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=218737

Thanks so much,
-Jev

Waiting for my mentor to approve.



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

Re: Is pkg quarterly really needed?

[Baptiste Daroussin]

On Thu, Apr 20, 2017 at 02:13:52PM -0400, qjail1 wrote:
> I maintain a port and I have users complaining that the pkg system takes
> many months before the updated version of my port shows up in the pkg
> system.
> 
> My response is I tell them to change a line in their
> /etc/pkg/FreeBSD.conf file
> from url: "pkg+http://pkg.Freebsd.org/${ABI}/quarterly;,
> to   url: "pkg+http://pkg.Freebsd.org/${ABI}/latest;,

Tell them not to modify that file but to override it:
cat /usr/local/etc/pkg/repos/whatever.conf
FreeBSD: {
url: "pkg+http://pkg.Freebsd.org/${ABI}/latest;
}

:)

Best regards,
Bapt


signature.asc
Description: PGP signature

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

[Jev Björsell]

Hi Larry,

I presume you are referring the the strings 'unknown' that appear in the
 do-build: portion of the Makefile.

These are set to 'unknown' on purpose, because we do not have a way of
finding out that information unless we do it dynamically at build time.
Doing dynamically is not recommended for several reasons.

This data gets displayed when a user runs `prometheus -version`, and most
of the fields are only really relevant to dev builds anyway.

The crucial information is the software version number which is set.

You can see me exchange on the subject in the ports mailing list archive
here:

https://lists.freebsd.org/pipermail/freebsd-ports/2017-March/107833.html

-Jev


On Wed, Apr 19, 2017 at 9:23 PM ler  wrote:

> Can you fill in the unknown stuff in the version package or should I just
> go ahead and do it?
>
>
>
> On Apr 19, 2017 at 10:22 PM, > wrote:
>
> Thanks Larry,
>
> I have updated the patch on the bug, because the upstream project has just
> released a minor version/bug fix release. New patch updates us to 1.6.1.
>
> Thanks,
> -Jev
>
> On Tue, Apr 18, 2017 at 1:22 PM Larry Rosenman  wrote:
>
> On 4/18/17, 2:41 PM, "Jev Björsell" > behalf of j...@ecadlabs.com> wrote:
>>
>> Hi All,
>>
>> Could I get a committer to apply my latest update patch for net-mg
>> mt/prometheus?
>>
>> Patch is available here:
>> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=218737
>>
>> Thanks so much,
>> -Jev
>>
>> Waiting for my mentor to approve.
>>
>>
>>
>>
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Is pkg quarterly really needed?

[qjail1]

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

My response is I tell them to change a line in their
/etc/pkg/FreeBSD.conf file
from url: "pkg+http://pkg.Freebsd.org/${ABI}/quarterly;,
to   url: "pkg+http://pkg.Freebsd.org/${ABI}/latest;,

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

Why not just change the default to "latest" and save on all the overhead
of the quarterly cycle?



Is there a better place to over ride this setting than in 
/etc/pkg/FreeBSD.conf?


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

Re: Is pkg quarterly really needed?

[Kurt Jaeger]

Hi!

> Fine, but would that be a good approach? Doesn't it look more like a 
> process change than a code change?

For me, it does not look like a process-change only.

I haven't thought through all the details, I'm going with my
intuition here (because thinking it through takes a long time).

One number: I made approx. 40 commits to quarterly trees in 2 years,
and broke it one least once, probably more often. Go to

https://secure.freshbsd.org/search?committer=pi

and then limit the view to the 8 quarterlies and check those commits.
It might as well be my sloppiness, but...

> Surely, some code would need to be 
> changed but then again, wouldn't that be mostly configuration?

My gut feeling says it's more than a little change and a bit
of configuration.

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

Re: Any hope of compiling firefox port on ARM?

[bob prohaska]

On Wed, Apr 19, 2017 at 12:49:37PM +0200, Dimitry Andric wrote:
> How is that even possible?  I committed the fix on Oct 12, 2016:
> 
> Maybe you are seeing a different problem altogether?  

Perhaps. Along that line, I've submitted Bug 218782. Hope it was
done correctlythe diagnostic files were > 2MB, so I put them
at http://www.zefox.net/~fbsd/rpi2/firefox/ 

> Or your ports tree has no been updated?
>
 
/usr/ports is at 438916, /usr/src is at 317106

Thanks for reading, and any guidance!

bob prohaska

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

Re: Is pkg quarterly really needed?

[Grzegorz Junka]

Fine, but would that be a good approach? Doesn't it look more like a 
process change than a code change? Surely, some code would need to be 
changed but then again, wouldn't that be mostly configuration?


Grzegorz


On 20/04/2017 08:44, Kurt Jaeger wrote:

Hi!


I am not sure if this is a rant in favour or against quarterly branches.
And this discussion comes up again and again quite regularly. I wonder
why ports don't follow the development model of the FreeBSD kernel?

- lack of developer time
   We have bapt who develops pkg. bdrewery, who does poudriere.
   A small group works on the ports framework.
   There are a few who report issues and fixes.
   I think that's it, and all work on huge workloads.
   They add features that are even more important than
   perfecting quarterly. Quarterly was not meant to fix all issues,
   it was meant as a test to learn what comes up if one provides
   some more stable pkg tree besides the HEAD.

- lack of maintainer and committer time
   maintainers and committers have to track lots of changes,
   and it's already hard to keep up with HEAD and quarterly.
   So many changes are never merged to quarterly, because
   it's difficult to grasp side effects.

About the 'lack-of-time': Please visit

https://bugs.freebsd.org/bugzilla/page.cgi?id=dashboard.html

and look at the numbers. Do it from time to time. Plot
the trajectory 8-} Submit patches to the bugzilla project that allows
us to track the trajectory 8-}

So, in general: trust the folks who do the complicated work, and
please react in a friendly way to issues you encounter. Report
them using bugzilla.freebsd.org. Search on bugzilla for
similar reports and add to them with additional tests,
reports etc.

If, after all this 'keeping-up' leaves you with spare brain cycles,
start submitting patches, and learn the big picture. It's amazingly
complex!


Then it would be a matter of creating a scheme for url addresses for
easy access to these folders with build packages.

The scheme has to be implemented in the tools.



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

Re: Is pkg quarterly really needed?

[Baho Utot]

On 04/20/17 07:29, Mathieu Arnold wrote:

Le 20/04/2017 à 13:04, Julian Elischer a écrit :

On 20/4/17 5:15 pm, Mathieu Arnold wrote:

Le 20/04/2017 à 10:49, Torfinn Ingolfsen a écrit :

On Thu, Apr 20, 2017 at 8:00 AM, Kurt Jaeger  wrote:

Hi!


On Thu, Apr 20, 2017 at 1:30 AM, Julian Elischer
 wrote:

quarterly however is broken because the pkg mirors discard it all
at the
time of update.

Do they have to?
Why couldn't pkg mirrors keep say, the four latest quarterly sets
all the time?

Because the URL for the latest quarterly is one stable URL.

Obviously this has to be changed. As I wrote:
"No extra work involved once the setup is configured and tested".
So yes, there is some work needed, but it would be a one-time job.

If anyone has any real arguments as to why the FreeBSD project can't
do it this way, let's hear them.
HTH


I am not exactly sure what you are asking for, to keep the previous, not
updated, quarterly package repositories ? say, in latest-1 latest-2
latest-3... ?


What purpose would that serve ? I mean, they would not be updated.


exactly! that's what is often needed...  something that is not updated..


I still do not understand, if you need something that is not updated,
then do not update...



/ rant on

I tried that when I first transisioned from linux to FreeBSD.  I had one 
BITCH of a time simply because I could not find one set of base/ports 
that would give me a stable desktop.  It took me 6 months of random 
reboots ( the pc would just reboot for no reason, even if it was doing 
nothing ) packages that were in compatible with each other ( version 
hell ).  I finally got my desktop settle down,  then I became stupid and 
updated it only to go thru the process all over again.  I started using 
synth ( now I can not use it because of the last dust up that occurred, 
I don't trust it now ),  and now I have nothing to trust to get me out 
of trouble. I can not go back to a know version of base/ports that will 
together as I have not found the combination.


Now before you think I am only complaining here is a little bit of 
history. I came from Arch then moved to LFS because of the rolling 
release.  I know what a terrible time you have to keep things updated 
and working together.  The exception with LFS you can go back to a known 
point ( where things are known to work together ) and restart from there 
if you have an entire mess and must start over.


I am currently thinking of returning to LFS simply because updating 
FreeBSD and ports makes my asshole pucker.  After updating will I be 
left with something that works or will I be cussing myself for being 
stupid and updating, when I sould have left it well enough alone.


I really wanted for FreeBSD to work out so I could have one system for 
my servers, desktop and raspberry pi computers.


/rant off

Sorry if I offended anyone, I just wanted to share my delving in FreeBSD

Well carry on and have fun my friends.

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

Waste Treatment and Recycling Email List

[Angela Schultz]

Hi,

 

I was researching your company website .I figured it'd be worth leaving a
note.

 

We maintain about 25 Million+ B2B contacts from various industries across
the globe,

 Just Wanted to check if be interested in below mentioned Email List types
which can be 

your target audience:-

 

Architecture / Engineering Offices, Construction / Contracting, Environment
Agencies, Health and Safety Authorities, Hospitality/Facility Management,
Hospitals, Hotel, Inter-Governmental Organization (IGO), Landscaping and
Land Reclamation, Manufacturing Company / Industrial Plants, Ministries of
Environment, Municipalities, Non-Governmental Organization (NGO), Oil
Companies, Refineries, Universities / Research Institutions, Urban Planning,
Waste Generator, Waste Management, Waste Processing / Recycling
Professional, Waste Services and many more.

 

Please let me know your:- Target Industry:_, Target Titles: __ and
Target Geography Location: 

 

so that I can send you more information and few samples for your review.

 

Waiting for your Swift Response!

 

Regards,

Angela Schultz

Sr. Marketing Analyst

 

 If you want stop receiving email please reply Remove in subject line.

 

 

___
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: iocage port

[Vick Khera]

Actually, it is not so much a suitable drop-in replacement since I would
have to re-create every one of my jails within the iocell structure.

I guess I'll just reproduce the old iocage port in my own local section of
the ports tree.

On Thu, Apr 20, 2017 at 8:34 AM, Vick Khera  wrote:

> On Wed, Apr 19, 2017 at 12:41 PM, Sebastian Schwarz 
> wrote:
>
>> On 2017-04-19, Vick Khera wrote:
>> > Can the original iocage port be restored?
>>
>> I believe the old code has been forked and preserved under the
>> name iocell (https://github.com/bartekrutkowski/iocell) and is
>> available in pkg/ports under sysutils/iocell.
>>
>
> Thanks! That looks like a suitable replacement.
>
> An entry in the UPDATING file would have been helpful to me if this is the
> official position.
>
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: Is pkg quarterly really needed?

[Michelle Sullivan]

Miroslav Lachman wrote:


It is not just about updates but about new installs too - if you have 
dozens of machines for customers and you need them all in the same 
version. Then some customer need some package not installed on his 
machine and you cannot run "pkg install somepackage" because then you 
will end up with upgrade of already installed packages (dependencies) 
before new package from current quaterly branch is installed.


(I do not use this scheme, but I understand the environment where 
somebody needs frozen pkg repo for much longer time than 3 months)

Create your own snapshot... it has 2 immediate and distinct advantages:

1/ Its frozen across all your systems (which means when random updates 
on how the ports system works are applied breaking everything you're not 
affected.)
2/ You can apply patches (security patches) as you need them instead of 
having to upgrade/re-snapshot because the port manager refuses/ignores 
requests to update the previous snapshot (the one you settled on)..


Then when all that is done, you can do as I did, fork the entire lot 
into a secure, up to date and working tree/build system (for OS and 
ports) where you actually have a working and reliable production system 
rather than a moving target... then you can remove all the bloat and 
unnecessary crap from the base OS and replace it all with ports stuff so 
that the base OS doesn't need upgrading unless there is a 
libc/kernel/etc security issue...  Oh wait - that's exactly what I did 
as well... you get the idea..  don't argue for it, just do it yourself 
its a lot less of a waste of energy and you get exactly what you want/need.


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"

Re: iocage port

[Vick Khera]

On Wed, Apr 19, 2017 at 12:41 PM, Sebastian Schwarz 
wrote:

> On 2017-04-19, Vick Khera wrote:
> > Can the original iocage port be restored?
>
> I believe the old code has been forked and preserved under the
> name iocell (https://github.com/bartekrutkowski/iocell) and is
> available in pkg/ports under sysutils/iocell.
>

Thanks! That looks like a suitable replacement.

An entry in the UPDATING file would have been helpful to me if this is the
official position.
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: Is pkg quarterly really needed?

[Miroslav Lachman]

Mathieu Arnold wrote on 2017/04/20 13:29:

Le 20/04/2017 à 13:04, Julian Elischer a écrit :

On 20/4/17 5:15 pm, Mathieu Arnold wrote:

Le 20/04/2017 à 10:49, Torfinn Ingolfsen a écrit :



I am not exactly sure what you are asking for, to keep the previous, not
updated, quarterly package repositories ? say, in latest-1 latest-2
latest-3... ?


What purpose would that serve ? I mean, they would not be updated.


exactly! that's what is often needed...  something that is not updated..


I still do not understand, if you need something that is not updated,
then do not update...


It is not just about updates but about new installs too - if you have 
dozens of machines for customers and you need them all in the same 
version. Then some customer need some package not installed on his 
machine and you cannot run "pkg install somepackage" because then you 
will end up with upgrade of already installed packages (dependencies) 
before new package from current quaterly branch is installed.


(I do not use this scheme, but I understand the environment where 
somebody needs frozen pkg repo for much longer time than 3 months)


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: Is pkg quarterly really needed?

[Mathieu Arnold]

Le 20/04/2017 à 13:04, Julian Elischer a écrit :
> On 20/4/17 5:15 pm, Mathieu Arnold wrote:
>> Le 20/04/2017 à 10:49, Torfinn Ingolfsen a écrit :
>>> On Thu, Apr 20, 2017 at 8:00 AM, Kurt Jaeger  wrote:
 Hi!

> On Thu, Apr 20, 2017 at 1:30 AM, Julian Elischer
>  wrote:
>> quarterly however is broken because the pkg mirors discard it all
>> at the
>> time of update.
> Do they have to?
> Why couldn't pkg mirrors keep say, the four latest quarterly sets
> all the time?
 Because the URL for the latest quarterly is one stable URL.
>>> Obviously this has to be changed. As I wrote:
>>> "No extra work involved once the setup is configured and tested".
>>> So yes, there is some work needed, but it would be a one-time job.
>>>
>>> If anyone has any real arguments as to why the FreeBSD project can't
>>> do it this way, let's hear them.
>>> HTH
>>
>> I am not exactly sure what you are asking for, to keep the previous, not
>> updated, quarterly package repositories ? say, in latest-1 latest-2
>> latest-3... ?
>>
>>
>> What purpose would that serve ? I mean, they would not be updated.
>
> exactly! that's what is often needed...  something that is not updated..

I still do not understand, if you need something that is not updated,
then do not update...

-- 
Mathieu Arnold

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

Re: Is pkg quarterly really needed?

[Julian Elischer]

On 20/4/17 5:18 pm, Mathieu Arnold wrote:

Le 20/04/2017 à 11:15, Mathieu Arnold a écrit :

Le 20/04/2017 à 10:49, Torfinn Ingolfsen a écrit :

On Thu, Apr 20, 2017 at 8:00 AM, Kurt Jaeger  wrote:

Hi!


On Thu, Apr 20, 2017 at 1:30 AM, Julian Elischer  wrote:

quarterly however is broken because the pkg mirors discard it all at the
time of update.

Do they have to?
Why couldn't pkg mirrors keep say, the four latest quarterly sets
all the time?

Because the URL for the latest quarterly is one stable URL.

Obviously this has to be changed. As I wrote:
"No extra work involved once the setup is configured and tested".
So yes, there is some work needed, but it would be a one-time job.

If anyone has any real arguments as to why the FreeBSD project can't
do it this way, let's hear them.
HTH

I am not exactly sure what you are asking for, to keep the previous, not
updated, quarterly package repositories ? say, in latest-1 latest-2
latest-3... ?

So, that should be quarterly-1, quarterly-2..., not latest :-)

2017-Q1, 2017-Q2, 2017-Q3   etc.




What purpose would that serve ? I mean, they would not be updated.




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

Re: Is pkg quarterly really needed?

[Julian Elischer]

On 20/4/17 5:15 pm, Mathieu Arnold wrote:

Le 20/04/2017 à 10:49, Torfinn Ingolfsen a écrit :

On Thu, Apr 20, 2017 at 8:00 AM, Kurt Jaeger  wrote:

Hi!


On Thu, Apr 20, 2017 at 1:30 AM, Julian Elischer  wrote:

quarterly however is broken because the pkg mirors discard it all at the
time of update.

Do they have to?
Why couldn't pkg mirrors keep say, the four latest quarterly sets
all the time?

Because the URL for the latest quarterly is one stable URL.

Obviously this has to be changed. As I wrote:
"No extra work involved once the setup is configured and tested".
So yes, there is some work needed, but it would be a one-time job.

If anyone has any real arguments as to why the FreeBSD project can't
do it this way, let's hear them.
HTH


I am not exactly sure what you are asking for, to keep the previous, not
updated, quarterly package repositories ? say, in latest-1 latest-2
latest-3... ?


What purpose would that serve ? I mean, they would not be updated.


exactly! that's what is often needed...  something that is not updated..
having spent 20 years embedding FreeBSD into products I can tell you 
that the commercial reality is a requirement for FROZEN (or near to 
it) contents. not contents changing all the time. ports/pkgs that need 
to be updated for security reasons are the exception, not the rule. 
And since handling a security issue usually required extra paperwork 
anyhow, they are usually handled in a different workflow.


here's a workflow I'd find less annoying.. or something similar:

quarterly snapshot into .../quarterly/$DATE/initial/All/
   this never changes again. it is a snapshot of the head set of 
patches at that time. no recomipiles needed.

an additional directory: .../quarterly/$DATE/updating/All...
all files in 'updating' start out as symlinks to 
../../initial/All/$filename and are replaced if the files get updated.

   ( or if name changes.. maybe we get a choice of two)
For the people who want to leap from quarterly to quarterly we have a
symlink from "quarterly/Latest" to $DATE/updating/ and  from 
quarterly/Initial to $DATE/initial


Each quarter  a new set is created with new dates, and the symlinks 
are recreated.
also create in each real directory, a file that contains the (possibly 
relative) URL so we know what to point our pkg.cfg at if we don't want 
to follow the rolling version.


how long you leave the old ones there is up to you, but someone 
mirroring might decide to leave them for ever if they had the space.

but at least leave them for a whole quarter...










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

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

[Xavi Garcia]

Hi,

This can be the plan B if we cannot host the builds. I will discuss with
the colleagues.

My concern is accessing old builds, in case we are tracking a quarterly
branch for stability, because the developer is only offering builds for the
latest version.

Regarding the software we want to port, it is GPLv3 and it shouldn't be a
problem if we release our own builds.

Kind regards,

Xavier Garcia


2017-04-20 11:10 GMT+02:00 Dmytro Bilokha :

> On 20.04.2017 11:02, Xavi Garcia wrote:
>
>> Hi,
>>
>>
> Hi!
>
> I'd definitely download a compiled version but the developer is
>> hosting the builds in Amazon S3 and you need to receive a token via
>> e-mail in order to download the files, which is awful in my opinion.
>>
>>
> I agree with you, its awful. But, I saw ports which shows you a message
> like "Please download this file: http://blahblah... and put in in the
> distfiles, because of the license reasons it is not allowed to download it
> by automatic tool. Then run make again". It is not convenient, but possible
> if there are no another options.
>
> The other option is to compile my own builds and host them somewhere
>> in the Internet.
>>
>
> As for me, it would be the best option. But, be careful, it is possible
> that by software license you are not allowed to build your version of the
> application and provide it to users.
>
>
>> Kind regards,
>>
>> Xavier Garcia
>>
>> 2017-04-19 22:29 GMT+02:00 Dmytro Bilokha :
>>
>> On 19.04.2017 19:27, Xavi Garcia wrote:
>>>
>>> Hi all,

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

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

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

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

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

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

 You can find attached the Makefile.

 Kind regards,

 Xavier Garcia

>>>
>>> Hi!
>>> If you need examples of the "best practice",
>>> probably, you can take a look at already exsisting
>>> ports of Java software.
>>>
>>> For example, I've checked the Glassfish port and
>>> it was made with different approach:
>>> 1. During fetch phase distribution zip-file with
>>> already compiled Java classes is downloaded.
>>> 2. Then it is unzipped to some directory, like
>>> /usr/local/glassfish.
>>> 3. Some scripts put, package registered, etc.
>>>
>>> So here there is no building of Java app from sources,
>>> mostly fetching already built, some tweaking and putting
>>> to the right place.
>>> I saw similar procedure for some another ports
>>> of Java software.
>>>
>>> I am not sure, but it seems because of such reasons:
>>> 1. With Java you won't gain a lot with building application
>>> from sources. If OS has JVM you can just run already
>>> compiled -- it should work.
>>> 2. For port its better to have as least dependencies,
>>> as possible. So, making your port dependent on
>>> Gradle (which fast evolving itself) and/or another
>>> Java build tooling can make port fragile and not
>>> very stable.
>>> 3. Building the big Java project from sources could be
>>> time and traffic consuming task. Usualy users
>>> don't like this.
>>>
>>> ---
>>> Best regards,
>>> Dmytro Bilokha
>>>
>>
>>
>>
>> Links:
>> --
>> [1] https://gradle.org/
>>
>
> ---
> Best regards,
> Dmytro Bilokha
>
>
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: Is pkg quarterly really needed?

[Mathieu Arnold]

Le 20/04/2017 à 11:15, Mathieu Arnold a écrit :
> Le 20/04/2017 à 10:49, Torfinn Ingolfsen a écrit :
>> On Thu, Apr 20, 2017 at 8:00 AM, Kurt Jaeger  wrote:
>>> Hi!
>>>
 On Thu, Apr 20, 2017 at 1:30 AM, Julian Elischer  
 wrote:
> quarterly however is broken because the pkg mirors discard it all at the
> time of update.
 Do they have to?
 Why couldn't pkg mirrors keep say, the four latest quarterly sets
 all the time?
>>> Because the URL for the latest quarterly is one stable URL.
>> Obviously this has to be changed. As I wrote:
>> "No extra work involved once the setup is configured and tested".
>> So yes, there is some work needed, but it would be a one-time job.
>>
>> If anyone has any real arguments as to why the FreeBSD project can't
>> do it this way, let's hear them.
>> HTH
>
> I am not exactly sure what you are asking for, to keep the previous, not
> updated, quarterly package repositories ? say, in latest-1 latest-2
> latest-3... ?

So, that should be quarterly-1, quarterly-2..., not latest :-)

>
> What purpose would that serve ? I mean, they would not be updated.
>
>

-- 
Mathieu Arnold




signature.asc
Description: OpenPGP digital signature

Re: Is pkg quarterly really needed?

[Mathieu Arnold]

Le 20/04/2017 à 10:49, Torfinn Ingolfsen a écrit :
> On Thu, Apr 20, 2017 at 8:00 AM, Kurt Jaeger  wrote:
>> Hi!
>>
>>> On Thu, Apr 20, 2017 at 1:30 AM, Julian Elischer  wrote:
 quarterly however is broken because the pkg mirors discard it all at the
 time of update.
>>> Do they have to?
>>> Why couldn't pkg mirrors keep say, the four latest quarterly sets
>>> all the time?
>> Because the URL for the latest quarterly is one stable URL.
> Obviously this has to be changed. As I wrote:
> "No extra work involved once the setup is configured and tested".
> So yes, there is some work needed, but it would be a one-time job.
>
> If anyone has any real arguments as to why the FreeBSD project can't
> do it this way, let's hear them.
> HTH


I am not exactly sure what you are asking for, to keep the previous, not
updated, quarterly package repositories ? say, in latest-1 latest-2
latest-3... ?


What purpose would that serve ? I mean, they would not be updated.


-- 
Mathieu Arnold




signature.asc
Description: OpenPGP digital signature

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

[Dmytro Bilokha]

On 20.04.2017 11:02, Xavi Garcia wrote:

Hi,



Hi!


I'd definitely download a compiled version but the developer is
hosting the builds in Amazon S3 and you need to receive a token via
e-mail in order to download the files, which is awful in my opinion.



I agree with you, its awful. But, I saw ports which shows you a message 
like "Please download this file: http://blahblah... and put in in the 
distfiles, because of the license reasons it is not allowed to download 
it by automatic tool. Then run make again". It is not convenient, but 
possible if there are no another options.



The other option is to compile my own builds and host them somewhere
in the Internet.


As for me, it would be the best option. But, be careful, it is possible 
that by software license you are not allowed to build your version of 
the application and provide it to users.




Kind regards,

Xavier Garcia

2017-04-19 22:29 GMT+02:00 Dmytro Bilokha :


On 19.04.2017 19:27, Xavi Garcia wrote:


Hi all,

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

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

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

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

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

You can find attached the Makefile.

Kind regards,

Xavier Garcia


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

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

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

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

---
Best regards,
Dmytro Bilokha




Links:
--
[1] https://gradle.org/


---
Best regards,
Dmytro Bilokha

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

Re: Is pkg quarterly really needed?

[Kurt Jaeger]

Hi!

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

> >> Do they have to?
> >> Why couldn't pkg mirrors keep say, the four latest quarterly sets
> >> all the time?

> > Because the URL for the latest quarterly is one stable URL.

> Obviously this has to be changed. As I wrote:
> "No extra work involved once the setup is configured and tested".
> So yes, there is some work needed, but it would be a one-time job.

> If anyone has any real arguments as to why the FreeBSD project can't
> do it this way, let's hear them.

Lack of developer- and clusteradm-time. See my other posting.
Time deficit goes directly to the core of pkg/ports stuff, which
is, due to the complexity, limited to very few very skilled people
that happen to find time to solve the problem.

It's not a trivial problem, you can look at almost all source
code ecosystems (OSX, Microsoft, Solaris 8-}, debian, etc):
All struggle with the rate of change and the complexity of the task.

So it's not helping to yell louder at the folks working on it,
so please yell smarter 8-} Use a yelling tool like bugzilla,
and fine-tune your yelling by providing test cases and patches.

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

Re: Is pkg quarterly really needed?

[Torfinn Ingolfsen]

On Thu, Apr 20, 2017 at 8:00 AM, Kurt Jaeger  wrote:
> Hi!
>
>> On Thu, Apr 20, 2017 at 1:30 AM, Julian Elischer  wrote:
>> > quarterly however is broken because the pkg mirors discard it all at the
>> > time of update.
>
>> Do they have to?
>> Why couldn't pkg mirrors keep say, the four latest quarterly sets
>> all the time?
>
> Because the URL for the latest quarterly is one stable URL.

Obviously this has to be changed. As I wrote:
"No extra work involved once the setup is configured and tested".
So yes, there is some work needed, but it would be a one-time job.

If anyone has any real arguments as to why the FreeBSD project can't
do it this way, let's hear them.
HTH
-- 
Regards,
Torfinn Ingolfsen
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: Is pkg quarterly really needed?

[Kurt Jaeger]

Hi!

> I am not sure if this is a rant in favour or against quarterly branches. 
> And this discussion comes up again and again quite regularly. I wonder 
> why ports don't follow the development model of the FreeBSD kernel?

- lack of developer time
  We have bapt who develops pkg. bdrewery, who does poudriere.
  A small group works on the ports framework.
  There are a few who report issues and fixes.
  I think that's it, and all work on huge workloads.
  They add features that are even more important than
  perfecting quarterly. Quarterly was not meant to fix all issues,
  it was meant as a test to learn what comes up if one provides
  some more stable pkg tree besides the HEAD.

- lack of maintainer and committer time
  maintainers and committers have to track lots of changes,
  and it's already hard to keep up with HEAD and quarterly.
  So many changes are never merged to quarterly, because
  it's difficult to grasp side effects.

About the 'lack-of-time': Please visit

https://bugs.freebsd.org/bugzilla/page.cgi?id=dashboard.html

and look at the numbers. Do it from time to time. Plot
the trajectory 8-} Submit patches to the bugzilla project that allows
us to track the trajectory 8-}

So, in general: trust the folks who do the complicated work, and
please react in a friendly way to issues you encounter. Report
them using bugzilla.freebsd.org. Search on bugzilla for
similar reports and add to them with additional tests,
reports etc.

If, after all this 'keeping-up' leaves you with spare brain cycles,
start submitting patches, and learn the big picture. It's amazingly
complex!

> Then it would be a matter of creating a scheme for url addresses for 
> easy access to these folders with build packages.

The scheme has to be implemented in the tools.

-- 
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
+-+
multimedia/gtk-youtube-viewer   | 3.2.5   | 3.2.7
+-+


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: Is pkg quarterly really needed?

[Grzegorz Junka]

On 20/04/2017 05:37, Mark Linimon wrote:

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

So you want some kind of running -quarterly branch.

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

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

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

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

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



I am not sure if this is a rant in favour or against quarterly branches. 
And this discussion comes up again and again quite regularly. I wonder 
why ports don't follow the development model of the FreeBSD kernel? In 
short:


1. CURRENT - latest upgrades from upstreams, a broken port or a port 
that breaks other ports shouldn't be committed but not all option 
combinations are fully tested. Don't rebuild all ports, at least not 
often (maybe once a month), but rebuild all dependant ports of a port 
whenever a change in that port has been made.


2. STABLE - Only upgrade ports to the version from CURRENT when users 
haven't reported any issues with any combination of options for that 
port for some agreeable period of time since the upgrade in CURRENT 
(e.g. 2 weeks, a month). Rebuild all ports more often than in CURRENT 
(e.g. fortnight) but also not too often. Like in CURRENT rebuild all 
dependant ports whenever a port on which they depend has changed.


3. RELEASE (optional) - Like STABLE - only upgrade ports to the version 
from STABLE if no issues with any combination of options has been 
reported for some agreeable period of time since the upgrade in STABLE 
(e.g. 2-3 months this time). Rebuild all ports more often than in STABLE 
(e.g. once a week). Also like in STABLE rebuild all dependant ports when 
a port on which they depend changes.


Each branch would keep X latest full rebuilds (one, two, three - 
depending on resource availability) and the partial rebuilds in between 
them when dependant ports are rebuild - I think poudriere would copy 
them to the latest directory with packages by default.


This could give something folders like:

CURRENT month 1
any partial rebuilds on top of month 1
CURRENT month 2
any partial rebuilds on top of month 2
...

STABLE week 1
any partial rebuilds on top of week 1
STABLE week 3
any partial rebuild on top of week 3

RELEASE week 1
any partial rebuilds on top of week 1
RELEASE week 2
any partial rebuilds on top of week 2
RELEASE week 3
any partial rebuilds on top of week 3

etc.

Then it would be a matter of creating a scheme for url addresses for 
easy access to these folders with build packages.


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

[Miroslav Lachman]

Bernard Spil wrote on 2017/04/19 21:32:

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

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

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

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

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


[...]


[82/86] Upgrading mariadb101-server from 10.1.21 to 10.1.22...
===> Creating groups.
Using existing group 'mysql'.
===> Creating users
Using existing user 'mysql'.
[82/86] Extracting mariadb101-server-10.1.22: .. done

This was on FreeBSD 10.3 amd64 with packages from own poudriere with
follogin settings:

OPTIONS_UNSET= X11 GUI CUPS DOCS EXAMPLES NLS HAL
WITH_BDB_VER=5
WITH_GHOSTSCRIPT_VER=9
DEFAULT_VERSIONS=apache=2.4 perl5=5.24 mysql=10.1m php=5.6 python=2.7
python3=3.5 pgsql=9.4 ssl=openssl
DISABLE_LICENSES=yes


databases_mariadb101-client/options
OPTIONS_FILE_SET+=GSSAPI_NONE

databases_mariadb101-server/options
OPTIONS_FILE_SET+=MAXKEY
OPTIONS_FILE_SET+=GSSAPI_NONE
OPTIONS_FILE_SET+=SPHINX
OPTIONS_FILE_SET+=SPIDER

I think all users of MariaDB 10.1 should be warned in UPDATING

Let me know if you need some more details.


Am I the only one beaten by this issue? I see this on each of our
machines during pkg upgrade.

Miroslav Lachman


Hi Miroslav,

Looks like it. My own servers were upgraded with mariadb from pkg
without issues.

Sorry for your inconvenience, don't know what would cause that.


The root cause is IMHO this change in pkg-plist

https://svnweb.freebsd.org/ports/head/databases/mariadb101-client/pkg-plist?r1=436392=436391=436392
https://svnweb.freebsd.org/ports/head/databases/mariadb101-server/pkg-plist?r1=436857=436856=436857

but I don't understand why nobody else see this problem on pkg upgrade.

We are using poudriere with standard ports tree, MariaDB is build with 
standard options etc.


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

[Miroslav Lachman]

scratch65...@att.net wrote on 2017/04/19 17:55:

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



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

pkg check -Ba

Checking all packages
(p5-DBD-mysql-4.042)
/usr/local/lib/perl5/site_perl/mach/5.24/auto/DBD/mysql/mysql.so -
required shared library libmysqlclient.so.18 not found
Checking all packages
(sphinxsearch-2.2.11_1) /usr/local/bin/indexer - required shared library
libmysqlclient.so.18 not found
(sphinxsearch-2.2.11_1) /usr/local/bin/indextool - required shared
library libmysqlclient.so.18 not found
(sphinxsearch-2.2.11_1) /usr/local/bin/spelldump - required shared
library libmysqlclient.so.18 not found
(sphinxsearch-2.2.11_1) /usr/local/bin/wordbreaker - required shared
library libmysqlclient.so.18 not found
(sphinxsearch-2.2.11_1) /usr/local/sbin/searchd - required shared
library libmysqlclient.so.18 not found


That's odd.  You're upping the 64-bit version, right?


Yes, we are using FreeBSD 10.3-p18 amd64 on all our machines.
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

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

[Xavi Garcia]

Hi,

I'd definitely download a compiled version but the developer is hosting the
builds in Amazon S3 and you need to receive a token via e-mail in order to
download the files, which is awful in my opinion.


The other option is to compile my own builds and host them somewhere in the
Internet.

Kind regards,

Xavier Garcia


2017-04-19 22:29 GMT+02:00 Dmytro Bilokha :

>
> On 19.04.2017 19:27, Xavi Garcia wrote:
>
>> Hi all,
>>
>> We are writing a port for a Java software that downloads a large number of
>> jar files (around 200) with Gradle (https://gradle.org/), that is similar
>> to other package managers like Pip or Ruby Gems but for Java projects.
>>
>> What would be the best practice in this scenario? I am aware that we can
>> only download files in the fetch phase but I am not sure if my solution is
>> clean enough.
>>
>> We will be deploying this port in our servers via Portshaker and Poudriere
>> but we would also like to commit it to the ports tree.
>>
>>
>> In short, I am using the 'pre-fetch' phase together with FETCH_DEPENDS  to
>> drop the Gradle wrapper in ${DISTDIR}/${PORTNAME} and then I use the
>> 'dependencies' task to download all the dependencies.
>>
>> The 'do-build' stage will run again the Gradle wrapper to build the
>> software, but using the offline mode.
>>
>> You can find attached the Makefile.
>>
>> Kind regards,
>>
>> Xavier Garcia
>>
>
> Hi!
> If you need examples of the "best practice",
> probably, you can take a look at already exsisting
> ports of Java software.
>
> For example, I've checked the Glassfish port and
> it was made with different approach:
> 1. During fetch phase distribution zip-file with
> already compiled Java classes is downloaded.
> 2. Then it is unzipped to some directory, like
> /usr/local/glassfish.
> 3. Some scripts put, package registered, etc.
>
> So here there is no building of Java app from sources,
> mostly fetching already built, some tweaking and putting
> to the right place.
> I saw similar procedure for some another ports
> of Java software.
>
> I am not sure, but it seems because of such reasons:
> 1. With Java you won't gain a lot with building application
> from sources. If OS has JVM you can just run already
> compiled -- it should work.
> 2. For port its better to have as least dependencies,
> as possible. So, making your port dependent on
> Gradle (which fast evolving itself) and/or another
> Java build tooling can make port fragile and not
> very stable.
> 3. Building the big Java project from sources could be
> time and traffic consuming task. Usualy users
> don't like this.
>
> ---
> Best regards,
> Dmytro Bilokha
>
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: Is pkg quarterly really needed?

[Michael Gmelin]

On Thu, 20 Apr 2017 00:37:22 -0500
Mark Linimon  wrote:

> I understand that having the quarterlies is not meeting your use case.
> You've said that.  We get it.
> 
> So you want some kind of running -quarterly branch.
> 
> But where are the N hours of work per week to QA all the patches to
> the -quarterly branch, or a -stable branch, or whatever people seem
> to demand, to come from?
> 
> This is a serious -- if very irritated -- request.
> 
> We've moved from a "we don't have enough person-power to manage a
> ports branch" to "we kinda have enough person-power to manage both
> head and a kinda-branch."  OK.  That isn't meeting all the use
> cases.  Understood.
> 
> Are you going to volunteer for a team to run that QA?  Who else do you
> think should be on it?  Clearly the current volunteers don't have the
> bandwidth.  It is hard enough just to kep ports-head building.  Where
> do the hours come from?
> 
> You're comparing your expectations of the output of what a
> professional QA team would do, to the work that N volunteers do.
> Obviously the results are not comparable.  It's crazy to think that
> they would be.
> 
> Honestly without some volunteers to do the _hard_, _unrewarding_, work
> to QA the ports tree, this is all either a) just talk, or b) people
> wanting volunteers to provide professional-level support, for free.
> 
> tl;dr: provide some resources, or don't.  I am getting to the point
> where I don't care either way.  All I see is the people who are doing
> actual work get poked in the eye.
> 

Answering one email in the thread to provide feedback on my experience.

After some time it took to adapt, I find quarterly to be extremely
useful to me, because

  a) as a maintainer, it provides a natural deadline when
 updates should be in the ports tree (as many users will use that
 for the next three months)
  b) it's the first time I'm actually using binaries from project
 servers on a few private hosts and vms
  c) as professional users, running our own poudriere builders,
 quarterly branches are useful as a baseline for our ports tree and
 patches to it. As many things in business are done on a quarterly
 basis, we simply create a new builder every quarter, build our
 package set, test the upgrades on staging machines and then change
 the repo URL on all productions servers and upgrade.

So, even though things might not be perfect, to me it's a great
improvement compared to the previous situation and I'm grateful to those
who put lots of effort into it.

-m

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

Re: Is pkg quarterly really needed?

[Ethan Grammatikidis]

On Thu, Apr 20, 2017, at 06:22 AM, Mark Linimon wrote:
> On Wed, Apr 19, 2017 at 04:37:05PM -0400, scratch65...@att.net wrote:
> > (Right now, it's quite hard to resist the paranoid suspicion that
> > maybe this crazy, anti-real-user behavior is a subtle way to kill
> > freebsd altogether by driving away the non-hobbyists.)
> 
> That's one explanation.
> 
> The other, possible, explanation, is that the efforts of a group of
> volunteers isn't adequate enough for every use case -- including your own.

This!!! I used to help out a little with a Linux distro, many years ago when it 
was feasible for a handful of hobyists to do so in their spare time. The 
experience was sobering. In about 5 years I went from building my own LFS 
system without any help (I wasn't on the net) to seeing a bunch of people just 
barely keep up as Xorg and Gtk+ grew circular dependency chains, some users 
demanded stability while others wanted updates, and of course compile times 
were rapidly increasing.
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: Is pkg quarterly really needed?

[Ethan Grammatikidis]

On Tue, Apr 18, 2017, at 02:54 PM, qjail1 wrote:
> I maintain a port and I have users complaining that the pkg system takes 
> many months before the updated version of my port shows up in the pkg 
> system.
> 
> My response is I tell them to change a line in their 
> /etc/pkg/FreeBSD.conf file
> from url: "pkg+http://pkg.Freebsd.org/${ABI}/quarterly;,
> to   url: "pkg+http://pkg.Freebsd.org/${ABI}/latest;,
> 
> The old pkg system never had this quarterly update cycle and I see no 
> reason to have it now when its so easy to over ride the default.
> 
> Why not just change the default to "latest" and save on all the overhead 
> of the quarterly cycle?

I have to say that if pkg abandoned the cautious update cycle, I'd abandon 
FreeBSD. I've really had enough of constant upgrades. The one thing I have 
which needs constant upgrades is a Flash video downloader. I keep that in ~/bin 
and use its built-in upgrade mechanism when required, which is simple. I don't 
need to get it via some root-only mechanism. It doesn't have a man page of 
course, but --help|less is easy enough.
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: Is pkg quarterly really needed?

[Kurt Jaeger]

Hi!

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

> Do they have to?
> Why couldn't pkg mirrors keep say, the four latest quarterly sets
> all the time?

Because the URL for the latest quarterly is one stable URL.

If an enduser wants to access a particular quarterly, the enduser
needs to edit the repo URL. Which probably kills approx. 95%
of the use-cases.

One could do some process where every quarterly repo communicates
it's quarterly URL back to the client accessing it and pkg automagically
adapts the repo URL, but that does sound fragile, too.

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