Re: Re-enabling old ciphers in openssl

[John Kennedy]

On Sun, Dec 27, 2020 at 03:49:10PM -0800, Dan Mahoney (Gushi) wrote:
> Hey there all.
> 
> This is a "don't try this at home" question.  This is not something I'm 
> asking how to do in the general case, but I'd like to know.
> 
> It seems recently (since 1.1.1, OpenSSL has deprecated a number of 
> ciphers, and made them a compile-time default disable.) ...
> Ergo, I am wondering what the best way forward is to get a reasonably 
> patched version of openssl that has old ciphers turned on (since it is 
> still possible at compile-time, the code hasn't been outright removed), 
> that I can build *some* subset of ports against.
> 
> Here are the questions I can't seem to answer:
> 
> 1) There's no make.conf entry to override the openssl ciphers.  This needs 
> to be done at the port level.  (Probably reasonable, I don't think there 
> should be an insecure "flavor")  But in the interest of making things 
> reproducible, is there a "Standard" way to keep this consistent without 
> running "make config" every time, or echo'ing options into 
> /var/db/ports/security-openssl/options?

If you can submit a patch, the person that maintains OpenSSL may accept it.
If not, you can always have a local-to-your-system patch that permits it.
That would give you a OpenSSL that allows it.  Hopefully your window of
support isn't so big that you have to go back and start using obsolete/
dangerous versions of the software, because at some point software support
may get yanked out for those.

Either way, you start out with your own patch.

> 2) I'm unclear as to what to put in make.conf to tell ONE PORT to use the 
> openssl from ports, while I want all the others to use base.  I know this 
> is in some cases askign for trouble, but the nagios plugins are standalone 
> binaries.  Is there some method in make.conf or on the port command line 
> to tell ONE PORT to use a defaults+=ssl-openssl without making it the 
> default for ALL PORTS?

Assuming that by default the DEFAULT_VERSIONS for ssl is base, you'd just
want to use the .if syntax for your port.  Something like:

.if ${.CURDIR:M*/www/firefox}
DEFAULT_VERSIONS += ssl=openssl
.endif

That shouldn't be a syntax error, but I'm not sure it'll do what you want or
be anywhere near complete enough (I just picked it because you mentioned
firefox).  Firefox has a ton of dependencies, and if one of them needs
SSL then you're going to want it running against the same version of SSL
and now you're going to be chasing a lot of nitty-gritty details that will
change over time.

Not sure if poudriere (or whatever you're using to build packages) will
complain about the potential conflicts that setup might imply.

You seemed to want a minimum amount of apps that might be linked against
the less-secure library, so there are going to be some tradeoffs there.

I haven't played with it in a while, but SSL_CTX_set_cipher_list() may
or may not be your friend if the software you're interested in lets you
configure it (so you can exclude bad ciphers where you don't want them,
and include them where you do) but then you still have to hope that
if you're using strength levels (high, medium, low, etc) that the ciphers
you want aren't getting discriminated against in multiple ways.  And
who knows how that function would be called across all the packages+ports.


It sounds like you're trying to do your best with the insecure targets,
so I'm not sure if your insecure jump-hosts would be treated the same
(responsibly), then I might not feel too bad if openssl was recompiled
for everything on the box as long as it wasn't weak for incoming traffic.
Weak for outgoing traffic might be considered acceptable since the only
things it would be talking to are the known-weak remote devices.

If it was a multi-purpose host (like you were using it for other admin
purposes, like looking up documentation out on the web) then I'd lean
way more towards jailing those packages somewhere.

> 3) If I do all that, ports seems to lack a standard way to build static 
> binaries, which is what I'd really like.  Is there an easy way to do this, 
> or is it best to work outside the ports system at that point?

Don't know the answer to that one.
___
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: portsnap

[Thomas Mueller]

> Kudos to Stefan for keeping portmaster relevant and up-to-date.
> But I never understood the appeal of portsnap. What's the advantage over

> svnlite co ...
> cd /usr/ports; make update

> This mechanism is in the base system, so an extra tool demands some
> justification ;-)

> Kind regards,
> Patrick

> punkt.de GmbH
> Patrick M. Hausen

Better yet, I built the full subversion from FreeBSD ports and NetBSD pkgsrc so 
am able to use from either FreeBSD or NetBSD.

But the useful days of svnlite or svn with FreeBSD with ports tree seem to end 
with the migration to git scheduled for the end of next March; already ended 
for FreeBSD doc and current src trees.

I guess svnlite will be dropped from FreeBSD when it will no longer be usable.

Any way portsnap can be updated to deal with a git repository?

I switched from portsnap to subversion following FreeBSD's switch from csup to 
subversion for security reasons in summer 2012 (to the best of my memory).

I figured if I needed subversion to update src and doc trees, may as well also 
use it with ports tree: one-stop shopping.

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: portmaster new development

[Tatsuki Makino]

Guido Falsi wrote on 2020/12/29 08:49:
> This is intentional behaviour, hand there are good reasons for this.
> 
> Anyway poudriere has the CHECK_CHANGED_DEPS option which can be disabled and 
> should restrict this behavior. I have never tested it though, I don't think 
> the risk of getting and incoherent repo is worth it.
> 

Oh, thank you.

However, CHECK_CHANGED_DEPS does not seem to change it's behavior.

For example, if we have the following line
[00:01:22] [Dry Run] Deleting harfbuzz-2.7.2_1.txz: new version: 2.7.4
gtk3 will be involved and removed.
[00:01:26] [Dry Run] Deleting gtk3-3.24.24.txz: missing dependency: 
harfbuzz-2.7.2_1
When gtk3 is removed, this will also be removed.
[00:01:26] [Dry Run] Deleting gtkspell3-3.0.10.txz: missing dependency: 
gtk3-3.24.24
[00:01:26] [Dry Run] Deleting webkit2-gtk3-2.30.2.txz: missing dependency: 
gtk3-3.24.24
webkit2-gtk3 also requires harfbuzz, so it must be built. orz
But gtkspell3 doesn't seem to have anything to do with harfbuzz, so if we 
rebuild gtk3 by poudriere bulk -j jail -J 2 x11-toolkits/gtk30, we won't have 
to rebuild it.

It's such a repetition.

___
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: portmaster new development

[Guido Falsi via freebsd-ports]

On 29/12/20 00:07, Tatsuki Makino wrote:

Where should I hang out to reply? :)

poudriere has weaknesses in updating packages such as libxml and glib.
When run all at once, all packages that depend on the package being updated and 
all packages that depend on the package being removed will be removed.
The text is not clear :), but qt5-webkit and webkit2-gtk3 are removed, and the 
time-consuming build begins.

This is intentional behaviour, hand there are good reasons for this.

Anyway poudriere has the CHECK_CHANGED_DEPS option which can be disabled 
and should restrict this behavior. I have never tested it though, I 
don't think the risk of getting and incoherent repo is worth it.


--
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: portmaster new development

[Tatsuki Makino]

To add to the extremes, it is enough to be able to topologically sort in some 
way.

#!/bin/tcsh
foreach origin (`pkg version -vPL= | cut -f 1 -w | xargs pkg 
some-topological-sort-command-can-someone-make-this -o`)
make -C /usr/ports/${origin:q} clean
make -C /usr/ports/${origin:q} build deinstall install clean
end

That should be enough. :)

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

Re: portmaster new development

[Tatsuki Makino]

Where should I hang out to reply? :)

poudriere has weaknesses in updating packages such as libxml and glib.
When run all at once, all packages that depend on the package being updated and 
all packages that depend on the package being removed will be removed.
The text is not clear :), but qt5-webkit and webkit2-gtk3 are removed, and the 
time-consuming build begins.

To prevent packages that do not need to be removed from being removed, I 
manually do the following.

poudriere ports -u -v
poudriere bulk -j jail -J 2 -S -f pkglist.txt
||:
poudriere bulk -j jail -J 2 -n -f pkglist.txt
# visually look for packages that have broken dependencies with the updated 
package here.
poudriere bulk -j jail -J 2 originfor/dependencymissingpackage1 
originfor/dependencymissingpackage2 ...
:||
___
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: portmaster new development

[Stefan Esser]

Am 28.12.20 um 22:07 schrieb Michael Grimm:>> On 28. Dec 2020, at 21:41, 
Stefan Esser  wrote:


Poudriere works best on sufficiently powerful build servers and it
often requires rebuilding dependencies over hours when I just want to
test a new port before committing it.


Excuse me, but that is not true in this generality. I do run poudriere on ZFS 
in a cloud instance with 7G of memory and a CPU of 2.1 MHz. Never had to wait 
for more then one hour for recompiling *all* of my 240+ ports for STABLE-12. 
YMMV, yes, but stating that in that totality is nonsense, at least IMHO.


My build host is much bigger and I often have to build
dependencies over night before I can test-build a new
port with poudriere.

Maybe your ports do not have as many big dependencies,
but building LLVM and GCC as a dependency for 3 release
versions takes its time and whenever these ports have
been updated I cannot run "poudriere test" for my new
port before the compilers are updated.

If there are no complex dependencies, you are right,
but MESA, KDE (or even Qt5) and all ports that need
a specific compiler version that is receiving updates
cause excessive delays before a port can be test built
with poudriere.

So yes, YMMV, but it depends on the complexity of the
dependencies. And I test with different options in
the different jails (e.g. with/without DOCS, one with
non-standard PREFIX, etc.) for a better test coverage.
Therefore I cannot fetch pre-compiled compilers and
other dependencies to speed up my port tests.

And this might be typical for poudriere users. If you
do not want to build with non-default options you are
better served by using pre-compiled packages.

Regards, STefan



OpenPGP_signature
Description: OpenPGP digital signature

Re: portmaster new development

[Michael Grimm]

Hi

> On 28. Dec 2020, at 21:41, Stefan Esser  wrote:
> 
> Poudriere works best on sufficiently powerful build servers and it
> often requires rebuilding dependencies over hours when I just want to
> test a new port before committing it.

Excuse me, but that is not true in this generality. I do run poudriere on ZFS 
in a cloud instance with 7G of memory and a CPU of 2.1 MHz. Never had to wait 
for more then one hour for recompiling *all* of my 240+ ports for STABLE-12. 
YMMV, yes, but stating that in that totality is nonsense, at least IMHO.

Regards,
Michael

___
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: portmaster new development

[Stefan Esser]

Am 28.12.20 um 15:04 schrieb abi via freebsd-ports:

On 28.12.2020 16:16, Stefan Esser wrote:
Am 28.12.20 um 11:11 schrieb abi via freebsd-ports:> I build my ports 
in poudriere in VM without zfs or ssd on pre-Sandy
Bridge CPU. I don't have enough memory or disk space, so I don't use 
tmpfs or ccache either. I migrated from portmaster when it was 
abandoned several years ago and don't think I'll come back, 
especially if new portmaster will be written on bash. The idea behind 
portmaster was zero dependencies, so it doesn't brake after major 
upgrades.


You are free to use poudriere and it definitely is the official tool
for FreeBSD package building (and I have to use it myself and it has
cost me a lot of time rebuilding broken poudriere jails and keeping
them in state that I can use them to test new ports on a number of
different releases as well as i386 plus amd64).

And while you are free to never again use portmaster, telling people
that it has been abandoned is just a _lie_ and I'd want to ask you to
stop telling it. It has been continuously maintained for decades.

I remember portmaster marked as deprecated in 2016. I've switched to 
poudriere because of that. So, it _was_ abandoned when I migrated. It is 
good that it is not, the more options - the better. But some people here 
telling that poudriere requires ZFS and powerful dedicated hardware, I 
just pointed that they are wrong.


The portmaster port had been marked deprecated by the author of synth
and this commit has been reverted by him on request of portmgr on the
next day.

The portmaster port has never been abandoned - it does not suffice that
some unrelated committer considers his port management tool superior
and decides to deprecate a "competing" one.

Poudriere works best on sufficiently powerful build servers and it
often requires rebuilding dependencies over hours when I just want to
test a new port before committing it.

My goal is to have portmaster build ports in a clean jail as synth
does (restricted to i386 and amd64 due to the dependency on Ada) and
poudriere do, but without giving up the ease of use of portmaster for
other use cases.

Regards, STefan



OpenPGP_signature
Description: OpenPGP digital signature

