INDEX now builds successfully on 6.x
___ 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: Users and groups kept after a port deinstallation
On 05/21/2010 20:08, Garrett Cooper wrote: On Fri, May 21, 2010 at 4:53 PM, RW rwmailli...@googlemail.com wrote: On Fri, 21 May 2010 16:23:18 +0100 Florent Thoumie f...@xbsd.org wrote: On Fri, May 21, 2010 at 11:11 AM, David DEMELIER demelier.da...@gmail.com wrote: Hi, I used pkgsrc for a while on NetBSD. I was used to the pkgsrc notifications about the users and groups leaves, when some ports are removed these leaves are not used anymore. e.g pulseaudio needs some users on the system. This was discussed in the following bug-report: http://www.freebsd.org/cgi/query-pr.cgi?pr=108514 I think the proper solution is to create a +UGIDS file to be able to maintain a refcount, but the status quo isn't that bad. Personally I'd much prefer to keep them so ls -l, filemanagers etc can continue to use names rather than numbers for any files left behind. IMO the status quo is better than any solution that involves automated deletion. I agree by and large with RW, but it would be nice if there was an audit tool to do this check and suggest whether or not a group should be added or removed in general, regardless of whether or not a pkg/port was added or removed. Thanks, -Garrett find(1) is already used by periodic(1) through weekly_noid_enable which should probably be extended to also include weekly_nogid_enable and would ultimately alert you to users and groups that have gone missing due to a port removal. Having unused logins on a system is bad! and just for the case of mapping to uid/gid does not justify leaving them. uid gid printed in ls(1) output may be ugly as well but you can not log in with one of those and they should be handled in a way that is prompt to login removal. find / -nouser find / -nogroup and then after inspection add -delete -print. find / -empty Of course these can be combined to form a simple one line command but I will leave that as a exercise for the reader. Regards, -- jhell ___ 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: Users and groups kept after a port deinstallation
2010/5/22 Garrett Cooper yanef...@gmail.com: On Fri, May 21, 2010 at 4:53 PM, RW rwmailli...@googlemail.com wrote: On Fri, 21 May 2010 16:23:18 +0100 Florent Thoumie f...@xbsd.org wrote: On Fri, May 21, 2010 at 11:11 AM, David DEMELIER demelier.da...@gmail.com wrote: Hi, I used pkgsrc for a while on NetBSD. I was used to the pkgsrc notifications about the users and groups leaves, when some ports are removed these leaves are not used anymore. e.g pulseaudio needs some users on the system. This was discussed in the following bug-report: http://www.freebsd.org/cgi/query-pr.cgi?pr=108514 I think the proper solution is to create a +UGIDS file to be able to maintain a refcount, but the status quo isn't that bad. Personally I'd much prefer to keep them so ls -l, filemanagers etc can continue to use names rather than numbers for any files left behind. IMO the status quo is better than any solution that involves automated deletion. I agree by and large with RW, but it would be nice if there was an audit tool to do this check and suggest whether or not a group should be added or removed in general, regardless of whether or not a pkg/port was added or removed. Thanks, -Garrett Yes, of course I would not have something that remove automatically without prompting the user. I just wanted something like : Warning : these users are no long used by the system, you can remove then safely user1, user2 etc Cheers. ___ 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: Users and groups kept after a port deinstallation
On Sat, 22 May 2010 03:29:38 -0400 jhell jh...@dataix.net wrote: Having unused logins on a system is bad! Why? ___ 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
did sudo change the default sense of env_reset option?
Hi there, I haven't changed my configuration recently, but I've noticed that sudo processes have stopped inheriting my environment variables like MAKEOBJDIRPREFIX and PORTSDIR. I read the man page, and tried sudo -E, and that brings back the old behaviour, but that implies (according to the man page) that my sudoers file has env_reset enabled, and it just doesn't. Hmm. Closer reading of man 5 sudoers says that env_reset is *on* by default. This is new to me. Hmm. More digging in man pages: I need to add Defaults !env_reset under the #Defaults specification line. Any thoughts or suggestions? OK, so I've figured out the answer to my problem now, but since I have seen one other post about the sudden disappearance of MAKEOBJDIRPREFIX, and no obvious conversation about changes to sudo, I'll post this anyway. Hope it helps someone. Cheers, -- Andrew ___ 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: did sudo change the default sense of env_reset option?
On 05/22/2010 05:52, Andrew Reilly wrote: Hi there, I haven't changed my configuration recently, but I've noticed that sudo processes have stopped inheriting my environment variables like MAKEOBJDIRPREFIX and PORTSDIR. I read the man page, and tried sudo -E, and that brings back the old behaviour, but that implies (according to the man page) that my sudoers file has env_reset enabled, and it just doesn't. Hmm. Closer reading of man 5 sudoers says that env_reset is *on* by default. This is new to me. Hmm. More digging in man pages: I need to add Defaults !env_reset under the #Defaults specification line. Any thoughts or suggestions? OK, so I've figured out the answer to my problem now, but since I have seen one other post about the sudden disappearance of MAKEOBJDIRPREFIX, and no obvious conversation about changes to sudo, I'll post this anyway. Hope it helps someone. Cheers, Attached is the copy of the sudoers.default take a look through it to see how to set a environment variable for use with portupgrade or portmaster etc... -- jhell # sudoers file. # # This file MUST be edited with the 'visudo' command as root. # Failure to use 'visudo' may result in syntax or file permission errors # that prevent sudo from running. # # See the sudoers man page for the details on how to write a sudoers file. # # Host alias specification # User alias specification # Cmnd alias specification # Defaults specification # Uncomment if needed to preserve environmental variables related to the # FreeBSD pkg_* utilities and fetch. #Defaults env_keep += PKG_PATH PKG_DBDIR PKG_TMPDIR TMPDIR PACKAGEROOT PACKAGESITE PKGDIR FTP_PASSIVE_MODE # Additionally uncomment if needed to preserve environmental variables # related to portupgrade. #Defaults env_keep += PORTSDIR PORTS_INDEX PORTS_DBDIR PACKAGES PKGTOOLS_CONF # Runas alias specification # User privilege specification rootALL=(ALL) ALL # Uncomment to allow people in group wheel to run all commands # %wheelALL=(ALL) ALL # Same thing without a password # %wheelALL=(ALL) NOPASSWD: ALL # Samples # %users ALL=/sbin/mount /cdrom,/sbin/umount /cdrom # %users localhost=/sbin/shutdown -h now ___ 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
new upstream tracker (linuxtesting.org)
Hello, I'm from ISPRAS and we have created an experimental system for monitoring and analyzing of upstream libraries development. It may be helpful for analyzing risks of updating one of the distribution components (shared libraries). The web page of upstream-tracker is: http://linuxtesting.org/upstream-tracker/ It now includes ABI changes analysis and API shallow test results for several versions of 60 popular open source libraries. Any bugs or feature requests are welcome. Thanks. -- Andrey Ponomarenko Linux Verification Center, ISPRAS web:http://www.linuxtesting.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
Re: new upstream tracker (linuxtesting.org)
On Sat, May 22, 2010 at 03:54:20PM +0400, Andrey Ponomarenko wrote: Hello, I'm from ISPRAS and we have created an experimental system for monitoring and analyzing of upstream libraries development. It may be helpful for analyzing risks of updating one of the distribution components (shared libraries). The web page of upstream-tracker is: http://linuxtesting.org/upstream-tracker/ It now includes ABI changes analysis and API shallow test results for several versions of 60 popular open source libraries. Any bugs or feature requests are welcome. Thanks. WOW. Can you, please, share the setup of the tracker ? It would be amazingly interesting if you added FreeBSD base system libraries to the tracker. It would be extremely interesting and useful for us to see changes among releases and tips of the stable and head branches. pgp2mKk6vsaG1.pgp Description: PGP signature
Re: did sudo change the default sense of env_reset option?
Andrew Reilly arei...@bigpond.net.au wrote: Hmm. Closer reading of man 5 sudoers says that env_reset is *on* by default. This is new to me. Yes, the default for this changed a while back. -- Christian naddy Weisgerber na...@mips.inka.de ___ 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: Users and groups kept after a port deinstallation
On Sat, 22 May 2010 07:58:38 -0400 jhell jh...@dataix.net wrote: On 05/22/2010 07:08, RW wrote: On Sat, 22 May 2010 03:29:38 -0400 jhell jh...@dataix.net wrote: Having unused logins on a system is bad! Why? For one example: This opens up a point of possible access to the system in which its integrity could be jeopardized. What all the implications are of this is out of scope for this thread. These are unprivileged accounts without passwords - you need root privileges to use them. Nothing is going to be running under them or they wouldn't be candidates for removal in the first place. ___ 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: new upstream tracker (linuxtesting.org)
On 05/22/2010 04:30 PM, Kostik Belousov wrote: On Sat, May 22, 2010 at 03:54:20PM +0400, Andrey Ponomarenko wrote: Hello, I'm from ISPRAS and we have created an experimental system for monitoring and analyzing of upstream libraries development. It may be helpful for analyzing risks of updating one of the distribution components (shared libraries). The web page of upstream-tracker is: http://linuxtesting.org/upstream-tracker/ It now includes ABI changes analysis and API shallow test results for several versions of 60 popular open source libraries. Any bugs or feature requests are welcome. Thanks. WOW. Can you, please, share the setup of the tracker ? The tool itself is very young and is not well documented yet. Although the first version has been recently released under dual GNU GPL and LGPL licenses: http://ispras.linuxfoundation.org/index.php/Upstream_Tracker We are not recommended to use this version of the tool by yourself. Very soon we will release 1.1 version containing a lot of bug fixes and new features. It would be amazingly interesting if you added FreeBSD base system libraries to the tracker. Provide, please, the list of necessary libraries. It would be extremely interesting and useful for us to see changes among releases and tips of the stable and head branches. -- Andrey Ponomarenko Linux Verification Center, ISPRAS web:http://www.linuxtesting.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
OpenArena 0.8.5 port
For those of you interested in playing OpenArena on FreeBSD, I submitted a patch to games/openarena and a shar for OAX (OpenArena Xpanded): http://www.freebsd.org/cgi/query-pr.cgi?pr=146818 Unfortunately I'm not the maintainer so there's no saying if and when this will be committed, so I recommend to apply the patches yourself. Have fun fragging! -- 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
MPlayer - Invalid and inefficient vfw-avi packed B frames detected
Recently, i upgraded packages all by csup(fetch: 2010-05-14) + portupgrade. I did mplayer, too. After all that, when i launched mplayer with some avi movie file, mplayer said Invalid and inefficient vfw-avi packed B frames detected. Also mplayer's subtitle(Korean) was broken. Actually the mplayer of 8.0-RELEASE's official package is good. That have no such problems. Is there a solution? I'm running FreeBSD 8.0-RELEASE. And here is all packages installed (see following link). URL:http://izb.knu.ac.kr/~bh/stuff/pa20100522.lst Sincerely, Byung-Hee ___ 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
Porting SANE backend 1.0.21 to FreeBSD 7.2
If this is the wrong place, please be gentle! I need to get a Canon 8800F
scanner running on FreeBSD 7.2 . SANE's latest version is said to support this
scanner.
I have gotten a copy of it to build (and fed a few minor problems back to the
people at the SANE project:
https://alioth.debian.org/tracker/?func=detailatid=410366aid=312503group_id=30186)
and I have added
product CANON CS8800F 0x1901 CanoScan 8800F
to /usr/src/sys/dev/usb/usbdevs. I have also added
{{ USB_VENDOR_CANON, USB_PRODUCT_CANON_CS8800F }, 0 },
to /usr/src/sys/dev/usb/uscanner.c
When I run scanimage -L I get
-
device `pixma:04A91901' is a CANON Canoscan 8800F multi-function peripheral
---
When I run scanimage -d pixma:04A9101 I get
scanimage: sane_read: Invalid argument
Which I have traced to a defaulted fill routine in a table.
scanimage --help gives me
---
Usage: scanimage [OPTION]...
Start image acquisition on a scanner device and write image data to
standard output.
Parameters are separated by a blank from single-character options (e.g.
-d epson) and by a = from multi-character options (e.g. --device-name=epson).
-d, --device-name=DEVICE use a given scanner device (e.g. hp:/dev/scanner)
--format=pnm|tiff file format of output file
-i, --icc-profile=PROFILE include this ICC profile into TIFF file
-L, --list-devices show available scanner devices
-f, --formatted-device-list=FORMAT similar to -L, but the FORMAT of the output
can be specified: %d (device name), %v (vendor),
%m (model), %t (type), %i (index number), and
%n (newline)
-b, --batch[=FORMAT] working in batch mode, FORMAT is `out%d.pnm' or
`out%d.tif' by default depending on --format
--batch-start=#page number to start naming files with
--batch-count=#how many pages to scan in batch mode
--batch-increment=#increase page number in filename by #
--batch-double increment page number by two, same as
--batch-increment=2
--batch-prompt ask for pressing a key before scanning a page
--accept-md5-only only accept authorization requests using md5
-p, --progress print progress messages
-n, --dont-scanonly set options, don't actually scan
-T, --test test backend thoroughly
-h, --help display this help message and exit
-v, --verbose give even more status messages
-B, --buffer-size=#change input buffer size (in kB, default 32)
-V, --version print version information
Options specific to device `pixma:04A91901':
Scan mode:
--resolution auto||75|150|300|600|1200|2400|4800dpi [75]
Sets the resolution of the scanned image.
--mode auto|Color|Gray [Color]
Selects the scan mode (e.g., lineart, monochrome, or color).
--source Flatbed|Transparency Unit [Flatbed]
Selects the scan source (such as a document-feeder).
--button-controlled[=(yes|no)] [no]
When enabled, scan process will not start immediately. To proceed,
press SCAN button (for MP150) or COLOR button (for other models).
To cancel, press GRAY button.
Gamma:
--custom-gamma[=(auto|yes|no)] [yes]
Determines whether a builtin or a custom gamma-table should be used.
--gamma-table auto|0..255,...
Gamma-correction table. In color mode this option equally affects the
red, green, and blue channels simultaneously (i.e., it is an intensity
gamma table).
Geometry:
-l auto|0..216.069mm [0]
Top-left x position of scan area.
-t auto|0..297.011mm [0]
Top-left y position of scan area.
-x auto|0..216.069mm [216.069]
Width of scan-area.
-y auto|0..297.011mm [297.011]
Height of scan-area.
Buttons:
--button-update
Update button state
--button-1 int [0]
Button 1
--button-2 int [0]
Button 2
Type ``scanimage --help -d DEVICE'' to get list of all options for DEVICE.
List of available devices:
There is a /dev/usb/uscanner .
I haven't figured out how to turn on the internal debugging system, so my first
question to someone who may have ported an earlier version is how to do that.
My second question is whether I have the USB entries right, and whether I need
to do anything else to make this work.
And finally, I ask for any general wisdom or hints in dealing with SANE and
SANE with USB devices.
When I am done, I will gladly turn my work over to anyone who would like to
incorporate it into the ports base. (And after this, I need a new CUPS and an
EPSON Sylus R1900).
Thank you for any help you may be able to offer.
Mark Terribile
___
freebsd-ports@freebsd.org mailing list
Re: Users and groups kept after a port deinstallation
On 05/22/2010 08:42, RW wrote: On Sat, 22 May 2010 07:58:38 -0400 jhell jh...@dataix.net wrote: On 05/22/2010 07:08, RW wrote: On Sat, 22 May 2010 03:29:38 -0400 jhell jh...@dataix.net wrote: Having unused logins on a system is bad! Why? For one example: This opens up a point of possible access to the system in which its integrity could be jeopardized. What all the implications are of this is out of scope for this thread. These are unprivileged accounts without passwords - you need root privileges to use them. Nothing is going to be running under them or they wouldn't be candidates for removal in the first place. Are we arguing the point that these should just be left or can we come to a point like I stated in the previous email that you so gracefully chopped out that stated: If they are to be left in the system a admin should be notified or they should be automatically removed upon package removal. This is more of a best practices case than what the implications of leaving users in the master.passwd are. -- jhell ___ 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
Portscout stuff
Hi folks, I have been working on a new portscout release, and using miwi's server for debugging, so a) updates aren't being sent out as frequently as usual, and b) I'm resetting the old data each time, meaning you will probably get multiple notices for each new version found. So sorry for any annoyance caused. The new release is a huge step forward, fixing many bugs, and vastly improving the version detection and comparison algorithms. Also, you may have noticed that the new SourceForge mirror layout is now supported. In fact, despite requiring some extra hooping-jumping, accuracy should be improved somewhat for SourceForge-hosted ports. In addition, there are many goodies for users of portscout itself, including support for SQLite (at last), support for building without CVSup logs or even an INDEX file, and possible support (with a little work) for repos other than FreeBSD ports; feeding portscout with a simple XML file is now possible too. There are also a few new features destined for the /next/ release, including RSS feeds. For those who have no idea what I'm talking about, here's a quick refresher: Portscout is a tool/service that looks for new distfile versions. We have an installation, provided by Martin Wilke (miwi) which runs daily and both publishes HTML reports and sends out incremental summaries via e-mail: http://portscout.org/ The page for ports@ is a particularly good place to look if you want to help out but don't know where to start. Plenty of easy ports to upgrade. Once you've found one, check out the Porter's Handbook for details on how to go about upgrading the port and submitting a PR: http://www.freebsd.org/doc/en_US.ISO8859-1/books/porters-handbook/ If you want to sign up for e-mail reminders for ports you maintain, talk to Martin or to me. Shaun -- Shaun Amott // PGP: 0x6B387A9A A foolish consistency is the hobgoblin of little minds. - Ralph Waldo Emerson ___ 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
RFT: netatalk-2.1
Hi, I'm working on updating the net/netatalk port from 2.0.5 to 2.1. You can find the most current version of my work at http://www.lassitu.de/freebsd/netatalk/ Initial testing looks promising. There's one outstanding issue: upgrading from 2.0.5 to 2.1 appears to fail because of the wrong order of include paths. You can work around this by deinstalling 2.0.5 before building the new version. This work is also being tracked in PR#146576. HTH, Stefan -- Stefan Bethke s...@lassitu.de Fon +49 151 14070811 ___ 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: cvs commit: ports/math/metis-edf Makefile
The Restless Daemon identified a arch error while trying to build: metis-edf-4.1.2_2 maintained by po...@freebsd.org Makefile ident: $FreeBSD: ports/math/metis-edf/Makefile,v 1.21 2010/05/22 12:53:44 thierry Exp $ Excerpt from http://QAT.TecNik93.com/logs/8-STABLE-NPD/metis-edf-4.1.2_2.log : a - frename.o a - fortran.o a - myqsort.o a - compress.o a - parmetis.o a - estmem.o a - mpmetis.o a - mcoarsen.o a - mmatch.o a - minitpart.o a - mbalance.o a - mrefine.o a - mutil.o a - mfm.o a - mkmetis.o a - mkwayrefine.o a - mkwayfmh.o a - mrefine2.o a - minitpart2.o a - mbalance2.o a - mfm2.o a - kvmetis.o a - kwayvolrefine.o a - kwayvolfm.o a - subdomains.o gcc44 -L. -Wl,-Bshareable -Wl,-o,../libmetis.so.1 -Wl,-x -Wl,-soname,libmetis.so.1 -Wl,--whole-archive ../libmetis.a -Wl,-no-whole-archive /usr/local/bin/ld: /usr/lib/crt1.o: relocation R_X86_64_32 against `_DYNAMIC' can not be used when making a shared object; recompile with -fPIC /usr/lib/crt1.o: could not read symbols: Bad value collect2: ld returned 1 exit status *** Error code 1 Stop in /work/a/ports/math/metis-edf/work/metis_edf-4.1/Lib. *** Error code 1 Stop in /work/a/ports/math/metis-edf/work/metis_edf-4.1. *** Error code 1 Stop in /a/ports/math/metis-edf. build of /usr/ports/math/metis-edf ended at Sat May 22 18:04:43 UTC 2010 PortsMon page for the port: http://portsmon.freebsd.org/portoverview.py?category=mathportname=metis-edf The build which triggered this BotMail was done under tinderbox-3.3_3; dsversion: 3.2.1 on RELENG_8 on amd64, kern.smp.cpus: 8 with tinderd_flags=-nullfs -plistcheck -onceonly and ccache support, with the official up-to-date Ports Tree, with the following vars set: NOPORTDOCS=yes, NOPORTEXAMPLES=yes, NOPORTDATA=yes, FORCE_PACKAGE=yes. A description of the testing process can be found here: http://T32.TecNik93.com/FreeBSD/QA-Tindy/ Thanks for your work on making FreeBSD better, -- QAT - your friendly neighborhood Daemon, preparing a heck of an error trapping system: - HMC and EOI? - Halt, Melt and Catch fire or Execute Operator Immediately. ___ 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: Porting SANE backend 1.0.21 to FreeBSD 7.2
On Sat, 22 May 2010, Mark Terribile wrote: If this is the wrong place, please be gentle! I need to get a Canon 8800F scanner running on FreeBSD 7.2 . SANE's latest version is said to support this scanner. sane-backends 1.0.21 showed up in ports this morning... I have gotten a copy of it to build (and fed a few minor problems back to the people at the SANE project: https://alioth.debian.org/tracker/?func=detailatid=410366aid=312503group_id=30186) Not sure what's going on in that thread, but the upstream software developer really shouldn't have to worry about FreeBSD paths and where the FreeBSD port is going to end up directory-wise. That's kind of what the port is all about. -Warren Block * Rapid City, South Dakota USA___ 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
innotop 1.7.2
Hello Steven, you are the maintainer of databases/innotop port for FreeBSD. Have you seen that there is a new version of innotop: http://code.google.com/p/innotop/ ? Would you mention updating it in the ports collection? -- // cronfy ___ 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: new upstream tracker (linuxtesting.org)
On Sat, May 22, 2010 at 4:54 AM, Andrey Ponomarenko susa...@ispras.ru wrote: Hello, I'm from ISPRAS and we have created an experimental system for monitoring and analyzing of upstream libraries development. It may be helpful for analyzing risks of updating one of the distribution components (shared libraries). The web page of upstream-tracker is: http://linuxtesting.org/upstream-tracker/ It now includes ABI changes analysis and API shallow test results for several versions of 60 popular open source libraries. Any bugs or feature requests are welcome. Thanks. Just out of curiosity, is this a system for monitoring the 3rd party libraries that have been imported into our base system, or is it a generic tool for running testcases? I'll poke at it further, in the meantime, but it would be helpful if an expert could comment on the issue more :). I ask because Linux in and of itself doesn't really have a base system and everything's packages from the get-go, whereas *BSD has a userland with some 3rd party packages all wrapped into one base system. Also, how do you `test' the applications -- using the runtime tests produced in previous versions, or by just executing applications and observing whether or not the API calls pass or fail? Thanks! -Garrett ___ 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: new upstream tracker (linuxtesting.org)
On Sat, May 22, 2010 at 6:12 AM, Andrey Ponomarenko susa...@ispras.ru wrote: On 05/22/2010 04:30 PM, Kostik Belousov wrote: On Sat, May 22, 2010 at 03:54:20PM +0400, Andrey Ponomarenko wrote: Hello, I'm from ISPRAS and we have created an experimental system for monitoring and analyzing of upstream libraries development. It may be helpful for analyzing risks of updating one of the distribution components (shared libraries). The web page of upstream-tracker is: http://linuxtesting.org/upstream-tracker/ It now includes ABI changes analysis and API shallow test results for several versions of 60 popular open source libraries. Any bugs or feature requests are welcome. Thanks. WOW. Can you, please, share the setup of the tracker ? The tool itself is very young and is not well documented yet. Although the first version has been recently released under dual GNU GPL and LGPL licenses: http://ispras.linuxfoundation.org/index.php/Upstream_Tracker We are not recommended to use this version of the tool by yourself. Very soon we will release 1.1 version containing a lot of bug fixes and new features. Unfortunately this could only be added to the base system as a port today as it depends on perl (something that was tossed from the base system many moons ago because of cross-building issues). I'll poke around at the software and port it to FreeBSD because it looks interesting though and does provide a relatively simple interface for digesting test results. It would be amazingly interesting if you added FreeBSD base system libraries to the tracker. Provide, please, the list of necessary libraries. It would be extremely interesting and useful for us to see changes among releases and tips of the stable and head branches. Thanks, -Garrett ___ 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: innotop 1.7.2
On May 22, 2010, at 2:16 PM, cronfy wrote: Hello Steven, you are the maintainer of databases/innotop port for FreeBSD. Have you seen that there is a new version of innotop: http://code.google.com/p/innotop/ ? Would you mention updating it in the ports collection? Thanks for the heads up. I just committed the update. Update your ports tree and you should be all set. -- Steven Kreuzer http://www.exit2shell.com/~skreuzer ___ 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: new upstream tracker (linuxtesting.org)
On Sat, May 22, 2010 at 12:32 PM, Garrett Cooper yanef...@gmail.com wrote: On Sat, May 22, 2010 at 6:12 AM, Andrey Ponomarenko susa...@ispras.ru wrote: On 05/22/2010 04:30 PM, Kostik Belousov wrote: On Sat, May 22, 2010 at 03:54:20PM +0400, Andrey Ponomarenko wrote: Hello, I'm from ISPRAS and we have created an experimental system for monitoring and analyzing of upstream libraries development. It may be helpful for analyzing risks of updating one of the distribution components (shared libraries). The web page of upstream-tracker is: http://linuxtesting.org/upstream-tracker/ It now includes ABI changes analysis and API shallow test results for several versions of 60 popular open source libraries. Any bugs or feature requests are welcome. Thanks. WOW. Can you, please, share the setup of the tracker ? The tool itself is very young and is not well documented yet. Although the first version has been recently released under dual GNU GPL and LGPL licenses: http://ispras.linuxfoundation.org/index.php/Upstream_Tracker We are not recommended to use this version of the tool by yourself. Very soon we will release 1.1 version containing a lot of bug fixes and new features. Unfortunately this could only be added to the base system as a port today as it depends on perl (something that was tossed from the base system many moons ago because of cross-building issues). I'll poke around at the software and port it to FreeBSD because it looks interesting though and does provide a relatively simple interface for digesting test results. There are several portability issues with the perl scripts that should be resolved for this to be usable outside of Linux. I'll file bugs for these bits. It would be amazingly interesting if you added FreeBSD base system libraries to the tracker. Provide, please, the list of necessary libraries. It would be extremely interesting and useful for us to see changes among releases and tips of the stable and head branches. Thanks, -Garrett ___ 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: new upstream tracker (linuxtesting.org)
On Sat, May 22, 2010 at 12:58 PM, Garrett Cooper yanef...@gmail.com wrote: On Sat, May 22, 2010 at 12:32 PM, Garrett Cooper yanef...@gmail.com wrote: On Sat, May 22, 2010 at 6:12 AM, Andrey Ponomarenko susa...@ispras.ru wrote: On 05/22/2010 04:30 PM, Kostik Belousov wrote: On Sat, May 22, 2010 at 03:54:20PM +0400, Andrey Ponomarenko wrote: Hello, I'm from ISPRAS and we have created an experimental system for monitoring and analyzing of upstream libraries development. It may be helpful for analyzing risks of updating one of the distribution components (shared libraries). The web page of upstream-tracker is: http://linuxtesting.org/upstream-tracker/ It now includes ABI changes analysis and API shallow test results for several versions of 60 popular open source libraries. Any bugs or feature requests are welcome. Thanks. WOW. Can you, please, share the setup of the tracker ? The tool itself is very young and is not well documented yet. Although the first version has been recently released under dual GNU GPL and LGPL licenses: http://ispras.linuxfoundation.org/index.php/Upstream_Tracker We are not recommended to use this version of the tool by yourself. Very soon we will release 1.1 version containing a lot of bug fixes and new features. Unfortunately this could only be added to the base system as a port today as it depends on perl (something that was tossed from the base system many moons ago because of cross-building issues). I'll poke around at the software and port it to FreeBSD because it looks interesting though and does provide a relatively simple interface for digesting test results. There are several portability issues with the perl scripts that should be resolved for this to be usable outside of Linux. I'll file bugs for these bits. It would be amazingly interesting if you added FreeBSD base system libraries to the tracker. Provide, please, the list of necessary libraries. It would be extremely interesting and useful for us to see changes among releases and tips of the stable and head branches. Wow... there's so much grown code in this project that it quite frankly scares me (20k lines of perl code... yikes). I need to look into implementing a clean design with my ballista rewrite in python, because the lack of modularity and the number of gcc-isms and linux-isms in this isn't really super portable. But that's several months or maybe a year down the line. Thanks, -Garrett ___ 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
How to extract tcl src
I am trying to update graphics/togl. I am running into the following issue. The togl configure file accesses /usr/local/lib/tcl8.5/tclConfig.sh, and figures out that the port was built in /usr/ports/lang/tcl85/work/tcl8.5.8. It wants to access that directory. How do I tell the Makefile in the port to make sure that I have done something like cd /usr/ports/lang/tcl85 make extract? ___ 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: Users and groups kept after a port deinstallation
On Sat, 22 May 2010 11:42:53 -0400 jhell jh...@dataix.net wrote: Having unused logins on a system is bad! Why? For one example: This opens up a point of possible access to the system in which its integrity could be jeopardized. What all the implications are of this is out of scope for this thread. These are unprivileged accounts without passwords - you need root privileges to use them. Nothing is going to be running under them or they wouldn't be candidates for removal in the first place. Are we arguing the point that these should just be left or can we come to a point like I stated in the previous email that you so gracefully chopped out that stated: If they are to be left in the system a admin should be notified or they should be automatically removed upon package removal. If there are no security concerns, the rest is just a bike shed This is more of a best practices case than what the implications of leaving users in the master.passwd are. Why is it best practice? Why add extra complexity to solve a problem that doesn't actually exist? ___ 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: How to extract tcl src
Stephen Montgomery-Smith step...@missouri.edu writes:
I am trying to update graphics/togl. I am running into the following issue.
The togl configure file accesses /usr/local/lib/tcl8.5/tclConfig.sh,
and figures out that the port was built in
/usr/ports/lang/tcl85/work/tcl8.5.8. It wants to access that
directory.
How do I tell the Makefile in the port to make sure that I have done
something like cd /usr/ports/lang/tcl85 make extract?
Try to add following
BUILD_DEPENDS= ${NONEXISTENT}:${PORTSDIR}/lang/tcl85:extract
___
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: Users and groups kept after a port deinstallation
RW rwmailli...@googlemail.com writes: On Sat, 22 May 2010 11:42:53 -0400 jhell jh...@dataix.net wrote: This is more of a best practices case than what the implications of leaving users in the master.passwd are. Why is it best practice? Why add extra complexity to solve a problem that doesn't actually exist? Such unused entries in passwd add clutter. It in turn makes managing users more complex. You have to remember which users are created by you and which ones are created by ports. So, if you change home dir of some user there may be undesireble consequences. And only then security becomes a concern because port app may be run with privilegies that are higher than intended. ___ 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: Users and groups kept after a port deinstallation
On Sun, 23 May 2010 03:39:53 +0400 Anonymous swel...@gmail.com wrote: RW rwmailli...@googlemail.com writes: On Sat, 22 May 2010 11:42:53 -0400 jhell jh...@dataix.net wrote: This is more of a best practices case than what the implications of leaving users in the master.passwd are. Why is it best practice? Why add extra complexity to solve a problem that doesn't actually exist? Such unused entries in passwd add clutter. It in turn makes managing users more complex. You have to remember which users are created by you and which ones are created by ports. You don't have to remember, just look at the UID/GID values, ordinary users start at 1001, ports create UIDs 1000. The base system alone creates 18 such users, if you have problems with this kind of thing a few stale uids are the least of your problems. So, if you change home dir of some user there may be undesireble consequences. And only then security becomes a concern because port app may be run with privilegies that are higher than intended. This appears to refer to an admin confusing a normal user with a system user that's still in use by a port, so I don't see the relevance. ___ 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: How to extract tcl src
On 05/22/2010 19:23, Anonymous wrote:
BUILD_DEPENDS= ${NONEXISTENT}:${PORTSDIR}/lang/tcl85:extract
Attached is the Makefile I just edited to configure against tcl and tk
8.5 instead of 8.4.
I have verified it for functionality (as in) extract, configure, make
install only.
Before I made the mods I did not make a original copy so this is why I
did not provide a unified diff but I have bumped the the PORTREVISION
from _1 to _2 and it should be ready to be committed as this was a
pretty trivial change.
The most significant change mentioned above was changed to:
BUILD_DEPENDS= ${NONEXISTENT}:${PORTSDIR}/lang/tcl85:configure
This was needed to provide configured values that graphics/togl would
then read.
Regards,
--
jhell
# New ports collection makefile for:Togl
# Date created: Wed Aug 18 18:49:17 EDT 1999
# Whom: Randall Hopper aa...@ipass.net
#
# $FreeBSD: ports/graphics/togl/Makefile,v 1.20 2009/08/22 00:23:10 amdmi3 Exp $
#
PORTNAME= togl
PORTVERSION=1.7
PORTREVISION= 2
CATEGORIES= graphics tk
MASTER_SITES= SF/${PORTNAME}/Togl/${PORTVERSION}
DISTNAME= Togl-${PORTVERSION}
MAINTAINER= po...@freebsd.org
COMMENT=A Tk OpenGL widget
BUILD_DEPENDS= ${NONEXISTENT}:${PORTSDIR}/lang/tcl85:configure
LIB_DEPENDS=tk85.1:${PORTSDIR}/x11-toolkits/tk85 \
tcl85.1:${PORTSDIR}/lang/tcl85
USE_GMAKE= yes
GNU_CONFIGURE= yes
USE_GL= yes
USE_XORG= x11 xt xmu
MAKE_ENV= PTHREAD_LIBS=${PTHREAD_LIBS} \
PTHREAD_CFLAGS=${PTHREAD_CFLAGS}
CONFIGURE_ENV= CFLAGS=-I${LOCALBASE}/include/tk8.5 \
LDFLAGS=-L${LOCALBASE}/lib/tk8.5
CONFIGURE_ARGS= --with-tk=${LOCALBASE}/lib/tk8.5 \
--with-tcl=${LOCALBASE}/lib/tcl8.5 \
--with-tclinclude=${LOCALBASE}/include/tcl8.5 \
TOGL_INSTDIR= ${PREFIX}/lib/tk8.5/${DISTNAME}
PLIST_SUB= TOGL_INSTDIR=${TOGL_INSTDIR:S,^${PREFIX}/,,}
.if !defined(NOPORTDOCS)
PORTDOCS= *
.endif
post-patch:
@${REINPLACE_CMD} -e 's|wish |wish8.5 |' ${WRKSRC}/*.tcl
do-install:
@${MKDIR} ${TOGL_INSTDIR}
${INSTALL_DATA} ${WRKSRC}/libTogl1.7.so ${TOGL_INSTDIR}/togl.so
${INSTALL_DATA} ${WRKSRC}/togl.h ${WRKSRC}/pkgIndex.tcl ${TOGL_INSTDIR}
@${MKDIR} ${EXAMPLESDIR}
${INSTALL_DATA} ${WRKSRC}/Makefile ${EXAMPLESDIR}
${INSTALL_DATA} ${WRKSRC}/togl.c ${WRKSRC}/togl.h ${EXAMPLESDIR}
${INSTALL_DATA} ${WRKSRC}/double.c ${WRKSRC}/double.tcl ${EXAMPLESDIR}
${INSTALL_DATA} ${WRKSRC}/gears.c ${WRKSRC}/gears.tcl ${EXAMPLESDIR}
${INSTALL_DATA} ${WRKSRC}/index.c ${WRKSRC}/index.tcl ${EXAMPLESDIR}
${INSTALL_DATA} ${WRKSRC}/overlay.c ${WRKSRC}/overlay.tcl ${EXAMPLESDIR}
${INSTALL_DATA} ${WRKSRC}/stereo.c ${WRKSRC}/stereo.tcl ${EXAMPLESDIR}
${INSTALL_DATA} ${WRKSRC}/texture.c ${WRKSRC}/texture.tcl ${EXAMPLESDIR}
${INSTALL_DATA} ${WRKSRC}/image.c ${WRKSRC}/image.h ${WRKSRC}/ben.rgb
${WRKSRC}/tree2.rgba ${EXAMPLESDIR}
.if !defined(NOPORTDOCS)
@${MKDIR} ${DOCSDIR}
${INSTALL_DATA} ${WRKSRC}/Togl.html ${DOCSDIR}
.endif
.include bsd.port.mk
___
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: Users and groups kept after a port deinstallation
On May 22, 2010, at 16:39 , Anonymous wrote: Such unused entries in passwd add clutter. It in turn makes managing users more complex. You have to remember which users are created by you and which ones are created by ports. Irrespective of the UID/GID stuff mentioned elsewhere, merely go through the ports tree and add (or append) (created by ports) to the GECOS field of any such created users. I'd like my shed to be white, for some definition of the sixty bazillion different whites out there, paint-wise. Meh. Hate painting. -aDe ___ 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: How to extract tcl src
On Sat, May 22, 2010 at 7:11 PM, jhell jh...@dataix.net wrote:
On 05/22/2010 19:23, Anonymous wrote:
BUILD_DEPENDS= ${NONEXISTENT}:${PORTSDIR}/lang/tcl85:extract
Attached is the Makefile I just edited to configure against tcl and tk
8.5 instead of 8.4.
I have verified it for functionality (as in) extract, configure, make
install only.
Before I made the mods I did not make a original copy so this is why I
did not provide a unified diff but I have bumped the the PORTREVISION
from _1 to _2 and it should be ready to be committed as this was a
pretty trivial change.
The most significant change mentioned above was changed to:
BUILD_DEPENDS= ${NONEXISTENT}:${PORTSDIR}/lang/tcl85:configure
This was needed to provide configured values that graphics/togl would
then read.
The danger in this particular case is that you're assuming that
the copy of tcl installed and the copy in ports are one in the same.
Just pre-patch whatever code is monkey fubaring the path lookup to point to:
${LIBDIR}/tcl-version/tclConfig.sh
and file the appropriate bug upstream to fix whatever software
package is monkeying up the path.
HTH,
-Garrett
___
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: Users and groups kept after a port deinstallation
On 05/22/2010 21:11, RW wrote: On Sun, 23 May 2010 03:39:53 +0400 Anonymous swel...@gmail.com wrote: RW rwmailli...@googlemail.com writes: On Sat, 22 May 2010 11:42:53 -0400 jhell jh...@dataix.net wrote: This is more of a best practices case than what the implications of leaving users in the master.passwd are. Why is it best practice? Why add extra complexity to solve a problem that doesn't actually exist? Such unused entries in passwd add clutter. It in turn makes managing users more complex. You have to remember which users are created by you and which ones are created by ports. You don't have to remember, just look at the UID/GID values, ordinary users start at 1001, ports create UIDs 1000. The base system alone creates 18 such users, if you have problems with this kind of thing a few stale uids are the least of your problems. So, if you change home dir of some user there may be undesireble consequences. And only then security becomes a concern because port app may be run with privilegies that are higher than intended. This appears to refer to an admin confusing a normal user with a system user that's still in use by a port, so I don't see the relevance. You being the originator of the thread called Users and groups kept after a port deinstallation which implies to me that you had a problem with users left behind on a system am I correct ? If so then why do you keep insisting on arguing a point that says you really do not care about left-overs on your system ? If you really do not care about them after suggestions have been made in either point that would help with the above subject line then what is the original intention of your email ? why did you even write it ? Here is some additional reading that might spark your interests in removing them or maybe not. http://tinyurl.com/36ww9k2 PS: SANSFIRE is coming to Baltimore, MD in June. R U Signed ^? -- jhell ___ 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: How to extract tcl src
jhell jh...@dataix.net writes:
On 05/22/2010 19:23, Anonymous wrote:
BUILD_DEPENDS= ${NONEXISTENT}:${PORTSDIR}/lang/tcl85:extract
Attached is the Makefile I just edited to configure against tcl and tk
8.5 instead of 8.4.
I think using bsd.tcl.mk is better idea, see below
Index: graphics/togl/Makefile
===
RCS file: /a/.cvsup/ports/graphics/togl/Makefile,v
retrieving revision 1.20
diff -u -p -r1.20 Makefile
--- graphics/togl/Makefile 22 Aug 2009 00:23:10 - 1.20
+++ graphics/togl/Makefile 23 May 2010 03:15:07 -
@@ -15,34 +15,30 @@ DISTNAME= Togl-${PORTVERSION}
MAINTAINER= po...@freebsd.org
COMMENT= A Tk OpenGL widget
-LIB_DEPENDS= tk84.1:${PORTSDIR}/x11-toolkits/tk84 \
- tcl84.1:${PORTSDIR}/lang/tcl84
-
USE_GMAKE= yes
GNU_CONFIGURE= yes
USE_GL= yes
USE_XORG= x11 xt xmu
+USE_TK= 85+
+PATCH_TK_SCRIPTS=*.tcl
MAKE_ENV= PTHREAD_LIBS=${PTHREAD_LIBS} \
PTHREAD_CFLAGS=${PTHREAD_CFLAGS}
-CONFIGURE_ENV= CFLAGS=-I${LOCALBASE}/include/tk8.4 \
- LDFLAGS=-L${LOCALBASE}/lib/tk8.4
-CONFIGURE_ARGS= --with-tk=${LOCALBASE}/lib/tk8.4 \
- --with-tcl=${LOCALBASE}/lib/tcl8.4 \
- --with-tclinclude=${LOCALBASE}/include/tcl8.4 \
+CONFIGURE_ENV= CFLAGS=-I${TK_INCLUDEDIR} \
+ LDFLAGS=-L${TK_LIBDIR}
+CONFIGURE_ARGS= --with-tk=${TK_LIBDIR} \
+ --with-tcl=${TCL_LIBDIR} \
+ --with-tclinclude=${TCL_INCLUDEDIR} \
-TOGL_INSTDIR= ${PREFIX}/lib/tk8.4/${DISTNAME}
+TOGL_INSTDIR= ${TK_LIBDIR:S/${LOCALBASE}/${PREFIX}/}/${DISTNAME}
PLIST_SUB= TOGL_INSTDIR=${TOGL_INSTDIR:S,^${PREFIX}/,,}
.if !defined(NOPORTDOCS)
PORTDOCS= *
.endif
-post-patch:
- @${REINPLACE_CMD} -e 's|wish |wish8.4 |' ${WRKSRC}/*.tcl
-
do-install:
@${MKDIR} ${TOGL_INSTDIR}
- ${INSTALL_DATA} ${WRKSRC}/libTogl1.7.so ${TOGL_INSTDIR}/togl.so
+ ${INSTALL_DATA} ${WRKSRC}/libTogl${PORTVERSION}.so ${TOGL_INSTDIR}/togl.so
${INSTALL_DATA} ${WRKSRC}/togl.h ${WRKSRC}/pkgIndex.tcl ${TOGL_INSTDIR}
@${MKDIR} ${EXAMPLESDIR}
${INSTALL_DATA} ${WRKSRC}/Makefile ${EXAMPLESDIR}
And user can override it with WITH_TCL_VER/WITH_TK_VER or the port will
pick up already installed version. I for one use tk86.
I have verified it for functionality (as in) extract, configure, make
install only.
Before I made the mods I did not make a original copy so this is why I
did not provide a unified diff but I have bumped the the PORTREVISION
from _1 to _2 and it should be ready to be committed as this was a
pretty trivial change.
You could have used CVS, i.e.
$ cvs -d$CVSROOT co togl
make changes
$ cvs diff -up
The most significant change mentioned above was changed to:
BUILD_DEPENDS= ${NONEXISTENT}:${PORTSDIR}/lang/tcl85:configure
Well, I've tried to update the port myself but I'm yet to figure out how
to reliably determine ${WRKSRC} from lang/tcl${TCL_VER}. It's easy to do
from a slave port but togl is not one.
This was needed to provide configured values that graphics/togl would
then read.
Regards,
___
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
netgen - was Re: How to extract tcl src
Thanks for all the responses. However I have decided against performing an update of graphics/togl. I was trying to upgrade cad/netgen to 4.9.13 (an update appeared on sourceforge a while ago). This required togl, and there are some mistakes in the togl port. So I thought I might as well upgrade to togl-2.0 while I was at it. But netgen 4.9.13 requires togl 1.7. But I've even given up on the netgen port upgrade. The configure file seems to be rather poorly written, and requires many hacks. I am uncertain that even if I get it to build, that it will run properly. If someone out there really wants me to upgrade netgen, I'll give it another go. But they have to be a user of netgen, so that they can ensure that it still works properly for them. ___ 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: Users and groups kept after a port deinstallation
On 05/22/2010 21:50, Ade Lovett wrote: On May 22, 2010, at 16:39 , Anonymous wrote: Such unused entries in passwd add clutter. It in turn makes managing users more complex. You have to remember which users are created by you and which ones are created by ports. Irrespective of the UID/GID stuff mentioned elsewhere, merely go through the ports tree and add (or append) (created by ports) to the GECOS field of any such created users. I do like this idea, but with respects to such; storing when it was created and what created it like www/apache22 might be a little more useful to narrow these down. But if a port can install a user there is no reason that it can not uninstall a user via pw(8) that is available from bsd.commands.mk after checking a recorded md5(1) sum that it could create upon installation for the output of pw usershow/groupshow UID/GID. -- jhell ___ 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: Users and groups kept after a port deinstallation
RW rwmailli...@googlemail.com writes: On Sun, 23 May 2010 03:39:53 +0400 Anonymous swel...@gmail.com wrote: RW rwmailli...@googlemail.com writes: On Sat, 22 May 2010 11:42:53 -0400 jhell jh...@dataix.net wrote: This is more of a best practices case than what the implications of leaving users in the master.passwd are. Why is it best practice? Why add extra complexity to solve a problem that doesn't actually exist? Such unused entries in passwd add clutter. It in turn makes managing users more complex. You have to remember which users are created by you and which ones are created by ports. You don't have to remember, just look at the UID/GID values, ordinary users start at 1001, ports create UIDs 1000. You're presuming non-ordinary users are created only by ports framework. That's not always the case. I may want for example a separate user for telnetd to broadcast ascii movies or youterm sessions. ;) Besides, some ports do not create users by default but may use them if available, e.g. dns/dnsmasq dnsmasq user. This case is more like a bug, though. The base system alone creates 18 such users, if you have problems with this kind of thing a few stale uids are the least of your problems. So, if you change home dir of some user there may be undesireble consequences. And only then security becomes a concern because port app may be run with privilegies that are higher than intended. This appears to refer to an admin confusing a normal user with a system user that's still in use by a port, so I don't see the relevance. No. It's about conflict: system user created by admin and system user created by port happen to have same username. ___ 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
