Bug 233749 - net/samba47, net/samba48: Merge ports r486043 to 2018Q4 (Fixes several vulnerabilities)
Would someone work on ports/233749, please? The original security fix was committed to head 15 days ago, but has yet to be merged to quarterly. ___ 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"
Package names and flavors for python (and php?)
The devel/gdb port supports optional python integration (so that you can write python scripts that work with gdb internals to define custom commands, pretty printers, etc.). This means gdb can be linked against different python versions. I decided to add flavors to the gdb port to handle the different python versions (diff is at D18534). However, I chose to do something with the package name suffixes that apparently is at odds with best practice, but seems to be more user friendly. Specifically, I did not add the python flavor as a suffix for the "default" package. Had I done so, the two packages would have been named 'gdb-py27' and 'gdb-py36' and 'pkg install gdb' would no longer work. So, I instead dropped the suffix when the default python version was used so that the results are 'gdb' and 'gdb-py36' (or if you python3 as your default you will get 'gdb' and 'gdb-py27'). I could have just used 'USE_PYTHON=optsuffix' for this, but that currently emits a warning, so I ended up doing it via a 'homegrown' way. I do think it's important that 'pkg install gdb' still works since that is splatted in various places now like the release notes for 12.0 and src/UPDATING, etc. If having the equivalent of 'optsuffix' really is terrible then I'd rather drop the python flavors than break 'pkg install gdb'. On a related note, I installed a new box with 12.0 last week and wanted to install arcanist. Trying to use 'pkg install arcanist' failed because there is no longer a package named 'arcanist'. Trying to use 'pkg install devel/arcanist' was a separate fail because it wanted to install all four flavors (along with 4 sets of php packages). I ended up using 'pkg install arcanist-php72'. However, as a user I was just guessing that 'php72' is the default version of php, and I would probably prefer to not have to think about that. It would be great if 'pkg install arcanist' just installed the default flavor with the default version of PHP. Also related to this, I upgraded a different box from 11.2-ish to 12.0 two weeks ago and rebuilt all its packages using a local poudriere. It also tripped over the flavors package names because the old arcanist package I had installed (php5-arcanist-20161003 from devel/arcanist) wasn't upgraded by 'pkg upgrade -f' to the php72 version. I ended up explicitly deleting it and installing the new version. I'm not sure what the right solution is, but it seems like 'pkg upgrade' of the previous default flavor should upgrade to the new default flavor if the default flavor changes rather than getting stuck on an old version (that in my case my poudriere build didn't rebuild). -- John Baldwin ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: How much memory to compile www/chromium?
## Ian Lepore (i...@freebsd.org): > That's a bit of a harsh tone to take with a user who has questions. Sorry, the day is getting long (and it doesn't sound that harsh in german, it definitively wasn't meant that harsh). > If > Bob was an aspiring ports developer, maybe a response like that would > make some sense. Asking a user who knows how to build ports to be > poking around in and understanding the guts of the ports build > framework is a bit much. Asking them to even know bsd.port.mk *exists* > is a bit much. Every ports developer started by compiling their own ports :) At least, that's how I started. And I had mentioned bsd.ports.mk in my previous mail. > A good response would be to point a user to the manpage that documents > all this stuff. Oh wait... there isn't one. There is ports(7), and again it redirects to bsd.ports.mk. I'm not even sure we could have all the ports make variables in a man page - the knobs of the ports tree depend on your checkout (portsnap, svn, whatever) and not on the base system or some installed package. Regards, Christoph -- Spare Space. ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: How much memory to compile www/chromium?
Kurt Jaeger wrote on 2018/12/12 19:46: Hi! The system in question is an RPI3 running r341643. That will hurt. A regular chromium build takes about 16 CPU-hours on my fairly modern i7 CPU, SSDs and large RAM. Parallel compilation helps a lot, keeping 16 CPU threads busy and my feet warm (building chromium alone takes 1 hour of wall clock time on my system - if that's the only thing I'm running at that time). How can this parallel compilation be configured for chromium in poudriere ? I have a builder host that would be able to handle this 8-} Something like this can help ALLOW_MAKE_JOBS_PACKAGES="pkg py* cmake openjdk* openjdk8 phantomjs gcc6 gcc7 gcc* webkit2-* webkit-* llvm39 llvm60 llvm* rust iridium-browser chromium" But also can hurt if you run in to parallel build of multiple parallel packages (for example iridium with chromium at the same time) Miroslav Lachman ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: How much memory to compile www/chromium?
## bob prohaska (f...@www.zefox.net): > > See bsd.ports.mk: DISABLE_MAKE_JOBS (as in "make -DDISABLE_MAKE_JOBS"). > > > Thank you, I think that's the information needed. Come to think of it, > will the -j option, such as -j2, work in this situation also? Two threads > are much better than one 8-) If you had looked into bsd.port.mk yourself... right below the docs of DISABLE_MAKE_JOBS (line 814) is some documentation for MAKE_JOBS_NUMBER and MAKE_JOBS_NUMBER_LIMIT. -j won't help because there's a lot of arguments sanitizing going on - we can't be having with random arguments showing up down in the port's make invocations - quite often, it's not even "our" make down there. Regards, Christoph -- Spare Space. ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: How much memory to compile www/chromium?
On Wed, Dec 12, 2018 at 07:41:49PM +0100, Christoph Moench-Tegeder wrote: > ## bob prohaska (f...@www.zefox.net): > > > How much memory should be required for > > make -DBATCH > > in www/chromium? > > Quite a lot, multiple GBs. > > > I'm not even sure if your SD card will survive that :) > That's ok, I'm trying to discover what is and isn't practical on a Pi3 > > If this is expected, is there a way to reduce the number of > > threads started by make? > > See bsd.ports.mk: DISABLE_MAKE_JOBS (as in "make -DDISABLE_MAKE_JOBS"). > Thank you, I think that's the information needed. Come to think of it, will the -j option, such as -j2, work in this situation also? Two threads are much better than one 8-) As it happens, the machine isn't stuck. Make still seems to be running, now it's up to [18466/30819], admittedly not making fast progress. I'll let it run for now, just to see what happens. Thanks for your help, bob prohaska ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: Massive PORTREVSION bump for gcc8
No, it doesn't. The PORTREVISION in the individual ports were bumped, so they will get rebuilt with gcc7 if you set the DEFAULT_VERSION, but it will still show as dated and be rebuilt by any postmaster or poudriere general update. On Wed, Dec 12, 2018, 10:40 AM Steve Kargl On Wed, Dec 12, 2018 at 10:29:59AM -0800, Kevin Oberman wrote: > > This morning the PORTREVISION on at least hundreds of ports was bumped > > because gcc8 was declared as the "canonical" version. As a result, I will > > have about 300 ports to rebuild which will take many hours. > > Why? > > > > If a port is built and running properly with gcc7, I see no reason to > force > > the rebuild of all of the ports that are built with gcc7. This will lead > to > > a delay of probably several days in getting updated packages built for > > LATEST repos and will consume hours of CPU time for everyone using > > poudriere or building from ports. This even impacts (slightly) climate > > change with the extra energy used in rebuilding all of those ports across > > the globe. > > > > Perhaps there was a real reason this was required. I have certainly never > > seen it before for any new compiler version to either gcc or llvm. > > Does adding > > DEFAULT_VERSIONS+=GCC=7 > > to /etc/make.conf prevent the need to update 300 ports. > > -- > Steve > ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: How much memory to compile www/chromium?
## Kurt Jaeger (p...@freebsd.org): > How can this parallel compilation be configured for chromium in poudriere ? Look for ALLOW_MAKE_JOBS and/or ALLOW_MAKE_JOBS_PACKAGES in poudriere.conf. That's what does the trick for my poudriere :) Regards, Christoph -- Spare Space. ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: How much memory to compile www/chromium?
Hi! > > The system in question is an RPI3 running r341643. > > That will hurt. A regular chromium build takes about 16 CPU-hours on > my fairly modern i7 CPU, SSDs and large RAM. Parallel compilation helps > a lot, keeping 16 CPU threads busy and my feet warm (building chromium > alone takes 1 hour of wall clock time on my system - if that's the only > thing I'm running at that time). How can this parallel compilation be configured for chromium in poudriere ? I have a builder host that would be able to handle this 8-} -- p...@freebsd.org +49 171 3101372 2 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: How much memory to compile www/chromium?
## bob prohaska (f...@www.zefox.net): > How much memory should be required for > make -DBATCH > in www/chromium? Quite a lot, multiple GBs. > The system in question is an RPI3 running r341643. That will hurt. A regular chromium build takes about 16 CPU-hours on my fairly modern i7 CPU, SSDs and large RAM. Parallel compilation helps a lot, keeping 16 CPU threads busy and my feet warm (building chromium alone takes 1 hour of wall clock time on my system - if that's the only thing I'm running at that time). > Device 1K-blocks UsedAvail Capacity > /dev/mmcsd0s2b4404252 2705928 169832461% I'm not even sure if your SD card will survive that :) > If this is expected, is there a way to reduce the number of threads started > by make? See bsd.ports.mk: DISABLE_MAKE_JOBS (as in "make -DDISABLE_MAKE_JOBS"). Gruss, Christoph -- Spare Space. ___ 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: Massive PORTREVSION bump for gcc8
On Wed, Dec 12, 2018 at 10:29:59AM -0800, Kevin Oberman wrote: > This morning the PORTREVISION on at least hundreds of ports was bumped > because gcc8 was declared as the "canonical" version. As a result, I will > have about 300 ports to rebuild which will take many hours. > Why? > > If a port is built and running properly with gcc7, I see no reason to force > the rebuild of all of the ports that are built with gcc7. This will lead to > a delay of probably several days in getting updated packages built for > LATEST repos and will consume hours of CPU time for everyone using > poudriere or building from ports. This even impacts (slightly) climate > change with the extra energy used in rebuilding all of those ports across > the globe. > > Perhaps there was a real reason this was required. I have certainly never > seen it before for any new compiler version to either gcc or llvm. Does adding DEFAULT_VERSIONS+=GCC=7 to /etc/make.conf prevent the need to update 300 ports. -- Steve ___ 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"
Massive PORTREVSION bump for gcc8
This morning the PORTREVISION on at least hundreds of ports was bumped because gcc8 was declared as the "canonical" version. As a result, I will have about 300 ports to rebuild which will take many hours. Why? If a port is built and running properly with gcc7, I see no reason to force the rebuild of all of the ports that are built with gcc7. This will lead to a delay of probably several days in getting updated packages built for LATEST repos and will consume hours of CPU time for everyone using poudriere or building from ports. This even impacts (slightly) climate change with the extra energy used in rebuilding all of those ports across the globe. Perhaps there was a real reason this was required. I have certainly never seen it before for any new compiler version to either gcc or llvm. -- 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"
How much memory to compile www/chromium?
How much memory should be required for make -DBATCH in www/chromium? Make issues warnings about disk space required, but I don't recall seeing anything about RAM or swap. The system in question is an RPI3 running r341643. Make reached part [18416/30819], at which point it seems to have stalled. The machine is still (sluggishly) responsive, gstat is reporting dT: 10.050s w: 10.000s L(q) ops/sr/s kBps ms/rw/s kBps ms/wd/s kBps ms/d %busy Name 8588149708 25.7439 20567.7 0 00.0 100.0 mmcsd0 8588149708 25.7439 20567.8 0 00.0 100.0 mmcsd0s2 8588149708 25.7439 20567.8 0 00.0 100.0 mmcsd0s2b That it got stuck on reading, rather than writing, is a little surprising. Swapinfo reports Device 1K-blocks UsedAvail Capacity /dev/mmcsd0s2b4404252 2705928 169832461% If this is expected, is there a way to reduce the number of threads started by make? It's using four now, all in state SWREAD showing WCPU of zero to a few percent. Top is reporting mostly idle, with system and interrupt at less than 10%. There are swap_pager_getswapspace(32): failed messages on the console, so it really is out of memory. Thanks for reading! bob prohaska ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: ClamAV Port Version Regression?
Perfect! Thanks for the replies and the clarification, guys!
On 12/11/18 11:21 AM, Stefan Esser wrote:
> Am 11.12.18 um 18:51 schrieb Janky Jay, III:
>> Hi All,
>>
>> After a portsnap to pull ${latest), I'm seeing the following:
>>
>> clamav-0.101.0_2 < needs updating (index has 0.100.2,1)
>>
>> The version that is claiming to be the latest appears to be a version
>> regression. Am I wrong here? I checked the ClamAV site and it appears
>> version 0.101.0 is, in fact, the latest. So, I'm wondering if there was
>> possibly a revision issue that's causing this?
>
> The ,1 at the end of the port to be installed indicates a new port epoch,
> which is used to enforce an "upgrade" to a lower version number.
>
> This is typically done if a port upgrade has been revoked due to problems
> with the new version.
>
> In this particular case the commit log says:
>
> r487064 | antoine | 2018-12-09 18:33:26 +0100 (Sun, 09 Dec 2018) | 6 lines
>
> Downgrade to 0.100.2
> Upstream plans to release version 0.101.1 which fixes header issues in January
> 2019
>
> Regards, STefan
>
Regards,
Janky Jay, III
signature.asc
Description: OpenPGP digital signature
