Re: saving a few ports from death
Adam, On Tue, Apr 26, 2011 at 10:51:39PM -0500, Adam Vande More wrote: >On Tue, Apr 26, 2011 at 10:41 PM, Robert Huff wrote: > >> >> Garance A Drosehn writes: >> >> > Speaking of which, I haven't noticed the old lists of >> > "FreeBSD unmaintained ports which are currently marked broken" >> > and >> > "FreeBSD ports which are currently scheduled for deletion" >> > >> > show up recently. I did have some mixup in my email account >> > for a short period, so I assume I just missed an announcement >> > on how that is handled now. >> >> I get regular e-mails for "marked as broken". >> > >Last one I have is from Jan 21, prior to that it was twice monthly. > Must be they were scheduled for deletion ;) last ones I received here for the two first listed subjects above were recieved January. -- Regards, (jhell) Jason Hellenthal pgpcLCljljQNW.pgp Description: PGP signature
Re: expiration of net/skype ?!
martinko, Hi, Ive read your post below and the following two messages on this among other messages regarding the deprecation of ports. One thing that should be noted is that once the deprecation process is done and over and the port nolonger becomes part of the tree, you are still more than able and welcome to keep the distfiles you have as well checkout just the port directory in question that you are worried about to a seperate place other than the ports tree to maintain it locally. The port may not exactly be in the snapshot tree but just because of that does not mean it will not work for you from a different location. Also note that it may actually be good practice for those that need to use those ports but are unsure of exactly what it involves to upkeep them. It could lead you to another time where you might be interested in being the maintainer for that port. On Tue, Apr 26, 2011 at 01:47:30AM +0200, martinko wrote: >Hi all, > >So what is this deprecation and expiration of net/skype port please ?? >I'm asking because I've been using it successfully for more than a year >and installed it again just this weekend without any issue. And I've >read in the mailing lists many others use it too. So why all that >black-listing ? Should I copy the port to my home folder for future >installations ? Or can I / we do something about keeping it in the >ports tree ? I would surely appreciate if it could stay there. > -- Regards, (jhell) Jason Hellenthal pgpEgF7qh4JeD.pgp Description: PGP signature
Re: Need to use some library path before /usr/lib
On Thu, 17 Sep 2009 21:24 -, jasonh wrote: On Thu, 17 Sep 2009 12:45 -, gerald wrote: Building some (Fortran) applications with lang/gcc44 it turns out we get weird failures upon startup which look like: /libexec/ld-elf.so.1: /usr/lib/libstdc++.so.6: version GLIBCXX_3.4.11 required by ./gendoc not found What is happening here is that lang/gcc44 lays down /usr/local/lib/gcc44/libstdc++.so.6 and puts /usr/local/lib/gcc44 into USE_LDCONFIG. Alas the system then finds and uses /usr/lib/libstdc++.so.6 from our aging system compiler instead. Now, both libraries share the same name/version because these libraries, like also (and especially) libgcc_s.so.1 because new versions are drop ins for older ones, but not the other way round. How can we address this? Updating the old, unsupported by upstream system compiler has been ruled out historically, and does not look like an option (and also would not help older versions of FreeBSD). Use -rpath, somehow, by changing the configuration of the lang/gcc44 ports? That sucks in that it will break updates to newer versions of GCC. Set up ldconfig such that /usr/local/lib/gcc44 comes before /usr/lib? Anything else? Any pointers on how to best implement an ordering of search paths for ldconfig (or rpath, if that is the best of options)? Gerald Would it be possible to just libmap.conf gcc44 and friends just for that lib and the programs it builds. I know this is not such a great solution but for the mean time it may be a relevant answer. Something like the following. [/usr/local/bin/] libstdc++.so/usr/local/lib/gcc44/libstdc++.so libstdc++.so.6 /usr/local/lib/gcc44/libstdc++.so.6 On a second note. It would be real nice if the install of a second/third compiler would get installed into its own directory rather than placing executables in /usr/local/bin/ place them /usr/local/lib/gcc44/bin and create the symlinks to them. This would at least help the libmap issue and gcc44 for several ports (just building). Now for a port running (octave as example) have that port spam libmap.conf with the proper configuration for just that port the same way perl does to make.conf. -- Jason J. Hellenthal http://www.DataIX.net/ jas...@dataix.net 0x691411AC - (2^(N-1)) ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: Need to use some library path before /usr/lib
On Thu, 17 Sep 2009 12:45 -, gerald wrote: Building some (Fortran) applications with lang/gcc44 it turns out we get weird failures upon startup which look like: /libexec/ld-elf.so.1: /usr/lib/libstdc++.so.6: version GLIBCXX_3.4.11 required by ./gendoc not found What is happening here is that lang/gcc44 lays down /usr/local/lib/gcc44/libstdc++.so.6 and puts /usr/local/lib/gcc44 into USE_LDCONFIG. Alas the system then finds and uses /usr/lib/libstdc++.so.6 from our aging system compiler instead. Now, both libraries share the same name/version because these libraries, like also (and especially) libgcc_s.so.1 because new versions are drop ins for older ones, but not the other way round. How can we address this? Updating the old, unsupported by upstream system compiler has been ruled out historically, and does not look like an option (and also would not help older versions of FreeBSD). Use -rpath, somehow, by changing the configuration of the lang/gcc44 ports? That sucks in that it will break updates to newer versions of GCC. Set up ldconfig such that /usr/local/lib/gcc44 comes before /usr/lib? Anything else? Any pointers on how to best implement an ordering of search paths for ldconfig (or rpath, if that is the best of options)? Gerald Would it be possible to just libmap.conf gcc44 and friends just for that lib and the programs it builds. I know this is not such a great solution but for the mean time it may be a relevant answer. -- Jason J. Hellenthal http://www.DataIX.net/ jas...@dataix.net 0x691411AC - (2^(N-1)) ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: show port commit history in portmaster
On Sun, 13 Sep 2009 19:57 -, villa.alberto wrote: hello! encouraged by a request, i've written this small utility (attached) to show the commit history for a port (using freshports.org), and i was wondering... how about adding this functionality to portmaster? here's an example of its output: $ ./portchangelog.sh editors/vim ===>>> Gathering commit history for editors/vim ===>>> Number of commits found: 220 (showing only 100 on this page) =>>> 29 Jul 2009 21:19:43 >> 7.2.239 Committer: w...@freebsd.org Chase patch rename so that it passes "make checksum" =>>> 29 Jul 2009 08:40:23 >> 7.2.239 Committer: obr...@freebsd.org Change name of diked patch. at the moment it is a bit rough (it is just a shell script), but i can make it more serious if wanted (eg. not using a " " to identify a field) so... what do you think about this? I don't see this as a necessary addition. For one portmaster is a shell script. For two it means that the upgrade always needs to be connected and able to connect to the freshports site. For three freshports is just an 3rd party site where as you can get commit info right from the FreeBSD.org repo's. Four I don't see why anyone needs the commit info at upgrade time because as a part of administration this should be taken care of before you decide to upgrade anything. Best regards. -- Jason J. Hellenthal http://www.DataIX.net/ jas...@dataix.net 0x691411AC - (2^(N-1)) ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: devel/9base v2 upgrade to v4
On Thu, 10 Sep 2009 04:24 -, sbrabez wrote: Hi Jason On Wed, Sep 9, 2009 at 6:10 PM, Jason J. Hellenthal wrote: Would it be possible to fit in 9base-4 before the ports freeze. I am planning on going off air within the next couple of weeks and this is my preferred window manager and the provided with 9base-4 read command sure would come in handy. http://dl.suckless.org/tools/9base-4.tar.gz Thanks in advance. -- |-| Jason J. Hellenthal http://www.DataIX.net/ jas...@dataix.net 0x691411AC - (2^(N-1)) I prefer wait the port freeze of 14 September to update devel/9base but as you need it. I attached a unified diff which allow you to compile and install the new version 9base-4 released the 2009/09/27. As you could see, It needs lot of changes because lot of new binaries are now in plan9port distribution. That's why I want to wait the port freeze to correct handle them. Regards Thank you very much, This is much appreciated. As a workaround I have been just doing a local compile of 9lib and read then just copying the resulting read static binary to local/9/bin. Though this has provided temporary fixes its a pretty tedious process. Curious question: Have you noticed any weirdness the user environment whether it be in X or on the console while the fdescfs module is loaded ?. I have had some impacts with this being loaded in the past that I can not really explain and has deterred me from wanting to use the environment with that module loaded. I have noticed this happening since 6.1 through 7.2-STABLE and not specific to just the wmii port. Best regards. And thanks again. -- |----| Jason J. Hellenthal http://www.DataIX.net/ jas...@dataix.net 0x691411AC - (2^(N-1)) ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
devel/9base v2 upgrade to v4
Would it be possible to fit in 9base-4 before the ports freeze. I am planning on going off air within the next couple of weeks and this is my preferred window manager and the provided with 9base-4 read command sure would come in handy. http://dl.suckless.org/tools/9base-4.tar.gz Thanks in advance. -- |-| Jason J. Hellenthal http://www.DataIX.net/ jas...@dataix.net 0x691411AC - (2^(N-1)) ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
graphics/graphviz dangling symlinks
graphics/graphviz dangling symlinks: This port installs these symlinks which point to a missing file(s) dangling: /usr/local/share/doc/graphviz/pdf/neato.pdf -> dot.pdf dangling: /usr/local/share/doc/graphviz/pdf/twopi.pdf -> dot.pdf dangling: /usr/local/share/doc/graphviz/pdf/fdp.pdf -> dot.pdf dangling: /usr/local/share/doc/graphviz/pdf/circo.pdf -> dot.pdf dangling: /usr/local/share/doc/graphviz/pdf/dot2gxl.pdf -> gxl2dot.pdf -- Jason J. Hellenthal +1.616.403.8065 jas...@dataix.net ___ 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: sysutils/gnome-system-tools-2.22.2_1 self referencing symlink
Additionally Installed by: www/epiphany-extensions - epiphany-extensions-2.26.1 /usr/local/share/gnome/help/epiphany-extensions/C/figures/epi-ext-action-use.png ../../C/figures/epi-ext-action-use.png On Thu, 27 Aug 2009 15:04:27 -0400 "Jason J. Hellenthal" wrote: > [HEADS-UP] > > gnome-system-tools-2.22.2_1 installs a self referencing symlink. > > /usr/local/share/gnome/help/services-admin/C/figures > lrwxr-xr-x 1 root wheel 38 Aug 27 14:53 service-properties.png -> > ../../C/figures/service-properties.png > > This file is referenced by a half dozen or more other symlinks for other > area's of that help section. > > Best regards. > > -- > Jason J. Hellenthal > +1.616.403.8065 > jas...@dataix.net -- Jason J. Hellenthal +1.616.403.8065 jas...@dataix.net ___ 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"
sysutils/gnome-system-tools-2.22.2_1 self referencing symlink
[HEADS-UP] gnome-system-tools-2.22.2_1 installs a self referencing symlink. /usr/local/share/gnome/help/services-admin/C/figures lrwxr-xr-x 1 root wheel 38 Aug 27 14:53 service-properties.png -> ../../C/figures/service-properties.png This file is referenced by a half dozen or more other symlinks for other area's of that help section. Best regards. -- Jason J. Hellenthal +1.616.403.8065 jas...@dataix.net ___ 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"
xine failure during linking on FreeBSD 7.2
ports/multimedia/libxine Somehow links against a lib in its own source directory. Unresolvable link(s) found in: /usr/local/bin/xine-list-1.1 ../src/xine-engine/.libs/libxine.so Is there another way of getting around this problem ? -- Jason J. Hellenthal +1.616.403.8065 jas...@dataix.net ___ 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: portversion and pkg_version have different opinions on current versions
On Sat, 15 Aug 2009 13:06:56 -0700 Doug Barton wrote: > Jason J. Hellenthal wrote: > > > Why not just add weekly_status_pkg_enable="YES" to /etc/periodic.conf.local > > and youll be informed of packages that need updating. > > Sorry to pick on your response, but this thread is a good time to > remind people of some basic mailing list etiquette: No its not a problem at all I must have missed part of the thread and picked up the portion where pkg_version was being discussed. > > 1. Read the whole thread before you reply (the suggestion you made > above was already made earlier in this thread). > > 2. Make sure you understand the real problem before you reply (the OP > has some sort of problem with his INDEX and ports tree not matching, > we've moved past just finding out what needs updating). > > 3. Don't speculate. If you're not 100% sure about something let > someone who is more knowledgeable reply. There have been several posts > in this thread that gave misleading and/or confusing information that > could easily have been avoided. > > > hth, > > Doug > > -- > > This .signature sanitized for your protection > -- Jason J. Hellenthal +1.616.403.8065 jas...@dataix.net ___ 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: portversion and pkg_version have different opinions on current versions
On Sat, 15 Aug 2009 20:48:53 +0200 Thomas Backman wrote: > > On Aug 15, 2009, at 20:31, Miroslav Lachman wrote: > > > Thomas Backman wrote: > > [...] > >> [r...@chaos ~]# pkgdb -aF > >> ---> Checking the package registry database > >> [r...@chaos ~]# portversion -l '<' > >> dnsmasq < > >> ezm3< > >> libtool < > >> python26< > >> [r...@chaos ~]# pkg_version | awk '$2 !~ /=/' > >> [r...@chaos ~]# portupgrade -a > >> [r...@chaos ~]# > > [...] > > > > As was mentioned, you can use pkg_version -L =, or you can compare > > it with INDEX.db instead of ports tree: pkg_version -IL =. This is > > significantly faster. > > > > pkg_version -L = > > Usr: 7.286s Krnl: 3.984s Totl: 0:31.77s > > > > pkg_version -IL = > > Usr: 0.195s Krnl: 0.015s Totl: 0:00.21s > > > > And if you want to know the version of newer (available) port, you > > can use pkg_version -vIL = > > It gives you something like this: > > > > png-1.2.35 < needs updating (index has 1.2.38) > > postfix-2.5.6,1 < needs updating (index has 2.6.3,1) > > vim-lite-7.2.209 < needs updating (index has 7.2.239) > > > > Miroslav Lachman > Thanks, guys! > However, a new issue appeared... Kind of. I know I read something > about portsnap and INDEX on the -current list recently, so I'm > guessing this is related? Maybe not, though (see later in the mail). > > [r...@chaos /usr/ports/ports-mgmt]# portsnap -I fetch update >/dev/null > [r...@chaos /usr/ports/ports-mgmt]# pkg_version -vL= > [r...@chaos /usr/ports/ports-mgmt]# pkg_version -vIL= > curl-7.19.5_1 < needs updating (index has > 7.19.6) > dnsmasq-2.49_1 < needs updating (index has > 2.49_2) > ezm3-1.1_2 < needs updating (index has 1.2_1) > libtool-1.5.26 ! Comparison failed > postfix-2.6.2_1,1 < needs updating (index has > 2.6.3,1) > python26-2.6.2_1< needs updating (index has > 2.6.2_2) > vnstat-1.7_2< needs updating (index has 1.8) > vsftpd-ssl-2.1.2< needs updating (index has 2.2.0) > [r...@chaos /usr/ports/ports-mgmt]# portupgrade -a > [r...@chaos /usr/ports/ports-mgmt]# ls -l /usr/ports/INDEX-* > -rw-r--r-- 1 root wheel 17370624 Jul 31 19:45 /usr/ports/INDEX-5 > -rw-r--r-- 1 root wheel 19813792 Aug 15 20:42 /usr/ports/INDEX-6 > -rw-r--r-- 1 root wheel 19808537 Aug 15 20:42 /usr/ports/INDEX-7 > -rw-r--r-- 1 root wheel 34316288 May 8 10:35 /usr/ports/INDEX-7.db > -rw-r--r-- 1 root wheel 19816190 Aug 15 20:42 /usr/ports/INDEX-8 > -rw-r--r-- 1 root wheel 1291821 May 30 12:06 /usr/ports/INDEX-8.bz2 > -rw-r--r-- 1 root wheel 34869248 Aug 14 19:30 /usr/ports/INDEX-8.db > [r...@chaos /usr/ports/ports-mgmt]# date > Sat Aug 15 20:43:07 CEST 2009 > [r...@chaos /usr/ports/ports-mgmt]# > > So... Using the index causes problems (or the opposite!). Could I be > using an index for something like HEAD despite not using that ports > tree? (Again, pretty new to this!) > I don't know how the INDEX files work, but I do know (thank you > DTrace) that INDEX-8 was the only one read during "pkg_version -vIL=". > Oh, and my understanding is that the INDEX-8 is fetched via portsnap? > Running the "fetch update" took less than 20 seconds (the cron job ran > about 2 hours ago, though), so I guess it cannot have been built (that > does take a lot of time, yes?)? > > Regards, > Thomas > Why not just add weekly_status_pkg_enable="YES" to /etc/periodic.conf.local and youll be informed of packages that need updating. Best regards. -- Jason J. Hellenthal +1.616.403.8065 jas...@dataix.net ___ 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: Updating the "Mailscanner" port
On Fri, 14 Aug 2009 11:18:13 -0400 Kevin Kobb wrote: > Johan Hendriks wrote: > >> Mike Jakubik wrote: > >> > >>> On Mon, March 30, 2009 9:49 pm, Mark Linimon wrote: > >>> > >>> > >>>> On Thu, Mar 26, 2009 at 09:04:30PM +1100, Peter Jeremy wrote: > >>>> > >>>> > >>>>> If the existing maintainer has disappeared, one option would be for > >>>>> you to take over maintainership: Upgrade mailscanner yourself and > >>>>> submit the upgrade as a PR that also transfers maintainership to > >>>>> youself. If there's no response after about 2 weeks, the port is > >>>>> > > yours. > > > >>>>> > >>>>> > >>>> Actually, there is a 2-week timeout on updates, but a 3-month > >>>> > > timeout > > > >>>> on maintainer inactivity for transferring maintainership. Vacations > >>>> can last more than 2 weeks :-) > >>>> > >>>> > >>> I've just submitted a patch that updates this port to the latest > >>> > > version, > > > >>> perhaps we can squeeze it in before the freeze. > >>> > >>> http://www.freebsd.org/cgi/query-pr.cgi?pr=137747 > >>> > >>> Thanks. > >>> > >>> ___ > >>> freebsd-ports@freebsd.org mailing list > >>> http://lists.freebsd.org/mailman/listinfo/freebsd-ports > >>> To unsubscribe, send any mail to > >>> > > "freebsd-ports-unsubscr...@freebsd.org" > > > >>> > >>> > >> I noticed a couple of things here. The 4.78.9 version is still listed > >> > > as > > > >> Beta according to the MailScanner site, though the site may just not > >> have updated yet. Second, the patch submitted forces perl 5.10+ as a > >> requirement. I've seen nothing on the MailScanner site that says that > >> this is a requirement, and have had no problems myself using any of the > >> > > > > > >> Beta versions with perl 5.8.9_3. Given that upgrading perl is not > >> something to be done lightly, I was wondering what issues people were > >> seeing that 5.10 fixed. > >> > >> Thanks > >> > > > > I am running quit a few Mailscanner servers, and they all failed under > > perl 5.8.9 > > This was on FreeBSD 6.x, 7.x and 8-Current that time, when i switched to > > 5.10.x or back to 5.8.8 my problems went away. > > > > if you google on FreeBSD perl 5.8.9 and mailscanner there are a lot of > > people reporting issues. > > > > Regards, > > Johan Hendriks > > > > > > > > > > > > No virus found in this outgoing message. > > Checked by AVG - www.avg.com > > Version: 8.5.392 / Virus Database: 270.13.55/2301 - Release Date: > > 08/13/09 18:16:00 > > ___ > > 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" > > > I do remember seeing these problems reported, but for the life of me, I > can not reproduce them. I use 5.8.9 in production, and get 20 to 40 > thousand messages a day scanned without a problem. I am setting up a new > server, and I will try 5.10 on that and see how things go. > ___ > freebsd-ports@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-ports > To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org" This is most likely the common problem. ports/UPDATING states: 20090113: AFFECTS: users of lang/perl5.8 AUTHOR: s...@freebsd.org lang/perl5.8 has been updated to 5.8.9. You should update everything that depends on perl. The easiest way to do that is to use perl-after-upgrade script supplied with lang/perl5.8. Please see its manual page for details. Please check UPDATING after to follow up on any other updates for perl that you might have to perform. This explains why going back to 5.8.8 works for you. Best regards. -- Jason J. Hellenthal +1.616.403.8065 jas...@dataix.net I pledge Allegiance to the Flag of the United States of America, and to the Republic for which it stands; one Nation under God, Indivisible, with Liberty and Justice for all. ___ 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"
ImageMagick-6.5.* missing libs
This has not had any negative effect on any of the operations that I have used ImageMagick for but thought I would get this out there to see if there is something I might have missed or maybe there is something missing upon install. This has gone on repeatedly since 6.5.* versions repeatedly. Output from portmaster: ===>>> Creating a backup package for old version ImageMagick-6.5.4.10 tar: lib/ImageMagick-6.5.4/modules-Q16/coders/djvu.a: Cannot stat: No such file or directory tar: lib/ImageMagick-6.5.4/modules-Q16/coders/djvu.la: Cannot stat: No such file or directory tar: lib/ImageMagick-6.5.4/modules-Q16/coders/djvu.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 ===>>> Backup package creation failed for ImageMagick-6.5.4.10! ===>>> Ignore this error [i] ===>>> Abort [a] Any insight into this would cetainly be helpful since this causes a "automagick ;-) " backup process to stop. Best regards. -- Jason J. Hellenthal +1.616.403.8065 jas...@dataix.net ___ 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: ImageMagick 6.5.4.10
On Wed, 12 Aug 2009 21:44:39 -0500 (CDT)
Stephen Montgomery-Smith wrote:
>
>
> On Wed, 12 Aug 2009, Jason J. Hellenthal wrote:
>
> > On Wed, 12 Aug 2009 20:11:20 -0500
> > ajtiM wrote:
> >
> >> Update to 6.5.4.10 on FreeBSD 7.2
> >>
> >> magick/.libs/libMagickCore.so: undefined reference to `carg'
> >> *** Error code 1
>
> Try this patch:
>
> diff -u magick/fourier-orig.c magick/fourier.c
> --- magick/fourier-orig.c 2009-08-13 02:39:18.0 +
> +++ magick/fourier.c2009-08-13 02:40:13.0 +
> @@ -515,7 +515,7 @@
> for (x=0L; x < (long) fourier_info->center; x++)
> {
> magnitude[i]=cabs(fourier[i]);
> -phase[i]=carg(fourier[i]);
> +phase[i]=atan2(cimag(fourier[i]),creal(fourier[i]));
> i++;
> }
> else
>
I conclude this fixes the problem on 7.2-RELEASE-p3/i386 Non-SMP
--
Jason J. Hellenthal
+1.616.403.8065
jas...@dataix.net
___
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: ImageMagick 6.5.4.10
On Wed, 12 Aug 2009 20:11:20 -0500 ajtiM wrote: > Update to 6.5.4.10 on FreeBSD 7.2 > > magick/.libs/libMagickCore.so: undefined reference to `carg' > *** Error code 1 > magick/.libs/libMagickCore.so: undefined reference to `carg' > *** Error code 1 > 2 errors > *** Error code 2 > 1 error > *** Error code 1 > > Stop in /usr/ports/graphics/ImageMagick. > *** Error code 1 > > Stop in /usr/ports/graphics/ImageMagick. > > ===>>> make failed for graphics/ImageMagick > ===>>> Aborting update > > -- > Mitja > - > http://starikarp.redbubble.com > I have just built this as of the last 5 minutes with no problems. I am using all but three configure options... [ ] IMAGEMAGICK_TESTSRun bundled self-tests after build [ ] IMAGEMAGICK_OPENMP OpenMP for SMP (needs threads) [ ] IMAGEMAGICK_HDRI High Dynamic Range Images (HDRI) -- Jason J. Hellenthal +1.616.403.8065 jas...@dataix.net ___ 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: Multiple instances of Mailman on FreeBSD
On Wed, 12 Aug 2009 15:41:19 -0500
Jeffrey Goldberg wrote:
> On Aug 12, 2009, at 3:21 PM, Paul Schmehl wrote:
>
> > --On Wednesday, August 12, 2009 13:55:18 -0500 Jeffrey Goldberg
> > > > wrote:
>
> >> I'm posting this to both the mailman-users list and the freebsd-ports
> >> list. I realize that not all follow-up will make it to both lists.
>
>
> >> But when I do
> >>
> >> % cd /usr/ports/mail/mailman
> >> % sudo make -DMM_DIR=mailman/vhosts/lists.wilson-pta.org -
> >> DFORCE_PKG_REGISTER install
> >>
> >> It just installs in the default location, /usr/local/mailman
>
> > This could be a really stupid question (because I've never tried to
> > do what you're doing), but shouldn't the above line be:
> >
> > $ sudo make MM_DIR=/mailman/vhosts/lists.wilson-pta.org
> >
> > In other words, don't you have to provide the *absolute* patch to
> > the install location?
>
> No. Reading the Makefile it is clear that MM_DIR is relative to $PREFIX
>
> The default setting in the Makefile is
>
> MM_DIR?= mailman
>
> And later on there is a
>
>MAILMANDIR= ${PREFIX}/${MM_DIR}
>
> With MAILMANDIR being the absolute install directory.
>
> > The problem is, I'm not exactly sure *where* you want mailman to
> > install, so it's hard to be correct without more information.
>
> Mailman (under normal defaults) installs in various directories under
>
> /usr/local/mailman
>
> The python for all of the CGIs lives in
>
> /usr/local/mailman/Mailman
>
> and the programs that an administrator might run on the command line
> live in
>
> /usr/local/mailmain/bin
>
> And there are various other directories for queues and logs and data
> and per list configurations and such
>
> I want to have instances installed in
>
> /usr/local/mailman/vhosts/site1
> /usr/local/mailman/vhosts/site2
> /usr/local/mailman/vhosts/site3
>
> Cheers,
>
> -j
>
> --
> Jeffrey Goldberghttp://www.goldmark.org/jeff/
>
Can you not just ( cp -r /usr/local/mailman /path/to/vhost/staging ) edit some
of the paths and then just host it. How many of the files are you actually
required to edit ?. If this will be a continual process it might be better off
to rsync your master mailman directory to all the separate vhosts obviously
skipping configs and list directories and then scripting out the exact changes
you need to make up creation of a new vhost.
Best regards.
:wq
--
Jason J. Hellenthal
+1.616.403.8065
jas...@dataix.net
___
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"
graphics/netpbm & netpbm-devel
graphics/netpbm & netpbm-devel: These two ports dont list and CONFLICTS for either one of them. They do on the other hand list a conflict with "mgetty ???". Why don't these list conflicts with each other?. As of now I am doing cleanup once again for two versions of netpbm that have somehow been installed by portmaster during the mass confusion of graphics/jpeg. Best regards. -- Jason J. Hellenthal +1.616.403.8065 jas...@dataix.net ___ 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: No sound in linux-flashplugin-9.0r246 on -current
On Sat, 08 Aug 2009 22:27:23 +0200 Rainer Hurling wrote: > Hi Doug, > > for me it helps to set the following link > > ln -s /compat/linux/lib/libssl.so.0.9.8g /compat/linux/lib/libssl.so.5 > > Hope this helps, > Rainer Hurling > > > On 08.08.2009 21:25 (UTC+2), Doug Barton wrote: > > I vaguely recall seeing something about this, but don't recall if > > there was a resolution. > > > > > > Doug > > Is this something that could be handled through libmap.conf rather than adding an extraneous symlink to that may stick around after package deletion ? Curious question as I am unsure if libmap.conf can handle /compat/linux. Best regards. -- Jason J. Hellenthal +1.616.403.8065 jas...@dataix.net ___ 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"
slib-guile
# Date created:3 November 2003 # Whom:Kimura Fuyuki # # $FreeBSD: ports/lang/slib-guile/Makefile,v 1.8 2008/06/06 13:41:14 edwin Exp $ #$MCom: ports/lang/slib-guile/Makefile,v 1.3 2006/10/13 02:32:48 marcus Exp $ PORTNAME= slib PORTVERSION=3a4 # Keep this in sync with lang/slib PORTREVISION= 2 CATEGORIES= lang scheme MASTER_SITES= # empty PKGNAMESUFFIX= -guile DISTFILES= # empty This is not in sync with lang/slib is this port used anymore or should I just disregard this to /dev/trash ? -- Jason J. Hellenthal +1.616.403.8065 jas...@dataix.net ___ 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"
Ideas upon the port infrastructure. [MOVED] was "ports/*/jpeg "Thanks a lot guys""
That is a very nice idea, I am sure that with a little tweaking it would turn
out just fine.
Another nice aspect or solve for this would be getting something going like
symbol versioning in the libs by means of the developer that supports 2 or so
version's prior to the current lib in order to ease upgrading on any system
rather than just FreeBSD. I am certainly no expert in that field so I can not
comment more.
More comments ? any other takers. "Brain storming session"
On Fri, 7 Aug 2009 07:13:31 +0800
Buganini wrote:
> The meaning of NODE_VERSION and the flag is to describe dependencies more
> detailed,
> to make it possible to do automated upgrade, instead of bump PORTREVISION by
> man.
>
> An important thing, NODE_VERSION and the flag could be backward compatible,
> for port/package don't have NODE_VERSION, it's just 0.
> the flag could be just a '!' prefix, for example:
> !fltk-threads>=1.1.9:${PORTSDIR}/x11-toolkits/fltk-threads
> QT_COMPONENTS= gui imageformats_run moc_build !qmake_build !uic_build
> without the flag, everything is just like how it is now.
>
> this should be enough for cases like this jpeg case.
> For more detail, if we only save NODE_VERSION of port itself in +CONTENTS
> upgrade MUST be transactional, but for portupgrade and portmaster, exit in
> half way is usual,
> so I think to save NODE_VERSION of each dependencies is also necessary,
> or even make it part of version string, but this may be confused for
> somebody I think.
>
> For the upgrade of perl, now we use port* -o to replace, then -r or -fr to
> rebulid required-by
> If we have
> NODE_VERSION=5.8.0 in lang/perl5.8
> NODE_VERSION=5.10.0 in lang/perl5.10
> then when we port{upgrade,master} -o lang/perl5.10 perl5.8
> we dont have to rebuild required-by manually anymore.
>
> Furthermore, a unified target post-upgrade: is good, some ports has already
> have this,
> for example, upgrade-site-packages in lang/python
>
> --Buganini
--
Jason J. Hellenthal
+1.616.403.8065
jas...@dataix.net
___
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/*/jpeg "Thanks a lot guys"
I believe unless I misunderstand what you are meaning, is the same thing that
PORTREVISION is meant for doing. If the maintainer like what has just recently
happened for jpeg bumps the PORTREVISION up one for every port that depends on
jpeg then any upgrade utilities see that port as a new version and upgrade them
happily.
PORTREVISION is the end of the package name as package-VERSION-{ , or _
}PORTREVISION.
Personally I feel that adding another NODE_VERSION as your saying could
possibly be a benefit but at this time would cause a lot of maintainer overhead
on which that they already have. I think more of a short written policy or
checklist system for a maintainer might be a better route. Or possibly a ticket
system built around a dependency checklist that should be fulfilled before a
commit on a newer version would happen. Even with the previous statement that
still causes overhead in workload but eventually speeds the process up due to
lack of errors and re-corrections that have to be made ultimately resulting in
a higher percent of satisfied hobbyists and customers alike thus bringing in
more revenue.
If I could be of more assistance on this matter I have great experience
satisfying time tested analytics that speed up processes in the form of Lean
Manufacturing also plays a role in development.
Best regards.
On Thu, 6 Aug 2009 12:46:12 +0800
Buganini wrote:
> Recently I'm think about how to make ports easier to upgraded:
> 1) Add a NODE_VERSION in each ports' Makefile, this variable would be stored
> in +CONTENTS.
> 2) Add a volatile-meaning flag in description of dependencies
>
> When a port, A, whose NODE_VERSION in Makefile > NODE_VERSION in +CONTENTS,
> ports that volatile'ly depends on A would be rebuilt.
>
> Any comment is welcome
>
> --Buganini
--
Jason J. Hellenthal
+1.616.403.8065
jas...@dataix.net
___
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/*/jpeg "Thanks a lot guys"
On Fri, 31 Jul 2009 16:53:16 -0500 "Jeremy Messenger" wrote: > On Fri, 31 Jul 2009 12:36:36 -0500, Erik Trulsson > wrote: > > > On Fri, Jul 31, 2009 at 12:12:49PM -0400, Jason J. Hellenthal wrote: > >> > >> Now that I have finally upgraded my system in full from the last mix-up > >> with jpeg, You guys have bumped up every PORTREVISION that depends on > >> jpeg > >> "Great real great" Now I get to spend another three days fixing up some > >> more packages and rebuilding about 800+ ports. > >> > >> Thanks a whole lot. > > > > Nobody is forcing you to rebuild your ports just because the PORTREVISION > > was bumped. If everything works fine for you there is actually no good > > reason at all to do so. > So now the implication becomes that everyone should resort to manual checking of port versions and upgrade each port manually from here on out ?. Because if that is going to happen then eventually someone or a amateur for that matter is going to manually check their ports and come across an update they need and then it will update hand-in-hand every port that depends on libjpeg just to satisfy itself. Am I wrong ? is this not why portupgrade and portmaster were created so this could be done autonomously ? Don't get me wrong but I have been very involved in this upgrade that slipped into my systems from the 19th and it is frustrating when a rather circumvented actions consequences were not well thought out and gets repeated again for a third time. Please don't take this as a list bash or a personal matter, but I believe this needs to be discussed so it could be prevented in the future. Maybe a policy change on library bumps ? that gets more developers involved so the process is less likely to cause administration overhead. Or a policy stating that if your ports lib is bumped you should also bump all PORTREVISIONS that depend on it at the time it is committed ?. That is up for discussion and these are only thoughts but they are thoughts with a new user community in mind. Best regards. I am not on this list: please CC me in your replies. > Yes, but how can you tell if there is newer version? The pkg_version and > pkgversion don't tell you that it's PORTREVISION or actually newer > version. What about when we run 'port* -a'? Took about two weeks to get > PORTREVISION bump isn't right at all. > > Cheers, > Mezz > > > -- > me...@cox.net - m...@freebsd.org > FreeBSD GNOME Team > http://www.FreeBSD.org/gnome/ - gn...@freebsd.org Thanks Mezz -- Jason J. Hellenthal +1.616.403.8065 jas...@dataix.net ___ 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/*/jpeg "Thanks a lot guys"
Now that I have finally upgraded my system in full from the last mix-up with jpeg, You guys have bumped up every PORTREVISION that depends on jpeg "Great real great" Now I get to spend another three days fixing up some more packages and rebuilding about 800+ ports. Thanks a whole lot. -- Jason J. Hellenthal +1.616.403.8065 jas...@dataix.net ___ 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/jpeg especially UPDATING
If you pkg_delete -r that will remove every package that depends on jpeg. This is not the right way of just getting rid of jpeg considering it involves the complete almost full re-installation of the entire system manually. A better route to upgrade would be: pkg_delete -f jpeg-\* reinstall the new jpeg and then portmaster -r jpeg-\* I suppose the damage is already done to most of the systems for people that did not already catch this. On Thu, 23 Jul 2009 08:07:13 +0200 dirk.me...@dinoex.sub.org (Dirk Meyer) wrote: > Hallo Jason J. Hellenthal, > > > pkg_delete -r jpeg-6b_7 > > Please rebuild all ports that depends on it. > > "" > > You should remove this pkg_delete -r line in UPDATING. This is just telling > > the user to remove any packages that depended on jpeg recursively. There > > will be nothing left to upgrade if users do this as a lot of packages rely > > on jpeg. > > You need rebuild the dependent ports without old jpeg being installed. > > > Maybe a portupgrade -fr or portmaster -r would be more appropriate. > > maybe, I don't use this tools, so I can not tell. I do. And I know how much of a pain it is to manually replace over 800 packages is by hand. > > Gruß Dirk > > - Dirk Meyer, Im Grund 4, 34317 Habichtswald, Germany > - [dirk.me...@dinoex.sub.org],[dirk.me...@guug.de],[din...@freebsd.org] > http://people.freebsd.org/~dinoex/errorlogs/ -- Jason J. Hellenthal +1.616.403.8065 jas...@dataix.net ___ 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"
