don't fork portmaster source

[John Marino]

> I'm asking myself how to manage the code. Should i create a new GitHub 
> repository? Fork the existing from freebsd/portmaster? How to handle the 
> LOCAL Master-Site?


Talk to Bryan Drewery.

"If someone else would like to maintain this please discuss with me and
I will get you access to the github account where the code lives." from
portmaster commit history.

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

Ports with github private repository

[Nycko]

Hello, reading the documentation[1],I find no way to use a private github
repo in ports.
They can give me a hand if possible or if I'm misreading the documentation

[1]
https://www.freebsd.org/doc/en/books/porters-handbook/book.html#makefile-master_sites-github-description

thanks & regards
-- 
nycko
___
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: Removing documentation

[Guido Falsi]

On 02/10/16 12:21, John Marino wrote:
> On 2/9/2016 9:27 PM, John Marino wrote:
>> On 2/9/2016 9:20 PM, Warren Block wrote:
>>> On Tue, 9 Feb 2016, John Marino wrote:
>>>
 On 2/9/2016 7:20 PM, Warren Block wrote:
>> If you have the build log, I'd like to see it.  Dewayne G. got an error
>> after overriding CPUTYPE (do you do that too?) and I'm thinking it's
>> sensitive to CPU and I'd like to know more.
>
> Yes, I use
>
> CPUTYPE?=core-avx2

 What happens when you try to build lang/gcc6-devel ?
 Same issue or does it complete?
>>>
>>> It builds successfully, in about 40 minutes.
>>
>> My suspicion is that due to the bootstrap, we'd have two possible options:
>> A) turn on the full bootstrap which takes the same amount of time as
>> gcc6-devel does (I'm not sure it will work but there's a chance)
>> B) I put CPUTYPE=native in the gcc6-aux Makefile
>>
>> I am inclined towards B.  It works on DragonFly but I need somebody else
>> to test it on i7 on FreeBSD.  I asked Dewayne, but I'd be grateful if
>> you could test it as well.
> 
> Hi Warren,
> Dewayne got back to me, and it appears the only solution is to put
> "CPUTYPE=" in the gcc6-aux makefile.  I think the bootstrap compiler
> (the ada-capable compiler downloaded to build gcc6-aux) doesn't know
> these instructions and that's the issue.  The options are don't override
> CPUTYPE or regenerate the bootstrap, but that might have other
> consequences or won't fix every combination.

I just tried to compile lang/gcc in poudriere with CPUTYPE set and it
failed too in configure phase.

It appears that any setting "higher" than nocona makes the gcc ports
fail, not only gcc6.

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

Re: PHP7 package?

[Dan Busarow]

On 2/9/16 10:32 PM, Kurt Jaeger wrote:

Hi!


Everythig seemed to work fine but when I added

LoadModule php7_modulelibexec/apache24/libphp7.so

to the httpd.conf apache core dumped.


Ah, that is a different issue.

Use

https://people.freebsd.org/~ohauer/scripts/fixphpextorder.sh

on

/usr/local/etc/php/extensions.ini

to avoid core dumps of apache. The sequence of extensions.ini
is problematic.



Voila!  Thanks!

After running this httpd is happy with the new mod_php70

I will begin testing it out.

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

Re: maintaining portmaster ? was: Re: Removing documentation

[Kurt Jaeger]

Hi!

> I'm asking myself how to manage the code. Should i create a new GitHub 
> repository? Fork the existing from freebsd/portmaster? How to handle the 
> LOCAL Master-Site?

Fork it on Github, for now. It can later be merged with freebsd/portmaster.

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

pkg 1.6.3 unable to upgrade, URL in pkg.conf problem?

[Daniel Eischen]

I'm trying to upgrade my ports with a set that I built using poudriere.
I'm running FreeBSD-current r295354, pkg 1.6.3.

The packages are here on my local (localhost, vega) box:

  /usr/local/poudriere/data/packages/11amd64-default

My repo pkg.conf (vega.conf) looks like this:

  vega: {
url: "file://localhost/usr/local/poudriere/data/packages/11amd64-default",
mirror_type: "srv",
signature_type: "none"
fingerprints: "/usr/share/keys/pkg",
enabled: yes
  }

'pkg upgrade -r vega' yields this:

  #  pkg upgrade -r vega
  Updating vega repository catalogue...
  vega repository is up-to-date.
  All repositories are up-to-date.
  Checking for upgrades (360 candidates): 100%
  Processing candidates (360 candidates): 100%
  The following 139 package(s) will be affected (of 0 checked):

  New packages to be INSTALLED:
  cblas: 1.0_4 [vega]
  ...

  Installed packages to be UPGRADED:
  xterm: 320 -> 322 [vega]
  ...

  Installed packages to be REINSTALLED:
  yajl-2.1.0 [vega] (provided shared library changed)
  ...

  The operation will free 20 MiB.
  323 MiB to be downloaded.

  Proceed with this action? [y/N]: y
  Checking integrity... done (0 conflicting)
  pkg: 
archive_read_open_filename(localhost/usr/local/poudriere/data/packages/11amd64-default/All/pciids-20160116.txz):
  Failed to open 
'localhost/usr/local/poudriere/data/packages/11amd64-default/All/pciids-20160116.txz'

Fetch however seems to work fine:

  $ fetch 
file://localhost/usr/local/poudriere/data/packages/11amd64-default/All/pciids-20160116.txz
  pciids-20160116.txz   100% of  191 kB  332 MBps 00m00s

Fetch also works fine using my hostname (vega) instead of localhost,
while 'pkg upgrade' still fails in the same way.  I am not using DNS
for local hosts, just /etc/hosts.

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

Re: pkg 1.6.3 unable to upgrade, URL in pkg.conf problem?

