, make them fully backwards compatible and update the
distribution.
Roger Marquis
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
, then don't remove the
build dependency afterwards. Most of these apps don't even appear to
need Perl but for an operation or two that could have been done in a BASE
language like awk or sh.
Anyone know of a workaround, I mean other than manual pkg_delete?
Roger Marquis
, submitted
earlier in the month, worked for us:
http://www.freebsd.org/cgi/query-pr.cgi?pr=148611
Roger Marquis
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to freebsd-ports
to restrict derivative works from adopting a copyleft license?
This is not a rhetorical question as I know several places where code has
not been open sourced because the developers and/or owners did not want
it to be used by a competing but lower quality and/or non cross-platform
GPL project.
Roger
if [ $? = 0 ]; then
echo -n $msg. Continue [Y/^C]:
read x y z
else
echo $msg. Continuing in 10s, ^C to abort ...
sleep 10
fi
Roger Marquis
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
Peter Jeremy wrote:
You might like to check out
http://www.mavetju.org/unix/freebsd-mirrors/cvsup-stats-global.php
As well as:
http://www.roble.com/docs/cvsup-ports-rep
Roger Marquis
___
freebsd-ports@freebsd.org mailing list
http
-dynload', '/usr/local/lib/python2.6/site-packages']
admin(26870): sys.platform= freebsd8
Roger Marquis
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman
Palle Girgensohn gir...@pingpong.net wrote:
So, apart from the obvious I want to upgrade the client separately
(before) the server, there are no arguments for not doing it the way we
do it now. But maybe that argument is enough to motivate a change?
KIS is one reason we do not install clients
is that much of an
issue. For most of us end-users it doesn't matter as we use portsnap
(and update speed really isn't an issue).
IMO,
Roger Marquis
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
close to the hassle of this year's make and
pkgng changes. Partly this is due to a shortage of good FreeBSD devs
able to contribute backwards-compatible components but there's more to it
than that.
IMO,
Roger Marquis
___
freebsd-ports@freebsd.org mailing
Of all the pkgng bugs we've finally hit one that doesn't have an obvious
workaround.
# pkg anything
pkg: sqlite error while executing DROP INDEX deps_unique;CREATE UNIQUE INDEX
deps_unique ON deps(name, version, package_id); in file pkgdb.c:2262: UNIQUE
constraint failed: deps.name,
Matthew Seaman wrote:
Something like:
SELECT name, version, package_id FROM deps GROUP BY name, version,
package_id HAVING count(*) 1 ;
That returns:
pkgconf|0.8.7_2|7714
Though the server's daily 'pkg info' gave no indication this was multiply
installed. Question now is how to
Matthew Seaman wrote:
SELECT * FROM DEPS WHERE name='pkgconf' AND version='0.8.7_2'
AND package_id='7714';
Given two rows that are exactly the same
No two rows but it apears one of pkg's dependencies may have changed
names at some point:
# SELECT * FROM DEPS WHERE name='pkgconf' AND
Baptiste Daroussin wrote:
The way to fix is:
sqlite3 /var/db/pkg/local.sqlite delete from deps where
origin='devel/pkg-config';
Then everything should be back to normal
That worked! Merci Baptiste and Matthew,
Roger
___
freebsd-ports@freebsd.org
This sounds like you, like many other people have done in the past, have
built an in-house solution based on the tools available at the time,
which includes 'make package'
I wouldn't call it an in-house solution since the package target is a
feature of the ports infrastructure. We simply 'make
these binaries in the first place?
That leaves the issue of cross-platform compatibility, which is still
broken without REPLACE_BASE. What about those of us who support
environments that aren't BSD monocultures?
Roger Marquis
Well, like I said, REPLACE_BASE was an abomination that should never have
On Tue, Jan 13, 2015 at 08:33:13AM -0800, Roger Marquis wrote:
... Poudriere is a self-contained build system that can be used to
bulk build any number of packages that can be used on any number of
other systems. This is very useful if you need different features or
options than the packages
Matthew Seaman wrote:
Yes, poudriere does a lot of stuff, but if you didn't use a central
builder, you'ld end up replicating all of that stuff onto every machine
you wanted to manage.
What stuff would you end up replicating? I ask because our make
package host don't replicate anything other
?
Roger Marquis
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Mathieu Arnold wrote:
| That leaves the issue of cross-platform compatibility, which is still
| broken without REPLACE_BASE. What about those of us who support
| environments that aren't BSD monocultures?
By using the named_conf variable in /etc/rc.conf ?
That enables configuration
a cross-platform compatibility options
and not being short-sighted regarding the scope of $PREFIX.
Sometimes you really have to wonder whether these feature deprecations
are due less to resource shortages than to special interests outside of
FreeBSD's user-base.
IMO,
Roger Marquis
Mark Linimon wrote:
It was believed to be a bad design pattern to let ports modify anything
in base.
Believed by who? Surely not those of us advocating FreeBSD in mixed
environments where the Linux and Windows admins are pushing for something
closer to a monoculture.
Apparently 10.0 seemed
The dialog option you talk about says:
[ ] REPLACE_BASEEOL, no longer supported
I'm quite sure the end-user you're talking about can get a clue from it,
and if he either already had selected it before, or he just selected it, he
will get:
=== bind99-9.9.6P1_3 REPLACE_BASE is no longer
Mathieu Arnold wrote:
I'm only going to answer that part, the rest of the thread being, I feel,
mostly FUD.
...
The BIND ports were in such a miserable way, with kludges everywhere, when
I took over that it took me some time to get them right.
I wish people wouldn't make statements like this.
Mathieu Arnold wrote:
Would you rather the port installing BIND in /usr/local without telling you
anything, silently breaking your installation completely ?
Certainly not but it's unprofessional to present the end-user with a dialog
option that can be selected only to subsequently inform them
Found why mailman is trying (and failing) to reinstall postfix and it
appears to be a bug in other ports as well.
# cd /usr/ports/mail grep '_DEPENDS+=.*postfix' */Makefile
dk-milter/Makefile:RUN_DEPENDS+=
${LOCALBASE}/libexec/postfix/smtpd:${PORTSDIR}/mail/postfix-current
Found why mailman is trying (and failing) to reinstall postfix and it
appears to be a bug in other ports as well.
Shouldn't these ports be querying the pkg db rather than checking for a
particular file, particularly when the file is incorrectly specified?
Have you read the Porters' Handbook?
Short of editing mail/mailman/Makefile and building the port is there a
way force 'pkg install' to just install a package and ignore its
dependencies? The man page doesn't indicate any such logic (a difference
from other package managers).
Roger
Found why mailman is trying (and failing) to
I would like to contribute on that level as well.
Still interested in the team's policies and procedures, if those are
online somewhere.
Roger Marquis
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
to the security team).
Is there a URL outlining the policies and procedures of vuln.xml
maintenance?
Roger Marquis
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to freebsd
is supported).
Can't recall seeing these issues before portsng/pkgng so am putting this
out for recommendations.
Roger Marquis
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail
On Fri, May 29, 2015 at 5:15 PM, Robert Simmons rsimmo...@gmail.com wrote:
Crickets.
May I ask again:
How do we find out who the members of the Ports Secteam are?
How do we join the team?
Anyone?
On Thu, May 28, 2015 at 12:47 PM, Bryan Drewery bdrew...@freebsd.org
wrote:
I think
The ports-secteam knows about this but posting here in case someone wants to
update ahead of the port, from this morning's Hackernews:
https://www.openssl.org/news/secadv_20150611.txt
Roger
___
freebsd-ports@freebsd.org mailing list
FreeBSD servers and
looking to the freebsd.org website for help securing their systems.
The signifiance of these 7 bullets should not be overlooked or
understated. They call in to question the viability of FreeBSD itself.
IMO,
Roger Marquis
___
freebsd
* operators of FreeBSD servers (unlike Debian, Ubuntu, RedHat, Suse and
OpenBSD server operators) have no assurance that their systems are
secure.
Slow down here for a second. Where's the command-line tool on RedHat or
Debian that lists only the known vulnerable packages?
In RedHat
FreeBSD servers and
looking to the freebsd.org website for help securing their systems.
The signifiance of these 7 bullets should not be overlooked or
understated. They call in to question the viability of FreeBSD itself.
IMO,
Roger Marquis
SSLStaplingReturnResponderErrors off
SSLStaplingCacheshmcb:/var/run/ocsp(128000)
If you're processing credit cards SSLProtocol will need to be expanded to
-SSLv2 -SSLv3 -TLSv1 by 2016/07 (for PCI compliance) and if you have
good reason to be paranoid and all of your clients are up-to-date, add
-TLSv1.1.
Roger
FYI regarding these new and significant failures of FreeBSD security
policy and procedures.
PHP55 vulnerabilities announced over a week ago
https://www.dotdeb.org/2015/05/22/php-5-5-25-for-wheezy/) have still
not been ported to lang/php55. You can, however, edit the Makefile,
increment the
Yes, it does not create a /usr/bin/perl symlink, starting with Perl 5.20.
I'm curious about the logic behind this (automatic symlink removal without a
large warning message)? It would seem to come with a high cost and little
(any?) benefit. Shouldn't this at least be a dialog option?
If you
I need to get license info from a batch of ports and packages.
Problem is not all the specified ports/pkgs are installed or have license
info in their Makefile. Is there a reliable way to enumerate port or
package license strings, preferably without fetching a package tarfile?
Roger
On 7/07/2015 3:31 PM, Gregory Orange wrote:
I don't know if this is a helpful forum to raise it, but I would like to
request that SASL be enabled in the default build options for
mail/postfix.
We don't use the upstream Postfix package but have noticed that sites
serving IMAP use Dovecot more
curious because this violates KIS, the
principle of least surprise and few rc scripts seem to have this variable
defined.
Using command_interpreter is good to be sure, for for the reason listed,
but rc scripts should not fail if it is undefined.
IMO,
Roger Marquis
appreciate the features this subsystem
provides and the work devs have put into it but not when it's made
mandatory. The value of KIS needs to be emphasized here.
IMO,
Roger Marquis
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org
e reasons
are not mutually exclusive nor should they be. The design of pkgng should not
make it difficult or infeasible to mix ports and packages.
In other words, this is a bug.
Roger Marquis
___
freebsd-ports@freebsd.org mailing list
https://lists.fr
this be fixed
in 'pkg'?
Roger Marquis
Lowell Gilbert wrote:
> Baptiste Daroussin <b...@freebsd.org> wrote:
>> The change that was made was having the default packages on releases point to
>> quarterly branch of the ports tree. This was noted in the release note.
>
> Yes, but th
voluntary compliance it would surely help
corporate adoption. In our package tree only about 40% of several hundred
ports and packages provide any license string. That contrasts with Redhat
which has license info for every rpm (on the systems I've tested).
Roger Marquis
>> > I need to ge
Having endured 'buildworld; buildkernel; nstallkernal; reboot' and
'installworld; mergemaster' over the past few weeks I can say without
exaggeration it is an order of magnitude more time consuming that
'yum update' or 'aptitude upgrade'.
How about "freebsd-update fetch; freebsd-update install;
To be fair the support is last release + 2 years, supporting a minor
version for more than 2 years seems unreasonable, compare to say redhat
a major commercial vendor.
You can't really compare FreeBSD to a Redhat or Ubuntu LTS in this way
because ports generally continue to be upgradeable after
(The Ubuntu /etc/alternatives symlink system and other mechanisms solve
this well)
That hasn't been my experience but then I'm not a big fan of symlinks
which can't be safely modified outside of the (d)pkg system. As a
general rule you want to avoid such unnecessary layers of abstraction
where
In ports we have:
mail/postfix-current 2.11.7
mail/postfix 2.8.0
The version in mail/postfix-current is just barely still supported,
"barely still supported" is not accurate. 2.11 is still the most common
implementation by a good margin. Wietse recognizes this which is why he
has always
easons why Linux has effectively eclipsed BSD
including device drivers, unattended deployments and install menus but
8.X's wholesale throwing of so many of us under the bus was by far the
worst.
IMO,
Roger Marquis
___
freebsd-ports@freebsd.org mailing list
https
This makes no sense. Ports are not tied to base releases.
And you think lack of developer resources is an invalid reason?
There was no mid-release issue with base as far as I know. The issue was
with ports and by extension pkgng (and related -ngs).
You know good and well that people kick
So, if it was too burdensome for the whole project to support
two trees (that probably was the estimate for the core developers
involved [and I'm not one of them]), why, do you think, would
it have worked for a sub-fraction of the project ?
Thanks Kurt, for cutting to the core issue. It's one
Ports have to support all supported releases, that's the only connection.
They have historically and for good reason. Cross-platform ports are
FreeBSD's strongest feature, but it would not have taken a tremendous
amount of effort to have supported both pre- and post- ng trees in tandem
for say
I've never met bapt, who implemented pkg, or bdrewery, but from
what I can see, implementing pkg was not a short-term project for them.
Short-term perspective != short-term project considering they're both
relative to the ecosystem.
It was the only way out from the technical burden of the old
Ronald F. Guilmette wrote:
what would be a proper sort of sed command to extract
_just_ the port/package names, without the version numbers attached?
This has changed in the past so may not currently be 100% correct but
these should work:
awk -F'-[0-9]' '{ print $1 }'
or:
sed
Matthew Seaman wrote:
Put another way, if you're working with full pkgnames '%n-%v' it's always
the last '-' character that separates the name from the version.
$ pkgname='postgresql92-client-9.2.16'
$ echo ${pkgname%-*}
postgresql92-client
$ echo ${pkgname##*-}
9.2.16
Those of us who
A port name can contain digits and hyphens, so this could remove
part of the name.
As in: `pkg rquery -a %n | grep -- '-[0-9]' | fmt`
efax-0.9a font-adobe-100dpi font-adobe-75dpi font-adobe-utopia-100dpi
font-adobe-utopia-75dpi font-bh-100dpi font-bh-75dpi
font-bh-lucidatypewriter-100dpi
\mail\postfix-XXX Older versions of Postfix
\mail\postfix-stableLatest stable version of Postfix
\mail\postfix-current Experimental version of Postfix
Based on the goal of user-friendliness and principle of least surprise
I'd vote for changing -current to -experimental. It is a
Christoph Moench-Tegeder wrote:
Some systems (e.g. cfengine) are using a pull model, where the "managed"
machines connect to a central hub periodically, fetch the configuration
and "do what needs to be done", while e.g. ansible follows a "push"
model, where the "agent" is executed
https://reviews.freebsd.org/D7460
constructive comments welcome.
Would be nice if dialog were able to disable/enable modules after
choosing them for installation. An installed but disabled module would
still, in this design, write a file to modules.d but the LoadModule line
would be commented.
Timely update via Hackernews:
Note in particular:
"FreeBSD is still vulnerable to the portsnap, freebsd-update, bspatch,
and libarchive vulnerabilities."
Not sure why the portsec team has not commented or published an advisory
(possibly because the freebsd list spam filters are so bad
tions that do not
require patches.
Roger Marquis
___
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"
Matt Smith wrote:
Going slightly off-topic, I'm curious what the opinion is around this
and LibreSSL.
My organization evaluated this a few months ago and after a few diffs
and code reviews decided that libressl was the future. We updated
poudriere and all make.confs, removed openssl,
Rod Person wrote:
anything that can used to create text or graphics can be used to promote
hatred, discrimination or violence
"can used to" != "promotes" && "recursive logic" != "logic. Surely
there are better arguments against deprecating jive.
If PyCon can implement a Code of Conduct
Louis Epstein wrote:
You really need to have a hands-off policy on what software people use.
The meaning of this is unclear as anyone can still compile jive on their
own outside of the ports tree. WRT ports, they should be subject to the
same policies as base.
The meta questions here are: A)
was deprecated after being installed is
simply not a good reason for not listing it in the vulnxml. I say this
from experience have had to inform more than one FreeBSD site that they
were hosting known insecure software when they had previously trusted
'pkg audit'.
Roger Marquis
Walter Schwarzenfeld wrote:
|chmod 755 /var/db/pkg solved it.
Interesting. I had to 'chmod 644 /var/db/pkg/vuln.xml' for the same
effect. Wouldn't best practices set these at 750 and 640? Is there an
upside to restricting access to vuln.xml considering it's world readable
on the web?
Roger
On Tue, 11 Oct 2016, Julian Elischer wrote:
*manually* (scripted) copy out only the files I need, and then copy the pkg
database, so that when run on the running appliance, pkg THINKS all the
packages are loaded
We do something similar using prebuilt (pkg fetch) or locally built
(make
It is every week. Consider the FreeBSD forums as well.
"misuse" and "misunderstanding" failures are attributed to the tool. Let's
stop making excuses for portmaster. It is what it is and we've had years to
evaluate it.
If portmaster was part of base I'd agree that it should be deprecated,
John Marino wrote:
From porters handbook, section 12.15:
"It is possible to set DEPRECATED without an EXPIRATION_DATE (for instance,
recommending a newer version of the port)
I'd consider that to be a bug.
So it's not a contradiction. Ports that have a specific removal date must
have
of the sources you wouldn't be mislead by
following the money i.e., astroturf. At least the FreeBSD project
doesn't utilize professional astroturfers advertising on sites like the
Philippines' Craigslist. See also
<http://www.cringely.com/2016/12/08/whats-real-fake-news/>.
Roger M
It is just semantics.
That may be but as illustrated in this thread people maintain
unreasonable expectations of portmaster which they often blame on the
ports subsystem.
I never understood why people went ape- over it, unless they don't
understand what "deprecated without expiration"
Mark Linimon wrote:
* some extensive changes to the ports framework are coming;
Is there a URL (other than svnweb) where we can see a project plan for
these changes? As in the recent past (i.e., since 8-REL) the FreeBSD
end-user community has reason to be worried that:
* popular tools that
regarding the
validity of FreeBSD's vulnerability database is larger than this CVE.
We are concerned about update processes and procedures, especially
considering how this topic has come up in the past (for different apps).
Roger Marquis
___
fre
Jos Chrispijn wrote:
Dear sunpoet,
Noticed this week following issue on procmail.
...
procmail -- Heap-based buffer overflow
https://vuxml.FreeBSD.org/freebsd/288f7cee-ced6-11e7-8ae9-0050569f0b83.html
Whether mail/procmail is patched or deprecated standard practice has
been to upgrade to
12/1, had an updated Makefile since 12/2, yet there is still no
mention of it in vuxml, 3 days and one 'cd security/vuxml;make
newentry' later)
FWIW,
Roger Marquis
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/
As one of the "irresponsible" people who is still using procmail on our
systems and has built an number of scripts and customer infrastructure
around it I take exception to the term irresponsible. Perhaps the better
word is overworked. If I had the time to move to dovecot/sieve or maildrop
as a
Can certainly sympathize depending on the threat model, but how is that
any different from Equifax' not having time to patch Struts or not
having time to change the oil in your car or to brush your teeth ...
That's a non-sequitur if I understand the response correctly. Procmail IS
patched and
postfix to score and hold the obvious
spam that continues to get forwarded to freebsd lists. At least making
-ports subscriber-only is a small indication that someone on the
postmaster team recognizes there is an issue here.
IME,
Roger Marquis
_
Michelle Sullivan wrote:
Personally I think if you remove Sendmail you should not replace it with
something else... but then FreeBSD is not about what I want or what the
users want anymore.
I thought there already was a viable replacement in OpenSMTPD? The fact
that OpenBSD migrated 3 years
Anonymous (Carmel NY) wrote:
of course microsoft bought it to steal software more efficiently.
Steal what? It is already freely available. This is just more FUD spread by
people who fail to comprehend the actual logistics of the situation.
Unless you have a repo marked as private. Good luck
Per the 20171214 UPDATING entry:
Support for some deprecated variables is going to be removed soon. If
you use any of the following constructs (usually in /etc/make.conf),
you must switch to the new incantations:
...
WITH_OPENSSL_BASE DEFAULT_VERSIONS+= ssl=base
Sorry, the language there is unclear. It should say "ssl=[name of the port]".
You just want the ssl=libressl line.
Ah, so the "base" specified here is a constant whereas "port" is a
variable, to be expanded before writing make.conf. If I might then
suggest a potential documentation update:
<
is that the ports-secteam is a volunteer
effort and nobody really expects 'pkg audit' to be timely anyhow.
Such easily fixable problems. Even the FreeBSD Foundation for all the
projects it funds, and could fund with +$2.5M in the bank, doesn't seem
to care.
Roger Marquis
on updates be predicated on
equally significant OS version updates.
Roger Marquis
___
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"
Kurt Jaeger wrote:
I prepared a patch to build lyx without the 2.7 restriction. The
patch needs a run-test, can you test and report back ?
Has anyone enumerated the ports and applications which don't work with
python{,2,2.7} symlinked from pypy? Mailman seems fine but fail2ban
does not start,
committers instead of destroying their work without notice,
even for "niche" ports. Perhaps it doesn't because this was implicit or taken
for granted. In which case, in light of recent events, it may be a good time
to revise it.
Agreed.
Roger Marquis
_
88 matches
Mail list logo
