FreeBSD Port: omake-0.9.8.1_1
Hi, Could you please update omake to the latest veraion? Thanks, ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: [PROPOSAL] Ports using SCM repositories as source instead of distfiles
* Ashish Shukla आशीष शुक्ल ([EMAIL PROTECTED]) wrote: > This is what Debian and Gentoo does. Remember we don't have to pass > DESTDIR variable to 'make -C /usr/ports/editors/emacs-cvs' instead it > will be passed to the 'gmake' process invoked by port's Makefile. If we I understand. But you're implying that there is Makefile and it supports DESTDIR. As I understand, you're referring to autotools-based ports. Remember, those are less than 1/4 of the collection. > pass DESTDIR to port's commandline, then it will install all > dependencies in that chroot which is not desired, we simply care about > the files installed by that port. Since there're already 20,000 ports we > can't do it by default, so we've to hack some knob (like > REQUIRES_DYNAMIC_INSTALLATION) which if defined will enable this > behaviour. So if I understand correctly, you're proposing to only use dynamic plist generation for the ports that support it without modification, i.e. autotools-based? My opinion is that we should support the feature for all ports, or don't support it at all. Only getting rid of ~5k pkg-plists is not a huge accomplishment considering the mess it causes and I doubt it's worth the work on adding the feature to port.mk and then rebuilding and testing all affected ports. Being able to forget about pkg-plists once and forever however would be a huge accomplishment and if that's possible it should be done sooner or later. -- Dmitry Marakasov . 55B5 0596 FF1E 8D84 5F56 9510 D35A 80DD F9D2 F77D [EMAIL PROTECTED] ..: jabber: [EMAIL PROTECTED]http://www.amdmi3.ru ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: [PROPOSAL] Ports using SCM repositories as source instead of distfiles
On Thu, Dec 11, 2008 at 12:23 AM, Dmitry Marakasov <[EMAIL PROTECTED]> wrote: > * Ashish Shukla आशीष शुक्ल ([EMAIL PROTECTED]) wrote: > >> This is what Debian and Gentoo does. Remember we don't have to pass >> DESTDIR variable to 'make -C /usr/ports/editors/emacs-cvs' instead it >> will be passed to the 'gmake' process invoked by port's Makefile. If we > > I understand. But you're implying that there is Makefile and it supports > DESTDIR. As I understand, you're referring to autotools-based ports. > Remember, those are less than 1/4 of the collection. > >> pass DESTDIR to port's commandline, then it will install all >> dependencies in that chroot which is not desired, we simply care about >> the files installed by that port. Since there're already 20,000 ports we >> can't do it by default, so we've to hack some knob (like >> REQUIRES_DYNAMIC_INSTALLATION) which if defined will enable this >> behaviour. > > So if I understand correctly, you're proposing to only use dynamic > plist generation for the ports that support it without modification, > i.e. autotools-based? > > My opinion is that we should support the feature for all ports, or don't > support it at all. Only getting rid of ~5k pkg-plists is not a huge > accomplishment considering the mess it causes and I doubt it's worth > the work on adding the feature to port.mk and then rebuilding and > testing all affected ports. Being able to forget about pkg-plists > once and forever however would be a huge accomplishment and if that's > possible it should be done sooner or later. > > -- > Dmitry Marakasov . 55B5 0596 FF1E 8D84 5F56 9510 D35A 80DD F9D2 F77D > [EMAIL PROTECTED] ..: jabber: [EMAIL PROTECTED]http://www.amdmi3.ru Agreed. I've come across many ports where folks haven't written Makefiles properly and it results in problems . Most cases you can make the following assumption: if a port can be cross-compiled, it can most likely be installed under another destination directory. The converse is not necessarily true. These are issues which should be documented in a Makefile FAQ for everyone, and this should be noted whenever an issue is found so that folks can be educated and things like this can be fixed. -Garrett ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "[EMAIL PROTECTED]"
INDEX build failed for 6.x
INDEX build failed with errors: Generating INDEX-6 - please wait..pkg_info: not found pkg_info: not found pkg_info: not found pkg_info: not found Done. make_index: phpwebgallery-1.7.2: no entry for /usr/ports/security/pecl-filter make_index: php5-extensions-1.2: no entry for /usr/ports/security/pecl-filter make_index: php5-extensions-1.2: no entry for /usr/ports/security/pecl-filter Committers on the hook: ale flz leeym Most recent CVS update was: U archivers/Makefile U archivers/pecl-zip/Makefile U archivers/php5-zip/Makefile U devel/Makefile U devel/pecl-json/Makefile U devel/php5-json/Makefile U lang/php5/Makefile U lang/php5/Makefile.ext U lang/php5/distinfo U net-p2p/rtorrent/Makefile U security/Makefile U security/pecl-hash/Makefile U security/php5-filter/Makefile U security/php5-hash/Makefile U textproc/p5-RDF-Simple/Makefile U textproc/p5-RDF-Simple/distinfo U textproc/p5-RDF-Simple/pkg-plist ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: [PROPOSAL] Ports using SCM repositories as source instead of distfiles
On Thu, Dec 11, 2008 at 10:23 AM, Dmitry Marakasov <[EMAIL PROTECTED]> wrote: > * Ashish Shukla आशीष शुक्ल ([EMAIL PROTECTED]) wrote: > >> This is what Debian and Gentoo does. Remember we don't have to pass >> DESTDIR variable to 'make -C /usr/ports/editors/emacs-cvs' instead it >> will be passed to the 'gmake' process invoked by port's Makefile. If we > > I understand. But you're implying that there is Makefile and it supports > DESTDIR. As I understand, you're referring to autotools-based ports. > Remember, those are less than 1/4 of the collection. Excuse me, but he refers not to autotools-based ports, but to ports that follows GNU Coding Standards (section "Makefile Conventions" if more preciously). Autotools just brings such support out-of-the-box. And, IMO, projects that violates these things heavy, should be fixed upstream. BTW, from my expiriense, there are little amount of project that doesn't support DESTDIR of it's analog. And many of them may be worked around anyway. -- Andrew W. Nosenko <[EMAIL PROTECTED]> ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "[EMAIL PROTECTED]"
build problem
When building ImageMagick-6.4.7-5 on FreeBSD 6.4 I have a build error: /usr/obj/home/ports/graphics/ImageMagick/work/ImageMagick-6.4.7-5/tests/.libs/co nstitute -storagetype double /usr/obj/home/ports/graphics/ImageMagick/work/Image Magick-6.4.7-5/tests/input_truecolor.miff cmy Constitute check failed: 6615/0.0587497/0.843137 FAIL: tests/constitute_double_cmy.sh -- regis ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: [PROPOSAL] Ports using SCM repositories as source instead of distfiles
* Andrew W. Nosenko ([EMAIL PROTECTED]) wrote: > > I understand. But you're implying that there is Makefile and it supports > > DESTDIR. As I understand, you're referring to autotools-based ports. > > Remember, those are less than 1/4 of the collection. > Excuse me, but he refers not to autotools-based ports, but to ports > that follows GNU Coding Standards (section "Makefile Conventions" if > more preciously). > Autotools just brings such support out-of-the-box. > And, IMO, projects that violates these things heavy, should be fixed upstream. > BTW, from my expiriense, there are little amount of project that > doesn't support DESTDIR of it's analog. And many of them may be > worked around anyway. I didn't count or check thoroughfully, but the feeling I've got from my 150+ ports is that no one actually supports it. I may be wrong though. And again, GNU Coding Standards don't cover build systems other than make. Also, it's not even a requirement: "So, we strongly recommend GNU packages support DESTDIR, though it is not an absolute requirement." I agree with that you can't require all upstream maintainers to support this feature. Architecturally this should be completely package manager's problem (i.e. upstream should only provide installation into PREFIX, and may optionally support DESTDIR, and if package manager needs features like that staged install or automatic plist generation, and upstream don't provide it, package manager should take care of it by itself. Tecnically, we may support DESTDIR in all ports. But considering the amount of work required, and increased complexety of everything as a result, I'd stick with static plists without hesitation. See http://lists.freebsd.org/pipermail/freebsd-ports/2006-August/034745.html those are some real examples of complexity and resulting confusion, from first variant of DESTDIR support in ports. Now, when we have one DESTDIR implementation, adding another will likely make some heads explode, just think of variable naming. I'll remind that what we are talking about is automatic plist generation, and I think that this can be done without any hacks like installing a port into intermediate directory before real installation just by logging all writes to the filesystem. This will require no modifications to the ports, very minor modifications to Mk, and will (in theory) work without fail whatever the port will install, also ensuring there're no runaway files (that is, files not listed in plist, or files not installed into DESTDIR for some reason). -- Dmitry Marakasov . 55B5 0596 FF1E 8D84 5F56 9510 D35A 80DD F9D2 F77D [EMAIL PROTECTED] ..: jabber: [EMAIL PROTECTED]http://www.amdmi3.ru ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "[EMAIL PROTECTED]"
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 "[EMAIL PROTECTED]"
Re: [ImageMagick] build problem
On Thu, Dec 11, 2008 at 11:48:07AM +0100, regisr wrote: > When building ImageMagick-6.4.7-5 on FreeBSD 6.4 I have a build error: > > /usr/obj/home/ports/graphics/ImageMagick/work/ImageMagick-6.4.7-5/tests/.libs/co > nstitute -storagetype > double /usr/obj/home/ports/graphics/ImageMagick/work/Image > Magick-6.4.7-5/tests/input_truecolor.miff cmy Constitute check failed: > 6615/0.0587497/0.843137 FAIL: tests/constitute_double_cmy.sh For what it's worth, I did not encounter this. Running on: FreeBSD g1-35.catwhisker.org 6.4-STABLE FreeBSD 6.4-STABLE #659: Thu Dec 11 05:01:52 PST 2008 [EMAIL PROTECTED]:/common/S1/obj/usr/src/sys/CANARY i386 I ran "portmaster -ad" and: ===>>> Upgrade of ImageMagick-6.4.5.5 to ImageMagick-6.4.7.5 succeeded Peace, david -- David H. Wolfskill [EMAIL PROTECTED] Depriving a girl or boy of an opportunity for education is evil. See http://www.catwhisker.org/~david/publickey.gpg for my public key. pgpxOfAeJmdda.pgp Description: PGP signature
Re: [PROPOSAL] Ports using SCM repositories as source instead of distfiles
Dmitry Marakasov writes:
> * Andrew W. Nosenko ([EMAIL PROTECTED]) wrote:
>> > I understand. But you're implying that there is Makefile and it supports
>> > DESTDIR. As I understand, you're referring to autotools-based ports.
>> > Remember, those are less than 1/4 of the collection.
>> Excuse me, but he refers not to autotools-based ports, but to ports
>> that follows GNU Coding Standards (section "Makefile Conventions" if
>> more preciously).
>> Autotools just brings such support out-of-the-box.
>> And, IMO, projects that violates these things heavy, should be fixed
>> upstream.
>> BTW, from my expiriense, there are little amount of project that
>> doesn't support DESTDIR of it's analog. And many of them may be
>> worked around anyway.
Yes, I meant that only.
> I didn't count or check thoroughfully, but the feeling I've got
> from my 150+ ports is that no one actually supports it. I may be
> wrong though.
> And again, GNU Coding Standards don't cover build systems other
> than make. Also, it's not even a requirement: "So, we strongly
> recommend GNU packages support DESTDIR, though it is not an absolute
> requirement."
> I agree with that you can't require all upstream maintainers to
> support this feature. Architecturally this should be completely
> package manager's problem (i.e. upstream should only provide
> installation into PREFIX, and may optionally support DESTDIR, and
> if package manager needs features like that staged install or
> automatic plist generation, and upstream don't provide it, package
> manager should take care of it by itself.
> Tecnically, we may support DESTDIR in all ports. But considering
> the amount of work required, and increased complexety of everything
> as a result, I'd stick with static plists without hesitation.
Yes, that is why I mentioned having a variable which enables this
behaviour, by default it is disabled. I mean ports which are okay
with providing static plists are fine, but ports which aren't
predictable with what files are going to installed can go with this
dynamic plist support, where ports infrastructure will only help in
generating a plist from an already setup directory tree
(/var/tmp/${portname}), now it is maintainer's responsibility to make
sure that all files will be installed in /var/tmp/${portname} which
{s,}he can do by either using 'make install DESTDIR=/var/tmp/${portname}'
or something similar if supported by port's upstream or {s,}he has to
add installation commands in ports Makefile rather than going with
upstream's way of installing things.
> See
> http://lists.freebsd.org/pipermail/freebsd-ports/2006-August/034745.html
> those are some real examples of complexity and resulting confusion,
> from first variant of DESTDIR support in ports. Now, when we have
> one DESTDIR implementation, adding another will likely make some heads
> explode, just think of variable naming.
The DESTDIR issue in above link refers to the DESTDIR support[1] present in
FreeBSD Ports system, and the one which I'm talking about has nothing to
do with that.
> I'll remind that what we are talking about is automatic plist generation,
> and I think that this can be done without any hacks like installing a
> port into intermediate directory before real installation just by
> logging all writes to the filesystem.
Yes that intermediate directory is what DESTDIR is. And if you're
capable of logging all writes in the DESTDIR, then its cool, but
remember you're also talking about installing port in an intermediate
directory. After the port gets installed in intermediate directory, the
plist can be generated with your filesystem writes logger component or a
well tested version of following simply command line:
% find /var/tmp/${PORTNAME} -type f |sed -e \
"s[/var/tmp/${PORTNAME}${PREFIX}/[[g" > plist.tmp
HTH
--
Ashish Shukla
pgpNOI51EppJr.pgp
Description: PGP signature
latest asterisk and zaptel and app meeatme
Guys,
I have the latest ports from yesterday - asterisk 1.4.22 and zaptel 1.4.11,
FreeBSD 7.1 PRE
My server uses app_meatme for our conferences.
The there is an issue with latest software. When I tried to enter in the
conference i got:
-- Executing [EMAIL PROTECTED]:1] Ringing("SIP/3004-28713000", "")
in new stack
-- Executing [EMAIL PROTECTED]:2] Wait("SIP/3004-28713000", "3")
in new stack
-- Executing [EMAIL PROTECTED]:3] MeetMe("SIP/3004-28713000",
"13003|Mpcid") in new stack
-- Created MeetMe conference 1023 for conference '13003'
-- Recording
-- Playing 'vm-rec-name' (language 'en')
-- Playing 'beep' (language 'en')
-- x=0, open writing:
/var/spool/asterisk/meetme/meetme-username-13003-1 format: sln, 0x28b3e200
-- User ended message by pressing #
-- Playing 'auth-thankyou' (language 'en')
-- Playing 'vm-review' (language 'en')
-- Playing 'vm-msgsaved' (language 'en')
-- Playing 'conf-onlyperson' (language 'en')
[Dec 11 15:52:28] WARNING[57181]: app_meetme.c:1621 conf_run: Unable to set
flags: Inappropriate ioctl for device
And the application fails
At this line there is a new fdset for ASYNC socket I commented these lines
there and now I have the application running but I am not sure this is
correct.
is there another solution?
Thanks in advance
Anatoli Marinov
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: [PROPOSAL] Ports using SCM repositories as source instead of distfiles
On Thu, 11 Dec 2008 02:23:25 -0600, Dmitry Marakasov <[EMAIL PROTECTED]> wrote: * Ashish Shukla आशीष शुक्ल ([EMAIL PROTECTED]) wrote: This is what Debian and Gentoo does. Remember we don't have to pass DESTDIR variable to 'make -C /usr/ports/editors/emacs-cvs' instead it will be passed to the 'gmake' process invoked by port's Makefile. If we I understand. But you're implying that there is Makefile and it supports DESTDIR. As I understand, you're referring to autotools-based ports. Remember, those are less than 1/4 of the collection. pass DESTDIR to port's commandline, then it will install all dependencies in that chroot which is not desired, we simply care about the files installed by that port. Since there're already 20,000 ports we can't do it by default, so we've to hack some knob (like REQUIRES_DYNAMIC_INSTALLATION) which if defined will enable this behaviour. So if I understand correctly, you're proposing to only use dynamic plist generation for the ports that support it without modification, i.e. autotools-based? My opinion is that we should support the feature for all ports, or don't support it at all. Only getting rid of ~5k pkg-plists is not a huge accomplishment considering the mess it causes and I doubt it's worth the work on adding the feature to port.mk and then rebuilding and testing all affected ports. Being able to forget about pkg-plists once and forever however would be a huge accomplishment and if that's possible it should be done sooner or later. I object on get rid of pkg-plist. I depend on pkg-plist too much. I think it's important for us to keep on track where the files/directories are. Cheers, Mezz -- [EMAIL PROTECTED] - [EMAIL PROTECTED] FreeBSD GNOME Team http://www.FreeBSD.org/gnome/ - [EMAIL PROTECTED] ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "[EMAIL PROTECTED]"
FreeBSD Port: zaptel-1.4.11
Hello, I recently installed the new version of zaptel-bsd (1.4.11), and noticed that the module wcfxo no longer exists. Is there a way to set up a card X100P Clone with this version of zaptel? I'm using FreeBSD 7.0 Thank you very much, Rodrigo Müller ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "[EMAIL PROTECTED]"
net/asterisk: b2bua.org down, patch fails
Tried to upgrade asterisk today: ===> Found saved configuration for asterisk-1.4.22 => asterisk-1.4.22-codec-negotiation-20081110.diff.gz doesn't seem to exist in /usr/ports/distfiles/. => Attempting to fetch from http://b2bua.org/chrome/site/. fetch: http://b2bua.org/chrome/site/asterisk-1.4.22-codec-negotiation-20081110.diff.gz: Internal Server Error => Attempting to fetch from ftp://ftp.FreeBSD.org/pub/FreeBSD/ports/distfiles/. fetch: ftp://ftp.FreeBSD.org/pub/FreeBSD/ports/distfiles/asterisk-1.4.22-codec-negotiation-20081110.diff.gz: File unavailable (e.g., file not found, no access) => Couldn't fetch it - please try to retrieve this => port manually into /usr/ports/distfiles/ and try again. Then with codec-negotiation patch turned off: ===> Found saved configuration for asterisk-1.4.22 ===> Extracting for asterisk-1.4.22 => MD5 Checksum OK for asterisk-1.4.22.tar.gz. => SHA256 Checksum OK for asterisk-1.4.22.tar.gz. /bin/mkdir -p /usr/ports/net/asterisk/work/asterisk-1.4.22/codecs/ilbc /usr/bin/find /usr/ports/net/asterisk/work/asterisk-1.4.22 -name '*.d' -delete ===> Patching for asterisk-1.4.22 ===> Applying extra patch /usr/ports/net/asterisk/files/nocodecnego-patch-Makefile ===> Applying extra patch /usr/ports/net/asterisk/files/dtmf_debug.diff ===> Applying extra patch /usr/ports/net/asterisk/files/feature_disconnect.diff ===> Applying extra patch /usr/ports/net/asterisk/files/sip_force_callid.diff ===> Applying extra patch /usr/ports/net/asterisk/files/sip_set_auth.diff ===> Applying extra patch /usr/ports/net/asterisk/files/rtp_force_dtmf-nocodecnego.diff 1 out of 1 hunks failed--saving rejects to configs/sip.conf.sample.rej Looks like the sip.conf.sample changed in the slightest of ways: -; See doc/README.tos for a description of these parameters. +; See doc/ip-tos.txt for a description of these parameters. Even then, it doesn't compile... cc -o chan_dahdi.o -c chan_dahdi.c -D_THREAD_SAFE -pthread -I/usr/ports/net/asterisk/work/asterisk-1.4.22/include -O2 -fno-strict-aliasing -pipe -pipe -Wall -Wstrict-prototypes -Wmissing-prototypes -Wmissing-declarations -g3 -include /usr/ports/net/asterisk/work/asterisk-1.4.22/include/asterisk/autoconfig.h -I/usr/local/include -fPIC -DAST_MODULE=\"chan_dahdi\" -MD -MT chan_dahdi.o -MF .chan_dahdi.o.d -MP chan_dahdi.c: In function `get_alarms': chan_dahdi.c:3693: error: structure has no member named `chan_alarms' gmake[1]: *** [chan_dahdi.o] Error 1 gmake[1]: Leaving directory `/usr/ports/net/asterisk/work/asterisk-1.4.22/channels' gmake: *** [channels] Error 2 --- Peter Beckman Internet Guy beck...@angryox.com http://www.angryox.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"
net/asterisk: b2bua.org down, patch fails
Tried to upgrade asterisk today: ===> Found saved configuration for asterisk-1.4.22 => asterisk-1.4.22-codec-negotiation-20081110.diff.gz doesn't seem to exist in /usr/ports/distfiles/. => Attempting to fetch from http://b2bua.org/chrome/site/. fetch: http://b2bua.org/chrome/site/asterisk-1.4.22-codec-negotiation-20081110.diff.gz: Internal Server Error => Attempting to fetch from ftp://ftp.FreeBSD.org/pub/FreeBSD/ports/distfiles/. fetch: ftp://ftp.FreeBSD.org/pub/FreeBSD/ports/distfiles/asterisk-1.4.22-codec-negotiation-20081110.diff.gz: File unavailable (e.g., file not found, no access) => Couldn't fetch it - please try to retrieve this => port manually into /usr/ports/distfiles/ and try again. Then with codec-negotiation patch turned off: ===> Found saved configuration for asterisk-1.4.22 ===> Extracting for asterisk-1.4.22 => MD5 Checksum OK for asterisk-1.4.22.tar.gz. => SHA256 Checksum OK for asterisk-1.4.22.tar.gz. /bin/mkdir -p /usr/ports/net/asterisk/work/asterisk-1.4.22/codecs/ilbc /usr/bin/find /usr/ports/net/asterisk/work/asterisk-1.4.22 -name '*.d' -delete ===> Patching for asterisk-1.4.22 ===> Applying extra patch /usr/ports/net/asterisk/files/nocodecnego-patch-Makefile ===> Applying extra patch /usr/ports/net/asterisk/files/dtmf_debug.diff ===> Applying extra patch /usr/ports/net/asterisk/files/feature_disconnect.diff ===> Applying extra patch /usr/ports/net/asterisk/files/sip_force_callid.diff ===> Applying extra patch /usr/ports/net/asterisk/files/sip_set_auth.diff ===> Applying extra patch /usr/ports/net/asterisk/files/rtp_force_dtmf-nocodecnego.diff 1 out of 1 hunks failed--saving rejects to configs/sip.conf.sample.rej Looks like the sip.conf.sample changed in the slightest of ways: -; See doc/README.tos for a description of these parameters. +; See doc/ip-tos.txt for a description of these parameters. Even then, it doesn't compile... cc -o chan_dahdi.o -c chan_dahdi.c -D_THREAD_SAFE -pthread -I/usr/ports/net/asterisk/work/asterisk-1.4.22/include -O2 -fno-strict-aliasing -pipe -pipe -Wall -Wstrict-prototypes -Wmissing-prototypes -Wmissing-declarations -g3 -include /usr/ports/net/asterisk/work/asterisk-1.4.22/include/asterisk/autoconfig.h -I/usr/local/include -fPIC -DAST_MODULE=\"chan_dahdi\" -MD -MT chan_dahdi.o -MF .chan_dahdi.o.d -MP chan_dahdi.c: In function `get_alarms': chan_dahdi.c:3693: error: structure has no member named `chan_alarms' gmake[1]: *** [chan_dahdi.o] Error 1 gmake[1]: Leaving directory `/usr/ports/net/asterisk/work/asterisk-1.4.22/channels' gmake: *** [channels] Error 2 --- Peter Beckman Internet Guy beck...@angryox.com http://www.angryox.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"
Re: Proposal: mechanism for local patches
In message <20081203131234.gd70...@hades.panopticon>, Dmitry Marakasov (amd...@amdmi3.ru) wrote: > * G. Paul Ziemba (pz-freebsd-po...@ziemba.us) wrote: [...] > > > 2. I'm not sure we need the test for *.orig|*.rej|*~|*,v, but it > >wouldn't hurt. Maybe it helps admins who are actively developing > >local patches. I see that it's in the existing do-patch code above. > > I suppose that check was done to help to detect patching failures, so it > may be removed. I've just been trying out your patch and I think from an organisational point of view it is very good. What I mean by this is that with the patch I am now able to keep my local patches completely separate from the official, FreeBSD patches. No more backing up the whole of /usr/ports just in case I have a private patch in there somewhere. Now I just need to backup /usr/ports.localpatchdir (which is what I called the directory LOCAPATCHDIR points to). However, please consider putting back in the test for *.orig and *~ files. That way one can be actively be hacking on a patch without having to keep deleting editor backup files, which you may not wish to delete anyway, before attempting another build. In my case I see no need to skip *.rej and *,v files, but others may have a need for them. I hope some form of your patch gets into the tree once 7.1 ships. Cheers, Nick. -- ___ 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"
FreeBSD Port: apache-2.2.9_5
Greetings, I would like to report that apache-2.2.9 port doesn't include usr/local/etc/rc.d/* into a binary package. I am doing this in RELENG_7 using 'make package-recursive'. Thanks. ___ 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"
portupgrade and freebsd-update: A better way?
So I took on binary upgrading one of my FreeBSD servers today from 6.2-RELEASE to 7.0-RELEASE. Many useful sites outline exactly how to do this right, and they are mostly useful. Except when it comes to ports. http://www.daemonology.net/blog/2007-11-11-freebsd-major-version-upgrade.html http://www.cyberciti.biz/faq/howto-freebsd-server-upgrades/ You get a few production servers with 200+ ports installed, and upgrading could take several days and lots of headaches and a lot of babysitting. Is there some sort of automated way that someone smart has figured out how to determine which ports are actually affected by the upgrade, so I only have to upgrade a hopefully small subset of installed ports? Are ALL the libraries upgraded during the OS upgrade modified in a way that breaks ALL existing ports? My gut says no, but my brain says it's not trivial to match the two together to limit the number of times you have to rebuild a port. Is there a better way? Does portsnap or portmanager or portupgrade keep track? What have I missed? Beckman --- Peter Beckman Internet Guy beck...@angryox.com http://www.angryox.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"
Re: portupgrade and freebsd-update: A better way?
On Thu, Dec 11, 2008 at 7:13 PM, Peter Beckman wrote: > So I took on binary upgrading one of my FreeBSD servers today from > 6.2-RELEASE to 7.0-RELEASE. Many useful sites outline exactly how to do > this right, and they are mostly useful. > > Except when it comes to ports. > > > http://www.daemonology.net/blog/2007-11-11-freebsd-major-version-upgrade.html >http://www.cyberciti.biz/faq/howto-freebsd-server-upgrades/ > > You get a few production servers with 200+ ports installed, and upgrading > could take several days and lots of headaches and a lot of babysitting. > > Is there some sort of automated way that someone smart has figured out how > to determine which ports are actually affected by the upgrade, so I only > have to upgrade a hopefully small subset of installed ports? Are ALL the > libraries upgraded during the OS upgrade modified in a way that breaks ALL > existing ports? My gut says no, but my brain says it's not trivial to > match the two together to limit the number of times you have to rebuild a > port. > > Is there a better way? Does portsnap or portmanager or portupgrade keep > track? What have I missed? > > Beckman 7.x and 6.2 aren't ABI compatible, so unfortunately no, you have to babysit a bit. -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: portupgrade and freebsd-update: A better way?
On 12/11/08, Peter Beckman wrote: > So I took on binary upgrading one of my FreeBSD servers today from > 6.2-RELEASE to 7.0-RELEASE. Many useful sites outline exactly how to do > this right, and they are mostly useful. > > Except when it comes to ports. > > > http://www.daemonology.net/blog/2007-11-11-freebsd-major-version-upgrade.html > > http://www.cyberciti.biz/faq/howto-freebsd-server-upgrades/ > > You get a few production servers with 200+ ports installed, and upgrading > could take several days and lots of headaches and a lot of babysitting. > > Is there some sort of automated way that someone smart has figured out how > to determine which ports are actually affected by the upgrade, so I only > have to upgrade a hopefully small subset of installed ports? Are ALL the > libraries upgraded during the OS upgrade modified in a way that breaks ALL > existing ports? My gut says no, but my brain says it's not trivial to > match the two together to limit the number of times you have to rebuild a > port. > > Is there a better way? Does portsnap or portmanager or portupgrade keep > track? What have I missed? > If you have the compat6x port installed, you will not need to upgrade any of the 200+ ports on those productions servers. If you upgrade one port, you'll then need to upgrade all of it dependencies, as well as the ports that depend on these dependencies. To minimize your down time, you should set up a port build server that will build these 200+ ports as packages. On the production systems, you would use portupgrade to install the pre-built packages Scot ___ 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: portupgrade and freebsd-update: A better way?
On Thu, Dec 11, 2008 at 10:25 PM, Scot Hetzel wrote: > On 12/11/08, Peter Beckman wrote: >> So I took on binary upgrading one of my FreeBSD servers today from >> 6.2-RELEASE to 7.0-RELEASE. Many useful sites outline exactly how to do >> this right, and they are mostly useful. >> >> Except when it comes to ports. >> >> >> http://www.daemonology.net/blog/2007-11-11-freebsd-major-version-upgrade.html >> >> http://www.cyberciti.biz/faq/howto-freebsd-server-upgrades/ >> >> You get a few production servers with 200+ ports installed, and upgrading >> could take several days and lots of headaches and a lot of babysitting. >> >> Is there some sort of automated way that someone smart has figured out how >> to determine which ports are actually affected by the upgrade, so I only >> have to upgrade a hopefully small subset of installed ports? Are ALL the >> libraries upgraded during the OS upgrade modified in a way that breaks ALL >> existing ports? My gut says no, but my brain says it's not trivial to >> match the two together to limit the number of times you have to rebuild a >> port. >> >> Is there a better way? Does portsnap or portmanager or portupgrade keep >> track? What have I missed? >> > If you have the compat6x port installed, you will not need to upgrade > any of the 200+ ports on those productions servers. > > If you upgrade one port, you'll then need to upgrade all of it > dependencies, as well as the ports that depend on these dependencies. > > To minimize your down time, you should set up a port build server that > will build these 200+ ports as packages. On the production systems, > you would use portupgrade to install the pre-built packages > > Scot True... forgot about compat6x. -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"
