Re: Status of portupgrade and portmaster?
On Fri, Sep 29, 2017 at 09:21:31PM +0200 I heard the voice of Marco Beishuizen, and lo! it spake thus: > > Using portupgrade every day and still works great. Tried portmaster > once but liked portupgrade more. I use poudriere just for testing > ports. I also use portupgrade constantly on several systems, and portmaster occasionally for some special cases where it has advantages. I also use poudriere on a lot of systems. Actually, most, nowadays. And I'm extremely happy with it. But I expect the systems I'm running straight out of ports now will continue to do so for a very long time, since poudriere just won't fit at all. -- Matthew Fuller (MF4839) | fulle...@over-yonder.net Systems/Network Administrator | http://www.over-yonder.net/~fullermd/ On the Internet, nobody can hear you scream. ___ 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: Status of portupgrade and portmaster?
On 2017-10-02 00:19, RW via freebsd-ports wrote: I meant installing up-to-date packages from the *local* repository. So if only Firefox needs to be updated would Poudriere first install Firefox's dependencies into the jail from locally generated package files before building Firefox. Poudriere builds repositories and yes, uses any package already built in that repository if it's a build dependency for another. Note that you have multiple repos, built with different base jails, different ports trees, different sets of packages, options, make.conf options. But even for single machine use, it allows simple building of any list of wanted packages, it makes sure those and their dependencies are built, up to date (relative to the ports tree it's configured to use), and kept as a persistent repository. You can even delete a package txz from the repo manually, on next bulk run it will simply rebuild what's missing. -- Vlad K. ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: Status of portupgrade and portmaster?
On Sun, 01 Oct 2017 20:53:29 +0200 Vlad K. wrote: > On 2017-10-01 18:24, RW via freebsd-ports wrote: > > > > Do you mean as opposed to installing the dependencies from the > > repository, or are you saying that it rebuilds them? > > Poudriere builds isolated, in jails. That means it's not reusing > packages installed on the host, nor from another repo, if those are > needed as (build) dependencies. I meant installing up-to-date packages from the *local* repository. So if only Firefox needs to be updated would Poudriere first install Firefox's dependencies into the jail from locally generated package files before building Firefox. If that happens then there wouldn't be much incentive to use anything from the host as any package installed on the host would be in the local repository - you'd just save a few installs. ___ 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 Port: sudo-1.8.21p2 - 1.8.21p2 SegFaults
Hi Renato & ports : I was just stumble over this, with 12.0-CURRENT r323934, sudo 1.8.21p2 SegFaults when run in a bhyve VM - however, seemly on bare metal, its fine. sudo-1.8.20p2_3 runs just fine in bhyve VM. There are all my own builds of 12- and ports (via poudriere). I recompiled sudo on the Bhyve, and still had the same issue. -- David P. Discher • d...@ixsystems.com Director, Information Technology iXsystems, Inc. Office: 408.943.4100 x150 Mobile: 408.368.3725 signature.asc Description: Message signed with OpenPGP
Re: Status of portupgrade and portmaster?
On 2017-10-01 18:24, RW via freebsd-ports wrote: Do you mean as opposed to installing the dependencies from the repository, or are you saying that it rebuilds them? Poudriere builds isolated, in jails. That means it's not reusing packages installed on the host, nor from another repo, if those are needed as (build) dependencies. Unless of course it grew this ability recently and I'm gravely mistaken, but I don't know of such addition. -- Vlad K. ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: Debugging A Port
Thanks, It seems to work. On 01.10.2017 20:42, Kurt Jaeger wrote: Hi! What action will make the Make command to recompile a source file? That depends on the port, there's no generic way to say. Basically, the port framework adds a wrapper of targets around the upstream source Makefile and those targets can shield a recompile from happening. What sometimes work is this: cd work// make ___ 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"
lang/pdflib: I've submitted bugzilla 222722 with a patch for allowing lang/pdflib to build under __POWERPC__
I wrote in bugziila 222722: > [I tried to build math/gnuplot and it was > indirectly blocked by print/pdflib failing > to build for "missing" include files.] > > The following avoids print/pdflib classifying the > context as an old MAC context (pre-MACOSX) when > building for powerpc64 (for example): > > # more /usr/ports/print/pdflib/files/patch-libs_pdcore_pc__config.h > --- libs/pdcore/pc_config.h.orig2012-06-06 11:58:58 UTC > +++ libs/pdcore/pc_config.h > @@ -179,9 +179,11 @@ > > /* try to identify Mac OS 9 compilers */ > > +#if 0 > #if (defined macintosh || defined __POWERPC__ || defined __CFM68K__) && \ > !defined MAC && !defined MACOSX && !defined __BEOS__ > #define MAC > +#endif > #endif > > /* === Mark Millard markmi at dsl-only.net ___ 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: Debugging A Port
Hi! > What action will make the Make command to recompile a source file? That depends on the port, there's no generic way to say. Basically, the port framework adds a wrapper of targets around the upstream source Makefile and those targets can shield a recompile from happening. What sometimes work is this: cd work// make -- p...@opsec.eu+49 171 3101372 3 years to go ! ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Debugging A Port
Hi, What action will make the Make command to recompile a source file? Thanks, Amit ___ 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: Status of portupgrade and portmaster?
On Sun, Oct 1, 2017 at 12:34 PM, Carmel NYwrote: > lifting leaving me free to work on more important projects. I suppose I could > always go back to “portupgrade”; however, I understand that it is not being > maintained either. FWIW, portupgrade has received enough maintenance that it continues to work nicely on at least stable/11 and stable/10. And I am grateful for that. HTH -- Regards, Torfinn Ingolfsen ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: Status of portupgrade and portmaster?
On Sun, 01 Oct 2017 12:26:25 +0200 Vlad K. wrote: > Another problem is poudriere's inability to reuse already installed > packages, if they're a dependency for something being built by it. > Personally I'd never use that option, as I want clean, isolated > rebuilds of everything affected, but I can understand how quick > building of one or two packages could use already installed deps, if > people wanted that (and break any promise of integrity facilitated > with isolated builds). Do you mean as opposed to installing the dependencies from the repository, or are you saying that it rebuilds them? ___ 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: Status of portupgrade and portmaster?
On 2017-10-01 12:34, Carmel NY wrote: 1. Does it determine out-of-date update packages automatically or does the user have to determine that what is out-of-date and feed them to poudriere manually and in the proper order? 2. From what I have read, the user is required to install each package manually. Is that correct? It's not. Poudriere builds a pkg repo, and automatically rebuilds all ports that have changed version (including epoch and portrevision, so essentially -- changed version string), including all ports that depend on ports that changed (see my previous post about frequent rebuilds), or became a new dependency. So you can have it build updates in the background and when you're done, just issue pkg upgrade. Another benefit of this approach is that you don't get partial updates for a program that's in active use. I've seen this cause failure a lot of times, eg with perl. The master program is running or being actively run (from cron or initiated by user), not yet updated but a dep just updated. Crash. I have a small system. Three PCs plus a number of laptops. Only one machine runs FreeBSD. I don’t have the time to be a slave to this system. It appears that there is a considerable amount of manual configuration to get poudriere up and running, which means there is a significant possibility of making mistakes. Depends on the definition of "significant". With poudriere you really have four steps at minimum to get started: 1. create the builder jail (poudriere jail -c ...) 2. create the ports tree (poudriere ports -c ...) -- create new, or point it to use system's /usr/ports 3. create a file that lists ports you want build for that repo 3a. optional step, issue poudriere options ..., to set non-default options . 4. configure /etc/pkg.conf to use the repo poudriere is building After that, the workflow is simple: 1. update ports tree (poudriere ports -u) 2. manage new/changed options (poudriere options ...) 3. run build (poudriere bulk ...) 4. when it's done, pkg upgrade It's covered in the handbook: https://www.freebsd.org/doc/handbook/ports-poudriere.html The above is just a minimum, but poudriere allows you to have many builder jails (eg for 64 or 32 bit, for different ABIs, ...), and many package option sets, so essentially it can create many repositories that differ in supported arch, abi, options used, packages listed, ... -- Vlad K. Acheron Media, Croatia www.acheronmedia.hr +385 95 536 3850 ___ 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: Status of portupgrade and portmaster?
On Sun, 1 Oct 2017 10:51:39 +0100, Matthew Seaman stated: >On 30/09/2017 18:06, Kevin Oberman wrote: >> John did state that he would continue to support synth. I can't say if he >> has continued to make contributions. In any case, only poudriere is >> available for maintaining ports in HEAD and I, for one, feel that it is >> simply unacceptable as it make FreeBSD unusable for those of us with only >> "small" systems where the weight poudriere simply can't be justified. (I >> have no system with other than SATA disk drives and, for my current needs, >> 1 TB of SATA on my development system and .5TB on my production system is >> adequate. Both systems are physically constrained in expansion capability, >> though otherwise easily meet my requirements. > >I don't know what it is about poudriere that elicits this immediate >reaction that it is some sort of behemoth, trampling through disks by >the bushel, shouldering aside other processes to seize the best bits of >RAM and making CPUs cry with incessant demands for more cycles. > >It's simply not so. > >poudriere is really a very thin layer of shell scripts (and a few other >bits) over the general ports make system. All of the really heavy >lifting is done by the compilers and so forth /that you'ld have to >invoke anyhow/. > >In fact, I'd say that if your system is /at all/ capable of building the >ports you want, then it is perfectly capable of running poudriere to >help automate that. > >Yes, the pkg builders used by the project are pretty chunky bits of kit. > That's because they are building some 30,000 ports for about 8 >different combinations of OS and CPU architecture with a cycle time of >less than two days. > >If you're just building a few hundred ports for your own consumption, >then you don't need anything like that amount of resource. I manage >perfectly well with a 6-year old Core2Duo with 8GB RAM and some 500GB >SSDs which cost me under £500 originally + about £200 for replacement >drives later on. Which also runs a bunch of other stuff including my >mail system. This is probably OT for this thread; however, at this point I don’t think it matters much. I have read up on poudriere although I have never used it. I have several questions that I cannot find the answer too. 1. Does it determine out-of-date update packages automatically or does the user have to determine that what is out-of-date and feed them to poudriere manually and in the proper order? 2. From what I have read, the user is required to install each package manually. Is that correct? I have a small system. Three PCs plus a number of laptops. Only one machine runs FreeBSD. I don’t have the time to be a slave to this system. It appears that there is a considerable amount of manual configuration to get poudriere up and running, which means there is a significant possibility of making mistakes. Synth, and before that “portmanager”, and then “portupgrade” do all the heavy lifting leaving me free to work on more important projects. I suppose I could always go back to “portupgrade”; however, I understand that it is not being maintained either. If FreeBSD cannot get the problems with synth corrected when FreeBSD-12 is released, perhaps it will be time to consider a new OS. -- Carmel ___ 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: Status of portupgrade and portmaster?
On 2017-10-01 11:51, Matthew Seaman wrote: poudriere is really a very thin layer of shell scripts (and a few other bits) over the general ports make system. All of the really heavy lifting is done by the compilers and so forth /that you'ld have to invoke anyhow/. There is one tiny problem that users see often and that's the rebuilding of all reverse deps for any port that changed, which can result with frequent rebuilds of tens or hundreds of packages. But -- that's only a good thing. I've never had issues with eg. perl upgrades that portmaster users seem to have often. However, CCACHE is very effective in this situation. As an example CCACHE reduces building of Firefox from ~45 minutes down to 3-4 minutes, in my case. Another problem is poudriere's inability to reuse already installed packages, if they're a dependency for something being built by it. Personally I'd never use that option, as I want clean, isolated rebuilds of everything affected, but I can understand how quick building of one or two packages could use already installed deps, if people wanted that (and break any promise of integrity facilitated with isolated builds). I'll also second the opinion -- if you're building from ports on a machine anyway, poudriere does not in any way require any more resources except to store produced packages and ccache files, which is not much. -- Vlad K. ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: Status of portupgrade and portmaster?
> John did state that he would continue to support synth. I can't say if he > has continued to make contributions. In any case, only poudriere is > available for maintaining ports in HEAD and I, for one, feel that it is > simply unacceptable as it make FreeBSD unusable for those of us with only > "small" systems where the weight poudriere simply can't be justified. (I > have no system with other than SATA disk drives and, for my current needs, > 1 TB of SATA on my development system and .5TB on my production system is > adequate. Both systems are physically constrained in expansion capability, > though otherwise easily meet my requirements. > As a result, I am no longer able to track HEAD and, if the issue is not > resolved in some manner before 11 support ends, will be forced to move from > FreeBSD after an using it for over 2 decades. I certainly hope that this is > not what happens. > Kevin Oberman, Part time kid herder and retired Network Engineer I keep svn-updating 11-STABLE and HEAD, but the ino64 issue with some ports including gcc(5,6)-aux holds me back from activity on HEAD. But conceivably there could be a fix in the future. I also keep cvs-updating NetBSD-HEAD and pkgsrc. On FreeBSD, I am also miffed by the lack of support for my Realtek 8111E/8168 chip on MSI Z77 MPOWER motherboard, especially after that Ethernet worked for a time, and still does for Linux (System Rescue CD) and NetBSD. Synth and pkgng in pkgsrc seem to be falling into desuetude; gcc6-aux is broken for NetBSD (stated in the Makefile). I wonder also about the status of synth and possibly poudriere on DragonFlyBSD, idly curious in that I am more favorably impressed by Linux or Haiku, compared to DragonFlyBSD. Tom ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: Status of portupgrade and portmaster?
On 30/09/2017 18:06, Kevin Oberman wrote: > John did state that he would continue to support synth. I can't say if he > has continued to make contributions. In any case, only poudriere is > available for maintaining ports in HEAD and I, for one, feel that it is > simply unacceptable as it make FreeBSD unusable for those of us with only > "small" systems where the weight poudriere simply can't be justified. (I > have no system with other than SATA disk drives and, for my current needs, > 1 TB of SATA on my development system and .5TB on my production system is > adequate. Both systems are physically constrained in expansion capability, > though otherwise easily meet my requirements. I don't know what it is about poudriere that elicits this immediate reaction that it is some sort of behemoth, trampling through disks by the bushel, shouldering aside other processes to seize the best bits of RAM and making CPUs cry with incessant demands for more cycles. It's simply not so. poudriere is really a very thin layer of shell scripts (and a few other bits) over the general ports make system. All of the really heavy lifting is done by the compilers and so forth /that you'ld have to invoke anyhow/. In fact, I'd say that if your system is /at all/ capable of building the ports you want, then it is perfectly capable of running poudriere to help automate that. Yes, the pkg builders used by the project are pretty chunky bits of kit. That's because they are building some 30,000 ports for about 8 different combinations of OS and CPU architecture with a cycle time of less than two days. If you're just building a few hundred ports for your own consumption, then you don't need anything like that amount of resource. I manage perfectly well with a 6-year old Core2Duo with 8GB RAM and some 500GB SSDs which cost me under £500 originally + about £200 for replacement drives later on. Which also runs a bunch of other stuff including my mail system. Cheers, Matthew signature.asc Description: OpenPGP digital signature
Re: head -r324071 system clang 5 based powerpc64 building ports: lang/gcc7 messed up by a matching name vec_step? [renaming in tree-vect-loop.c avoids the issue]
[If work/gcc-7.2.0/gcc/tree-vect-loop.c avoids the name vec_step then it avoids the conflicting use for altivec support in the powerpc64 context. I used vec_step_renamed as the name in work/gcc-7.2.0/gcc/tree-vect-loop.c instead. Similarly for devel/powerpc64-gcc and likely other variants.] On 2017-Sep-29, at 12:14 PM, Mark Millardwrote: > Summary of later additions: > > devel/powerpc64-gcc has the same problem as gcc7 > in this clang-based powerpc64. > > My note about using gcc 4.2.1 for the kernel > build was wrong. (My 32-bit powerpc builds > are that way, not the powerpc64 ones.) > > On 2017-Sep-29, at 1:51 AM, Mark Millard wrote: > >> [Looks like gcc7 might be causing its own problem >> via a vec_step macro name in its altivec.h .] >> >> On 2017-Sep-29, at 1:14 AM, Mark Millard wrote: >> >>> I attempted a poudriere based build of some >>> ports and the gcc7 build involved failed >>> with the following sorts of notices: > > devel/powerpc64-gcc has the same problem as gcc7 > in this clang-based powerpc64 > >>> /wrkdirs/usr/ports/lang/gcc7/work/gcc-7.2.0/gcc/tree-vect-loop.c:3835:27: >>> error: expected unqualified-id >>> tree new_vec, vec_init, vec_step, t; >>>^ >>> /wrkdirs/usr/ports/lang/gcc7/work/gcc-7.2.0/gcc/tree-vect-loop.c:3835:26: >>> error: expected ';' at end of declaration >>> tree new_vec, vec_init, vec_step, t; >>> ^ >>> ; >>> /wrkdirs/usr/ports/lang/gcc7/work/gcc-7.2.0/gcc/tree-vect-loop.c:3983:3: >>> error: use of undeclared identifier 't' >>> t = unshare_expr (new_name); >>> ^ >>> /wrkdirs/usr/ports/lang/gcc7/work/gcc-7.2.0/gcc/tree-vect-loop.c:3988:49: >>> error: use of undeclared identifier 't' >>> new_vec = build_vector_from_val (stepvectype, t); >>> ^ >>> /wrkdirs/usr/ports/lang/gcc7/work/gcc-7.2.0/gcc/tree-vect-loop.c:3989:12: >>> error: expected expression >>> vec_step = vect_init_vector (iv_phi, new_vec, stepvectype, NULL); >>> ^ >>> /wrkdirs/usr/ports/lang/gcc7/work/gcc-7.2.0/gcc/tree-vect-loop.c:4011:75: >>> error: expected expression >>> new_stmt = gimple_build_assign (vec_dest, PLUS_EXPR, induc_def, vec_step); >>>^ >>> /wrkdirs/usr/ports/lang/gcc7/work/gcc-7.2.0/gcc/tree-vect-loop.c:4048:7: >>> error: use of undeclared identifier 't' >>>t = unshare_expr (new_name); >>>^ >>> /wrkdirs/usr/ports/lang/gcc7/work/gcc-7.2.0/gcc/tree-vect-loop.c:4051:53: >>> error: use of undeclared identifier 't' >>>new_vec = build_vector_from_val (stepvectype, t); >>> ^ >>> /wrkdirs/usr/ports/lang/gcc7/work/gcc-7.2.0/gcc/tree-vect-loop.c:4052:16: >>> error: expected expression >>>vec_step = vect_init_vector (iv_phi, new_vec, stepvectype, NULL); >>> ^ >>> /wrkdirs/usr/ports/lang/gcc7/work/gcc-7.2.0/gcc/tree-vect-loop.c:4060:25: >>> error: expected expression >>>vec_def, vec_step); >>> ^ >>> /wrkdirs/usr/ports/lang/gcc7/work/gcc-7.2.0/gcc/tree-vect-loop.c:6327:9: >>> error: expected unqualified-id >>>tree vec_step = build_vector_from_val (cr_index_vector_type, step); >>> ^ >>> /wrkdirs/usr/ports/lang/gcc7/work/gcc-7.2.0/gcc/tree-vect-loop.c:6333:36: >>> error: expected expression >>>create_iv (series_vect, vec_step, NULL_TREE, loop, _gsi, >>>^ >>> 50 warnings and 12 errors generated. >>> gmake[3]: *** [Makefile:1099: tree-vect-loop.o] Error 1 >>> gmake[3]: *** Waiting for unfinished jobs >>> 42 warnings generated. >>> 51 warnings generated. >>> 50 warnings generated. >>> rm gfortran.pod gcc.pod >>> gmake[3]: Leaving directory '/wrkdirs/usr/ports/lang/gcc7/work/.build/gcc' >>> gmake[2]: *** [Makefile:4225: all-gcc] Error 2 >>> gmake[2]: Leaving directory '/wrkdirs/usr/ports/lang/gcc7/work/.build' >>> gmake[1]: *** [Makefile:893: all] Error 2 >>> gmake[1]: Leaving directory '/wrkdirs/usr/ports/lang/gcc7/work/.build' >>> ===> Compilation failed unexpectedly. >>> Try to set MAKE_JOBS_UNSAFE=yes and rebuild before reporting the failure to >>> the maintainer. >>> *** Error code 1 >>> >>> Stop. >>> make: stopped in /usr/ports/lang/gcc7 >>> =>> Cleaning up wrkdir >>> ===> Cleaning for gcc7-7.2.0_1 >>> build of lang/gcc7 | gcc7-7.2.0_1 ended at Fri Sep 29 00:22:00 PDT 2017 >>> build time: 00:29:27 >>> !!! build failure encountered !!! >> >> Turns out that there is: >> >> # grep -r "\ " ~/poudriere_failure/lang_gcc7/ | more >> . . . >> /root/poudriere_failure/lang_gcc7/work/gcc-7.2.0/gcc/config/rs6000/altivec.h:/* >> Given the vec_step of a type, return the corresponding bool type. */ >> /root/poudriere_failure/lang_gcc7/work/gcc-7.2.0/gcc/config/rs6000/altivec.h:typename >> __altivec_bool_ret ::__ret \ >>