[Daniel Eischen]

On Wed, 10 Feb 2016, Daniel Eischen wrote:


I'm trying to upgrade my ports with a set that I built using poudriere.
I'm running FreeBSD-current r295354, pkg 1.6.3.

The packages are here on my local (localhost, vega) box:

 /usr/local/poudriere/data/packages/11amd64-default

My repo pkg.conf (vega.conf) looks like this:

 vega: {
   url: 
"file://localhost/usr/local/poudriere/data/packages/11amd64-default",

   mirror_type: "srv",


BTW, I changed mirror_type to "none", but it doesn't make a difference,
still fails in the same way.

--
DE
___
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: Removing documentation

[Kevin Oberman]

On Mon, Feb 8, 2016 at 1:55 AM, John Marino  wrote:

> On 2/8/2016 10:30 AM, Mathias Picker wrote:
> > Am Montag, den 08.02.2016, 08:35 +0100 schrieb John Marino:
> > While I like the ideas of synth, and hoped I could use it to just build
> > my 3-8 ports with modified options, on first look I found many things
> > suggesting that it's not yet ready:
> >
> > - shows uninteresting eye candy instead of build
>
> Every single port has it's own build log with far more detail that a
> source build provides (similar to poudriere)
>
> > - stops at every conf file version mismatch requiring me to start make
> > config by hand, and then to re-run when it discovers the next mismatch.
> > I mean, WTF?
>
> This is incorrect.  It lists *ALL* the configuration mismatches at once.
>  This is actually a huge "pro" for synth; no other tool detects this
> mismatches.  It is far worse to have cached options that do not match
> the current port.  The port can be misbuilt and it's a major pain to
> troubleshoot.  All build tools should be doing this.  Are you really
> proposing that a tool build a port with a bad configuration file?  You
> should be thanking Synth for alerting to a problem you obviously didn't
> know you had.
>
> Also, once you fix it, then configuration problems are rare, they occur
> when the port changes.
>

OK. I have been playing with synth and I must say that I find it
impressive. Not that I am ready to put it into  "production", but
impressive, none the less. Maybe after a bit more testing and updating all
ports after moving from 10 to 11 (which will not be too soon). Still, it is
way better than poudriere for my limited purposes. I will certainly use it
for that, even if I still use portmaster for my "development" system.

The stale configuration file issue has me a bit confused. The man page does
not make it clear just what makes a config "stale". All of my ports are up
to date as of 11:00 UTC this morning. As far as I know, all of the configs
are "current", although the actual config run may have been for a much
older version. "synth status shows 46 cases. I looked at one
(sysutils/tmux) and the options listed by "make showconfig" are no
different from those in the current Makefile, so I don't understand why
they are stale.

I also have found at least one thing portmster can do that synth can't, but
I expect pkg can, so I won't complain about it until I have tried using pkg
to list all top-level ports (nothing depends on them) to use to re-install
all ports. I could list all ports, it's just that this is a much longer
list and portmaster did the job nicely with a simple example in the man
page.

And, please, everyone, let's stop with the silly statements like "the
Handbook should be limited to the base system" or "a maintainer needs to be
able to fix all PRs". At least one is a trivial annoyance in the display
only that is amazingly hard to fix. I asked Doug about it quite a while ago
and he said that he's keep beating on it, but a proper fix would
substantially complicate the script and be rather fragile, as well. I
assume that he is no longer beating on it.

> --
> Kevin Oberman, Part time kid herder and retired Network Engineer
> E-mail: rkober...@gmail.com
> PGP Fingerprint: D03FB98AFA78E3B78C1694B318AB39EF1B055683
>
>
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: pkg 1.6.3 unable to upgrade, URL in pkg.conf problem?

[Dimitry Andric]

On 10 Feb 2016, at 20:10, Daniel Eischen  wrote:
> 
> I'm trying to upgrade my ports with a set that I built using poudriere.
> I'm running FreeBSD-current r295354, pkg 1.6.3.
> 
> The packages are here on my local (localhost, vega) box:
> 
>  /usr/local/poudriere/data/packages/11amd64-default
> 
> My repo pkg.conf (vega.conf) looks like this:
> 
>  vega: {
>url: "file://localhost/usr/local/poudriere/data/packages/11amd64-default",

Try using file:/// (e.g three slashes).  Yes, this is ugly, and Tim
Berners-Lee has even apologized for it... :-) [1]

-Dimitry

[1] http://news.bbc.co.uk/2/hi/technology/8306631.stm



signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: Removing documentation

[John Marino]

On 2/10/2016 11:31 PM, Alphons van Werven wrote:
> ???Between all the question marks (sorry, I just can't help myself) I
> can reveal that Portmaster detects at least some of the above kinds of
> changes. Perhaps not all four, but at least some (if not most).
> 
> I suspect it's probably not so much a matter of a feature having been
> removed, but rather of Portmaster insufficiently keeping up with the ports
> infrastructure in general and the options framework in particular. It's an
> orphaned port after all.

Well, if I make the assume that Kevin has been using portmaster, and
that using Synth revealed 42 obsolete cached configurations, I would
have to conclude PM doesn't do this anymore or does it very poorly and
misses a large number of configs.

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

Re: pkg 1.6.3 unable to upgrade, URL in pkg.conf problem?

[Daniel Eischen]

On Wed, 10 Feb 2016, Dimitry Andric wrote:


On 10 Feb 2016, at 20:10, Daniel Eischen  wrote:


I'm trying to upgrade my ports with a set that I built using poudriere.
I'm running FreeBSD-current r295354, pkg 1.6.3.

The packages are here on my local (localhost, vega) box:

 /usr/local/poudriere/data/packages/11amd64-default

My repo pkg.conf (vega.conf) looks like this:

 vega: {
   url: "file://localhost/usr/local/poudriere/data/packages/11amd64-default",


Try using file:/// (e.g three slashes).  Yes, this is ugly, and Tim
Berners-Lee has even apologized for it... :-) [1]


Nope, that doesn't work either.  Previously, I used:

  url: "file:/usr/local/poudriere/data/packages/11amd64-default

and that worked until upgrading to a more recent -current and pkg
at the same time.  fetch(1,3) do not work with that syntax any more
and pkg complains with "pkg: invalid url: file:/usr/local/..."

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

Re: pkg 1.6.3 unable to upgrade, URL in pkg.conf problem?

[Baptiste Daroussin]

On Wed, Feb 10, 2016 at 10:16:44PM +0100, Dimitry Andric wrote:
> On 10 Feb 2016, at 20:10, Daniel Eischen  wrote:
> > 
> > I'm trying to upgrade my ports with a set that I built using poudriere.
> > I'm running FreeBSD-current r295354, pkg 1.6.3.
> > 
> > The packages are here on my local (localhost, vega) box:
> > 
> >  /usr/local/poudriere/data/packages/11amd64-default
> > 
> > My repo pkg.conf (vega.conf) looks like this:
> > 
> >  vega: {
> >url: 
> > "file://localhost/usr/local/poudriere/data/packages/11amd64-default",
> 
> Try using file:/// (e.g three slashes).  Yes, this is ugly, and Tim
> Berners-Lee has even apologized for it... :-) [1]
> 
> -Dimitry
> 
> [1] http://news.bbc.co.uk/2/hi/technology/8306631.stm
> 
Yes that is it.

Note that I will relax it in pkg 1.6.4 to be released very soon, I have been too
strict by accident in pkg 1.6.3 (I have never thought anyone would use file://
or file:/.

pkg respects RFC2396 but there are not reason not to relax it a bit given some
users seems to use the previous syntax

Best regards,
Bapt


signature.asc
Description: PGP signature

Re: Removing documentation

[Alphons van Werven]

John Marino wrote:

> Well, if I make the assume that Kevin has been using portmaster, and
> that using Synth revealed 42 obsolete cached configurations, I would
> have to conclude PM doesn't do this anymore or does it very poorly and
> misses a large number of configs.

Using the latest version of Portmaster, I feel confident in stating that
the "doesn't do this anymore" part appears to be false. My money is on
incomplete detection, i.e. detecting only a subset (but doing at least
that part correctly) of all possible kinds of option changes.

However, I did not intend to sidetrack the discussion. As previously
mentioned, it's just an observation.

Fonz

-- 
Get the cheese to sickbay. The doctor should look at it as soon as possible.
-- Lt. B'Elanna Torres


signature.asc
Description: PGP signature

Re: Removing documentation

[John Marino]

On 2/10/2016 10:15 PM, Kevin Oberman wrote:
> 
> The stale configuration file issue has me a bit confused. The man page
> does not make it clear just what makes a config "stale". All of my ports
> are up to date as of 11:00 UTC this morning. As far as I know, all of
> the configs are "current", although the actual config run may have been
> for a much older version. "synth status shows 46 cases. I looked at one
> (sysutils/tmux) and the options listed by "make showconfig" are no
> different from those in the current Makefile, so I don't understand why
> they are stale.

Stale isn't the right word.  You could use "invalid" or "obsolete"
instead.  The saved configuration does not match the current port.

Imagine a month ago you run "make config".  It saves the status of the 4
options on this imaginary port.  Now imagine any of the following
happening to the port.

A) An option is added
B) An option is removed
C) An option default changed.
D) Any other option configuration changed.