committer for Cassandra4 aarch64 fix?

[Ronald Klop]

Hi,


Looking for a committer for 
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=252068 ?
Small fix for compilation on aarch64. Would be nice to have it in the 2021Q1 
quarterly branch.


Regards,
Ronald
___
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: Fresh Ports: citrix_ica Citrix(R) Presentation Server(TM) client

[Carmel NY]

On Wed, 11 Nov 2020 17:51:05 +0100, Emanuel Haupt stated:
>Hi Michael
>
>Michael Hooten  wrote:
>> https://www.freshports.org/net/citrix_ica/
>> 
>> Has anyone gotten Citrix completely working on FreeBSD 12.2? I can
>> connect without a problem. However, I have no sound. Where can I look
>> for documentation on integrating audio (GStreamer and Alsa I assume)?
>> 
>> Thanks,
>> Michael  
>
>I haven't used it in a long time but as I recall sound support was
>always a bit wonky, at least for me.
>
>A word of caution: the current port is hopelessly outdated. If someone
>is interested in porting the latest version it is available from:
>
>https://www.citrix.com/downloads/workspace-app/linux/workspace-app-for-linux-latest.html
>
>Best regards,
>Emanuel

I was going to try using it to access to VC3. Our municipality's
network is operated and maintained from there. I usually access the
network either from work or from home on my Win 10 machine. It has
citrix installed. I contacted the VC3 support team and they told me
that they could not insure that the version of citrix available on
FreeBSD would work and that they would not be offering me any technical
support with a long ago depreciated version.

I realize that 'citrix' apparently does not have a maintainer, and
since I cannot maintain it, it would be nice if someone with the
required technical knowledge could update it to the latest version.

-- 
Carmel


pgp9sNj0Pl81p.pgp
Description: OpenPGP digital signature

Re: portmaster new development

[Edward Sanford Sutton, III]

On 12/27/20 4:00 AM, LuMiWa via freebsd-ports wrote:
> The subject is 'portmaster new development' but again start pushing
> poudriere to FreeBSD users. I do not use zfs file system and I do not
> use poudriere and I do not want to use on my computer for building some
> ports and then spending hours and hours with poudriere with not enough
> machine. For me is portmaster perfect as is now.

  More tools and improvements to tools can be a good thing. There are
some things that portmaster did better and others that portupgrade did
better. Can't remember which for each task but I think I used portmaster
for configure dialogs and fetching as it would perform those steps
before builds started. I found myself using portmaster to create a list
of ports I had installed (portmaster --list-origins >
~/installed-port-list) to then feed into poudriere as a list to build
though pkg prime-origins completes in a small fraction of a second
instead of more than 5 seconds.
  I've dealt with a number of ports that fail to build because of a
conflict (usually not noted). May have been avahi or a different port
sounding similar in my head but one would regularly fail to upgrade for
me if it was currently installed because the build found and used tools
from the old version during the build of the new even after it spent
time building the new tools in the work directory. People probably think
those issues are rare in the ports tree but back around 2009-2011 I
upgraded a x86 to x64 by upgrading in place. Running portupgrade lead to
many failures due to ports using locally installed 32bit tools and
libraries even though in theory everything should have been
rebuilt/reinstalled in an orderly fashion where it would be replaced
before it gets used. I've thought about repeating that to document
findings but unless other developers want to look into the issues then
there is no point as I have not been able to fix those type of build
issues when I've tried. Deleting any installed package before its own
port rebuild would work around many of those issues I saw but you really
need to uninstall all nondependent ports to guarantee an individual port
build succeeds. If uninstalling a port does not remove everything (bad
pkg-plist) it created then there is still a chance of a contaminated
build. Some builds will break if you have nondependencies installed and
other times it may just modify what you get from building it as the
program detects its surroundings and makes findings the port maintainer
didn't account for when the build autodetects surroundings with things
like autotools which didn't have the maintainer override or add a
dependency for every possible optional manual detection. Remove port(s),
rebuild, and reinstall once built is higher downtime than a pkg upgrade
of already built ports. That is made worse when portmaster aborts on an
unrelated dependency tree branch causing a complete build halt
mid-upgrade. Portupgrade's "continue building all others on fail" leaves
less programs broken without interaction but still higher than if it
rolled back the entire dependency tree of a failed port.
  Building in a jail gets around the issue of needing a separate build
