Re: Unable to configure dirmngr after openldap upgrade
On Mon, Mar 28, 2011 at 04:44:25PM -0700, Xin LI wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 03/28/11 16:30, Doug Barton wrote: On 03/28/2011 14:20, Xin LI wrote: On 03/28/11 13:57, Doug Barton wrote: On 03/28/2011 13:48, Xin LI wrote: On 03/28/11 12:42, Kevin Oberman wrote: Yup. openldap-client-2.4.24 does fine. Looks like a bug in 2.4.25. I'll take a look at CHANGES and see if I can figure out what broke the inclusion of fetch(3) support if I get a bit of time. It seems that libldif now referenced the fetch support, and ironically it seem be a bug but a feature :( I have decided to disable FETCH support from now on, since it's likely to bring more problems. (If you would prefer to fix the problem for this specific problem, I think adding a '-lfetch' would be sufficient; but, it seems to be undesirable to depend fetch(3) unconditionally for all programs that uses openldap). I know next to nothing about how the openldap-client stuff works, so I'm sorry if these questions are silly. :) The biggest question is, does dirmngr compile after your change? The other question is that the only reason I have openldap installed at all is so that gnupg can use it to fetch keys from ldap keyservers. Will this still work when the FETCH option is no longer present? hmm... how do I test fetching from an ldap keyserver? I'll save you the trouble. :) I got your latest update and tested both scenarios myself, and the answer is that they both work. So now the question is, should the FETCH OPTION be removed altogether? I imagine that a lot of users will be at least as confused as I, and word is that PRs for other ports are already showing up. I think that's being used in some ldap utilities so it might broke some applications that makes use of that? I'll add a note in UPDATING to document this. I did not verified it, but suspect that libldap.so linking line missed -lfetch. Note, that I mean the libldap.so linking, and not linking of the utilities depended on libldap. pgpDrJ0VLZI26.pgp Description: PGP signature
Alpha/AXP ports
I recently happened to notice that lang/compaq-cc is still present in the ports tree, although it's only for alpha. It can presumably be deleted. That triggered me to have a closer look through the ports tree. Whilst there aren't any other alpha-only ports, there are a number of other ports that mention alpha in ONLY_FOR_ARCHS or in conditional make code. A complete list follows. How should this be handled? It seems silly to submit a massive number of PRs. archivers/paq b...@freebsd.org audio/cheesetracker po...@freebsd.org audio/gqradio stefan.j...@nemesis-sektor.de audio/linux-mbrola po...@freebsd.org audio/xsidplay po...@freebsd.org audio/zinf po...@freebsd.org biology/dna-qc po...@freebsd.org biology/platon po...@freebsd.org cad/chipmunkpo...@freebsd.org databases/metakit m...@freebsd.org devel/allegro cyberb...@cyberbotx.com devel/asl po...@freebsd.org devel/directfb anatoly.boro...@gmail.com devel/gdb53-act j...@johnrshannon.com (%) devel/judy s...@freebsd.org devel/ossp-ex po...@freebsd.org devel/ossp-var m...@freebsd.org devel/qmake m...@aldan.algebra.com devel/qmake4k...@freebsd.org devel/stli...@freebsd.org emulators/generator po...@freebsd.org emulators/ia64sim po...@freebsd.org emulators/twin po...@freebsd.org (%) finance/quantlibdiks...@sfc.wide.ad.jp games/adgalig...@freebsd.org games/digger-vglpo...@freebsd.org (#) games/exmarspo...@freebsd.org games/freesci po...@freebsd.org games/quakeforgeda...@freebsd.org graphics/alepo...@freebsd.org graphics/ayam g...@freebsd.org graphics/gtkdps din...@freebsd.org lang/TenDRA po...@freebsd.org lang/compaq-cc po...@freebsd.org (*) lang/ezm3 po...@freebsd.org lang/mpdkai...@gmail.com lang/pnetlibsyl...@freebsd.org lang/python24 pyt...@freebsd.org lang/python25 pyt...@freebsd.org lang/python26 pyt...@freebsd.org lang/python27 pyt...@freebsd.org lang/sml-nj-devel joem...@beefree.free.de lang/sr po...@freebsd.org lang/swi-pl g.gon...@ieee.org lang/tccdin...@freebsd.org (#) mail/lmtp2nntp v...@freebsd.org mail/mutt udo.schweig...@siemens.com mail/scmail po...@freebsd.org math/GiNaC step...@missouri.edu math/PDLp...@freebsd.org math/algae po...@freebsd.org math/gotoblas m...@freebsd.org misc/compat4x po...@freebsd.org misc/compat5x po...@freebsd.org misc/compat5x po...@freebsd.org misc/compat6x m...@freebsd.org misc/localedata po...@freebsd.org multimedia/bsdbktr_tvtune mina.webs...@naguib.ca multimedia/camserv po...@freebsd.org multimedia/fxtv po...@freebsd.org multimedia/libmpeg2 multime...@freebsd.org multimedia/vcdgear po...@freebsd.org multimedia/xawtvoli...@freebsd.org net/click po...@freebsd.org net/cvsup po...@freebsd.org ($) net/mDNSResponder sunp...@freebsd.org science/flounderpo...@freebsd.org science/hdf po...@freebsd.org security/john da...@freebsd.org security/p5-Net-SinFP s...@freebsd.org security/pgppo...@freebsd.org sysutils/gpart mand...@freebsd.org (%) sysutils/screen c...@freebsd.org textproc/docbook-to-man po...@freebsd.org textproc/opensched po...@freebsd.org textproc/xalan-cpo...@freebsd.org textproc/xerces-c2 po...@freebsd.org textproc/xerces-c2-develjanos.moha...@bsd.hu www/kannel po...@freebsd.org www/osb-nrcore po...@freebsd.org (%) www/wiliki po...@freebsd.org x11-clocks/glclock po...@freebsd.org x11-servers/xorg-server x...@freebsd.org x11-toolkits/9libs po...@freebsd.org x11-toolkits/Xaw3d din...@freebsd.org x11-toolkits/fox17 g...@freebsd.org x11-toolkits/v po...@freebsd.org x11/mgapdeskpo...@freebsd.org x11/xorgx...@freebsd.org (*) Only supported on Alpha (#) Alpha mentioned in comment only (%) Already deprecated -- Peter Jeremy pgpPilSvKHEwy.pgp Description: PGP signature
ports/graphics/netpbm out of date
Hi, Both graphics/netpbm and graphics/netpbm-devel are *WAY* out of date (5 to 6 years). Many tools listed in the documentation are not present in the FreeBSD port, and many of the tools that are present are missing features. What's making things is worse is the fact that the netpbm ports don't include any documentation. Instead they refer to the online documentation which is way ahead of the state of the FreeBSD port, as explained above. Is anybody working on updating the netpbm ports? Is there any problem with it that I'm not aware of? Best regards Oliver -- Oliver Fromme, secnetix GmbH Co. KG, Marktplatz 29, 85567 Grafing b. M. Handelsregister: Registergericht Muenchen, HRA 74606, Geschäftsfuehrung: secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht Mün- chen, HRB 125758, Geschäftsführer: Maik Bachmann, Olaf Erb, Ralf Gebhart FreeBSD-Dienstleistungen, -Produkte und mehr: http://www.secnetix.de/bsd Being really good at C++ is like being really good at using rocks to sharpen sticks. -- Thant Tessman ___ 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: [ECFT] pkgng 0.1-alpha1: a replacement for pkg_install
On Tue, Mar 29, 2011 at 5:15 AM, Tim Kientzle kient...@freebsd.org wrote: II. Package signing. That would be really nice. Right know we only planned to sign the repo database, so we can trust the sah256 of the packages stored in the database. Then if the package has the same sha256 as the one in the repo database it is considered trusted. If we want a per-package signing, we would have a tarball in a tarball. I really expected this to have been mentioned already, but this approach (tarball in a tarball) is taken by Debian packages, and I don't remember hearing of any issues related to it. I don't think it's worth discounting from the start without giving some considerationg, but I will defer to the people actually doing the work. If you use libarchive-style streaming, it's even pretty straightforward to read and extract such things without having to create a bunch of temporary files. You just need to be careful about compression. Agreed, if we dont want to verify the signature, we can extract the tarball in the tarball efficiently. But to verify the signature, we have to read the tarball in the tarball twice: the first time to compute the digest and verify the signature, the second time to do the real extraction. So I guess that the tarball containing the real package archive and the signature should be uncompressed. The real package archive would be compressed, though. ___ 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: Failed building kdebase-workspace-4.5.5_1 cannot find the library liblzma.la
Troy t...@twisted.net wrote: Anytime I've ever upgraded the system, I built the kernel and the world. I have 419 .la files in /usr/local/lib. I don't think I want to try that idea. Are you saying if I rebuilt the kernel/world it would not fix this properly? No, it won't, because it's a ports problem. If you are looking for a one-line solution: rebuild all your installed ports. portupgrade -af. A somewhat more measured approach is to check which /usr/local/lib/*.la files reference /usr/local/lib/liblzma.*, look up which ports these .la files belong to, and only rebuild those ports. -- 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: [CFT] cpu stresser^W libreoffice 3.3.0 final
2011/3/29 Buganini bugan...@gmail.com:
Here on my computer,
ldconfig -m ${PREFIX}/lib/libreoffice/ure/lib
is required to load pyuno in a python script.
though, unoconv is still is not working..
Thanks,
Buganini
I have nothing to test pyuno, do you have a sample to send me?
concerning unoconv, strange, I will investigate, I thougth I fixed it.
regards,
Bapt
___
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: [CFT] cpu stresser^W libreoffice 3.3.0 final
Here on my computer,
ldconfig -m ${PREFIX}/lib/libreoffice/ure/lib
is required to load pyuno in a python script.
though, unoconv is still is not working..
Thanks,
Buganini
___
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: [ECFT] pkgng 0.1-alpha1: a replacement for pkg_install
I'm just going to clarify a statement I made earlier on this thread in order to remove some possible misconceptions. One can only boot 32bit PPC on a 32bit PPC machines and have it work properly. The same applies for 64bit ppc machines. On Tue, Mar 29, 2011 at 8:11 AM, Julien Laffaye jlaff...@freebsd.orgwrote: On Tue, Mar 29, 2011 at 5:15 AM, Tim Kientzle kient...@freebsd.org wrote: II. Package signing. That would be really nice. Right know we only planned to sign the repo database, so we can trust the sah256 of the packages stored in the database. Then if the package has the same sha256 as the one in the repo database it is considered trusted. If we want a per-package signing, we would have a tarball in a tarball. I really expected this to have been mentioned already, but this approach (tarball in a tarball) is taken by Debian packages, and I don't remember hearing of any issues related to it. I don't think it's worth discounting from the start without giving some considerationg, but I will defer to the people actually doing the work. If you use libarchive-style streaming, it's even pretty straightforward to read and extract such things without having to create a bunch of temporary files. You just need to be careful about compression. Agreed, if we dont want to verify the signature, we can extract the tarball in the tarball efficiently. But to verify the signature, we have to read the tarball in the tarball twice: the first time to compute the digest and verify the signature, the second time to do the real extraction. So I guess that the tarball containing the real package archive and the signature should be uncompressed. The real package archive would be compressed, though. ___ freebsd-hack...@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
[CFT] mplayer with multithreaded decoding
Hi, since I am in the middle of updating the mplayer and mencoder ports anyway, we might as well include the latest feature that has found its way upstream. For a few days now, the mplayer development snapshots are able to take advantage of multithreaded ffmpeg decoding (h264 and a few others). Therefore I have updated the experimental tarballs to today's svn snapshot. You can find the port tarballs here: http://www.rrr.de/~riggs/mplayer/m20110329.tar.bz2 You can enable the multithreaded decoder by running run mplayer -lavdopts threads=N file (N being the number of desired decoder threads). Note that this does not apply to all stages of the playback pipeline, e.g., if playback is dropping frames due to excessive postprocessing options, this won't necessarily solve the problem. Have fun Riggs ___ 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: [CFT] mplayer with multithreaded decoding
On Tue, 2011-03-29 at 18:53 +0200, Thomas Zander wrote: You can enable the multithreaded decoder by running run mplayer -lavdopts threads=N file (N being the number of desired decoder threads). Note that this does not apply to all stages of the playback pipeline, e.g., if playback is dropping frames due to excessive postprocessing options, this won't necessarily solve the problem. Hi Thomas, AFAIK -lavdopts threads=auto should work too in this case, though I didn't check your code yet if it's actually done there. Just mentioning it in case someone might be interested and/or wants to correct me before I get to it later today :) m. -- Michal Varga, Stonehenge (Gmail account) ___ 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: [ECFT] pkgng 0.1-alpha1: a replacement for pkg_install
on 28/03/2011 21:22 Julien Laffaye said the following: On Mon, Mar 28, 2011 at 6:59 PM, Garrett Cooper gcoo...@freebsd.org wrote: III. Package naming that includes architecture, major OS version (for API/ABI), maybe more. This could be provided in the manifest. Doing it in the filename sort of turns into a mess, as I've discovered working at Cisco :). Actually, it *is* in the +MANIFEST of pkgng packages archives :-) Well, by the package name I meant not only a package file name. Let's imagine that we do support installing i386 packages on amd64 in parallel to amd64 packages. And for some reason I want to have both 32-bit and 64-bit versions of, say, firefox; e.g. for benchmarking. If the packages would have the same name, then that would be impossible. I think that having some thing in package name in addition to package metadata could have certain benefits. -- Andriy Gapon ___ 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: Failed building kdebase-workspace-4.5.5_1 cannot find the library liblzma.la
On Mar 28, 2011, at 18:55 , Troy wrote: Anytime I've ever upgraded the system, I built the kernel and the world. I have 419 .la files in /usr/local/lib. I don't think I want to try that idea. Are you saying if I rebuilt the kernel/world it would not fix this properly? Rebuilding src/ will have absolutely no effect, since it's not the problem. Somewhere along the lines (by virtue of the reference to the lzma.la file), archivers/xz was installed on the system. Then src/ was upgraded to a point in time where xz was in the base system, rendering the port as IGNORE. At a rough guess, a ports upgrade after that fact found the now-defunct archivers/xz and most likely removed it WITHOUT also rebuilding all ports that depend on liblzma.so -- resulting in a system where some ports are using the src/ library, some are _perhaps_ using the old one from the port (check /usr/local/lib/compat/pkg -- it may be in there), but worse, a number of installed ports have references to liblzma.la in their own .la files. What you could try doing is grepping for liblzma.la in all of those .la files, making a note of which ones are affected, then use pkg_info -W name-of-file to determine which ports they belong to and forcibly rebuild them. -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: Alpha/AXP ports
On Mar 29, 2011, at 04:11 , Peter Jeremy wrote: I recently happened to notice that lang/compaq-cc is still present in the ports tree, although it's only for alpha. It can presumably be deleted. Most likely, yes. Unless there are dependent ports which also need to be burned away. That triggered me to have a closer look through the ports tree. Whilst there aren't any other alpha-only ports, there are a number of other ports that mention alpha in ONLY_FOR_ARCHS or in conditional make code. A complete list follows. How should this be handled? It seems silly to submit a massive number of PRs. Certainly one PR per port is not the way to go. If I were to do this (and, no I'm not volunteering ;) I'd (a) get approval from portmgr@ to forcibly remove alpha/axp support from the tree and then (b) simply check out all the relevant ports below, break out the Danish Axe, and do a single byebye, Alpha commit. However, there's no real defined policy on purging truly dead stuff (a _similar_ example would be hunting down anything for OSVERSION = 69 since we have the 6_EOL tag). -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: [ECFT] pkgng 0.1-alpha1: a replacement for pkg_install
2011/3/29 Andriy Gapon a...@freebsd.org: on 28/03/2011 21:22 Julien Laffaye said the following: On Mon, Mar 28, 2011 at 6:59 PM, Garrett Cooper gcoo...@freebsd.org wrote: III. Package naming that includes architecture, major OS version (for API/ABI), maybe more. This could be provided in the manifest. Doing it in the filename sort of turns into a mess, as I've discovered working at Cisco :). Actually, it *is* in the +MANIFEST of pkgng packages archives :-) Well, by the package name I meant not only a package file name. Let's imagine that we do support installing i386 packages on amd64 in parallel to amd64 packages. And for some reason I want to have both 32-bit and 64-bit versions of, say, firefox; e.g. for benchmarking. If the packages would have the same name, then that would be impossible. I think that having some thing in package name in addition to package metadata could have certain benefits. -- Andriy Gapon I understand but I think pkgng is already quite radical changement. More change is taking the risk that it would be rejected in the end, we still do not have any reply from portmgr, there is no insurance pkgng will in the end replace pkg_install. Currently pkgng requires only very few changes from the ports infrastruture, I don't know the cost of changing the name scheme. If I'm not clear enough, supporting both 32bits and 64bits packages at the same time on amd64 or arches that could support this kind of installation, is a large change we don't want to take the responsability of :) and implementing this in pkgng would significate we already choose how it should work. regards, Bapt ___ 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: Unable to configure dirmngr after openldap upgrade
Date: Mon, 28 Mar 2011 16:30:03 -0700 From: Doug Barton do...@freebsd.org On 03/28/2011 14:20, Xin LI wrote: On 03/28/11 13:57, Doug Barton wrote: On 03/28/2011 13:48, Xin LI wrote: On 03/28/11 12:42, Kevin Oberman wrote: Yup. openldap-client-2.4.24 does fine. Looks like a bug in 2.4.25. I'll take a look at CHANGES and see if I can figure out what broke the inclusion of fetch(3) support if I get a bit of time. It seems that libldif now referenced the fetch support, and ironically it seem be a bug but a feature :( I have decided to disable FETCH support from now on, since it's likely to bring more problems. (If you would prefer to fix the problem for this specific problem, I think adding a '-lfetch' would be sufficient; but, it seems to be undesirable to depend fetch(3) unconditionally for all programs that uses openldap). I know next to nothing about how the openldap-client stuff works, so I'm sorry if these questions are silly. :) The biggest question is, does dirmngr compile after your change? The other question is that the only reason I have openldap installed at all is so that gnupg can use it to fetch keys from ldap keyservers. Will this still work when the FETCH option is no longer present? hmm... how do I test fetching from an ldap keyserver? I'll save you the trouble. :) I got your latest update and tested both scenarios myself, and the answer is that they both work. So now the question is, should the FETCH OPTION be removed altogether? I imagine that a lot of users will be at least as confused as I, and word is that PRs for other ports are already showing up. No joy. I updated openldap-client to 2.4.25_1 and than tried to rebuild dirmngr. Same error as I had before: /usr/local/lib/libldap.so: undefined reference to `fetchGetURL' Back to 2.2.24. Thanks for trying to get this fixed up. -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: ober...@es.net Phone: +1 510 486-8634 Key fingerprint:059B 2DDF 031C 9BA3 14A4 EADA 927D EBB3 987B 3751 ___ 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: Unable to configure dirmngr after openldap upgrade
On 03/29/2011 11:54, Kevin Oberman wrote: No joy. I updated openldap-client to 2.4.25_1 and than tried to rebuild dirmngr. Same error as I had before: /usr/local/lib/libldap.so: undefined reference to `fetchGetURL' You have to disable the FETCH option. If you're building it in the port directory, type 'make config'. If you're using portmaster, add --force-config to the command line. hth, Doug -- Nothin' ever doesn't change, but nothin' changes much. -- OK Go Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/ ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: Unable to configure dirmngr after openldap upgrade
Date: Tue, 29 Mar 2011 11:57:52 -0700 From: Doug Barton do...@freebsd.org On 03/29/2011 11:54, Kevin Oberman wrote: No joy. I updated openldap-client to 2.4.25_1 and than tried to rebuild dirmngr. Same error as I had before: /usr/local/lib/libldap.so: undefined reference to `fetchGetURL' You have to disable the FETCH option. If you're building it in the port directory, type 'make config'. If you're using portmaster, add --force-config to the command line. In the immortal words of Homer, Doh! (Homer Simpson, that is). -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: ober...@es.net Phone: +1 510 486-8634 Key fingerprint:059B 2DDF 031C 9BA3 14A4 EADA 927D EBB3 987B 3751 ___ 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: [ECFT] pkgng 0.1-alpha1: a replacement for pkg_install
2011/3/29 Baptiste Daroussin b...@freebsd.org: 2011/3/29 Andriy Gapon a...@freebsd.org: on 28/03/2011 21:22 Julien Laffaye said the following: On Mon, Mar 28, 2011 at 6:59 PM, Garrett Cooper gcoo...@freebsd.org wrote: III. Package naming that includes architecture, major OS version (for API/ABI), maybe more. This could be provided in the manifest. Doing it in the filename sort of turns into a mess, as I've discovered working at Cisco :). Actually, it *is* in the +MANIFEST of pkgng packages archives :-) Well, by the package name I meant not only a package file name. Let's imagine that we do support installing i386 packages on amd64 in parallel to amd64 packages. And for some reason I want to have both 32-bit and 64-bit versions of, say, firefox; e.g. for benchmarking. If the packages would have the same name, then that would be impossible. I think that having some thing in package name in addition to package metadata could have certain benefits. -- Andriy Gapon I understand but I think pkgng is already quite radical changement. More change is taking the risk that it would be rejected in the end, we still do not have any reply from portmgr, there is no insurance pkgng will in the end replace pkg_install. Currently pkgng requires only very few changes from the ports infrastruture, I don't know the cost of changing the name scheme. If I'm not clear enough, supporting both 32bits and 64bits packages at the same time on amd64 or arches that could support this kind of installation, is a large change we don't want to take the responsability of :) and implementing this in pkgng would significate we already choose how it should work. regards, Bapt seems it was not clear :) ok let's try to say it simpler :) the main goal is to keep it simple for now, simple and rock solid, so that we can replace pkg_install and do some cleanup in the ports tree, add the must have features while doing that. And only when we will be ready for that and that portmgr have decided that it is mature enough to replace pkg_install, only after that we will start improving with new features and new changes. I thinks changing the package name scheme is not a must have feature, it for sure is and intresting feature, but what about pushing to after the first stable release? managing architecture as we plan to do it is enough imho. But I can be wrong. regards, Bapt ___ 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: Help with first port Makefile
On Mon, 28 Mar 2011 23:28:39 -0300 Raphael Kubo da Costa kub...@gmail.com wrote: By the way, taking a look at the comments in the beginning of bsd.gnome.mk is also a good idea, as it shows you can use something like USE_GNOME=gtk20 and be done with it. Thanks, after being suggested to use this twice, I tried it again and doubled checked the dependencies that were being check were dependecies of gtk20. Guess it was just too late to think :) -- Rod Person http://www.rodperson.com Jesus was a Jew. And he loved being a Jew so much, he wanted everyone to get their dicks snipped. Waler J. Person, Jr.. ___ 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: Failed building kdebase-workspace-4.5.5_1 cannot find the library liblzma.la
Anytime I've ever upgraded the system, I built the kernel and the world. I have 419 .la files in /usr/local/lib. I don't think I want to try that idea. Are you saying if I rebuilt the kernel/world it would not fix this properly? Rebuilding src/ will have absolutely no effect, since it's not the problem. Somewhere along the lines (by virtue of the reference to the lzma.la file), archivers/xz was installed on the system. Then src/ was upgraded to a point in time where xz was in the base system, rendering the port as IGNORE. At a rough guess, a ports upgrade after that fact found the now-defunct archivers/xz and most likely removed it WITHOUT also rebuilding all ports that depend on liblzma.so -- resulting in a system where some ports are using the src/ library, some are _perhaps_ using the old one from the port (check /usr/local/lib/compat/pkg -- it may be in there), but worse, a number of installed ports have references to liblzma.la in their own .la files. What you could try doing is grepping for liblzma.la in all of those .la files, making a note of which ones are affected, then use pkg_info -Wname-of-file to determine which ports they belong to and forcibly rebuild them. -aDe That worked. It was ImageMagick-6.6.7.10 that was the culprit. Once I re-built it, I was able to rebuild kdebase-workspace-4.5.5._1 ___ 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
David Brooks as maintainer of sabnzbd port
David has asked to take over the maintenance of the sabnzbd port. This is something I support. What can I do to make this happen? -d -- America was founded by men who understood that the threat of domestic tyranny is as great as any threat from abroad. If we want to be worthy of their legacy, we must resist the rush toward ever-increasing state control of our society. Otherwise, our own government will become a greater threat to our freedoms than any foreign terrorist. - Ron Paul, Texas Straight Talk, May 31, 2004 ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: ports/graphics/netpbm out of date
On 2011-Mar-29 13:51:21 +0200, Oliver Fromme o...@lurza.secnetix.de wrote: Both graphics/netpbm and graphics/netpbm-devel are *WAY* out of date (5 to 6 years). I don't understand you. In my experience, the netpbm ports have always been updated fairly regularly. The ports currently have: STABLE_PORTVERSION= 10.26.64 DEVEL_PORTVERSION= 10.35.80 10.26.64 is the last of the 10.26 series and was released almost exactly 18 months ago. 10.35.80 is the current stable version and was released about 5 weeks ago. The port was updated the day following the release. What's making things is worse is the fact that the netpbm ports don't include any documentation. Instead they refer to the online documentation which is way ahead of the state of the FreeBSD port, as explained above. I agree this is annoying and don't understand the rationale behind the way netpbm documentation is handled but that is not the FreeBSD maintainer's fault. Is anybody working on updating the netpbm ports? Is there any problem with it that I'm not aware of? A quick check would have identified the maintainer (now Cc'd). -- Peter Jeremy pgpw417oQghTg.pgp Description: PGP signature