Now the month-old saved configuration doesn't match the port.  See the
problem?

Synth is the *only* tool that detects this.  The rest keep using the old
configuration the best they can, resulting in hard to track down bugs.
Removing the saved configuration solves the problem; then Synth uses the
defaults.  Running "make config" also solves the problem, the
configuration will match the port again.

 > I also have found at least one thing portmster can do that synth can't,
> but I expect pkg can, so I won't complain about it until I have tried
> using pkg to list all top-level ports (nothing depends on them) to use
> to re-install all ports. I could list all ports, it's just that this is
> a much longer list and portmaster did the job nicely with a simple
> example in the man page.

You don't need to list all the ports.  Like you said, "pkg prime-list >
my.list" and there's your top level.  Or "synth upgrade" system and
upgrade everything.  Either approach works.  The tight integration with
pkg is helpful.



> And, please, everyone, let's stop with the silly statements like "the
> Handbook should be limited to the base system" or "a maintainer needs to
> be able to fix all PRs". 

"All" is literal.  Nobody expects all PRs to be valid.
It's a moot point anyway, Torsten is now officially the maintainer
(based on faith I guess) so for now there's no issue.  Let's hope he is
successful.

John
___
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: Removing documentation

[Alphons van Werven]

Freddie Cash wrote:

>> A) An option is added
>> B) An option is removed
>> C) An option default changed.
>> D) Any other option configuration changed.
>>
>> Synth is the *only* tool that detects this.
 
> ???portmaster used to do this; was this option removed?  It was one of the
> nicer features of portmaster and really came in handy in the past.
> 
> Haven't used portmaster since 9.something when pkg really became useful
> and I stopped building anything from source, so maybe this feature was
> removed

