Re: [FreeBSD-Ports-Announce] Time to bid farewell to the old pkg_ tools
On Thu, Feb 6, 2014 at 7:45 AM, Matthew Seaman m.sea...@infracaninophile.co.uk wrote: On 05/02/2014 23:57, Kevin Oberman wrote: 1. The ports/packages system is not total crap. In fact, at the time jkh started it, it was far superior to any tool available. When I first encountered the ports, way back in 1998 or so, I was completely mind-blown that something so fantastic could exist. Yes, it was revolutionary at the time and right where FreeBSD should be -- leading the rest of the world with great innovations. However, things have changed in the last 16 years. Development of the ports as a global concept has been resting on its laurels a bit, and the rest of the world has caught up, and indeed overtaken. Partly that was due to the mindset of seeing binary packages as a second-class thing; partly due to the old pkg_tools not providing the scope to implement innovative features; partly due to pkg_tools being part of the FreeBSD base, so impossible to update over reasonable timescales due to the requirement to support older RELEASE branches. pkg(8) addresses those problems, and I hope will do so for at least the next decade. 5. The introduction of pkgng could have really been handled better and that probably increased the negative feelings about it. It was also a bit before it was really ready. It still lacks a few features I feel are quite important, but they were also missing from the old system. I don't think it's possible to make a change of this magnitude without upsetting anyone. We have been getting a lot of feedack on the lines of 'Wow! This is great. When can we have feature XYZ?' to which we frequently have to reply that XYZ can't be implemented without breaking compatibility with pkg_tools. Like sub-packages. I'd be interested to hear what features you think are missing. We will implement anything (eventually...) that there is demand for and that is technically feasible, and that fits with the overall concept of what we think a packaging system should do. There's a number of ideas in the github issue list already (usually tagged with 'longterm' or 'thinking') and we are happy for people to add to that, or to discuss ideas -- the freebsd-pkg@ list is a good place for that. The ability to install certain package version, instead of installing simply the latest one. Please, please, pretty please! :) B. Cheers, Matthew -- Dr Matthew J Seaman MA, D.Phil. PGP: http://www.infracaninophile.co.uk/pgpkey JID: matt...@infracaninophile.co.uk ___ 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 ports you maintain which are out of date
Dear port maintainer, The portscout new distfile checker has detected that one or more of your ports appears to be out of date. Please take the opportunity to check each of the ports listed below, and if possible and appropriate, submit/commit an update. If any ports have already been updated, you can safely ignore the entry. You will not be e-mailed again for any of the port/version combinations below. Full details can be found at the following URL: http://portscout.freebsd.org/po...@freebsd.org.html Port| Current version | New version +-+ devel/cross-gdb | 7.2 | 7.7 +-+ If any of the above results are invalid, please check the following page for details on how to improve portscout's detection and selection of distfiles on a per-port basis: http://portscout.freebsd.org/info/portscout-portconfig.txt 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
Re: graphics/rawtherapee: r342622 crashes on HEAD
Am 06.02.2014 08:52 (UTC+1) schrieb Baptiste Daroussin: On Thu, Feb 06, 2014 at 07:03:22AM +0100, Rainer Hurling wrote: Am 05.02.2014 22:20 (UTC+1) schrieb Baptiste Daroussin: On Wed, Feb 05, 2014 at 09:19:51PM +0100, Matthias Andree wrote: Am 05.02.2014 21:08, schrieb Dimitry Andric: #17 0x484c0ee0 in std::__1::locale::id::__next_id () from /usr/local/lib/libc++.so.1 Hmm, is this a ports version of libc++? I was not aware Baptiste had already committed this? :) Yes, it is (as a build requisite, but apparently remained installed on the destination machine), because we need to match the libraries that the requisites use (Glibmm for one). I have given up on compiling RawTherapee with clang++ for now, and use GCC 4.8 on all systems. RawTherapee is somewhat demanding, especially at higher optimization level, and kills the 10.0-RELEASE base clang and Port GCC 4.6 and 4.7, all with internal compiler errors. Since GCC 4.8 worked for me, I did not bother to send Gerald the details. We may want to retry with clang if we've got the next clang version. Feel free to use Rawtherapee as compiler system test ;) try with something like this in libmap.conf libc++.so.1 /usr/local/lib/libc++.so.1 If that fixes the problem, then a rpath with /usr/local/lib should be set while building the port Hmm, I am not very familiar with libmapping. After adding it to /etc/libmap.conf I get #rawtherapee Shared object /usr/local/lib/libc++.so.1 not found, required by rawtherapee Thanks for the tip, Rainer regards, Bapt try reinstalling devel/libc++ and keeping the libmap.conf entry, that should do the trick as it was a build only dep it may have been removed. just remove the line from libmap.conf before reinstalling devel/libc++ and readd it once it is installed. I commented out libmap.conf entry, reinstalled devel/libc++ and readded libmap.conf entry. After that, I get the same error, when starting rawtherapee. In a second step I tried to rebuild graphics/rawtherapee with the entry in /etc/libmap.conf active. That also fails with: [..snip..] /bin/mkdir -p /usr/ports/graphics/rawtherapee/work/.build Shared object /usr/local/lib/libc++.so.1 not found, required by cmake *** Error code 1 Stop. make[1]: stopped in /usr/ports/graphics/rawtherapee *** Error code 1 Rainer 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: graphics/rawtherapee: r342622 crashes on HEAD
Am 06.02.2014 08:23 (UTC+1) schrieb Dimitry Andric: On 06 Feb 2014, at 07:48, Rainer Hurling rhur...@gwdg.de wrote: ... I just recognized, that in my CURRENT boxes in base their are two versions of libc++: #ll /usr/lib/libc++.so* -r--r--r-- 1 root wheel -134 3 Aug 22:33:00 2013 /usr/lib/libc++.so -r--r--r-- 1 root wheel - 768248 4 Feb 18:08:00 2014 /usr/lib/libc++.so.1 Shouldn't libc++.so be a link to libc++.so.1 or at least also come from the newest built? No, libc++.so is a linker script, similar to libc.so: $ cat /usr/lib/libc++.so /* $FreeBSD: head/lib/libc++/libc++.ldscript 253917 2013-08-03 16:23:43Z dim $ */ GROUP ( /usr/lib/libc++.so.1 /usr/lib/libcxxrt.so ) Oh, yes. I did not look enough at it, sorry. So no problem here in this place. Thanks, Rainer -Dimitry ___ 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: [FreeBSD-Ports-Announce] Time to bid farewell to the old pkg_ tools
On Thu, Feb 6, 2014 at 2:59 AM, Big Lebowski spankthes...@gmail.com wrote: On Thu, Feb 6, 2014 at 7:45 AM, Matthew Seaman m.sea...@infracaninophile.co.uk wrote: I'd be interested to hear what features you think are missing. We will implement anything (eventually...) that there is demand for and that is technically feasible, and that fits with the overall concept of what we think a packaging system should do. There's a number of ideas in the github issue list already (usually tagged with 'longterm' or 'thinking') and we are happy for people to add to that, or to discuss ideas -- the freebsd-pkg@ list is a good place for that. The ability to install certain package version, instead of installing simply the latest one. Please, please, pretty please! :) I echo this sentiment, but I would like to take it a step further and say a certain version or greater. -- Take care Rick Miller ___ 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: [FreeBSD-Ports-Announce] Time to bid farewell to the old pkg_ tools
On Thu, Feb 6, 2014 at 12:41 PM, Rick Miller vmil...@hostileadmin.com wrote: On Thu, Feb 6, 2014 at 2:59 AM, Big Lebowski spankthes...@gmail.com wrote: On Thu, Feb 6, 2014 at 7:45 AM, Matthew Seaman m.sea...@infracaninophile.co.uk wrote: I'd be interested to hear what features you think are missing. We will implement anything (eventually...) that there is demand for and that is technically feasible, and that fits with the overall concept of what we think a packaging system should do. There's a number of ideas in the github issue list already (usually tagged with 'longterm' or 'thinking') and we are happy for people to add to that, or to discuss ideas -- the freebsd-pkg@ list is a good place for that. The ability to install certain package version, instead of installing simply the latest one. Please, please, pretty please! :) I echo this sentiment, but I would like to take it a step further and say a certain version or greater. I suspect he meant a certain version, and *not* newer - sometimes you might want to hold back a package. -- Daniel Nebdal ___ 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: [FreeBSD-Ports-Announce] Time to bid farewell to the old pkg_ tools
Michel Talon wrote: --Apple-Mail=_102D913B-49CA-4129-972A-758AABCAA293 Content-Type: multipart/alternative; boundary=Apple-Mail=_16E0BC5A-FE3D-444D-8437-47827626590A --Apple-Mail=_16E0BC5A-FE3D-444D-8437-47827626590A Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Junk mail format, not impressed. Use Ascii ports/ is not just for package addicts. I never install packages, but only build install from ports/. sqlite junk obstructs /var/db/pkg being accessed by find grep to debug breaking ports = builds. As someone who has advocated the use of sqlite to replace the old = database in the filesystem several years before it has been implemented by the new package system, = i can only conclude, like Matthew that you are being absurd. Personal inuendo does not impress. The old package system was total = crap, local.sqlite is also crap, breaks decades of accessibility by find grep other text pipe / search tools. incredibly slow and using system resources in absurd ways. Sqlite obstructs nothing, False. local.sqlite obstructs inspection by find grep text search tools. you = have to spend a couple of minutes learning the basic SQL queries, which is no more difficult that learning = obtuse find and grep options. Package addicts were so myopic they ignored some people won't even use packages, just /usr/ports make. local.sqlite was immaturely shoved in without documenting it, no man 5 local.sqlite no hook there for the couple of minutes learning you assert, (no hook to believe the couple you assert). Moreover i have hard time believing one needs to dissect the package = system (beyond reading the=20 output of pkg info) to debug a port build. One surely needs some = ports/ is not just a plaything for package script addicts. Some use ports/ to make debug exclusively from sources. --Apple-Mail=_16E0BC5A-FE3D-444D-8437-47827626590A Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii htmlhead/headbody style=3Dword-wrap: break-word; = -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; pre = Send no junk ! class=3DApple-interchange-newline /div br/body/html= --Apple-Mail=_16E0BC5A-FE3D-444D-8437-47827626590A-- --Apple-Mail=_102D913B-49CA-4129-972A-758AABCAA293 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIIbzCCA7Yw 50 lines un-necessary. Cheers, Julian -- Julian Stacey, BSD Unix Linux C Sys Eng Consultant, Munich http://berklix.com Interleave replies below like a play script. Indent old text with . Send plain text, not quoted-printable, HTML, base64, or multipart/alternative. ___ 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: [FreeBSD-Ports-Announce] Time to bid farewell to the old pkg_ tools
El día Thursday, February 06, 2014 a las 01:27:50PM +0100, Julian H. Stacey escribió: Michel Talon wrote: The old package system was total = crap, local.sqlite is also crap, breaks decades of accessibility by find grep other text pipe / search tools. Since many years I have always compiled my (i.e. the ports I need) from CVS or now SVN ports tree on some fast baquery maschine. After compiling I just did something like: # mkdir PKG # cd PKG # pkg_create -Rnb `cd /var/db/pkg ; ls -C1` and moved the resulting ~1500 packages to my laptops or smaller netbooks. Until today I'm still using the old pkg_info/_add/_create tools and skipped pkgng until today. Will the above procedure work fine too in the future? Why not keep the old methods unchanged in place as today? Thanks matthias -- Matthias Apitz | /\ ASCII Ribbon Campaign: www.asciiribbon.org E-mail: g...@unixarea.de | \ / - No HTML/RTF in E-mail WWW: http://www.unixarea.de/ | X - No proprietary attachments phone: +49-170-4527211 | / \ - Respect for open standards ___ 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: [FreeBSD-Ports-Announce] Time to bid farewell to the old pkg_ tools
On Thu, Feb 6, 2014 at 7:23 AM, Daniel Nebdal dneb...@gmail.com wrote: On Thu, Feb 6, 2014 at 12:41 PM, Rick Miller vmil...@hostileadmin.com wrote: On Thu, Feb 6, 2014 at 2:59 AM, Big Lebowski spankthes...@gmail.com wrote: On Thu, Feb 6, 2014 at 7:45 AM, Matthew Seaman m.sea...@infracaninophile.co.uk wrote: I'd be interested to hear what features you think are missing. We will implement anything (eventually...) that there is demand for and that is technically feasible, and that fits with the overall concept of what we think a packaging system should do. There's a number of ideas in the github issue list already (usually tagged with 'longterm' or 'thinking') and we are happy for people to add to that, or to discuss ideas -- the freebsd-pkg@ list is a good place for that. The ability to install certain package version, instead of installing simply the latest one. Please, please, pretty please! :) I echo this sentiment, but I would like to take it a step further and say a certain version or greater. I suspect he meant a certain version, and *not* newer - sometimes you might want to hold back a package. Correct. My wish is the functionality be extended further to mean a certain version *or* newer, encompassing both features. Thus, allowing him to say port-1.1, while I say port-1.4 or newer or even port-1.0 or newer. -- Take care Rick Miller ___ 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: [FreeBSD-Ports-Announce] Time to bid farewell to the old pkg_ tools
On 2/6/2014 13:27, Julian H. Stacey wrote: Michel Talon wrote: charset=us-ascii Junk mail format, not impressed. Use Ascii This is petty. i can only conclude, like Matthew that you are being absurd. Personal inuendo does not impress. While you may take this as an unnecessary attack, it doesn't mean that it's not true. In reality, I don't know how else I would describe your POV in a nicer way. Yes, everyone is entitled to an opinion, but you aren't free to be criticized for the one you publicly have. False. local.sqlite obstructs inspection by find grep text search tools. And several people said this was not something they ever had to do with years of experience. It also matches my experience. And the solution is swap out grep for pkg query. This looks like a red herring to me. Package addicts were so myopic they ignored some people won't even use packages, just /usr/ports make. local.sqlite was immaturely shoved in without documenting it, no man 5 local.sqlite no hook there for the couple of minutes learning you assert, (no hook to believe the couple you assert). hmm? I'm not following this. You aren't supposed to interact with the db directly, but though pkg queries. Moreover i have hard time believing one needs to dissect the package = system (beyond reading the=20 output of pkg info) to debug a port build. One surely needs some = ports/ is not just a plaything for package script addicts. Some use ports/ to make debug exclusively from sources. That doesn't require /var/db/ports though. --Apple-Mail=_16E0BC5A-FE3D-444D-8437-47827626590A Content-Transfer-Encoding: quoted-printable Send no junk ! petty class=3DApple-interchange-newline MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIIbzCCA7Yw 50 lines un-necessary. petty. I didn't even see it. Either the mail list stripped it out or the mail client (thunderbird) obscured it. John ___ 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
Has NO_MANCOMPRESS been silently depreciated?
Hi, For many years I have set NO_MANCOMPRESS (and before that NOMANCOMPRESS) in /etc/make.conf on all my machines. In the last few weeks I have noticed that this setting is being ignored by port updates. Has this setting been silently depreciated? 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
Re: [FreeBSD-Ports-Announce] Time to bid farewell to the old pkg_ tools
On 2/6/2014 13:58, Rick Miller wrote: On Thu, Feb 6, 2014 at 7:23 AM, Daniel Nebdal dneb...@gmail.com wrote: I suspect he meant a certain version, and *not* newer - sometimes you might want to hold back a package. Correct. My wish is the functionality be extended further to mean a certain version *or* newer, encompassing both features. Thus, allowing him to say port-1.1, while I say port-1.4 or newer or even port-1.0 or newer. As an observer, all I can say is Don't get your hopes up on this one. Hundreds of ports are bumped with majority dependency changes for a reason. The tree is treated as an integrated entity, not 25,000 interchangeable parts. It would take major technology shift, something closer to what PC-BSD's pbi things do/did. Ports itself isn't geared for this. Maybe some kind of package archive could be used though, if pkg solvers could be made to handle such requests. Sounds like an extremely difficult request to me though. John ___ 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: [FreeBSD-Ports-Announce] Time to bid farewell to the old pkg_ tools
On Thu, Feb 6, 2014 at 1:45 PM, Matthias Apitz g...@unixarea.de wrote: El día Thursday, February 06, 2014 a las 01:27:50PM +0100, Julian H. Stacey escribió: Michel Talon wrote: The old package system was total = crap, local.sqlite is also crap, breaks decades of accessibility by find grep other text pipe / search tools. Since many years I have always compiled my (i.e. the ports I need) from CVS or now SVN ports tree on some fast baquery maschine. After compiling I just did something like: # mkdir PKG # cd PKG # pkg_create -Rnb `cd /var/db/pkg ; ls -C1` and moved the resulting ~1500 packages to my laptops or smaller netbooks. Until today I'm still using the old pkg_info/_add/_create tools and skipped pkgng until today. Will the above procedure work fine too in the future? Why not keep the old methods unchanged in place as today? Thanks matthias The recommended way to do that is to set up poudriere. It's a different tool, but easy enough to work with, and it has certain benefits [1]. Obviously, that's neither a yes nor a no - and in short I don't know how pkg supports that specific use. [1] It's smarter about building in parallel, so it should be faster. It also handles compiling upgraded packages better - the logic is about the same as in portmaster/portupgrade, though building each port in a clean jail (with dependencies installed from the packages it has already created) reduces the risk of contamination from old versions on the host (typically automake scripts detecting some installed and not-yet upgraded library that's not set as a dependency ... at least that has happened to me a few times). It also creates a pkg repository with the packages, so if you have network access (nfs or http) you can use pkg to do installs or upgrades on the client machines (especially upgrades are very smooth like that). -- Daniel Nebdal ___ 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: Has NO_MANCOMPRESS been silently depreciated?
On 2/6/2014 13:54, N.J. Mann wrote: For many years I have set NO_MANCOMPRESS (and before that NOMANCOMPRESS) in /etc/make.conf on all my machines. In the last few weeks I have noticed that this setting is being ignored by port updates. Has this setting been silently depreciated? You have been setting it in make.conf? I don't believe it was ever a user variable. Anyway, yes, it doesn't do anything on staged ports and it was silently removed because it was for port maintainers only, not users. (subject to confirmation by the experts). John ___ 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: [FreeBSD-Ports-Announce] Time to bid farewell to the old pkg_ tools
On Wed, 5 Feb 2014 23:26:18 -0800 Kevin Oberman rkober...@gmail.com wrote: If you use poudriere, you can roll your own packages with custom options and maintain things pretty reasonably, but for a single system (or two), this is a bit of overkill. As things stand, this is a real pain to use customized ports and packages from the standard FreeBSD distributions. I'm waiting with great excitement for this to appear, though I have no idea if it is near or far. I really don't think so. Even with a single machine, poudriere literally saved my a.. pretty bottom several times breaking on implicit dependencies which would have popped up ages later with nasty and difficult to trace problems/errors. I think anybody who compiles from ports should _really_ use poudriere. I even think it should be strongly suggested in the handbook. (I'd be willing to write that up for that matter.) -- Christopher TZ: GMT + 1h GnuPG/GPG: 0xE8DE2C14 FreeBSD 9.2-STABLE #1 r256184: Thu Oct 10 19:12:54 CEST 2013 c...@dijkstra.cruwe.de:/usr/obj/usr/home/cjr/media/src/freebsd/base/stable/9/sys/GEN_WDTRACE Punctuation matters: Lets eat Grandma. or Lets eat, Grandma. - Punctuation saves lives. A panda eats shoots and leaves. or A panda eats, shoots, and leaves. - Punctuation teaches proper biology. With sufficient thrust, pigs fly just fine. However, this is not necessarily a good idea. It is hard to be sure where they are going to land, and it could be dangerous sitting under them as they fly overhead. (RFC 1925) ___ 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: Has NO_MANCOMPRESS been silently depreciated?
In message 52f388ee.30...@marino.st, John Marino (freebsd.cont...@marino.st) wrote: On 2/6/2014 13:54, N.J. Mann wrote: For many years I have set NO_MANCOMPRESS (and before that NOMANCOMPRESS) in /etc/make.conf on all my machines. In the last few weeks I have noticed that this setting is being ignored by port updates. Has this setting been silently depreciated? You have been setting it in make.conf? Yes. I don't believe it was ever a user variable. It was and still is for the base system - this machine was updated to 8-STABLE r261161 ten days ago and all base manual pages are uncompressed. Anyway, yes, it doesn't do anything on staged ports and it was silently removed because it was for port maintainers only, not users. (subject It _is_ a user, well administrator really, setting. Please unremove it. 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
Re: Has NO_MANCOMPRESS been silently depreciated?
On 2/6/2014 14:31, N.J. Mann wrote: I don't believe it was ever a user variable. It was and still is for the base system - this machine was updated to 8-STABLE r261161 ten days ago and all base manual pages are uncompressed. okay, that's right. It's a case where ports honored a base variable and probably should have created their own version instead. When all the ports are staged, the man page variables will be unrecognized. Anyway, yes, it doesn't do anything on staged ports and it was silently removed because it was for port maintainers only, not users. (subject It _is_ a user, well administrator really, setting. Please unremove it. Not my call, but I can pretty much guarantee that won't happen. Man pages are automatically handled in stage, and all of them are marked compressed in the internal plist. You are asking for an infrastructure change. We don't even know why it's important (why can't man pages be compressed?) John ___ 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
[QAT] r343053: 4x leftovers
- Stage support - Build ID: 20140206122802-62035 Job owner: m...@freebsd.org Buildtime: 94 minutes Enddate: Thu, 06 Feb 2014 14:01:48 GMT Revision: r343053 Repository: https://svnweb.freebsd.org/ports?view=revisionrevision=343053 - Port:security/yersinia 0.7.1_1 Buildgroup: 8.4-QAT/amd64 Buildstatus: LEFTOVERS Log: https://qat.redports.org//~m...@freebsd.org/20140206122802-62035-272280/yersinia-0.7.1_1.log Buildgroup: 8.4-QAT/i386 Buildstatus: LEFTOVERS Log: https://qat.redports.org//~m...@freebsd.org/20140206122802-62035-272281/yersinia-0.7.1_1.log Buildgroup: 9.2-QAT/amd64 Buildstatus: LEFTOVERS Log: https://qat.redports.org//~m...@freebsd.org/20140206122802-62035-272282/yersinia-0.7.1_1.log Buildgroup: 9.2-QAT/i386 Buildstatus: LEFTOVERS Log: https://qat.redports.org//~m...@freebsd.org/20140206122802-62035-272283/yersinia-0.7.1_1.log -- Buildarchive URL: https://qat.redports.org/buildarchive/20140206122802-62035 redports https://qat.redports.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: [FreeBSD-Ports-Announce] Time to bid farewell to the old pkg_ tools
Am 2014-02-06 14:05, schrieb Daniel Nebdal: On Thu, Feb 6, 2014 at 1:45 PM, Matthias Apitz g...@unixarea.de wrote: El día Thursday, February 06, 2014 a las 01:27:50PM +0100, Julian H. Stacey escribió: Michel Talon wrote: The old package system was total = crap, local.sqlite is also crap, breaks decades of accessibility by find grep other text pipe / search tools. Since many years I have always compiled my (i.e. the ports I need) from CVS or now SVN ports tree on some fast baquery maschine. After compiling I just did something like: # mkdir PKG # cd PKG # pkg_create -Rnb `cd /var/db/pkg ; ls -C1` and moved the resulting ~1500 packages to my laptops or smaller netbooks. Until today I'm still using the old pkg_info/_add/_create tools and skipped pkgng until today. Will the above procedure work fine too in the future? Why not keep the old methods unchanged in place as today? Thanks matthias The recommended way to do that is to set up poudriere. It's a different tool, but easy enough to work with, and it has certain benefits [1]. Obviously, that's neither a yes nor a no - and in short I don't know how pkg supports that specific use. [1] It's smarter about building in parallel, so it should be faster. It also handles compiling upgraded packages better - the logic is about the same as in portmaster/portupgrade, though building each port in a clean jail (with dependencies installed from the packages it has already created) reduces the risk of contamination from old versions on the host (typically automake scripts detecting some installed and not-yet upgraded library that's not set as a dependency ... at least that has happened to me a few times). It also creates a pkg repository with the packages, so if you have network access (nfs or http) you can use pkg to do installs or upgrades on the client machines (especially upgrades are very smooth like that). And it supports devel/ccache out of the box. Just install ccache, create /var/cache/ccache and uncomment CCACHE_DIR=/var/cache/ccache in poudriere.conf The ports compile much faster with ccache enabled. ___ 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: Has NO_MANCOMPRESS been silently depreciated?
In message 52f39326.2040...@marino.st, John Marino (freebsd.cont...@marino.st) wrote: On 2/6/2014 14:31, N.J. Mann wrote: You are asking for an infrastructure change. No I am not. I _am_ asking that something which used to be supported (and was documented), that has silently been removed, be reinstated. 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
Re: Has NO_MANCOMPRESS been silently depreciated?
On 2/6/14, 9:36 AM, N.J. Mann wrote: In message 52f39326.2040...@marino.st, John Marino (freebsd.cont...@marino.st) wrote: On 2/6/2014 14:31, N.J. Mann wrote: You are asking for an infrastructure change. No I am not. I _am_ asking that something which used to be supported (and was documented), that has silently been removed, be reinstated. The two are not mutually exclusive. So actually, yes you _are_. If you want it back that badly, write the necessary patches and submit them. -- Jim Ohlstein Never argue with a fool, onlookers may not be able to tell the difference. - Mark Twain ___ 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: prosody-0.8.2
Hey there. Totally new to FreeBSD here, trying to migrate a piece of my infrastructure from .. Linux. One thing I'm relying on is prosody, you seem to maintain that port. 0.8.2 was released around the 20.06.2011. Starting from 20.08.2013 prosody is on 0.9, 0.9.2 was released in January 2014. Is there any chance to see an update to this port? Are you still interested in this project or is the port currently abandoned? Can I help with anything to bump this to a more current (ideally: THE current) version? Thanks a lot, Ben ___ 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: [FreeBSD-Ports-Announce] Time to bid farewell to the old pkg_ tools
El día Thursday, February 06, 2014 a las 02:36:30PM +0100, Christopher J. Ruwe escribió: On Wed, 5 Feb 2014 23:26:18 -0800 Kevin Oberman rkober...@gmail.com wrote: If you use poudriere, you can roll your own packages with custom options and maintain things pretty reasonably, but for a single system (or two), this is a bit of overkill. As things stand, this is a real pain to use customized ports and packages from the standard FreeBSD distributions. I'm waiting with great excitement for this to appear, though I have no idea if it is near or far. I really don't think so. Even with a single machine, poudriere literally saved my a.. pretty bottom several times breaking on implicit dependencies which would have popped up ages later with nasty and difficult to trace problems/errors. I think anybody who compiles from ports should _really_ use poudriere. I even think it should be strongly suggested in the handbook. (I'd be willing to write that up for that matter.) Please point me to the existing documentation. I don't see the string poudriere in our handbook. Thx matthias -- Matthias Apitz | /\ ASCII Ribbon Campaign: www.asciiribbon.org E-mail: g...@unixarea.de | \ / - No HTML/RTF in E-mail WWW: http://www.unixarea.de/ | X - No proprietary attachments phone: +49-170-4527211 | / \ - Respect for open standards ___ 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: [FreeBSD-Ports-Announce] Time to bid farewell to the old pkg_ tools
On Thu, February 6, 2014 4:27 am, Julian H. Stacey wrote: Michel Talon wrote: ports/ is not just for package addicts. I never install packages, but only build install from ports/. sqlite junk obstructs /var/db/pkg being accessed by find grep to debug breaking ports = builds. As someone who has advocated the use of sqlite to replace the old = database in the filesystem several years before it has been implemented by the new package system, = i can only conclude, like Matthew that you are being absurd. Personal inuendo does not impress. The old package system was total = crap, local.sqlite is also crap, breaks decades of accessibility by find grep other text pipe / search tools. incredibly slow and using system resources in absurd ways. Sqlite obstructs nothing, False. local.sqlite obstructs inspection by find grep text search tools. you = have to spend a couple of minutes learning the basic SQL queries, which is no more difficult that learning = obtuse find and grep options. Package addicts were so myopic they ignored some people won't even use packages, just /usr/ports make. local.sqlite was immaturely shoved in without documenting it, no man 5 local.sqlite no hook there for the couple of minutes learning you assert, (no hook to believe the couple you assert). That's a good point, having the sqlite structures documented would be nice. I'll research to see what already exists, if nothing I'll put together some documentation in the next few days. I normally build from source, however I'm currently 'on the road' and wanted to update a laptop which has not been touched in about one year. Updating to 11.0-CURRENT was no problem, however converting the system to pkgng then trying to 'pkg upgrade' all the packages caused some headaches for me.. in the end it was _much_ easier to wipe /usr/local and /var/db/pkg and install everything fresh using pkg. Perhaps 'sounds scary' but not really. User settings/configuration is mostly in ~/ ... Doing it that way went very smooth and very quick. Overall I prefer pkgng to the previous pkg system. And storing information in sqlite database seems smart to me. I think maybe sqlite is used with yellowdog, but i've not looked hard at the inner mechanics of that system. I see your point about grep, I suppose grep doesn't work so well with sqlite databases. # grep fun local.sqlite Binary file local.sqlite matches The most painful trouble I've had with (any) package systems: r) a major upgrade to libraries which are dependencies in (many) other packages, ie png. s) introducing foreign software: building custom/or self-written/or 'manual' software into the same space as the packaged software (ie, /usr/local). t) updating a machine which has been 'neglected' for and extended period. pkgng is the most 'intuitive' and uncomplicated package system i've seen, i'm happy that so much effort has gone into creating a great product. Moreover i have hard time believing one needs to dissect the package = system (beyond reading the=20 output of pkg info) to debug a port build. One surely needs some = ports/ is not just a plaything for package script addicts. Some use ports/ to make debug exclusively from sources. -- Waitman Gobble San Jose California USA +1.510-830-7975 ___ 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: [FreeBSD-Ports-Announce] Time to bid farewell to the old pkg_ tools
On Thu, 6 Feb 2014 15:49:24 +0100 Matthias Apitz g...@unixarea.de wrote: El día Thursday, February 06, 2014 a las 02:36:30PM +0100, Christopher J. Ruwe escribió: On Wed, 5 Feb 2014 23:26:18 -0800 Kevin Oberman rkober...@gmail.com wrote: If you use poudriere, you can roll your own packages with custom options and maintain things pretty reasonably, but for a single system (or two), this is a bit of overkill. As things stand, this is a real pain to use customized ports and packages from the standard FreeBSD distributions. I'm waiting with great excitement for this to appear, though I have no idea if it is near or far. I really don't think so. Even with a single machine, poudriere literally saved my a.. pretty bottom several times breaking on implicit dependencies which would have popped up ages later with nasty and difficult to trace problems/errors. I think anybody who compiles from ports should _really_ use poudriere. I even think it should be strongly suggested in the handbook. (I'd be willing to write that up for that matter.) Please point me to the existing documentation. I don't see the string poudriere in our handbook. Thx matthias I wrote it should be suggested, which means that I think it would be a good idea, not that it already happened. I do not understand how that could be misunderstood. Cheers, -- Christopher TZ: GMT + 1h GnuPG/GPG: 0xE8DE2C14 FreeBSD 9.2-STABLE #1 r256184: Thu Oct 10 19:12:54 CEST 2013 c...@dijkstra.cruwe.de:/usr/obj/usr/home/cjr/media/src/freebsd/base/stable/9/sys/GEN_WDTRACE Punctuation matters: Lets eat Grandma. or Lets eat, Grandma. - Punctuation saves lives. A panda eats shoots and leaves. or A panda eats, shoots, and leaves. - Punctuation teaches proper biology. With sufficient thrust, pigs fly just fine. However, this is not necessarily a good idea. It is hard to be sure where they are going to land, and it could be dangerous sitting under them as they fly overhead. (RFC 1925) ___ 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: FreeBSD Port: prosody-0.8.2
Hi! Starting from 20.08.2013 prosody is on 0.9, 0.9.2 was released in January 2014. Have a look at http://www.freebsd.org/cgi/query-pr.cgi?pr=ports/182075 there is an update to 0.9.1 as a patch and one open question someone has to solve. Is there any chance to see an update to this port? Are you still interested in this project or is the port currently abandoned? Can I help with anything to bump this to a more current (ideally: THE current) version? If you can try to coordinate with the luasec and luasocket maintainers ? -- p...@opsec.eu+49 171 3101372 6 years to go ! ___ 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: FreeBSD Port: prosody-0.8.2
Hi. On Thu, Feb 6, 2014 at 4:06 PM, Kurt Jaeger p...@opsec.eu wrote: Hi! Starting from 20.08.2013 prosody is on 0.9, 0.9.2 was released in January 2014. Have a look at http://www.freebsd.org/cgi/query-pr.cgi?pr=ports/182075 there is an update to 0.9.1 as a patch and one open question someone has to solve. Thanks for the link. I .. didn't know better to search there first. Sorry about that. So I guess I want that bug to be resolved, with a bump to 0.9.2 ideally :) Is there any chance to see an update to this port? Are you still interested in this project or is the port currently abandoned? Can I help with anything to bump this to a more current (ideally: THE current) version? If you can try to coordinate with the luasec and luasocket maintainers ? Actually I think that's a non-issue (now). The comment from lx/the maintainer of prosody claims that s2s is broken (no idea, haven't tried the patch just yet) and wonders if we'd need the forked lua dependencies. Looking at the prosody project page [1] even THEY don't realize that the situation has changed and they still point to [2] as a 'fork just to get a release out'. The luasec bug [3] was closed just a week ago - in other words: luasec proper, the official version, got a new release out and the fork should be irrelevant now. A quick chat with the prosody developers seems to confirm that. That said: The luasec changes _shouldn't_ break s2s (merely disable some features, such as PFS for TLS for example). So .. this probably now needs a bump for lua51-luasec (which lists no individual maintainer, points to po...@freebsd.org only) from 0.4 to 0.5. How would I approach that? Looking at the port myself and giving it a try? Attaching that to a bug of sorts (similar to the prosody one)? Thanks a lot/regards, Ben 1: https://prosody.im/doc/depends#luasec 2: https://prosody.im/doc/depends/luasec/prosody 3: https://github.com/brunoos/luasec/issues/3 ___ 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: FreeBSD Port: prosody-0.8.2
Hi! Starting from 20.08.2013 prosody is on 0.9, 0.9.2 was released in January 2014. Have a look at http://www.freebsd.org/cgi/query-pr.cgi?pr=ports/182075 there is an update to 0.9.1 as a patch and one open question someone has to solve. Thanks for the link. I .. didn't know better to search there first. Sorry about that. No problem, I learned to rely on http://www.freebsd.org/cgi/query-pr-summary.cgi?query only recently, as well 8-} So I guess I want that bug to be resolved, with a bump to 0.9.2 ideally :) Yes, probably. Is there any chance to see an update to this port? Are you still interested in this project or is the port currently abandoned? Can I help with anything to bump this to a more current (ideally: THE current) version? If you can try to coordinate with the luasec and luasocket maintainers ? Actually I think that's a non-issue (now). The comment from lx/the maintainer of prosody claims that s2s is broken (no idea, haven't tried the patch just yet) and wonders if we'd need the forked lua dependencies. Looking at the prosody project page [1] even THEY don't realize that the situation has changed and they still point to [2] as a 'fork just to get a release out'. The luasec bug [3] was closed just a week ago - in other words: luasec proper, the official version, got a new release out and the fork should be irrelevant now. A quick chat with the prosody developers seems to confirm that. That said: The luasec changes _shouldn't_ break s2s (merely disable some features, such as PFS for TLS for example). Well, PFS for TLS in post-Snowden-time seems like a must-have feature, but who am I to judge 8-} So .. this probably now needs a bump for lua51-luasec (which lists no individual maintainer, points to po...@freebsd.org only) from 0.4 to 0.5. Sounds plausible, yes. How would I approach that? Looking at the port myself and giving it a try? Yes, but this needs some serious investigation to try. I just had a look, and there's no distfile, you need to get it from github, etc. I normally copy the port to some work dir, and start fixing the issues that come up. Here's the script to copy the dir to ~/myp/ --- #!/usr/local/bin/bash if [ X$1 = 'X' ] then echo usage: $0 port/dir exit 1 fi if [ ! -d /usr/ports/$1 ] then echo $0: error: invalid directory '/usr/ports/$1' exit 1 fi cd ~/myp rm -rf $1 cd /usr/ports tar cf - $1 | ( cd ~/myp; tar xf -) --- If I achive a workable port, I generate a diff and submit it using send-pr. Here's the script to generate the diff: --- #!/usr/local/bin/bash if [ X$1 = 'X' ] then echo usage: $0 port/dir exit 1 fi if [ ! -d /usr/ports/$1 ] then echo $0: error: invalid directory '/usr/ports/$1' exit 1 fi if [ -d /usr/ports/$1/work ] then rm -rf /usr/ports/$1/work fi if [ -d ~/myp/$1/work ] then rm -rf ~/myp/$1/work fi cd /usr/ports diff -r -u -N $1 ~/myp/$1 --- Attaching that to a bug of sorts (similar to the prosody one)? Yes, somewhat like this. I would suggest to first experiment with smaller ports that need attention 8-} It's a steep learning curve. Check the queue for open PRs: http://www.freebsd.org/cgi/query-pr-summary.cgi?category=ports Find one with a patch, copy the port, apply the patch and try it. Submit an update to the bug-report that you have tested it and that it works. etc. It's a useful way to learn many things about software. -- p...@opsec.eu+49 171 3101372 6 years to go ! ___ 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: [FreeBSD-Ports-Announce] Time to bid farewell to the old pkg_ tools
On Wed, 5 Feb 2014 23:26:18 -0800 Kevin Oberman rkober...@gmail.com wrote: On Wed, Feb 5, 2014 at 10:45 PM, Matthew Seaman m.sea...@infracaninophile.co.uk wrote: On 05/02/2014 23:57, Kevin Oberman wrote: 1. The ports/packages system is not total crap. In fact, at the time jkh started it, it was far superior to any tool available. When I first encountered the ports, way back in 1998 or so, I was completely mind-blown that something so fantastic could exist. Yes, it was revolutionary at the time and right where FreeBSD should be -- leading the rest of the world with great innovations. However, things have changed in the last 16 years. Development of the ports as a global concept has been resting on its laurels a bit, and the rest of the world has caught up, and indeed overtaken. Partly that was due to the mindset of seeing binary packages as a second-class thing; partly due to the old pkg_tools not providing the scope to implement innovative features; partly due to pkg_tools being part of the FreeBSD base, so impossible to update over reasonable timescales due to the requirement to support older RELEASE branches. pkg(8) addresses those problems, and I hope will do so for at least the next decade. 5. The introduction of pkgng could have really been handled better and that probably increased the negative feelings about it. It was also a bit before it was really ready. It still lacks a few features I feel are quite important, but they were also missing from the old system. I don't think it's possible to make a change of this magnitude without upsetting anyone. We have been getting a lot of feedack on the lines of 'Wow! This is great. When can we have feature XYZ?' to which we frequently have to reply that XYZ can't be implemented without breaking compatibility with pkg_tools. Like sub-packages. I'd be interested to hear what features you think are missing. We will implement anything (eventually...) that there is demand for and that is technically feasible, and that fits with the overall concept of what we think a packaging system should do. There's a number of ideas in the github issue list already (usually tagged with 'longterm' or 'thinking') and we are happy for people to add to that, or to discuss ideas -- the freebsd-pkg@ list is a good place for that. One BIG one that I know is being worked is the capability to mix packages and ports effectively. If you use poudriere, you can roll your own packages with custom options and maintain things pretty reasonably, but for a single system (or two), this is a bit of overkill. As things stand, this is a real pain to use customized ports and packages from the standard FreeBSD distributions. I'm waiting with great excitement for this to appear, though I have no idea if it is near or far. -- R. Kevin Oberman, Network Engineer, Retired E-mail: rkober...@gmail.com My experience with mixing ports and packages dates back to 2.2.5 and the disasters it created. Most of the problems were created by the ports tree and package builds not being syncronized. I switched to ports exclusively and have not had those problems again. If a mechanism existed to svn update a ports tree to the revision level of the package build I would probably try to use packages for most and limit building to those ports for which non-default OPTIONS were employed. For me, this is the feature that has always been missing. I recently switched to pkgng and while there is a learning curve I think it is more versatile and efficient than its predecessor. Thanks to all who are working to make things better. Randy ___ 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: Problem compiling Squid 3.x + TP_PF (FreeBSD 10)
05/02/14 18:41(e)an, Kevin Oberman(e)k idatzi zuen: Let's see. The instructions said to notify tms...@freebsd.org. I don't see any indication that you did so. They also say to attach the config.log file. I see no attached file. While it is possible that someone other than the maintainer of the port could help, without the log file, it's pretty unlikely. Please try again after reading and following what appear to be the clear instructions supplied in the error message. Yes, you're right, sorry. Anyway, there is an open PR, ports/186378 which states the same problem that i have. I should have looked first there. ___ 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
[QAT] r343109: 8x leftovers, 4x success
Stagify. - Build ID: 20140206155000-62431 Job owner: k...@freebsd.org Buildtime: 38 minutes Enddate: Thu, 06 Feb 2014 16:27:48 GMT Revision: r343109 Repository: https://svnweb.freebsd.org/ports?view=revisionrevision=343109 - Port:devel/ptlib 2.10.10 Buildgroup: 8.4-QAT/amd64 Buildstatus: SUCCESS Log: https://qat.redports.org//~k...@freebsd.org/20140206155000-62431-272500/ptlib-2.10.10.log Buildgroup: 8.4-QAT/i386 Buildstatus: SUCCESS Log: https://qat.redports.org//~k...@freebsd.org/20140206155000-62431-272501/ptlib-2.10.10.log Buildgroup: 9.2-QAT/amd64 Buildstatus: SUCCESS Log: https://qat.redports.org//~k...@freebsd.org/20140206155000-62431-272502/ptlib-2.10.10.log Buildgroup: 9.2-QAT/i386 Buildstatus: SUCCESS Log: https://qat.redports.org//~k...@freebsd.org/20140206155000-62431-272503/ptlib-2.10.10.log - Port:net-im/ekiga 4.0.1 Buildgroup: 8.4-QAT/amd64 Buildstatus: LEFTOVERS Log: https://qat.redports.org//~k...@freebsd.org/20140206155000-62431-272504/ekiga-4.0.1.log Buildgroup: 8.4-QAT/i386 Buildstatus: LEFTOVERS Log: https://qat.redports.org//~k...@freebsd.org/20140206155000-62431-272505/ekiga-4.0.1.log Buildgroup: 9.2-QAT/amd64 Buildstatus: LEFTOVERS Log: https://qat.redports.org//~k...@freebsd.org/20140206155000-62431-272506/ekiga-4.0.1.log Buildgroup: 9.2-QAT/i386 Buildstatus: LEFTOVERS Log: https://qat.redports.org//~k...@freebsd.org/20140206155000-62431-272507/ekiga-4.0.1.log - Port:net/opal 3.10.10_2 Buildgroup: 8.4-QAT/amd64 Buildstatus: LEFTOVERS Log: https://qat.redports.org//~k...@freebsd.org/20140206155000-62431-272508/opal-3.10.10_2.log Buildgroup: 8.4-QAT/i386 Buildstatus: LEFTOVERS Log: https://qat.redports.org//~k...@freebsd.org/20140206155000-62431-272509/opal-3.10.10_2.log Buildgroup: 9.2-QAT/amd64 Buildstatus: LEFTOVERS Log: https://qat.redports.org//~k...@freebsd.org/20140206155000-62431-272510/opal-3.10.10_2.log Buildgroup: 9.2-QAT/i386 Buildstatus: LEFTOVERS Log: https://qat.redports.org//~k...@freebsd.org/20140206155000-62431-272511/opal-3.10.10_2.log -- Buildarchive URL: https://qat.redports.org/buildarchive/20140206155000-62431 redports https://qat.redports.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: [FreeBSD-Ports-Announce] Time to bid farewell to the old pkg_ tools
On Thu, Feb 6, 2014 at 8:13 AM, Randy Pratt bsd-u...@embarqmail.com wrote: On Wed, 5 Feb 2014 23:26:18 -0800 Kevin Oberman rkober...@gmail.com wrote: On Wed, Feb 5, 2014 at 10:45 PM, Matthew Seaman m.sea...@infracaninophile.co.uk wrote: On 05/02/2014 23:57, Kevin Oberman wrote: One BIG one that I know is being worked is the capability to mix packages and ports effectively. If you use poudriere, you can roll your own packages with custom options and maintain things pretty reasonably, but for a single system (or two), this is a bit of overkill. As things stand, this is a real pain to use customized ports and packages from the standard FreeBSD distributions. I'm waiting with great excitement for this to appear, though I have no idea if it is near or far. -- R. Kevin Oberman, Network Engineer, Retired E-mail: rkober...@gmail.com My experience with mixing ports and packages dates back to 2.2.5 and the disasters it created. Most of the problems were created by the ports tree and package builds not being syncronized. I switched to ports exclusively and have not had those problems again. If a mechanism existed to svn update a ports tree to the revision level of the package build I would probably try to use packages for most and limit building to those ports for which non-default OPTIONS were employed. For me, this is the feature that has always been missing. I recently switched to pkgng and while there is a learning curve I think it is more versatile and efficient than its predecessor. Thanks to all who are working to make things better. That would be a *very* useful feature. To be able to query the remote pkg repo to get the svn revision number of the ports tree that was used to build the repo. Then you could pass that to svnup/svn to sync your local ports tree to the same revision. Then you could very easily mix/match local ports installs with remote pkg installs, as the versions for everything would match. Once the multi-repo features of pkg are up to snuff, perhaps adding a local repo would also help. Any software installed via the ports tree infrastructure would get tagged as part of the local repo. Then one could query the pkg database to get a list of software that came from the local repo, so we know which bits needs to be reinstalled/upgraded from the ports tree. Which, could easily tie into poudriere (or portmaster) for building the local ports en-masse. -- Freddie Cash fjwc...@gmail.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: Making WebRTC available for FreeBSD
https://plus.google.com/110946378055202199166/posts/8iTsSCatk4x The process has been started : http://forums.freebsd.org/viewtopic.php?f=39t=44691 Dependencies needed- referenced in howto and webrtc dependencies: libbrlapi from brltty. Benefits: Native client and sever side of WebRTC applications for FreeBSD and possibly other BSDs. Eliminated dependency for Linuixlator based applications thus cutting down on hardware resource use. Eliminated need for other simulated and emulated programs to run Skype or other voice-and-video binaries. I.e. Wine, VirtualBox, qemu, et cetera, et al. Since it is known that Sony's PS4 uses FreeBSD as the basis for its OS, WebRTC could be implemented as a native application on the platform/console thus allowing users to communicater in real time while gaming. Sony surely has a voice and video chat system in mind, one that is not inter-operable with anything that doesn't bear the PlayStation brand. Why am I proposing this? 1. Adrian Chadd asked on Google+ and nowhere else. I decided to bring his proposal to the public and attempt an initial starting phase. 2. Users would not be limited to having only a few selected operating systems at their disposal. Developers could easily communicate with each other. Limit only exists for closed networks. Don't use Skype, don't need Linuxulator. 3. Real time sharing/viewing of conventions. This would give the community another window into the development of FreeBSD. 4. Companies such as IxSystems and Sony would be able to contact develoers while simultaneously working on a FreeBSD/FreeBSD_based system. Both are easily accomplished with SIP, which is an existing widely- deployed standard. Nearly all relevant platforms have at least a few SIP clients, with voice and video support, to choose from. Some clients also support encryption to secure your communications. There are quite a few available in FreeBSD ports. 5. FreeBSD developers would be able to give feedback on the development of WebRTC sources. I can't speak for all, but my feedback for WebRTC is expressed by trying as hard as possible to ignore it while blissfully using SIP for my non-textual communication needs. It is a simple matter of the web guys intentionally ignoring the existence of all else so they could have another great solution to a problem that doesn't exist within the domain of document viewer. The web browser is not a good place to do so, but if they want to take on chat in the browser, they could have simply adopted the SIP protocol, and maybe also SIMPLE protocol for text chat at the same time. Instead they invent their own, not because they had to but because they chose to. All the large companies developing one of the web browsers with significant market share are receiving significant income from advertising. The more time they get you to spend in the browser, the more ads you might see. The more tasks a browser takes on, appropriate or not, the more time you are likely to spend in the browser, seeing the ads. At best, a native client would only be a distraction that would draw developer attention which could be better spent continuing to improve SIP clients. Worse, a native client could help to legitimize WebRTC as some sort of successor to SIP, another step toward their goal of replacing the what the average users knows as the OS with web browsers in the effort to revert PCs back to serving as dumb terminals for their cloud of mainframes (albeit very fancy and smart dumb terminals). Being that I am limited on resources, is it possible that others could take over what was started? Of course others CAN, but WILL they want to is another matter. YOU CAN right now if it is important to you to pursue this distraction. ___ 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: [FreeBSD-Ports-Announce] Time to bid farewell to the old pkg_ tools
El día Thursday, February 06, 2014 a las 03:55:57PM +0100, Christopher J. Ruwe escribió: I think anybody who compiles from ports should _really_ use poudriere. I even think it should be strongly suggested in the handbook. (I'd be willing to write that up for that matter.) Please point me to the existing documentation. I don't see the string poudriere in our handbook. Thx matthias I wrote it should be suggested, which means that I think it would be a good idea, not that it already happened. I do not understand how that could be misunderstood. I have not misunderstood it. I only asked for any other existing documentation and that I do not even see the word/string in our handbook (which is ofc not your fault and which you want to improve). matthias -- Matthias Apitz | /\ ASCII Ribbon Campaign: www.asciiribbon.org E-mail: g...@unixarea.de | \ / - No HTML/RTF in E-mail WWW: http://www.unixarea.de/ | X - No proprietary attachments phone: +49-170-4527211 | / \ - Respect for open standards ___ 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: [FreeBSD-Ports-Announce] Time to bid farewell to the old pkg_ tools
Le 6 févr. 2014 à 13:27, Julian H. Stacey a écrit : you = have to spend a couple of minutes learning the basic SQL queries, which is no more difficult that learning = obtuse find and grep options. Package addicts were so myopic they ignored some people won't even use packages, just /usr/ports make. local.sqlite was immaturely shoved in without documenting it, no man 5 local.sqlite no hook there for the couple of minutes learning you assert, (no hook to believe the couple you assert). First please excuse me, this message is posted via an Apple mail system. So how to interact with local.sqlite? niobe% sqlite3 local.sqlite SQLite version 3.8.2 2013-12-06 14:53:30 Enter .help for instructions Enter SQL statements terminated with a ; sqlite .tables annotation options pkg_script categories packages pkg_shlibs deps pkg_annotation pkg_shlibs_provided directories pkg_categories pkg_shlibs_required filespkg_directories pkg_users groups pkg_groups script licenses pkg_licenses scripts mtreepkg_option shlibs option pkg_option_default users option_desc pkg_option_desc sqlite .schema packages CREATE TABLE packages (id INTEGER PRIMARY KEY,origin TEXT UNIQUE NOT NULL,name TEXT NOT NULL,version TEXT NOT NULL,comment TEXT NOT NULL,desc TEXT NOT NULL,mtree_id INTEGER REFERENCES mtree(id) ON DELETE RESTRICT ON UPDATE CASCADE,message TEXT,arch TEXT NOT NULL,maintainer TEXT NOT NULL, www TEXT,prefix TEXT NOT NULL,flatsize INTEGER NOT NULL,automatic INTEGER NOT NULL,locked INTEGER NOT NULL DEFAULT 0,licenselogic INTEGER NOT NULL,time INTEGER, manifestdigest TEXT NULL, pkg_format_version INTEGER); CREATE INDEX pkg_digest_id ON packages(origin, manifestdigest); sqlite select name,version from packages limit 10; pkg|1.2.5 xproto|7.0.25 xextproto|7.2.1 xbitmaps|1.1.1 renderproto|0.11.1 libXdmcp|1.1.1 libXau|1.0.8 libxml2|2.8.0_3 libpthread-stubs|0.3_4 kbproto|1.0.6 and to replace grepping sqlite select name,version from packages where name like '%kde%' limit 10; kdehier4|1.1.1_1 kde4-wallpapers-freebsd|1.0 pam_kde|1.0 kde4-xdg-env|1.0.1 kde4-icons-oxygen|4.10.5 kde4-shared-mime-info|1.2 kdelibs|4.10.5_2 kde-wallpapers|4.10.5 kde-base-artwork|4.10.5 polkit-kde|0.99.1 sqlite .quit niobe% From this it is easy to experiment, and the full sqlite documentation is at: http://www.sqlite.org/lang.html -- Michel Talon ta...@lpthe.jussieu.fr smime.p7s Description: S/MIME cryptographic signature
Re: [FreeBSD-Ports-Announce] Time to bid farewell to the old pkg_ tools
On 2014-02-06 13:45, Matthias Apitz wrote:
El día Thursday, February 06, 2014 a las 01:27:50PM +0100, Julian H. Stacey
escribió:
Michel Talon wrote:
The old package system was total =
crap,
local.sqlite is also crap, breaks decades of accessibility by find grep
other text pipe / search tools.
Since many years I have always compiled my (i.e. the ports I need)
from CVS or now SVN ports tree on some fast baquery maschine. After
compiling I just did something like:
# mkdir PKG
# cd PKG
# pkg_create -Rnb `cd /var/db/pkg ; ls -C1`
and moved the resulting ~1500 packages to my laptops or smaller
netbooks. Until today I'm still using the old pkg_info/_add/_create
tools and skipped pkgng until today.
Will the above procedure work fine too in the future?
Why not keep the old methods unchanged in place as today?
Yes this is even possible.
$ mkdir $space/packages/All
$ pkg create -a -o $space/packages/All
$ pkg repo $space/packages/
Populate $space/packages via http(s), nfs or ftp
on your client:
$ mkdir -p $LOCALBASE/etc/pkg/repos
$ cat _EOL $LOCALBASE/etc/pkg/repos/mapitz.conf
mapitz: {
url: $proto://$baquery_maschine/$space/packages ,
enabled : true ,
mirror_type : none
}
_EOF
On your client run '$ pkg upgrade' and you are done.
However I suspect this method changes the checksum of the packages
every time you run '$ pkg create -a -o ...', but even then only
packages that really changed PORTREVISION ... will be updated
on your client.
The better way with a fast box is to run ports-mgmt/poudriere and
also have clean packages for your fast box.
A good starting point is to create a poudriere build and sync your
/var/db/ports to $LOCALBASE/etc/poudriere.d/($build)options/ and
copy your /etc/make.conf to $LOCALBASE/etc/poudriere.d/
Then use a list of ports (pkg_info -qoa| pkg info -qoa) and fire up
a build. The next time only changed ports are rebuild.
In the past I used tinderbox with the command
$ ./tc addBuildPortsQueueEntry -b ${BUILD}
to get consistent packages and had to wait a long time (*everything*
was located in a big 20GB RAM disk and/or on SSD), with poudriere most
everything is done on zfs in a part of the time and I guess with most
in a RAM disk even faster.
A good way to play with the new tools:
Setup a jail, install parts of your packages, convert them to pkg
packages and on a second jail install this ports.
--
olli
___
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: FreeBSD Port: prosody-0.8.2
On 02/06, Benjamin Podszun wrote: If you can try to coordinate with the luasec and luasocket maintainers ? Actually I think that's a non-issue (now). The comment from lx/the maintainer of prosody claims that s2s is broken (no idea, haven't tried the patch just yet) and wonders if we'd need the forked lua dependencies. Looking at the prosody project page [1] even THEY don't realize that the situation has changed and they still point to [2] as a 'fork just to get a release out'. The luasec bug [3] was closed just a week ago - in other words: luasec proper, the official version, got a new release out and the fork should be irrelevant now. A quick chat with the prosody developers seems to confirm that. Well, that's good, at least. Thanks for investigating. That said: The luasec changes _shouldn't_ break s2s (merely disable some features, such as PFS for TLS for example). I agree! However, I was not able to successfully debug the issue with the Prosody developers. Things may well have changed now, I just want to get things fully in compliance with what the Prosody developers are using, as a test cycle of all of Prosody's functionality is quite time-consuming. So .. this probably now needs a bump for lua51-luasec (which lists no individual maintainer, points to po...@freebsd.org only) from 0.4 to 0.5. How would I approach that? Looking at the port myself and giving it a try? Attaching that to a bug of sorts (similar to the prosody one)? Tell you what -- I'll try to tackle LuaSec. If you can take a look at the Luasocket situation and perhaps bring that up with the maintainer, that'd certainly be useful. Thanks, David ___ 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: [FreeBSD-Ports-Announce] Time to bid farewell to the old pkg_ tools
On 2014-02-06 19:17, Michel Talon wrote: Le 6 févr. 2014 à 13:27, Julian H. Stacey a écrit : you = have to spend a couple of minutes learning the basic SQL queries, which is no more difficult that learning = obtuse find and grep options. Package addicts were so myopic they ignored some people won't even use packages, just /usr/ports make. local.sqlite was immaturely shoved in without documenting it, no man 5 local.sqlite no hook there for the couple of minutes learning you assert, (no hook to believe the couple you assert). First please excuse me, this message is posted via an Apple mail system. So how to interact with local.sqlite? niobe% sqlite3 local.sqlite SQLite version 3.8.2 2013-12-06 14:53:30 Enter .help for instructions Enter SQL statements terminated with a ; sqlite .tables annotation options pkg_script categories packages pkg_shlibs deps pkg_annotation pkg_shlibs_provided directories pkg_categories pkg_shlibs_required filespkg_directories pkg_users groups pkg_groups script licenses pkg_licenses scripts mtreepkg_option shlibs option pkg_option_default users option_desc pkg_option_desc sqlite .schema packages CREATE TABLE packages (id INTEGER PRIMARY KEY,origin TEXT UNIQUE NOT NULL,name TEXT NOT NULL,version TEXT NOT NULL,comment TEXT NOT NULL,desc TEXT NOT NULL,mtree_id INTEGER REFERENCES mtree(id) ON DELETE RESTRICT ON UPDATE CASCADE,message TEXT,arch TEXT NOT NULL,maintainer TEXT NOT NULL, www TEXT,prefix TEXT NOT NULL,flatsize INTEGER NOT NULL,automatic INTEGER NOT NULL,locked INTEGER NOT NULL DEFAULT 0,licenselogic INTEGER NOT NULL,time INTEGER, manifestdigest TEXT NULL, pkg_format_version INTEGER); CREATE INDEX pkg_digest_id ON packages(origin, manifestdigest); sqlite select name,version from packages limit 10; pkg|1.2.5 xproto|7.0.25 xextproto|7.2.1 xbitmaps|1.1.1 renderproto|0.11.1 libXdmcp|1.1.1 libXau|1.0.8 libxml2|2.8.0_3 libpthread-stubs|0.3_4 kbproto|1.0.6 and to replace grepping sqlite select name,version from packages where name like '%kde%' limit 10; kdehier4|1.1.1_1 kde4-wallpapers-freebsd|1.0 pam_kde|1.0 kde4-xdg-env|1.0.1 kde4-icons-oxygen|4.10.5 kde4-shared-mime-info|1.2 kdelibs|4.10.5_2 kde-wallpapers|4.10.5 kde-base-artwork|4.10.5 polkit-kde|0.99.1 sqlite .quit niobe% From this it is easy to experiment, and the full sqlite documentation is at: http://www.sqlite.org/lang.html -- Michel Talon ta...@lpthe.jussieu.fr Before someone complains Michel's examples requires sqlite on the system, it even works without this way. $ pkg shell select name,version from packages limit 10; or $ echo 'select name,version from packages limit 10;' | pkg shell -- olli ___ 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: FreeBSD Port: prosody-0.8.2
On Thu, Feb 6, 2014 at 7:55 PM, David Thiel l...@freebsd.org wrote: On 02/06, Benjamin Podszun wrote: If you can try to coordinate with the luasec and luasocket maintainers ? Actually I think that's a non-issue (now). The comment from lx/the maintainer of prosody claims that s2s is broken (no idea, haven't tried the patch just yet) and wonders if we'd need the forked lua dependencies. Looking at the prosody project page [1] even THEY don't realize that the situation has changed and they still point to [2] as a 'fork just to get a release out'. The luasec bug [3] was closed just a week ago - in other words: luasec proper, the official version, got a new release out and the fork should be irrelevant now. A quick chat with the prosody developers seems to confirm that. Well, that's good, at least. Thanks for investigating. That said: The luasec changes _shouldn't_ break s2s (merely disable some features, such as PFS for TLS for example). I agree! However, I was not able to successfully debug the issue with the Prosody developers. Things may well have changed now, I just want to get things fully in compliance with what the Prosody developers are using, as a test cycle of all of Prosody's functionality is quite time-consuming. Maybe I can help with that - since I plan to migrate/relocate and that's a core part of what I need here (which is why I'm diving into ports about 30min after my first FreeBSD installation in years). So - one tester, ready to help out. ;-) The prosody people updated their website to deprecate their luasec fork when I asked them about the new 0.5 release - so their website is now stating 'Use 0.5 if you can, we have a fork that you can use if you have no 0.5 package available just yet'. So .. this probably now needs a bump for lua51-luasec (which lists no individual maintainer, points to po...@freebsd.org only) from 0.4 to 0.5. How would I approach that? Looking at the port myself and giving it a try? Attaching that to a bug of sorts (similar to the prosody one)? Tell you what -- I'll try to tackle LuaSec. If you can take a look at the Luasocket situation and perhaps bring that up with the maintainer, that'd certainly be useful. So, I have a building luasec 0.5 here. Sortof. It fails in make package or anything _after_ make build, failing in 'install'. Obviously I'm not sure if this is just a hge hack or roughly usable.. Luasocket: Well, can you explain what you mean? Are you talking about luasec including luasocket (and again, in a prerelease 3.x version)? If you could tell me a bit more I'd be happy to invest some time/give it a go. Thanks, Ben ___ 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: [FreeBSD-Ports-Announce] Time to bid farewell to the old pkg_ tools
On 2/6/2014 17:13, Randy Pratt wrote: My experience with mixing ports and packages dates back to 2.2.5 and the disasters it created. Most of the problems were created by the ports tree and package builds not being syncronized. I switched to ports exclusively and have not had those problems again. If a mechanism existed to svn update a ports tree to the revision level of the package build I would probably try to use packages for most and limit building to those ports for which non-default OPTIONS were employed. For me, this is the feature that has always been missing. Well, there are now Quarterly branches. You should be able to use pkgs and interlace with built ports seamlessly as long as a quarterly branch is the source of both. But yes, using some random binary package set with the latest and greatest ports trunk is probably going to end badly at some point. John ___ 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: FreeBSD Port: prosody-0.8.2
On 02/06, Benjamin Podszun wrote: Maybe I can help with that - since I plan to migrate/relocate and that's a core part of what I need here (which is why I'm diving into ports about 30min after my first FreeBSD installation in years). So - one tester, ready to help out. ;-) Thanks! Luasocket: Well, can you explain what you mean? Are you talking about luasec including luasocket (and again, in a prerelease 3.x version)? If you could tell me a bit more I'd be happy to invest some time/give it a go. Ugh, I forgot about this part of the mess. So, Prosody says that Luasocket 2 is required, but the new Luasec includes luasocket 3. Do we update the Luasocket port to 3, hosted on its new GitHub repo? Does this mean that the updated Luasec and luasocket ports would actually conflict with each other? If you know or can find those answers, that'd be useful. ___ 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: [FreeBSD-Ports-Announce] Time to bid farewell to the old pkg_ tools
W dniu 2014-02-06 14:04, John Marino pisze: On 2/6/2014 13:58, Rick Miller wrote: On Thu, Feb 6, 2014 at 7:23 AM, Daniel Nebdal dneb...@gmail.com wrote: I suspect he meant a certain version, and *not* newer - sometimes you might want to hold back a package. Correct. My wish is the functionality be extended further to mean a certain version *or* newer, encompassing both features. Thus, allowing him to say port-1.1, while I say port-1.4 or newer or even port-1.0 or newer. As an observer, all I can say is Don't get your hopes up on this one. Hundreds of ports are bumped with majority dependency changes for a reason. The tree is treated as an integrated entity, not 25,000 interchangeable parts. It would take major technology shift, something closer to what PC-BSD's pbi things do/did. Ports itself isn't geared for this. Maybe some kind of package archive could be used though, if pkg solvers could be made to handle such requests. Sounds like an extremely difficult request to me though. Gentoo's portage has this capability and it works quite well. I'd love to see it in FreeBSD. -- best regards, Lukasz Wasikowski ___ 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: FreeBSD Port: prosody-0.8.2
On Thu, Feb 6, 2014 at 9:05 PM, David Thiel l...@redundancy.redundancy.orgwrote: On 02/06, Benjamin Podszun wrote: Maybe I can help with that - since I plan to migrate/relocate and that's a core part of what I need here (which is why I'm diving into ports about 30min after my first FreeBSD installation in years). So - one tester, ready to help out. ;-) Thanks! Depending on your progress: Attached the diff that bumps luasec as far as I can tell (builds, installs - but I haven't actually _used_ the package). Note: There might be atrocities in that diff. How can I know.. ;-) Luasocket: Well, can you explain what you mean? Are you talking about luasec including luasocket (and again, in a prerelease 3.x version)? If you could tell me a bit more I'd be happy to invest some time/give it a go. Ugh, I forgot about this part of the mess. So, Prosody says that Luasocket 2 is required, but the new Luasec includes luasocket 3. Do we update the Luasocket port to 3, hosted on its new GitHub repo? Does this mean that the updated Luasec and luasocket ports would actually conflict with each other? If you know or can find those answers, that'd be useful. I'll see what I can find out. According to the (generally lua-knowledgable) prosody folks these libraries might even be merged in the future.. For now I'll see if I can use the 0.9.1 patch (and bump it maybe?) so that I can prosody as my test application. On a different note: Is this back and forth okay on this list or .. too much spam? :) Ben luasec-update Description: Binary data ___ 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: bsd.apache.mk Malformed conditional when APACHE_VERSION defined
On 2014-02-03 08:32, Dewayne Geraghty wrote:
On 2/02/2014 9:51 PM, olli hauer wrote:
On 2014-02-02 10:11, Dewayne Geraghty wrote:
I filed a PR against textproc/htdig which should really be against the
ports systems.
Would someone be kind enough to advise the current method to specify the
apache version. In ports.conf, I currently use
USE_APACHE=22 | APACHE_VERSION=22
to specify the required version of apache for:
textproc/htdig
www/mod_security
lang/php5
I believe this PR
http://www.freebsd.org/cgi/query-pr.cgi?pr=186364
which probably should be routed to the ports system, and not textproc/htdig
The error is:
cd /usr/ports/textproc/htdig make -V UNIQUENAME
/usr/ports/Mk/bsd.apache.mk, line 306: warning: String comparison
operator should be either == or !=
/usr/ports/Mk/bsd.apache.mk, line 306: Malformed conditional
(!empty(_APACHE_VERSION_MINIMUM) (${_APACHE_VERSION}
${_APACHE_VERSION_MINIMUM}))
/usr/ports/Mk/bsd.port.mk, line 6603: if-less endif
make: fatal errors encountered -- cannot continue
which goes away if APACHE_VERSION isn't used, eg.
cd /usr/ports/textproc/htdig make __MAKE_CONF=/dev/null -V UNIQUENAME
htdig
Hi Dewayne,
APACHE_VERSION is a read only variable in case a port needs to know the
installed / default Apache version - do not set this variable!
In case you want to specify a default apache use in etc/make.conf for example
APACHE_PORT=www/apache22
See lines 12 - 25 in Mk/bsd.apache.mk
Olli,
Thank-you for pointing me to the right place. I've removed
APACHE_VERSION=22;
but noted that
PERL_VERSION=5.16.3 | PYTHON_VERSION=python2.7
remain valid, which maintains my confusion.
With the ongoing changes to the ports system, I've also retained this line in
make.conf
DEFAULT_VERSIONS=perl5=5.16 python=2.7 python2=2.7 apache=22
Apache ports don't support the DEFAULT_VERSIONS variable because there are 5
different
apache22 flavors that cannot run in a mix.
See output from the command
$ egrep 'apache2[24]' /usr/ports/www/Makefile | awk '{print www/ $3}'
www/apache22 (default prefork)
www/apache22-event-mpm
www/apache22-itk-mpm
www/apache22-peruser-mpm
www/apache22-worker-mpm
www/apache24
So the only supported way for apache is to specify for example
APACHE_PORT= www/apache22-worker-mpm
Though I suspect that using the latter is preferred and should be the stable
way of constricting versions?
The last rebuild of all ports occurred on Jan 20, strange that
APACHE_VERSION=22 didn't halt that rebuild cycle, as bsd.apache.mk has been
changed for 2 months... One of life's mysteries.
The build of the www/htdig port has changed a little bit and does no longer
include explicit bsd.apache.mk so your issue popped up.
Anyway if you run the www/apache22 port and not one of the 4 other flavors you
don't need to specify anything.
PS:
can I close PR 186364
--
Regards,
olli
___
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: [FreeBSD-Ports-Announce] Time to bid farewell to the old pkg_ tools
On 06/02/2014 12:45, Matthias Apitz wrote: Since many years I have always compiled my (i.e. the ports I need) from CVS or now SVN ports tree on some fast baquery maschine. After compiling I just did something like: # mkdir PKG # cd PKG # pkg_create -Rnb `cd /var/db/pkg ; ls -C1` and moved the resulting ~1500 packages to my laptops or smaller netbooks. Until today I'm still using the old pkg_info/_add/_create tools and skipped pkgng until today. Much the same except the pkgng command line is: pkg create -a There are fancier approaches to doing this sort of thing involving creating your own package repository (which is a lot easier than it sounds -- basically 'pkg repo /directory/where/your/pkgs/are' and then you can tell pkg to install from there by using a file:// URL for the packagesite. However, this is all optional and you can simply install what you want using 'pkg add'. Cheers, Matthew -- Dr Matthew J Seaman MA, D.Phil. PGP: http://www.infracaninophile.co.uk/pgpkey signature.asc Description: OpenPGP digital signature
Re: FreeBSD Port: prosody-0.8.2
I'll see what I can find out. According to the (generally lua-knowledgable) prosody folks these libraries might even be merged in the future.. For now I'll see if I can use the 0.9.1 patch (and bump it maybe?) so that I can prosody as my test application. Sorry for replying to myself. I fixed a minor issue in the luasec patch and formatted it to apply more easily. Plus, I created a patch for prosody and sent a follow-up to ports/182075. I'd be glad to get some feedback, especially from you, David. Would be awesome to get this in somehow. Regards, Ben luasec-update Description: Binary data ___ 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: graphics/rawtherapee: r342622 crashes on HEAD
Hi, I just faced the same problem. On Thu, 06 Feb 2014 10:27:12 +0100 Rainer Hurling rhur...@gwdg.de wrote: Am 06.02.2014 08:52 (UTC+1) schrieb Baptiste Daroussin: On Thu, Feb 06, 2014 at 07:03:22AM +0100, Rainer Hurling wrote: Am 05.02.2014 22:20 (UTC+1) schrieb Baptiste Daroussin: On Wed, Feb 05, 2014 at 09:19:51PM +0100, Matthias Andree wrote: Am 05.02.2014 21:08, schrieb Dimitry Andric: #17 0x484c0ee0 in std::__1::locale::id::__next_id () from /usr/local/lib/libc++.so.1 Hmm, is this a ports version of libc++? I was not aware Baptiste had already committed this? :) Yes, it is (as a build requisite, but apparently remained installed on the destination machine), because we need to match the libraries that the requisites use (Glibmm for one). I have given up on compiling RawTherapee with clang++ for now, and use GCC 4.8 on all systems. RawTherapee is somewhat demanding, especially at higher optimization level, and kills the 10.0-RELEASE base clang and Port GCC 4.6 and 4.7, all with internal compiler errors. Since GCC 4.8 worked for me, I did not bother to send Gerald the details. We may want to retry with clang if we've got the next clang version. Feel free to use Rawtherapee as compiler system test ;) try with something like this in libmap.conf libc++.so.1 /usr/local/lib/libc++.so.1 If that fixes the problem, then a rpath with /usr/local/lib should be set while building the port Hmm, I am not very familiar with libmapping. After adding it to /etc/libmap.conf I get #rawtherapee Shared object /usr/local/lib/libc++.so.1 not found, required by rawtherapee Thanks for the tip, Rainer regards, Bapt try reinstalling devel/libc++ and keeping the libmap.conf entry, that should do the trick as it was a build only dep it may have been removed. just remove the line from libmap.conf before reinstalling devel/libc++ and readd it once it is installed. I commented out libmap.conf entry, reinstalled devel/libc++ and readded libmap.conf entry. After that, I get the same error, when starting rawtherapee. In a second step I tried to rebuild graphics/rawtherapee with the entry in /etc/libmap.conf active. That also fails with: [..snip..] /bin/mkdir -p /usr/ports/graphics/rawtherapee/work/.build Shared object /usr/local/lib/libc++.so.1 not found, required by cmake *** Error code 1 Stop. make[1]: stopped in /usr/ports/graphics/rawtherapee *** Error code 1 It looks to me that the entry in libmap.conf is not even needed as there is a link in /usr/local/lib anyway. Rawtherapee is a very sensitive program from my point of view. It works after one update and it crashes after the next. It might also be just random. Erich ___ 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
10.0-release jail on head-hosted tinderbox (Was: Re: 10.0-hosted tinderbox: 8.4 builds broken?)
On Sun, Oct 13, 2013 at 01:36:45PM +0100, Chris Rees wrote:
It appears that really weird SRCBASE assumptions are made throughout the
code. I'll have to put a temporary hack in to just make SRCBASE appear
inside the chroot whatever it's set to. Setting and unsetting SRCBASE just
breaks different things in weird ways, and this is the only reliable fix
I've found.
Joe, please can I stick this in, and merge to the beta?
http://www.bayofrum.net/~crees/patches/tinderbox-fake-srcbase.diff
Alexey, try this patch. This one definitely works for me, and gets the
dependencies working correctly.
Can be unrelated, but I've been observing some bad behavior with fresh
tinderbox code from CVS and equally fresh -CURRENT (just tried again
today): install FreeBSD/amd64, 'cvs up', rebuild world/kernel (GENERIC),
cvs co tinderbox, create jails for 10.0-RELEASE and 9.2-RELEASE. Builds
for 9.2 work fine; trying to build anything for 10.0 always fails in a
similar way (take a look at attached make.0 file). I've seen this on
i386/non-zfs as well. Particularly, these lines look bad:
/buildscript: pkg-static: not found
tar: Error opening archive: Failed to open 'pkg-1.2.6.txz'
/buildscript: ./pkg-static: not found
error in dependency pkg-1.2.6.txz, exiting
./danfe
pcre-8.34
/usr/ports/devel/pcre
chroot is: /usr/home/danfe/tb/10.0-wip
jailname is: j100-wip
ERROR: Port, devel/pcre is not in the datastore.
10.0-wip: cleaning out /usr/home/danfe/tb/10.0-wip/usr/local
10.0-wip: cleaning out /usr/home/danfe/tb/10.0-wip/compat
10.0-wip: cleaning out /usr/home/danfe/tb/10.0-wip/var/db/pkg
building pcre-8.34 in /usr/home/danfe/tb/10.0-wip
building pcre-8.34 in directory /usr/home/danfe/tb/10.0-wip
ELF ldconfig path: /lib /usr/lib /usr/lib/compat /usr/local/lib
32-bit compatibility ldconfig path: /usr/lib32
skipping package pkg-1.2.6.txz for pcre-8.34 since it is missing
build started at Fri Feb 7 06:32:52 UTC 2014
port directory: /usr/ports/devel/pcre
building for: 10.0-RELEASE amd64
maintained by: b...@freebsd.org
Makefile ident: $FreeBSD: head/devel/pcre/Makefile 342800 2014-02-05 17:40:42Z
bf $
prefixes: LOCALBASE=usr/local PREFIX=/usr/local
Begin Configuration:
---Begin Environment---
INDEXFILE=INDEX-10
ARCH=amd64
PORTOBJFORMAT=elf
PORTBUILD_USE_IPV6=YES
MD_SIZE=2g
X_WINDOW_SYSTEM=xorg
PAGER=more
DISTFILE_URI=
MAKELEVEL=1
TIMEOUT=7200
FTP_PASSIVE_MODE=yes
CCACHE_ENABLED=0
MASTER_SITE_OVERRIDE=file:///distcache/${DIST_SUBDIR}/
MAIL=/var/mail/root
OPTIONS_ENABLED=0
MD_FSTYPE=zfs
DISTCACHE=/distcache
PATH=/sbin:/bin:/usr/sbin:/usr/bin:/usr/games:/usr/local/sbin:/usr/local/bin:/root/bin
EDITOR=vi
pb=/usr/home/danfe/tb
HTTP_TIMEOUT=900
PACKAGES=/tmp/packages
HAVE_MOTIF=1
LOG_DIRECTORY=
PKGSUFFIX=.txz
BATCH=1
OSREL=10.0
__DSVERSION__=4.0.0
CCACHE_DIR=
LOG_COMPRESSLOGS=0
OLDPWD=/
.MAKE.LEVEL.ENV=MAKELEVEL
USA_RESIDENT=YES
DISTFILE_CACHE=/usr/ports/distfiles
WRKDIRPREFIX=/work
BRANCH=RELEASE
PWD=/usr/ports/devel/pcre
HOST_WORKDIR=
OPTIONS_DIR=
PKGZIPCMD=bzip2
USER=root
DISTDIR=/tmp/distfiles
HOME=/root
CCACHE_JAIL=0
LOG_DOCOPY=0
CCACHE_MAX_SIZE=1G
UNAME_m=amd64
UNAME_n=tinderbox.host
CCACHE_NOLINK=1
TINDERD_SLEEPTIME=120
FTP_TIMEOUT=900
PARALLEL_PACKAGE_BUILD=1
TINDERD_LOGFILE=/dev/null
UNAME_p=amd64
CCACHE_LOGFILE=
UNAME_r=10.0-RELEASE
LOCALBASE=/usr/local
UNAME_s=FreeBSD
PACKAGE_BUILDING=1
TINDERBOX_BUILDING=1
OSVERSION=1000510
UNAME_v=FreeBSD 10.0-RELEASE #0: Fri Feb 7 10:32:31 MSK 2014
r...@tinderbox.host:/usr/src/sys/magic/kernel/path
BLOCKSIZE=K
PORTBUILD_USE_IPV4=YES
---End Environment---
---Begin OPTIONS List---
=== The following configuration options are available for pcre-8.34:
STACK_RECURSION=on: Use the stack for recursion during matching
=== Use 'make config' to modify these settings
---End OPTIONS List---
End Configuration.
PKG_DEPENDS=pkg-1.2.6.txz
FETCH_DEPENDS=
PATCH_DEPENDS=
EXTRACT_DEPENDS=
BUILD_DEPENDS=
RUN_DEPENDS=
TEST_DEPENDS=
add_pkg pkg-1.2.6.txz
adding dependencies
pkg_add pkg-1.2.6.txz
/buildscript: pkg-static: not found
tar: Error opening archive: Failed to open 'pkg-1.2.6.txz'
/buildscript: ./pkg-static: not found
error in dependency pkg-1.2.6.txz, exiting
ERROR: Port, devel/pcre is not in the datastore.
ERROR: Port, devel/pcre is not in the datastore.
[: -gt: unexpected operator
ERROR: Port, devel/pcre is not in the datastore.
ERROR: Port, x11-toolkits/pango is not in the datastore.
ERROR: Port, graphics/cairo is not in the datastore.
ERROR: Port, devel/gobject-introspection is not in the datastore.
ERROR: Port, x11-toolkits/pangox-compat is not in the datastore.
ERROR: Port, games/gtkradiant is not in the datastore.
ERROR: Port, devel/glib20 is not in the datastore.
ERROR: Port, print/harfbuzz is not in the datastore.
ERROR: Port, misc/shared-mime-info is not in the datastore.
ERROR: Port, x11-toolkits/gtkglext is not in the datastore.
ERROR: Port, graphics/gtk-update-icon-cache is not in the datastore.
ERROR: Port, x11-toolkits/gtk20 is not in the datastore.
ERROR:
