Re: RFT: Please help testing the llvm/clang 3.5.0 import
On Dec 18, 2014, at 5:02, Dimitry Andric d...@freebsd.org wrote: On 18 Dec 2014, at 02:17, NGie Cooper yaneurab...@gmail.com wrote: On Fri, Nov 28, 2014 at 1:03 PM, Dimitry Andric d...@freebsd.org wrote: ... As a request to speed up the build process further, - Would it be [easily] possible in the clang35 branch to bootstrap the compiler for a specific architecture? The bootstrap / cross compiler for instance always builds N targets instead of building just the desired TARGET/TARGET_ARCH combo. It's not very easy, at least not without breaking various parts of our fragile build system, but I surely want to put something like this on the TODO list for *after* the import has completed. The branch is making progress right now, and I would not want to complicate matters further by introducing yet another tricky feature. :) Fair enough :). - Could a MK_CLANG_ALL_TARGETS or something similar option be added to src.opts.mk to fine tune this process for those of us who don't want to build a cross-compile toolchain every iteration for our target MACHINE/MACHINE_ARCH? I would be fine with something like this, as long as it is turned off by default, or if it is only used for the bootstrap stages. It is actually an extremely useful feature of clang that you can target multiple architectures with one compiler binary. Yes. If make tinderbox could use this it would be useful, otherwise, for most folks it seems like a less interesting feature. A more interesting case would be to remodel the build system so it can use one toolchain (external, or pkg-ng'd, maybe?) for building an entire universe. With clang, that should be relatively easy to do. Agreed. bdrewery is working on something similar to that internally for Isilon. Building the same toolchain N times internally when building the system and your upstream revision of FreeBSD doesn’t change is like testing your sanity — not much changes with the bootstrap compiler/toolchain then! Thanks for the reply :)! signature.asc Description: Message signed with OpenPGP using GPGMail
Re: RFT: Please help testing the llvm/clang 3.5.0 import
On Dec 18, 2014, at 6:51, Warner Losh i...@bsdimp.com wrote: With the recent parallelism work, the is true. It might save a couple percent off the build time. Before those changes, though, disabling all non target arches saved about 10% of the buildworld time. I’m curious. How much is 10% in terms of minutes and with what -j value? Creating a hack to do this is easy (which is how I measured it). But Dimitry is right that creating a robust solution is hard. Even harder if you want it to be completely clean. It didn’t seem incredibly hard — it just required a bit more “generated files” in clang AFAICT. I’ll hang ten until clang35 is in so I can re-asses what’s going on with building it. I tend to agree. IMHO, supporting the work going on to bring the meta-mode stuff will pay far higher dividends than optimizing this corner of the build. True… probably will! signature.asc Description: Message signed with OpenPGP using GPGMail
Re: shells/bash port, add a knob which symlinks to /bin/bash ?
On Sep 12, 2014, at 14:38, Bryan Drewery bdrew...@freebsd.org wrote: No (as portmgr). Ports should not be touching the base system like this. Let's NOT go backwards and add a /bin/bash. In fact the /usr/bin/perl one will be removed soon as well. If we can actually eliminate ports touching /usr and / (not including /usr/local and /var) then we gain a very large memory optimization for package building by being able to ro null-mount these to the build jails. There's no reason for bash (and perl) to be exceptions to the 24000 other ports that install to /usr/local/bin. I can think of dozens of other ports that will fall into the same arguments being made here, but it does not mean it is the right thing for FreeBSD. If you want to install the symlink on your system feel free to do it. I install a static bash to /bin/bash on mine and only because I prefer bash shell and want it in / for single-user mode. That's my personal choice though. The proper fix is to fix scripts to be portable and use #! /usr/bin/env bash rather than /bin/bash. We install all packages to PREFIX=/usr/local by default. Why should a bin symlink be an exception? There's no suggestion for symlinking includes or libraries which also hit users often. Hi Bryan, I understand portmgr’s reasoning for removing these knobs as it improves “portability” (builds and runtime won’t depend on broken code), but I see the merits of making a separate package for Linux “compatibility” for the various items that people have brought up (mostly the LDAP issue and the vendor/legacy script portability issue). Plus it makes the barrier for entry lower, and less of a reason for Linux users to complain about how FreeBSD is different from Linux. Adding these as options to the port(s) won’t work for various reasons, two of which came to mind are: 1. People should be able to install packages from FreeBSD.org instead of having to roll their own ports with custom options. 2. It’s best not to build other packages on unportable (/bin/bash) behavior. Thanks! -Garrett PS I don’t agree with Fedora/FreeDesktop’s push to move everything to /usr (I think it’s a wee bit radical, to say the least, and seems like it’s optimizing the wrong thing), but it’s something to keep in mind as this non-portable decision may start working its way into upstream ports: https://fedoraproject.org/wiki/Features/UsrMove . signature.asc Description: Message signed with OpenPGP using GPGMail
Re: shells/bash port, add a knob which symlinks to /bin/bash ?
On Sep 12, 2014, at 14:53, Benjamin Kaduk ka...@mit.edu wrote: On Fri, 12 Sep 2014, Rang, Anton wrote: If you want interoperability just use /usr/bin/env bash as a shebang. That doesn't work for this use case -- the user shell coming from LDAP -- but I agree that the port shouldn't be modifying /usr/bin. Here at MIT, where our Athena environment has a long history of providing a consistent experience across many different platforms, we ended up limiting the login shells a user could select, to a whitelist we provide (/bin/sh, /usr/athena/bin/bash, and /usr/athena/bin/tcsh). (The latter two are now symlinks to the normal system shells, but they used to be custom binaries.) Some people did not like being so restricted, and set their login shell to /bin/sh, with logic in their dotfiles to re-exec a different shell depending on the current runtime environment. +1 user rc files (not that it would fix this particular case...): - https://github.com/yaneurabeya/scratch/blob/master/bayonetta/home/ngie/dot.bashrc - https://github.com/yaneurabeya/scratch/blob/master/bayonetta/home/ngie/dot.shrc-local Cheers, -Garrett signature.asc Description: Message signed with OpenPGP using GPGMail
Re: [HEADSUP] pkg(8) is now the only package management tool
On Sep 2, 2014, at 4:47, Michelle Sullivan miche...@sorbs.net wrote: Marcus von Appen wrote: Alban Hertroys haram...@gmail.com: I can totally understand that at some point it starts to get impossible to maintain two separate packaging systems and I understand that you think 2 years is enough time to shake things out, but software vendors aren't that quick. For many, 2 years is a short time. It also should be noted that everyone had enough time to raise those issues in the time between tthe announcement and now. No one did. Now that it is gone, they are brought up, while they should have been long time ago instead. It can't work that way. My 2 cents in this discussion :-). Actually I brought it up as soon as I found the EOL was a deadline for breaking pkg_* tools, was told, too late now - that was more than 2 weeks ago, less than 2 months ago (forget the date) ... I'm happy with an EOL and working to upgrade everything, I'm not happy that the EOL was not actually an EOL and it was actually a deadline. Hi Michelle, One subtle point that I wanted to ask for clarification is you thought the EOL announcement for pkg_install was going to be pkg_install is no longer going to be supported, but you can still use it, instead of pkg_install support is going to be removed from the tree -- is that correct? You'd probably hate to do this, but forking the sources and changing from portsnap to a git or svn backed ports tree that downloads a tarball snapshot might be the best resolution to this issue now... Thanks! -Garrett ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Why doesn't USE_UNZIP use the base system unzip?
So... trying to trim down dependencies in a ports build and I'm confused as to why unzip in base (it's been in base for ~5 years) isn't a sufficient replacement for archivers/unzip in ports. It doesn't seem like we're doing anything incredibly complicated with archivers/unzip, so I would think that it would be a drop-in replacement. Am I incorrect? Thanks, -Garrett PS Please CC me as I'm not currently subscribed to the list. ___ 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: Why doesn't USE_UNZIP use the base system unzip?
On Thu, May 9, 2013 at 3:57 PM, Baptiste Daroussin b...@freebsd.org wrote: On Thu, May 09, 2013 at 03:48:34PM -0700, Garrett Cooper wrote: So... trying to trim down dependencies in a ports build and I'm confused as to why unzip in base (it's been in base for ~5 years) isn't a sufficient replacement for archivers/unzip in ports. It doesn't seem like we're doing anything incredibly complicated with archivers/unzip, so I would think that it would be a drop-in replacement. Am I incorrect? Thanks, -Garrett PS Please CC me as I'm not currently subscribed to the list. Simple because libarchive doesn't support all the infozip format yet. My plan is to make USE_ZIP automatically use bsdtar (and not unzip so that FreeBSD 8.x can get it) and introduce a new USE_INFOZIP for ports that won't work with bsdtar. I have a patch for this: http://people.freebsd.org/~bapt/nounzip.diff But I didn't get time to totally exp-run it yet. Perfect -- that helps a lot (and now I know that none of the ports we are going to build require anything beyond what's in the base system. Thanks! -Garrett ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: Cross Compiling of ports Makefiles.
On Mon, Dec 31, 2012 at 6:33 AM, Michael Vale mas...@internode.on.net wrote:
-Original Message- From: Simon J. Gerraty
Sent: Friday, December 28, 2012 5:00 AM
To: Michael Vale
Cc: freebsd-hack...@freebsd.org ; freebsd-a...@freebsd.org ;
freebsd-ports@freebsd.org
Subject: Re: Cross Compiling of ports Makefiles.
Doing the same thing could also prevent the need for a DESTDIR JAIL
install at all and just use the real build machine’s build env, rather
than a jail. Regardless. We still have to install these targets and
their DESTDIR is skewed. There is a few options,
I think I know what you mean, but not clear on the their DESTDIR is
skewed bit.
You were probably thinking of PREFIX, not DESTDIR. DESTDIR in
ports-land should be an install directory wherein if I do...
./configure --prefix=/usr/local
make all
make install DESTDIR=/chroot/
It would install all (well, ok most if it needs to touch more of the
base system) of the package files into /chroot/usr/local and pathing
would be setup appropriately that way.
I'm not sure what I meant here either. Thank-you for taking the time to
read the entire e-mail! :)
One is to have a MAKEOBJDIRPREFIX like option, and redefine every
target’s DESTDIR ${makeobjDESTDIR} before running do-install. Now i’ve
yet to complete this stage, but I believe this is the way to do it.
Would it be sufficient to have an INSTALL_PREFIX and/or INSTALL_DESTDIR
so that DESTDIR can be different during install ?
[I was recently experimenting with something similar...]
So how would that work?
pre-install:
INSTALL_DESTDIR=/usr/obj/crossoutroot/
DESTDIR=${INSTALL_DESTDIR}
do-install:
? I will try something like that.
Thank-you for taking the time to reply Simon,
I've thought about this item quite a bit and while I might not have
hashed out all of the internal details, I think that it should go
something like this:
0. Run standard build/install targets which will go and create
necessary binaries into a predefined world dir.
Once the installation is complete (installworld / distribution)...
1. Mount the necessary mountpoints.
2. Install the host-compiled tools into a predefined set of
directories. Example:
/chroot/h/bin
/chroot/h/sbin
/chroot/h/usr/bin
/chroot/h/usr/libexec
/chroot/h/usr/sbin
3. Do a nullfs overlay of the host-compiled tools on top of the
target system's equivalent directories in order to provide the needed
bits for executing the build.
4. Verify sanity for the install base (just in case the new binaries
don't run on the host system due to KPI differences) with a basic
check like we use for make in `upgrade_checks`.
5. Mock up the build environment to look like the target system, like
what's described .
6. Jump into the world dir.
7. Start building/installing packages.
Notes:
I'm suggesting steps 2. and 3. because while fixing hardcoding in
ports packages is a noble effort, there's just way too much work to be
done in order to accomplish the job (we have other problems to contend
with around the ports tree) and it's an ongoing battle trying to get
everyone to use sane build methodologies (I'm making an assumption
based on several projects I've used, but many devs aren't capable
build system engineers because it takes a bit of mental skewing, so
hardcoding abounds in a number of places). Doing this will allow us to
have a working prototype quicker, so in the event that others wish to
make the process more streamlined in the future, they could do so.
Whether or not this handled in the FreeBSD build system or outside it
is an implementation detail, but for the sake of modularity (and to
keep KISS principle with the FreeBSD build system, which I would argue
is complicated enough) I would say make them separate processes.
Besides, we already have canned methods for doing this in NanoBSD,
PicoBSD, etc already -- and they really could deserve some
consolidation (speaking of which, have you looked at using these in
zrouter?).
You might want to look at FreeNAS 8.x's build architecture and use
that as a starting point for how to do things. imp@ designed the
initial system, I (gcooper@) modified it heavily, and
jhixson@/jpaetzel@ modified it more after I left iXsystems in order to
work with their plugin architecture. I can send you a copy of the
system I was starting to architect (Avatar) if you wish.
Overall, I like the direction you're going in and I'm glad someone is
picking this up. I greatly appreciate it because it's been on my
laundry list of items that need to get done for some time :).
HTH,
-Garrett
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: [PATCH] unbreak imake build when clang set as base compiler
On Wed, Sep 26, 2012 at 2:18 PM, Oliver Pinter oliver.p...@gmail.com wrote: On 9/26/12, Garrett Cooper yaneg...@gmail.com wrote: On Tue, Sep 25, 2012 at 3:37 PM, Oliver Pinter oliver.p...@gmail.com wrote: Hi all! This patch fixed the problem, when buildig imake on a machine where clang is the base the compiler (WITH_CLANG_IS_CC). (Picking a random message to reply to) Why not create PRs and CC the relevant parties? because I hope, there become this issue a mote attention ;) Or gets lost in someone's mailbox :(... of course, I create in near future a PR, but before that, I send an updated patch, and yes, I know, that this is not a clean solution, but better than nothing. Having a PR is better than a random email that will most likely get lost. I would definitely respond to: Hey $dev! I filed $PR -- can you please take a look at it? It solves '$reason'. Thanks! You might get better results this way too and less duplicated effort by multiple individuals.. just sayin'... Thanks! -Garrett ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: [PATCH] unbreak imake build when clang set as base compiler
On Tue, Sep 25, 2012 at 3:37 PM, Oliver Pinter oliver.p...@gmail.com wrote: Hi all! This patch fixed the problem, when buildig imake on a machine where clang is the base the compiler (WITH_CLANG_IS_CC). (Picking a random message to reply to) Why not create PRs and CC the relevant parties? ___ 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: pkgng suggestion: renaming /usr/sbin/pkg to /usr/sbin/pkg-bootstrap
On Fri, Aug 31, 2012 at 8:47 AM, Tijl Coosemans t...@coosemans.org wrote: On 31-08-2012 14:22, Baptiste Daroussin wrote: On Fri, Aug 31, 2012 at 08:10:50AM -0400, John Baldwin wrote: On Friday, August 31, 2012 5:59:10 am Baptiste Daroussin wrote: On Thu, Aug 30, 2012 at 01:02:06PM -1000, Doug Barton wrote: I agree with John on all counts here. Further, the idea of a self-installing package, at least for the pkg stuff itself, addresses the issue that someone else brought up about how to handle installation of pkg by the installer for a new system. I like the idea of also providing a self-installing package, and it seems really easy to do, so I'll try to see what I can do in this area I'll wrote a PoC in 5 minutes which looks pretty good, this could also be a very simple and easy way to integrate into bsdinstaller. I'll do work in that direction. Still it doesn't solve the problem of boostrapping pkgng in a fresh new box, because the user may not know where to download the pkg-setup.sh. I do think that is something bsdinstall should be able to handle, and I would certainly want bsdinstall to include a dialog that says do you want to install the package manager? Of course this is being worked on by dteske@ on his bsdconfig scripts, so yes in anycase the bsdinstaller will end up with a boostrap dialog to install pkgng. ...using a mechanism that will be supported for the lifetime of the release. My concern is that the problem with the pkg tools was never that they were tied to FreeBSD releases. If that were true then you cannot accept the bootstrap solution above because it has exactly the same problems. The problem in my opinion was simply that the source code lived in src where ports developers didn't have good access to it. And the solution for that is to turn pkg development into a third party project and import that into base from time to time. There can also be a port for it so people can use more recent versions if they want to. That's the situation for several third party tools in base. Given that the ports tree is currently supporting both the old and new pkg tools I don't think it would be a problem for them to support older versions of pkgng when the time comes, especially since the database used by pkgng is much more flexible and you can execute any sql query on it. I also suspect that with pkgng's deployment features the temptation to package and deploy base with it are going to be bigger. And if that happens you want to ship a version of pkg on the release media and be able to do package management from the fixit shell. It would also be nice if the installation could fetch the latest security fixes for the release and install the latest packages so you don't have to install a browser with known vulnerabilities, etc. That seems easy to solve with symlinks and/or putting the tarball in the release directory, so that way bsdconfig downloads the copy that lives out in the release directory instead of the latest version in ports. Once development stabilizes a bit more, it might be wise to maintain multiple `release branches` of pkgng so it's possible to maintain the level of compatibility that FreeBSD users typically expect. Thanks, -Garrett ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: pkgng suggestion: renaming /usr/sbin/pkg to /usr/sbin/pkg-bootstrap
On Fri, Aug 31, 2012 at 2:59 AM, Baptiste Daroussin b...@freebsd.org wrote: On Thu, Aug 30, 2012 at 01:02:06PM -1000, Doug Barton wrote: On 08/30/2012 07:32 AM, John Baldwin wrote: On Thursday, August 30, 2012 1:10:24 pm Chris Rees wrote: On 30 Aug 2012 18:03, John Baldwin j...@freebsd.org wrote: I agree with John on all counts here. Further, the idea of a self-installing package, at least for the pkg stuff itself, addresses the issue that someone else brought up about how to handle installation of pkg by the installer for a new system. ... Still it doesn't solve the problem of boostrapping pkgng in a fresh new box, because the user may not know where to download the pkg-setup.sh. A bit self-referential, but why not do something similar to what I proposed on http://docs.freebsd.org/cgi/getmsg.cgi?fetch=120111+0+current/freebsd-ports ? Thanks, -Garrett ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: Regression in PREFIX handling in packages
On Wed, Aug 29, 2012 at 12:48 PM, Alexander Leidinger alexan...@leidinger.net wrote: On Wed, 29 Aug 2012 15:28:36 -0400 Eitan Adler ead...@freebsd.org wrote: On 29 August 2012 15:17, Alexander Leidinger alexan...@leidinger.net wrote: Could it be that my problem comes from r231300 and I was lucky that I didn't create a package on the machine with the symlinked /usr/local and used it on a machine with a normal /usr/local? Symlinking would be a problem if you built it on one machine and installed it on another. ... Wouldn't it be better to use ---snip--- if (Prefix[0] != '/' realpath(... ---snip--- in this case? Attention: I just guessed what Prefix is and what it should contain by looking at the diff, I didn't had a look at the declaraction and assignments of Prefix. That would cause problems in some cases where someone called pkg_create -p /usr/foobar/../local If this commit causes more harm than good, please back it out -- pkg_install is going to die soon anyhow, so I'd rather not fritter away time debating its usefulness if it breaks a valid use case. Thanks, -Garrett ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: pkgng suggestion: renaming /usr/sbin/pkg to /usr/sbin/pkg-bootstrap
On Sun, 26 Aug 2012, Doug Barton wrote:
...
There really is no need to be so clever here. The bootstrapping issue is
going to be a minor annoyance that affects a small percentage of our users.
I think Doug's correct in this case about it being a one-time
problem as installing via bsdinstall, etc should take care of this (I
disagree with the small percentage of our users part though). There's
still a chicken and egg problem with installing packaging via bsdinstall,
etc though, as ports requires pkg* in order to function; I really hope
that some of the naysayers have considered this minor issue as this
would be a stop-gap to removing pkg(8) from base.
Rather than providing a solution for that problem because that's a
bigger architectural issue (and not my job to solve), I offer this patch I
quickly hacked up instead as my 2 cents for the discussion on how to make
users aware that pkg_install is dying/dead, as this is one case that
needs to be better handled.
Thanks,
-Garrett
PS It's really sad that no one really has been updating UPDATING in either
ports or src, as I think this would help alleviate the need for
unnecessary obfuscation.
Index: UPDATING
===
--- UPDATING(revision 239716)
+++ UPDATING(working copy)
@@ -24,6 +24,10 @@
disable the most expensive debugging functionality run
ln -s 'abort:false,junk:false' /etc/malloc.conf.)
+2014:
+ pkg_install has been replaced with pkgng; please see webpage
+ XXX/install port YYY for more details.
+
20120727:
The sparc64 ZFS loader has been changed to no longer try to auto-
detect ZFS providers based on diskN aliases but now requires these
Index: usr.sbin/pkg_install/version/main.c
===
--- usr.sbin/pkg_install/version/main.c (revision 239290)
+++ usr.sbin/pkg_install/version/main.c (working copy)
@@ -123,6 +123,8 @@
argc -= optind;
argv += optind;
+PKG_PORTS_MSG();
+
return pkg_perform(argv);
}
Index: usr.sbin/pkg_install/add/main.c
===
--- usr.sbin/pkg_install/add/main.c (revision 239290)
+++ usr.sbin/pkg_install/add/main.c (working copy)
@@ -215,6 +215,8 @@
argc -= optind;
argv += optind;
+PKG_PORTS_MSG();
+
if (AddMode != SLAVE) {
pkgs = (char **)malloc((argc+1) * sizeof(char *));
for (ch = 0; ch = argc; pkgs[ch++] = NULL) ;
Index: usr.sbin/pkg_install/info/main.c
===
--- usr.sbin/pkg_install/info/main.c(revision 239290)
+++ usr.sbin/pkg_install/info/main.c(working copy)
@@ -238,6 +238,8 @@
argc -= optind;
argv += optind;
+PKG_PORTS_MSG();
+
if (Flags SHOW_PTREV) {
if (!Quiet)
printf(Package tools revision: );
Index: usr.sbin/pkg_install/delete/main.c
===
--- usr.sbin/pkg_install/delete/main.c (revision 239290)
+++ usr.sbin/pkg_install/delete/main.c (working copy)
@@ -128,6 +128,8 @@
argc -= optind;
argv += optind;
+PKG_PORTS_MSG();
+
/* Get all the remaining package names, if any */
while (*argv) {
/* Don't try to apply heuristics if arguments are regexs */
Index: usr.sbin/pkg_install/create/main.c
===
--- usr.sbin/pkg_install/create/main.c (revision 239290)
+++ usr.sbin/pkg_install/create/main.c (working copy)
@@ -229,6 +229,8 @@
argc -= optind;
argv += optind;
+PKG_PORTS_MSG();
+
/* Get all the remaining package names, if any */
while (*argv)
*pkgs++ = *argv++;
Index: usr.sbin/pkg_install/lib/lib.h
===
--- usr.sbin/pkg_install/lib/lib.h (revision 239290)
+++ usr.sbin/pkg_install/lib/lib.h (working copy)
@@ -31,6 +31,7 @@
#include sys/utsname.h
#include ctype.h
#include dirent.h
+#include err.h
#include stdarg.h
#include stdio.h
#include stdlib.h
@@ -239,4 +240,33 @@
extern int AutoAnswer;
extern int Verbose;
+#defineEOL_VERSION 1100
+
+#definePKG_INSTALL_DEPRECATION_MSG \
+ pkg_install has been deprecated in favor of pkgng; please see UPDATING for
more details
+
+#if __FreeBSD_version EOL_VERSION
+
+#define PKG_PORTS_MSG() \
+do { \
+ if (Quiet) { \
+ exit(1); \
+ } else { \
+ warnx(PKG_INSTALL_DEPECATION_MSG); \
+ } \
+} while (0)
+
+#else
+
+#define PKG_PORTS_MSG() \
+do { \
+ if (Quiet) { \
+ exit(1); \
+ } else { \
+ errx(1, PKG_INSTALL_DEPRECATION_MSG); \
+ } \
+} while (0)
+
+#endif /* __FreeBSD_version EOL_VERSION */
+
#endif /* _INST_LIB_LIB_H_ */
Index: usr.sbin/pkg_install/updating/main.c
Re: pkgng 1.0 release schedule, and HEAD switch to pkgng by default schedule
On Tue, Aug 21, 2012 at 11:17 AM, Doug Barton do...@freebsd.org wrote: On 8/21/2012 6:46 AM, Baptiste Daroussin wrote: I would also like to just remove pkg_* tools from RELENG_10 if that fits the schedule. Um, no? ... What _would_ be useful is what should have been done many years ago when it was first suggested: Move the pkg_* tools to ports. It already exists -- it's just out of date / crufty: $ make describe pkg_install-20090902|/usr/ports/ports-mgmt/pkg_install|/usr/local|FreeBSD -STABLE version of the package tools|/usr/ports/ports-mgmt/pkg_install/pkg-descr|port...@freebsd.org|ports-mgmt||http://www.freebsd.org/cgi/cvsweb.cgi/src/usr.sbin/pkg_install/ It's too late for 9.1 already, but if you made that change today in HEAD, and after 9.1 (but before 8.4) you MFC it to stable/[89], then you could theoretically make pkg mandatory after 9.1 EOLs. To make my point more clear, the ports tree has to support the last release to ship with pkg_* tools in the base throughout its lifetime. To do anything else would be be a massive POLA violation. Agreed. Thanks, -Garrett ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: pkgng 1.0 release schedule, and HEAD switch to pkgng by default schedule
On Tue, Aug 21, 2012 at 1:15 PM, Doug Barton do...@freebsd.org wrote: On 8/21/2012 1:08 PM, Warner Losh wrote: On Aug 21, 2012, at 1:51 PM, Doug Barton wrote: On 8/21/2012 12:42 PM, Baptiste Daroussin wrote: On Tue, Aug 21, 2012 at 12:38:04PM -0700, Doug Barton wrote: On 8/21/2012 12:05 PM, Baptiste Daroussin wrote: 1/ if it fits the schedule: get rid of pkg_* tools in current to be able to have a fully pkgng only 10-RELEASE I think it would fit better with historic precedents to make pkg optional (but default on) in 10, and mandatory in 11. As stated before, I'm fine with removing pkg_* tools from 10 if there is robust support for them in the ports tree. I know you're excited about this project, but let's not lose sight of how big a change this is, and how important ports are to the project. That was what if it fits the schedule was about. I think what I'm trying to say, ever so politely, is that what you're suggesting isn't even an option, so it shouldn't be discussed. If you are fine with removing them if there's robust support, how can you also be suggesting that it is impossible and shouldn't be talked about? Those address different parts of the problem. Making pkg mandatory in 10 is different from where the old pkg_* tools end up. The command line tools are just the tip of the iceberg, there are a lot of interactions behind the scenes. Personally, I think we should handle this the same way that other replacement tools have been done, which is close to what Baptiste has proposed. If the new tools are totally awesome, we have replaced old tools. I don't think we have ever done a complete replacement of major infrastructure in one release. The traditional model has been to deprecate in one release, remove in the next. And in this case, it doesn't matter how awesome the new tools are, they are a MAJOR paradigm shift for how users interact with ports, and we are going to have a lot of users who take years to transition their installed base. No matter how much we may want to move fast on this, it just isn't going to be possible. What Doug mentioned (and I don't think was really considered, but is valid) would break people that use pkg_* outside of ports. I know of at least two instances where this would be the case (one case that uses pkg_* directly, and another case that uses libpkg from pkg_* 0-o...). I know it's delaying the inevitable (pkg_* is going to go away), but we shouldn't count our chickens before they've hatched as far as how pkgng needs to be used and how things might change. The optional in 8/9/10, mandatory in 11 proposal seems very sane and it allows people to get things worked out properly without too many headaches. Thanks! -Garrett ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: ports: clang: error: unsupported option '-dumpspecs'
On Wed, Dec 14, 2011 at 1:52 PM, Roman Divacky rdiva...@freebsd.org wrote: -dumpspecs is a gcc internal thing that clang will never support (it doesnt use specs). It's wrong for ports to mess with the internals of the compiler and this should be fixed in a clean way. Ie. we have to replace the -dumpspec | grep something with a saner check. The fact that gcc -dumpspecs is looked at at all is a really bad idea. Do you know which port in the tree is calling this? Thanks, -Garrett ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: ports: clang: error: unsupported option '-dumpspecs'
On Wed, Dec 14, 2011 at 3:44 PM, b. f. bf1...@googlemail.com wrote: -dumpspecs is a gcc internal thing that clang will never support (it doesnt use specs). It's wrong for ports to mess with the internals of the compiler and this should be fixed in a clean way. Ie. we have to replace the -dumpspec | grep something with a saner check. The fact that gcc -dumpspecs is looked at at all is a really bad idea. Do you know which port in the tree is calling this? As far as I know, in the Ports tree there are only: editors/emacs editors/emacs-devel graphics/OpenEXR multimedia/vdpau-video which use it in an ill-conceived (and now probably unnecessary) test for thread libraries. However, there are many more instances within the configuration scripts of various port distfiles, and I do not think that all of these are protected by tests for gcc*. Ah... great -- the -pthread vs -lpthread vs nptl vs [..] mess. Yeah... those ports should probably have PRs filed against them so upstream fixes their autoconf tests. Thanks, -Garrett ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: 10.0-CUR r226986 ports/net-mgmt/net-snmp
On Nov 3, 2011, at 8:25 PM, Matthias Apitz wrote: El día Thursday, November 03, 2011 a las 01:42:50PM -0400, b. f. escribió: No, it is not the same. You can either masquerade, by setting UNAME_r and OSVERSION, or by editing the headers and scripts that define them; or you can use WITH_FBSD10_FIX for ports that define HAS_CONFIGURE (which is implied by USE_AUTOTOOLS and GNU_CONFIGURE). Right now the masquerading is probably safer, because there are some problems with the fix that are still being resolved -- and a few ports that may fail despite the fix. But of course if you help to test without masquerading, these problems will be resolved sooner. Well, I will try to help. I have set WITH_FBSD10_FIX in /etc/make.conf; the port ports/net-mgmt/net-snmp installs: /usr/local/include/net-snmp/net-snmp-config.h with: ... /* define the system type include file here */ #define NETSNMP_SYSTEM_INCLUDE_FILE net-snmp/system/freebsd10.h ... but the named header file is not there: # ls -C1 /usr/local/include/net-snmp/system/free* /usr/local/include/net-snmp/system/freebsd.h /usr/local/include/net-snmp/system/freebsd2.h /usr/local/include/net-snmp/system/freebsd3.h /usr/local/include/net-snmp/system/freebsd4.h /usr/local/include/net-snmp/system/freebsd5.h /usr/local/include/net-snmp/system/freebsd6.h /usr/local/include/net-snmp/system/freebsd7.h /usr/local/include/net-snmp/system/freebsd8.h /usr/local/include/net-snmp/system/freebsd9.h I don't know what the correct fix ist, and for the moment I created 'freebsd10.h' as a copy of 'freebsd9.h': # cat freebsd10.h #include freebsd9.h #define freebsd8 freebsd8 +Cc: maintainer You'll need to do more than just that. Take a look at the port history for more details... -Garrett___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: HEADS UP: ports/ and 10.0-CURRENT
On Sep 28, 2011, at 10:29 AM, Hartmann, O. wrote: On 09/28/11 09:26, Hartmann, O. wrote: On 09/28/11 15:47, per...@pluto.rain.com wrote: Eitan Adler li...@eitanadler.com wrote: 2011/9/27 O. Hartmann ohart...@zedat.fu-berlin.de: Now I understand why some OS vendors have choosen the latin 10 'X' for their tenth version of their operating system ... FreeBSD XP anyone? Are you sure there's a sufficient window of opportunity? :) Window of Fortune A stupid question: I experience some strange failures on one of my FreeBSD 10.0-CURRENT/amd64 boxes. libiconv.so.3 is missing for svn. I can not install conversters/libiconv anymore, portbuild compains about a missing libintl.so.9 (huhh?), see below. Ok, libintl.so.9 is gettext. So I try reinstall gettext and it fails, also! gawk is missing libintl.so.9. So I try to reinstall gawk: portmaster gawk. But gawk complains about no intl found, so it tries to install gettext and gettext complains about not finding libintl.so.9. I'm confused! Is this due to the FreeBSD 10 issue? If not, how to repair? checking for ptrdiff_t integer literal suffix... l checking for size_t integer literal suffix... Shared object libintl.so.9 not found, required by pg_configul checking for sig_atomic_t integer literal suffix... l checking for wchar_t integer literal suffix... checking for wint_t integer literal suffix... checking for random.h... no checking for struct random_data... no checking whether wchar.h is standalone... (cached) yes configure: creating ./config.status config.status: creating Makefile Shared object libintl.so.9 not found, required by gawkconfig.status: error: could not create Makefile === Script configure failed unexpectedly. Please report the problem to gn...@freebsd.org [maintainer] and attach the /usr/ports/converters/libiconv/work/libiconv-1.13.1/config.log including the output of the failure of your make command. Also, it might be a good idea to provide an overview of all packages installed on your system (e.g. an `ls /var/db/pkg`). *** Error code 1 Stop in /usr/ports/converters/libiconv. *** Error code 1 Stop in /usr/ports/converters/libiconv. === make failed for converters/libiconv === Aborting update Terminated === You can restart from the point of failure with this command line: portmaster flags converters/libiconv Oh great.. the gawk/libintl chicken and egg problem again because the port was updated (it's in the current or ports archives, 1.5 years ago -- search for gawk). IIRC all you need to do is manually update gawk, then libintl, etc. Thanks, -Garrett___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: HEADS UP: ports/ and 10.0-CURRENT
On Wed, Sep 28, 2011 at 1:45 PM, Beech Rintoul be...@freebsd.org wrote: On Wednesday 28 September 2011 12:18:47 Doug Barton wrote: On 09/28/2011 12:39, Hartmann, O. wrote: The mess started to happen when I tried to repair a non CLANG compiling port math/gotoblas with portmaster -vf amth/gotoblas. Since this build binutils and even gettext and libiconv, I guess they got broken. Last I saw was a successful installation report from portmaster. But the libiconv.so.3 wasn't there anymore when I checked! This is a catastrophy ... I'm on FreeBSD 10.0-CURRENT r225844 It's been widely reported on the ports list that you can't do fresh ports compiles on 10-current, and won't be able to until well after 9.0-RELEASE. The primary reason is that auto* stuff doesn't understand the 2-digit release version. Solutions are to set UNAME_r=9.0-CURRENT in your environment, and/or twiddle the version in newvers.sh and rebuild/reinstall your kernel. hth, Doug So if I change /usr/src/sys/conf/newvers.sh to something like vers 9.9 I'm not going to shoot myself in the foot if I try and update? I would really like to avoid downgrading this box.I've altready been bitten once today and had to build packages on my tindy and force install. Today no, but when someone in changes something in base or ports that checks for __FreeBSD_version, yes. HTH, -Garrett ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: HEADS UP: ports/ and 10.0-CURRENT
On Sep 28, 2011, at 4:36 PM, Matt wrote: On 09/28/11 15:41, Hartmann, O. wrote: On 09/28/11 22:18, Doug Barton wrote: On 09/28/2011 12:39, Hartmann, O. wrote: The mess started to happen when I tried to repair a non CLANG compiling port math/gotoblas with portmaster -vf amth/gotoblas. Since this build binutils and even gettext and libiconv, I guess they got broken. Last I saw was a successful installation report from portmaster. But the libiconv.so.3 wasn't there anymore when I checked! This is a catastrophy ... I'm on FreeBSD 10.0-CURRENT r225844 It's been widely reported on the ports list that you can't do fresh ports compiles on 10-current, and won't be able to until well after 9.0-RELEASE. The primary reason is that auto* stuff doesn't understand the 2-digit release version. Solutions are to set UNAME_r=9.0-CURRENT in your environment, and/or twiddle the version in newvers.sh and rebuild/reinstall your kernel. hth, Doug Yes, it has been discussed. But I was too dumb to realise that the phenomenon I experienced was triggered by this. I'll stay tuned and watch when a solution is at hand. I also was apparently too dumb! Making progress with UNAME_r and newvers.sh as we speak. I was unable to compile neon29 properly with UNAME_r alone... buildkernel underway. At least it's never boring! Please be aware that some user apps like net-smp and kernel modules like nvidia-driver key in on the __FreeBSD_version number. So if it's out of sync with reality, bad things can happen as you're breaking some developers' assumptions. Thanks! -Garrett___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: HEADS UP: ports/ and 10.0-CURRENT
On Tue, 27 Sep 2011, h h wrote: Kevin Oberman kob6...@gmail.com writes: On Mon, Sep 26, 2011 at 9:03 PM, Ade Lovett a...@freebsd.org wrote: With the advent of the conversion of HEAD to 10.0-CURRENT and, as to be expected, ports/ is going to be essentially unusable for a while. The issue stems from configure scripts (to choose something completely at random) assuming that FreeBSD would never jump to a double-digit major version number, and as such, various regexps for freebsd1* (ie: FreeBSD 1.1.x) are now matching freebsd10. [...] aDe, Could an entry to this effect be added to UPDATING (with a matching entry when ports/ is unbroken). Also mention a workaround, e.g. $ export UNAME_r='9.9-BLAH' Assuming that a script's detection algorithm is simple. Please see http://unix.derkeiler.com/Mailing-Lists/FreeBSD/current/2007-07/msg00597.html for a more complete masquerading algorithm.p -Garrett ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: HEADS UP: ports/ and 10.0-CURRENT
On Mon, Sep 26, 2011 at 10:15 PM, Kevin Oberman kob6...@gmail.com wrote: On Mon, Sep 26, 2011 at 10:01 PM, Garrett Cooper yaneg...@gmail.com wrote: It's not the FreeBSD dev's fault. Unfortunately the autotools folks were microoptimizing and didn't consider that the future would come sooner than it actually did. First, I'm not complaining or criticizing any of the developers and I am very grateful to aDe for maintaining them as I get a headache every time I start looking at them. I am baffled in my attempts to parse didn't consider that the future would come sooner than it actually did. Is that what you really meant, because it's self-contradictory? Or am I just confused. It just means that folks didn't plan ahead and didn't think up proper contingency plans. FWIW FreeBSD has developed faster in the last couple of years than most folks would have expected -- including myself -- and the release cycles reflect that change. That's more of what I was addressing in my previous reply. Corner cases are the bane of all software developers. -Garrett ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: HEADS UP: ports/ and 10.0-CURRENT
On Mon, Sep 26, 2011 at 9:56 PM, Kevin Oberman kob6...@gmail.com wrote: On Mon, Sep 26, 2011 at 9:03 PM, Ade Lovett a...@freebsd.org wrote: With the advent of the conversion of HEAD to 10.0-CURRENT and, as to be expected, ports/ is going to be essentially unusable for a while. The issue stems from configure scripts (to choose something completely at random) assuming that FreeBSD would never jump to a double-digit major version number, and as such, various regexps for freebsd1* (ie: FreeBSD 1.1.x) are now matching freebsd10. This is going to be some fairly fundamental breakage. However, until such time as 9.0-RELEASE is completely out of the door, with autotools hat on, I will _not_ be committing any changes to infrastructural ports to fix this. That is to say, until 9.0-R happens, and for some considerable period afterwards, ya'll can pretty much expect ports/ to be non-functional on HEAD. PRs mentioning this will be gleefully closed referencing this message. aDe, Could an entry to this effect be added to UPDATING (with a matching entry when ports/ is unbroken). Being a pessimist, ports will never be fully unbroken unless all the thousands of autotools based ports as fixed, due to unfortunately code duplication. That being said, I think that a note in /usr/ports/UPDATING as well as /usr/src/UPDATING is a VERY good idea. Anyone running CURRENT should be reading your message, but I'm a belt and suspenders type of guy on this sort of thing. Backing out of CURRENT and moving to 9-STABLE can be a REAL pain that will likely rapidly get worse as HEAD gets less and less frozen. It's not the FreeBSD dev's fault. Unfortunately the autotools folks were microoptimizing and didn't consider that the future would come sooner than it actually did. Thanks, -Garrett ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: 8-STABLE /usr/include/utmp.h and tmpx
On Fri, Jun 3, 2011 at 5:02 PM, Aryeh Friedman aryeh.fried...@gmail.com wrote: Some time in the last 2 weeks (I am sure when) a commit caused many ports that assume a standard utmp/utmp.x to break for example x11-toolkits/vte produces: gnome-pty-helper.c:497: warning: passing argument 4 of 'pty_add' discards qualifiers from pointer target type mv -f .deps/gnome-pty-helper.Tpo .deps/gnome-pty-helper.Po cc -DHAVE_CONFIG_H -I. -I/usr/local/include -O2 -pipe -march=prescott -fno-strict-aliasing -MT gnome-utmp.o -MD -MP -MF .deps/gnome-utmp.Tpo -c -o gnome-utmp.o gnome-utmp.c gnome-utmp.c: In function 'write_login_record': gnome-utmp.c:367: warning: passing argument 1 of 'login' from incompatible pointer type gnome-utmp.c:374: error: 'struct utmpx' has no member named 'ut_name' This is not the only port that has the issue but it is the only one I remember off the top of my head (I manually fixed a few others) Compiles just fine on CURRENT. Did you open a PR for this item? Thanks, -Garrett ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: [ECFT] pkgng 0.1-alpha1: a replacement for pkg_install
On Mon, Mar 28, 2011 at 10:44 AM, Andriy Gapon a...@freebsd.org wrote: on 25/03/2011 12:11 Baptiste Daroussin said the following: Hi all, miwi@ launched the new thing called Experimental Call For Testing, it's our turn :) Julien Laffaye (jlaffaye@) and I, helped by Philippe Pepiot (huge contributor) have been working since the end of the last GSoC on a rewrite of pkg_install. pkgng is a binary package manager written from scratch for FreeBSD. After a long period of technology testing, (json, tinycdb, bdb, etc) and we now have achieved to implement the basic functionnality. We would greatly approciate to have some feedback, wider testing, patching, documenting etc, before implementing the higher level features. pkgng is built on top of a new libpkg, which allow to deal with the database of installed packages, to deal with remote repositories, manage packages: creation, installation gathering informations, registering new ports. features supported are or will be : - smooth integration with bsd.port.mk (including bsd.pkg.mk line 2486) which allow to have a bsd.port.mk which deal with both pkg_install and pkgng. (done in alpha) - the register command can analyse elf files when registering a new port to discover forgotten dependencies if necessary. (done in alpha using libelf) - the register command has two mode available : when dealing with old fashion ports it just registers the package, in new mode it does everything that would have been done by pkg add when installing the package : should display messages, execute post-install, execute @exec etc. (old fashion done in the alpha) - pkg add supports two mode : the old fashion one (no real upgrade support) and new one: upgrade scripts supported. (old fashion in the alpha) - new scripts supported +PREINSTALL +POSTINSTALL, +PREDEINSTALL, +POSTDEINSTALL, +PREUPGRADE, +POSTUPGRADE as well as the old fashion scripts : +INSTALL +DEINSTALL +UPGRADE (all supported *UPGRADES aren't supported in the alpha) - new +MANIFEST (plist-like format) with new metadatas : options, arch, os version, etc. (done in the alpha) - pkgng supports checking arch of the package which means that users won't be able to install sparc64 binary package into amd64 machines. (not done yet) - a special architecture all allows to specify when a package can be used on every architecture. (not done yet) - @dirrm and @dirrmtry are now deprecated, pkgng can discover itself which directory has to be removed. (done in the alpha but needs love :)) - new repository (apt-like feature) (only the repository generation is done) - real support for reverse dependency (no ugly +REQUIRED_BY) (done in the alpha) - test unit (libcheck) on libpkg. (done in the alpha needs some more love) - many more Perhaps I am too impatient :) but I would like to inquire about the following features: I. A provides/requires interface for packages. Each package specified a list of files (and perhaps other entities) that it provides and requires. At the initial stage, without ports modifications, these could be: (1) a list of all files installed by package for provides; (2) for requires - an auto-generated list of dependencies based on required shared libraries plus dependency specifications in ports. I think that this kind of interface should help with using alternatives that provide the same interface (e.g. like gamin vs fam). II. Package signing. That would be really nice. 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 :). IV. Convenient support for i386 packages on amd64. Distinct installation directories, proper installation conflict detection/avoidance between i386 and amd64 packages, proper library paths, etc. There are other architectures that would benefit from this as well, like powerpc 32-bit on 64-bit, MIPs 32-bit on n32, etc. This involves more work than pkgng could provide IIRC as build infrastructure would need to be fixed to look at and link against usr/lib32 instead of usr/lib, unless you mean to rewrite the linker stuff at install-time. And finally some exotic ideas - support for multiple package sources (when different people build packages in different ways (e.g. with different options, or different optimizations) from the same ports tree; support for multiple ports sources.(when people maintain different ports tree (e.g. kde or gnome development ports tree)). Perhaps, with some compatibility/hierarchy support for packages and ports sources. But that's almost a pipe dream, so don't take it seriously :) It would be nice. That's a request in the same general area that Gentoo portage's overlay goes into, but I think that would require rewriting certain bits of ports infrastructure to be extensible, not extend pkgng in this
Re: HEADS UP: Merge of binutils 2.17
On Jan 8, 2011, at 3:10 PM, Erik Cederstrand wrote: Hello Pav, Den 08/01/2011 kl. 20.34 skrev Pav Lucistnik: Package cluster is quite clever, akshully, and since this is OT here, just terse comments Sorry, replied to a bad message... redirecting to current@ 1. adding SSD disks irrelevant because of bullet 2. 2. source and destination directories on md devices already done, swap backed md devices are used 3. huge ccache cache 4. dist-cc these tend to have their own issues 5. some heuristics on which ports could be skipped because dependencies haven't changed since last run this is also already done, we call it incremental builds 6. tuning the host system for this specific task empty words I was pretty sure I couldn't improve anything with 5 minutes of thinking. I'm glad the most obvious things have already been done, and I'm sure you and others have put a lot of effort into this. My question was more what, if anything, can be done to speed up the cluster. Also, how long does it take to complete an exp-run on the cluster? Erik, As I said before, the tinderbox / exp-run infrastructure needs to be made portable, the infrastructure needs to be there, and as extra credit (I've stated this in other emails in the past) parallelization in ports/pkg_install needs to be fixed as ports/packaging in FreeBSD doesn't work in an ACID[1]-like manner. I'd rather not repeat the reasons in greater detail. Please look for my replies to this thread on current@ for more details in part A, and look for my replies on ports@ for more details in part B. Thanks, -Garrett 1. http://en.wikipedia.org/wiki/ACID___ 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
[PATCH] Upgrade devel/monotone to 0.48.1
Hi Lapo,
I noticed that the current version of devel/monotone is set at
0.48. Could you please upgrade the version to 0.48.1 with the attached
patch?
The attached patch also fixed the MASTER_SITES var.
Thanks!
-Garrett
Index: devel/monotone/Makefile
===
RCS file: /home/ncvs/ports/devel/monotone/Makefile,v
retrieving revision 1.48
diff -u -r1.48 Makefile
--- devel/monotone/Makefile 29 Jun 2010 09:07:03 - 1.48
+++ devel/monotone/Makefile 24 Oct 2010 07:30:28 -
@@ -6,9 +6,9 @@
#
PORTNAME= monotone
-PORTVERSION= 0.48
+PORTVERSION= 0.48.1
CATEGORIES= devel
-MASTER_SITES= http://monotone.ca/downloads/${PORTVERSION}/
+MASTER_SITES= http://www.monotone.ca/downloads/${PORTVERSION}/
MAINTAINER= l...@lapo.it
COMMENT= A distributed version control system with digital signatures
Index: devel/monotone/distinfo
===
RCS file: /home/ncvs/ports/devel/monotone/distinfo,v
retrieving revision 1.29
diff -u -r1.29 distinfo
--- devel/monotone/distinfo 29 Jun 2010 09:07:03 - 1.29
+++ devel/monotone/distinfo 24 Oct 2010 07:30:28 -
@@ -1,3 +1,3 @@
-MD5 (monotone-0.48.tar.gz) = 330a1fe1d92c899d1ad539606f85a9f8
-SHA256 (monotone-0.48.tar.gz) = 3149abf0e4433a0e14c5da805a04dbbc45b16086bc267d473b17e933407d839d
-SIZE (monotone-0.48.tar.gz) = 4792019
+MD5 (monotone-0.48.1.tar.gz) = b5fa9e3b02ca3dcaf58fb7a2519ef956
+SHA256 (monotone-0.48.1.tar.gz) = e5ab4917866d2c597f99577554549b7c4cda9895be7a5dd0469f1c7798fe3c10
+SIZE (monotone-0.48.1.tar.gz) = 4868557
___
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: [PATCH] Upgrade devel/monotone to 0.48.1
On Sun, Oct 24, 2010 at 9:23 AM, Sahil Tandon sa...@freebsd.org wrote: On Sun, 2010-10-24 at 00:45:01 -0700, Garrett Cooper wrote: Hi Lapo, I noticed that the current version of devel/monotone is set at 0.48. Could you please upgrade the version to 0.48.1 with the attached patch? The attached patch also fixed the MASTER_SITES var. Lapo submitted ports/151665 to update devel/monotone to 0.48.1 on Oct 23 18:00:20 UTC, and rene@ committed it earlier today. :) Hah -- ok ... something else broken recently (within the past couple of weeks) with mtn and the atf repository (mtn is complaining about database issues; I'll followup with other folks in monotone about this). Thanks, -Garrett ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: ports/146754: [patch] new port: add devel/atf framework to ports
On Tue, Aug 31, 2010 at 10:17 AM, Ade Lovett a...@freebsd.org wrote:
On Aug 29, 2010, at 20:00 , Garrett Cooper wrote:
Found the reference. The stuff that gets installed under
${PREFIX}/tests (to some degree) are actually executables
($(execdir)), and some are data files ($(datarootdir)).
Woo. Lots of fun there. :)
As much as I hate committing a port that has known issues (in this case
hier(7) breakage), I can certainly see the value in having it in the tree.
So. Here's the deal. I'll go ahead and commit it, adding a note that it
currently isn't hier(7) safe (just a note, not an IGNORE/BROKEN/whatever).
However, if in 6 months, or two version jumps, whichever comes first, it is
still not heir(7) safe, then I _will_ mark it BROKEN.
Unless anyone else can thing of an utter show-stopper, this would seem to be
the best compromise.
Understood.
Thanks,
-Garrett
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: ports/146754: [patch] new port: add devel/atf framework to ports
On Fri, Aug 20, 2010 at 2:22 PM, Garrett Cooper yaneg...@gmail.com wrote:
On Fri, Aug 20, 2010 at 12:39 PM, Ade Lovett a...@freebsd.org wrote:
On Aug 19, 2010, at 20:30 , Garrett Cooper wrote:
This request has been sitting mostly idle for the last 3 months. I
realize people are busy, but could someone with some time please help
me work out any issues that might exist with this port, and commit
this to ports? There are a _lot_ of developers that would be happy to
see this committed to ports so they can add unittests for their work,
and I would like to see this committed so I can start writing real
testcases for pkg_install.
It looks relatively straightforward. My only concern is the bunch of files
being dumped into ${PREFIX}/tests, which violates hier(7). Would it be
possible to move them to, say ${PREFIX}/share/${PORTNAME}/tests ??
It might be but I'll have to check with Julio from NetBSD about that
because this is how things install today; they use a fixed version in
NetBSD though instead of from pkgsrc, and it hasn't gained a lot of
traction outside of a smaller niche of users, so I might be able to
convince him to change the default (or at least parameterize it so it
conforms to hier(7)).
Found the reference. The stuff that gets installed under
${PREFIX}/tests (to some degree) are actually executables
($(execdir)), and some are data files ($(datarootdir)). The author --
Julio -- used $(execdir) for everything... incorrectly as you noted,
but I think that this should be resolved at a later date (say, when
0.11 rolls out?) because I don't know what functional issues might
arise if I start monkeying around with paths right now.
The package upstream is already at 0.10, and I would rather get
this in and resolve issues as they come instead of waiting for
perfection, if that's ok.. atf is still a rather fledgling project
that's changing a bit from release to release, and is being modified
on a regular basis, so just waiting for things to resolve themselves
will be more hurtful than beneficial. I want to get to the 0.11
release though in the next hop, so I'd be more than happy to work
towards achieving that goal in that period of time (0.12 at the
latest).
Thoughts?
-Garrett
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: ports/146754: [patch] new port: add devel/atf framework to ports
On Fri, Aug 20, 2010 at 12:39 PM, Ade Lovett a...@freebsd.org wrote:
On Aug 19, 2010, at 20:30 , Garrett Cooper wrote:
This request has been sitting mostly idle for the last 3 months. I
realize people are busy, but could someone with some time please help
me work out any issues that might exist with this port, and commit
this to ports? There are a _lot_ of developers that would be happy to
see this committed to ports so they can add unittests for their work,
and I would like to see this committed so I can start writing real
testcases for pkg_install.
It looks relatively straightforward. My only concern is the bunch of files
being dumped into ${PREFIX}/tests, which violates hier(7). Would it be
possible to move them to, say ${PREFIX}/share/${PORTNAME}/tests ??
It might be but I'll have to check with Julio from NetBSD about that
because this is how things install today; they use a fixed version in
NetBSD though instead of from pkgsrc, and it hasn't gained a lot of
traction outside of a smaller niche of users, so I might be able to
convince him to change the default (or at least parameterize it so it
conforms to hier(7)).
Thanks!
-Garrett
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: what next for the pkg_install rewrite
On Aug 20, 2010, at 9:27 AM, Anonymous wrote: Garrett Cooper yaneurab...@gmail.com writes: The emphasis that Florent made too was to remove crud in pkg_install and libpkg and get things down to more of a library form so we could develop thin wrappers above pkg_install with logical functions (like apt-get, yum, etc does with fetching, whereas rpm does with installation, etc), instead of maintaining pkg_install the way it is today. From perspective of a user I'd like those wrappers be written in a scripted language so they're easy to hack. Because sh(1) doesn't have smth like FFI we'd need one command that exports all functions from the library. Some port managing tools could then bypass those wrappers when doing complex tasks. As long as we don't get into wrapper script hell (greater than 2 levels deep), sure :).___ 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/146754: [patch] new port: add devel/atf framework to ports
This request has been sitting mostly idle for the last 3 months. I realize people are busy, but could someone with some time please help me work out any issues that might exist with this port, and commit this to ports? There are a _lot_ of developers that would be happy to see this committed to ports so they can add unittests for their work, and I would like to see this committed so I can start writing real testcases for pkg_install. Thanks, -Garrett ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: what next for the pkg_install rewrite
On Thu, Aug 19, 2010 at 3:10 PM, Ivan Voras ivo...@freebsd.org wrote:
On 19/08/2010, jhell jh...@dataix.net wrote:
Adding to this I would like to see a central database created for
packages that have been removed like in Slackware Linux. They keep a
file in /var/log/preserved_packages with a flat text format with the
file name looking like:
${PORTNAME}-${PORTVERSION}${PORTREVISION}-`date +%Y%m%d%H%M%S`
Please no. We need another ad hoc text format like we need holes in our head.
Ah yes, you reminded me of this other thing: I would also suggest
getting rid of text files carrying rich information in ad-hoc formats
:)
I'm not saying XML should be the only choice, but it *is* well
supported - expat is even in base as libbsdxml.
While suggesting nebulous things I know will be hard to pass near a
lot of people: sqlite is *the* choice for any record-based file
databases today. The single most important thing I'll promote with it
is its transaction capabilities and ACID - these would get much use if
parallel operations (upgrades / installs) are to be supported. There
are a ton of other reasons too.
I started writing this a long time ago but abandoned it because of
strong opposition: http://wiki.freebsd.org/PortsUsingSQLite - maybe it
would help at this time.
There are a lot of ideas going around, but unless the current patches
get polished up and portmgr (points in flz's general direction)
actually accept ideas, ideas are nothing more than ideas and will
essentially be vaporware. That has been the chokepoint for patches
I've added to the PR database.
Also, if it breaks backwards compatibility used everywhere over the
map and is actually functionality that's used in ports and src
packages without equivalent functionality, it's a non-starter.
If any work needs to be done, we should be getting _rid_ of features
which aren't in use, or can be easily replaced with equivalent
methods. Stuff I've identified over the past year that can be worked
on are:
pkg_install
Locking:
- We need concurrent package installation.
Packing list:
@dirrmtry (needs to be replaced with scripting infrastructure called
via +INSTALL/+DEINSTALL). See @exec/@unexec (similar problem).
@exec/@unexec (needs to be replaced with scripting infrastructure
using +INSTALL/+DEINSTALL).
@group/@mode/@owner (needs to be replaced with scripting infrastructure).
@srcdir really shouldn't be in a plist (someone can script the call
easily with pkg_create).
At the end of the day, it would be really nice if there was one small
file with the package metadata, and the other file was checksums via
an mtree file. mtree files will solve a lot of the problems with the
ad hoc plist `format'.
@noinst should be checked to see whether or not it's widely used in
ports. It might be a good idea to implement, but I'm not confident in
that statement.
Dependencies:
- We should be using reverse dependencies, not forward dependencies.
There's less value in forward dependencies, because I can uninstall
things, and I don't have an accurate idea of what the current state is
on the system. Reverse dependencies actually tell us _what_ we depend
on, and should be expressed in terms of origins, not package versions.
Whenever the version for the origins change, the package should be
bumped. This would (IMO) reduce a lot of headaches with packages.
INDEX*:
- We should depend on INDEX* for package data, and it should be
distributed with the base system, not ports, and ports should build
off of this data.
*libpkg*!!:
- I emphasize this, because it's extremely important... David/Florent
are already doing work to make this a reality, BUT we shouldn't be
duplicating their work. It would be nice if the work being done by
both Florent and David was more transparent, could be tasked out to
various individuals, etc... but that's not how it is today.
Ports
bsd.*.mk:
- Needs to use pkg_add / pkg_create out of the box instead of
installing things directly into DESTDIR/LOCALBASE. This would
avoid a lot of issues with corrupted installs, etc.
- [Nice to have] should be trimmed wherever possible. There's a lot of
cruft that actually could be moved elsewhere to reduce the amount of
work in terms of parsing and evaluating statements for everyday ports
users.
In general:
- Ports need to be fixed so that BUILD_DEPENDS and RUN_DEPENDS don't
end up in the package dependency list. We suffer from this in areas,
Redhat suffers from this, etc, and it's not an easy task to do.
However, if done properly, this will 1) speed up package building, 2)
package installation, 3) reduce installed package count, etc.
Just for the sake of not repeating past discussions:
1. SQLite was killed before because of complexity and because it was
needs another package in base that isn't BSD licensed. That's why
everyone in the know has been pushing for BDB 1.8x (in base). People
suggested that to me back when I was trying to get off the ground in
GSoC
Re: what next for the pkg_install rewrite
On Aug 19, 2010, at 7:30 PM, jhell wrote:
On 08/19/2010 21:26, Garrett Cooper wrote:
On Thu, Aug 19, 2010 at 3:10 PM, Ivan Voras ivo...@freebsd.org wrote:
On 19/08/2010, jhell jh...@dataix.net wrote:
Adding to this I would like to see a central database created for
packages that have been removed like in Slackware Linux. They keep a
file in /var/log/preserved_packages with a flat text format with the
file name looking like:
${PORTNAME}-${PORTVERSION}${PORTREVISION}-`date +%Y%m%d%H%M%S`
Please no. We need another ad hoc text format like we need holes in our head.
You may have misunderstood or maybe not the intention behind that file.
This is just simply a log file of the transactions that were performed
upon package deletion and nothing more but just a way for the user to
look back and say HEY! how did that get there!. or where in the
``jhell'' did that file come from! that they can simply grep the
package removal logs to find out.
-- Shameless plug with my email name put in for humor.
:)
It is also really handy if you remove some packages that somehow the
depends had been messed up and later on your having a problem with a
missing lib, easy enough to grep the removal logs to find out what
package held that file. Especially useful if you only use binary packages.
This is part of the request that someone was making for a feature like Gentoo's
world file on the forums: http://forums.freebsd.org/showthread.php?t=16963 .
Personally it's one of the takeaways I like about Gentoo's portage system
because it's easy to track what I as a user installed manually, and hence, it's
easy to track what can be removed (instead of using pkg_cutleaves) if we have a
`emerge -C` (package dependency [dist]clean equivalent). It also makes it
easier for admins to mass install packages on multiple machines using a smaller
`distroot' install binary base, so all I would have to do is:
1. Install prebuilt version of FreeBSD with sysinstall / ad hoc installer
method.
2. Say, pkg_add install all, force options
3. Do whatever I need to do to configure the machine.
Done.
That would make system administration really easy and slick, and would improve
the setup process for corporations that build on a static FreeBSD base for
several releases and have varying packages for several bits. I know if my group
did it, things wouldn't be such a mess..
By the way... /var/lib/portage/world is a simple text file composed line by
line like:
pkg-origin-a
pkg-origin-b
i.e.
devel/gcc46
lang/python26
www/firefox36
etc. Simple and easy to understand, and easy to modify :).
There is a lot of information that can be logged, especially with '-v',
I personally do not think we or anyone for that matter should pass up
that opportunity to make sure the information is collected rather than
leaving it up to the user to redirect or script(1) the output every time
which they would still or should be able to do.
Another approach that I have not seen talked about here is a proposed
directory layout. I think before 'unless I missed it' that someone jumps
into this, some standards goals should be made and made quite loudly
as to attract as much public opinion and suggestions as possible for
what works, what does not what people would like to see.
Something of this magnitude like changing packaging databases and
directory structures and all that involved needs a central place and a
clear, clean plan to be developed properly. I personally do not see this
list anymore as a proper place to discuss it. packaging@ list request ?
so this can all be centralized.
I agree that it's high time that a freebsd-packaging@ list be created.
sysinstall has its own list now -- we should have one for the packaging
software too :).
PS: I have been toying with the idea of the directory layout just for
spurring thoughts of others. http://bit.ly/aNLhNU but until there is a
central place for these things it does not mean much.
I think that you're adding unnecessary complexity to the overall issue. It
really doesn't make sense for me to install packages that aren't available for
my architecture for one (in particular today), unless you were thinking of
serving up this data on an NFS server, but even then it doesn't make sense
because almost all of these files are hardcoded to exist at ${LOCALBASE} when
built as ports, so setting it to another location would be problematic. Other
things would need to be done before you could get to this stage.
Also, many of the ports installed are prefixed with the package name, which is
different for multiple ports. Example:
$ ls /var/db/pkg/python*
python-2.6,2/ python26-2.6.5_1/ python31-3.1.2_1/
Having a concept of multiple versions in ports would require a major overhaul
to get things to work in a Gentoo like method, and I'm not sure how many people
would be particularly keen in doing this (especially when there are name
Re: devel/subversion
On Wed, Jul 7, 2010 at 10:02 AM, Greg Larkin glar...@freebsd.org wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 andrew clarke wrote: On Wed 2010-07-07 02:06:39 UTC+1000, andrew clarke (m...@ozzmosis.com) wrote: Can anyone confirm that subversion fails to build with www/neon28 and requires www/neon29? This is not mentioned in UPDATING. Building subversion 1.6.11_3 with neon28-0.28.6_1 installed: === Configuring for subversion-1.6.11_3 configure: Configuring Subversion 1.6.11 ... checking for pkg-config... /usr/local/bin/pkg-config configure: checking neon library checking neon library version... 0.28.6 configure: error: cannot find Neon === Script configure failed unexpectedly. Please report the problem to l...@freebsd.org [maintainer] and attach the /usr/ports/devel/subversion/work/subversion-1.6.11/config.log including the Looking at config.log: configure:5698: cc -o conftest -O2 -fno-strict-aliasing -pipe -g -O2 -I/usr/local/include/neon -L/usr/local/lib -L/usr/local/lib/db42 conftest.c -L/usr/local/lib -lneon 5 /usr/local/lib/libneon.so: undefined reference to `SSL_SESSION_cmp' At this point I thought I should try rebuilding openssl-1.0.0_2, however while that's re-building I decide to grep for SSL_SESSION_cmp in the neon29-0.29.3_1 sources and find this comment: OpenSSL 1.0 removed SSL_SESSION_cmp for no apparent reason with an apparent fix. So my conclusion is that building subversion needs neon29 to be installed if you're using OpenSSL 1.0. And this should probably be mentioned in UPDATING... Thanks, Regards Andrew Hi Andrew, I confirmed the problem here with these ports installed prior to upgrading to Subversion 1.6.12: openssl-1.0.0_2 SSL and crypto library neon28-0.28.6_1 An HTTP and WebDAV client library for Unix systems Eventually, this issue should be resolved by the following PR (http://www.freebsd.org/cgi/query-pr.cgi?pr=ports/148295), but a full port build has to be performed by portmgr first. In the mean time, I think an entry in UPDATING would be helpful. Would you mind writing one and assigning it to me in the PR system? I resolved the problem by issuing the command: portmaster -o www/neon29 neon28 and proceeding with the devel/subversion build. Certain bits probably need to be added to detect the version incompatibility and recommend an upgrade and/or CONFLICTS, maybe? -Garrett ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Request for removal of ports maintainership
Hi, I'm currently removing things from my tasklist that I don't have time to work on, or pay attention to, and I have a handful of ports that I should be removed from the maintainership for: archivers/py-lzma archivers/py-tarfile comms/py-serial devel/py-ctypes devel/py-nose devel/py-plex devel/py-repl misc/posixtestsuite net-mgmt/py-snmp py-tarfile (in python proper since 2.3) and py-ctypes (in python proper since 2.4) should be deprecated, along with py-snmp eventually (py-snmp4 will supersede py-snmp). Thanks, -Garrett ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: devel/subversion
On Tue, Jul 6, 2010 at 9:06 AM, andrew clarke m...@ozzmosis.com wrote: Can anyone confirm that subversion fails to build with www/neon28 and requires www/neon29? This is not mentioned in UPDATING. I'm using neon28 and subversion without issues here, but I'm running CURRENT. Thanks, -Garrett ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: Address for www/linux-nvu maintainer
On Sun, Jul 4, 2010 at 11:30 AM, Jerry freebsd-ports.u...@seibercom.net wrote: I am attempting top contact the maintainer of the www/linux-nvu port. I did a make maintainer in the port and this was revealed: /usr/ports/www/linux-nvu $ make maintainer i...@space.rootshell.ru Unfortunately, this address is not operational. I received the follow bounce message: Delivery to the following recipient failed permanently: i...@space.rootshell.ru Technical details of permanent failure: Google tried to deliver your message, but it was rejected by the recipient domain. We recommend contacting the other email provider for further information about the cause of this error. The error that the other server returned was: 550 550 5.7.1 i...@space.rootshell.ru... Mail disabled for this domain (state 14). The address did seem a little strange thought. In any case, does anyone have an email address for this maintainer or has he also abandoned this port? The domain is dead, so the email address needs to be reset to po...@freebsd.org, or whoever picks up the port next. -Garrett ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: Confirming a bug in clang++ (freeBSD
On Thu, Jul 1, 2010 at 1:07 PM, Anonymous swel...@gmail.com wrote: Anonymous swel...@gmail.com writes: It's better to use -lstdc++ from same version of gcc by which the program using it was compiled. Is it possible to determine which one? No. If there is an easy way I think strings(1) would show. Doh, $ strings $LOCALBASE/lib/libLLVM* | fgrep GCC GCC: (GNU) 4.5.1 20100617 (prerelease) Oops. This is part of the reason why whenever there's a compiler upgrade in Gentoo Linux land I always built the toolchain twice . -Garrett ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: posix test suite port source code
On Wed, Jun 30, 2010 at 11:22 AM, Greg Larkin glar...@freebsd.org wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Dave Abel wrote: Any idea how I can get my hands on the posix test suite port source code? It is not avaiable via their website currently. Any help you can offer would be much appreciated. Is there a method by which I can access the source code of ports through FreeBSD? I am currently running FreeBSD 8.0 as a Guest OS on VMware player (host is win 7). Thanks! Dave Hi Dave, You can download the source code tarball here: http://sourceforge.net/projects/posixtest/files/ Whenever you want to fetch the distfile for a FreeBSD port, just cd into the port directory and type: make fetch e.g.: cd /usr/ports/misc/posixtestsuite make fetch Most ports will fetch their distfile into /usr/ports/distfiles (or a subdir of that), except for certain tools that require a manual download. Hang tight for another couple of weeks. I'm cleaning up the open posix testsuite from within the LTP (sf.net/projects/ltp) repository (I have to merge over some of their changes), and once that's done I'll see about backporting bits (if the maintainers are still around..) and/or publishing a revised copy that _is_ more POSIX compliant as the testsuite as-is has a number of bash'isms, gmake'isms, and Linux'isms. Some work needs to be done to bring the tests up to spec and sort out all of the XOPEN/XSI extensions. Thanks, -Garrett ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: Early CONFLICTS detection is POLA viloation?
2010/6/27 Lev Serebryakov l...@freebsd.org: Hello, Freebsd-ports. I understand, that this change (ports/137855, bsd.port.mk:1.632) was made 6 months ago, but I've noticed it only now (twice in one day!). Am I only person, who thinks, that this change is HUGE POLA violation? PR says about big tarball is downloaded and CONFLICTS are detected after that, but I've have two more realistic scenarios, when early conflict detection is VERY annoying. Thry are real-life scenarios, occured today for me in a row. (1) I have `subversion' port installed, and want to `makesum' in updated subversion-freebsd port directory (because I'm maintainer and need to update port with new version, which have new tarball). OOPS. I cannot even download new tarball -- confilct is detected. (2) I want upgrade perl from 5.8.x to 5.10.x. Type command: #portupgrade -rfo lang/petl5.10 perl-5.8.9_3 Ooops, confilct is detected, upgraid failed. G! Maybe, early conflict detection should only print WARNING, and only install target should be blocked by it, as everybody used for MANY years? I'm in a similar boat as you when I was trying to eval some of the linux base / dist ports recently. I would think that the CONFLICTS detection should only be a warning in the first run-through, and become a hard error when you try and run make install. Thanks, -Garrett ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: New pkg-message[.in] guideline idea
On Thu, Jun 24, 2010 at 9:43 AM, David DEMELIER
demelier.da...@gmail.com wrote:
2010/6/24 Freddie Cash fjwc...@gmail.com:
On Thu, Jun 24, 2010 at 12:04 AM, David DEMELIER
demelier.da...@gmail.com wrote:
2010/6/24 Janne Snabb sn...@epipe.com:
On Wed, 23 Jun 2010, David DEMELIER wrote:
2010/6/23 Janne Snabb sn...@epipe.com:
I find it completely useless and plainly stupid to edit the
pkg-messages of all ports to include lots of equal signs for tty-based
formatting purposes.
We can take a long time to do that (we don't have to do it quickly),
but it could be useful to standardize it for one reason :
You will see that it's a message from the port maintainer/submitter
and not from the program itself! Sometimes configure scripts stage say
some useless things to the user.
You obviously did not get my point.
I fully agree with you that displaying a line of equals signs on
tty based interfaces to make the messages stand out from other crap
when installing ports makes sense, but I STRONGLY oppose to the
idea of putting this visual formatting in the actual message files.
It is just not the right place to put it in.
I see, so maybe in the future you would like some tools that can print
the message, like a GTK+ dialog, QT dialog, or an other tool, if it's
your point I agree. I don't specially want a equal == line, I would
just something consistent, why not : nothing ? Yes we can just print
the text without any visual characters, and the [future] tool will
print the message as it want.
No, what he's saying is:
- put the logic to print the separators into the appropriate bsd.*.mk file
- remove all separators from all pkg-message* files
That way, you can update the separators at any time by editing a
single file, instead of editing 20,000+ pkg-message files. And, that
way, future tools can override the separator set in the mk file.
Leave the pkg-message files as unformatted text. Put the formatting
into the mk file.
Separate content from style.
Yes, that was I said, sorry if you did not understand well :-)
The only problem is that pushing all of this logic into bsd.*.mk only
solves half the problem: from source installations. It doesn't cover
binary installations via pkg_install.
I think Doug and Phillip were on the right track with pushing the data
into a pkg_install consumable format, but the only problem is that
creating additional code that handles one more corner case for
@comment will serve to only slow down the plist parser unnecessarily.
That's why I was suggesting a scripting infrastructure, like so:
pkgmsg() {
local message=$1
pkgmsg_separator
echo $message
pkgmsg_separator
}
Example:
echo This is an install message for my awesome new package
foo-BLAH +DISPLAY
pkgmsg `cat +DISPLAY`
And considering that you almost get the functionality for free via
pkg_install (from pkg_create(8)):
-D displayfile
Display the file (by concatenating it to stdout) after installing
the package. Useful for things like legal notices on almost-free
software, etc.
The thing about using a script function like pkgmsg too is that it can
be dynamically overwritten by certain groups in order to tailor the
messages (or mute output for customer purposes after everything has
passed QA if they use pkg_install in a product) to the meet their
needs when doing localized installations or deployments as well.
So, why not just add the relevant bits as I described?
Thanks,
-Garrett
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: lang/perl5.10 doesn't build with gcc 4.5.1
On Sat, Jun 19, 2010 at 8:25 AM, b. f. bf1...@googlemail.com wrote:
lang/perl5.* fails with -fstack-protector in CFLAGS, when built with
the base system compiler, on some architectures. I used the attached
patch with the base system compiler and lang/perl5.10 on 9-CURRENT
i386 to fix the problem. However, I never attempted to use it with
lang/gcc45, because I did not want to introduce circular dependencies
in my ports. Your problem may be related.
This patch's logic is inverted:
$ make -f Makefile.cflags_test
-fstack-protector -fstack-protector-all
$ cat Makefile.cflags_test
CFLAGS+=-fstack-protector -fstack-protector-all -funroll-loops
all:
@echo ${CFLAGS:M-fstack-protector*}
I think you wanted :N...
HTH,
-Garrett
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: License Framework: Develop Best Practices
On Tue, Jun 15, 2010 at 1:29 PM, Marco Bröder marco.broe...@gmx.eu wrote: On Tue June 15 2010 09:10:49 Janne Snabb wrote: As a previous poster pointed out, I also think that the different BSD licences should be separated. Yes, they really are different licenses. The BSD license has evolved over time. Compare the 4-clause license to the 3-clause license and the 2-clause license. Who else should it know better than the FreeBSD Project (and NetBSD, OpenBSD, DragonflyBSD, ...)? ;-) -Garrett ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: License Framework: Develop Best Practices
On Tue, Jun 15, 2010 at 1:39 PM, Garrett Cooper yanef...@gmail.com wrote: On Tue, Jun 15, 2010 at 1:29 PM, Marco Bröder marco.broe...@gmx.eu wrote: On Tue June 15 2010 09:10:49 Janne Snabb wrote: As a previous poster pointed out, I also think that the different BSD licences should be separated. Yes, they really are different licenses. The BSD license has evolved over time. Compare the 4-clause license to the 3-clause license and the 2-clause license. Who else should it know better than the FreeBSD Project (and NetBSD, OpenBSD, DragonflyBSD, ...)? ;-) Ugh... my brain went out to lunch. Please ignore my last reply. -Garrett ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: graphics/png fails on FreeBSD 8.1-beta1/powerpc - is xz broken on this platform?
On Sun, Jun 13, 2010 at 2:50 PM, Torfinn Ingolfsen tin...@gmail.com wrote: I am trying to install the graphics/png port on my PowerMac G4, which runs 8.1-beta1: r...@kg-g4# uname -a FreeBSD kg-g4.kg4.no 8.1-BETA1 FreeBSD 8.1-BETA1 #0: Fri May 28 04:38:56 UTC 2010 r...@xserve.lan.xcllnt.net:/usr/obj/usr/src/sys/GENERIC powerpc r...@kg-g4# cd /usr/ports/graphics/png r...@kg-g4# make clean === Cleaning for png-1.4.1_1 r...@kg-g4# make === Vulnerability check disabled, database not found === License check disabled, port has not defined LICENSE === Found saved configuration for png-1.4.1_1 === Extracting for png-1.4.1_1 = MD5 Checksum OK for libpng-1.4.1.tar.xz. = SHA256 Checksum OK for libpng-1.4.1.tar.xz. /usr/bin/xz: /usr/ports/distfiles//libpng-1.4.1.tar.xz: Compressed data is corrupt === Patching for png-1.4.1_1 === Applying FreeBSD patches for png-1.4.1_1 patch: can't cd to /usr/ports/graphics/png/work/libpng-1.4.1: No such file or directory = Patch patch-ac failed to apply cleanly. *** Error code 1 Stop in /usr/ports/graphics/png. *** Error code 1 Stop in /usr/ports/graphics/png. r...@kg-g4# which xz /usr/bin/xz r...@kg-g4# pkg_info -W xz r...@kg-g4# xz --version xz (XZ Utils) 4.999.9beta liblzma 4.999.9beta When I try to do this on my amd64 workstation it works without problem. The difference is that it runs 8.0-stable: r...@kg-v2# uname -a FreeBSD kg-v2.kg4.no 8.0-STABLE FreeBSD 8.0-STABLE #2: Sun Apr 11 19:39:02 CEST 2010 r...@kg-v2.kg4.no:/usr/obj/usr/src/sys/GENERIC amd64 and that xz is installed from a port: r...@kg-v2# which xz /usr/local/bin/xz r...@kg-v2# pkg_info -W xz /usr/local/bin/xz was installed by package xz-4.999.9_1 r...@kg-v2# xz --version xz (XZ Utils) 4.999.9beta liblzma 4.999.9beta What else could be wrong? Update: I installed xz from the port (edited IGNORE out of the Makefile), renamed /usr/bin/xz, and now then png port install sucessfully. This should be fixed with src revision r209089 . It was occurring because the little-endian generated config.h file got committed. HTH, -Garrett ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: Manually registering dependencies for ports
On Sun, Jun 6, 2010 at 4:53 PM, Thomas Rasmussen tho...@gibfest.dk wrote: Hello, I've been wondering about something: When I write a script or webapp that needs some port to run, like a perl module, I install the needed port and life is good (tm). A year later when I've completely forgotten about the script I go do some spring-cleaning of the ports on the server, and I see some perl module that doesn't have any dependencies, and delete it. Fast forward a few days when I discover the script doesn't work anymore, cue face-palm, remove bullet from foot, etc. Is there some way I can register a dependency to prevent this ? Like adding a flag to an installed port to say something outside of the ports system depends on this along with a user specified comment string. A system like that could result in something like this: pkg_delete -x p5-something pkg_delete: p5-something cant be uninstalled because: somescript.pl uses this module, for the love of everything good do not delete it Is something like this already implemented, or does anyone have suggestions to where I might begin if I want to make this ? Am I the only FreeBSD admin absent-minded enough to have this problem ? :) Best regards Thomas Steen Rasmussen PS: I know that this kind of hand-holding is uncommon in FreeBSD. We allow all kinds of foot-shooting, but a safeguard like this would be a nice improvement to an (IMO) already excellent ports system. It would probably just be better to create ports Makefiles for this and then run a make install ; that way you have all of the required metadata for the package you just created. If you go this route you'll need several skeleton files to create a complete port. You can look at any port, or here's another simple example port ( http://p4db.freebsd.org/depotTreeBrowser.cgi?FSPC=//depot/user/gcooper/ports/devel/atfHIDEDEL=NO ). Feel free to skip the pkg-deinstall script. HTH, -Garrett ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
mpich2 installation problem
On Sat, Jun 5, 2010 at 1:17 AM, PA Zolczynski zolczyn...@googlemail.com wrote: On 05/06/2010 08:42, Garrett Cooper wrote: 2010/6/4 PA Zolczynski zolczyn...@googlemail.com: See `config.log' for more details. === Script configure failed unexpectedly. Please report the problem to po...@freebsd.org [maintainer] and attach the /usr/ports/net/mpich2/work/mpich2-1.2.1p1/config.log including the output of the failure of your make command. Also, it might be a good idea to provide an overview of all packages installed on your system (e.g. an `ls /var/db/pkg`). *** Error code 1 Does execinfo.1 exist /usr/local ? Thanks, -Garrett thanks Garrett, cd /usr/ports/devel/libexecinfo ; make install helped, it ok now This was probably the result of an incomplete package or port install because the OP installed the port and magically the issue went away... If you look at the configure log nowhere does it actually state that -lexecinfo was added to the LDFLAGS or LDLIBS by the OP. Thanks, -Garrett ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: mpich2 installation problem
On Sat, Jun 5, 2010 at 9:00 PM, Garrett Cooper yanef...@gmail.com wrote: On Sat, Jun 5, 2010 at 1:17 AM, PA Zolczynski zolczyn...@googlemail.com wrote: On 05/06/2010 08:42, Garrett Cooper wrote: 2010/6/4 PA Zolczynski zolczyn...@googlemail.com: See `config.log' for more details. === Script configure failed unexpectedly. Please report the problem to po...@freebsd.org [maintainer] and attach the /usr/ports/net/mpich2/work/mpich2-1.2.1p1/config.log including the output of the failure of your make command. Also, it might be a good idea to provide an overview of all packages installed on your system (e.g. an `ls /var/db/pkg`). *** Error code 1 Does execinfo.1 exist /usr/local ? Thanks, -Garrett thanks Garrett, cd /usr/ports/devel/libexecinfo ; make install helped, it ok now This was probably the result of an incomplete package or port install because the OP installed the port and magically the issue went away... If you look at the configure log nowhere does it actually state that -lexecinfo was added to the LDFLAGS or LDLIBS by the OP. nm, spoke too soon... it was set in LDFLAGS (sigh). Sorry for the noise... -Garrett ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: How to know which version of an apps available in various FreeBSD release?
On Wed, Jun 2, 2010 at 2:09 AM, Emanuel Haupt eha...@freebsd.org wrote: Tao Wang dancef...@gmail.com wrote: Hi, I'm doing a survey about the availablilty of some packages in different platform, including FreeBSD release. I want to know whether the package is existed in the specific FreeBSD release, and which version it is? I found: http://www.freebsd.org/ports/ , however, it is only against -STABLE or -CURRENT. I also need to know the information on previous release. How to do it? Thanks. All the information you need is available in INDEX: http://www.FreeBSD.org/ports/INDEX-8.bz2 That only works for the head of each branch though, right? Thanks, -Garrett ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: Direct or indirect libdependencies (using the libintl.so.8 case)
On Wed, Jun 2, 2010 at 1:36 AM, Michel Talon ta...@lpthe.jussieu.fr wrote: Garrett Cooper wrote: followed consistently. I know that the decisions are made on a case-by-case basis, but for my taste, it is too much case-by-case. I haven't done portmaster -af in a long time, but unfortunately some things aren't working as expected (gthumb segfaults on certain directories), so here we go... In fact these remarks combined show that there are fundamental problems in the port system, a thing which has been remarked since a long time, but is regularly denied by many people. Basically it is not in a shape to be reliably maintained by automatic procedures, contrary to some concurrence. How to solve the problem, i don't know. The lack of reverse dependencies in the pkg_install metadata and the fact that pkg_install falls back to ports and INDEX (which is produced by ports) for pkg_version is partly to blame. The cruxt of the majority of the issues is with the larger package groups, and the fact that there are some implicit reverse dependencies that aren't properly resolved because they aren't present in ports. There are a handful people looking into pkg_install right now (sort of similar to the way that sysinstall is being treated right now); it's my goal to take a crack at fixing this problem when I get the archive(5) pieces in and pkg_install locking work as well. Other folks are working at fixing how everything is componentized and fits together in the big picture. So in summary... there will be a lot of good work coming out of this area as well, so hopefully these next couple of FreeBSD releases will be much easier to maintain than the past couple have been from a packaging perspective. Thanks, -Garrett ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: FreeBSD Port: python26-2.6.5
On Mon, May 31, 2010 at 9:49 AM, Bernardo Maciel bernardo.mac...@gmail.com wrote: Hello, I recently ran into a problem when compiling python 2.6.5 under FreeBSD 8.0-p2 . I searched around, asked in FreeBSD forums ( http://forums.freebsd.org/showthread.php?t=14268 ) and then e-mailed the python-help mailing list. The problem isn't yet solved. My problem is that when I compile python 2.6.5, I get a sem_init: No space left on device message when the script is building the _ssl extension: ... Increase the value of the kern.ipc.shmall sysctl because you have other applications eating up POSIX shmem in the background. HTH, -Garrett ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: Building ports with stack-protector
On Sat, May 29, 2010 at 7:19 PM, Janne Snabb sn...@epipe.com wrote: Hi, Big thanks to the folks who made make buildworld to use -fstack-protector by default since 8.0. This should make FreeBSD more secure. How about the ports system? I tried to re-build all my ports some time ago with the stack-protector enabled by adding -fstack-protector in CFLAGS in /etc/make.conf. Most ports build work fine with this enabled, but there are several exceptions. Some libraries cannot be compiled with this (either the build fails or linking other programs which use the library later fail). Also some programs that do strange things fail to build or run. IMHO it would make sense to make some sort of framework in the ports system to support this. I think there should be a port Makefile knob which tells if the port can be built with the stack-protector or not. Now it is difficult to determine on port-by-port basis if it can be enabled or not. Is there any work or plans to accomplish this? It would be great to compile at least all the network facing server programs with this enabled. I have an impression that more than 90% of programs can be compiled with the stack-protector. For libraries the percentage might be less. What do you think? While this might be an interesting feature, I think that there must be a line drawn at what is and what isn't acceptable to maintain. Check and see whether or not a similar feature exists in other compilers. If so, then I'd start noting which ports are and which aren't usable with this feature, and maybe approach the portmgr folks to see what they think. Maintaining this feature would be a pain though because it would require a lot more QA work beyond just seeing whether or not things build. Cheers, -Garrett ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: Users and groups kept after a port deinstallation
On May 24, 2010, at 9:22 AM, Alexander Churanov wrote: 2010/5/23 jhell jh...@dataix.net: That shouldn't actually be to hard. If a utility like the three main upgrade tools that are being used the most right now would export a variable for say UPGRADING=yes then the uninstall script could check against that to decide whether or not the port is being removed or upgraded and make the proper decision while alerting the admin to whats going on. Folks, May be is' better to add another make target, called update, which would invoke deinstall, followed by reinstall? This would encapsulate the mechanism inside port.mk. I'm going to have toe disagree with you on this. Using pkg_install with the appropriate install/deinstall scripts would better solve the installation and deletion scenarios properly (especially because adding code like this to port.mk would be haphazard in cases where you need to specify a specific DESTDIR, PREFIX, etc). Thanks, -Garrett___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: port installation
On Sun, May 23, 2010 at 3:25 PM, madal 30 mada...@hotmail.com wrote: Hello here, I am a new freebsd user and would like to know how to install port from link below: http://www.freebsd.org/cgi/cvsweb.cgi/ports/net-mgmt/nav/ There are not much info on howto for this particular package. Any help or guide would be appreciated. Hi, The documentation you're looking for can be found here: http://www.freebsd.org/doc/handbook/ports.html . The port corresponds to net-mgmt/nav in the ports tree on your machine. HTH, -Garrett ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: port installation
On May 23, 2010, at 4:22 PM, Indi wrote: On Sun, May 23, 2010 at 03:40:47PM -0700, Garrett Cooper wrote: On Sun, May 23, 2010 at 3:25 PM, madal 30 mada...@hotmail.com wrote: Hello here, I am a new freebsd user and would like to know how to install port from link below: http://www.freebsd.org/cgi/cvsweb.cgi/ports/net-mgmt/nav/ There are not much info on howto for this particular package. Any help or guide would be appreciated. Hi, The documentation you're looking for can be found here: http://www.freebsd.org/doc/handbook/ports.html . The port corresponds to net-mgmt/nav in the ports tree on your machine. Really? That port doesn't exist on my machine... (just portsnapped today) It was removed ages ago (read through the cvs history for the port and you'll figure out why). Thanks, -Garrett___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: new upstream tracker (linuxtesting.org)
On Sat, May 22, 2010 at 4:54 AM, Andrey Ponomarenko susa...@ispras.ru wrote: Hello, I'm from ISPRAS and we have created an experimental system for monitoring and analyzing of upstream libraries development. It may be helpful for analyzing risks of updating one of the distribution components (shared libraries). The web page of upstream-tracker is: http://linuxtesting.org/upstream-tracker/ It now includes ABI changes analysis and API shallow test results for several versions of 60 popular open source libraries. Any bugs or feature requests are welcome. Thanks. Just out of curiosity, is this a system for monitoring the 3rd party libraries that have been imported into our base system, or is it a generic tool for running testcases? I'll poke at it further, in the meantime, but it would be helpful if an expert could comment on the issue more :). I ask because Linux in and of itself doesn't really have a base system and everything's packages from the get-go, whereas *BSD has a userland with some 3rd party packages all wrapped into one base system. Also, how do you `test' the applications -- using the runtime tests produced in previous versions, or by just executing applications and observing whether or not the API calls pass or fail? Thanks! -Garrett ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: new upstream tracker (linuxtesting.org)
On Sat, May 22, 2010 at 6:12 AM, Andrey Ponomarenko susa...@ispras.ru wrote: On 05/22/2010 04:30 PM, Kostik Belousov wrote: On Sat, May 22, 2010 at 03:54:20PM +0400, Andrey Ponomarenko wrote: Hello, I'm from ISPRAS and we have created an experimental system for monitoring and analyzing of upstream libraries development. It may be helpful for analyzing risks of updating one of the distribution components (shared libraries). The web page of upstream-tracker is: http://linuxtesting.org/upstream-tracker/ It now includes ABI changes analysis and API shallow test results for several versions of 60 popular open source libraries. Any bugs or feature requests are welcome. Thanks. WOW. Can you, please, share the setup of the tracker ? The tool itself is very young and is not well documented yet. Although the first version has been recently released under dual GNU GPL and LGPL licenses: http://ispras.linuxfoundation.org/index.php/Upstream_Tracker We are not recommended to use this version of the tool by yourself. Very soon we will release 1.1 version containing a lot of bug fixes and new features. Unfortunately this could only be added to the base system as a port today as it depends on perl (something that was tossed from the base system many moons ago because of cross-building issues). I'll poke around at the software and port it to FreeBSD because it looks interesting though and does provide a relatively simple interface for digesting test results. It would be amazingly interesting if you added FreeBSD base system libraries to the tracker. Provide, please, the list of necessary libraries. It would be extremely interesting and useful for us to see changes among releases and tips of the stable and head branches. Thanks, -Garrett ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: new upstream tracker (linuxtesting.org)
On Sat, May 22, 2010 at 12:32 PM, Garrett Cooper yanef...@gmail.com wrote: On Sat, May 22, 2010 at 6:12 AM, Andrey Ponomarenko susa...@ispras.ru wrote: On 05/22/2010 04:30 PM, Kostik Belousov wrote: On Sat, May 22, 2010 at 03:54:20PM +0400, Andrey Ponomarenko wrote: Hello, I'm from ISPRAS and we have created an experimental system for monitoring and analyzing of upstream libraries development. It may be helpful for analyzing risks of updating one of the distribution components (shared libraries). The web page of upstream-tracker is: http://linuxtesting.org/upstream-tracker/ It now includes ABI changes analysis and API shallow test results for several versions of 60 popular open source libraries. Any bugs or feature requests are welcome. Thanks. WOW. Can you, please, share the setup of the tracker ? The tool itself is very young and is not well documented yet. Although the first version has been recently released under dual GNU GPL and LGPL licenses: http://ispras.linuxfoundation.org/index.php/Upstream_Tracker We are not recommended to use this version of the tool by yourself. Very soon we will release 1.1 version containing a lot of bug fixes and new features. Unfortunately this could only be added to the base system as a port today as it depends on perl (something that was tossed from the base system many moons ago because of cross-building issues). I'll poke around at the software and port it to FreeBSD because it looks interesting though and does provide a relatively simple interface for digesting test results. There are several portability issues with the perl scripts that should be resolved for this to be usable outside of Linux. I'll file bugs for these bits. It would be amazingly interesting if you added FreeBSD base system libraries to the tracker. Provide, please, the list of necessary libraries. It would be extremely interesting and useful for us to see changes among releases and tips of the stable and head branches. Thanks, -Garrett ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: new upstream tracker (linuxtesting.org)
On Sat, May 22, 2010 at 12:58 PM, Garrett Cooper yanef...@gmail.com wrote: On Sat, May 22, 2010 at 12:32 PM, Garrett Cooper yanef...@gmail.com wrote: On Sat, May 22, 2010 at 6:12 AM, Andrey Ponomarenko susa...@ispras.ru wrote: On 05/22/2010 04:30 PM, Kostik Belousov wrote: On Sat, May 22, 2010 at 03:54:20PM +0400, Andrey Ponomarenko wrote: Hello, I'm from ISPRAS and we have created an experimental system for monitoring and analyzing of upstream libraries development. It may be helpful for analyzing risks of updating one of the distribution components (shared libraries). The web page of upstream-tracker is: http://linuxtesting.org/upstream-tracker/ It now includes ABI changes analysis and API shallow test results for several versions of 60 popular open source libraries. Any bugs or feature requests are welcome. Thanks. WOW. Can you, please, share the setup of the tracker ? The tool itself is very young and is not well documented yet. Although the first version has been recently released under dual GNU GPL and LGPL licenses: http://ispras.linuxfoundation.org/index.php/Upstream_Tracker We are not recommended to use this version of the tool by yourself. Very soon we will release 1.1 version containing a lot of bug fixes and new features. Unfortunately this could only be added to the base system as a port today as it depends on perl (something that was tossed from the base system many moons ago because of cross-building issues). I'll poke around at the software and port it to FreeBSD because it looks interesting though and does provide a relatively simple interface for digesting test results. There are several portability issues with the perl scripts that should be resolved for this to be usable outside of Linux. I'll file bugs for these bits. It would be amazingly interesting if you added FreeBSD base system libraries to the tracker. Provide, please, the list of necessary libraries. It would be extremely interesting and useful for us to see changes among releases and tips of the stable and head branches. Wow... there's so much grown code in this project that it quite frankly scares me (20k lines of perl code... yikes). I need to look into implementing a clean design with my ballista rewrite in python, because the lack of modularity and the number of gcc-isms and linux-isms in this isn't really super portable. But that's several months or maybe a year down the line. Thanks, -Garrett ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: How to extract tcl src
On Sat, May 22, 2010 at 7:11 PM, jhell jh...@dataix.net wrote:
On 05/22/2010 19:23, Anonymous wrote:
BUILD_DEPENDS= ${NONEXISTENT}:${PORTSDIR}/lang/tcl85:extract
Attached is the Makefile I just edited to configure against tcl and tk
8.5 instead of 8.4.
I have verified it for functionality (as in) extract, configure, make
install only.
Before I made the mods I did not make a original copy so this is why I
did not provide a unified diff but I have bumped the the PORTREVISION
from _1 to _2 and it should be ready to be committed as this was a
pretty trivial change.
The most significant change mentioned above was changed to:
BUILD_DEPENDS= ${NONEXISTENT}:${PORTSDIR}/lang/tcl85:configure
This was needed to provide configured values that graphics/togl would
then read.
The danger in this particular case is that you're assuming that
the copy of tcl installed and the copy in ports are one in the same.
Just pre-patch whatever code is monkey fubaring the path lookup to point to:
${LIBDIR}/tcl-version/tclConfig.sh
and file the appropriate bug upstream to fix whatever software
package is monkeying up the path.
HTH,
-Garrett
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: Users and groups kept after a port deinstallation
On Fri, May 21, 2010 at 4:53 PM, RW rwmailli...@googlemail.com wrote: On Fri, 21 May 2010 16:23:18 +0100 Florent Thoumie f...@xbsd.org wrote: On Fri, May 21, 2010 at 11:11 AM, David DEMELIER demelier.da...@gmail.com wrote: Hi, I used pkgsrc for a while on NetBSD. I was used to the pkgsrc notifications about the users and groups leaves, when some ports are removed these leaves are not used anymore. e.g pulseaudio needs some users on the system. This was discussed in the following bug-report: http://www.freebsd.org/cgi/query-pr.cgi?pr=108514 I think the proper solution is to create a +UGIDS file to be able to maintain a refcount, but the status quo isn't that bad. Personally I'd much prefer to keep them so ls -l, filemanagers etc can continue to use names rather than numbers for any files left behind. IMO the status quo is better than any solution that involves automated deletion. I agree by and large with RW, but it would be nice if there was an audit tool to do this check and suggest whether or not a group should be added or removed in general, regardless of whether or not a pkg/port was added or removed. Thanks, -Garrett ___ 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: GPLv3-licensed ports
On May 19, 2010, at 11:54 AM, Charlie Kester wrote: On Wed 19 May 2010 at 05:10:49 PDT jhell wrote: Adding to this bundle of madness... I believe that it would be best practice to keep ports/LEGAL up-to-date with this list. Those who already have ports on a machine may find it more usefull to find them there. Quoting ports/LEGAL: Some of the ports in this directory have restrictive copyrights and GPLv3 I believe certainly would fall under that category. Yes, I don't what the original legal concerns were that led to the wiki page, but I know that many FreeBSD users are wary of GPLv3. So it makes sense to let them know which ports are licensed that way. After checking the COPYING files, some more of my ports for the list: devel/gengetopt devel/libYGP sysutils/iextract sysutils/gaffitter The ports in the devel category are especially noteworthy, since (if I understand correctly) their license will infect anything built with them. Is ports/LEGAL prominent enough? Should I also add something to the pkg-descr? As an end-user I don't care about GPLv3 other than from a philosophical stance; but using GPLv3 with FreeBSD as an employee is a non-starter, so that's a good primary reason for the wiki page I think. This data should really be inside the Makefile or something similar to CATEGORIES, etc like Gentoo Linux does (at least you know what you're getting before you install a package or port). That way other non-permissive licenses could be audited before the package is installed and someone could make a decision as to whether or not they can install it either because of licensing constraints, export issues, or the like... Thanks, -Garrett___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: GPLv3-licensed ports
On Wed, May 19, 2010 at 8:02 PM, Indi thebeelzebubtrig...@gmail.com wrote:
On Wed, May 19, 2010 at 04:51:30PM -0700, Garrett Cooper wrote:
On May 19, 2010, at 11:54 AM, Charlie Kester wrote:
The ports in the devel category are especially noteworthy, since (if I
understand correctly) their license will infect anything
built with them.
Is ports/LEGAL prominent enough? Should I also add something to the
pkg-descr?
As an end-user I don't care about GPLv3 other than from a
philosophical stance; but using GPLv3 with FreeBSD as an employee is a
non-starter, so that's a good primary reason for the wiki page I think.
This data should really be inside the Makefile or something similar to
CATEGORIES, etc like Gentoo Linux does (at least you know what you're
getting before you install a package or port). That way other non-permissive
licenses could be audited before the package is installed and someone could
make a decision as to whether or not they can install it either because of
licensing constraints, export issues, or the like...
I'd go a step beyond that and suggest that GPL-licensed ports should
have an EULA requiring the user to type yes or no, like parts of java
and some other restrictively-licensed things.
No .. that will never fly with the number of ports in the ports
tree that are GPL licensed; I find the downloading the other accept
before continuing logic to be highly counterproductive when
downloading and installing ports, and I sure others do as well. It
would be considerably more convenient if there was a license signoff
for certain items because it would make things less of a PITA.
Looking at pkgsrc, they have a variable per-Makefile, LICENSE.
Determining what license a port is distributed under would be
considerably easier. Also, if someone wanted to block all GPLv3 ports,
they could effectively look for GPLv3 ports like so:
.if defined(LICENSE) ${LICENSE} == GPLV3
.error GPLv3 licensed ports blocked due to site policy
.endif
in make.conf, etc (or ports.conf like some folks have lightly
tossed around on #bsdports and elsewhere).
Thanks,
-Garrett
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: GPLv3-licensed ports
On Tue, May 18, 2010 at 6:05 PM, David N david...@gmail.com wrote: On 19 May 2010 10:49, Marius Nünnerich mar...@nuenneri.ch wrote: On Wed, May 19, 2010 at 00:41, Charlie Kester corky1...@comcast.net wrote: Will someone with edit privileges for the wiki please add the following to the list of GPLv3-licensed ports (http://wiki.freebsd.org/PortsAndGPLv3)? math/ised misc/xsw sysutils/rdup Done, thanks for reporting. Also, Can you add net/samba33 net/samba34 Done. I've also added appropriate entries for binutils and gcc as well while I was there. HTH, -Garrett ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: FreeBSD Port: net-mgmt/net-snmp
On May 12, 2010, at 4:56 PM, Mike Jakubik wrote: Hi, I am having trouble compiling net-snmp on a number of 8-STABLE systems, below is the error. Thanks. --- creating libnetsnmpmibs.la (cd .libs rm -f libnetsnmpmibs.la ln -s ../libnetsnmpmibs.la libnetsnmpmibs.la) : libnetsnmpmibs.la /bin/sh ../libtool --mode=compile cc -I../include -I. -I../agent -I../agent/mibgroup -I../snmplib -I/usr/include -O2 -pipe -march=nocona -fno-strict-aliasing -Ufreebsd8 -Dfreebsd8=freebsd8 -c -o snmpd.lo snmpd.c cc -I../include -I. -I../agent -I../agent/mibgroup -I../snmplib -I/usr/include -O2 -pipe -march=nocona -fno-strict-aliasing -Ufreebsd8 -Dfreebsd8=freebsd8 -c snmpd.c -fPIC -DPIC -o .libs/snmpd.o cc -I../include -I. -I../agent -I../agent/mibgroup -I../snmplib -I/usr/include -O2 -pipe -march=nocona -fno-strict-aliasing -Ufreebsd8 -Dfreebsd8=freebsd8 -c snmpd.c -o snmpd.o /dev/null 21 /bin/sh ../libtool --mode=link cc -O2 -pipe -march=nocona -fno-strict-aliasing -Ufreebsd8 -Dfreebsd8=freebsd8 -o snmpd snmpd.lo -L../snmplib/.libs -L../snmplib -L./.libs -L./helpers/.libs -L./helpers -L/usr/lib -rpath=/usr/lib:/usr/local/lib libnetsnmpagent.la helpers/libnetsnmphelpers.la libnetsnmpmibs.la ../snmplib/libnetsnmp.la -lelf -lssp_nonshared cc -O2 -pipe -march=nocona -fno-strict-aliasing -Ufreebsd8 -Dfreebsd8=freebsd8 -o .libs/snmpd .libs/snmpd.o -rpath=/usr/lib:/usr/local/lib -L/usr/ports/net-mgmt/net-snmp/work/net-snmp-5.4.2.1/agent/.libs -L/usr/ports/net-mgmt/net-snmp/work/net-snmp-5.4.2.1/agent/helpers/.libs -L/usr/ports/net-mgmt/net-snmp/work/net-snmp-5.4.2.1/snmplib/.libs -L/usr/ports/net-mgmt/net-snmp/work/net-snmp-5.4.2.1/snmplib -L/usr/ports/net-mgmt/net-snmp/work/net-snmp-5.4.2.1/agent/helpers -L/usr/lib ./.libs/libnetsnmpagent.so helpers/.libs/libnetsnmphelpers.so ./.libs/libnetsnmpmibs.so /usr/ports/net-mgmt/net-snmp/work/net-snmp-5.4.2.1/agent/helpers/.libs/libnetsnmphelpers.so /usr/ports/net-mgmt/net-snmp/work/net-snmp-5.4.2.1/agent/.libs/libnetsnmpagent.so -lwrap -lkvm /usr/ports/net-mgmt/net-snmp/work/net-snmp-5.4.2.1/snmplib/.libs/libnetsnmp.so -ldevstat ../snmplib/.libs/libnetsnmp.so -lcrypto -lelf -lssp_nonshared -Wl,--rpath -Wl,/usr/local/lib ./.libs/libnetsnmpmibs.so: undefined reference to `exp' *** Error code 1 It looks like -lm is missing in the linker line -- do you have the config.log? Thanks, -Garrett___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: Dixit port bad management
On Sun, May 2, 2010 at 12:59 PM, Tim A cx...@live.com wrote:
1) I don't understand why the Textproc/Dixit port is so badly managed. The
program itself is at version 10.4, while your unprofessional port still stays
at version 1.0.1, claiming that the GCC 4.2 compilation is broken.
2) I don't understand either why you don't use Dixit sourceforge RSS feeds to
know when a new version is available.
3) I don't understand how your Dixit port points to files which don't exist
anymore.
4) I don't understand the suprematism attitude of the maintainers in charge,
who don't give a penny on the programs they are suppose to maintain. They are
only interested in the statistics generated by their unprofessional ports,
but not in their quality.
Tim,
Here's a start. I'll leave it as an exercise for you to fix the rest
of the bits; I at least got you past the fun sites change in the
extract part, but the path for ${_DB_D} with what's setup in the
Makefile differs from reality (the current path is:
${SOURCEFORGE_SITE}/project/dixit/dixit_qdb/dixit.qdb.tar.bz2 , not
${SOURCEFORGE_SITE}/project/dixit/dixit/10.4/dixit.qdb.tar.bz2 ); you
probably don't want to pull the potentially out-of-sync zip file from
ftp*.freebsd.org , especially because we can decompress a tarball
natively without installing archivers/unzip .
I've trimmed out a lot of the fud, but you'll probably have to do some
hacking to get the project to work with QT3 or QT4 (hopefully the
latter).
The porter's handbook [1] is your guide as well as make(1) [2].
After that, run `make makesum all install ' . Submit a PR with the
diffs for all of the files if it works to your liking.
Good luck,
-Garrett
[1] http://www.freebsd.org/doc/en_US.ISO8859-1/books/porters-handbook/
[2]
http://www.freebsd.org/cgi/man.cgi?query=makeapropos=0sektion=0format=html
textproc-dixit.diff
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/dri fails to build.
On May 2, 2010, at 5:30 AM, Robert Noland rnol...@freebsd.org wrote: On Sun, 2010-05-02 at 11:26 +0200, Demelier David wrote: http://www.freebsd.org/cgi/query-pr.cgi?pr=143723 It seems adding CFLAGS+=-march-=native solved the problem but I don't want to keep this flag everytime in my make.conf How this flag could solve the problem ? I can't understand. This actually stems from libdrm. Intel requires certain atomics that are not available on pure i386. They are present in code built for i486 +. The default cpu was changed to i486 some time . Should the port be marked broken with -march=i386 then? -Garrett ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: graphics/dri fails to build.
On May 2, 2010, at 12:58 PM, Robert Noland wrote:
On Sun, 2010-05-02 at 11:46 -0700, Garrett Cooper wrote:
On May 2, 2010, at 5:30 AM, Robert Noland rnol...@freebsd.org wrote:
On Sun, 2010-05-02 at 11:26 +0200, Demelier David wrote:
http://www.freebsd.org/cgi/query-pr.cgi?pr=143723
It seems adding CFLAGS+=-march-=native solved the problem but I
don't want to
keep this flag everytime in my make.conf
How this flag could solve the problem ? I can't understand.
This actually stems from libdrm. Intel requires certain atomics that
are not available on pure i386. They are present in code built for
i486
+. The default cpu was changed to i486 some time .
Should the port be marked broken with -march=i386 then?
Well, I'm not sure quite how we would do that... but if your
kernel/world is not really old, it should just work unless you force gcc
to produce code that will run on i386.
Something like this?
.if ${CPUTYPE} == i386 || ${ARCH} == i386 ${CPUTYPE} == native
BROKEN := this port requires i486+ CPU support
.endif
Can't protect against someone using the non-supported means of
compiling things and putting -m{arch,cpu,tune}=native in CFLAGS, et all.
Thanks,
-Garrett___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: python can't make package.
On Fri, Apr 30, 2010 at 3:08 PM, David DEMELIER demelier.da...@gmail.com wrote: Hi freebsd-ports, This morning I wasn't able to make package in lang/python26 port. === Building package for python26-2.6.4 Creating package /usr/ports/packages/All/python26-2.6.4.tbz Registering depends:. Creating bzip'd tar ball in '/usr/ports/packages/All/python26-2.6.4.tbz' tar: lib/python2.6/lib-dynload/_multiprocessing.so: Cannot stat: No such file or directory tar: Error exit delayed from previous errors. pkg_create: make_dist: tar command failed with code 256 *** Error code 1 Stop in /usr/ports/lang/python26. *** Error code 1 Stop in /usr/ports/lang/python26. Is it a broken PLIST issue? It's a known issue I (and others) informed miwi@ about (I provided him with a patch). It's because you're not disabling the threads functionality in python. HTH, -Garrett ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: New FreeBSD ports system - bachelors work
On Apr 29, 2010, at 10:08 AM, Aldis Berjoza wrote: Some time ago I've read, that FreeBSD might be interested to move ports tree to database (sqlite?). This would require rewriting of all existing and writing some new tools related to ports. I'm IT student and next year I have to write bachelor work. As active FreeBSD user, I am very interested in supporting FreeBSD, and, if FreeBSD developers, think that such ports reimplementation would benefit FreeBSD community, I'd be willing to develop new system. If you have other ideas, how to improve FreeBSD ports please let me know. Currently this is just an idea, but I'm also open to other suggestions/ideas. Please, FreeBSD team, replay to my email ASAP, cause I have very limited time to select subjects for next semester, this will also affect my bachelors work. Aldis, For technical discussions that require some degree of design oversight into ports and packaging in general, please get in touch with port...@. I can tell you right now though, sqlite was an idea that is most likely not going to fly with pkg_install though, unless it's a completely modular framework where BDB 1.8x can be used in its place. The thing is that while certain tools like portmgr use this to `speed' things up... it's somewhat artificial as using INDEX sufficiently fast in most cases and most of the performance -- and most importantly functional issues -- lie elsewhere in the code. FWIW there was also a discussion about the merits of speed with sqlite and bdb with small-to-medium-ish datasets (of which ports is... currently 21k elements stored in one data table), and sqlite was significantly slower according to the performance data nox (I think it was nox at least...) had on hand. Thanks, -Garrett___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: New FreeBSD ports system - bachelors work
On Thu, Apr 29, 2010 at 10:57 AM, Ashish SHUKLA wahjava...@gmail.com wrote: Aldis Berjoza writes: Hello! Some time ago I've read, that FreeBSD might be interested to move ports tree to database (sqlite?). This would require rewriting of all existing and writing some new tools related to ports. I hope pkg_improved[1] GSoC project might interest you. [1] - http://wiki.freebsd.org/AndersNore/pkg_improved That's going to become moot in a bit as several of us are working on a combined effort to improve pkg_install. The patch probably also doesn't apply 100%. Thanks, -Garrett ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: portmaster and IGNOREME
On Sun, Apr 25, 2010 at 9:40 PM, Doug Barton do...@freebsd.org wrote: On 04/25/10 17:15, Aristedes Maniatis wrote: On 26/04/10 8:55 AM, Doug Barton wrote: I've just committed a fix for this problem to the svn (development) version of portmaster. You can find information on how to download it at http://dougbarton.us/portmaster-proposal.html. I would appreciate it if you would test that version in your environment to confirm that the fix is satisfactory. Firstly, it looks like it is unable to run with a relative path. Pretty minor issue, but I thought I'd mention it. yes, there is no way that will work. portmaster calls itself recursively, so it has to have an explicit path when you start it. _portmaster=$(realpath $0) ? ... $_portmaster foo But when using an absolute path # sh /root/portmaster -ai You could also chmod a+x /root/portmaster and then run it without the sh, but the way you did it works fine too. * I get the list of ports to upgrade, then Proceed y/n, and after that it sees CGatePro and tries to upgrade it. Yes, I was too hasty to get the fix out the door. I just committed version 207220 which has a more thorough fix for this issue in -a. * when using portmaster -ai I'm still given a choice to upgrade the package with no ORIGIN. I changed the logic for -a to be warn+skip automatically if an +IGNOREME file is present. For the case of no ORIGIN and no +IGNOREME it's back to being a fatal error. But why ask since we already know it will fail 100% of the time? Exactly right. Thanks, -Garrett ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: portmaster and IGNOREME
On Fri, Apr 23, 2010 at 10:43 PM, Aristedes Maniatis a...@ish.com.au wrote: I have a package which is not built from a port (it is commercial software). I've put an +IGNOREME file in the package folder. But portmaster will not ignore it: It's not ignoring it for -a (update). Kind of funny though why this functionality exists if pkg_install doesn't even check it. I've gotten a lot of noise similar to that related to homegrown packages I've dealt with at work when running pkg_add // pkg_create as it builds up package origins when it reads the contents of the plists -- not sure why a ports-ism made it into pkg_install though, but flz most likely knows why. #portmaster -a [snip...] === Proceed? y/n [y] === Starting build for for ports that need updating === === Launching child to update CGatePro-5.3.5 === No ORIGIN in /var/db/pkg/CGatePro-5.3.5/+CONTENTS === Aborting update === Update for CGatePro-5.3.5 failed === Aborting update Unless there is some clear documented reason, portmaster should ignore ports which are marked to be ignored. The documentation reads: If you do a regular update of the port, or if the -a option is being used you will be asked if you want to update the port anyway. I am not being asked, it just fails the entire port upgrade process, unless I use -ia and specifically exclude this package. I don't know enough about package files to know why ORIGIN is required, even for packages which aren't generated from the ports system. This I don't know (and is potentially a bug or a needed enhancement with portmaster). dougb would be able to fill you in on this. Cheers, -Garrett ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: databases/sqlite3 build fails
On Fri, Apr 23, 2010 at 12:53 PM, Doug Barton do...@freebsd.org wrote: On 04/23/10 12:16, Alexey Shuvaev wrote: Not sure, if I ran into the same problem, but I recall that sqlite3 needs an option TCL_MODULES turned on in lang/tcl85. Or, better, try to install tcl-modules by hand and see, if it helps. Yes, that solves it, thanks. When I am forced to install something like tcl for a build dependency I generally strip it down as much as possible, so I had unchecked the modules option. As you point out below, the option is enabled by default. If it does, should sqlite3 port directly depend on tcl-modules? A cursory examination indicates that this would be a good solution. The maintainer has been restored to the cc line. The problem doesn't manifest itself on the package clusters as TCL_MODULES turned on by default. devel/subversion requires sqlite by default, so I did an initial look at busting this build dependency a few weeks ago. There are some tcl modules used by sqlite so that isn't available in all cases, but it can be broken down when they're not compiled. If someone points me to the tcl script that breaks this assumption, I'll gladly whip up an awk, sed, or bourne shell script solution to remove this nasty dependency. Thanks, -Garrett ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: How to depend on package in EGG?
On Wed, Apr 21, 2010 at 2:11 PM, Ruslan Mahmatkhanov cvs-...@yandex.ru wrote:
Good day!
I want add option in port's Makefile to depend on textproc/py-enchant.
But how i can do it? It installs as python egg.
.if defined(WITH_ENCHANT)
RUN_DEPENDS+=${LOCALBASE}//enchant/__init__.py:${PORTSDIR}/textproc/py-enchant
.endif
What should i wrote instead in left part of this RUN_DEPENDS string?
Thanks in advance for answer.
Depend on the .egg instead of the __init__.py file?
-Garrett
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: [ HEADS UP ] Ports unstable for the next 10 days
On Mon, Apr 19, 2010 at 12:25 AM, Leslie Jensen les...@eskk.nu wrote: It's now more than 10 days. Are ports stable now? http://ragingred.files.wordpress.com/2008/10/simpsons_are-we-there-yet.jpg In short, sorry... nope (there's still some ways to go on updating packages -- porters have hit some snags with updating graphics/png, zlib in base and lang/php5, mostly -- there's still xorg, gnome, and kde to go...). Honestly, apart from the zlib and png upgrades, there's been little churn though for me (XFCE4 user), and I still update without much issue on a periodic basis every week. HTH, -Garrett ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: VLC does not support the audio or video format XVID.
On Sun, Apr 18, 2010 at 2:46 PM, Doug Barton do...@freebsd.org wrote: On 04/17/10 23:48, Doug Barton wrote: I recently updated -current, and all of my ports, and am now getting the following message when I try to watch an avi file encoded with xvid: No suitable decoder module: VLC does not support the audio or video format XVID. Unfortunately there is no way for you to fix this. Recompiling vlc, xvid, and numerous other things didn't help. Any suggestions? I have found the problem, it's zlib. In r206708-9 delphij updated zlib to version 1.2.4.3 and did some magic with the symbols. I just regressed my system to r206707 and now the same vlc does xvid just fine. When I booted the new -current yesterday (after the libz changes) I had to rebuild and reinstall openbox and libxml2 because the latter had some sort of unresolved symbol problem related to libz. When I regressed the system today and had to do the same thing I got this error: /usr/local/lib/libxml2.so: undefined reference to `gzo...@zlib_1.2.4.0' (Note, this libxml2 that generated this error was compiled against the NEW libz, so it's not the error that I was seeing previously.) In looking over the things in /usr/lib that may be related I see that gpac-libgpac-0.4.5_4,1 has the gzopen symbol, and I did not recompile that when I was trying to get vlc to work last night so it may be the magic bullet. My plan at this point is to re-upgrade to the latest -current, record the error I get from libxml2 when recompiling openbox, and then try recompiling stuff until I find the one that does the trick. Worst case scenario I do 'portmaster -f vlc' but that constitutes 175 ports, which would take a while. Yeah... that's what I thought it was. vlc does some interesting work initializing codecs I think where it disguises runtime linker issues, etc with pieces that tie into vlc. Not really happy about that, but after the issue with zlib was identified 2~3 weeks ago, it was easy to clean up... The other issues with zlib are pretty well known, and the overall upgrade as I and others mentioned a few weeks back is large as it's use is pervasive in 3rd party software. HTH, -Garrett ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: [RFC] Remove pkg_add -C (chroot functionality)
On Wed, Apr 7, 2010 at 8:49 PM, Garrett Cooper yanef...@gmail.com wrote: On Wed, Apr 7, 2010 at 7:22 PM, Tim Kientzle kient...@freebsd.org wrote: Garrett Cooper wrote: There's an outstanding bug to fix chroot(2)'ing functionality with pkg_add(1) [1]. Anyone that has tried this functionality knows that it's currently crippled If it's currently broken, it's better to simply remove it. I'm not sure I understand why anyone wants pkg_add to call chroot(2) at the top, though. As you pointed out, chroot pkg_add exists already. The feature we need should: * update $ROOTDIR/var/db/pkg * Add $ROOTDIR as a prefix to all installed file locations This would allow pkg_add when running outside of a chroot to install packages into a chrooted system, which is what you can't easily do with chroot pkg_add. As discussed in #bsdports with flz, it's much more complicated because in the future we'll most likely have mainstream support for cross-building where this isn't possible, i.e. build arm on i386 -- the point is that there are some steps that must be run on the target system or chroot, and this quite frankly isn't possible without being able to install directly on the target. Regardless, cross-building right now requires that one define the proper environment, and again that can't be delivered with pkg_add without introducing unneeded complexity. Point being, if someone wants to chroot, and they understand the complete exercise, or if we have documentation provided which demonstrates how to do so, people will use it, and potentially grow upon it in a positive way. Right now this is just a vestige of brokenness in pkg_install that should go IMO. Of course, this isn't particularly easy to do when forking tar(1), so the libarchive integration might be a necessary prerequisite. (Command-line tar doesn't support re-rooting absolute paths. There is a --chroot option to tar, but it's currently broken in some rather complex ways. As I'm composing this message, I'm starting to wonder if it also should not use chroot(2). Hmmm) The hard part is @exec/@unexec. On the one hand, you don't necessarily want to require the install dependencies of a package to be installed in the chroot, which argues against running those under chroot(2). On the other hand, a lot of the commands used within @exec/@unexec manipulate common system databases (e.g., ldconfig), which argues that those commands should be run under chroot(2). Bingo -- that is the cruxt of the problem with doing chroot(2) with pkg_add. From a support perspective it's a nightmare because when something does go south, you're up a crik without a paddle trying to figure out what the heck is going on... it's better for us that someone is running with a stable, pre-defined system than try and force them to use a home grown / unknown method built around a shaky base. It's been two days without a lot of commentary. Expanding to a larger audience... Thanks, -Garrett ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: Trivial PR, fix package-noinstall
On Sat, Apr 10, 2010 at 2:29 AM, Dominic Fandrey kamik...@bsdforen.de wrote:
This morning I took a look at my outstanding PRs. There are
is a ports PR I consider old and trivial:
This one fixes a bug in the package-noinstall target. wxs told
me that he prefers my proposed fix over his own:
http://www.freebsd.org/cgi/query-pr.cgi?pr=ports/144164
This suggested fix completely breaks pkg_creates operation because it
does a chdir(2) prior to package creation (from
.../usr.sbin/pkg_install/create/perform.c:555):
if (chdir(log_dir) == FAIL) {
warnx(can't change directory to '%s'!, log_dir);
return FALSE;
}
The goal is to expand use of the install and deinstall scripts, not
break them in ports; this would be counterproductive to what we want
to do.
FWIW, I've thought this over and and user modifiable scripts should
not be in packages; they should instead be example files which don't
conflict with real configuration files. This is already the case for
several ports, but not all ports. If we did this, it would solve the
problem we've had with ports removing or overwriting user config files
simply and easily. I wonder if other folks agree with me or not.
Thanks,
-Garrett
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: Trivial PR, fix package-noinstall
On Sat, Apr 10, 2010 at 4:26 AM, Dominic Fandrey kamik...@bsdforen.de wrote:
On 10/04/2010 12:49, Garrett Cooper wrote:
On Sat, Apr 10, 2010 at 3:44 AM, Dominic Fandrey kamik...@bsdforen.de
wrote:
On 10/04/2010 12:18, Garrett Cooper wrote:
On Sat, Apr 10, 2010 at 2:29 AM, Dominic Fandrey kamik...@bsdforen.de
wrote:
This morning I took a look at my outstanding PRs. There are
is a ports PR I consider old and trivial:
This one fixes a bug in the package-noinstall target. wxs told
me that he prefers my proposed fix over his own:
http://www.freebsd.org/cgi/query-pr.cgi?pr=ports/144164
This suggested fix completely breaks pkg_creates operation because it
does a chdir(2) prior to package creation (from
.../usr.sbin/pkg_install/create/perform.c:555):
if (chdir(log_dir) == FAIL) {
warnx(can't change directory to '%s'!, log_dir);
return FALSE;
}
I don't see what appears to be the problem. The fix is tested,
there is no chdiring and pkg_create is not modified in any way.
All it does is change the parameters pkg_create is called with.
Have you tested in the following cases:
1. With the pkg_install scripts.
2. Without the pkg_install scripts.
If not, then you need to do that before asking for someone to
commit your code :).
The do-package code is used by the package and the package-noinstall
targets.
package-noinstall is called by package-recursive on ALL-DEPENDS.
I.e. it is only used on completely installed packages, just what
pkg_create -b was made for.
The regular package target is always run after install (search for
Main logic in bsd.port.mk). So do-package is only called after
install has completed, hence the code can, in every case, rely on
logdir containing all required data.
Ok, interesting. If you look at another spot in bsd.port.mk, there's
another area where +INSTALL and friends are installed:
fake-pkg:
# ...
if [ -f ${PKGINSTALL} ]; then \
${CP} ${PKGINSTALL} ${PKG_DBDIR}/${PKGNAME}/+INSTALL; \
fi; \
if [ -f ${PKGDEINSTALL} ]; then \
${CP} ${PKGDEINSTALL} ${PKG_DBDIR}/${PKGNAME}/+DEINSTALL; \
fi; \
if [ -f ${PKGREQ} ]; then \
${CP} ${PKGREQ} ${PKG_DBDIR}/${PKGNAME}/+REQUIRE; \
if [ -f ${PKGMESSAGE} ]; then \
${CP} ${PKGMESSAGE} ${PKG_DBDIR}/${PKGNAME}/+DISPLAY; \
fi; \
# ...
So if I don't define NO_PKG_REGISTER and I define FORCE_PKG_REGISTER,
then this logic will be executed.
This change does need to be tested for the make package-noinstall case
with pkg-install, pkg-deinstall, etc being present and not being
present [in their .in files form and non-.in files form]. Otherwise
this is going to potentially introduce a regression into bsd.port.mk.
Thanks,
-Garrett
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: ports and PBIs
On Sat, Apr 10, 2010 at 10:03 AM, Julian Elischer jul...@elischer.org wrote: On 4/10/10 3:35 AM, Garrett Cooper wrote: [...] If I'm understanding you correctly you're saying it's an issue when I do: pkg_add A B C # 1 year passes pkg_add D # D depends on A, B, C, of different revisions. pkg_add barfs because it can't find the applications, etc. This is something that's been hashed over a number of times (a few of which I've participated in in #bsdports). There needs to be a simple update command which will handle the action of upgrading packages, because there isn't a proper command that will do so today. Unless PBIs are self-contained entities which have their own sets of dependent utilities and libraries, etc (which you weren't suggesting in the sentence above), or install into a common location with versioned directories (which is a pain in the ass and involves a lot of hardcoded pains dealing with libtool files, libraries, etc -- been there, done that with Gentoo Linux -- there are hack scripts written to work around several possible hardcoded version issue, and there are a handful), AFAIK there's nothing positive and new that PBIs can bring to the table in this regard that can't be implemented in pkg_install as-is, other than the point-click-install user-friendly interface. ok that's your opinion n the matter. I for one think htat hte default ettin for PBIs to install all the dependencies, in this day of 1TB drives, makes sense and is a good capability for us to have, even if not everyone needs to use it. It's more than just diskspace though. Consider the fact that now you're going to lose a lot of the memory sharing between shared libs and what-not, and now you'd have to be running N number of daemons . Take PCBSD for instance -- do they really revision packages with unshared dependencies, or are all of the dependencies updated at once? This becomes a big issue as you can't have dissimilar applications like dbus, gamin, openssh, etc running on the same system at one time. How does the PBI layout plan to deal with this kind of conflict -- apart from jails, which would greatly increase the required footprint...? If you can do this with package code, Maybe you will supply the packages.. Not quite sure what you meant here. better still, make the development ports a PBI, I am just thinking out loud here,but that may work, toughts? one could say I could use merge scripts like marcusmerge for example, or use Virtualbox... but for large ports like Xorg and gnome or KDE, virtualbox doesn't cut it yet... thinks like Nvidia Video cards, multiple monitors, USB devices, and whatnot do not work on virtual box.. PBI's for development ports, with all the dependencies, wrapped in one package. Ok, well here's the thing. Instead of having N shared dependencies and libraries in /usr/local/lib, you'd have N**2 shared dependencies and libraries in each and every package. Now, let's look at $ ls -l irssi-0.8.14_1.tbz ~/Downloads/Irssi0.8.14_1-PV0.pbi -rw-r--r-- 1 gcooper gcooper 6856203 Apr 10 00:05 /usr/home/gcooper/Downloads/Irssi0.8.14_1-PV0.pbi -rw-r--r-- 1 root wheel 517442 Apr 10 00:07 irssi-0.8.14_1.tbz The .tbz file is a file created with pkg_create -b, and the other file is the PBI I pulled off of http://www.pbidir.com/bt/download/210/2079 . Big difference in size (13.25 fold difference). Yes but that is a worst case thing. We are talking about making a system where the PBIs contain all the libraries needed but that only some of them are installed, when there is not already the same one (i.e. identical) installed by a previous PBI. so if you installed, say, 20 PBI from the same 'set' you woudl only be installing one copy of the libraries that See above comment. PBIs only comprise a small set of packages in FreeBSD; if my understanding is correct based on a mirror referenced in pbidir.com, the number is currently under 500~750 PBIs -- this is drastically smaller than the number of binary packages produced by ports on a regular basis for FreeBSD. solution? well let all the developers develop working ports in progress in one place, give users like me a way to track these changes and install and test them... I think FreeBSD becomes a better place for it. Packages are more of the answer IMO, not PBIs. PBIs are merely a different set of contents and different means of delivering those contents, and while I like the idea of point - click - install, I'm not ready to create unnecessary complexity by having libraries rev'ed according to what the maintainer A believes are correct, even though maintainer B set it differently, and I'm not interested in sacrificing disk space for this reason. If I wanted to use a packaging scheme like this, I should be using Mac OSX as my primary operating system. well no-one is going to make you use PBIs Yes, but if I now have to waste more bandwidth and disk space installing
Re: Ports breakage since r205471
On Mon, Apr 5, 2010 at 2:12 AM, Erwin Lansing er...@freebsd.org wrote: On Mon, Apr 05, 2010 at 02:02:46AM -0700, Xin LI wrote: On 2010/04/05 01:50, Erwin Lansing wrote: On Sun, Apr 04, 2010 at 03:06:15PM -0700, Garrett Cooper wrote: Hi all, I realize that this is most suitable for current@ and I'm cross-posting, but I wanted to jot down all of the ports broken since the zlib version bump so that we can keep track of what's going on and what needs to be fixed. I have just started a new package build against todays HEAD on pointyhat , actually before seeing this thread, so these, and any others, will be picked up there. I'll update the list with the results when it finishes in a day or two. Which svn revision is currently using on the build cluster? Unfortunately, we're still using cvs for updating, but I just double checked that it is past r206058. The update is less than an hour old from cvs. You won't see the issue unless you roll back to before r206057; r206057 and r206058 disguise the compatibility issue by completely zapping the #ifdef _LARGEFILE64_SOURCE and #if _FILE_OFFSET_BITS == 64 enable pieces. Thanks, -Garrett ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: [ HEADS UP ] Ports unstable for the next 10 days
On Mon, Apr 5, 2010 at 12:05 PM, Antonio Olivares olivares14...@gmail.com wrote: Ion-Mihai, Does this fix the following issue? I have installed FreeBSD 8.0 and updated it to current p2 I try to use konqueror and I get There was an error loading the module About-Page for Konqueror. The diagnostics is: Cannot load library /usr/local/kde4/lib/kde4/konq_aboutpage.so: (Shared object libjpeg.so.10 not found, required by libkhtml.so.7) Other programs like kile and k3b don't work because of the same message or others. I did not know about this, otherwise I would not have tried to install these programs in the first place, till the coast was clear :( Thanks though, I saw the message a little bit late :( Nope. You need to update all of jpeg. See UPDATING for more details (but substitute this for the portmaster directions: portmaster -r 'jpeg-*' . HTH, -Garrett ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Ports breakage since r205471
Hi all, I realize that this is most suitable for current@ and I'm cross-posting, but I wanted to jot down all of the ports broken since the zlib version bump so that we can keep track of what's going on and what needs to be fixed. The following 3rd party libraries and all of their dependencies: graphics/png graphics/tiff textproc/libxml2 all needed to be rebuilt. The following items incorrectly define LARGEFILE64 and result in errors like the following: /usr/include/zlib.h:1561: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'gzseek64' /usr/include/zlib.h:1562: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'gztell64' /usr/include/zlib.h:1563: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'gzoffset64' /usr/include/zlib.h:1564: error: expected declaration specifiers or '...' before 'off64_t' /usr/include/zlib.h:1565: error: expected declaration specifiers or '...' before 'off64_t' devel/qt-moc lang/python (uses pieces from gpac-libgpac I think) multimedia/gpac-libgpac multimedia/vlc (draft patch attached to ports/145387) Also, I really think we should add packaging metadata to third party libraries in base and at least track the versioning and dependencies because this CURRENT upgrade has turned into a royal mess and has eaten up more of my time than it should have. Thanks, -Garrett ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: Ports breakage since r205471
On Sun, Apr 4, 2010 at 3:06 PM, Garrett Cooper yanef...@gmail.com wrote: Hi all, I realize that this is most suitable for current@ and I'm cross-posting, but I wanted to jot down all of the ports broken since the zlib version bump so that we can keep track of what's going on and what needs to be fixed. The following 3rd party libraries and all of their dependencies: graphics/png graphics/tiff textproc/libxml2 all needed to be rebuilt. The following items incorrectly define LARGEFILE64 and result in errors like the following: /usr/include/zlib.h:1561: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'gzseek64' /usr/include/zlib.h:1562: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'gztell64' /usr/include/zlib.h:1563: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'gzoffset64' /usr/include/zlib.h:1564: error: expected declaration specifiers or '...' before 'off64_t' /usr/include/zlib.h:1565: error: expected declaration specifiers or '...' before 'off64_t' devel/qt-moc lang/python (uses pieces from gpac-libgpac I think) multimedia/gpac-libgpac multimedia/vlc (draft patch attached to ports/145387) Also, I really think we should add packaging metadata to third party libraries in base and at least track the versioning and dependencies because this CURRENT upgrade has turned into a royal mess and has eaten up more of my time than it should have. As jsa@ so kindly pointed out, upgrading to r206057 temporarily alleviates this issue. I'll keep on looking for problematic areas where this needs to be fixed, but a #warning should probably be added to the header to catch all of the offenders. Thanks, -Garrett ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: Bug Report: Firefox 3.6.2 crashes on JavaScript heavy pages
On Sat, Apr 3, 2010 at 3:30 AM, Edward Tjörnhammar e...@cube2.se wrote: The browser crashes on JavaScript intensive pages. I've tried to debug the behavior but since firebug crashes with firefox this is a no go. I've tried disabling optimizations in the firefox makefile but it makes no difference. I don't believe it matters but my hardware is a Dell XPS m1210 laptop with intel graphics. What system: pylon# uname -a FreeBSD pylon 8.0-RELEASE FreeBSD 8.0-RELEASE #0: Sat Mar 13 18:50:29 CET 2010 r...@pylon:/usr/obj/usr/src/sys/PYLON i386 What makefile: pylon# grep Makefile,v /usr/ports/www/firefox/Makefile # $FreeBSD: ports/www/firefox/Makefile,v 1.221 2010/03/23 08:54:22 beat Exp $ How to reproduce: I can reproduce this crash everytime by removing my .mozilla and then visit: http://review.source.android.com/11633 Most pages are Ok. Error message: Floating point exception (core dumped) Well.. the processor supports SSE instrincs, perhaps this is a SIMD optimization bug somewhere else, I remember I enabled that for some other port.. Other notable behaviour: If i run firefox3 with truss -f firefox3 does not crash on the page. I could probably dive deeper into this. Doesn't crash for me on Firefox 3.5.8: # /etc/make.conf: CFLAGS += -fno-strict-aliasing -pipe CXXFLAGS+= -fno-strict-aliasing -pipe # ... CPUTYPE := nocona Do you have a custom make.conf file? If so, what's your processor and your CPUTYPE / C*FLAGS? Thanks, -Garrett ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: Bug Report: Firefox 3.6.2 crashes on JavaScript heavy pages
On Sat, Apr 3, 2010 at 6:50 PM, Edward Tjörnhammar e...@cube2.se wrote: Thank you for your replies! I didn't have any special make.conf but tried using fno-strict-aliasing as suggested by Garret and now it works. Regards On Sat, Apr 3, 2010 at 4:56 PM, Gary Jennejohn gary.jennej...@freenet.de wrote: On Sat, 3 Apr 2010 04:24:05 -0700 Garrett Cooper yanef...@gmail.com wrote: On Sat, Apr 3, 2010 at 3:30 AM, Edward Tj__rnhammar e...@cube2.se wrote: The browser crashes on JavaScript intensive pages. I've tried to debug the behavior but since firebug crashes with firefox this is a no go. I've tried disabling optimizations in the firefox makefile but it makes no difference. I don't believe it matters but my hardware is a Dell XPS m1210 laptop with intel graphics. What system: pylon# uname -a FreeBSD pylon 8.0-RELEASE FreeBSD 8.0-RELEASE #0: Sat Mar 13 18:50:29 CET 2010 __ __ r...@pylon:/usr/obj/usr/src/sys/PYLON __i386 What makefile: pylon# grep Makefile,v /usr/ports/www/firefox/Makefile # $FreeBSD: ports/www/firefox/Makefile,v 1.221 2010/03/23 08:54:22 beat Exp $ How to reproduce: I can reproduce this crash everytime by removing my .mozilla and then visit: __http://review.source.android.com/11633 Most pages are Ok. Error message: Floating point exception (core dumped) Well.. the processor supports SSE instrincs, perhaps this is a SIMD optimization bug somewhere else, I remember I enabled that for some other port.. Other notable behaviour: If i run firefox3 with truss -f firefox3 does not crash on the page. I could probably dive deeper into this. Doesn't crash for me on Firefox 3.5.8: # /etc/make.conf: CFLAGS += -fno-strict-aliasing -pipe CXXFLAGS += -fno-strict-aliasing -pipe # ... CPUTYPE := nocona Do you have a custom make.conf file? If so, what's your processor and your CPUTYPE / C*FLAGS? The referenced page works for me using FF 3.6.2. I don't have any special CFLAGS values set in src.conf/make.conf. I also have CPU: AMD Athlon(tm) Dual Core Processor 4850e (2505.35-MHz K8-class CPU) Features=0x178bfbffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE, MCA,CMOV,PAT,PSE36,CLFLUSH,MMX,FXSR,SSE,SSE2,HTT Features2=0x2001SSE3,CX16 It might be a bug then in how they're type-casting in firefox; if this is reproducible, a bug should definitely be submitted upstream. Thanks, -Garrett ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: Bug Report: Firefox 3.6.2 crashes on JavaScript heavy pages
On Sat, Apr 3, 2010 at 7:48 PM, Garrett Cooper yanef...@gmail.com wrote: On Sat, Apr 3, 2010 at 6:50 PM, Edward Tjörnhammar e...@cube2.se wrote: Thank you for your replies! I didn't have any special make.conf but tried using fno-strict-aliasing as suggested by Garret and now it works. Regards On Sat, Apr 3, 2010 at 4:56 PM, Gary Jennejohn gary.jennej...@freenet.de wrote: On Sat, 3 Apr 2010 04:24:05 -0700 Garrett Cooper yanef...@gmail.com wrote: On Sat, Apr 3, 2010 at 3:30 AM, Edward Tj__rnhammar e...@cube2.se wrote: The browser crashes on JavaScript intensive pages. I've tried to debug the behavior but since firebug crashes with firefox this is a no go. I've tried disabling optimizations in the firefox makefile but it makes no difference. I don't believe it matters but my hardware is a Dell XPS m1210 laptop with intel graphics. What system: pylon# uname -a FreeBSD pylon 8.0-RELEASE FreeBSD 8.0-RELEASE #0: Sat Mar 13 18:50:29 CET 2010 __ __ r...@pylon:/usr/obj/usr/src/sys/PYLON __i386 What makefile: pylon# grep Makefile,v /usr/ports/www/firefox/Makefile # $FreeBSD: ports/www/firefox/Makefile,v 1.221 2010/03/23 08:54:22 beat Exp $ How to reproduce: I can reproduce this crash everytime by removing my .mozilla and then visit: __http://review.source.android.com/11633 Most pages are Ok. Error message: Floating point exception (core dumped) Well.. the processor supports SSE instrincs, perhaps this is a SIMD optimization bug somewhere else, I remember I enabled that for some other port.. Other notable behaviour: If i run firefox3 with truss -f firefox3 does not crash on the page. I could probably dive deeper into this. Doesn't crash for me on Firefox 3.5.8: # /etc/make.conf: CFLAGS += -fno-strict-aliasing -pipe CXXFLAGS += -fno-strict-aliasing -pipe # ... CPUTYPE := nocona Do you have a custom make.conf file? If so, what's your processor and your CPUTYPE / C*FLAGS? The referenced page works for me using FF 3.6.2. I don't have any special CFLAGS values set in src.conf/make.conf. I also have CPU: AMD Athlon(tm) Dual Core Processor 4850e (2505.35-MHz K8-class CPU) Features=0x178bfbffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE, MCA,CMOV,PAT,PSE36,CLFLUSH,MMX,FXSR,SSE,SSE2,HTT Features2=0x2001SSE3,CX16 It might be a bug then in how they're type-casting in firefox; if this is reproducible, a bug should definitely be submitted upstream. Another possibility -- if you're using -O2, etc, it might be a compiler optimization bug on your CPU architecture (less likely). Cheers, -Garrett ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: Old ports bugs analyzis
On Tue, Mar 30, 2010 at 10:19 PM, Doug Barton do...@freebsd.org wrote: On 03/30/10 21:36, Arseny Nasokin wrote: I don't clearly understand, will be ports system removed? At this time all discussion is theoretical. LONG before we make any actual changes the users will have a chance to chime in, and will be notified if any actual changes are made. Ports shouldn't ever be removed; it's just that the focus for folks should be shifted to binary packages unless they have a pressing urge to install packages from source, or don't want the bloat associated with the package they're installing. Doug is right though -- it's going to take a while before what's being discussed is going to happen and we'll provide sufficient heads up before the changes are made. HTH, -Garrett ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: Old ports bugs analyzis
On Tue, Mar 30, 2010 at 9:36 PM, Arseny Nasokin eir...@gmail.com wrote:
On 31 Mar 2010, at 04:14, Garrett Cooper yanef...@gmail.com wrote:
Today binary packages are rolled as generic as possible provided the
architecture they're built for and are monolithic, meaning that they
contain the build, lib, patch, and run dependencies required to build
everything, as they're generated after an in-place install in
${PREFIX} .
One of many ideas we were kicking around on #bsdports was to produce
`fat packages' which would be usable in package installation and ports
building scenarios (similar to the headache that exists in many Linux
distros with -devel and non-devel packages), but the user could
specify whether or not they wanted the -devel pieces or not (if it
applied) -- so only one set of packages would need to be distributed.
We didn't really kick the idea around too much, but it was still a
novelty that should be `nursed' to a proper conclusion as it would
allow folks who roll packages and install on embedded systems /
install bases, or prefer installing via packages, to have small
install bases, and smaller potential binary roll up after the fact.
I can't see and discuss in IRC due browser and platform(software part)
limitations in nearest future.
I don't clearly understand, will be ports system removed? Will there will be
sourse and binary packages or will it be Gentoo-style portages, which will
provide installation from binary or source with options?
Gentoo portage is maintainer hell; we have enough fun with ports not
to get stuck in that mess.
Almost all packages in my systems has custom settings.
Which is exactly why I advocate using ports for my desktops and
servers. I just have other vested interests outside of my personal
machines where binary packages are better suited than installed a
boatload of packages from source.
Cool thing is though, if people use standard packages, there's a
greater chance of there not being stability issues with the packages
themselves right (or at least all of the issues will be known
upfront)?
Thanks :),
-Garrett
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: Old ports bugs analyzis
On Wed, Mar 31, 2010 at 12:59 AM, Arseny Nasokin eir...@gmail.com wrote:
On 31 Mar 2010, at 10:20, Garrett Cooper yanef...@gmail.com wrote:
On Tue, Mar 30, 2010 at 9:36 PM, Arseny Nasokin eir...@gmail.com wrote:
On 31 Mar 2010, at 04:14, Garrett Cooper yanef...@gmail.com wrote:
Today binary packages are rolled as generic as possible provided the
architecture they're built for and are monolithic, meaning that they
contain the build, lib, patch, and run dependencies required to build
everything, as they're generated after an in-place install in
${PREFIX} .
One of many ideas we were kicking around on #bsdports was to produce
`fat packages' which would be usable in package installation and ports
building scenarios (similar to the headache that exists in many Linux
distros with -devel and non-devel packages), but the user could
specify whether or not they wanted the -devel pieces or not (if it
applied) -- so only one set of packages would need to be distributed.
We didn't really kick the idea around too much, but it was still a
novelty that should be `nursed' to a proper conclusion as it would
allow folks who roll packages and install on embedded systems /
install bases, or prefer installing via packages, to have small
install bases, and smaller potential binary roll up after the fact.
I can't see and discuss in IRC due browser and platform(software part)
limitations in nearest future.
I don't clearly understand, will be ports system removed? Will there will
be
sourse and binary packages or will it be Gentoo-style portages, which
will
provide installation from binary or source with options?
Gentoo portage is maintainer hell; we have enough fun with ports not
to get stuck in that mess.
Almost all packages in my systems has custom settings.
Which is exactly why I advocate using ports for my desktops and
servers. I just have other vested interests outside of my personal
machines where binary packages are better suited than installed a
boatload of packages from source.
Cool thing is though, if people use standard packages, there's a
greater chance of there not being stability issues with the packages
themselves right (or at least all of the issues will be known
upfront)?
Thanks :),
-Garrett
If we are talk about specialized optimisations or customisations we should
talk about ports system. If we talk about desktop machines, there binary
packages are better in most cases (for example, using Synaptics frontend)
YMMV, but most of the time binary packages are built with the idea in
mind that it will meet the majority of the end-users' needs instead of
a specific case (unless there is a good reason for there being
variance, in that case ports are split, i.e. vim, vim-lite, etc).
There is a small amount of optimization that can be gained by using
proper CFLAGS as well with more modern hardware (let's face it.. the
default flags that binary packages are built with are meant to run on
generic old-school IBM clones all the way up to the most bleeding edge
AMD and Intel processors for instance) -- so if you use the
appropriate CPUTYPE and CFLAGS you can gain performance wise, because
you're tailoring the programs you compile to meet your system's
capabilities. You just have to be careful because ricing is something
that Gentoo users got themselves in trouble with back around 2003 ~
2004, and then I think that most people learned that they weren't
really gaining much in performance and were losing in stability, so
they stopped ricing their compiles.
Cheers,
-Garrett
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: stable ports?
On Mon, Mar 29, 2010 at 3:57 PM, eculp ec...@encontacto.net wrote: Quoting Ivan Voras ivo...@freebsd.org: Doug Hardie wrote: On 29 March 2010, at 08:57, Ivan Voras wrote: In some cases the burdens are obvious - the maintainer(s) would need to e.g. maintain three versions of the ports - a random example would be e.g. X.Org 7.0 for 6.x, 7.2 for 7.x and 7.4 for 8.x. Another would be keeping PHP 5.2 for 7.x and 8.x and having 5.3 in the future (CURRENT/9.x) branch. I am a bit concerned about your concept of maintain, being able to build a port successfully, does not necessarily mean it will work properly. For example, qpopper (which I maintain) has an issue where one feature does not work properly on 64 bit machines where it works fine on 32 bit machines. In addition, there are a number of other machine types that are currently not heavily used but might become so in the future. Thats a lot of different combinations of hardware and OSs to keep running for the maintainers. It was done (in Linux), hence it can be done. If all else fails and both the project and the maintainer cannot find suitable build and test machines, I'd suggest using ONLY_FOR_ARCHS, or doing the whole stable dance only for Tier 1 platforms (enumerated in http://www.freebsd.org/doc/en/articles/committers-guide/archs.html to be i386, amd64, pc98). AFAIK from the ports POW, pc98 and i386 are too close to be considered separately. Virtualization (VirtualBox) may help maintainers test on the architecture they don't run natively. IIRC, pcbsd uses both ports and package system that I have assumed was similar to linux but I have never used it so I can't comment but it would seem practical to work together if there is common ground. Their site says: -- The PBI Format Part of making a Desktop Operating System that people feel immediately comfortable with is ensuring that software installation is as easy and familiar as possible. PC-BSD has taken this approach when developing the PBI (Pc-Bsd Installer or Push-Button Installer) file format. Programs under PC-BSD are completely self-contained and self-installing, in a graphical format. A PBI file also ships with all the files and libraries necessary for the installed program to function, eliminating much of the hardship of dealing with broken dependencies and system incompatibilities. PBI files also provide developers and packagers with advanced scripting and user interaction in an entirely graphical format, making the entire install procedure similar to what a user would expect from other popular graphical operating systems. -- I personally like the way the ports work and will probably not change to any type of packages but you never know. I have never felt comfortable with the Linux packages. From what I've heard PBIs actually resemble OSX's dmgs more than Linux packages as Linux doesn't package in `bundle' format (contain all of the needed applications and libraries in one container). HTH, -Garrett ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: stable ports?
On Mon, Mar 29, 2010 at 11:35 AM, Ivan Voras ivo...@freebsd.org wrote: Alexey Shuvaev wrote: One way to do it, my proposal, would be to maintain a stable overlay of the ports, one for each major supported branch (i.e. 6.x, 7.x, 8.x), containing ports deemed important for some reason. What is the criteria which port version goes into particular branch? That is, which versions of, say, gtk will have 6.x, 7.x and 8.x? Is it supposed to be what was available at the time when the branch was out? I'd suggest that yes - keeping the current ports tree as-is as the unstable HEAD. If this is the case, 6.x branch will have pretty outdated heavy infrastructure ports (like gnome/kde libs, see below). Yes. Exactly as with all other operating systems with long-term support and binary packages. OTOH, users can always track HEAD as they do now. Only the users who really need it would follow the stagnating branches. See ref: Debian :) Also, nothing (for some values of nothing) would stop people running FreeBSD 6.x to track the 7.x stable ports branch if they want. Or not, depending on ports developers. What if the supported lifetime of the port upstream is less than supported lifetime of FreeBSD branch? Only if an update is needed (e.g. for security purposes), either of these: 1) Some other OS, Linux distribution, etc. nags the developers to fix it upstream or do the patch themselves, which we can pick up 2) The port maintainer(s) do it themselves (discouraged, of course) 3) The port is marked as insecure (possibly in vuxml) and the users are left to nag the developers for #1 or #2 :) If there is no immediate pressing need to update such a port (e.g. security), people can run arbitrarily old versions of applications forever. Or track HEAD. Who will backport at least security fixes to the port? I'd suggest that, previously to including the port in the stable branched the maintainer(s) agree to do it if necessary. Of course, it would be completely voluntarily - no maintainance, no stable port. It would defeat the purpose. * Updates which break shared libraries would not be allowed within such a branch/overlay (i.e. no updating gnome 2.xx to 2.x(x+1), libpng, libjpeg, xorg). On the one side who will maintain such a beasts like outdated version of xorg??? On the other side, if all major ports are frozen what is left Outdated beasts tend not to change much. to be updated? In other words what is the difference between proposed stable ports branch and a static snapshot? The static snapshot doesn't magically evolve Apache from 2.2.0 to 2.2.14+ but deliberately stays away from 2.4.0 because it would break its ABI and require recompilation of its modules :) As others noted, shared libraries are the issue - if a port, during its update, bumps its shared library version (libsomething.so.1 - libsomething.so.2), it would *not* *ever* be upgraded in the stable branch. * Binary packages for a whole X.Y branch would be built on X.0 (e.g. on 7.0 for all 7.x branches). Could not this be done already with the current ports? Yes it could. This is really tangential for the discussion, it concerns more the next step - binary packages and updates. I have not used Linux myself in the last 6 years, so I'm not very confident with all these 'apt', 'yum' and co, however I have 2 Ubuntu installations not far from me. Well, as tools they (apt, ...) may be quite good, but I remember the too early update to firefox3 (which crashed every few minutes and that was an official gnome browser!) and the problems with intel video card (hard freeze of the system) after upgrade to the new Xorg. So, the tools alone do not solve that many problems... Yes, of course. Most of the problems here are not technical but organizational. Creating a package manager is relatively easy compared to the project infrastructure (peopleware) that need to support it. Weighting these all, I would say no. There is already enough fun keeping ports working on CURRENT. And see below. Ok. Back on topic, would not it be better to provide official packages for upgrades built from some chosen snapshots of the ports tree? No, since it doesn't solve the major problem of forced upgrades of entires subtrees when an ancestor changes (e.g. libgtk, libpng, libjpeg, qt). In some cases (when really needed?) there are already different variants of the same port (port / portXY / port-devel). This makes sense for a very small number of ports. E.g. having PHP 5.2 and 5.3 at the same time in the same ports tree would probably add to the confusion. But you *must* upgrade to latest php-5.x port because of security updates and so you are forced to upgrade php to 5.3 (and everything that depends on it) even when 5.2 is supported upstream. There is one important note to make: Many times you're forced to upgrade packages because of ABI breakages, etc. What would happen if there was a CVE assigned for
Re: stable ports?
On Mon, Mar 29, 2010 at 12:49 PM, Ivan Voras ivo...@freebsd.org wrote: Doug Hardie wrote: On 29 March 2010, at 08:57, Ivan Voras wrote: In some cases the burdens are obvious - the maintainer(s) would need to e.g. maintain three versions of the ports - a random example would be e.g. X.Org 7.0 for 6.x, 7.2 for 7.x and 7.4 for 8.x. Another would be keeping PHP 5.2 for 7.x and 8.x and having 5.3 in the future (CURRENT/9.x) branch. I am a bit concerned about your concept of maintain, being able to build a port successfully, does not necessarily mean it will work properly. For example, qpopper (which I maintain) has an issue where one feature does not work properly on 64 bit machines where it works fine on 32 bit machines. In addition, there are a number of other machine types that are currently not heavily used but might become so in the future. Thats a lot of different combinations of hardware and OSs to keep running for the maintainers. It was done (in Linux), hence it can be done. If all else fails and both the project and the maintainer cannot find suitable build and test machines, I'd suggest using ONLY_FOR_ARCHS, or doing the whole stable dance only for Tier 1 platforms (enumerated in http://www.freebsd.org/doc/en/articles/committers-guide/archs.html to be i386, amd64, pc98). AFAIK from the ports POW, pc98 and i386 are too close to be considered separately. Virtualization (VirtualBox) may help maintainers test on the architecture they don't run natively. Virtualbox only runs x86-compatible platforms: An x86 virtualization software package developed by Sun Microsystems. Distributed under either the GNU GPL or a proprietary license with additional ... That would leave arm, ia64, mips, powerpc, and sparc64 out in the cold. Maybe folks should try qemu (despite the fact that it's a buggy-ish emulator?): From http://wiki.qemu.org/download/qemu-doc.html: For system emulation, the following hardware targets are supported: * PC (x86 or x86_64 processor) * ISA PC (old style PC without PCI bus) * PREP (PowerPC processor) * G3 Beige PowerMac (PowerPC processor) * Mac99 PowerMac (PowerPC processor, in progress) * Sun4m/Sun4c/Sun4d (32-bit Sparc processor) * Sun4u/Sun4v (64-bit Sparc processor, in progress) * Malta board (32-bit and 64-bit MIPS processors) * MIPS Magnum (64-bit MIPS processor) * ARM Integrator/CP (ARM) * ARM Versatile baseboard (ARM) * ARM RealView Emulation/Platform baseboard (ARM) * Spitz, Akita, Borzoi, Terrier and Tosa PDAs (PXA270 processor) * Luminary Micro LM3S811EVB (ARM Cortex-M3) * Luminary Micro LM3S6965EVB (ARM Cortex-M3) * Freescale MCF5208EVB (ColdFire V2). * Arnewsh MCF5206 evaluation board (ColdFire V2). * Palm Tungsten|E PDA (OMAP310 processor) * N800 and N810 tablets (OMAP2420 processor) * MusicPal (MV88W8618 ARM processor) * Gumstix Connex and Verdex motherboards (PXA255/270). * Siemens SX1 smartphone (OMAP310 processor) * Syborg SVP base model (ARM Cortex-A8). * AXIS-Devboard88 (CRISv32 ETRAX-FS). * Petalogix Spartan 3aDSP1800 MMU ref design (MicroBlaze). Thanks, -Garrett ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: stable ports?
On Tue, Mar 30, 2010 at 12:26 AM, Garrett Cooper yanef...@gmail.com wrote: On Tue, Mar 30, 2010 at 12:18 AM, Garrett Cooper yanef...@gmail.com wrote: On Mon, Mar 29, 2010 at 11:35 AM, Ivan Voras ivo...@freebsd.org wrote: Alexey Shuvaev wrote: One way to do it, my proposal, would be to maintain a stable overlay of the ports, one for each major supported branch (i.e. 6.x, 7.x, 8.x), containing ports deemed important for some reason. What is the criteria which port version goes into particular branch? That is, which versions of, say, gtk will have 6.x, 7.x and 8.x? Is it supposed to be what was available at the time when the branch was out? I'd suggest that yes - keeping the current ports tree as-is as the unstable HEAD. If this is the case, 6.x branch will have pretty outdated heavy infrastructure ports (like gnome/kde libs, see below). Yes. Exactly as with all other operating systems with long-term support and binary packages. OTOH, users can always track HEAD as they do now. Only the users who really need it would follow the stagnating branches. See ref: Debian :) Also, nothing (for some values of nothing) would stop people running FreeBSD 6.x to track the 7.x stable ports branch if they want. Or not, depending on ports developers. What if the supported lifetime of the port upstream is less than supported lifetime of FreeBSD branch? Only if an update is needed (e.g. for security purposes), either of these: 1) Some other OS, Linux distribution, etc. nags the developers to fix it upstream or do the patch themselves, which we can pick up 2) The port maintainer(s) do it themselves (discouraged, of course) 3) The port is marked as insecure (possibly in vuxml) and the users are left to nag the developers for #1 or #2 :) If there is no immediate pressing need to update such a port (e.g. security), people can run arbitrarily old versions of applications forever. Or track HEAD. Who will backport at least security fixes to the port? I'd suggest that, previously to including the port in the stable branched the maintainer(s) agree to do it if necessary. Of course, it would be completely voluntarily - no maintainance, no stable port. It would defeat the purpose. * Updates which break shared libraries would not be allowed within such a branch/overlay (i.e. no updating gnome 2.xx to 2.x(x+1), libpng, libjpeg, xorg). On the one side who will maintain such a beasts like outdated version of xorg??? On the other side, if all major ports are frozen what is left Outdated beasts tend not to change much. to be updated? In other words what is the difference between proposed stable ports branch and a static snapshot? The static snapshot doesn't magically evolve Apache from 2.2.0 to 2.2.14+ but deliberately stays away from 2.4.0 because it would break its ABI and require recompilation of its modules :) As others noted, shared libraries are the issue - if a port, during its update, bumps its shared library version (libsomething.so.1 - libsomething.so.2), it would *not* *ever* be upgraded in the stable branch. * Binary packages for a whole X.Y branch would be built on X.0 (e.g. on 7.0 for all 7.x branches). Could not this be done already with the current ports? Yes it could. This is really tangential for the discussion, it concerns more the next step - binary packages and updates. I have not used Linux myself in the last 6 years, so I'm not very confident with all these 'apt', 'yum' and co, however I have 2 Ubuntu installations not far from me. Well, as tools they (apt, ...) may be quite good, but I remember the too early update to firefox3 (which crashed every few minutes and that was an official gnome browser!) and the problems with intel video card (hard freeze of the system) after upgrade to the new Xorg. So, the tools alone do not solve that many problems... Yes, of course. Most of the problems here are not technical but organizational. Creating a package manager is relatively easy compared to the project infrastructure (peopleware) that need to support it. Weighting these all, I would say no. There is already enough fun keeping ports working on CURRENT. And see below. Ok. Back on topic, would not it be better to provide official packages for upgrades built from some chosen snapshots of the ports tree? No, since it doesn't solve the major problem of forced upgrades of entires subtrees when an ancestor changes (e.g. libgtk, libpng, libjpeg, qt). In some cases (when really needed?) there are already different variants of the same port (port / portXY / port-devel). This makes sense for a very small number of ports. E.g. having PHP 5.2 and 5.3 at the same time in the same ports tree would probably add to the confusion. But you *must* upgrade to latest php-5.x port because of security updates and so you are forced to upgrade php to 5.3 (and everything that depends on it) even when 5.2 is supported upstream. There is one
Re: Old ports bugs analyzis
On Tue, Mar 30, 2010 at 1:25 PM, Arseny Nasokin eir...@gmail.com wrote:
--
With pleasure
On 30 Mar 2010, at 23:14, Alexey Shuvaev shuv...@physik.uni-wuerzburg.de
wrote:
On Tue, Mar 30, 2010 at 01:05:39AM +0400, Eir Nym wrote:
I work on creating system for system and ports autobuilder with custom
settings for my FreeBSD machines. I know about many programs, which do
same, but I don't like strange depends, which are not controlled by
OPTIONS and some another
I've analyse ports tree and want to say about.
There're lot problems with ports to create per-port PRs
manually.Common types of problems are listed here:
0) Main part of problems in tons of ports, which has hidden options
(WITH WITHOUT checking), but not using OPTIONS for them.
1) There many libraries added with BUILDRUN dependencies, not as
LIB-DEPENDS.
2) Some ports has only BUILD depends to libraries, but links them
dynamicly.
3) All(?) samba33 slaves define dependency as samba33, and make
warning me about master target redefinition when do something on them.
4) many ports define dependencies as
${.CURDIR}/../../category/dep-port-name
5) And some adds trailing slash.
I want fix these problems, but I have no much time to fix several
thousands of ports. This work (include PR sending) needs about is 1-2
month per 8-10 hours a day.
If the problems are so common, maybe there are not so many problems
at all? :)
Yes, it's features! Let's all bugs will be features! Do you remember The Bat
mail client, which doesn't want support standarts at all?
Cases 0, 2, 3 and 4 are bugs.
0: I want to control options via OPTIONS, not by knowledge about Makefile
syntax with much time.
2: build port, install, remove lib and get this port unusable.
3: where program should find package orign samba33?
4: when reading Makefile, it hard to explain where port is. And when ports
tree has changed place in system, it's not good idea to rebuild index.
2, 5 are questions at most.
2: libraries should be LIB_DEPENDS
Caveat: static libraries are build dependencies; dynamic libraries are
lib dependencies. We had a discussion about this on #bsdports
yesterday and it was a well understood fact that was being proposed
for a move forward in terms of installing binary packages.
I put my analysys in several work files:
I've removed ${PORTSDIR} from paths for readability in index files.
http://freebsd.eroese.org/bsd.local.mk - different describe target
(clean and simple)
http://freebsd.eroese.org/portInfo.py - py-IDX maker. old, but enough
version.
http://freebsd.eroese.org/tag - portsnap(8) tag
http://freebsd.eroese.org/IDX - special maked IDX
http://freebsd.eroese.org/py-IDX - human readable format of IDX, see
py program for comments about types.
I have tried to understand what is in these files but have not managed
it completely.
The file py-IDX lists 2 of my ports, devel/slglade and
x11-toolkits/gtkdatabox as being fixed:
fix devel/slglade
fix x11-toolkits/gtkdatabox
Could you elaborate more what was 'fixed' in these 2 examples?
Thanks,
I've striped out debug output from top.
I've updated files py-IDX and python program.
And also put some documentation in file http://freebsd.eroese.org/docs
Cheers,
-Garrett
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