???Between all the question marks (sorry, I just can't help myself) I
can reveal that Portmaster detects at least some of the above kinds of
changes. Perhaps not all four, but at least some (if not most).

I suspect it's probably not so much a matter of a feature having been
removed, but rather of Portmaster insufficiently keeping up with the ports
infrastructure in general and the options framework in particular. It's an
orphaned port after all.

Just an observation.

Fonz

-- 
obsig: developing a new sig


signature.asc
Description: PGP signature

Re: Removing documentation

[Lars Engels]

On Wed, Feb 10, 2016 at 01:15:58PM -0800, Kevin Oberman wrote:
> On Mon, Feb 8, 2016 at 1:55 AM, John Marino  wrote:
> 
> > On 2/8/2016 10:30 AM, Mathias Picker wrote:
> > > Am Montag, den 08.02.2016, 08:35 +0100 schrieb John Marino:
> > > While I like the ideas of synth, and hoped I could use it to just build
> > > my 3-8 ports with modified options, on first look I found many things
> > > suggesting that it's not yet ready:
> > >
> > > - shows uninteresting eye candy instead of build
> >
> > Every single port has it's own build log with far more detail that a
> > source build provides (similar to poudriere)
> >
> > > - stops at every conf file version mismatch requiring me to start make
> > > config by hand, and then to re-run when it discovers the next mismatch.
> > > I mean, WTF?
> >
> > This is incorrect.  It lists *ALL* the configuration mismatches at once.
> >  This is actually a huge "pro" for synth; no other tool detects this
> > mismatches.  It is far worse to have cached options that do not match
> > the current port.  The port can be misbuilt and it's a major pain to
> > troubleshoot.  All build tools should be doing this.  Are you really
> > proposing that a tool build a port with a bad configuration file?  You
> > should be thanking Synth for alerting to a problem you obviously didn't
> > know you had.
> >
> > Also, once you fix it, then configuration problems are rare, they occur
> > when the port changes.
> >
> 
> OK. I have been playing with synth and I must say that I find it
> impressive. Not that I am ready to put it into  "production", but
> impressive, none the less. Maybe after a bit more testing and updating all
> ports after moving from 10 to 11 (which will not be too soon). Still, it is
> way better than poudriere for my limited purposes. I will certainly use it
> for that, even if I still use portmaster for my "development" system.
> 
> The stale configuration file issue has me a bit confused. The man page does
> not make it clear just what makes a config "stale". All of my ports are up
> to date as of 11:00 UTC this morning. As far as I know, all of the configs
> are "current", although the actual config run may have been for a much
> older version. "synth status shows 46 cases. I looked at one
> (sysutils/tmux) and the options listed by "make showconfig" are no
> different from those in the current Makefile, so I don't understand why
> they are stale.
> 
> I also have found at least one thing portmster can do that synth can't, but
> I expect pkg can, so I won't complain about it until I have tried using pkg
> to list all top-level ports (nothing depends on them) to use to re-install
> all ports. I could list all ports, it's just that this is a much longer
> list and portmaster did the job nicely with a simple example in the man
> page.

You need to uncomment the "leaf" alias in /usr/local/etc/pkg.conf

leaf  'query -e "%a == 0" "%n-%v"'

Then "pkg leaf" works like pkg_cutleaves(8) or the portmaster option.



pgp7fz14CNcgV.pgp
Description: PGP signature

Re: Removing documentation

[Freddie Cash]

On Wed, Feb 10, 2016 at 1:46 PM, John Marino  wrote:

> On 2/10/2016 10:15 PM, Kevin Oberman wrote:
> >
> > The stale configuration file issue has me a bit confused. The man page
> > does not make it clear just what makes a config "stale". All of my ports
> > are up to date as of 11:00 UTC this morning. As far as I know, all of
> > the configs are "current", although the actual config run may have been
> > for a much older version. "synth status shows 46 cases. I looked at one
> > (sysutils/tmux) and the options listed by "make showconfig" are no
> > different from those in the current Makefile, so I don't understand why
> > they are stale.
>
> Stale isn't the right word.  You could use "invalid" or "obsolete"
> instead.  The saved configuration does not match the current port.
>
> Imagine a month ago you run "make config".  It saves the status of the 4
> options on this imaginary port.  Now imagine any of the following
> happening to the port.
>
> A) An option is added
> B) An option is removed
> C) An option default changed.
> D) Any other option configuration changed.
>
> Now the month-old saved configuration doesn't match the port.  See the
> problem?
>
> Synth is the *only* tool that detects this.


​portmaster used to do this; was this option removed?  It was one of the
nicer features of portmaster and really came in handy in the past.

Haven't used portmaster since 9.something when pkg really became useful and
I stopped building anything from source, so maybe this feature was removed?​


-- 
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: pkg 1.6.3 unable to upgrade, URL in pkg.conf problem?

[Warren Block]

On Wed, 10 Feb 2016, Daniel Eischen wrote:


On Wed, 10 Feb 2016, Dimitry Andric wrote:


On 10 Feb 2016, at 20:10, Daniel Eischen  wrote:


I'm trying to upgrade my ports with a set that I built using poudriere.
I'm running FreeBSD-current r295354, pkg 1.6.3.

The packages are here on my local (localhost, vega) box:

 /usr/local/poudriere/data/packages/11amd64-default

My repo pkg.conf (vega.conf) looks like this:

 vega: {
   url: 
"file://localhost/usr/local/poudriere/data/packages/11amd64-default",


Try using file:/// (e.g three slashes).  Yes, this is ugly, and Tim
Berners-Lee has even apologized for it... :-) [1]


Nope, that doesn't work either.  Previously, I used:

 url: "file:/usr/local/poudriere/data/packages/11amd64-default

and that worked until upgrading to a more recent -current and pkg
at the same time.  fetch(1,3) do not work with that syntax any more
and pkg complains with "pkg: invalid url: file:/usr/local/..."


Not with localhost, no.  It's file:// and then the path, which begins 
with a slash, so


file:///usr/local/poudriere/data/packages/11amd64-default
___
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: Removing documentation

