Re: Please commit PR#203931 dns/knot2
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"
Re: pkg 1.6.3 unable to upgrade, URL in pkg.conf problem?
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"
Re: pkg 1.6.3 unable to upgrade, URL in pkg.conf problem?
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"
Please commit PR#203931 dns/knot2
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: Removing documentation
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
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?
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
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: pkg 1.6.3 unable to upgrade, URL in pkg.conf problem?
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: pkg 1.6.3 unable to upgrade, URL in pkg.conf problem?
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: Removing documentation
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: Removing documentation
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
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: pkg 1.6.3 unable to upgrade, URL in pkg.conf problem?
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
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?
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: maintaining portmaster ? was: Re: Removing documentation
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?
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"
Ports with github private repository
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: PHP7 package?
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: Removing documentation
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"
don't fork portmaster source
> 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"
Re: maintaining portmaster ? was: Re: Removing documentation
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
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: Removing documentation
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: Removing documentation
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: Removing documentation
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: Moving to synth
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
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: Moving to synth (was: Removing documentation)
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: Removing documentation
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: maintaining portmaster ? was: Re: Removing documentation
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
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"
FreeBSD ports you maintain which are out of date
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: synth documentation
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"
Re: synth documentation
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
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"