machine, removing installed packages, and having program downtime while
waiting for the chain of it+dependencies to all be rebuilt (incomplete
build of program+dependencies leads to broken programs if I cannot
resolve). That time would be extended when I would have days worth of
building to do and portmaster would stop building within hours or
minutes of starting and I won't see results for hours later when I get
home from work or wake up. I completed very little with portmaster
before going back to portupgrade back in the day because abort on
failure rarely errored out on the first or last of a dependency chain
and stopping in the middle without rolling back the entire chain would
mean the update attempt generally broke things other than the one failed
port. Installing from packages after all building is done offers the
shortest downtime of programs on the system.
  A poudriere build stays in its own area and keeps it clean as it goes
so those problems go away. Other solutions including a
portmaster/portupgrade building in a jail should be able to do so too.
Poudriere can be configured to not use excessive resources by
controlling number of different ports to build at once, how many threads
to use per port build, and how much to use memory disks vs real disks
for workdirs, ccache, etc. Poudriere will take longer due to always
starting with a clean environment, being more aggressive about deciding
when a port needs a rebuild, and time spent building/updating the base
system to be used inside the jail. Other jailed build systems will
likely perform faster due to less cleanup per package. Poudriere
defaults performing a full build for my machine while I use my machine
is a bad experience but had controls to adjust settings to all be more
sane. Poudriere, with more tame settings

Re: portmaster new development

[Chris]

On 2020-12-28 05:16, Stefan Esser wrote:
Am 28.12.20 um 11:11 schrieb abi via freebsd-ports:> I build my ports in 
poudriere

in VM without zfs or ssd on pre-Sandy
Bridge CPU. I don't have enough memory or disk space, so I don't use tmpfs 
or ccache either. I migrated from portmaster when it was abandoned several 
years ago and don't think I'll come back, especially if new portmaster will 
be written on bash. The idea behind portmaster was zero dependencies, so it 
doesn't brake after major upgrades.


You are free to use poudriere and it definitely is the official tool
for FreeBSD package building (and I have to use it myself and it has
cost me a lot of time rebuilding broken poudriere jails and keeping
them in state that I can use them to test new ports on a number of
different releases as well as i386 plus amd64).

And while you are free to never again use portmaster, telling people
that it has been abandoned is just a _lie_ and I'd want to ask you to
stop telling it. It has been continuously maintained for decades.

The next version will not be using bash but LUA, which is highly
portable and does not have problematic dependencies. I'm well aware
that a pure shell script has its advantages, but bringing down the
time to scan for updates on my system from 300 to less than 10 seconds
(for > 2000 installed packages) combined with the ability to build
ports in a clean jail might make it an attractive choice for current
users of the /bin/sh based version.


The lovely thing about options, is that *everyone* gets to have one.
The more the merrier! :-)

@Stefan
Really excited to hear about your LUA version of portmaster.
Thanks! :-)

--Chris



Regards, STefan

___
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: portsnap

[Patrick M. Hausen]

Hi all,

> Am 28.12.2020 um 16:38 schrieb Kevin Oberman :
> 
> portsnap(8) predates svnlite by quite a bit, but you have just described
> why it is not really worth the overhead of maintaining it. As bugzilla
> describes many ticket closures, Overcome by events".

Somehow I must have missed/skipped it.

I used cvsup and later csup all the time it was available. While the migration
from CVS to Subversion took place in 2008 I think I remember the cvsup mirrors
to have been up for quite some time afterwards. Feeding back from Subversion
into a read-only CVS I figure?

/usr/bin/svnlite was introduced in 2013 which leaves a 5 year period of 
interest.

I could not find when cvsup/csup was finally terminated. Does anyone remember?

Kind regards,
Patrick
--
punkt.de GmbH
Patrick M. Hausen
.infrastructure

Kaiserallee 13a
76133 Karlsruhe

Tel. +49 721 9109500

https://infrastructure.punkt.de
i...@punkt.de

AG Mannheim 108285
Geschäftsführer: Jürgen Egeling, Daniel Lienert, Fabian Stein