[John Marino]

On 2/10/2016 10:37 AM, Lars Engels wrote:
> On Tue, Feb 09, 2016 at 06:28:11PM +0100, John Marino wrote:
>> On 2/9/2016 4:15 PM, Lars Engels wrote:
>>>
>>> root@fbsd01:~ # synth status
>>> Querying system about current package installations.
>>> Stand by, comparing installed packages against the ports tree.
>>> Stand by, building pkg(8) first ... Failed!!  (Synth must exit)
>>> Unfortunately, the system upgrade failed.
>>
>> Do you have a file called /var/log/synth/ports-mgmt___pkg.log ?  If so,
>> does it provide clues?
> 
> So it's missing the proxy variables.
> 

okay, so internally it's only installing resolv.conf in the builder
environment.  Where are these proxy variables defined?  When I
understand what's needed, I can give you a patch to try (if required)

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

Re: maintaining portmaster ? was: Re: Removing documentation

[Kurt Jaeger]

Hi!

> >> I did take a look. I could do both: maintaining the port and maintaining 
> >> the software. What do you need? ;)
> >
> >Submit patches to the 12 PRs open for portmaster:
> >
> >https://bugs.freebsd.org/bugzilla/buglist.cgi?quicksearch=portmaster
> 
> That is just being silly.

Sorry if my mail was misinterpretable: I do not insist that Torsten
has to fix every single PR to become maintainer, far from it.

And I neither use portmaster nor synth in my setups, I use poudriere and
portupgrade, so I'm not really part of the debate.

Clearly, the documentation of the process in the handbook can be
improved, and if this involves some words on alternatives, its even
better.

> Providing a patch for one of
> the bugs would probably be sufficient for demonstrating interest
> and ability.

Yes, I understand that. It was not my intention to put up undue hurdles.

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

Re: Removing documentation

[John Marino]

On 2/10/2016 11:09 AM, Lars Engels wrote:
> On Wed, Feb 10, 2016 at 10:40:44AM +0100, John Marino wrote:
>> On 2/10/2016 10:37 AM, Lars Engels wrote:
>>> On Tue, Feb 09, 2016 at 06:28:11PM +0100, John Marino wrote:
 On 2/9/2016 4:15 PM, Lars Engels wrote:
>
> root@fbsd01:~ # synth status
> Querying system about current package installations.
> Stand by, comparing installed packages against the ports tree.
> Stand by, building pkg(8) first ... Failed!!  (Synth must exit)
> Unfortunately, the system upgrade failed.

 Do you have a file called /var/log/synth/ports-mgmt___pkg.log ?  If so,
 does it provide clues?
>>>
>>> So it's missing the proxy variables.
>>>
>>
>> okay, so internally it's only installing resolv.conf in the builder
>> environment.  Where are these proxy variables defined?  When I
>> understand what's needed, I can give you a patch to try (if required)
> 
> resolv.conf doesn't work in that proxy scenario. DNS requests are
> handled by the proxy server.
> 
> I set
> HTTP_PROXY=http://proxyserver:; export HTTP_PROXY
> http_proxy=http://proxyserver:; export http_proxy
> ftp_proxy=http://proxyserver:; export FTP_PROXY
> ftp_proxy=http://proxyserver:; export ftp_proxy
> 
> NO_PROXY="localhost,127.0.0.1,..."; export NO_PROXY
> 
> in /etc/profile and
> :setenv=MAIL=/var/mail/$,BLOCKSIZE=K,HTTP_PROXY=http\c//proxyserver\c,FTP_PROXY=http\c//proxyserver\c,NO_PROXY=localhost\054127.0.0.1\054...:\
> 
> in /etc/login.conf
> 

wow, okay, so basically these 4 variables would have to be present in
the builder environment then?

I'll have to think about this.  I'll probably have to add a feature like
a file like "/usr/local/etc/synth/-environment which will
append user environment variables to the stock ones.

That's not exactly a 1-line change, but would that solve this issue?

John


___
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: Moving to synth (was: Removing documentation)

[Peter Jeremy]

There are still issues moving to synth on non-Tier1 architectures:

$ sudo pkg install synth-0.99_6
Updating FreeBSD repository catalogue...
FreeBSD repository is up-to-date.
All repositories are up-to-date.
Updating database digests format: 100%
pkg: No packages available to install matching 'synth-0.99_6' have been found 
in the repositories
$ make
===>   synth-0.99_6 depends on file: /usr/local/gcc6-aux/bin/ada - not found
===>  gcc6-aux-20160124 is only for amd64 i386, while you are running armv6hf.
*** Error code 1

Stop.
make[1]: stopped in /usr/ports/lang/gcc6-aux
*** Error code 1

Stop.
make: stopped in /usr/ports/ports-mgmt/synth

-- 
Peter Jeremy


signature.asc
Description: PGP signature

Re: Moving to synth

[John Marino]

On 2/10/2016 12:10 PM, Peter Jeremy wrote:
> There are still issues moving to synth on non-Tier1 architectures:

