confusion about sudo version
$ pkg_info -Ix sudo sudo-1.8.3 Allow others to run commands as root $ grep DISTVERSION /usr/ports/security/sudo/Makefile DISTVERSION=1.8.3p1 $ pkg_version -I | grep sudo sudo> Regards Barbara ___ 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"
Re: confusion about sudo version
On 30 Oct 2011 09:48, "Barbara" wrote: > > > $ pkg_info -Ix sudo > sudo-1.8.3 Allow others to run commands as root > $ grep DISTVERSION /usr/ports/security/sudo/Makefile > DISTVERSION=1.8.3p1 > $ pkg_version -I | grep sudo > sudo> > Yeah, unfortunately p1 has the same trouble as r1; it makes the version appear less. Perhaps as a temporary fix we could set PORTVERSION to 1.8.3.1? Portepoch would be a little strong for this case wouldn't it? Chris ___ 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"
Re: confusion about sudo version
On 30 Oct 2011 14:14, "Chris Rees" wrote: > > > On 30 Oct 2011 09:48, "Barbara" wrote: > > > > > > $ pkg_info -Ix sudo > > sudo-1.8.3 Allow others to run commands as root > > $ grep DISTVERSION /usr/ports/security/sudo/Makefile > > DISTVERSION=1.8.3p1 > > $ pkg_version -I | grep sudo > > sudo> > > > > Yeah, unfortunately p1 has the same trouble as r1; it makes the version appear less. > > Perhaps as a temporary fix we could set PORTVERSION to 1.8.3.1? > > Portepoch would be a little strong for this case wouldn't it? > Wesley has fixed this a slightly different way: http://FreeBSD.org/cgi/cvsweb.cgi/ports/security/sudo/Makefile.diff?&r1=1.136&r2=1.137&f=h Chris ___ 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"
Re: confusion about sudo version
Am 30.10.2011 15:14, schrieb Chris Rees: > On 30 Oct 2011 09:48, "Barbara" wrote: >> >> >> $ pkg_info -Ix sudo >> sudo-1.8.3 Allow others to run commands as root >> $ grep DISTVERSION /usr/ports/security/sudo/Makefile >> DISTVERSION=1.8.3p1 >> $ pkg_version -I | grep sudo >> sudo> >> > > Yeah, unfortunately p1 has the same trouble as r1; it makes the version > appear less. Can we have a commit hook on pcvs that prevents commits if it makes the version go backwards? We have a-posteriori checking in place, but that is too late. ___ 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"
Re: confusion about sudo version
On 30 Oct 2011 15:21, "Matthias Andree" wrote: > > Am 30.10.2011 15:14, schrieb Chris Rees: > > On 30 Oct 2011 09:48, "Barbara" wrote: > >> > >> > >> $ pkg_info -Ix sudo > >> sudo-1.8.3 Allow others to run commands as root > >> $ grep DISTVERSION /usr/ports/security/sudo/Makefile > >> DISTVERSION=1.8.3p1 > >> $ pkg_version -I | grep sudo > >> sudo> > >> > > > > Yeah, unfortunately p1 has the same trouble as r1; it makes the version > > appear less. > > Can we have a commit hook on pcvs that prevents commits if it makes the > version go backwards? We have a-posteriori checking in place, but that > is too late. > It hardly ever happens though... Chris ___ 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"
tinderbox error question
Good day. I'm trying to update devel/geany-plugins and have weird tinderbox error: """ smeshariki3# ./tc tinderbuild -b 8.2-FreeBSD -nullfs devel/geany-plugins ERROR: Port, devel/geany-plugins is not in the datastore. tinderbuild: creating makefile... cd: /usr/local/tinderbox/portstrees/FreeBSD/ports//usr/local/tinderbox/portstrees/FreeBSD/ports: No such file or directory ERROR: Directory /usr/local/tinderbox/portstrees/FreeBSD/ports//usr/local/tinderbox/portstrees/FreeBSD/ports does not exist. tinderbuild: failed to generate Makefile for 8.2-FreeBSD tinderbuild: Cleaning up after tinderbuild. Please be patient. """ I wasn't able to trace why it trying to cd into this odd path, but if i lauch the build with the same command, but using current geany-plugins port, i could not reproduce this error. So what the problem may be? This patched geany-plugins is the only port that i was able to trigger this with. I also tried to upgrade tinderbox to latest stable version (3.4) to not avail. Please help. Thanks. Patch is there: http://happy-nation.by.ru/ports/geany-plugins-0.21.diff.txt -- Regards, Ruslan Tinderboxing kills... the drives. ___ 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"
Re: misc/rfc - the port / protocol option doesn't work anymore
On Wed, 26 Oct 2011, Torfinn Ingolfsen wrote: On Wed, Oct 26, 2011 at 7:02 PM, Sean C. Farley wrote: On Tue, 25 Oct 2011, Torfinn Ingolfsen wrote: Hello, It seems that the '-p' option of rfc doesn't work anymore: *snip* Thank you for the report. I am not sure if this application is maintained elsewhere, but I could not find any new updates from the developer or anyone else that had forked it last night. I did write a patch[1] against the port to use the data from the FTP server instead of the HTTP server. The HTTP server provides XML by default and text if requested, however, the text is not the same format that rfc expects. Let me know if it works for you--it works for me :), and I will try to update the port tonight with it. *snip* Yes - it works. Thanks a lot! Thank you for testing it. It is now committed. Sean -- s...@freebsd.org___ 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"
bsd.clang.mk
I just submitted ports/162178 (http://www.freebsd.org/cgi/query-pr.cgi?pr=162178), it adds a bsd.clang.mk that allows port maintainers and users to tune the use of Clang/LLVM with the ports tree. Maintainers can: - Mark ports as CLANG_SAFE - Mark ports as CLANG_UNSAFE - Use CLANG_PREFERRED (if available, clang will be used instead of cc) - Use USE_CLANG (like CLANG_PREFERRED, but introduces a build dependency if clang originates from the ports tree) Users can: - PREFER_CLANG, which takes effect if a port is CLANG_SAFE - FORCE_CLANG, which takes effect unless a port is CLANG_UNSAFE Obviously this needs testers. The maintainer side is more complex, because you can do things like defining CLANG_UNSAFE=2.9- and CLANG_SAFE=3. It's also possible to define version ranges like USE_CLANG=2.9-3 or specify several ranges like CLANG_UNSAFE= 2.9- 3.4+. -- A: Because it fouls the order in which people normally read text. Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing on usenet and in e-mail? ___ 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"
Re: ports/162049: The Ports tree lacks a framework to restart services
On 10/27/2011 09:27, Scott Lambert wrote:
> On Thu, Oct 27, 2011 at 11:15:00AM +0200, Ed Schouten wrote:
>> Hi folks,
>>
>> As crees@ suggested, I'm sending an email to ports@ about this.
>>
>> What really bothers me when I use the FreeBSD Ports tree on one of my
>> systems, is that the behaviour of dealing with services is quite
>> inconsistent.
>>
>> My question is whether anyone has ever attempted to improve the
>> integration with rc-scripts? In the PR I propose something along these
>> lines:
>>
>> We know exactly which ports install rc scripts (USE_RC_SUBR).
>> Why not run `/usr/local/etc/rc.d/${FOO} status' and
>> `/usr/local/etc/rc.d/${FOO} stop' prior to installation. Based
>> on the return value of the first, we can run
>> `/usr/local/etc/rc.d/${FOO} start' after installation.
>
> If all of that is contingent upon a boolean knob the admin can set,
> something like NO_RESTART_SERVICES, I suspect everyone could get
> what they want and the bikeshed would be limitted to what the default
> for that boolean should be.
>
> The people who don't want the services restarted automagically can
> set it and, once things use the new ports framewoork properly, not
> have to worry about suprises. The people who want everything to
> restarted as soon as possible can set the knob the other way.
>
> It could help keep our less sophisticated users from continuing to
> run vulerable versions of software after they think they have done
> what is needed to get the patched software. The sophisticated users
> would still be free to choose which foot to shoot.
>
> A side effect might, eventually, be to encourage ports maintainers
> to analyse their ported software for incompatible config changes
> so that they can programatically halt the install and output a
> warning message before attempting to stop the old daemon then
> upgrading while a likely un-usable config is in place.
>
> I see it as win, win, if there is a knob.
>
> I do not like either option without a knob, depending on the box
> we are talking about.
Speaking only for myself I hate the idea of stopping/starting services
automatically. However this feature is often requested, and is something
that is provided by many other package systems. If we have people who
are willing to do the work I think it's worth discussing how to do it
properly.
I think Scott's on the right track. The way that I envision it working
would be a 3-knob system. One knob to always restart the services, one
to never do it; and then asking on a per-port basis, which should be the
default. I can imagine portmaster detecting this option in the pre-build
phase similarly to how it detects and warns about IS_INTERACTIVE now,
and giving the user a menu of options for how to handle it. I'm happy to
add more details if people are interested.
Where this actually becomes interesting is not in the ports
build/install process, which is pretty easy to deal with, but with
package installs/deinstalls. I definitely think it's doable, what we
probably want to do is put a knob for this in the port's Makefile, and
handle the stop/start for both the port and the package with a little
script that can be included in the package, and run with @exec and @unexec.
hth,
Doug
--
Nothin' ever doesn't change, but nothin' changes much.
-- OK Go
Breadth of IT experience, and depth of knowledge in the DNS.
Yours for the right price. :) http://SupersetSolutions.com/
___
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"