signature.asc
Description: Message signed with OpenPGP

Re: portmaster new development

[Kevin Oberman]

On Mon, Dec 28, 2020 at 6:04 AM abi via freebsd-ports <
freebsd-ports@freebsd.org> wrote:

> On 28.12.2020 16:16, Stefan Esser wrote:
> > Am 28.12.20 um 11:11 schrieb abi via freebsd-ports:> I build my ports
> > in poudriere in VM without zfs or ssd on pre-Sandy
> >> Bridge CPU. I don't have enough memory or disk space, so I don't use
> >> tmpfs or ccache either. I migrated from portmaster when it was
> >> abandoned several years ago and don't think I'll come back,
> >> especially if new portmaster will be written on bash. The idea behind
> >> portmaster was zero dependencies, so it doesn't brake after major
> >> upgrades.
> >
> > You are free to use poudriere and it definitely is the official tool
> > for FreeBSD package building (and I have to use it myself and it has
> > cost me a lot of time rebuilding broken poudriere jails and keeping
> > them in state that I can use them to test new ports on a number of
> > different releases as well as i386 plus amd64).
> >
> > And while you are free to never again use portmaster, telling people
> > that it has been abandoned is just a _lie_ and I'd want to ask you to
> > stop telling it. It has been continuously maintained for decades.
> >
> I remember portmaster marked as deprecated in 2016. I've switched to
> poudriere because of that. So, it _was_ abandoned when I migrated. It is
> good that it is not, the more options - the better. But some people here
> telling that poudriere requires ZFS and powerful dedicated hardware, I
> just pointed that they are wrong.
>
I'm afraid your recollection is in error. While there was a lot of talk of
deprecating it after Doug stopped supporting it. there was only discussion.
Check the history in svn and it simply never happened. Getting rid of it
was heavily pushed by a few people of the "poudreire is the solution to all
port updating issues and all other should be removed" stripe, but it is and
was never the solution for many even though it is a great tool and should
be considered the "standard" method of ports management.

If Stefan had not stepped up, deprecation would have had to happen as
bitrot would have required 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: portsnap

[Kevin Oberman]

On Mon, Dec 28, 2020 at 4:37 AM Patrick M. Hausen  wrote:

> Hi all,
>
> > Am 26.12.2020 um 20:04 schrieb LuMiWa via freebsd-ports <
> freebsd-ports@freebsd.org>:
> > ...and I will continue to use portmaster. But I don't understand why
> > we should no keep portsnap.
>
> Kudos to Stefan for keeping portmaster relevant and up-to-date.
> But I never understood the appeal of portsnap. What's the advantage over
>
> svnlite co ...
> cd /usr/ports; make update
>
> This mechanism is in the base system, so an extra tool demands some
> justification ;-)
>
> Kind regards,
> Patrick
> --
> punkt.de GmbH
> Patrick M. Hausen
> .infrastructure
>
> Kaiserallee 13a
> 76133 Karlsruhe
>
> Tel. +49 721 9109500
>
> https://infrastructure.punkt.de
> i...@punkt.de
>
> AG Mannheim 108285
> Geschäftsführer: Jürgen Egeling, Daniel Lienert, Fabian Stein
>
> portsnap(8) predates svnlite by quite a bit, but you have just described
why it is not really worth the overhead of maintaining it. As bugzilla
describes many ticket closures, Overcome by events".
--
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: portmaster new development

[abi via freebsd-ports]

On 28.12.2020 16:16, Stefan Esser wrote:
Am 28.12.20 um 11:11 schrieb abi via freebsd-ports:> I build my ports 
in poudriere in VM without zfs or ssd on pre-Sandy
Bridge CPU. I don't have enough memory or disk space, so I don't use 
tmpfs or ccache either. I migrated from portmaster when it was 
abandoned several years ago and don't think I'll come back, 
especially if new portmaster will be written on bash. The idea behind 
portmaster was zero dependencies, so it doesn't brake after major 
upgrades.


You are free to use poudriere and it definitely is the official tool
for FreeBSD package building (and I have to use it myself and it has
cost me a lot of time rebuilding broken poudriere jails and keeping
them in state that I can use them to test new ports on a number of
different releases as well as i386 plus amd64).