This limitation has been known and published from the beginning (bapt@
recently iterated it for those that weren't aware).

It would actually be possible to support ARM fairly easily, but stuff
like MIPS, sparc64, etc, would not be easy.  Bapt also points out that
building gcc on ARM would be undesiraable.

However, there is always poudriere and torsten may get portmaster in
good shape so T2 has options.
___
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: Removing documentation

[Lars Engels]

On Wed, Feb 10, 2016 at 10:40:44AM +0100, John Marino wrote:
> On 2/10/2016 10:37 AM, Lars Engels wrote:
> > On Tue, Feb 09, 2016 at 06:28:11PM +0100, John Marino wrote:
> >> On 2/9/2016 4:15 PM, Lars Engels wrote:
> >>>
> >>> root@fbsd01:~ # synth status
> >>> Querying system about current package installations.
> >>> Stand by, comparing installed packages against the ports tree.
> >>> Stand by, building pkg(8) first ... Failed!!  (Synth must exit)
> >>> Unfortunately, the system upgrade failed.
> >>
> >> Do you have a file called /var/log/synth/ports-mgmt___pkg.log ?  If so,
> >> does it provide clues?
> > 
> > So it's missing the proxy variables.
> > 
> 
> okay, so internally it's only installing resolv.conf in the builder
> environment.  Where are these proxy variables defined?  When I
> understand what's needed, I can give you a patch to try (if required)

resolv.conf doesn't work in that proxy scenario. DNS requests are
handled by the proxy server.

I set
HTTP_PROXY=http://proxyserver:; export HTTP_PROXY
http_proxy=http://proxyserver:; export http_proxy
ftp_proxy=http://proxyserver:; export FTP_PROXY
ftp_proxy=http://proxyserver:; export ftp_proxy

NO_PROXY="localhost,127.0.0.1,..."; export NO_PROXY

in /etc/profile and
:setenv=MAIL=/var/mail/$,BLOCKSIZE=K,HTTP_PROXY=http\c//proxyserver\c,FTP_PROXY=http\c//proxyserver\c,NO_PROXY=localhost\054127.0.0.1\054...:\

in /etc/login.conf



pgpKuGecm22cx.pgp
Description: PGP signature

Re: Removing documentation

[Lars Engels]

My rather short experience:

Synth configuration profile: LiveSystem
===
   [A] Ports directory/usr/ports
   [B] Packages directory /var/synth/live_packages
   [C] Distfiles directory/usr/ports/distfiles
   [D] Port options directory /var/db/ports
   [E] Build logs directory   /var/log/synth
   [F] Build base directory   /usr/obj/synth-live
   [G] System root directory  /
   [H] Compiler cache directory   disabled
   [I] Num. concurrent builders   6
   [J] Max. jobs per builder  4
   [K] Use tmpfs for work areatrue
   [L] Use tmpfs for /usr/local   true
   [M] Display using ncurses  true
   [N] Fetch prebuilt packagestrue

   [>]   Switch/create profiles
   [RET] Exit

Press key of selection:
root@fbsd01:~ # synth status
Querying system about current package installations.
Stand by, comparing installed packages against the ports tree.
Stand by, building pkg(8) first ... Failed!!  (Synth must exit)
Unfortunately, the system upgrade failed.
root@fbsd01:~ # uname -a
FreeBSD fbsd01 10.2-RELEASE-p9 FreeBSD 10.2-RELEASE-p9 #0: Thu Jan 14 01:32:46 
UTC 2016 r...@amd64-builder.daemonology.net:/usr/obj/usr/src/sys/GENERIC  
amd64
root@fbsd01:~ #


Not a very verbose message why it actually failed.
I need a proxy server to access the internet. Could this be the problem?
*_[pP][rR][oO][xX][yY] env vars are all set, though.


pgpCiYdOtis8M.pgp
Description: PGP signature

Re: Removing documentation

[John Marino]

On 2/9/2016 9:27 PM, John Marino wrote:
> On 2/9/2016 9:20 PM, Warren Block wrote:
>> On Tue, 9 Feb 2016, John Marino wrote:
>>
>>> On 2/9/2016 7:20 PM, Warren Block wrote:
> If you have the build log, I'd like to see it.  Dewayne G. got an error
> after overriding CPUTYPE (do you do that too?) and I'm thinking it's
> sensitive to CPU and I'd like to know more.

 Yes, I use

 CPUTYPE?=core-avx2
>>>
>>> What happens when you try to build lang/gcc6-devel ?
>>> Same issue or does it complete?
>>
>> It builds successfully, in about 40 minutes.
> 
> My suspicion is that due to the bootstrap, we'd have two possible options:
> A) turn on the full bootstrap which takes the same amount of time as
> gcc6-devel does (I'm not sure it will work but there's a chance)
> B) I put CPUTYPE=native in the gcc6-aux Makefile
> 
> I am inclined towards B.  It works on DragonFly but I need somebody else
> to test it on i7 on FreeBSD.  I asked Dewayne, but I'd be grateful if
> you could test it as well.

Hi Warren,
Dewayne got back to me, and it appears the only solution is to put
"CPUTYPE=" in the gcc6-aux makefile.  I think the bootstrap compiler
(the ada-capable compiler downloaded to build gcc6-aux) doesn't know
these instructions and that's the issue.  The options are don't override
CPUTYPE or regenerate the bootstrap, but that might have other
consequences or won't fix every combination.

John


___
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: synth documentation

[John Marino]

On 2/10/2016 2:57 AM, Greg 'groggy' Lehey wrote:
> I installed the synth package a couple of days ago, mainly to take a
> look.  And yes, I agree, if you're happy with the package (I would
> be), the Ada dependencies and long build times aren't an issue. 

I'm racking my brains and I can't find a single rational reason why
somebody would refuse the package (especially if building it on an Atom
is the alternative).

1) It's a binary executable, it either works or it doesn't.
2) It's not a library; nothing else depends on it.
3) The packages are signed by FreeBSD so they are known to be officially
built and unaltered.
4) There's no performance characteristics to be gained by building it
with custom flags.
5) At the moment, synth has no build options.


I don't see a rationale justification for not using the package *IF* the
dependencies are perceived to be heavy.  The exchange should go like this:

A) "Synth has too many build dependencies (1 is too many)"
B) "Use the official FreeBSD package, it's small and downloads quickly."
A) "I don't want to, I build everything myself."
B) "Then don't complain."


