[HEADSUP] Qt 4.5 and KDE 4.3
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Few peoples saw that i've copied KDE 4.2 to branches/KDE_4_2 in area51. With this move we start working on KDE 4.3 BETA1. Qt 4.5 is now default in area51 which we need as dependency for KDE 4.3 :-) Please do not ping us about any problems at the moment. We are working to get this buildable and are fixing dependencies. We'll let you know when you can start testing. Thanks Martin - -- +---+---+ | PGP: 0xB1E6FCE9 | Jabber : miwi(at)BSDCrew.de | | ICQ: 169139903 | Mail : miwi(at)FreeBSD.org | +---+---+ | Mess with the Best, Die like the Rest! | +---+---+ -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.11 (FreeBSD) iEYEARECAAYFAkoGsiwACgkQdLJIhLHm/Om76ACghQEm4ZUAAKTqXRwXxm1IkgmN Z+MAoLWEcFTzz4V4fzmDLkLWAphljCsp =2Wh4 -END PGP SIGNATURE- ___ 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/net Makefile ports/net/bwi-firmware-kmod Makefile distinfo pkg-descr pkg-plist
The Restless Daemon identified a mtree error while trying to build: bwi-firmware-kmod-3.130.20 maintained by po...@freebsd.org Makefile ident: $FreeBSD: ports/net/bwi-firmware-kmod/Makefile,v 1.1 2009/05/09 21:41:50 imp Exp $ Excerpt from http://QAT.TecNik93.com/logs/7-STABLE-FPT-NPD/bwi-firmware-kmod-3.130.20.log : a0g1bsinitvals5.fw a0g1bsinitvals5.fw a0g1initvals5.fw a0g1initvals5.fw b0g0bsinitvals2.fw b0g0bsinitvals2.fw b0g0bsinitvals5.fw b0g0bsinitvals5.fw b0g0initvals2.fw b0g0initvals2.fw b0g0initvals5.fw b0g0initvals5.fw pcm4.fw pcm4.fw pcm5.fw pcm5.fw awk -f @/tools/fw_stub.awk ucode.fw:bwi_v3_ucode ucode11.fw:bwi_v3_ucode11 ucode2.fw:bwi_v3_ucode2 ucode4.fw:bwi_v3_ucode4 ucode5.fw:bwi_v3_ucode5 a0g0bsinitvals2.fw:bwi_v3_a0g0bsinitvals2 a0g0bsinitvals5.fw:bwi_v3_a0g0bsinitvals5 a0g0initvals2.fw:bwi_v3_a0g0initvals2 a0g0initvals5.fw:bwi_v3_a0g0initvals5 a0g1bsinitvals5.fw:bwi_v3_a0g1bsinitvals5 a0g1initvals5.fw:bwi_v3_a0g1initvals5 b0g0bsinitvals2.fw:bwi_v3_b0g0bsinitvals2 b0g0bsinitvals5.fw:bwi_v3_b0g0bsinitvals5 b0g0initvals2.fw:bwi_v3_b0g0initvals2 b0g0initvals5.fw:bwi_v3_b0g0initvals5 pcm4.fw:bwi_v3_pcm4 pcm5.fw:bwi_v3_pcm5 -mbwi_v3_ucode -cbwi_v3_ucode.c cc -O2 -fno-strict-aliasing -pipe -D_KERNEL -DKLD_MODULE -std=c99 -nostdinc -I. -I@ -I@/contrib/altq -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-common -fno-omit-frame-pointer -mcmodel=kernel -mno-red-zone -mfpmath=387 -mno-sse -mno-sse2 -mno-mmx -mno-3dnow -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -c bwi_v3_ucode.c ld -d -warn-common -r -d -o bwi_v3_ucode.ko ucode.fw.fwo ucode11.fw.fwo ucode2.fw.fwo ucode4.fw.fwo ucode5.fw.fwo a0g0bsinitvals2.fw.fwo a0g0bsinitvals5.fw.fwo a0g0initvals2.fw.fwo a0g0initvals5.fw.fwo a0g1bsinitvals5.fw.fwo a0g1initvals5.fw.fwo b0g0bsinitvals2.fw.fwo b0g0bsinitvals5.fw.fwo b0g0initvals2.fw.fwo b0g0initvals5.fw.fwo pcm4.fw.fwo pcm5.fw.fwo bwi_v3_ucode.o :> export_syms awk -f /sys/conf/kmod_syms.awk bwi_v3_ucode.ko export_syms | xargs -J% objcopy % bwi_v3_ucode.ko objcopy --strip-debug bwi_v3_ucode.ko make: don't know how to make regression-test(continuing) add_pkg ===> Installing for bwi-firmware-kmod-3.130.20 ===> Generating temporary packing list ===> Checking if net/bwi-firmware-kmod already installed install -o root -g wheel -m 555 bwi_v3_ucode.ko /boot/modules kldxref /boot/modules ===> Registering installation for bwi-firmware-kmod-3.130.20 ===> Building package for bwi-firmware-kmod-3.130.20 Creating package /tmp/packages/All/bwi-firmware-kmod-3.130.20.tbz Registering depends:. Creating bzip'd tar ball in '/tmp/packages/All/bwi-firmware-kmod-3.130.20.tbz' Deleting bwi-firmware-kmod-3.130.20 === Checking filesystem state list of extra files and directories in / (not present before this port was installed but present after it was deinstalled) 330678874 -rw-r--r--1 root wheel 88 May 10 16:20 boot/modules/linker.hints build of /usr/ports/net/bwi-firmware-kmod ended at Sun May 10 16:20:00 UTC 2009 The tarballed WRKDIR can be found here: http://QAT.TecNik93.com/wrkdirs/7-STABLE-FPT-NPD/bwi-firmware-kmod-3.130.20.tbz PortsMon page for the port: http://portsmon.freebsd.org/portoverview.py?category=net&portname=bwi-firmware-kmod The build which triggered this BotMail was done under tinderbox-devel-3.2_2; dsversion: 3.2 on RELENG_7 on amd64, kern.smp.cpus: 4 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"
[RFC] NO_INSTALL in meta-ports considered harmful
Some metaports (like print/cups) use NO_INSTALL. This will prevent such port from registering its installation in /var/db/ pkg, which is different behaviour from installing it from prebuilt package (where it registers just fine). IMHO not registering installation makes no sense and serves only to confuse users (I've installed cups yet pkg_info claims I didn't!) and causes unnecessary differences between software installed from ports vs pkgs, which may lead to other unexpected problems (like missing RUN_DEPENDS). Thus I advocate for more uniform handling of ports and packages by treating it as a bug and replacing any such use of NO_INSTALL with empty do-install target. Maybe even add a note to Porter's Handbook (though I see no reference to NO_INSTALL there). If anyone has some insightfull comments why NO_INSTALL is not evil then I'm all ears. ___ 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: [RFC] NO_INSTALL in meta-ports considered harmful
On Sun, May 10, 2009 at 1:01 PM, Marcin Wisnicki wrote: > Some metaports (like print/cups) use NO_INSTALL. > > This will prevent such port from registering its installation in /var/db/ > pkg, which is different behaviour from installing it from prebuilt > package (where it registers just fine). > > IMHO not registering installation makes no sense and serves only to > confuse users (I've installed cups yet pkg_info claims I didn't!) and > causes unnecessary differences between software installed from ports vs > pkgs, which may lead to other unexpected problems (like missing > RUN_DEPENDS). > > Thus I advocate for more uniform handling of ports and packages by > treating it as a bug and replacing any such use of NO_INSTALL with empty > do-install target. Maybe even add a note to Porter's Handbook (though I > see no reference to NO_INSTALL there). > > If anyone has some insightfull comments why NO_INSTALL is not evil then > I'm all ears. > I'm not sure if this is the 'right answer', but NO_INSTALL allows the proper installation of numerous ports from one location (the meta-port). An example of this is the misc/instant-server port (though unmaintained, IIRC). If you remove the NO_INSTALL line from the Makefile, 'make' thinks misc/instant-server should be installed, rather than the collection of ports it is intended to install. Again, this is my interpretation of it. If I'm wrong, I gladly accept corrections to my thinking. :) -- Glen Barber ___ 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: [RFC] NO_INSTALL in meta-ports considered harmful
On Sun, 10 May 2009 13:08:56 -0400, Glen Barber wrote: > I'm not sure if this is the 'right answer', but NO_INSTALL allows the > proper installation of numerous ports from one location (the meta-port). > An example of this is the misc/instant-server port (though > unmaintained, IIRC). > > If you remove the NO_INSTALL line from the Makefile, 'make' thinks > misc/instant-server should be installed, rather than the collection of > ports it is intended to install. They will be installed since they are run dependencies. > > Again, this is my interpretation of it. If I'm wrong, I gladly accept > corrections to my thinking. :) ___ 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: [RFC] NO_INSTALL in meta-ports considered harmful
On Sun, May 10, 2009 at 2:51 PM, Marcin Wisnicki wrote: > On Sun, 10 May 2009 13:08:56 -0400, Glen Barber wrote: > >> I'm not sure if this is the 'right answer', but NO_INSTALL allows the >> proper installation of numerous ports from one location (the meta-port). >> An example of this is the misc/instant-server port (though >> unmaintained, IIRC). >> >> If you remove the NO_INSTALL line from the Makefile, 'make' thinks >> misc/instant-server should be installed, rather than the collection of >> ports it is intended to install. > > They will be installed since they are run dependencies. > >From what I can tell (from several metaports) -- they, themselves, are not installed. The ports defined in the metaport are installed. There is no source code for, using your example, CUPS[1]. CUPS (in the FreeBSD ports tree) is, for lack of a better explanation, a pointer to which specific ports you need to have in order to get a fully operation CUPS system running. Looking at the Makefile for print/cups [2] you can see the dependencies and that CUPS is not actually built (which in definition is what makes this a metaport). [1] http://www.freebsd.org/cgi/pds.cgi?ports/print/cups [2] http://www.freebsd.org/cgi/cvsweb.cgi/ports/print/cups/Makefile?rev=1.43 -- Glen Barber ___ 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/net Makefile ports/net/bwi-firmware-kmod Makefile distinfo pkg-descr pkg-plist
On Sun, May 10, 2009 at 11:20 AM, wrote: > > > add_pkg > ===> Installing for bwi-firmware-kmod-3.130.20 > ===> Generating temporary packing list > ===> Checking if net/bwi-firmware-kmod already installed > install -o root -g wheel -m 555 bwi_v3_ucode.ko /boot/modules > kldxref /boot/modules > ===> Registering installation for bwi-firmware-kmod-3.130.20 > > > ===> Building package for bwi-firmware-kmod-3.130.20 > Creating package /tmp/packages/All/bwi-firmware-kmod-3.130.20.tbz > Registering depends:. > Creating bzip'd tar ball in '/tmp/packages/All/bwi-firmware-kmod-3.130.20.tbz' > Deleting bwi-firmware-kmod-3.130.20 > > > === Checking filesystem state > list of extra files and directories in / (not present before this port was > installed but present after it was deinstalled) > 33067887 4 -rw-r--r-- 1 root wheel 88 > May 10 16:20 boot/modules/linker.hints > This shouldn't be flaged as an mtree error. The reason that linker.hints was left behind is due to this file is generated by kldxref. The port/package runs kldxref during the install of the firmware module to update the existing or create a linker.hints file, and when the package is removed, it runs kldxref again to clean up the linker.hints file to only contain the modules in /boot/modules. It has no way to know if it is safe to remove this file. Should Kernel Modules be running kldxref in /boot/modules? Should I change the port to have a do-install target that installs the bwi firmware kernel module so that it doesn't run kldxref during the install? 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: cvs commit: ports/net Makefile ports/net/bwi-firmware-kmod Makefile distinfo pkg-descr pkg-plist
On Sun, 10 May 2009 15:05:17 -0500 Scot Hetzel wrote: > On Sun, May 10, 2009 at 11:20 AM, wrote: > > > > > > add_pkg > > ===> Installing for bwi-firmware-kmod-3.130.20 > > ===> Generating temporary packing list > > ===> Checking if net/bwi-firmware-kmod already installed > > install -o root -g wheel -m 555 bwi_v3_ucode.ko /boot/modules > > kldxref /boot/modules > > ===> Registering installation for bwi-firmware-kmod-3.130.20 > > > > > > ===> Building package for bwi-firmware-kmod-3.130.20 > > Creating package /tmp/packages/All/bwi-firmware-kmod-3.130.20.tbz > > Registering depends:. > > Creating bzip'd tar ball in > > '/tmp/packages/All/bwi-firmware-kmod-3.130.20.tbz' Deleting > > bwi-firmware-kmod-3.130.20 > > > > > > === Checking filesystem state > > list of extra files and directories in / (not present before this > > port was installed but present after it was deinstalled) 33067887 > > 4 -rw-r--r-- 1 root wheel 88 > > May 10 16:20 boot/modules/linker.hints > > > > This shouldn't be flaged as an mtree error. The reason that > linker.hints was left behind is due to this file is generated by > kldxref. The port/package runs kldxref during the install of the > firmware module to update the existing or create a linker.hints file, > and when the package is removed, it runs kldxref again to clean up the > linker.hints file to only contain the modules in /boot/modules. It > has no way to know if it is safe to remove this file. > > Should Kernel Modules be running kldxref in /boot/modules? > > Should I change the port to have a do-install target that installs the > bwi firmware kernel module so that it doesn't run kldxref during the > install? No, I don't think so; we should teach tindy to ignore this file. -- IOnut - Un^d^dregistered ;) FreeBSD "user" "Intellectual Property" is nowhere near as valuable as "Intellect" FreeBSD committer -> ite...@freebsd.org, PGP Key ID 057E9F8B493A297B signature.asc Description: PGP signature
Re: [RFC] NO_INSTALL in meta-ports considered harmful
On Sun, 10 May 2009 15:22:04 -0400, Glen Barber wrote: > On Sun, May 10, 2009 at 2:51 PM, Marcin Wisnicki > wrote: >> They will be installed since they are run dependencies. >> >>From what I can tell (from several metaports) -- they, themselves, are > not installed. The ports defined in the metaport are installed. That's the point. The metaports should be installed as well (reasons given in my original mail). > There is no source code for, using your example, CUPS[1]. CUPS (in the > FreeBSD ports tree) is, for lack of a better explanation, a pointer to > which specific ports you need to have in order to get a fully operation > CUPS system running. Looking at the Makefile for print/cups [2] you can > see the dependencies and that CUPS is not actually built (which in > definition is what makes this a metaport). I know this. The proper way to make a metaport is to: 1. use only RUN_DEPENDS 2. set NO_BUILD 3. do *NOT* set NO_INSTALL 4. provide empty do-install target There are several metaports that get it right, like for example x11/gnome2: http://www.freebsd.org/cgi/cvsweb.cgi/ports/x11/gnome2/Makefile?rev=1.155 ___ 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"
INDEX now builds successfully on 7.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: cvs commit: ports/net Makefile ports/net/bwi-firmware-kmod Makefile distinfo pkg-descr pkg-plist
In message: <790a9fff0905101305l70d7809cl1ca2525729d53...@mail.gmail.com> Scot Hetzel writes: : On Sun, May 10, 2009 at 11:20 AM, wrote: : > : > : > add_pkg : > ===> Installing for bwi-firmware-kmod-3.130.20 : > ===> Generating temporary packing list : > ===> Checking if net/bwi-firmware-kmod already installed : > install -o root -g wheel -m 555 bwi_v3_ucode.ko /boot/modules : > kldxref /boot/modules : > ===> Registering installation for bwi-firmware-kmod-3.130.20 : > : > : > ===> Building package for bwi-firmware-kmod-3.130.20 : > Creating package /tmp/packages/All/bwi-firmware-kmod-3.130.20.tbz : > Registering depends:. : > Creating bzip'd tar ball in '/tmp/packages/All/bwi-firmware-kmod-3.130.20.tbz' : > Deleting bwi-firmware-kmod-3.130.20 : > : > : > === Checking filesystem state : > list of extra files and directories in / (not present before this port was installed but present after it was deinstalled) : > 33067887 4 -rw-r--r-- 1 root wheel 88 May 10 16:20 boot/modules/linker.hints : > : : This shouldn't be flaged as an mtree error. The reason that : linker.hints was left behind is due to this file is generated by : kldxref. The port/package runs kldxref during the install of the : firmware module to update the existing or create a linker.hints file, : and when the package is removed, it runs kldxref again to clean up the : linker.hints file to only contain the modules in /boot/modules. It : has no way to know if it is safe to remove this file. : : Should Kernel Modules be running kldxref in /boot/modules? I think so. In general, one needs to run it for optimal performance. : Should I change the port to have a do-install target that installs the : bwi firmware kernel module so that it doesn't run kldxref during the : install? What do other firmware ports do here? Warner ___ 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: OpenNMS 1.6.2 port
Port updated to v1.6.4 http://www.geeklan.co.uk/?p=132 http://www.geeklan.co.uk/files/opennms/opennms-164-freebsd-port.tgz Sevan / Venture37 ___ 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"