And while you are free to never again use portmaster, telling people
that it has been abandoned is just a _lie_ and I'd want to ask you to
stop telling it. It has been continuously maintained for decades.

I remember portmaster marked as deprecated in 2016. I've switched to 
poudriere because of that. So, it _was_ abandoned when I migrated. It is 
good that it is not, the more options - the better. But some people here 
telling that poudriere requires ZFS and powerful dedicated hardware, I 
just pointed that they are wrong.


___
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 like git? gitup is here for you

[Nuno Teixeira]

I'm proud to announce that net/gitup is almost landing. 252220


Thanks all,
Thanks Kimura. It's so good to learn! Nuno Teixeira
___
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: portmaster new development

[Stefan Esser]

Am 28.12.20 um 11:11 schrieb abi via freebsd-ports:> I build my ports in 
poudriere in VM without zfs or ssd on pre-Sandy
Bridge CPU. I don't have enough memory or disk space, so I don't use 
tmpfs or ccache either. I migrated from portmaster when it was abandoned 
several years ago and don't think I'll come back, especially if new 
portmaster will be written on bash. The idea behind portmaster was zero 
dependencies, so it doesn't brake after major upgrades.


You are free to use poudriere and it definitely is the official tool
for FreeBSD package building (and I have to use it myself and it has
cost me a lot of time rebuilding broken poudriere jails and keeping
them in state that I can use them to test new ports on a number of
different releases as well as i386 plus amd64).

And while you are free to never again use portmaster, telling people
that it has been abandoned is just a _lie_ and I'd want to ask you to
stop telling it. It has been continuously maintained for decades.

The next version will not be using bash but LUA, which is highly
portable and does not have problematic dependencies. I'm well aware
that a pure shell script has its advantages, but bringing down the
time to scan for updates on my system from 300 to less than 10 seconds
(for > 2000 installed packages) combined with the ability to build
ports in a clean jail might make it an attractive choice for current
users of the /bin/sh based version.

Regards, STefan



OpenPGP_signature
Description: OpenPGP digital signature

Re: portsnap

[Patrick M. Hausen]

Hi all,

> Am 26.12.2020 um 20:04 schrieb LuMiWa via freebsd-ports 
> :
> ...and I will continue to use portmaster. But I don't understand why
> we should no keep portsnap.

Kudos to Stefan for keeping portmaster relevant and up-to-date.
But I never understood the appeal of portsnap. What's the advantage over

svnlite co ...
cd /usr/ports; make update

This mechanism is in the base system, so an extra tool demands some
justification ;-)

Kind regards,
Patrick
--
punkt.de GmbH
Patrick M. Hausen
.infrastructure

Kaiserallee 13a
76133 Karlsruhe

Tel. +49 721 9109500

https://infrastructure.punkt.de
i...@punkt.de

AG Mannheim 108285
Geschäftsführer: Jürgen Egeling, Daniel Lienert, Fabian Stein



signature.asc
Description: Message signed with OpenPGP

Re: portmaster new development

[abi via freebsd-ports]

On 28.12.2020 12:44, David Gessel wrote:



 Original Message 
Subject: Re: portmaster new development
From: LuMiWa via freebsd-ports 
To: freebsd-ports@freebsd.org
Date: 2020-12-27 02:00+0300


On Sun, 27 Dec 2020 11:16:23 +0100
Michael Grimm  wrote:


Matthias Apitz  wrote:

El día domingo, diciembre 27, 2020 a las 09:22:42a. m. +0100, Kurt
Jaeger escribió:



That works as well. I have a checkout of the ports tree, use
make config to define non-default port options. This stores the
selected OPTIONs in /var/db/ports/, and poudriere uses those
options just fine.



Re/ the options, I copy them into the jail with something like this
procedure:

# cd /usr/ports/mail/mutt
# make config

# mkdir -p /usr/local/etc/poudriere.d/freebsd-head-options/mail_mutt
# cp /var/db/ports/mail_mutt/options
/usr/local/etc/poudriere.d/freebsd-head-options/mail_mutt