I would love to hear rationale from [A] that would withstand scrutiny
but so far I haven't been able to imagine any myself.

John




___
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: synth documentation

[Kurt Jaeger]

Hi!

> I'm racking my brains and I can't find a single rational reason why
> somebody would refuse the package (especially if building it on an Atom
> is the alternative).

The famous paper from Ken Thompson: Reflections on trusting trust

http://dl.acm.org/citation.cfm?doid=358198.358210

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

Re: synth documentation

[John Marino]

On 2/10/2016 10:01 AM, Kurt Jaeger wrote:
> Hi!
> 
>> I'm racking my brains and I can't find a single rational reason why
>> somebody would refuse the package (especially if building it on an Atom
>> is the alternative).
> 
> The famous paper from Ken Thompson: Reflections on trusting trust
> 
> http://dl.acm.org/citation.cfm?doid=358198.358210
> 

The source is publicly available on github.  The only way that Thompson
paper could apply is if a trojan is inserted at the FreeBSD package
builder level.

So I guess [A] could say FreeBSD package builder is compromised
(intentionally by FreeBSD project or unknown to all due a hacker).  And
I guess that could be possible, but the counter is: If you cant' trust
packages built by FreeBSD, how can you trust the FreeBSD base not to
have a trojan?

Which would mean that only the people that *also* build FreeBSD from
source would have a leg to stand on.

So I will concede that case: If you accept no binaries at all from
FreeBSD and only build base and packages from source, then you have a
point.  But still the response, "Then don't complain" applies.  It's a
conscious decision and consequences of decisions must be accepted.

Beside, this theoretical person will have a lot more issues that lil'
ole Synth.  It will be in the noise compared to Libreoffice, webkit
(x5), kde, etc.

John
___
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
+-+
net-mgmt/weathermap | 1.1.1   | 15.0.0
+-+


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: Removing documentation

[Lars Engels]

On Wed, Feb 10, 2016 at 11:16:10AM +0100, John Marino wrote:
> On 2/10/2016 11:09 AM, Lars Engels wrote:
> > On Wed, Feb 10, 2016 at 10:40:44AM +0100, John Marino wrote:
> >> On 2/10/2016 10:37 AM, Lars Engels wrote:
> >>> On Tue, Feb 09, 2016 at 06:28:11PM +0100, John Marino wrote:
>  On 2/9/2016 4:15 PM, Lars Engels wrote:
> >
> > root@fbsd01:~ # synth status
> > Querying system about current package installations.
> > Stand by, comparing installed packages against the ports tree.
> > Stand by, building pkg(8) first ... Failed!!  (Synth must exit)
> > Unfortunately, the system upgrade failed.
> 
>  Do you have a file called /var/log/synth/ports-mgmt___pkg.log ?  If so,
>  does it provide clues?
> >>>
> >>> So it's missing the proxy variables.
> >>>
> >>
> >> okay, so internally it's only installing resolv.conf in the builder
> >> environment.  Where are these proxy variables defined?  When I
> >> understand what's needed, I can give you a patch to try (if required)
> > 
> > resolv.conf doesn't work in that proxy scenario. DNS requests are
> > handled by the proxy server.
> > 
> > I set
> > HTTP_PROXY=http://proxyserver:; export HTTP_PROXY
> > http_proxy=http://proxyserver:; export http_proxy
> > ftp_proxy=http://proxyserver:; export FTP_PROXY
> > ftp_proxy=http://proxyserver:; export ftp_proxy
> > 
> > NO_PROXY="localhost,127.0.0.1,..."; export NO_PROXY
> > 
> > in /etc/profile and
> > :setenv=MAIL=/var/mail/$,BLOCKSIZE=K,HTTP_PROXY=http\c//proxyserver\c,FTP_PROXY=http\c//proxyserver\c,NO_PROXY=localhost\054127.0.0.1\054...:\
> > 
> > in /etc/login.conf
> > 
> 
> wow, okay, so basically these 4 variables would have to be present in
> the builder environment then?
> 
> I'll have to think about this.  I'll probably have to add a feature like
> a file like "/usr/local/etc/synth/-environment which will
> append user environment variables to the stock ones.
> 
> That's not exactly a 1-line change, but would that solve this issue?

That should work, yes.


pgpieLkC5c1Qe.pgp
Description: PGP signature

Re: maintaining portmaster ? was: Re: Removing documentation

[Torsten Zuehlsdorff]

On 10.02.2016 06:47, Peter Jeremy wrote:

On 2016-Feb-09 21:24:56 +0100, Kurt Jaeger  wrote:

Torsten wrote:


I did take a look. I could do both: maintaining the port and maintaining
the software. What do you need? ;)


Submit patches to the 12 PRs open for portmaster:

https://bugs.freebsd.org/bugzilla/buglist.cgi?quicksearch=portmaster


That is just being silly.

I'd start by triaging those bugs.  One is clearly a kernel bug,
another maybe a bug in a different port and one is described as a
feature request.  The remaining 9 may or may not still be bugs in
portmaster that are still relevant.  Providing a patch for one of
the bugs would probably be sufficient for demonstrating interest
and ability.


The discussion also put some attention at the existing PRs. Walter 
already tried to reproduce some of the PRs and give some feedback, for 
example that an issue is not reproducibly at the current time. I think 
this will be true for most of the PRs.


One already brings a patch with it. The first work will be most 
management of the PRs.


I'm asking myself how to manage the code. Should i create a new GitHub 
repository? Fork the existing from freebsd/portmaster? How to handle the 
LOCAL Master-Site?


I submitted a PR to take maintainer-ship for portmaster:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=207075

Also i fix some minor glitches and add missing RUN_DEPENDS.

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

Re: Removing documentation

[Lars Engels]

On Tue, Feb 09, 2016 at 06:28:11PM +0100, John Marino wrote:
> On 2/9/2016 4:15 PM, Lars Engels wrote:
> > 
> > root@fbsd01:~ # synth status
> > Querying system about current package installations.
> > Stand by, comparing installed packages against the ports tree.
> > Stand by, building pkg(8) first ... Failed!!  (Synth must exit)
> > Unfortunately, the system upgrade failed.
> 
> Do you have a file called /var/log/synth/ports-mgmt___pkg.log ?  If so,
> does it provide clues?
> 
> John

=> pkg-1.6.3.tar.xz doesn't seem to exist in /distfiles/.
=> Attempting to fetch http://files.etoilebsd.net/pkg/pkg-1.6.3.tar.xz
fetch: http://files.etoilebsd.net/pkg/pkg-1.6.3.tar.xz: No address record
=> Attempting to fetch 
http://distcache.FreeBSD.org/local-distfiles/portmgr/pkg-1.6.3.tar.xz
fetch: http://distcache.FreeBSD.org/local-distfiles/portmgr/pkg-1.6.3.tar.xz: 
No address record
=> Attempting to fetch 
http://distcache.us-east.FreeBSD.org/local-distfiles/portmgr/pkg-1.6.3.tar.xz
fetch: 
http://distcache.us-east.FreeBSD.org/local-distfiles/portmgr/pkg-1.6.3.tar.xz: 
No address record
=> Attempting to fetch 
http://distcache.eu.FreeBSD.org/local-distfiles/portmgr/pkg-1.6.3.tar.xz
fetch: 
http://distcache.eu.FreeBSD.org/local-distfiles/portmgr/pkg-1.6.3.tar.xz: No 
address record
=> Attempting to fetch 
http://distcache.us-west.FreeBSD.org/local-distfiles/portmgr/pkg-1.6.3.tar.xz
fetch: 
http://distcache.us-west.FreeBSD.org/local-distfiles/portmgr/pkg-1.6.3.tar.xz: 
No address record
=> Attempting to fetch http://mirror.shatow.net/freebsd/pkg/pkg-1.6.3.tar.xz
fetch: http://mirror.shatow.net/freebsd/pkg/pkg-1.6.3.tar.xz: No address record
=> Attempting to fetch 
http://distcache.FreeBSD.org/ports-distfiles/pkg-1.6.3.tar.xz
fetch: http://distcache.FreeBSD.org/ports-distfiles/pkg-1.6.3.tar.xz: No 
address record
=> Couldn't fetch it - please try to retrieve this
=> port manually into /distfiles/ and try again.


So it's missing the proxy variables.


pgpb4YOGt1H9b.pgp
Description: PGP signature

Re: Please commit PR#203931 dns/knot2

[Kurt Jaeger]

Hi!

> has maintainer approval. thanks everyone
> 
> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=203931

Done.

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

Please commit PR#203931 dns/knot2

[Chad J. Milios]

has maintainer approval. thanks everyone

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=203931
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: pkg 1.6.3 unable to upgrade, URL in pkg.conf problem?

[Daniel Eischen]

On Wed, 10 Feb 2016, Warren Block wrote:


On Wed, 10 Feb 2016, Daniel Eischen wrote:


On Wed, 10 Feb 2016, Dimitry Andric wrote:


On 10 Feb 2016, at 20:10, Daniel Eischen  wrote:


I'm trying to upgrade my ports with a set that I built using poudriere.
I'm running FreeBSD-current r295354, pkg 1.6.3.

The packages are here on my local (localhost, vega) box:

 /usr/local/poudriere/data/packages/11amd64-default

My repo pkg.conf (vega.conf) looks like this:

 vega: {
   url: 
"file://localhost/usr/local/poudriere/data/packages/11amd64-default",


Try using file:/// (e.g three slashes).  Yes, this is ugly, and Tim
Berners-Lee has even apologized for it... :-) [1]


Nope, that doesn't work either.  Previously, I used:

 url: "file:/usr/local/poudriere/data/packages/11amd64-default

and that worked until upgrading to a more recent -current and pkg
at the same time.  fetch(1,3) do not work with that syntax any more
and pkg complains with "pkg: invalid url: file:/usr/local/..."


Not with localhost, no.  It's file:// and then the path, which begins with a 
slash, so


file:///usr/local/poudriere/data/packages/11amd64-default


Thanks!  That did the trick.

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

Re: pkg 1.6.3 unable to upgrade, URL in pkg.conf problem?

[Daniel Eischen]

On Wed, 10 Feb 2016, Baptiste Daroussin wrote:


On Wed, Feb 10, 2016 at 10:16:44PM +0100, Dimitry Andric wrote:

On 10 Feb 2016, at 20:10, Daniel Eischen  wrote:


I'm trying to upgrade my ports with a set that I built using poudriere.
I'm running FreeBSD-current r295354, pkg 1.6.3.

The packages are here on my local (localhost, vega) box:

 /usr/local/poudriere/data/packages/11amd64-default

My repo pkg.conf (vega.conf) looks like this:

 vega: {
   url: "file://localhost/usr/local/poudriere/data/packages/11amd64-default",


Try using file:/// (e.g three slashes).  Yes, this is ugly, and Tim
Berners-Lee has even apologized for it... :-) [1]

-Dimitry

[1] http://news.bbc.co.uk/2/hi/technology/8306631.stm


Yes that is it.

Note that I will relax it in pkg 1.6.4 to be released very soon, I have been too
strict by accident in pkg 1.6.3 (I have never thought anyone would use file://
or file:/.

pkg respects RFC2396 but there are not reason not to relax it a bit given some
users seems to use the previous syntax


No worries, now that I have the correct syntax.  Thanks!

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