'freebsd-head' is the name of the poudriere jail (I have some of
them) and the ports options stay there, as well the make.conf
options in /usr/local/etc/poudriere.d/freebsd-head-make.conf



I am following stable, and my jail's name has been set to stable.

All of poudriere's settings/configs are kept in:

/usr/local/etc/poudriere.d



The subject is 'portmaster new development' but again start pushing
poudriere to FreeBSD users. I do not use zfs file system and I do not
use poudriere and I do not want to use on my computer for building some
ports and then spending hours and hours with poudriere with not enough
machine. For me is portmaster perfect as is now.






I have to agree, portmaster works for certain user cases where 
poudriere doesn't, like mine.  The answer seems to be just (buy) a 
high end machine and dedicate it to build with lots of RAM, high end 
CPU's, and a big ZFS array with the right combination of SSDs etc and 
it is fast and stable!



I build my ports in poudriere in VM without zfs or ssd on pre-Sandy 
Bridge CPU. I don't have enough memory or disk space, so I don't use 
tmpfs or ccache either. I migrated from portmaster when it was abandoned 
several years ago and don't think I'll come back, especially if new 
portmaster will be written on bash. The idea behind portmaster was zero 
dependencies, so it doesn't brake after major upgrades.


___
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: portmaster new development

[David Gessel]

 Original Message 
Subject: Re: portmaster new development
From: LuMiWa via freebsd-ports 
To: freebsd-ports@freebsd.org
Date: 2020-12-27 02:00+0300


On Sun, 27 Dec 2020 11:16:23 +0100
Michael Grimm  wrote:


Matthias Apitz  wrote:

El día domingo, diciembre 27, 2020 a las 09:22:42a. m. +0100, Kurt
Jaeger escribió:



That works as well. I have a checkout of the ports tree, use
make config to define non-default port options. This stores the
selected OPTIONs in /var/db/ports/, and poudriere uses those
options just fine.



Re/ the options, I copy them into the jail with something like this
procedure:

# cd /usr/ports/mail/mutt
# make config

# mkdir -p /usr/local/etc/poudriere.d/freebsd-head-options/mail_mutt
# cp /var/db/ports/mail_mutt/options
/usr/local/etc/poudriere.d/freebsd-head-options/mail_mutt

'freebsd-head' is the name of the poudriere jail (I have some of
them) and the ports options stay there, as well the make.conf
options in /usr/local/etc/poudriere.d/freebsd-head-make.conf



I am following stable, and my jail's name has been set to stable.

All of poudriere's settings/configs are kept in:

/usr/local/etc/poudriere.d



The subject is 'portmaster new development' but again start pushing
poudriere to FreeBSD users. I do not use zfs file system and I do not
use poudriere and I do not want to use on my computer for building some
ports and then spending hours and hours with poudriere with not enough
machine. For me is portmaster perfect as is now.






I have to agree, portmaster works for certain user cases where poudriere 
doesn't, like mine.  The answer seems to be just (buy) a high end machine and 
dedicate it to build with lots of RAM, high end CPU's, and a big ZFS array with 
the right combination of SSDs etc and it is fast and stable!

While I'm sure that's true, that's not consistent with everyone's environment.  I'm 
reminded of many client-server applications that are developed by people on gigabit fiber 
and seem to consider the "edge" case of the rest of the world on spotty 
internet not worthy of consideration, complaints merely whiny carping by people who 
should just lift their internet up by the bootstraps.

I've run a server with a set of jails providing services for about 20 years.  
Maintaining them with portsnap and portmaster works and is efficient and 
functional and an efficient and practical use of the compute resources I have.

Adding new and potentially better tools has been a pleasure of the community, but 
abandoning users always going to create friction and dismissing another's use case as 
"doing it wrong" is a great way to create animosity and dysfunction.

The first wave of poudriereism was very annoying and offputting, but in the last year 
I've been delighted by the excellent and very responsive work of port maintainers to 
resolve issues quickly and cleanly and those of us still doing it the "old way" 
can still do so successfully.  It'll be annoying and a little disruptive to lose the 
excellent tool that portsnap has been all these years, truly one of the brilliant, 
focused, and tremendously useful tools in the FreeBSD kit, but we'll figure out how to 
keep things working.
___
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"