Re: [RFC] NO_INSTALL in meta-ports considered harmful

[Alexey Shuvaev]

On Mon, May 11, 2009 at 09:17:00AM -0400, Wesley Shields wrote:
> On Sun, May 10, 2009 at 09:28:34PM +, Marcin Wisnicki wrote:
> > On Sun, 10 May 2009 15:22:04 -0400, Glen Barber wrote:
> > 
> > > On Sun, May 10, 2009 at 2:51 PM, Marcin Wisnicki
> > >  wrote:
> > >> They will be installed since they are run dependencies.
> > >>
> > >>From what I can tell (from several metaports) -- they, themselves, are
> > > not installed.  The ports defined in the metaport are installed.
> > 
> > That's the point. The metaports should be installed as well (reasons given 
> > in my original mail).
> > 
> > > There is no source code for, using your example, CUPS[1].  CUPS (in the
> > > FreeBSD ports tree) is, for lack of a better explanation, a pointer to
> > > which specific ports you need to have in order to get a fully operation
> > > CUPS system running.  Looking at the Makefile for print/cups [2] you can
> > > see the dependencies and that CUPS is not actually built (which in
> > > definition is what makes this a metaport).
> > 
> > I know this.
> > 
> > The proper way to make a metaport is to:
> > 1. use only RUN_DEPENDS
> > 2. set NO_BUILD
> > 3. do *NOT* set NO_INSTALL
> > 4. provide empty do-install target
> > 
> > There are several metaports that get it right, like for example x11/gnome2:
> > 
> > http://www.freebsd.org/cgi/cvsweb.cgi/ports/x11/gnome2/Makefile?rev=1.155
> 
> Based upon your description I think this is a bug in the CUPS port. I'd
> suggest you file a PR so that it can be tracked and (hopefully)
> addressed.
> 
FWIW, the following gives not so many hits:

/usr/ports> grep -R NO_INSTALL * | grep -v NO_INSTALL_MANPAGES
Mk/bsd.port.mk:# NO_INSTALL - Use a dummy (do-nothing) install target.
Mk/bsd.port.mk:.if defined(NO_INSTALL) && !target(install)
Tools/scripts/mkptools/mkpextr: $cap{"NO_INSTALL"} = "YES";
devel/gnustep/Makefile:NO_INSTALL=  yes
graphics/backfract/Makefile:NO_INSTALL_MANPAGE= yes
misc/posixtestsuite/Makefile:NO_INSTALL=YES
misc/kde4-l10n/Makefile:NO_INSTALL= yes
ports-mgmt/portmk/Mk/bsd.port.mk:# NO_INSTALL   - Use a dummy (do-nothing) 
install target.
ports-mgmt/portmk/Mk/bsd.port.mk:.if defined(NO_INSTALL) && !target(install)
print/cups/Makefile:NO_INSTALL= yes
x11/etoile/Makefile:NO_INSTALL= yes
x11/gnustep-app/Makefile:NO_INSTALL=yes

Ruling out *.mk scipts there is only 1 port that uses NO_INTSTALL correctly:
misc/posixtestsuite

These should be fixed (well, I'm not 100% sure):
devel/gnustep
misc/kde4-l10n
print/cups
x11/etoile
x11/gnustep-app

Not so many too :)

My 0.02$,
Alexey.
___
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 2.6 update with portmaster

[Alexey Shuvaev]

On Wed, Jun 10, 2009 at 09:26:47AM -0400, Wesley Shields wrote:
> Here's a patch[1] that allows you to use portmaster when doing the python
> upgrade. I intend to commit this tomorrow morning unless someone speaks
> up. I'll also be adding the instructions to the UPDATING entry.
> 
> Once applied you should be able to use:
> 
> cd /usr/ports/lang/python && make upgrade-site-packages -DUSE_PORTMASTER
> 
> It will be quite slow compared to using pkg_which (the normal method) so
> be patient. I've used this patch to upgrade one lightly used machine and
> I know at least one other person has survived an upgrade of a machine
> with over 1000 ports installed.
> 
> [1]: http://people.freebsd.org/~wxs/python26-portmaster.diff
> 
I think using "-f" switch with portmaster is not correct as it will
unconditionally rebuild all dependencies also (often up to perl :).

0.02$,
Alexey.
___
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: [REPOST] problem upgrading perl

[Alexey Shuvaev]

On Mon, Jun 15, 2009 at 10:25:59PM -0500, Scott Bennett wrote:
>  I got no responses when I posted this a few days ago, so I'm reposting
> it now.  I'd really like to finish the perl upgrade process, so I could move
> on to installing/updating other ports safely, but could use some advice.
>
>  Following the instructions in /usr/ports/UPDATING for upgrading from
> lang/perl5.8 to lang/perl5.10 using portmaster, the first part seems to go
> well.  The last line of that process is where the excerpt below begins.
> The second step, as you will see, fails with the error message shown.
> /usr/ports/UPDATING neglects to mention what to do next, and the process
> looks incomplete at this point.  If someone could offer instructions for
> completing the process, I would be grateful.
> 
> ===>>> Upgrade of perl-5.8.9_2 to perl-threaded-5.10.0_3 complete
> 
> hellas# nice +18 portmaster -v -r perl\*
> 
> ===>>> No ORIGIN in /var/db/pkg/perl-threaded-5.10.0_3/+CONTENTS:@comment 
> ORIGIN:lang/perl5.10 /var/db/pkg/perltidy-20071205/+CONTENTS:@comment 
> ORIGIN:devel/perltidy/+CONTENTS
> ===>>> Aborting update
> 
The something is wrong with packages database in /var/db/pkg or portmaster
doesn't like it. Please, show the output from the following commands to start:

head /var/db/pkg/perl-threaded-5.10.0_3/+CONTENTS
head /var/db/pkg/perltidy-20071205/+CONTENTS

Mine is (no perltidy though):
~> head /var/db/pkg/perl-5.10.0_3/+CONTENTS 
@comment PKG_FORMAT_REVISION:1.1
@name perl-5.10.0_3
@comment ORIGIN:lang/perl5.10
@cwd /usr/local
@conflicts perl-5.6.*
@conflicts perl-5.8.*
@conflicts perl-threaded-5.8.*
man/man1/a2p.1.gz
@comment MD5:41051bd143f495e113fa136ac0e9cb6f
man/man1/c2ph.1.gz

Hmmm... Looking at portmaster sources I've got one idea.
Can you try more precise command to upgrade everything depending on perl?

nice +18 portmaster -v -r perl-threaded-5.10.0_3

The point is that perl\* wildcard gives you both perl-threaded-XXX and
perltidy- which might be bad idea.

If this is the case I think UPDATING entry should be improved
to use perl-\* wildcard.

> hellas#
> 
>  Please copy me in on any responses.  I'm subscribed to the digest form
> of this list, so responses sent only to the list may take up to a day to be
> sent to me as part of the digest.
>  Thanks in advance for any assistance in proceeding with the perl upgrade.
> 
Just 0.02$,
Alexey.
___
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: nessus-2.2.9_1

[Alexey Shuvaev]

On Tue, Jun 16, 2009 at 07:07:12PM -0400, matt donovan wrote:
> On Tue, Jun 16, 2009 at 1:39 PM, Schweigert, Udo CERT <
> udo.schweig...@siemens.com> wrote:
> 
> > No, there are no further updates as 2.2.9 is the last open source version.
> >
> > Udo
> >
> > On Tue, Jun 16, 2009 at 12:16:54 -0500, phillip.gonza...@metavante.comwrote:
> > >
> > > hi,
> > >
> > > i'm looking at the nessus port on one of my FreeBSD boxes(recently
> > updated
> > > ports tree) and it looks like it's at version 2.2.9.  has this port not
> > > been updated or am i missing something?
> > >
> > > thanks for your time,
> > >
> > > Phillip P Gonzalez
> > > Information Security Analyst Sr.
> > > Security Analysis and Testing
> > > Metavante Corporation
> > > tel: 414.357.3156
> > >
> > >
> >
> 
> You have to go to the nessus website to grab the package now since it's no
> longer open source
>
I don't use nessus myself but just checking their website I see 2.2.11
as the latest open source version.

Just 0.02$,
Alexey.
___
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] New category proposal, i18n

[Alexey Shuvaev]

On Tue, Jun 23, 2009 at 10:13:48AM -0400, Thomas Abthorpe wrote:
> 2009/6/23 Chris Rees :
> > 2009/6/23 Doug Barton :
> >> Thomas Abthorpe wrote:
> >>> To have localization, you need internationalization, so from this, I 
> >>> stand by
> >>> my original proposal of i18n.
> >>
> >> I have no objection to your reasoning, but continue to object to the
> >> specific string. If you're going to go down this road then
> >> "internationalization" would be the better choice.
> >>
> >> Doug
> >>
> >
> > I would agree with Doug. We're in the days of tab-completion, and
> > typing 'in' will suffice to get there. I for one *hate* numbers
> > in paths; it takes one's hand off the letters. Also, I had to look up
> > i18n to find out what it was... Categories should be immediately
> > descriptive.
> >
Hard to achive... x11-wm, x11-fm, audio vs. multimedia, ...

> > Also, the French have to use Shift to type numbers; it's even more of
> > a pain for them!
> >
Unrelated problem.

head -50 test.c
kill -s KILL 46129
man 3 printf
mount /dev/da0a mnt/

I think you can't avoid using numbers in command-line.
BTW, numbers are much better than spaces or localized characters:
'Мои документы' ( == 'My Documents')

> > Chris
> >
> >
> 
> You have struck a chord with numbers in the path, reminds me of the
> pre-Xorg days with /usr/X11R6, not sure what I disliked more, the
> capital letters or the numbers!
> 
> I hereby relent, and yield to the logic of the arguments placed before
> me, I now agree that using internationalization for the category name
> is a better idea.
> 
Well, if the new category supposed to be real,
I don't like 'internationalization' name.
The reason? Very simple.
For now I get:

~> ls /usr/ports/
CHANGES   archivers finance   misc  shells
COPYRIGHT astro frenchmultimediasysutils
GIDs  audio ftp   net   textproc
INDEX-8   benchmarksgames net-imukrainian
KNOBS biology   germannet-mgmt  vietnamese
LEGAL cad   graphics  net-p2p   www
MOVED chinese   hebrewnews  x11
Makefile  comms hungarian packages  x11-clocks
Mkconvertersirc   palm  x11-drivers
READMEdatabases japanese  polishx11-fm
Templates deskutils java  ports-mgmtx11-fonts
Tools devel koreanportuguesex11-servers
UIDs  distfiles lang  print x11-themes
UPDATING  dns   mail  russian   x11-toolkits
accessibility editors   math  science   x11-wm
arabicemulators mbone security

which fits fine in one 80x25 terminal window.
With the new category:

~> ls /usr/ports/
CHANGES  develnet-p2p
COPYRIGHTdistfilesnews
GIDs dns  packages
INDEX-8  editors  palm
KNOBSemulatorspolish
LEGALfinance  ports-mgmt
MOVEDfrench   portuguese
Makefile ftp  print
Mk   gamesrussian
README   german   science
Templatesgraphics security
Toolshebrew   shells
UIDs hungariansysutils
UPDATING internationalization textproc
accessibilityirc  ukrainian
arabic   japanese vietnamese
archiversjava www
astrokorean   x11
audiolang x11-clocks
benchmarks   mail x11-drivers
biology  math x11-fm
cad  mbonex11-fonts
chinese  misc x11-servers
commsmultimedia   x11-themes
converters   net  x11-toolkits
databasesnet-im   x11-wm
deskutilsnet-mgmt

which is too long.
You need to scroll to see the whole content of the folder.



About the topic: from
http://lists.freebsd.org/pipermail/freebsd-ports/2009-June/055424.html

> It is my intention for ports that do localization related work
> would remain in their existing category, and if appropriate
> we could add the new name to CATEGORIES.

from:
http://lists.freebsd.org/pipermail/freebsd-ports/2009-June/055463.html

> To paraphrase a couple of key points
>
> "Localization refers to the adaptation of a product, application
> or document content to meet the language, cultural and other requirements
> of a specific target market (a "locale")."
>
> ...
>
> "Internationalization is the design and development of a product,
> application or document content that enables easy localization
> for target audienc

Re: needing install OpenOffice.org without messing up perl

[Alexey Shuvaev]

On Wed, Jul 22, 2009 at 07:52:11AM -0500, Scott Bennett wrote:
>  I wrote:
> > Sure, but OOo is so huge and requires so much other stuff
> >that there is almost certainly something it wants installed that
> >I do not already have installed.
> >
> > Why wouldn't OOo, once installed, simply use whatever were
> >installed as /usr/local/bin/perl?
> > It seems to me that the bigger worry it that portmaster may
> >try to rebuild it whenever a -a option is used.  portmanager, OTOH,
> >has a -u option that might do the job.  portupgrade, of course,
> 
>  My mistake.  portmanager -u is supposed to accomplish roughly
> what portmaster -a or portupgrade -a accomplishes.  I meant to write
> portmanager -u -ip packagename rather than what I wrote before.
> 
> >can have all sorts of things blocked from upgrading by putting the
> >proper magic into /etc/portupgrade.conf.  If only portmaster had
> >a similar way of doing things.  Since so many people now advocate
> >using either portmanager or portmaster to do general upgrades (-a),
> >rather than portupgrade -a, I guess portmanager is the only method
> >available to keep OOo from being rebuilt whenever one of its
> >dependencies gets upgraded.
> >
If only you have RTFM %)
>From man portmaster:

 /var/db/pkg/*/+IGNOREME
   If this file exists, several things will happen:

   1. The port will be ignored for all purposes, including
   dependency updates, if there is no directory for it in
   /usr/ports, and there is no entry for it in /usr/ports/MOVED.
   If the -v option is used, the fact that the port is being
   ignored will be mentioned.

   2. If using the
   -L option, and a new version exists, the existence of the
   +IGNOREME file will be mentioned.

   3. 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; unless the -u option is being used, in
   which case the port will be ignored.

So,
touch /var/db/pkg/openoffice.org-/+IGNOREME
would do the trick.
___
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: Stop in /usr/ports/graphics/aalib

[Alexey Shuvaev]

On Tue, Aug 11, 2009 at 09:44:11PM +0200, Jörgen Nilsson wrote:
> bastion# uname -a
> FreeBSD bastion.mordvap.net 7.2-RELEASE-p3 FreeBSD 7.2-RELEASE-p3 #1: Tue
> Aug 11 19:19:21 CEST 2009
> u...@bastion.host.net:/usr/obj/usr/src/sys/BASTION  i386
> 
> 
> 
> 
> checking whether ln -s works... (cached) yes
> ltconfig: `/usr/local/share/libtool/config/ltmain.sh' does not exist
> Try `ltconfig --help' for more information.
> configure: error: libtool configure failed
> ===>  Script "configure" failed unexpectedly.
> [snip]
> isc-dhcp30-server-3.0.7_4   libtool-1.5.26  pftop-0.7_1
  ^^
> yasm-0.8.0
> 
> 
> #
> 

On Wed, Aug 12, 2009 at 07:45:53PM +0700, karfagen wrote:
> Hi!
> 
> There is /usr/ports/graphics/aalib installation process log:
> 
> # make
> ===>  Vulnerability check disabled, database not found
> ===>  Extracting for aalib-1.4.r5_4
> => MD5 Checksum OK for aalib-1.4rc5.tar.gz.
> => SHA256 Checksum OK for aalib-1.4rc5.tar.gz.
> ===>  Patching for aalib-1.4.r5_4
> ===>  Applying FreeBSD patches for aalib-1.4.r5_4
> ===>   aalib-1.4.r5_4 depends on file: /usr/local/libdata/pkgconfig/x11.pc -
> found
> ===>   aalib-1.4.r5_4 depends on file: /usr/local/bin/libtool - found
> ===>  Configuring for aalib-1.4.r5_4
> creating cache ./config.cache
> checking for a BSD compatible install... /usr/bin/install -c -o root -g
> wheel
> checking whether build environment is sane... yes
> checking whether make sets ${MAKE}... yes
> checking for working aclocal... found
> checking for working autoconf... found
> checking for working automake... found
> checking for working autoheader... found
> checking for working makeinfo... found
> checking host system type... i386-portbld-freebsd7.2
> checking target system type... i386-portbld-freebsd7.2
> checking for gcc... cc
> checking whether the C compiler (cc -O2 -fno-strict-aliasing -pipe )
> works... yes
> checking whether the C compiler (cc -O2 -fno-strict-aliasing -pipe ) is a
> cross-compiler... no
> checking whether we are using GNU C... yes
> checking whether cc accepts -g... yes
> checking build system type... i386-portbld-freebsd7.2
> checking for ranlib... ranlib
> checking for ld used by GCC... /usr/bin/ld
> checking if the linker (/usr/bin/ld) is GNU ld... yes
> checking for BSD-compatible nm... /usr/bin/nm -B
> checking whether ln -s works... yes
> updating cache ./config.cache
> ltconfig: `/usr/local/share/libtool/config/ltmain.sh' does not exist
> Try `ltconfig --help' for more information.
> configure: error: libtool configure failed
> ===>  Script "configure" failed unexpectedly.
> [snip]
> 
Have you guys read entry 20090802 in /usr/ports/UPDATING?

HTH,
Alexey.
___
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: Script "configure" failed unexpectedly

[Alexey Shuvaev]

On Thu, Sep 03, 2009 at 07:23:40PM +0200, Stephan Sann wrote:
> Hello,
> 
> while trying:
> /usr/ports/graphics/xsane -> make -DFORCE_PKG_REGISTER install clean
> 
> I got:
> 
> updating cache ./config.cache
> ltconfig: `/usr/local/share/libtool/config/ltmain.sh' does not exist
> Try `ltconfig --help' for more information.
> configure: error: libtool configure failed
> ===>  Script "configure" failed unexpectedly.
> Please report the problem to po...@freebsd.org [maintainer] and attach the
> "/usr/ports/graphics/aalib/work/aalib-1.4.0/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`).
> 
> [snip]
> 
> libtool-1.5.26  ushare-1.1a
>
ports/UPDATING 20090802
___
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"

Tinderbox + perl5.10?

[Alexey Shuvaev]

Hello all!

After about one month of playing with ports-mgmt/tinderbox (thanks to all
for the tool!) I realized I've applied the following in order to get it
working in my environment (amd64 9-CURRENT with perl5.10):

--- tc_command.sh.orig  2009-09-28 21:35:34.0 +0200
+++ tc_command.sh   2009-09-28 21:35:43.0 +0200
@@ -190,7 +190,7 @@
 #---
 
 Setup () {
-MAN_PREREQS="lang/perl5.8"
+MAN_PREREQS="lang/perl5.10"
 OPT_PREREQS="lang/php[45] databases/pear-DB www/php[45]-session"
 PREF_FILES="tinderbox.ph"
 README="$(tinderLoc scripts README)"

I'm not very good at shell patters. Is there any way to depend on perl5.8 or
perl5.10?
BTW, this issue is seen only on fresh installations.

Thanks,
Alexey.
___
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: Tinderbox + perl5.10?

[Alexey Shuvaev]

On Mon, Sep 28, 2009 at 11:27:50PM +0300, Ion-Mihai Tetcu wrote:
> On Mon, 28 Sep 2009 21:46:06 +0200
> Alexey Shuvaev  wrote:
> 
> > Hello all!
> > 
> > After about one month of playing with ports-mgmt/tinderbox (thanks to
> > all for the tool!) I realized I've applied the following in order to
> > get it working in my environment (amd64 9-CURRENT with perl5.10):
> > 
> > --- tc_command.sh.orig  2009-09-28 21:35:34.0 +0200
> > +++ tc_command.sh   2009-09-28 21:35:43.0 +0200
> > @@ -190,7 +190,7 @@
> >  
> > #---
> >  
> >  Setup () {
> > -MAN_PREREQS="lang/perl5.8"
> > +MAN_PREREQS="lang/perl5.10"
> >  OPT_PREREQS="lang/php[45] databases/pear-DB www/php[45]-session"
> >  PREF_FILES="tinderbox.ph"
> >  README="$(tinderLoc scripts README)"
> > 
> > I'm not very good at shell patters. Is there any way to depend on
> > perl5.8 or perl5.10?
> > BTW, this issue is seen only on fresh installations.
> 
> It should be already fixed in the port, I think I did that.
> If not, it's fixed in marcus' CVS
> 
FYI, it is indeed fixed in marcus' CVS 2 months ago, but it is not
in the ports yet (neither tinderbox nor tinderbox-devel).

Thanks,
Alexey.
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: Problem building Openoffice 3.1.1 at -current

[Alexey Shuvaev]

On Mon, Sep 21, 2009 at 12:15:09PM -0700, Steve Kargl wrote:
> On Mon, Sep 21, 2009 at 02:39:44PM +0300, Andriy Gapon wrote:
> > on 20/09/2009 14:38 Sam Fourman Jr. said the following:
> > > On Sun, Sep 20, 2009 at 6:26 AM, Vinicius Abrahao  
> > > wrote:
> > >> Hello dear fellows,
> > >>
> > >> I'm trying to upgrade my openoffice.org3 from 3.1.0 to 3.1.1, but I'm
> > >> getting an strange error (associated with python).
> > >> This is the error that appears many hours after I start the upgrade:
> > > 
> > > 
> > > I am getting this same error on FreeBSD 8.0 Beta4
> > > any idea how to fix the build?
> > 
> > I also had a compilation problem like this.
> > Perhaps this is related to having python 2.6 installed on a system?
> > 
> > Anyway, I was able to continue the build by doing the following (adjust the 
> > paths
> > to your environment):
> > 
> > $ ln -s
> > /usr/obj/usr/ports/editors/openoffice.org-3/work/OOO310_m19/solver/310/unxfbsdx.pro/lib/python
> > /usr/obj/usr/ports/editors/openoffice.org-3/work/OOO310_m19/solver/310/unxfbsdx.pro/lib/python2.6
> > 
> > $ cp
> > /usr/obj/usr/ports/editors/openoffice.org-3/work/OOO310_m19/python/unxfbsdx.pro/misc/build/Python-2.6.1/build/lib.freebsd-9.0-CURRENT-amd64-2.6/*.so
> >  
> > /usr/obj/usr/ports/editors/openoffice.org-3/work/OOO310_m19/solver/310/unxfbsdx.pro/lib/python2.6/
> > 
> > Maybe something else, it was a while ago.
> > 
> 
> The above ln and cp were sufficient to complete my build.
> I haven't tested the resulting exectuables.
> 
> Thanks, Andriy
> 
Rrrr
The openoffice guys are trying to bundle every piece of code under
the sun into their tarball in attempt to not depend upon system libraries...
... and are getting away from what they want to achieve (IMHO).

OOO is as fragile as porcelain plate and
still as complex to repair as nuclear u-boot.

I hate OOO...

With the attached patch I was able to complete the build on
amd64 9-CURRENT. Will charge 9-amd64-Ports and 9-i386-Ports tinderboxes
to test in a clean environment. Testing on 8-RC is still welcome.
Just drop patch-OOO_XXX_CURRENT into files/ and try to rebuild.

Alexey.
--- python/Python-2.6.1.patch.orig  2009-10-03 22:08:45.0 +0200
+++ python/Python-2.6.1.patch   2009-10-03 23:00:22.0 +0200
@@ -127,7 +127,7 @@
  # Skip platforms with known problems forking from a worker thread.
  # See http://bugs.python.org/issue3863.
 -if sys.platform in ('freebsd4', 'freebsd5', 'freebsd6', 'os2emx'):
-+if sys.platform in ('freebsd4', 'freebsd5', 'freebsd6', 'freebsd7', 
'os2emx'):
++if sys.platform in ('freebsd4', 'freebsd5', 'freebsd6', 'freebsd7', 
'freebsd8', 'freebsd9', 'os2emx'):
  print >>sys.stderr, ('Skipping test_3_join_in_forked_from_thread'
   ' due to known OS bugs on'), sys.platform
  return
@@ -230,3 +230,603 @@
  RUNSHARED=LD_LIBRARY_PATH=`pwd`:${LD_LIBRARY_PATH}
  INSTSONAME="$LDLIBRARY".$SOVERSION
;;
+--- misc/Python-2.6.1/Lib/plat-freebsd9/IN.py  1970-01-01 01:00:00.0 
+0100
 misc/build/Python-2.6.1/Lib/plat-freebsd9/IN.py2009-10-03 
22:43:13.0 +0200
+@@ -0,0 +1,571 @@
++# Generated by h2py from /usr/include/netinet/in.h
++
++# Included from sys/cdefs.h
++__GNUCLIKE_ASM = 3
++__GNUCLIKE_ASM = 2
++__GNUCLIKE___TYPEOF = 1
++__GNUCLIKE___OFFSETOF = 1
++__GNUCLIKE___SECTION = 1
++__GNUCLIKE_ATTRIBUTE_MODE_DI = 1
++__GNUCLIKE_CTOR_SECTION_HANDLING = 1
++__GNUCLIKE_BUILTIN_CONSTANT_P = 1
++__GNUCLIKE_BUILTIN_VARARGS = 1
++__GNUCLIKE_BUILTIN_STDARG = 1
++__GNUCLIKE_BUILTIN_VAALIST = 1
++__GNUC_VA_LIST_COMPATIBILITY = 1
++__GNUCLIKE_BUILTIN_NEXT_ARG = 1
++__GNUCLIKE_BUILTIN_MEMCPY = 1
++__CC_SUPPORTS_INLINE = 1
++__CC_SUPPORTS___INLINE = 1
++__CC_SUPPORTS___INLINE__ = 1
++__CC_SUPPORTS___FUNC__ = 1
++__CC_SUPPORTS_WARNING = 1
++__CC_SUPPORTS_VARADIC_XXX = 1
++__CC_SUPPORTS_DYNAMIC_ARRAY_INIT = 1
++__CC_INT_IS_32BIT = 1
++def __P(protos): return protos
++
++def __STRING(x): return #x
++
++def __XSTRING(x): return __STRING(x)
++
++def __P(protos): return ()
++
++def __STRING(x): return "x"
++
++def __aligned(x): return __attribute__((__aligned__(x)))
++
++def __section(x): return __attribute__((__section__(x)))
++
++def __aligned(x): return __attribute__((__aligned__(x)))
++
++def __section(x): return __attribute__((__section__(x)))
++
++def __nonnull(x): return __attribute__((__nonnull__(x)))
++
++def __predict_true(exp): return __builtin_expect((exp), 1)
++
++def __predict_false(exp): return __builtin_expect((exp), 0)
++
++def __predict_true(exp): return (exp)
++
++def __predict_false(exp): return (exp)
++
++def __format_arg(fmtarg): return __attribute__((__format_arg__ (fmtarg)))
++
++def __FBSDID(s): return __IDSTRING(__CONCAT(__rcsid_,__LINE__),s)
++
++def __RCSID(s): return __IDSTRING(__CONCAT(__rcsid_,__LINE__),s)
++
++def __RCSID_SOURCE(s): return __IDSTRING(__CONCAT(__rcsid_source_,__LINE__),s)
++
++def __SCCSID(s):

Re: FreeBSD Port: qtcreator-1.2.1: Not installable

[Alexey Shuvaev]

On Wed, Oct 28, 2009 at 01:56:25PM +0100, Adrian Glaubitz wrote:
> Hi,
> 
> On Wed, Oct 28, 2009 at 1:46 PM, Gary Jennejohn
>  wrote:
> > The qtcreator port was created on May 7, 2009.  Seems to me that 7.2R
> > is older than that.  Obviously, qtcreator can't exist for 7.2R if the
> > port didn't exist when it was released.
> 
> Well, ok. Seems another case of "different systems, different
> philosophies" here for me.
> 
> My idea was that I was downloading the latest STABLE release of
> FreeBSD and I assumed that the ports directory always applies to the
> current STABLE version, noone should use a development version for
> daily use, should one.
> 
The base system (more or less what consists a RELEASE) and ports are
mostly independent of each other. Normal FreeBSD user will have some
RELEASE (say 7.2R) and up-to-date version of ports. There is no
separate STABLE or CURRENT versions of ports, there is only one.
(Well, there are marcuscom and area51 for testing new gnome and kde
releases, respectively, but you don't need to mess with them).
This explains the following:
> Besides, the ports website doesn't list at all what versions of
> FreeBSD include this port as opposed to Debian, for example; I don't
> want to start a flamewar though. It's not really user-friendly, is it.
> 
> I guess the minimum for my project will be FreeBSD 8.0 then.
> 
FreeBSD 7 will be ok too. You can add some phrase like
"Before the software can be built, the following ports/packages
have to be installed:
devel/qtcreator
audio/taglib
devel/glib20
audio/sox
audio/libmad
security/libmcrypt.
Note that ports tree newer than 7 May 2009 is needed to build qtcreator."

This is FreeBSD-user friendly.

HTH,
Alexey.
___
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: qtcreator-1.2.1: Not installable

[Alexey Shuvaev]

On Wed, Oct 28, 2009 at 02:51:29PM +0100, Adrian Glaubitz wrote:
> Hi Alexey,
> 
> On Wed, Oct 28, 2009 at 2:25 PM, Alexey Shuvaev
>  wrote:
> > The base system (more or less what consists a RELEASE) and ports are
> > mostly independent of each other. Normal FreeBSD user will have some
> > RELEASE (say 7.2R) and up-to-date version of ports. There is no
> > separate STABLE or CURRENT versions of ports, there is only one.
> > (Well, there are marcuscom and area51 for testing new gnome and kde
> > releases, respectively, but you don't need to mess with them).
> 
> Ok, thanks alot for shedding some light here. I am not really into
> FreeBSD but long term Linux user, so consider me being a noob here
> ;-).
> 
> > FreeBSD 7 will be ok too. You can add some phrase like
> > "Before the software can be built, the following ports/packages
> > have to be installed:
> > devel/qtcreator
> > audio/taglib
> > devel/glib20
> > audio/sox
> > audio/libmad
> > security/libmcrypt.
> > Note that ports tree newer than 7 May 2009 is needed to build qtcreator."
> >
> > This is FreeBSD-user friendly.
> 
> Thanks alot, I will put into our wiki like this. Is there actually a
> command to upgrade the ports tree, so that I can use the latest ports
> with FreeBSD 7.2? What would be the proper instructions to install the
> necessary ports, I want to try compiling our software on FreeBSD.
> 
See http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/ports-using.html
It covers pretty much of what you want.
You can also get better overview by going up one level:
http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/ports.html

> BTW: Whom should I contact to get our project into the ports? I guess
> a fully fledged MiniDisc transfer software could be interesting for
> alot of FreeBSD users as well ;-).
> 
Mmmm... Well, I think the best bet is yourself! The MAINTAINER variable
in ports' Makefiles points to the person responsible for the given port.
Everybody can become FreeBSD port maintainer. If you search for my
email address at http://www.freebsd.org/ports/index.html
in 'maintainer' category you'll find the ports I'm maintaining.

Creating FreeBSD port is not so difficult. And your companions here
are
1) Porter's Handbook:
   http://www.freebsd.org/doc/en_US.ISO8859-1/books/porters-handbook
2) Other ports as examples and
3) this mailing list if you have some specific problems.

However you'll find that it is better to roll some distribution
of your software to use it in the port (so to be possible to download
tarball with sources and not to use git directly).

Good luck!
Alexey.
___
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: Newbie question about additional documentation

[Alexey Shuvaev]

On Mon, Nov 23, 2009 at 09:23:18PM +0100, dave wrote:
> On Mon, 2009-11-23 at 12:21 +, Matthew Seaman wrote:
> > David Fries wrote:
> > > Hi everybody
> > > 
> > > I started working on my first port (a Haskell cabal package) over the
> > > last weekend. I read the porter's handbook and then began by looking
> > > at similar ports that already existed in the ports collection (e.g.
> > > archivers/hs-zlib) to get a basic idea of what the port should look
> > > like. I noticed that the only documentation listed in pkg-plist of
> > > these ports is the LICENSE file. So pkg-plist looks something like
> > > this:
> > > 
> > > ... other files..
> > > %%PORTDOCSDOCSDIR%%/LICENSE
> > > %%portdoc...@dirrm %%DOCSDIR%%
> > > ... @exec/@unexec...
> > > 
> > > However, when you install the port (assuming NOPORTDOCS is not set),
> > > a HTML documentation will also be generated by the Haskell compiler
> > > and put into %%PORTDOCSDOCSDIR%%/html/*. So my question is, is it
> > > ok to omit these html files in the pkg-plist? I thought, you should
> > > list those too...
> > 
> > It's not OK to install files without any record in the pkgdb.  If you do
> > things like that, firstly any committer working on the port should bounce
> > it back to you as not fulfilling the required standards, and secondly, if
> > the port does somehow get committed you'll be getting irate e-mails from
> > various QA systems that spend all their time looking for such problems.
> > 
> > Now, explicitly listing all of the files that get installed in pkg-plist
> > in the port directory is one way of dealing with this.  There are 
> > alternatives
> > though, which might suit your port better.  Check out the PLIST_FILES and
> > PORTDOCS variables in /usr/ports/Mk/bsd.port.mk -- in short these are:
> > 
> >PLIST_FILES a way of listing a short pkg_plist entirely from within
> >the port Makefile, which helps avoid using up inodes for
> >tiny little files
> >  
> > 
> >PORTDOCS a way of automatically adding a whole directory tree of
> > documentation to the pkg pretty much automatically. This is
> > particularly useful if your docco is generated automatically
> > and you can't always know exactly what files there will be
> > beforehand.
> > 
> > Cheers,
> > 
> > Matthew
> 
> Thanks for the hints. 
> 
> In section 5.14.4 of Porter's Handbook it says:
> [snip]
> 
> After looking at the Makefile again, I noticed that the maintainer of
> hs-zlib defined PORTDOCS= * . If I understand correctly, that means you
> can put as many files in DOCSDIR as you want. The asterisk will match
> everything and you always end up with everything registered in the final
> packing list. Right?
> 
> If so, the line %%PORTDOCSDOCSDIR%%/LICENSE in pkg-plist would be
> redundant, wouldn't it?
> 
Seems to be so...

There is one bad thing about PORTDOCS method: you don't have static
list of files the port is going to install. Some commiters here don't like
it. This is of course up to you but if it is not hard it is better to
manually list all of the installed files in static pkg-plist.

Just 0.02$,
Alexey.
___
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] Experimental 3D HW accel support for Radeon HD 2xxx, 3xxx and 4xxx, 2nd!

[Alexey Shuvaev]

On Tue, Dec 22, 2009 at 12:26:38AM -0600, Robert Noland wrote:
> On Mon, 2009-12-21 at 04:58 +0900, Norikatsu Shigemura wrote:
> > On Mon, 21 Dec 2009 00:34:22 +0900
> > Norikatsu Shigemura  wrote:
> > > > I'm ready to update ports related Mesa3D to 7.6 base, 
> > > > graphics/dri,
> > > > graphics/libGL*, graphics/libglut, graphics/mesa-demos and
> > > > graphics/libdrm.  Please see also my attached patch file.  I'll
> > > > update these as soon as tomorrow.
> > >   Reworking for 7.6.1-rc4.  Please test attached patch.
> 
> I've put a patch of 7.6.1 release at:
> 
> http://people.freebsd.org/~rnoland/mesa-7.6.1-release.patch
> 
> As much as I don't want to, I need to request a repo copy of libdrm in
> order to keep nouveau working...  The bits needed for r600 were added
> just after 2.4.12 and the bits that broke nouveau were just before
> 2.4.13...
> 
+1 for keeping nouveau working.

Alexey.
___
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 marked as IGNORE - (cups-pdf) & (urlview) why - how long?

[Alexey Shuvaev]

On Tue, Dec 22, 2009 at 11:23:58AM +, David Southwell wrote:
> > David Southwell wrote:
> > > Hi just curious about:
> > >
> > > - print/cups-pdf (marked as IGNORE)
> > > - textproc/urlview (marked as IGNORE)
> > >
> > > Anyone know what is happening with these? Get IGNORE with portupgrade -a.
> > 
> > $ cd /usr/ports/print/cups-pdf
> > $ make
> > ===>  cups-pdf-2.5.0 is marked as broken: does not install.
> > *** Error code 1
> > 
> > Stop in /usr/local/ports/print/cups-pdf.
> > 
> > 
> > $ portmaster .
> > ===>>> Port directory: /usr/ports/print/cups-pdf
> > ===>>> This port is marked BROKEN
> > ===>>> does not install
> > 
> > ===>>> If you are sure you can build it, remove the
> >BROKEN line in the Makefile and try again.
> > 
> > 
> > hth,
> > 
> > Doug
> > 
> > PS, Josh, if this e-mail address still works for you, howdy!  :)
> > 
> I am wondering what changes have taken place to change this from a 
> functioning 
> port to one that justifies it being labelled as broken. It must have compiled 
> OK for me as I already have cups-pdf-2.5.0 installed which appears to be the 
> same version. I heard some rumour that it was failing on ubuntu but not on 
> freebsd. Is there any truth in that? 
> 
> Is there any provision to ensure that something which should be marked as 
> broken for ubuntu is not, in consequence,automatically marked as broken when 
> on freebsd?
> 
> dns1# pkg_info |grep cups
> cups-base-1.4.2_3   Common UNIX Printing System: Server
> cups-client-1.4.2_3 Common UNIX Printing System: Library cups
> cups-image-1.4.2_3  Common UNIX Printing System: Library cupsimage
> cups-pdf-2.5.0  A virtual printer for CUPS to produce PDF files
> cups-pstoraster-8.15.4_4 Postscript interpreter for CUPS printing to non-PS 
> printers
> cups-samba-6.0_2The Common UNIX Printing System:  MS Windows client 
> drivers
> cups-smb-backend-1.0_2 A CUPS backend for printing to Windows servers
> gnome-cups-manager-0.31_10,1 Admistration tool for cups
> gutenprint-cups-5.2.4 GutenPrint Printer Driver
> libgnomecups-0.2.3_2,1 Support library for gnome cups admistration
> py26-cups-1.9.46CUPS bindings for Python
> dns1#
> 
Strange, but you can try to figure out what happening at pointyhat:
http://people.freebsd.org/~fenner/errorlogs/si...@olofsson.de-date.html

0.02$,
Alexey.
___
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: [SDL-1.2.14] Build fails on the libvlg checking

[Alexey Shuvaev]

On Sun, Jan 31, 2010 at 05:40:22PM +0100, Marcus von Appen wrote:
> On, Sun Jan 31, 2010, David Marec wrote:
> 
> > Le dimanche 31 janvier 2010 14:27:19, Marcus von Appen a écrit :
> > 
> > > /usr/lib/libvgl.* should not be available on RELENG_8, amd64 - instead
> > > it should reside in /usr/lib32 only. Did you upgrade from i386 to amd64
> > > or did you manually link the libvgl.* to /usr/lib?
> > 
> > Neither of them.
> > 
> > The system is amd64 from the begining.
> > 
> > 
> > > If so, please remove them or run make config and disable the VGL knob
> > > (or add 'WITHOUT_VGL=true' to the make invocation).
> > 
> > That s what i did.
> 
> And it still does not work for you?
> 
> > But, if, for example, svgalib is tagged "i386 only", svgl is not.
> 
> If I manually link libvgl.* from /usr/lib32 to /usr/lib and rebuild SDL
> with VGL enabled, anything links properly. I am not sure, what's wrong
> on your side. If it still fails for you after disabling the VGL knob,
> could you please send me the config.log from
> /usr/ports/devel/sdl12/work/SDL-1.2.14 as well as the tee'd output from
> your make invocation:
> 
>  make | tee sdlbuild.log
>  
> > btw, should i remove these libs ?
> 
> I do not recommend to do that manually. Which shared library versions of
> libvgl are installed (output of find /usr/lib -name "*vgl*") on your
> side?
> Did you ever run make delete-old or make delete-old-libs after updating
> the system?
> 
Just FYI, libvgl is built natively on amd64 now:

Revision 197025 - (view) (annotate) - [select for diffs]
Modified Wed Sep 9 09:50:31 2009 UTC (4 months, 3 weeks ago) by delphij
File length: 3386 byte(s)
Diff to previous 194869

 - Teach vesa(4) and dpms(4) about x86emu. [1]
 - Add vesa kernel options for amd64.
 - Connect libvgl library and splash kernel modules to amd64 build.
 - Connect manual page dpms(4) to amd64 build.
 - Remove old vesa/dpms files.

Submitted by:   paradox  [1], swell k at gmail.com
(with some minor tweaks)

Alexey.
___
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: Puzzled about gettext dependencies

[Alexey Shuvaev]

On Tue, Feb 09, 2010 at 04:01:01PM -0800, Chuck Swiger wrote:
> Hi--
> 
> On Feb 9, 2010, at 3:53 PM, Andrea Venturoli wrote:
> > # pkg_which /usr/local/bin/msgcat
> > gettext-0.17_1
> > 
> > # ldd /usr/local/bin/msgcat
> > /usr/local/bin/msgcat:
> >libgettextsrc-0.17.so => /usr/local/lib/libgettextsrc-0.17.so 
> > (0x33c7f000)
> >libgettextlib-0.17.so => /usr/local/lib/libgettextlib-0.17.so 
> > (0x33cb4000)
> >libcroco-0.6.so.3 => /usr/local/lib/libcroco-0.6.so.3 (0x33d91000)
> >libxml2.so.5 => /usr/local/lib/libxml2.so.5 (0x33dc6000)
> >libz.so.4 => /lib/libz.so.4 (0x33ef2000)
> >libm.so.5 => /lib/libm.so.5 (0x33f04000)
> >libglib-2.0.so.0 => /usr/local/lib/libglib-2.0.so.0 (0x33f19000)
> >libintl.so.8 => /usr/local/lib/libintl.so.8 (0x33fc8000)
> >libpcre.so.0 => /usr/local/lib/libpcre.so.0 (0x33fd1000)
> >libncurses.so.7 => /lib/libncurses.so.7 (0x34004000)
> >libiconv.so.3 => /usr/local/lib/libiconv.so.3 (0x34043000)
> >libc.so.7 => /lib/libc.so.7 (0x3413a000)
> >libz.so.3 => /lib/libz.so.3 (0x3423c000)
> >libm.so.4 => /lib/libm.so.4 (0x3424d000)
> > 
> > Is it me or the output of the latter command contraddicts the dependency 
> > database?
> > It seems to me libcroco, libglib, libpcre, and libxml2 are additional 
> > dependencies...
> > 
> > Have I done something wrong?
> 
> It doesn't do that here:
> 
> # pkg_which /usr/local/bin/msgcat
> gettext-0.17_1
> 
> # ldd /usr/local/bin/msgcat
> /usr/local/bin/msgcat:
>   libgettextsrc-0.17.so => /usr/local/lib/libgettextsrc-0.17.so 
> (0x2807e000)
>   libgettextlib-0.17.so => /usr/local/lib/libgettextlib-0.17.so 
> (0x280b2000)
>   libncurses.so.6 => /lib/libncurses.so.6 (0x281b2000)
>   libintl.so.8 => /usr/local/lib/libintl.so.8 (0x281f1000)
>   libiconv.so.3 => /usr/local/lib/libiconv.so.3 (0x281fa000)
>   libc.so.6 => /lib/libc.so.6 (0x282d9000)
> 
> I wonder why it's dragged in all of those...?
> 
The port autodetects the presence of these libraries and drags them in.
Taking a closer look at this it turned out that aDe@ has dropped
maintainership of what is referred to as 'autotools'. Not good :(

What follows is just an attempt to fix the problem, however it doesn't :)
and it seems that the port deserves more attention.

A little bit more than 0.02$,
Alexey.
diff -ruN /usr/ports/devel/gettext/Makefile gettext/Makefile
--- /usr/ports/devel/gettext/Makefile   2009-12-19 19:54:28.0 +0100
+++ gettext/Makefile2010-02-10 13:14:41.0 +0100
@@ -30,7 +30,10 @@
CPPFLAGS="-I${LOCALBASE}/include" \
LDFLAGS="-L${LOCALBASE}/lib" \
EMACS="no"
-CONFIGURE_ARGS=--disable-csharp --disable-threads --disable-openmp
+CONFIGURE_ARGS=--disable-csharp --disable-threads --disable-openmp \
+   --without-libintl-prefix --with-included-glib \
+   --with-included-libcroco --with-included-libxml \
+   --disable-java
 USE_LDCONFIG=  yes
 
 PLIST_SUB= VERSION=${PORTVERSION}
@@ -53,15 +56,6 @@
 EXTRA_PATCHES+=${FILESDIR}/extra-patch-nodocs
 .endif
 
-pre-extract:
-.if exists(${PREFIX}/bin/kaffe)
-   @${ECHO_MSG} "Gettext won't build with Kaffe's jar utility.  Doing:"
-   -${MV} ${PREFIX}/bin/jar ${PREFIX}/bin/jar.backup
-   @${ECHO_MSG} "Be sure to mv" ${PREFIX}/bin/jar.backup ${PREFIX}/bin/jar
-   @${ECHO_MSG} "if you abandon your attempt to build gettext."
-   @sleep 5
-.endif
-
 post-patch:
@${FIND} ${WRKSRC} -name configure -print | ${XARGS} \
${REINPLACE_CMD} -e 's|mkdir gmkdir|mkdir|'
@@ -72,14 +66,6 @@
 .endfor
 .endif
 
-post-build:
-.if exists(${PREFIX}/bin/kaffe)
-   -${MV} ${PREFIX}/bin/jar.backup ${PREFIX}/bin/jar
-   @${ECHO_MSG}
-   @${ECHO_MSG} "Your" ${PREFIX}/bin/jar "has been restored."
-   @sleep 5
-.endif
-
 post-install:
 .for f in po-compat.el po-mode.el
@${INSTALL_DATA} ${WRKSRC}/gettext-tools/misc/${f} \
___
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/xfce4-netload-plugin - why is it marked as broken on 8?

[Alexey Shuvaev]

On Wed, Feb 10, 2010 at 10:33:35PM +0100, Torfinn Ingolfsen wrote:
> Hello,
> 
> On Fri, Jan 15, 2010 at 7:41 PM, Greg Larkin  wrote:
> 
> > This commit log refers to the fact that the value of __FreeBSD_version
> > was bumped to 800045 due to the removal of the if_ppp(4) driver.  You
> > can find all of the historical values of that variable here:
> > http://www.freebsd.org/doc/en/books/porters-handbook/freebsd-versions.html
> >
> > In this case, the port Makefile should be patched like so:
> >
> > - --- Makefile.orig   2010-01-15 13:37:50.374330422 -0500
> > +++ Makefile2010-01-15 13:38:04.101133409 -0500
> > @@ -24,7 +24,7 @@
> >
> >  .include 
> >
> > - -.if ${OSVERSION} >= 80
> > +.if ${OSVERSION} >= 800045
> >
> 
> Well, that value doesn't work anymore. Here's the rub:
> r...@kg-v2# uname -a
> FreeBSD kg-v2.kg4.no 8.0-STABLE FreeBSD 8.0-STABLE #1: Wed Jan  6 21:21:40
> CET 2010 r...@kg-v2.kg4.no:/usr/obj/usr/src/sys/GENERIC  amd64
> r...@kg-v2# pwd
> /usr/ports/sysutils/xfce4-netload-plugin
> r...@kg-v2# make
> ===>  xfce4-netload-plugin-0.4.0_10 is marked as broken: does not compile:
> error: net/if_ppp.h: No such file or directory.
> *** Error code 1
> 
> Stop in /usr/ports/sysutils/xfce4-netload-plugin.
> 
> 
> According to param.h, the value is now 800108. if_ppp.h is still present,
> and the port compiles fine if I comment out the three lines reagarding the
> BROKEN meaasge.
> 
You have stale files in your system. From /usr/src/ObsoleteFiles.inc:

# 20090406: usb_sw_transfer.h removed
OLD_FILES+=usr/include/dev/usb/usb_sw_transfer.h
# 20090405: removal of if_ppp(4) and if_sl(4)
OLD_FILES+=sbin/slattach rescue/slattach
OLD_FILES+=sbin/startslip rescue/startslip
OLD_FILES+=usr/include/net/if_ppp.h
OLD_FILES+=usr/include/net/if_pppvar.h
OLD_FILES+=usr/include/net/if_slvar.h
OLD_FILES+=usr/include/net/ppp_comp.h
OLD_FILES+=usr/include/net/slip.h
OLD_FILES+=usr/sbin/sliplogin

You should do 'make delete-old' and 'make delete-old-libs' during upgades.

> > A better fix might be to port the code from using if_ppp(4) to the
> > replacement ppp(8), as noted in the commit log.
> 
> Probably. I don't know how to do that. Sorry.
>
___
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: Puzzled about gettext dependencies

[Alexey Shuvaev]

On Thu, Feb 11, 2010 at 09:08:08PM +0100, Andrea Venturoli wrote:
> Il 02/10/10 13:21, Alexey Shuvaev ha scritto:
> 
> >The port autodetects the presence of these libraries and drags them in.
> >Taking a closer look at this it turned out that aDe@ has dropped
> >maintainership of what is referred to as 'autotools'. Not good :(
> >
> >What follows is just an attempt to fix the problem, however it doesn't :)
> >and it seems that the port deserves more attention.
> >
> >A little bit more than 0.02$,
> >Alexey.
> 
> Thanks Alexey.
> 
> I admit I didn't try your patch, since you said in advance it doesn't work.
> 
> I really haven't understood whether this is a bug (or feature) in
> gettext or autotools (autoconf?).
> 
> Should I fill a PR in?
> 
Yes, it is non-critical bug in devel/gettext.
___
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/syslog-ng3 processes

[Alexey Shuvaev]

On Fri, Feb 26, 2010 at 04:51:25PM +0200, Marin Atanasov wrote:
> Hello,
> 
> I've noticed that when I start syslog-ng3 daemon it starts two processes. I
> haven't seen this when running syslog-ng.
> 
> Here are the processes:
> 
> root 554  0.0  0.1  5320  2092  ??  I 4:46PM   0:00.00
> /usr/local/sbin/syslog-ng -p /var/run/syslog.pid
> root 555  0.0  0.1  5320  2456  ??  Ss4:46PM   0:00.02
> /usr/local/sbin/syslog-ng -p /var/run/syslog.pid
> 
> I was wondering why it actually start two (identical?) processes? Anyone has
> an idea? Is this normal?
> 
I think this would happen if you have two different scripts in
/usr/local/etr/rc.d that launch the same daemon. I think the names
of the scripts do not matter here. Do you have any stale rc.d scripts
in /usr/local/etr/rc.d?

HTH,
Alexey.
___
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?

[Alexey Shuvaev]

On Mon, Mar 29, 2010 at 05:57:04PM +0200, Ivan Voras wrote:
> Hi,
> 
> First of all, I'd like to have this particular discussion in the open
> with ports developers and maintainers. So please - if you are a "simple"
> user, without a port to maintain, you will be given another thread if
> anything comes out as a result from this discussion.
> 
To start with, the number of ports I maintain is not large at all,
and all of them are mostly "dark corners" never used.

> There is a discussion[*] currently in The Forbidden Palace about the
> possibility (it's just that - a discussion of viability) of having a
> "stable" ports branch which would in the future as a consequence enable
> building binary packages and deploying them in the way of Linux's "apt"
> and "yum" tools.
> 
> 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?

If this is the case, 6.x branch will have pretty outdated
"heavy infrastructure" ports (like gnome/kde libs, see below).
What if the supported lifetime of the port upstream is less than
supported lifetime of FreeBSD branch? Who will backport at least
security fixes to the port?

> Some more potential properties:
> 
> * Ports in the stable branch/overlay would be maintained with more
> rigorous checking.
>
Are the current ports not already rigorously tested? :)

> * 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
to be updated? In other words what is the difference between proposed
"stable" ports branch and a static snapshot?

> * 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?

> This is obviously pretty fuzzy - rules would need to be specifically
> made later.
> 
> The biggest problem would seem to be the burden this would have on ports
> developers vs the gains that could be gotten from this system.
> 
> 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.
> 
> Some of the benefits are also obvious. The scheme would allow faster and
> more convenient updating of the system, without breakage of shlibs
> within a branch.
> 
> Within all this, I think one point is important: there should be no
> inventing of wheels or pioneering work on this. Much the same concepts
> are already proven to work with Linux systems (stable package branches,
> apt and yum), so this is not very much unknown territory. Here not be
> dragons :)
> 
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...

> I consider this just an opinion-collecting thread: Would you, as a
> maintainer / developer, be interested in something like this, and why?
> 
Weighting these all, I would say no. There is already enough fun keeping
ports working on CURRENT. And see below.

> [*] the discussion was started unexpectedly following my post bringing
> http://blog.hagander.net/archives/167-PostgreSQL-infrastructure-updates.html
> to attention.
> 
Quoting:
"... that will ensure that all our machines look the same way.
This also plugs into our monitoring systems very well,
making applying (security) updates across the many machines much easier. ..."

It's a pity that pgsql devs are not familiar with ports-mgmt/tinderbox...
Looks like it is exactly what they need. Maybe the README from tinderbox
deserves the place in the handbook
("Preparing packages in corporate environment" or something similar)?
Compiling the set of possibly customized (patched) packages for further
deployment on a large number of machines is an easy task when using
tinderbox.

Back on topic, would not it be better to provide "official packages for
upgrades" built from some chosen snapshots of the ports tree?
Then some community (portmgr?) would shape the flow of updates to the tr

Silent distfiles conflict between graphics/xface.el and mail/x-face-e21.

[Alexey Shuvaev]

Hello!

Could please someone with emacs knowledge (preferably ports commiter)
look into issue http://www.freebsd.org/cgi/query-pr.cgi?pr=141839

Both ports refer distfiles with the same name but of different sizes
(and checksums). It looks like one port is a subset of another,
but I am not familiar with emacs to say for sure.

Both maintainers, yoichi@ and ume@ haven't responded to private mails yet.

Thanks,
Alexey.
___
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

[Alexey Shuvaev]

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 BUILD&RUN 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}/../..//"
> 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? :)

> 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,
Alexey.
___
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: looking for simple 3d plotting program

[Alexey Shuvaev]

On Thu, Apr 08, 2010 at 11:05:15AM -0400, Robert Huff wrote:
> 
> Robert Huff writes:
> 
> > I have a project for which I need to produce a {gif, jpg, png}
> >  of a 3d space, with labled axes, and plot a small number (<25 ??) of
> >  points within it, either with labels or as icons.
> > Two constraints:
> > Current code is written in C.
> 
>   I expressed myself badly.  What I should have said was:
> 
>   It must be usable via C function calls.
> 
Not the best and the most elegant way to achieve this, but...
you can try math/gnuplot. It can do 3d.
CC=gcc
CCFLAGS= -g -Wall 
LDFLAGS= -lm -lpthread

target= testgnuplot
objects= testgnuplot.o gnuplot.o

all: $(target)

$(target): $(objects) 
$(CC) $(LDFLAGS) $(objects) -o $@ 

%.o: %.c
$(CC) $(CCFLAGS) -c $< -o $@

clean:
rm -f $(objects)
rm -f $(target)
gnuplot.c implements a helper function that invokes gnuplot
to display the acquired data. 

You need to have the gnuplot package installed to take advantage
of this function.

You can reuse it in your program by adding the gnuplot.c and 
gnuplot.h files to your project and calling the function:

int sendDataToGnuplot(int handle, float x0, float dX,
  double *buffer, int nbOfPointsPerCh,
  int nbOfCh);

handle is the handle of the acquisition session returned by _PdAquireSubsystem.
x0 is the origin of the x axis
dX is the increment between each points on the x axis
buffer contains the acquired data
nbOfPointsPerCh contains the number of sampels acquired for each channel
nbOfCh contains the number of channels
  
___
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

[Alexey Shuvaev]

On Fri, Apr 23, 2010 at 11:58:18AM -0700, Doug Barton wrote:
> On 04/23/10 11:52, Sean McAfee wrote:
> > I can confirm this behavior on multiple installs of 8.0Rp2 amd64.  I
> > don't use (or want) TCL, but tried to build it with TCL 8.4, 8.5, and
> > 8.6 installed with no luck.
> > 
> > I just gave up and pkg_add -r'ed it.
> 
> I run -current, so:
> 
> ===>>> The newest available package (sqlite3-3.6.19)
>is older than the version in ports (sqlite3-3.6.23.1_1)
> 
> I don't use tcl either, so I just let sqlite install the default as a
> dependency: tcl-8.5.8
> 
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.
If it does, should sqlite3 port directly depend on tcl-modules?
The problem doesn't manifest itself on the package clusters as
TCL_MODULES turned on by default.

HTH,
Alexey.
___
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"

Xorg 7.5 and Openmotif applications.

[Alexey Shuvaev]

Hello list!

There seems to be a known/fixed bug in new xserver that leads to
(many|all?) motif-based applications to malfunction:
https://bugs.freedesktop.org/show_bug.cgi?id=25400

There are already at least 2 PRs opened against individual ports:
http://www.freebsd.org/cgi/query-pr.cgi?pr=146383
http://www.freebsd.org/cgi/query-pr.cgi?pr=146380

I think it is wrong to patch applications when the fault seems to be
in the server. Now I am running patched xserver with the patch pulled
from the upstream git master:
http://cgit.freedesktop.org/xorg/xserver/commit/?id=1c612acca8568fcdf9761d23f112adaf4d496f1b

I confirm that math/grace now works OK (PR 141383).
I'll watch if the patch causes any side effects (nothing so far).
What about dropping attached patch to x11-servers/xorg-server/files?

Cross-posting to ports@ as the bug already leaked in the individual
ports' PRs.

Thanks,
Alexey.
>From 1c612acca8568fcdf9761d23f112adaf4d496f1b Mon Sep 17 00:00:00 2001
From: Peter Hutterer 
Date: Wed, 17 Mar 2010 04:32:38 +
Subject: dix: if owner-events is true for passive grabs, add the window mask 
(#25400)

A client requesting a GrabModeSync button grab, owner-events true, with only
the ButtonRelease mask set would never receive the press event even if the
grab window had the ButtonPress mask set.

The protocol requires that if owner-events is true, then the delivery mask
is the combination of the grab mask + the window event mask.

X.Org Bug 25400 

Signed-off-by: Peter Hutterer 
Tested-by: Jim Ramsay 
Signed-off-by: Keith Packard 
---
diff --git a/dix/events.c b/dix/events.c
index 0e9bc31..6541652 100644
--- dix/events.c.orig
+++ dix/events.c
@@ -3552,6 +3552,8 @@ CheckPassiveGrabsOnWindow(
 xE = &core;
 count = 1;
 mask = grab->eventMask;
+if (grab->ownerEvents)
+mask |= pWin->eventMask;
 } else if (match & XI2_MATCH)
 {
 rc = EventToXI2((InternalEvent*)event, &xE);
@@ -3573,6 +3575,24 @@ CheckPassiveGrabsOnWindow(
 mask = 
grab->xi2mask[device->id][((xGenericEvent*)xE)->evtype/8];
 else if (event->type == XI_Enter || event->type == XI_FocusIn)
 mask = grab->xi2mask[device->id][event->type/8];
+
+if (grab->ownerEvents && wOtherInputMasks(grab->window))
+{
+InputClientsPtr icp =
+wOtherInputMasks(grab->window)->inputClients;
+
+while(icp)
+{
+if (rClient(icp) == rClient(grab))
+{
+int evtype = (xE) ? ((xGenericEvent*)xE)->evtype : 
event->type;
+mask |= icp->xi2mask[device->id][evtype/8];
+break;
+}
+
+icp = icp->next;
+}
+}
 } else
 {
 rc = EventToXI((InternalEvent*)event, &xE, &count);
@@ -3584,6 +3604,22 @@ CheckPassiveGrabsOnWindow(
 continue;
 }
 mask = grab->eventMask;
+if (grab->ownerEvents && wOtherInputMasks(grab->window))
+{
+InputClientsPtr icp =
+wOtherInputMasks(grab->window)->inputClients;
+
+while(icp)
+{
+if (rClient(icp) == rClient(grab))
+{
+mask |= icp->mask[device->id];
+break;
+}
+
+icp = icp->next;
+}
+}
 }
 
(*grabinfo->ActivateGrab)(device, grab, currentTime, TRUE);
___
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: Xorg 7.5 and Openmotif applications.

[Alexey Shuvaev]

On Tue, May 11, 2010 at 09:03:08AM -0500, Robert Noland wrote:
> 
> 
> Alexey Shuvaev wrote:
> >Hello list!
> >
> >There seems to be a known/fixed bug in new xserver that leads to
> >(many|all?) motif-based applications to malfunction:
> >https://bugs.freedesktop.org/show_bug.cgi?id=25400
> >
> >There are already at least 2 PRs opened against individual ports:
> >http://www.freebsd.org/cgi/query-pr.cgi?pr=146383
> >http://www.freebsd.org/cgi/query-pr.cgi?pr=146380
> >
> >I think it is wrong to patch applications when the fault seems to be
> >in the server. Now I am running patched xserver with the patch pulled
> >from the upstream git master:
> >http://cgit.freedesktop.org/xorg/xserver/commit/?id=1c612acca8568fcdf9761d23f112adaf4d496f1b
> >
> >I confirm that math/grace now works OK (PR 141383).
> >I'll watch if the patch causes any side effects (nothing so far).
> >What about dropping attached patch to x11-servers/xorg-server/files?
> >
> >Cross-posting to ports@ as the bug already leaked in the individual
> >ports' PRs.
> 
> Let's look at updating to 1.7.7 or 1.8.0.  I need to poke the commit
> logs for 1.7.7 and see if it is included.
> 
Even better so. Just downloaded xorg-server-1.7.7.tar.gz and the patch
is already there:

~/xorg-server-1.7.7> patch < ../patch-dix-events.c 
Hmm...  Looks like a unified diff to me...
The text leading up to this was:
--
|From 1c612acca8568fcdf9761d23f112adaf4d496f1b Mon Sep 17 00:00:00 2001
|From: Peter Hutterer 

[snip]

|--- dix/events.c.orig
|+++ dix/events.c
--
Patching file dix/events.c using Plan A...
Reversed (or previously applied) patch detected!  Assume -R? [y] n

Thanks for takiing care of it!
Alexey.
___
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: Porting SANE backend 1.0.21 to FreeBSD 7.2

[Alexey Shuvaev]

On Sun, May 23, 2010 at 02:00:46PM -0700, Mark Terribile wrote:
> Thanks to help from Warren Block and Lowell Gilbert,
> I now have the offical ported version of sane-backends-1.0.21 running.
> Unfortunately, it's behaving the same way as before,
> apparently not properly recognizing the USB device.  It 
> 
> Does anyone have experience using this?
>
I have zero experience using SANE, but...

> Or better yet, some sense of what it needs from the USB side?
>
I think the right answer is 'nothing'.

> A clue on enabling the internal debugging would also be welcome.
> 
> I have added
> 
> product CANON CS8800F0x1901CanoScan 8800F
> 
> to /usr/src/sys/dev/usb/usbdevs.  I have also added
> 
> {{ USB_VENDOR_CANON, USB_PRODUCT_CANON_CS8800F }, 0 },
> 
> to /usr/src/sys/dev/usb/uscanner.c
>
I think this is wrong and may cause all of your problems. I have heard
somewhere that the right way of accessing USB scanners on FreeBSD
is through libusb.
That is, your scanner *should not be recognized* by uscanner driver and
*should not appear* in /dev/.

> When I run scanimage -L I get
> -
> 
> device `pixma:04A91901' is a CANON Canoscan 8800F multi-function peripheral
> ---
> 
> When I run scanimage -d pixma:04A9101 I get
> 
> scanimage: sane_read: Invalid argument
> 
> 
> Which I have traced to a defaulted fill routine in a table.
> 
> scanimage --help gives me a message ending with
> ---
> 
> Options specific to device `pixma:04A91901':
>   Scan mode:
> --resolution auto||75|150|300|600|1200|2400|4800dpi [75]
> Sets the resolution of the scanned image.
> --mode auto|Color|Gray [Color]
> Selects the scan mode (e.g., lineart, monochrome, or color).
> --source Flatbed|Transparency Unit [Flatbed]
> Selects the scan source (such as a document-feeder).
> --button-controlled[=(yes|no)] [no]
> When enabled, scan process will not start immediately. To proceed,
> press "SCAN" button (for MP150) or "COLOR" button (for other models).
> To cancel, press "GRAY" button.
>   Gamma:
> --custom-gamma[=(auto|yes|no)] [yes]
> Determines whether a builtin or a custom gamma-table should be used.
> --gamma-table auto|0..255,...
> Gamma-correction table.  In color mode this option equally affects the
> red, green, and blue channels simultaneously (i.e., it is an intensity
> gamma table).
>   Geometry:
> -l auto|0..216.069mm [0]
> Top-left x position of scan area.
> -t auto|0..297.011mm [0]
> Top-left y position of scan area.
> -x auto|0..216.069mm [216.069]
> Width of scan-area.
> -y auto|0..297.011mm [297.011]
> Height of scan-area.
>   Buttons:
> --button-update
> Update button state
> --button-1  [0]
> Button 1
> --button-2  [0]
> Button 2
> 
> Type ``scanimage --help -d DEVICE'' to get list of all options for DEVICE.
> 
> List of available devices:
> 
> 
> 
> There is a /dev/usb/uscanner .
> 
> I haven't figured out how to turn on the internal debugging system, so my 
> first question to someone who may have ported an earlier version is how to do 
> that.
> 
> My second question is whether I have the USB entries right,
> and whether I need to do anything else to make this work.
> 
Try reverting all your changes and look how it goes with
stock sane from ports.

> And finally, I ask for any general wisdom or hints in dealing with SANE and 
> SANE with USB devices.
> 

HTH,
Alexey.
___
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: Xorg 7.5 and Openmotif applications.

[Alexey Shuvaev]

On Tue, May 11, 2010 at 08:21:19PM +0200, Alexey Shuvaev wrote:
> On Tue, May 11, 2010 at 09:03:08AM -0500, Robert Noland wrote:
> > 
> > 
> > Alexey Shuvaev wrote:
> > >Hello list!
> > >
> > >There seems to be a known/fixed bug in new xserver that leads to
> > >(many|all?) motif-based applications to malfunction:
> > >https://bugs.freedesktop.org/show_bug.cgi?id=25400
> > >
> > >There are already at least 2 PRs opened against individual ports:
> > >http://www.freebsd.org/cgi/query-pr.cgi?pr=146383
> > >http://www.freebsd.org/cgi/query-pr.cgi?pr=146380
> > >
> > >I think it is wrong to patch applications when the fault seems to be
> > >in the server. Now I am running patched xserver with the patch pulled
> > >from the upstream git master:
> > >http://cgit.freedesktop.org/xorg/xserver/commit/?id=1c612acca8568fcdf9761d23f112adaf4d496f1b
> > >
> > >I confirm that math/grace now works OK (PR 141383).
> > >I'll watch if the patch causes any side effects (nothing so far).
> > >What about dropping attached patch to x11-servers/xorg-server/files?
> > >
> > >Cross-posting to ports@ as the bug already leaked in the individual
> > >ports' PRs.
> > 
> > Let's look at updating to 1.7.7 or 1.8.0.  I need to poke the commit
> > logs for 1.7.7 and see if it is included.
> > 
> Even better so. Just downloaded xorg-server-1.7.7.tar.gz and the patch
> is already there:
> 
> [snip]
> 
> |--- dix/events.c.orig
> |+++ dix/events.c
> --
> Patching file dix/events.c using Plan A...
> Reversed (or previously applied) patch detected!  Assume -R? [y] n
> 
Since there was no activity on this issue I have updated xorg-server
to 1.7.7. I have not seen any problems so far.
Any objections against updating xorg-server from 1.7.5 to 1.7.7?
Should I file PR?

Alexey.
diff -ruN xorg-server.orig/Makefile xorg-server/Makefile
--- xorg-server.orig/Makefile   2010-05-10 15:16:42.0 +0200
+++ xorg-server/Makefile2010-05-26 15:10:16.0 +0200
@@ -6,7 +6,7 @@
 #
 
 PORTNAME=  xorg-server
-PORTVERSION=   1.7.5
+PORTVERSION=   1.7.7
 PORTEPOCH= 1
 CATEGORIES=x11-servers
 MASTER_SITES=  http://xorg.freedesktop.org/releases/individual/xserver/
diff -ruN xorg-server.orig/distinfo xorg-server/distinfo
--- xorg-server.orig/distinfo   2010-05-10 15:16:42.0 +0200
+++ xorg-server/distinfo2010-05-26 15:14:10.0 +0200
@@ -1,3 +1,3 @@
-MD5 (xorg/xserver/xorg-server-1.7.5.tar.bz2) = 2856130aebf56e3df7b7d9be419bfb28
-SHA256 (xorg/xserver/xorg-server-1.7.5.tar.bz2) = 
91e5f3d05c3e7270f4122235b6ab071210cc79579dcb842ffd4e71199b6bb7aa
-SIZE (xorg/xserver/xorg-server-1.7.5.tar.bz2) = 4926990
+MD5 (xorg/xserver/xorg-server-1.7.7.tar.bz2) = 8c0146330fb155c23d947ac37d431d4b
+SHA256 (xorg/xserver/xorg-server-1.7.7.tar.bz2) = 
54c4d32bfeb8852adbea3ddae6981f3bc2eadb330124d9b35226c617c01926ff
+SIZE (xorg/xserver/xorg-server-1.7.7.tar.bz2) = 4939257
___
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: Xorg 7.5 and Openmotif applications.

[Alexey Shuvaev]

On Thu, May 27, 2010 at 08:33:12PM +, Christian Weisgerber wrote:
> Alexey Shuvaev  wrote:
> 
> > Since there was no activity on this issue I have updated xorg-server
> > to 1.7.7. I have not seen any problems so far.
> > Any objections against updating xorg-server from 1.7.5 to 1.7.7?
> 
> Alas, this does not address the problem with mwm(1).
> 
Hmmm... This is something new. I am successfully running math/grace
with xorg-server 1.7.7. Could you describe what problems with mwm do you see?

Alexey.
___
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: Xorg 7.5 and Openmotif applications.

[Alexey Shuvaev]

On Thu, May 27, 2010 at 11:17:28PM +0200, Alexey Shuvaev wrote:
> On Thu, May 27, 2010 at 08:33:12PM +, Christian Weisgerber wrote:
> > Alexey Shuvaev  wrote:
> > 
> > > Since there was no activity on this issue I have updated xorg-server
> > > to 1.7.7. I have not seen any problems so far.
> > > Any objections against updating xorg-server from 1.7.5 to 1.7.7?
> > 
> > Alas, this does not address the problem with mwm(1).
> > 
> Hmmm... This is something new. I am successfully running math/grace
> with xorg-server 1.7.7. Could you describe what problems with mwm do you see?
> 
I have tried mwm now and don't see any problems. On the other hand I am not
that familiar with mwm to say for sure.

Alexey.
___
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: Xorg 7.5 and Openmotif applications.

[Alexey Shuvaev]

On Fri, May 28, 2010 at 07:16:28PM +, Christian Weisgerber wrote:
> Alexey Shuvaev  wrote:
> 
> > > Alas, this does not address the problem with mwm(1).
> > > 
> > Hmmm... This is something new. I am successfully running math/grace
> > with xorg-server 1.7.7. Could you describe what problems with mwm
> > do you see?
> 
> As soon as you have multiple windows on the screen (two xterms are
> enough) and switch between them, all input is ignored.  You can
> move the pointer, but mouse clicks are ignored, as are keystrokes.
> 
Ok, reproduced. Note that in order to get this hang you should
click on the text area of xterm. Switching by clicking on the window's
titles seems to work.
___
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: replacing audio/libmpcdec by audio/musepack

[Alexey Shuvaev]

On Sat, May 29, 2010 at 12:50:30PM +0200, Stefan Ehmann wrote:
> Hi,
> 
> I'm the maintainer of audio/musepack. With the last update, it now provides 
> libmpdec.so. About 15 ports currently use the older shared library provided 
> by 
> audio/libmpcdec (maintained by multimedia@, CCed).
> 
> For now, mutual CONFLICTS are registered.
> 
> What I'm planning to do is update all depending ports to use audio/musepack, 
> thus making audio/libmpcdec obsolete.
> 
> 
> I have some questions before I'll start working on this task:
> 
> - Are there any objections to deprecating libmpcdec and replacing it by 
> musepack? According to the website, libmpcdec version is "Old. Refer to above 
> SV8 lib (compatible with SV7)".
> 
> After creating a patch for updating and testing:
> - Should I ask the maintainers of the affected ports for approval?
> 
> I've tested musicpd and vlc so far and update was pretty straight-forward:
> replace
> LIB_DEPENDS+=  mpcdec.5:${PORTSDIR}/audio/libmpcdec
> by
> LIB_DEPENDS+=   mpcdec.7:${PORTSDIR}/audio/musepack
> and bump the port revision.
> 
> 
> Because both ports conflict, upgrading needs manual intervention. I guess I 
> should prepare an entry for UPDATING?
> 
> Anything I forgot or other thoughts?
> 
Not that I am using either of them but... libmpcdec is a stand-alone library
while musepack depends on audio/esound. Is this dependency non-avoidable?

0.02$,
Alexey.
___
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: Testing editors/emacs-devel on 9-CURRENT

[Alexey Shuvaev]

On Mon, Sep 06, 2010 at 09:52:18AM +0530, Ashish SHUKLA wrote:
> Hi everyone,
> 
> Could some running 9-CURRENT try building a package of editors/emacs-devel
> port (latest version available in the tree) with default OPTIONS ?
> 
> Something like:
> 
> #v+
> % script emacs-devel.log sudo make -C /usr/ports/editors/emacs-devel build 
> deinstall package
> #v-
> 
> And after building the package, could you paste the generated log
> (emacs-devel.log) at some pastebin[1] and post a link here,
> irrespective of any
> errors you received ?
> 
Here is the tinderbox log on amd64 9-CURRENT:
http://pastebin.com/h1P2V41r

The build for i386 9-CURRENT is underway.

The ports tree is from 3 Sep, but the base used for the tinderbox
is rather old, it is from ~18 May.
I can rebuild it to the host sources which are at r212182 from 3 Sep,
but it will take some time :)

HTH,
Alexey.
___
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-mgmt/tinderbox: fix i386 jail on amd64 host on 9-CURRENT

[Alexey Shuvaev]

Hello!

I've recently bumped into the issue which was already discussed
on current@:
http://lists.freebsd.org/pipermail/freebsd-current/2010-July/018638.html

In short, in the ports' tinderbox, i386 jail fails on the amd64 host
during "make distribution" step. This configuration, while
not strictly supported, is rather usefull.

It looks like it hasn't been fixed in the repository or in ports.
I can confirm that the proposed patch:
http://lists.freebsd.org/pipermail/freebsd-current/2010-July/018676.html
fixes the build of i386 jail on amd64 host.
Attached is an updated patch-lib-tc_command.sh.new which could be
dropped into the files directory of ports-mgmt/tinderbox port
instead of the current file.

Could interested people (cc-ed) check it on other releases and
propagate it upstream?

Thanks,
Alexey.
--- lib/tc_command.sh.orig  2009-11-27 18:32:31.0 +0100
+++ lib/tc_command.sh   2010-09-07 16:50:24.0 +0200
@@ -223,7 +223,7 @@
 #---
 
 Setup () {
-MAN_PREREQS="lang/perl5.[81]"
+MAN_PREREQS="lang/perl5.[81]*"
 OPT_PREREQS="lang/php[45] databases/pear-MDB2 www/php[45]-session"
 PREF_FILES="tinderbox.ph"
 README="$(tinderLoc scripts README)"
@@ -774,10 +774,10 @@
 # determine if we're cross-building world
 crossEnv=""
 if [ "${jailArch}" != "${myArch}" ]; then
-   crossEnv="TARGET_ARCH=${jailArch} MACHINE_ARCH=${jailArch} 
MAKEOBJDIRPREFIX=${J_OBJDIR}/${jailArch} MACHINE=${jailArch}"
+   crossEnv="TARGET_ARCH=${jailArch}"
 fi
-cd ${SRCBASE}/etc && env DESTDIR=${J_TMPDIR} ${crossEnv} \
-   make -m ${J_TMPDIR}/usr/share/mk distribution > 
${jailBase}/distribution.tmp 2>&1
+cd ${SRCBASE} && env DESTDIR=${J_TMPDIR} ${crossEnv} \
+   make distribution > ${jailBase}/distribution.tmp 2>&1
 if [ $? -ne 0 ]; then
echo "ERROR: distribution failed - see ${jailBase}/distribution.tmp"
buildJailCleanup 1 ${jailName} ${J_SRCDIR}
___
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: ptlib build failure - breaks pwlib - hence also asterisk - opal - & openh323

[Alexey Shuvaev]

On Tue, Sep 21, 2010 at 12:29:50PM -0400, Mikhail T. wrote:
>  21.09.2010 12:05, David Southwell написав(ла):
> >Problem is opal does not compile due to failure which was in
> >original posting:
> According to:
> 
> http://pointyhat.freebsd.org/errorlogs/i386-8-latest-logs/opal-2.2.11_2.log.bz2
> 
> Opal builds just fine -- in the "clean" environment... As does ptlib:
> 
> http://pointyhat.freebsd.org/errorlogs/i386-8-latest-logs/ptlib-2.4.4.log.bz2
> 
> Which means, there is something about your configuration, that
> interferes with the build.
> 
> I'm not blaming you -- ports (unlike packages) ought to be flexible
> and build properly in a variety of configurations. The price for
> that flexibility, however, is having to deal with an occasional
> breakage, when your setup deviates "too far" from the mainstream.
> But you need to, at least, diagnose the problem yourself.
> 
> Does the presence of some "unusual" package break the build? Any
> other unexpected setting/configuration option?
> 
> Include that info in a PR, so that the problem can be reproduced...
> Thanks! Yours,
> 
To OP (David Southwell):

Do you have openssl installed from ports (so it shows up in pkg_info
output)?

That might be the cause of your build failures while pointyhat cluster
builds affected ports without errors.

To port maintainers:

Could you try to build your ports in the presence of openssl installed
from ports?

0.02$,
Alexey.
___
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: Crash using OSS when trying to rewind html5 video

[Alexey Shuvaev]

On Tue, Oct 26, 2010 at 10:02:10AM +0200, Beat Gaetzi wrote:
> On 25.10.2010 23:03, Ilya A. Arhipov wrote:
> > Crash using OSS when trying to rewind html5 video.
> > 
> > You can look here: https://bugzilla.mozilla.org/show_bug.cgi?id=605861
> > Also i create pr: http://www.freebsd.org/cgi/query-pr.cgi?pr=151728
> 
> Committed. Thanks!
> 
www/seamonkey2 is also affected.

TIA,
Alexey.
___
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: About games/flightgear-aircrafts

[Alexey Shuvaev]

As for me, I have played fgfs some time ago (5 years?), so...

On Thu, Sep 22, 2011 at 08:21:24PM +0200, Ganael LAPLANCHE wrote:
> On Thu, 22 Sep 2011 09:38:33 -0400, Greg Larkin wrote
> > You can also break them by first letter of the distfile names,
> > combining where appropriate. 
> > [...]
> 
This would not solve any problems with the port, only add troubles for
the end-user.

> On Thu, 22 Sep 2011 09:57:58 -0400, Robert Huff wrote
> >   my first reaction was to break it into broad categories.
> > For example:
> >
> >   aircraft-required
> >  aircraft-25-most-popular
> >  aircraft-civilian-prop
> > [...]
> 
> On Thu, 22 Sep 2011 16:58:03 +0200, Guido Falsi wrote
> > A "civialian-aerobatic" category could be sensible.
> > [...]
> 
> Greg, Robert, Guido, thanks for your suggestions ; anyway, this would
> not solve one of the problems : maintainability of the port :/
> 
Well, this depends, how many aircraft would go into each of categories.
See below...

> On Thu, 22 Sep 2011 08:11:39 -0600 (MDT), Warren Block wrote
> > #2 is reasonable, IMO.
> >
> > Other options, like breaking it up into multiple
> > ports, would not make it easier to maintain and might be more
> > difficult for users.
>  
> Warren, I agree with you : it would make the port even more complex.
> >From a maintainer port of view, we will still have to keep up-to-date
> with those 350+ zip files which regularly change upstream, but will now
> have to deal with sorting them and updating several different ports.
> >From a user point of view, it would also be a pain : users would have to
> browse into each "category" ports to be able to get all the planes they
> need. I am not sure this is the right way to go :/
> 
> I would also vote for #2, or, if we can get a limited list of "good"
> airplanes, option #1. I will try to find if I can get a list of top
> planes on FLightGear website, but I have not seen such a page so far.
> 
I have not looked what is needed to install new aircraft as a user,
but it it would be something against the habbits of a typical FreeBSD user.
At least I would certainly forget to update an aircraft installed this way...

> > (Note: "aircraft" is both singular and plural, so the port
> > name really should be just flightgear-aircraft.)
> 
> Thanks, I'll fix its name if we can manage to keep this port alive :)
> 
>From my experiency a while ago, the quality of the aircraft models varied
greatly from model to model. I remember, there was some transition
from one simulation engine to another more advanced one (JSBsim -> YASim
or vice versa?). For example, some WW II planes were able to perfom "back"
loop in the simulator, which is a non-sense... 
So, my 0.02$ is if you are somewhat familiar with at least some
of aircraft, you can chose those which are mature enough (such as
default Cessna 172).

>From another point of view, you are the maintainer of the port, so
it is up to you to decide (according to your personal prefereces)
which aircraft to include in the port. If somebody lacks his favorite
aircraft, he is free to create another aircraft add-on port, after all...

HTH,
Alexey.
___
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: About games/flightgear-aircrafts

[Alexey Shuvaev]

On Fri, Oct 14, 2011 at 09:14:46AM +0200, Ganael LAPLANCHE wrote:
> On Thu,  6 Oct 2011 10:29:32 +0200 (CEST), Ganael LAPLANCHE wrote
> 
> Hi Everyone,
> 
> > I've established a first selection by following the main 
> > aircraft page :
> > 
> > http://www.flightgear.org/download/aircraft-v2-4/
> > 
> > and removing alpha/beta/experimental/early-production planes. 
> > I'll try to shorten this list one way or another and come back 
> > with a limited aircraft list. If somebody wants a plane to be 
> > added to it, just tell me : I'll update it.
> > 
> > I'll try to work on that ASAP, but I am currently very busy, 
> > so don't expect any change before a few weeks.
> 
> Following my previous post, here is a selection of planes I've made.
> They will remain available in the flightgear-aircrafts port, any other
> plane will be removed and will have to be installed manually :
> 
> * 737-200_20110713.zip : Boeing 737-200
> * A-10_20110629.zip : Fairchild A-10
> * A300_20101217.zip : Airbus A300
> * Alouette-II_20110523.zip : Alouette II
> * Alphajet_20110228.zip : Dassault/Dornier Alphajet
> * B-17_20110516.zip : Boeing B17
> * Breguet-XIX_20101217.zip : Breguet XIX
> * C130_20101217.zip : C130 Hercules
> * Caravelle_20101217.zip : Caravelle
> * Caudron-G3_20101217.zip : Caudron G.III
> * F80C_20101217.zip : Lockheed F-80C Shooting Star
> * Hurricane_20110815.zip : Hawker Hurricane IIb
> * Lightning_20110705.zip : English Electric Lightning F.1A
> * Lockheed1049h_1.0.zip : Lockheed 1049H Super Constellation
> * Messerschmitt-P1101_20101217.zip : Messerschmitt Me P1101
> * MirageIII_20110124.zip : Mirage IIING
> * PaperAirplane_20110103.zip : Paper airplane
> * Pond-Racer_20101217.zip : Rutan Pond Racer
> * R44_20110523.zip : Robinson R44
> * Spitfire_20110705.zip : Supermarine Spitfire
> * Stieglitz_20101217.zip : Focke Wulf FW44 Stiegltz
> * Super-Etendard_20110324.zip : Dassault-Breguet Super Etendard
> * Supermarine-S.6B_20110118.zip : Supermarine S6B
> * Superwal_20101217.zip : Dornier Superwal
> * airwaveXtreme150_20101217.zip : Airwave Xtreme 150 hang glider
> * asw20_20101217.zip : ASW-20 sailplane
> * bf109_20110629.zip : Messerschmitt BF-109 G14
> * c310_20110113.zip : Cessna 310
> * dhc3_20110411.zip : DHC 3 Otter
> * f16_20110629.zip : General Dynamics F-16
> * pa24-250_20110222.zip : Piper Comanche 250
> * tu154_20101217.zip : Tupolev 154
> 
> This (now very limited) list includes every plane in the 'production'
> state, as well as well-known or seemingly interesting ones (no devel,
> beta, alpha, or pre-production ones). I have also tried to keep a wide
> variety of planes available. This list will make the port maintainable
> again. Anyway, it is far from perfect ; also, if a plane is missing, do
> not hesitate to contact me : I'll just add it.
> 
I don't know which aircraft are in the "base" package (flightgear-data),
but IMHO:
 * harrier : British Aerospace Harrier
is something known and interesting (vertical takeoff/landing),
 * il2 : Ilyoushin IL-2
is also quite famous WWII attack plane and
 * wrightFlyer1903 : 1903 Wright Flyer
is must have :)

> I'll commit the changes within 15 days if there is no complaint about
> this list.
> 
Thanks for taking care if the port!
Alexey (with 0.03 air$).
___
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: xorg-server 1.7.7

[Alexey Shuvaev]

On Mon, Nov 08, 2010 at 11:22:37AM +0200, Andriy Gapon wrote:
> 
> Can we update xorg-server to 1.7.7, the latest version on 1.7 branch?
> It looks like that would require only changing the version
> and regenerating the
> checksums.
> 
Seems to be not so trivial. Look at this thread:
http://lists.freebsd.org/pipermail/freebsd-ports/2010-May/061141.html

Since miwi@ and rnoland@ seem to be busy at moment there is a need for
the maintainer of ALL of the xorg-* ports (and not only the single ones,
like xorg-server, etc.). Someone with enough time, motivation (hardware,
programming foo in this area...)

Just 0.02$, :-(
Alexey.
___
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: xorg-server 1.7.7

[Alexey Shuvaev]

On Mon, Nov 08, 2010 at 05:11:41PM +0200, Andriy Gapon wrote:
> on 08/11/2010 17:03 Alexey Shuvaev said the following:
> > On Mon, Nov 08, 2010 at 11:22:37AM +0200, Andriy Gapon wrote:
> >>
> >> Can we update xorg-server to 1.7.7, the latest version on 1.7 branch?
> >> It looks like that would require only changing the version
> >> and regenerating the
> >> checksums.
> >>
> > Seems to be not so trivial. Look at this thread:
> > http://lists.freebsd.org/pipermail/freebsd-ports/2010-May/061141.html
> > 
> > Since miwi@ and rnoland@ seem to be busy at moment there is a need for
> > the maintainer of ALL of the xorg-* ports (and not only the single ones,
> > like xorg-server, etc.). Someone with enough time, motivation (hardware,
> > programming foo in this area...)
> 
> Oh, forgot a need to simply bump port revisions of all xorg driver ports.
> That's perhaps a little bit laborious, but doesn't require any special skills.
> Or did you have something else in mind?
> 
Well, I'm successfully running xorg-server-1.7.7 since May without
doing anything else to other xorg-related ports:

xorg-server-1.7.7,1 >   succeeds index (index has 1.7.5,1)

but it could be just a matter of luck :)

I mean this (from rnolad):
"I have an update to 1.7.7 queued up in my tree along with an updated 
pixman.  It is a little tedious as all of the server based ports need to 
be updated and drivers need PORTREVISION bumps.  I'll try and get it 
committed in the next couple of days though."

He mentions update (not just PORTREVISION bump) of pixman and other
server-based ports. I have some vague insight into what he means,
but I'd say it should be done by a person more familiar (than me) with xorg
infrastucture with all its interdependencies.

Alexey.
___
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: Combining several upgrades using portmaster

[Alexey Shuvaev]

On Tue, Nov 09, 2010 at 09:19:21AM -0800, Doug Barton wrote:
> On 11/09/2010 06:09, Dmitry Pryanishnikov wrote:
> >Hello!
> >
> >   I wonder whether it's possible to automatically combine several
> >upgrades using portmaster. Suppose one have to handle both
> >ports/UPDATING entries:
> >
> >20100530: suggests portmaster -w -r gettext
> >
> >20100328: suggests portmaster -r png-
> >
> >It would be nice to combine them as ' portmaster -w -r gettext -r
> >png-' to prevent double upgrade of relevant packages; however '-r' can
> >be specified only once according to manpage. I've handled this by
> >running both commands, replying 'n' to 'Proceed?' question, merging
> >resulting origin list with sort|uniq and feeding it back to
> >portmaster, but maybe there is a simpler way to solve the problem?
> 
> The number of times that -r is actually required is (thankfully)
> quite small, and the number of times that there is a need to do 2
> -r's of ports that are heavily depended on is very very small. In
> fact I can only remember a few such instances over 15+ years.
> 
> OTOH, the code to handle the -r feature is unfortunately quite
> complex, and I'm a little hesitant to mess with it (to be honest,
> mostly because it's working right now, so I don't want to tempt
> fate). :)  I will, however, add this idea to my big list o'
> portmaster ideas and see if it's something I could tackle at a
> future date.
> 
In the case that you catch 2 or more sweeping updates it is very likely
that you are updating across rather large time interval (half of a year
or more). In this case I usually ignore all '-r' UPDATING entries and
do just portmaster -a. The idea is that almost all ports have got
updated in this large period of time too.

Of course, you shold keep an eye on the system after such upgrade,
manualy reinstalling ports that fail to find old shared library.
But normally there are very few of them.
(From my experience, freetype2 is regulary one of them.)

0.02$,
Alexey.
___
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: Suggestions on getting compiz working?

[Alexey Shuvaev]

On Sun, Nov 21, 2010 at 05:35:20PM -0800, Doug Barton wrote:
> Any ideas? I've tried the suggestions at
> http://www.freebsd.org/doc/en/articles/compiz-fusion/index.html and
> they don't work for me.
> 
>  Original Message 
> Subject: Suggestions on getting compiz working?
> Date: Wed, 10 Nov 2010 22:21:28 -0800
> From: Doug Barton 
> Organization: http://SupersetSolutions.com/
> To: freebsd-gn...@freebsd.org
> 
> I've been multi-booting FreeBSD, Windows, and Ubuntu linux, and the
> default window manager for Ubuntu is compiz (with gnome of course). It
> works well, and I was hoping to get it working in FreeBSD. I tried
> several different configuration options that I found from searching on
> line, but didn't have any success, not even trying to run it all by
> itself (using startx).
> 
> So does anyone have compiz working with gnome on FreeBSD? The CPU and
> RAM on this system are pretty beefy, even though the Intel GPU is fairly
> run of the mill. OTOH, it works in linux ...
> 
Mmm... Error messages, back traces, etc.?
I think, you know, "doesn't work" would not bring you much :)

As a general note, composite + opengl always was a troublesome combination.
And the state of the intel graphics driver on freebsd is also not the best.

0.02$,
Alexey.
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: [CFT] cpu stresser^W libreoffice 3.3.0 final

[Alexey Shuvaev]

On Fri, Jan 28, 2011 at 03:09:24PM -0800, Chip Camden wrote:
> Quoth Baptiste Daroussin on Friday, 28 January 2011:
> > Hi all
> > 
> > I ported libreoffice 3.3.0, you can find it here:
> > http://people.freebsd.org/~bapt/libreoffice.shar or
> > http://git.etoilebsd.net/ports/tree/libreoffice
> > 
> > Can you please test it?
> > 
> > by default it builds without java. it only lacks kde and gnome
> > integration. (sorry but my poor CPU already hates enough :))
> > 
> > All languages supported are build.
> > 
> > I try to avoid as much as possible bundled libraries which gives a
> > pretty fast compiling libreoffice (on a Q6600: ~2h without java, ~3h30
> > with java)
> > 
> > at this points :
> > there is (I guess) only one remaining problem :
> > which launching libreoffice it can't find it libraries, I haven't
> > decided yet wether to add LD_LIBRARY_PATH to the wrapper script or to
> > add ldconfig -m ${PREFIX}/lib/libreoffice/ure/lib and ldconfig -m
> > ${PREFIX}/lib/libreoffice/base3.3/program
> > 
> > maybe it conflicts with openoffice I haven't checked yet.
> > 
> > to test it you will need a fresh ports tree (the needed libtextcat
> > modification was committed yesterday thanks thierry@)
> > 
> > the mandatory screenshot :
> > http://people.freebsd.org/~bapt/libreoffice-3.3.0-final.png
> > 
> > I expect to be able to push it in the tree during next week (after
> > finding a good way to deal with the libraries and checked if it
> > conflicts with openoffice)
> > 
> > I would like to thanks Robert Nagy from openbsd, he has made all the
> > hard work :), he was also very helpful.
> > 
> > regards,
> > Bapt
> > ___
> > freebsd-ports@freebsd.org mailing list
> > http://lists.freebsd.org/mailman/listinfo/freebsd-ports
> > To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
> 
> I'm getting the following on a make.  Followed the instructions, and
> sdext seemed to build OK, but the make in the top-level still gets the
> same error:
> 
> sw deliver
> Module 'sw' delivered successfully. 0 files copied, 281 files unchanged
> Module 'scp2' delivered successfully. 89 files copied, 12 files unchanged
> 
> ---
> Oh dear - something failed during the build - sorry !
>   For more help with debugging build errors, please see the section in:
> http://wiki.documentfoundation.org/Development
> 
>   internal build errors:
> 
> ERROR: error 65280 occurred while making
> /usr/home/sterling/src/ports/libreoffice/work/libreoffice-build-3.3.0.4/build/libreoffice/sdext/source/presenter
> ERROR: error 65280 occurred while making
> /usr/home/sterling/src/ports/libreoffice/work/libreoffice-build-3.3.0.4/build/libreoffice/lingucomponent/source/languageguessing
> 
>  it seems you are using a threaded build, which means that the
>  actual compile error is probably hidden far above, and could be
>  inside any of these other modules:
>  lingucomponent
>  please re-run build inside each one to isolate the problem.
> ---
> 
> /usr/local/bin/bash
> cd
> /usr/home/sterling/src/ports/libreoffice/work/libreoffice-build-3.3.0.4/build/libreoffice
> source ./FreeBSDAMDEnv.Set.sh
> cd sdext
> build
> 
> when the problem is isolated and fixed exit and re-run 'make' from the
> top-level
> sometimes (sadly) it is necessary to rm -Rf unxfbsdx.pro in a module.
> gmake: *** [stamp/build] Error 1
> *** Error code 1
> 
> Stop in /usr/home/sterling/src/ports/libreoffice.
> *** Error code 1
> 
> Stop in /usr/home/sterling/src/ports/libreoffice.
> [root@libertas /usr/home/sterling/src/ports/libreoffice]# 
> 
FYI, the build of 'stock' openoffice.org-3 is broken in multijob mode
on recent CURRENT (quad-core):

~> uname -a
FreeBSD lexx.ifp.tuwien.ac.at 9.0-CURRENT FreeBSD 9.0-CURRENT #0 r217884: Wed 
Jan 26 17:00:37 CET 2011 
r...@lexx.ifp.tuwien.ac.at:/usr/obj/usr/src/sys/GENERIC  amd64

I'm working this around with this in make.conf:
.if ${.CURDIR:M*/editors/openoffice.org-*}
#WITH_SYSTEM_FREETYPE=  yes
WITHOUT_GNOME=  yes
WITHOUT_MOZILLA=yes
DISABLE_MAKE_JOBS=  1
.endif

Is LibreOffice really MAKE_JOBS_SAFE?

0.02$,
Alexey.
___
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"

[WORKAROUND] www/seamonkey2 on CURRENT

[Alexey Shuvaev]

Hello!

It seems www/seamonkey2 is broken on CURRENT for at least 1 month now [1].
Examining build log and reproducing it locally, the problem is in the
usage of libiconv in nsNativeCharsetUtils.cpp. The linker fails to
produce libxpcom_core.so although -L/usr/local/lib and -liconv
are specified [2]. Examining this further I found that nsNativeCharsetUtils.o
produced with [3] fails to link with libiconv alone too [4] (note
still unresolved libiconv references).
I'm not a compiler/linker guru and do not understand what is happening
here. As a workaroud I use the attached patch which disables the usage
of libiconv in nsNativeCharsetUtils.cpp.

My little more than 0.02$,
Alexey.


[1]: 
http://portsmon.freebsd.org/portoverview.py?category=www&portname=seamonkey2&wildcard=

[2]: c++ -I/usr/local/include/nss -I/usr/local/include/nss/nss   
-I/usr/local/include  -I/usr/local/include -fno-rtti -fno-exceptions -Wall 
-Wpointer-arith -Woverloaded-virtual -Wsynth -Wno-ctor-dtor-privacy 
-Wno-non-virtual-dtor -Wcast-align -Wno-invalid-offsetof -Wno-long-long -O2 
-pipe -fno-strict-aliasing -fno-strict-aliasing -fshort-wchar -pipe  -DNDEBUG 
-DTRIMMED -O -fPIC -shared -Wl,-z,defs -Wl,-h,libxpcom_core.so -o 
libxpcom_core.so  pldhash.o nsArrayEnumerator.o nsArrayUtils.o 
nsCategoryCache.o nsCOMPtr.o nsCOMArray.o nsCRTGlue.o nsComponentManagerUtils.o 
nsEnumeratorUtils.o nsID.o nsIInterfaceRequestorUtils.o nsINIParser.o 
nsISupportsImpl.o nsMemory.o nsWeakReference.o nsGREGlue.o 
nsVersionComparator.o nsTHashtable.o nsQuickSort.o nsVoidArray.o nsTArray.o 
nsThreadUtils.o nsTObserverArray.o nsCycleCollectionParticipant.o nsDeque.o 
nsAutoLock.o nsGenericFactory.o nsProxyRelease.o nsTextFormatter.o 
nsXPComInit.o nsXPCOMStrings.o -pthread   -L/usr/local/lib/nss 
-Wl,-rpath,/usr/local/lib/seamonkey  -lc  
-Wl,-rpath-link,/work/a/ports/www/seamonkey2/work/comm-1.9.1/mozilla/dist/bin 
-Wl,-rpath-link,/work/a/ports/www/seamonkey2/work/fake/lib  -Wl,--whole-archive 
../ds/libxpcomds_s.a ../io/libxpcomio_s.a ../components/libxpcomcomponents_s.a 
../threads/libxpcomthreads_s.a ../proxy/src/libxpcomproxy_s.a 
../base/libxpcombase_s.a ../reflect/xptcall/src/libxptcall.a 
../reflect/xptcall/src/libxptcmd.a ../reflect/xptinfo/src/libxptinfo.a 
../../dist/lib/libxpt.a ../string/src/libstring_s.a  -Wl,--no-whole-archive  
-L/usr/local/lib -lplds4 -lplc4 -lnspr4 -pthread -pthread -L/usr/local/lib 
-lgtk-x11-2.0 -latk-1.0 -lgdk-x11-2.0 -lpangocairo-1.0 -lXext -lXrender 
-lXinerama -lXi -lXrandr -lXcursor -lXcomposite -lXdamage -lgdk_pixbuf-2.0 
-lpangoft2-1.0 -lpango-1.0 -lfreetype -lfontconfig -lgio-2.0 -lXfixes 
-lgobject-2.0 -lgmodule-2.0 -lpng -lz -lm -lgthread-2.0 -lglib-2.0 -lcairo 
-lX11   -lm -pthread -lm -pthread -pthread -L/usr/local/lib -liconv
../io/libxpcomio_s.a(nsNativeCharsetUtils.o)(.text+0x32): In function 
`xp_iconv(void*, char const**, unsigned int*, char**, unsigned int*)':
: undefined reference to `libiconv'

[3]: c++ -o nsNativeCharsetUtils.o -c -I../../dist/include/system_wrappers 
-include ../../config/gcc_hidden.h -DMOZILLA_INTERNAL_API -DMOZ_SUITE=1 
-DOSTYPE=\"FreeBSD9\" -DOSARCH=FreeBSD -D_IMPL_NS_COM -I.. -I. -I. 
-I../../dist/include/string -I../../dist/include   -I../../dist/include/xpcom 
-I/usr/local/include/nspr   -I/usr/include -I/usr/local/include   -fPIC  
-I/usr/local/include/nss -I/usr/local/include/nss/nss   -I/usr/local/include  
-I/usr/local/include -fno-rtti -fno-exceptions -Wall -Wpointer-arith 
-Woverloaded-virtual -Wsynth -Wno-ctor-dtor-privacy -Wno-non-virtual-dtor 
-Wcast-align -Wno-invalid-offsetof -Wno-long-long -O2 -pipe 
-fno-strict-aliasing -fno-strict-aliasing -fshort-wchar -pipe  -DNDEBUG 
-DTRIMMED -Os -fno-strict-aliasing   -I/usr/local/include/nss 
-I/usr/local/include/nss/nss   -I/usr/local/include  -I/usr/local/include 
-DMOZILLA_CLIENT -include ../../mozilla-config.h nsNativeCharsetUtils.cpp

[4]: c++ -o aaa nsNativeCharsetUtils.o -L/usr/local/lib -liconv
/usr/lib/crt1.o(.text+0x8a): In function `_start':
: undefined reference to `main'
nsNativeCharsetUtils.o(.text+0x16): In function `xp_iconv(void*, char const**, 
unsigned long*, char**, unsigned long*)':
: undefined reference to `libiconv'
nsNativeCharsetUtils.o(.text+0x571): In function 
`nsNativeCharsetConverter::GlobalShutdown()':
: undefined reference to `PR_DestroyLock'
nsNativeCharsetUtils.o(.text+0x58e): In function 
`nsNativeCharsetConverter::GlobalShutdown()':
: undefined reference to `libiconv_close'
nsNativeCharsetUtils.o(.text+0x5ab): In function 
`nsNativeCharsetConverter::GlobalShutdown()':
: undefined reference to `libiconv_close'
nsNativeCharsetUtils.o(.text+0x5c8): In function 
`nsNativeCharsetConverter::GlobalShutdown()':
: undefined reference to `libiconv_close'
nsNativeCharsetUtils.o(.text+0x5e5): In function 
`nsNativeCharsetConverter::GlobalShutdown()':
: undefined reference to `libiconv_close'
nsNativeCharsetUtils.o(.text+0x602): In function 
`nsNativeCharsetConverter::GlobalShutdown()':
: und

Re: [WORKAROUND] www/seamonkey2 on CURRENT

[Alexey Shuvaev]

On Fri, Jan 28, 2011 at 05:37:51PM -0800, Garrett Cooper wrote:
> On Fri, Jan 28, 2011 at 3:58 PM, Alexey Shuvaev
>  wrote:
> > Hello!
> >
> > It seems www/seamonkey2 is broken on CURRENT for at least 1 month now [1].
> > Examining build log and reproducing it locally, the problem is in the
> > usage of libiconv in nsNativeCharsetUtils.cpp. The linker fails to
> > produce libxpcom_core.so although -L/usr/local/lib and -liconv
> > are specified [2]. Examining this further I found that 
> > nsNativeCharsetUtils.o
> > produced with [3] fails to link with libiconv alone too [4] (note
> > still unresolved libiconv references).
> > I'm not a compiler/linker guru and do not understand what is happening
> > here. As a workaroud I use the attached patch which disables the usage
> > of libiconv in nsNativeCharsetUtils.cpp.
> 
> ls /usr/local/lib/libiconv*so* ?
>
~> ll /usr/local/lib/libiconv*so*
lrwxr-xr-x  1 root  wheel   13 Jan 27 13:14 /usr/local/lib/libiconv.so -> 
libiconv.so.3
-r--r--r--  1 root  wheel  1078567 Jan 27 13:14 /usr/local/lib/libiconv.so.3

I'm not so lame :)

On Sat, Jan 29, 2011 at 01:39:15PM -0500, Alexander Kabaev wrote:
> On Sat, 29 Jan 2011 13:21:44 -0500
> Alexander Kabaev  wrote:
> 
> > On Sat, 29 Jan 2011 13:02:24 -0500 (EST)
> > Daniel Eischen  wrote:
> > 
> > > On Sat, 29 Jan 2011, Alexey Shuvaev wrote:
> > > 
> > > > Hello!
> > > >
> > > > It seems www/seamonkey2 is broken on CURRENT for at least 1 month
> > > > now [1]. Examining build log and reproducing it locally, the
> > > > problem is in the usage of libiconv in nsNativeCharsetUtils.cpp.
> > > > The linker fails to produce libxpcom_core.so although
> > > > -L/usr/local/lib and -liconv are specified [2]. Examining this
> > > > further I found that nsNativeCharsetUtils.o produced with [3]
> > > > fails to link with libiconv alone too [4] (note still unresolved
> > > > libiconv references). I'm not a compiler/linker guru and do not
> > > > understand what is happening here. As a workaroud I use the
> > > > attached patch which disables the usage of libiconv in
> > > > nsNativeCharsetUtils.cpp.
> > > 
> > > Yes, I had this problem also on -current.  Does seamonkey build
> > > on recent 8.x?
> > > 
> > > libxpcomio_s.a is a static library that has unresolved references
> > > to libiconv.  I guess I'd expect those references to be resolved
> > > with a later -L/usr/local/lib -liconv when building the shared
> > > library (libxpcom_core.so), but they are not.
> > > 
> > 
> > My wild guess: seamonkey tries to hide symbols that are coming from
> > different .o file (this time one from libiconv.a) and that fails with
> > our toolchain.
> > 
> > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20218
> > -- 
> > Alexander Kabaev
> 
> Follow-up to myself: Nope, the fix to said bug appears in our compiler.
> Can you make amd64 version of nsNativeCharsetUtils.
> -- 
> Alexander Kabaev
>
??? (It is already on amd64)
Well, I have fogotten to put my environment:
~> uname -a
FreeBSD lexx.ifp.tuwien.ac.at 9.0-CURRENT FreeBSD 9.0-CURRENT #0 r217884: Wed 
Jan 26 17:00:37 CET 2011 
r...@lexx.ifp.tuwien.ac.at:/usr/obj/usr/src/sys/GENERIC  amd64

And here is the winner:

On Sat, Jan 29, 2011 at 08:32:07AM +0300, Anonymous wrote:
> Alexey Shuvaev  writes:
> 
> > Hello!
> >
> > It seems www/seamonkey2 is broken on CURRENT for at least 1 month now [1].
> > Examining build log and reproducing it locally, the problem is in the
> > usage of libiconv in nsNativeCharsetUtils.cpp. The linker fails to
> > produce libxpcom_core.so although -L/usr/local/lib and -liconv
> > are specified [2]. Examining this further I found that 
> > nsNativeCharsetUtils.o
> > produced with [3] fails to link with libiconv alone too [4] (note
> > still unresolved libiconv references).
> > I'm not a compiler/linker guru and do not understand what is happening
> > here. As a workaroud I use the attached patch which disables the usage
> > of libiconv in nsNativeCharsetUtils.cpp.
> >
> [...]
> > /usr/bin/ld: aaa: hidden symbol `libiconv_open' isn't defined
> 
> /head per r215840 has working -fvisibility=hidden, i.e. config/gcc_hidden.h.
> Try following diff, it should enable patching iconv.h wrapper in bsd.gecko.mk
> 
>   @${ECHO_CMD} "#pragma GCC system_header" >> ${MOZSRC}/${subdir}/iconv.h
>   @${ECHO_CMD} "#pragma GCC visibility push(default)" >> 
>

Re: graphics/simpleviewer doesn't build on head(?)

[Alexey Shuvaev]

On Fri, Apr 08, 2011 at 07:07:02AM +, Alexey Dokuchaev wrote:
> On Fri, Apr 08, 2011 at 01:50:27AM -0500, Zhihao Yuan wrote:
> > Whatever... I don't like this image viewer.
> 
> While this viewer is far from perfect, I find that it at least works
> (contrary to gliv which dumps core on me both now and many years ago
> when I first discovered it) and performs scaling correctly (unlike pho,
> which is currently my viewer of choice).
> 
> I'd happily switch to anything at least as good as default viewer in
> windoze xp, but have not seen anything decent so far.  Maybe you can
> recommend something which is not part of Gnome or KDE?
> 
graphics/geeqie, it uses gtk but not gnome

0.02$,
Alexey.
___
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: OO 3.3.0 fails to build "moz" module on amd64 8-STABLE

[Alexey Shuvaev]

On Sun, May 08, 2011 at 10:12:35PM +0900, Maho NAKATA wrote:
> Hi
> 
> Thanks for your report. I'm aware of this issue, since my OOo build
> is broken at the same place. Sorry and I don't have a clue yet, but,
> I guess from folllowing error message, somehow moz module
> invoke make instead gmake.
> > Makefile:83: *** missing separator.  Stop.
> 
> thanks,
>  Nakata Maho
> 
> From: Lawrence Stewart 
> Subject: OO 3.3.0 fails to build "moz" module on amd64 8-STABLE
> Date: Sun, 08 May 2011 13:51:36 +1000
> 
> > Hi,
> > 
> > I've attempted to build OO 3.3.0 on two separate machines set up from
> > scratch recently and both are unable to complete the OO build.
> > 
> > My most recent attempt to build is with a ports tree cvsup'd yesterday
> > (2011-05-07) and all my installed ports were built from the ports tree
> > and are up to date. Some details about the system:
> > 
> > lstewart@lstewart-laptop> uname -a
> > FreeBSD lstewart-laptop 8.2-STABLE FreeBSD 8.2-STABLE #0 r221492: Fri
> > May 6 00:41:20 EST 2011
> > lstewart@lstewart-laptop:/usr/obj/usr/src/sys/GENERIC amd64
> > 
> > Relevant lines from /etc/make.conf:
> > 
> > .if ${.CURDIR:M*/editors/openoffice.org-3}
> > WITH_KDE4=1
> > LOCALIZED_LANG=en-GB

The workaround could be to add
WITHOUT_MOZILLA=yes
here.

> > .endif
> > 
> > I'm running KDE 4.6.2.
> > 
> > 
> > 
> > 
> > The problem stems from the "moz" build module. Here are the last few
> > lines of console output when the make dies:
> > 
HTH,
Alexey.
___
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: 2nd deprecation campaign

[Alexey Shuvaev]

On Thu, Jun 16, 2011 at 05:05:31PM +0200, Baptiste Daroussin wrote:
> 2011/6/16 Baptiste Daroussin :
> > Hi all,
> >
> > I am in the middle of a new deprecation campaign, to remove ports
> > where no more distfiles are publicly available (no other OS mirrors
> > doesn't count except if they are the upstream of course).
> >
> > Maybe some will be false positive (I will try to not have too much of them).
> >
> > Do not hesitate to manifest and undeprecate ports that would have
> > deprecated by mistake. Even better do not hesitate to propose yourself
> > to maintain them.
> >
> > Thanks,
> > Bapt
> >
> 
> The list of deprecated ports can be find there:
> http://www.freshports.org/ports-expiration-date.php
>
I think you can add java/jai-imageio to the list.
I have not managed to find the distfile even google-ing.

0.02$,
Alexey.
___
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: 2nd deprecation campaign

[Alexey Shuvaev]

On Thu, Jun 16, 2011 at 09:24:42PM +0400, Ruslan Mahmatkhanov wrote:
> 16.06.2011 20:45, Alexey Shuvaev пишет:
> >On Thu, Jun 16, 2011 at 05:05:31PM +0200, Baptiste Daroussin wrote:
> >>2011/6/16 Baptiste Daroussin:
> >>>Hi all,
> >>>
> >>>I am in the middle of a new deprecation campaign, to remove ports
> >>>where no more distfiles are publicly available (no other OS mirrors
> >>>doesn't count except if they are the upstream of course).
> >>>
> >>>Maybe some will be false positive (I will try to not have too much of 
> >>>them).
> >>>
> >>>Do not hesitate to manifest and undeprecate ports that would have
> >>>deprecated by mistake. Even better do not hesitate to propose yourself
> >>>to maintain them.
> >>>
> >>>Thanks,
> >>>Bapt
> >>>
> >>
> >>The list of deprecated ports can be find there:
> >>http://www.freshports.org/ports-expiration-date.php
> >>
> >I think you can add java/jai-imageio to the list.
> >I have not managed to find the distfile even google-ing.
> >
> >0.02$,
> >Alexey.
> 
> It should be downloaded manually from here:
> http://java.sun.com/products/java-media/jai/downloads/download-iio.html
> 
That would be too easy :)
Have you actually opened this page? For me, it is empty.
As I have stated:
> >I have not managed to find the distfile even google-ing.
So, I still think the port is quite dead.
___
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: 2nd deprecation campaign

[Alexey Shuvaev]

On Thu, Jun 16, 2011 at 10:38:34PM +0400, Ruslan Mahmatkhanov wrote:
> 16.06.2011 22:33, Alexey Shuvaev пишет:
> >On Thu, Jun 16, 2011 at 09:24:42PM +0400, Ruslan Mahmatkhanov wrote:
> >>16.06.2011 20:45, Alexey Shuvaev пишет:
> >>>On Thu, Jun 16, 2011 at 05:05:31PM +0200, Baptiste Daroussin wrote:
> >>>>2011/6/16 Baptiste Daroussin:
> >>>>>Hi all,
> >>>>>
> >>>>>I am in the middle of a new deprecation campaign, to remove ports
> >>>>>where no more distfiles are publicly available (no other OS mirrors
> >>>>>doesn't count except if they are the upstream of course).
> >>>>>
> >>>>>Maybe some will be false positive (I will try to not have too much of 
> >>>>>them).
> >>>>>
> >>>>>Do not hesitate to manifest and undeprecate ports that would have
> >>>>>deprecated by mistake. Even better do not hesitate to propose yourself
> >>>>>to maintain them.
> >>>>>
> >>>>>Thanks,
> >>>>>Bapt
> >>>>>
> >>>>
> >>>>The list of deprecated ports can be find there:
> >>>>http://www.freshports.org/ports-expiration-date.php
> >>>>
> >>>I think you can add java/jai-imageio to the list.
> >>>I have not managed to find the distfile even google-ing.
> >>>
> >>>0.02$,
> >>>Alexey.
> >>
> >>It should be downloaded manually from here:
> >>http://java.sun.com/products/java-media/jai/downloads/download-iio.html
> >>
> >That would be too easy :)
> >Have you actually opened this page? For me, it is empty.
> >As I have stated:
> >>>I have not managed to find the distfile even google-ing.
> >So, I still think the port is quite dead.
> 
> I just downloaded distfile using procedure  mentioned before w/o
> any problems and place it into /usr/ports/distfiles:
> 
> smeshariki2# make extract
> ===>  License check disabled, port has not defined LICENSE
> ===>  Extracting for jai-imageio-1.0_2
> => SHA256 Checksum OK for jai_imageio-1_0-lib-linux-i586.tar.gz.
> 
> So it looks like your local problem.
> 
Ok, examining the page source I have found the right download link.
Seems Oracle is doing something that my seamonkey does not like :(
The case is closed, java/jai_imageio is OK.
___
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: tinderbox question

[Alexey Shuvaev]

On Fri, Jun 17, 2011 at 06:24:57PM +0400, Ruslan Mahmatkhanov wrote:
> 17.06.2011 18:14, Ruslan Mahmatkhanov пишет:
> >Good day.
> >
> >How can i `inject` updated (or new) port into tinderbox Build to test it for
> >correctness? I mean i have not any troubles to build any existing port, but 
> >what
> >should i do to place updated or new port into the tinderbox portstree?
> >
> 
> Ok, it seems i got it.
> I have /usr/local/tinderbox/8.2-FreeBSD/usr/ports/ that is symlinked
> to /usr/local/tinderbox/8.2-FreeBSD/a/ports/. It's nullfs mounted fs
> and it's read-only. I realise that i can just patch
> /usr/local/tinderbox/portstrees/FreeBSD/ports to achive this goal,
> but i'm not sure if this is Right Thing or there is some another
> correct way. This procedure isn't mentioned in Tinderbox Users Guide
> (maybe it should be too obvious) so i ask there. Thanks.
> 
Well, I think it is too obvious. Or, to say better, there are too many ways
to do it. Personally, I build "official" ports in tinderbox. So, I
null-mount /usr/ports to whatever tinderbox wants it to. If I want to test
updated port I move original category/port to caterogy/port.orig and place
the new port into category/port (all under /usr/ports). After testing
I remove category/port and move original port back. This way csup/portsnap
works as usual, keeping /usr/ports up-to-date.
The big changes like marcuscom or area51 repos are handled the same way,
but globally. So "mv /usr/ports /usr/ports.orig", then copy/patch/fetch/...
the new ports tree into /usr/ports, test the things, and move back at the end.

I find this strategy optimal for occasional ports testing, if you are
continiously working with the side repos like above, adding multiple ports
trees into tinderbox is (IMHO) the way to go. This is described in
tinderbox README.

HTH,
Alexey.
___
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 is gio-fam?

[Alexey Shuvaev]

On Sun, Apr 13, 2008 at 05:59:09PM +0200, Henrik Brix Andersen wrote:
> On Tue, Apr 08, 2008 at 10:17:56PM -0400, Joe Marcus Clarke wrote:
> > gio-fam-backend is a new piece of glib which provides a wrapper around
> > FAM to allow applications to monitor file objects using a glib API.
> 
> But this is optional, right? Any reason for making gio-fam-backend an
> implicit dependency for all software, that depends on glib20?
> 
> On my systems, this means I will get gio-fam-backend installed even
> though I don't have FAM installed at all.
> 

Hello!

Just another vote against gio-fam-backend. I had have a quick look at
mailing lists archives and hadn't found any discussion about it
prior to commit. The point is thas gtk != gnome. Even more so glib != gnome.
Introducing gio-fam-backend as a dependency to glib automatically adds
it to the dependency lists of too many other (not gnome related) ports.

Personally I don't use neither gnome nor kde but I use gtk apps (gqview, gimp,
beep-media-player, mplayer, seamonkey, ...) and for now I have no FAM system
installed and I don't want any at all. I had some experience with FAM some
time ago when it was non-optional requirement for samba. Since then I don't
like FAM systems due to their 'viral' nature: many ports will auto-detect
and uncoditionally link with them. Sweeping FAM out of the system after
that is not straightforward process.

Another aspect is that FAM is not so critical for most apps (I believe).
With samba it is clear: samba wants to monitor its conf files
in order to apply changes immediately.
And what is the use of FAM for typical gui-user-application?
Any example of such app that really will not properly function without
gio-fam-backend?
(Well, I am sure there are such and gio-fam-backend
was made a dependency for glib not just for fun. But some examples
would not hurt anyone.)

Joe Marcus Clarke at Mon Mar 24 20:27:23 PDT 2008:
> Glib 2.16 (with GIO) was designed to support pluggable file monitor
> backends. Without one such backend, any libgio consumer would be
> severely handicapped. The only reason gio-fam-backend is broken out
> as a separate port is that we have one FAM provider that requires glib.
> If this was not the case, we'd just have glib20 depend on FAM.
^^^
  why glib?

> Recompiling alone is not sufficient. Ports will happily build
> without this backend, but may not run correctly if they require libgio.
> The cost of the FAM dependency
> is minimal (most GNOME apps already had this as part of gnome-vfs),
   ^^^  ^^^ ^^^
Well, gnome-vfs can really need FAM support. But then why not to add
gio-fam-backend as a dependency to gnome-vfs instead of glib?
If I understand things correctly one can install gio-fam-backend (which is
pluggable module) at any point provided glib is already installed. So moving
gio from glib to gnome-vfs will not only make gio-fam-backend more gnome
specific but also possibly remove the hack with _glib20.

> and it just makes things easier for developers not to have
> to worry about adding the gio-fam-backend dependency.

IMHO gio-fam-backend should not be implicit dependency. Otherwise why
not to install all existing non-conflicting libraries just to ease
maintainer's life :->
FWIW x11-toolkits/gtkdatabox2 (PR 116120) do not need gio-fam-backend.

Just my 0.02$,
Alexey.
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: what is gio-fam?

[Alexey Shuvaev]

On Mon, Apr 14, 2008 at 10:31:18AM -0500, Jeremy Messenger wrote:
> On Mon, 14 Apr 2008 10:09:06 -0500, Jeremy Messenger <[EMAIL PROTECTED]> 
> wrote:
>
>> On Mon, 14 Apr 2008 03:50:09 -0500, Alexey Shuvaev 
>> <[EMAIL PROTECTED]> wrote:
>>
>> 
>>> IMHO gio-fam-backend should not be implicit dependency. Otherwise why
>>> not to install all existing non-conflicting libraries just to ease
>>> maintainer's life :->
>>> FWIW x11-toolkits/gtkdatabox2 (PR 116120) do not need gio-fam-backend.
>>
>> Well, all ports should depend on gio-fam-backend. The gio is included and 
>> part of glib20. marcus had to split gio out of glib20 package to avoid 
>> circle dependency of glib20 -> gamin (FAM replacement) -> glib20. If 
>> marcus doesn't split and you guys will have that gio library anyway.

Thanks, somewhat much clearer now. I had some feeling that gio-fam-backend is
freebsd specific.
How many chances are there to account for existence of gamin upstream?
(So to avoid glib -> gamin -> glib circular dependency)

>
> Uh, I should have check in glib20 and gio-fam-backend before I made that 
> comment. I thought that gio (libgio-2.0.so) is in gio-fam-backend, but not 
> it's in glib20. The gio-fam-backend only installs libgiofam.so and FAM 
> support is option in glib configure. I don't think it will be easy to make 
> optional (maybe I am wrong) with that split. Remove gio-fam-backend 
> dependency is going to hurt some users if they want some missing fuction(s) 
> of it.
>

So configure option is not enough. Does separating gio-fam-backend by
original developers solve the problem better?

Alexey.
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: FBSD 7, Gnome2-lite port broken

[Alexey Shuvaev]

On Sun, Apr 20, 2008 at 05:16:43AM +1000, Da Rock wrote:
> I've tried checking as far as my knowledge will allow the reason for
> this error, but its got me beat. I was installing the above port, and
> the config screen came up for one of its dependencies surrounding
> ghostscript I believe where it said "don't be stingy on the options
> selected as another port might need it later". So I checked them all as
> I probably will need them all at some point in the future. Also to note
> here there was a majority already selected to begin with.
> 
> Unfortunately, I can't find that screen again to uncheck some options,
> and I think its ghostscript-gpl which is failing. It errors on not
> finding vga.h and lvga.h files. So I installed all src's from
> sysinstall, but NG.
> 

It seems that you have checked lvga256 and vgalib options in
ghostscript-gpl configuration dialog. This dialog is not the
standart port's OPTIONS dialog and it doesn't remember the options you
have choosen between builds. So, to fix the build:

cd /usr/ports/print/ghostscript-gpl
make clean
make install

Once you are in this dialog again, just go on with the defaults.

BTW, can someone more experienced comment on reasons to have non-standard
configure script? Possibly related: are there any non-trivial reasons
to have ghostscript (rather significant for many other ports) maintained
by ports@ ? Or are there just no volunteers?

Alexey.
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Gnome reference framework bsd.gnome-reference.mk VS [NO]PORTDOCS

[Alexey Shuvaev]

Hello list!

I am working on update to x11-toolkits/gtkdatabox2 and it has recently got
an html reference (built using gtk-doc). The gtkdatabox2 is a rather
rarely used port and its reference consists of app. 25 files (for now).
What is better,
- to create separate gtkdatabox-reference port, or
- to intstall documentation from the existing port, under the
  control of NOPORTDOCS variable?

The second question is about bsd.gnome-reference.mk framework discussed
recently[1]. Althoug gtkdatabox is not an official part of gnome,
it uses the same structure and therefore could be handled in the same way
as other "official" gnome components. Are there any reasons to use one of:
- devel/glib20-reference/bsd.gnome-reference.mk framework
- handling docs on one's own?

Thanks,
Alexey.

1. http://lists.freebsd.org/pipermail/freebsd-ports/2008-May/048645.html
   http://lists.freebsd.org/pipermail/freebsd-ports/2008-May/048647.html
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: Building enlightenment-devel fails

[Alexey Shuvaev]

On Thu, May 29, 2008 at 07:52:18AM +0200, [EMAIL PROTECTED] wrote:
> Hi All,
>
> I'm running a FreeBSD 6.3-PRERELEASE and after a portupgrade building  
> enlightenment-devel fails with following error.
>
> --snip--
> libtool: link: cannot find the library `/usr/local/lib/libecore_dbus.la'  
> or unhandled argument `/usr/local/lib/libecore_dbus.la'
> gmake[3]: *** [enlightenment] Error 1
> --snip--
>
> I googled this problem an found this
>
> --snip--
> This removes the DBUS check for ecore. Since ecore does not appear to  
> link against any other DBUS port, it is not necessary. In addition  
> enlightenment-devel will not build if ecore does not have DBUS enabled  
> due to a dependency on Ecore_DBus.h in e.h. A better way is welcome.
> --snip--
>
> The attached patch doesn't solve the problem as I dunno know which  
> Makefile to patch. "/usr/ports/x11/ecore/Makefile" doesn't exist on my  
> machine, only "/usr/ports/x11/ecore-desktop".
>
> This was not the first problem with the upgrade. As ports/UPDATING said  
> on 20080312 ecore and evas have been splitted. After uninstalling and  
> clean reinstalling all e-related packages now problems with  
> libcore_dbus.la occure.
>
> Please excuse my probably stupid questions here, but I'm relatively new  
> to FreeBSD and try to fix most of my problems by myself. But in here im  
> stuck.
>
> Any help will be highly appreciated.
>
Could you check that you have up-to-date and consistent ports?
Or, otherwise, is it possible that there are some stale files laying
around in your system?
I have just installed x11-wm/enlightenment-devel without any problems
and it runs too. I have no libecore_dbus.* library. The dbus binding is
in devel/e_dbus now and installed as libedbus.*.
BTW, ecore is in devel/ecore and friends (deve/ecore-*), if it matters.
My system (amd64 FreeBSD-CURRENT) was updated yesterday (both base and ports):
-rw-r--r--  1 root  wheel  16507539 May 28 12:16 /usr/ports/INDEX-8

I would suggest removing ALL enlightenment-related ports first and starting
from scratch then. To locate which package has installed libecore_dbus,
you can run, for example:
~> grep -R libecore_dbus /var/db/pkg/

On my system this command produces no output, but:
~> grep -R libedbus /var/db/pkg/
/var/db/pkg/e_dbus-20080223/+CONTENTS:lib/libedbus.a
/var/db/pkg/e_dbus-20080223/+CONTENTS:lib/libedbus.la
/var/db/pkg/e_dbus-20080223/+CONTENTS:lib/libedbus.so
/var/db/pkg/e_dbus-20080223/+CONTENTS:lib/libedbus.so.1

shows that libedbus is inside e_dbus-20080223 package.

Hope this helps,
Alexey.
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: Issues with portmaster

[Alexey Shuvaev]

Hello!

On Mon, Jun 23, 2008 at 12:49:22AM -0700, Doug Barton wrote:
> Alex Dupre wrote:
>> Doug Barton ha scritto:
>>> Portmaster uses CONFLICTS to avoid this issue.
>>
>> I can't see how CONFLICTS could solve this issue: we can install all 
>> the JDKs together without problems
>
It seems I don't understand something here. Can someone explain why
jdk ports need to set BUILD_DEPENDS on diablo-jdk15 unconditionally?
Why it is not possible to define it inside 'if !defined(BOOTSTRAPJDKDIR)'?
(See attached patch.)

Just curious,
Alexey.
--- Makefile.orig   2008-06-23 10:33:59.0 +0200
+++ Makefile2008-06-23 10:34:36.0 +0200
@@ -108,9 +108,8 @@
 # if no valid jdk found, set dependency
 .if !defined(BOOTSTRAPJDKDIR)
 BOOTSTRAPJDKDIR?=  ${LOCALBASE}/diablo-jdk1.5.0
-.endif
-
 BUILD_DEPENDS+=
${BOOTSTRAPJDKDIR}/bin/javac:${PORTSDIR}/java/diablo-jdk15
+.endif
 
 .if defined(WITHOUT_WEB)
 MAKE_ENV+= DONT_BUILD_DEPLOY="YES"
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: Issues with portmaster

[Alexey Shuvaev]

On Mon, Jun 23, 2008 at 10:57:41AM +0200, Alex Dupre wrote:
> Alexey Shuvaev ha scritto:
>> It seems I don't understand something here. Can someone explain why
>> jdk ports need to set BUILD_DEPENDS on diablo-jdk15 unconditionally?
>
> (nearly) every JDK port needs an already usable/installed JDK to  
> bootstrap the compilation. This is the reason of the BUILD_DEPENDS on  
> javac that you cannot remove. But the port providing the javac binary  
 ^
> could not be the diablo-jdk.
>
Mmmm... why not???
In a nutshell, from the user point of view the reason to set BUILD_DEPENDS is
to ensure that some port (java here) is installed prior to build.
However, if the port checks against installed java in a more complicated manner
than BUILD_DEPENDS mechanism can provide, I see no reason to set
BUILD_DEPENDS to something just for its own sake.
And from the build cluster point of view, the port will be built in a clean
environment, so port will not detect any installed java and will set
BUILD_DEPENDS *conditionally* (.if !defiend(BOOTSTRAPJDKDIR)).

I have a feeling that the way BUILD_DEPENDS is set now is overkill, and
one can put it under .if !defined(BOOTSTRAPJDKDIR) without any functional
change. Of course, the Right Way To Do This would be to set the whole
correct BUILD_DEPENDS line based on detected java. Maybe this is even not
so complicated. Or I miss something?

Just 0.02$,
Alexey.
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: Issues with portmaster

[Alexey Shuvaev]

On Mon, Jun 23, 2008 at 12:56:40PM -0700, Greg Lewis wrote:
> On Mon, Jun 23, 2008 at 12:28:08PM -0700, Doug Barton wrote:
> > Alexey Shuvaev wrote:
> > >On Mon, Jun 23, 2008 at 10:57:41AM +0200, Alex Dupre wrote:
> > >>Alexey Shuvaev ha scritto:
> > >>>It seems I don't understand something here. Can someone explain why
> > >>>jdk ports need to set BUILD_DEPENDS on diablo-jdk15 unconditionally?
> > >>(nearly) every JDK port needs an already usable/installed JDK to  
> > >>bootstrap the compilation. This is the reason of the BUILD_DEPENDS on  
> > >>javac that you cannot remove. But the port providing the javac binary  
> > > ^
> > >>could not be the diablo-jdk.
> > >>
> > >Mmmm... why not???
> > >In a nutshell, from the user point of view the reason to set BUILD_DEPENDS 
> > >is
> > >to ensure that some port (java here) is installed prior to build.
> > >However, if the port checks against installed java in a more complicated 
> > >manner
> > >than BUILD_DEPENDS mechanism can provide, I see no reason to set
> > >BUILD_DEPENDS to something just for its own sake.
> > >And from the build cluster point of view, the port will be built in a clean
> > >environment, so port will not detect any installed java and will set
> > >BUILD_DEPENDS *conditionally* (.if !defiend(BOOTSTRAPJDKDIR)).
> > >
> > >I have a feeling that the way BUILD_DEPENDS is set now is overkill, and
> > >one can put it under .if !defined(BOOTSTRAPJDKDIR) without any functional
> > >change. Of course, the Right Way To Do This would be to set the whole
> > >correct BUILD_DEPENDS line based on detected java. Maybe this is even not
> > >so complicated. Or I miss something?
> > 
> > Thanks for the discussion on this. Since I don't use java I'm relying 
> > an the users here. Hopefully glewis can weigh in at some point.
> 
> Its probably not that complicated for the port to stop "cheating" on the
> way it sets up BUILD_DEPENDS.  At the moment it knows the potential
> bootstrap JDKs install paths, but it doesn't know where they live in
> ports, so it cheats and sets the requirement to the detected javac but
> then hardcodes the dependency as Diablo.  This works from a ports point
> of view in that the dependency isn't installed if the requirement is
> found, but it obviously confuses portsmaster.
> 
The translation table from install paths to ports is simple:
diablo-jdk1.5.0 -> java/diablo-jdk15
jdk1.5.0 -> java/jdk15
jdk1.6.0 -> java/jdk16
jdk1.4.2 -> java/jdk14
linux-sun-jdk1.5.0 -> java/linux-sun-jdk15
linux-sun-jdk1.6.0 -> java/linux-sun-jdk16
linux-sun-jdk1.4.2 -> java/linux-sun-jdk14

I have even thought about something like this:

# if no valid jdk found, set dependency
.if !defined(BOOTSTRAPJDKDIR)
BOOTSTRAPJDKDIR?=   ${LOCALBASE}/diablo-jdk1.5.0
BUILD_DEPENDS+= ${BOOTSTRAPJDKDIR}/bin/javac:${PORTSDIR}/java/diablo-jdk15
.else
# Do some black (Makefile/shell) magic to construct the valid BUILD_DEPENDS
# line from the detected BOOTSTRAPJDKDIR and the table above
.endif

but then I remembered the typical situation where I am. Normally,
I bootstrap java/jdk15 with already installed (old) jdk1.5.0.
But in this case the logic above would set BUILD_DEPENDS to itself!
I don't think it is good...

> >From a partial reading of the email thread, it looks like the simplest
> thing to do is to just not set BUILD_DEPENDS if it finds an appropriately
> installed JDK.  That way it will only set it if it can't find a bootstrap
> JDK and it needs one installed.
> 
This is achieved with attached 3-line patch. I have roughly tested it
with "make -V BUILD_DEPENDS". It produces reasonable results on a system
with jdk1.5.0 (no dependency on diablo) and on a system without any
java at all (there is a dependency on diablo).It is trivial, but nevertheless,
any real battlefield testing (upgrading real systems,
tinderbox package building)? Review from someone experienced?

Alexey.
--- Makefile.orig   2008-06-23 10:33:59.0 +0200
+++ Makefile2008-06-23 10:34:36.0 +0200
@@ -108,9 +108,8 @@
 # if no valid jdk found, set dependency
 .if !defined(BOOTSTRAPJDKDIR)
 BOOTSTRAPJDKDIR?=  ${LOCALBASE}/diablo-jdk1.5.0
-.endif
-
 BUILD_DEPENDS+=
${BOOTSTRAPJDKDIR}/bin/javac:${PORTSDIR}/java/diablo-jdk15
+.endif
 
 .if defined(WITHOUT_WEB)
 MAKE_ENV+= DONT_BUILD_DEPLOY="YES"
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: 8-current/kde3 stty defaults incorrect under konsole

[Alexey Shuvaev]

On Wed, Jun 25, 2008 at 04:51:02PM +0200, Alexey Shuvaev wrote:
> Hello!
> 
> On Wed, Jun 25, 2008 at 07:10:14AM -0700, Mark Atkinson wrote:
> > Hi,
> > 
> > Is anyone else running freebsd-current with kde3 (and has rebuilt both
> > recently)?   I can only suspect this is related to recent changes in
> > current in prep for mpsafe tty, but in konsole, the defaults turn out to be
> > this (note the missing '^' on intr and quit):
> > 
> > cchars: discard = ^O; dsusp = ^Y; eof = ^D; eol = ;
> > eol2 = ; erase = ^?; erase2 = ^H; intr = C; kill = ^U;
> > lnext = ^V; min = 1; quit = \; reprint = ^R; start = ^Q;
> > status = ^T; stop = ^S; susp = ^Z; time = 0; werase = ^W;
> > 
> > xterm and the freebsd console are fine.
> > 
> I have noticed that cursor key (right, forward direction) does not work
> as expected. By pressing it cancels the current command line and prompts with
> the empty one again.
> 
> [snip]
> On Wed, Jun 25, 2008 at 04:34:28PM +0200, Ed Schouten wrote:
> > Blegh. I always hate those applications using non-documented extensions
> > in a non-standard way. ;-)
> >
> > Anyway, could you store this patch in the files/ dir of the kdelibs3
> > port and see what happens? Thanks! :)
> >
> > %%%
> > --- kdecore/kpty.cpp
> > +++ kdecore/kpty.cpp
> > @@ -128,9 +128,8 @@
> >  #include// locate
> >
> >  // not defined on HP-UX for example
> > -#ifndef CTRL
> > -# define CTRL(x) ((x) & 037)
> > -#endif
> > +#undef CTRL
> > +#define CTRL(x) ((x) & 037)
> >
> >  #define TTY_GROUP "tty"
> >
> > %%%
> >
> Thanks, I will try this but it takes a while, it is 800MHz Pentium3 :-)
> 
> Alexey.
>
I have rebuilt kdelibs with this patch and now both wrong stty -a values
and issues with cursor keys are gone. Thanks!

Any chance to have this patch in the ports tree?

Alexey.
--- kdecore/kpty.cpp
+++ kdecore/kpty.cpp
@@ -128,9 +128,8 @@
 #include  // locate
 
 // not defined on HP-UX for example
-#ifndef CTRL
-# define CTRL(x) ((x) & 037)
-#endif
+#undef CTRL
+#define CTRL(x) ((x) & 037)
 
 #define TTY_GROUP "tty"
 
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

[x11-toolkits/gtkdatabox[2]]: Kind request to commit an update

[Alexey Shuvaev]

Hello dear commiters :->

There is a
http://www.freebsd.org/cgi/query-pr.cgi?pr=ports/123937
laying around for about 1.5 month. It is just a little bit non-trivial
update to the port (see the notes in the PR).
As for the maintainership claim one can see the beginning of the history at
http://www.freebsd.org/cgi/query-pr.cgi?pr=ports/116120
I belive one should not wait another maintainer timeout?
It would be nice if someone can commit this somewhere around weekend so I can
finish the trilogy x11-toolkits/{slgtk,gtkdatabox,slgtkdatabox}.
Here, the latest version of slgtkdatabox (not in the tree) is built
upon the latest version of gtkdatabox (not updated yet).

Thanks in advance,
Alexey.
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: sabnzbd

[Alexey Shuvaev]

On Sat, Aug 16, 2008 at 08:29:34PM +0200, Jos Chrispijn wrote:
> Just installed from /usr/ports/news/sabnzbd; found out that the port  
> that is 'live'installed is version 0.2.5_1 instead of 0.4.2
> Is this a port that is not maintained anymore or am I just stupid asking  
> this?
>
You should probably want news/sabnzbdplus. It is at 0.4.0 in the ports now.
If you want 0.4.2 you can contact maintainer off-list for the updating plans.

Alexey.
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: ruby18 won't upgrade - Patch error

[Alexey Shuvaev]

On Sun, Aug 17, 2008 at 09:45:38AM -0400, Eduardo Cerejo wrote:
> 
> ===>  Patching for ruby-1.8.6.287,1
> ===>  Applying FreeBSD patches for ruby-1.8.6.287,1
> Ignoring previously applied (or reversed) patch.
> 3 out of 3 hunks ignored--saving rejects to lib/cgi.rb.rej
> => Patch patch-lib_cgi.rb failed to apply cleanly.
>
This was fixed 8 hours after initial commit. Update your ports tree and
try again.
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: www/commonist BROKEN: No ${JAR} even if USE_JAVA=1.5+ defined?

[Alexey Shuvaev]

On Sun, Aug 17, 2008 at 04:41:37PM +0200, Marcin Cieslak wrote:
>
> One of my ports breaks badly on the tinderbox:
> The error message is:
>
> ===>   commonist-0.3.28 depends on executable: unzip - found
> (cd /work/a/ports/www/commonist/work/commonist-0.3.28 &&  
> /usr/local/diablo-jdk1.5.0/bin/jar xf lib/lib-util-src.jar src)
> /usr/local/diablo-jdk1.5.0/bin/jar: not found
>
> The port defines
>
> USE_JAVA=1.5+
>
> and uses ${JAR} to get the proper location of the tool.
>
> What's wrong?
>
Not 100% sure, you should define JAVA_EXTRACT in your port also:

JAVA_EXTRACT=   yes

Look at ports/Mk/bsd.java.mk and some ports too
(cd /usr/ports ; grep -R JAVA_EXTRACT):
finance/venice
games/robocode
games/sbfol
java/eclipse-pmd
print/arobatviewer
...

Seems to be not well documented and rarely used variable.

Just my 0.02$,
Alexey.
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: Ruby port broken? SOLVED

[Alexey Shuvaev]

On Sun, Aug 17, 2008 at 08:42:52AM -0600, hideo wrote:
> > Apparently, whatever worked for you hasn't done me any good:
> > 
> >   ===>  Patching for ruby-1.8.6.287,1
> >   ===>  Applying FreeBSD patches for ruby-1.8.6.287,1
> >   Ignoring previously applied (or reversed) patch.
> >   3 out of 3 hunks ignored--saving rejects to lib/cgi.rb.rej
> >   => Patch patch-lib_cgi.rb failed to apply cleanly.
> >   => Patch(es) patch-ext_tk_tkutil_extconf.rb patch-io.c applied cleanly.
> >   *** Error code 1
> > 
> >   Stop in /usr/ports/lang/ruby18.
> >   *** Error code 1
> > 
> >   Stop in /usr/ports/lang/ruby18.
> >   ** Command failed [exit code 1]: /usr/bin/script -qa
> >   /tmp/portupgrade.20719.0 env UPGRADE_TOOL=portupgrade
> >   UPGRADE_PORT=ruby-1.8.6.111_5,1 UPGRADE_PORT_VER=1.8.6.111_5,1 make
> >   ** Fix the problem and try again.
> 
> Just update ports at around 8:30 MDT and it's still broken on stable.
> 
You can manually remove offending files in ports/lang/ruby18/files:
patch-lib_cgi.rb
patch-lib_ipaddr.rb
patch-lib_optparse.rb
patch-lib_resolv-replace.rb
patch-lib_resolv.rb
patch-lib_webrick_httputils.rb

Alexey.
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: Can't seem to build mplayer on up to date (today) current i386

[Alexey Shuvaev]

On Sun, Aug 17, 2008 at 10:21:30AM -0500, eculp wrote:
> I've been trying to build multimedia/mplayer for a couple of days now  
> and end with the following error:
>
> In file included from ../libavutil/bswap.h:30,
>  from ../mpbswap.h:4,
>  from ao_pcm.c:8:
> ../libavutil/common.h:98: error: redefinition of 'av_log2'
> /usr/local/include/libavutil/common.h:124: error: previous definition of 
> 'av_log2' was here
>[snip]
> gmake[1]: *** [ao_pcm.o] Error 1
> gmake[1]: Leaving directory  
> `/usr/ports/multimedia/mplayer/work/MPlayer-1.0rc2/libao2'
> gmake: *** [libao2/libao2.a] Error 2
>
> Any suggestions appreciated. Thanks.
>
http://lists.freebsd.org/pipermail/freebsd-multimedia/2008-July/008856.html
already pointed out on this list earlier by Mezz.
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: Possible copyright problems in some games [Fwd: Removal of illegal packages]

[Alexey Shuvaev]

On Mon, Aug 18, 2008 at 02:11:35PM +0400, Dmitry Marakasov wrote:
> - Forwarded message from Stephen Sweeney <[EMAIL PROTECTED]> -
> 
> Date: Sat, 16 Aug 2008 19:02:15 +0100
> From: Stephen Sweeney <[EMAIL PROTECTED]>
> To: [EMAIL PROTECTED], [EMAIL PROTECTED],
>   [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED],
>   [EMAIL PROTECTED], [EMAIL PROTECTED],
>   "[EMAIL PROTECTED]" <[EMAIL PROTECTED]>
> Subject: Removal of illegal packages
> 
> Hi there,
> 
> It is with much regret that I have to ask you to remove the following
> packages from your repositories,
> 
> blobwars (Blob Wars : Metal Blob Solid)
> starfighter (Project: Starfighter)
> blobAndConquer (Blob Wars : Blob And Conquer)
> viruskiller (Virus Killer)
> 
> It has been brought to my attention by a Happy Penguin regular, leileilol,
> that the packages contain resources that are non-free and, in some cases,
> ripped from other games and still copyrighted. They should all be removed
> immediately to avoid any legal issues.
> 
> It would be within the interests of all if we could get these games removed
> ASAP so that your distributions are not affected by any legal issues.
> 
> Please could you forward this email along to any one else you may know who
> is a package maintainer.
> 
> Thank you,
> 
> Stephen Sweeney
> 
>From http://www.parallelrealities.co.uk/virusKiller.php:

License

Source code is distributed under the GNU General Public License. Resources are 
Non Free. This game should not be added to Linux distributions or 
respositories. 

>From porters-handbook:

RESTRICTED should be set to a string describing the reason why the port cannot 
be redistributed. Typically, this indicates that the port contains proprietary 
software and that the user will need to manually download the DISTFILES, 
possibly after registering for the software or agreeing to accept the terms of 
an EULA.

I think RESTRICTED is quite enough.

Alexey.
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: amule 2 port - trying an upgrade

[Alexey Shuvaev]

On Mon, Aug 18, 2008 at 10:31:21PM +0200, Torfinn Ingolfsen wrote:
> 
> As a first try, I have come up with the following diff[1]. The port
> compiles fine, but the installation step fails, because most of the
> man pages doesn't get installed. Here is the relevant part of the
> 'make install':
> ===>   Compressing manual pages for aMule-2.2.2_1
> gzip: can't stat: /usr/local/man/man1/cas.1: No such file or directory
> [snip]
> gzip: can't stat: /usr/local/man/hu/man1/amule.1: No such file or directory
> ===>   Registering installation for aMule-2.2.2_1
> 
> Any hnts on how I fix this?
> I have read the man pages[2] chapter in the Porter's Handbook, but it
> didn't help me. AFAICT, the Makefile.man should work as is.
> 
Port system does not install man pages for you. This should be done
by the build scripts in the distribution tarball. You should probably look at
various Makefiles* and/or configure script.

FYI, the port failed to patch with your diff:

===>  Applying FreeBSD patches for aMule-2.2.2_1
1 out of 2 hunks failed--saving rejects to src/amuleDlg.cpp.rej
=> Patch patch-amuleDlg.cpp failed to apply cleanly.
*** Error code 1

Alexey.
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

unBREAK cad/brlcad on CURRENT.

[Alexey Shuvaev]

Hello list!

After recent commit of MPSAFE TTY layer cad/brlcad builds
and runs successfully on CURRENT:

> uname -a
FreeBSD wep4017.physik.uni-wuerzburg.de 8.0-CURRENT FreeBSD 8.0-CURRENT #0: Wed 
Aug 20 17:15:25 CEST 2008 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/GENERIC  
amd64

However, it is marken as BROKEN= does not compile.
The relevant PR, when it was marked BROKEN is
http://www.freebsd.org/cgi/query-pr.cgi?pr=ports/124733
The reason for this was not the changes in TTY layer (namely, in termios.h),
but rather some white space problem on tinderbox. From brlcad-7.12.4.log:

[snip]
configure: configuring in misc/enigma
[snip]
configure: loading cache ../../config.cache.freebsd8.0.regis.goodking.ca
configure: error: `CFLAGS' has changed since the previous run:
configure:   former value:  -O2 -pipe  -fno-strict-aliasing
configure:   current value: -O2 -pipe -fno-strict-aliasing
configure: error: changes in the environment can compromise the build
configure: error: run `make distclean' and/or `rm 
../../config.cache.freebsd8.0.regis.goodking.ca' and start over
configure: error: /bin/sh './configure' failed for misc/enigma
[snip]

I cannot reproduce this error during normal build.

Could someone familiar with tinderbox environment unBREAK the port?
Should I file a PR?

Thanks,
Alexey.
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

devel/libtool15 unconditionally hardcodes autodetected textproc/gsed

[Alexey Shuvaev]

Hello all!

While the ports are in freeze just want to point to the problem I have
encountered. Not sure if this is a critical bug, just a bug or not
a bug at all (so, no PR yet).

If one installs/rebuilds devel/libtool15 while textproc/gsed is
installed, libtool autodetects it and hardcodes gsed in itself.
If later one removes gsed (and nothing prevents him from doing this),
libtool is left in a broken state. FWIW, textproc/gsed is a BUILD_DEPENDS
of some ports.

Ideally, I think, one should hack libtool's configure framework to
not detect gsed at all. Sorry, no patch here. Attached is the diff
between unpacked libtool packages, one built with system sed and
one - with gsed.

Alexey.
diff -ruN libtool-good/+CONTENTS libtool-bad/+CONTENTS
--- libtool-good/+CONTENTS  2008-09-08 10:29:34.0 +0200
+++ libtool-bad/+CONTENTS   2008-09-08 20:50:41.0 +0200
@@ -4,7 +4,7 @@
 @cwd /usr/local
 @comment $FreeBSD: ports/devel/libtool15/pkg-plist,v 1.13 2006/02/23 10:36:03 
ade Exp $
 bin/libtool
[EMAIL PROTECTED] MD5:d82d18482a1bdb6a66b4a88e5f6af477
[EMAIL PROTECTED] MD5:553962c30b1587c8cd17cd90a252a8f2
 bin/libtoolize
 @comment MD5:efbc69981145a9fac91f0f875ba11c3e
 share/aclocal/libtool.m4
diff -ruN libtool-good/bin/libtool libtool-bad/bin/libtool
--- libtool-good/bin/libtool2008-09-08 10:29:29.0 +0200
+++ libtool-bad/bin/libtool 2008-09-08 20:50:36.0 +0200
@@ -30,10 +30,10 @@
 # the same distribution terms that you use for the rest of that program.
 
 # A sed program that does not truncate output.
-SED="/usr/bin/sed"
+SED="/usr/local/bin/gsed"
 
 # Sed that helps us avoid accidentally triggering echo(1) options like -n.
-Xsed="/usr/bin/sed -e 1s/^X//"
+Xsed="/usr/local/bin/gsed -e 1s/^X//"
 
 # The HP-UX ksh and POSIX shell print the target directory to stdout
 # if CDPATH is set.
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: devel/libtool15 unconditionally hardcodes autodetected textproc/gsed

[Alexey Shuvaev]

On Tue, Sep 09, 2008 at 06:11:44PM +0400, Dmitry Marakasov wrote:
> * Peter Pentchev ([EMAIL PROTECTED]) wrote:
> 
> > > This is definitely a bug, so better send-pr for this issue not to be
> > > lost while we're in freeze.
> > What I mean is the following scenario:
> > - libfoo uses libtool for its build
> > - libfoo depends on libbar which depends on GNU sed
> > - during libfoo's build, libbar is built, thus gsed is installed
> > - during libfoo's build, libtool detects gsed installed and "remembers" it
> No, as  libtool package will be used, which doesn't
> use gsed for sure.
> > - in libfoo's binary package, there is a shell script that uses "gsed",
> >   because libtool "knows" gsed is present on the system
> > - an unsuspecting user installs the libfoo binary package without previously
> >   building libbar
> > - the unsuspecting user gets a shell script that tries to run "gsed" and
> >   fails.
> ...
> > If libtool may put "gsed" into libfoo's binary package, this should be
> > fixed before the freeze.  If libtool only uses "gsed" during libfoo's
> > build, then it is not a critical problem.
> Neither seem to be the case for package building.
> 
> > Of course, if Dmitry is more familiar with libtool than I am, and he
> I am most likely not,
> > knows that libtool does not leave any such files, then I've just wasted
> > everybody's time with unneeded idle speculation, for which I apologize :)
> but my vision is that the problem will only show itself if you build
> libtool with gsed installed and then deinstall gsed. Thus, you'll
> end up with defunct libtool and all ports which have
> USE_AUTOTOOLS=libtool:15 will fail to build.
> 
I have encountered this with x11/libX11, FWIW.
The error was 'gsed not found' or something similar.

> Since this doesn't affect package builds, I don't this this is serious
> enough to fix duing freeze. But still to be fixed :)
> 
Yes, but the releases will be bundled with a 'broken' devel/libtool15 port.
Many [new] users could be using this port tree for a rather long time...

I have filed PR with the proposed patch:
http://www.freebsd.org/cgi/query-pr.cgi?pr=127256

Alexey.
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: FreeBSD Port: clamav-0.94_1

[Alexey Shuvaev]

On Fri, Sep 19, 2008 at 12:40:35PM +0800, Snopy Land wrote:
> Hi,
> 
> My server version is freebsd6.2 amd64. I have installed clamav to scan my
  ^^^
According to http://www.freebsd.org/security/ it is not supported any more.
Consider upgrading your base system (as opposed to ports) as well.

> incoming mail. Everything works smoothly for several years.
> Recently, I need to upgrade clamav version from 0.92 to 0.94 (latest
> version).
> 

The procedure used (from the original mail):

> 1. run "make deinstall" to deinstall the clamav version of 0.92
> 2. Modify /usr/ports-supfile  (to make sure security port can be download
> from a correct default host)
> *default host=ftp.tw.freebsd.org
> ports-security   <--- remark ports-all, and enable the ports-security only
  ^^
  That is not a good idea, I think.

> 3. cd /usr ; run "cvsup -g -L 2 ports-supfile
> 4. check /usr/port/security/clamav port is updated
> 5. cd /usr/port/security/clamav
> 6. run "make install clean"

> There is no error message found in the whole process, however, I cannot find
> the file of "clamd", "clamscan" & "freshclam".
> The previous version of these file can be found in /usr/local/sbin and
> /usr/local/bin
> 
> After redo the upgrade process, I find there are some files under
> /usr/local/bin and /usr/local/sbin but the file name is differenet.
> 
> ls -ltr /usr/local/bin
> -r-xr-xr-x  1 root  wheel80624 Sep 19 11:07
> amd64-portbld-freebsd6.2-sigtool
> -r-xr-xr-x  1 root  wheel87944 Sep 19 11:07
> amd64-portbld-freebsd6.2-freshclam
> -r-xr-xr-x  1 root  wheel51968 Sep 19 11:07
> amd64-portbld-freebsd6.2-clamscan
> -r-xr-xr-x  1 root  wheel52592 Sep 19 11:07
> amd64-portbld-freebsd6.2-clamdscan
> -r-xr-xr-x  1 root  wheel28272 Sep 19 11:07
> amd64-portbld-freebsd6.2-clamconf
> -r-xr-xr-x  1 root  wheel 1103 Sep 19 11:07
> amd64-portbld-freebsd6.2-clamav-config
> 
> ls -ltr /usr/local/sbin
> -r-xr-xr-x  1 root  wheel67536 Sep 19 11:07
> amd64-portbld-freebsd6.2-clamd
> Are these files are the same as the file of "clamd", "freshclam" and
> "clamscan". If yes, can I create symbolic link for these file so that I can
> keep my old setting? (i.e run "/usr/local/sbin/clamd -c
> /usr/local/etc/clamd.conf",   and run "/usr/local/bin/freshclam --quiet" in
> the cronjob). How many configuration files location should I change ?
> 
Yes, these files are the same. You have run into this problem because you
have not updated the whole tree, namely ports/Mk* directory. There was
a change which is responsible for fixing these ugly names.
FWIW, from the /usr/share/examples/cvsup/ports-supfile:

# These are the individual collections that make up "ports-all".  If you
# use these, be sure to comment out "ports-all" above.
#
# Be sure to ALWAYS cvsup the ports-base collection if you use any of the
# other individual collections below. ports-base is a mandatory collection
# for the ports collection, and your ports may not build correctly if it
# is not kept up to date.
#ports-base

Good luck!
Alexey.
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: teTeX/TeXLive: powerdot still missing ...

[Alexey Shuvaev]

On Thu, Sep 18, 2008 at 02:03:01PM +, O. Hartmann wrote:
> Still using teTeX, but as we all know, development has been canceld by  
> Thomas Esser. I'm looking for a working 'powerdot' which is part of  
> TeXLive now, but there is no TeXLive-port available for FreeBSD.  
> Searching for that matter brings up some informations released a year  
> ago and I'm wondering about the fact that there is no support for 
> FreeBSD.
> Is there a workaround or 'master plan' how to bring TeXLive to a FreeBSD  
> bx in a clean way? Can TeXLive coexists with teTeX.
>
Not about porting TeXLive to FreeBSD actually.
After a quick look at 'powerdot' class I can suggest you using 'beamer'
as a workaround. It is in the teTeX.
Porting of TeXLive is a todo anyway, I think.

Alexey.
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

x11-wm/fluxbox fluxbox-generate_menu lists all available programs.

[Alexey Shuvaev]

Hello!

The script fluxbox-generate_menu shipped with current versions of
fluxbox (fluxbox-1.1.0.1_1 and 1.1.1 too, I think) produces
menu with all known programs. The reason for it is find_it* family
of functions used to determine if the program exists (see attached test.sh).
It expects that 'hash' will return non-zero exit code when it cannot find
the command and it is true on linix (some Ubuntu with 'dash', surprisingly
enough, man says it is BSD sh), but not here:

~> uname -a
FreeBSD wep4035.physik.uni-wuerzburg.de 8.0-CURRENT FreeBSD 8.0-CURRENT #0: Sun 
Sep 21 18:51:53 CEST 2008 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/GENERIC  
amd64

~> ./test.sh ls
Found ls

~> ./test.sh bla-bla-non-existent
Found bla-bla-non-existent

Substituting 'hash' with 'which' solves the problem more or less,
but I am not a sh guru to claim it is 100% correct.

It could be also a sh(1) bug...

Alexey.
#!/bin/sh
find_it() {
[ -n "$1" ] && hash $1 2> /dev/null && shift && "$@"
}

find_it $1 echo "Found $1"
exit 0
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: x11-wm/fluxbox fluxbox-generate_menu lists all available programs.

[Alexey Shuvaev]

On Mon, Sep 22, 2008 at 06:35:20PM -0400, Randy Pratt wrote:
> On Mon, 22 Sep 2008 14:16:35 -0500
> "Jeremy Messenger" <[EMAIL PROTECTED]> wrote:
> 
> > I agree for 'which' is best thing to do. Not all shells (csh, see in  
> > builtin(1)) have 'hash' stuff. I have bring all of hash -> which stuff  
> >  from 1.0.0, so let me know patches work for you.
> > 
> > http://people.freebsd.org/~mezz/diff/patch-util%3a%3afluxbox-generate_menu.in
> > http://people.freebsd.org/~mezz/diff/patch-util_fbsetbg
> > 
> > Put those files in x11-wm/fluxbox/files/ and reinstall fluxbox.
> 
Everything seems to be fine now.

> The patch-util_fbsetbg fixed the inability to set backgrounds.  I had
> almost forgotten about this minor problem.
> 
> The fluxbox-generate_menu.in patch results in an improved function
> but I recommend users backup their ~/.fluxbox in case it does
> something odd (I have a highly customized menu).
> 
This function gives some (not so bad) starting point for those
who have never used fluxbox before.

> Thanks again for fluxbox patches ;-)
> 
Me too :)

Alexey.
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: open-vm-tools fails on a recent sup to CURRENT

[Alexey Shuvaev]

On Tue, Oct 14, 2008 at 07:17:29PM -0400, Michael Proto wrote:
> Has anyone started seeing failures of ports/emulators/open-vm-tools builds
> with a recent current? I csup-ed my source recently (as of 20080926),
> rebuilt world and my kernel, and open-vm-tools builds fail in the vmhgfs
> module with the following:
> 
> 
> ...
> cc1: warnings being treated as errors
> vfsops.c: In function 'HgfsVfsMount':
> vfsops.c:142: warning: implicit declaration of function 'suser'
> vfsops.c:142: warning: nested extern declaration of 'suser'
> *** Error code 1
> ...
> 
> I've tried setting CFLAGS optimizations to -Os (my default), -O, -O2 and no
> optimizations and it fails with the same error every time. Has anyone else
> using CURRENT in VMware seen this error recently? Any ideas?
> 
This is due to API change suser() -> priv_check().
Have a look at
http://www.freebsd.org/cgi/cvsweb.cgi/ports/x11/nvidia-driver/Makefile
(revision 1.81) for example.
I am not sure about "PRIV_DRIVER" argument, but you can try to replace
"suser(CURTHREAD)" to "priv_check(CURTHREAD, PRIV_DRIVER)"
in the open-vm-tools sources.

Alexey.
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: ports/128754: [port infrastructure] implement master sites randomization

[Alexey Shuvaev]

On Tue, Nov 11, 2008 at 03:23:50AM +, RW wrote:
> On Mon, 10 Nov 2008 18:56:16 +0300 (MSK)
> Eygene Ryabinkin <[EMAIL PROTECTED]> wrote:
> 
> 
> > Today I was hit by the very bad connectivity with twaren.net and
> > nchc.dl.sourceforge.net (the first site in the SF mirrors list in the
> > FreeBSD ports .mk files) is hosted by Taiwan REN.  So, I decided to
> > implement simple randomization that will enable to evenly distribute
> > the downloads between SF mirrors.
> 
> 
> > ...
> > +# Need to drop a couple of initial rand() values: they tend
> > +# to be around 0.8 - 0.9, so for fairly small array lenght
> > +# they will produce identical values at the beginning.
> > +   srand(); rand(); rand(); rand(); rand();
> 
> I think it would be sensible to seed srand from a hash of something
> reproducible to make better use of caches - maybe DISTNAME+DISTVERSION.
>
Maybe I don't understand something, but is RANDOMIZE_MASTER_SITES
(see bsd.port.mk for details) not enough? It affects though all
sites, not only SF.

Just my 0.02$,
Alexey.
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: Kde4 install - no Xorg

[Alexey Shuvaev]

On Sat, Nov 29, 2008 at 10:10:28AM +1000, Da Rock wrote:
> Funny thing happened to me on a new install...
> 
> [snip]
> 
> A day and a half later, the install is finished so I run kdm. Not found
> so I run a find search and then run /usr/local/kde4/bin/kdm. It comes up
> saying it can't find and run the Xserver on display :0. What the?!
> 
> So I run a search on pkg_version -v and find xorg is not installed- what
> the?! Maybe I'm missing something here, but I thought installing kde4
> would install xorg (I'm pretty sure it has before if I remember right-
> it has been a while, but I'm sure I'm not that daft) as it kinda needs
> it to run and ports generally install dependencies. Has someone
> forgotten this in the Makefile?
> 
> Not trying to be picky, but I thought it might more sense and offer my
> view :)
> 
Well, I would say it is not a bug, it is a feature of X window system.
I think that X libraries are there, it is X server missing.
One can install all X applications on one machine (let's say, server)
and X servers on any number of graphical terminals (yes, X servers are
run on what is normally called a client). After that it is possible to
point clients on the server to the right X server (via DISPLAY environment,
for example). That way the application will be run on server displaying
output and receiving input from the remote X server. (Yes the terminology
is weird :)

If you don't care about unnecessary components you can
cd /usr/ports/x11/xorg
make intstall clean

Hope, this explains something,
Alexey.
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: PYTHON_SITELIBDIR gets parsed incorrectly

[Alexey Shuvaev]

Hello!

On Wed, Dec 10, 2008 at 12:57:52AM -0800, Silver Salonen wrote:
> 
> Hello.
> 
> I'm creating a port that uses python. I've set in Makefile:
> USE_PYTHON= yes
> PYTHON_SITELIBDIR=${PYTHON_SITELIBDIR:S|^${PREFIX}/||g}
> PLIST_SUB+= PYTHON_SITELIBDIR="${PYTHON_SITELIBDIR}"
> 
> And pkg-plist has entries a'la:
> %%BINDINGSPYTHON_SITELIBDIR%%/
> 
> This %%BINDINGS%% gets replaced with "", so that should not be an issue.
> 
> Anyway, when I install port, +CONTENTS contains lines a'la:
> /usr/local/lib/python2.5/site-packages/museek/__init__.py
> 
This is wrong. They should be relative to ${LOCALBASE},
lib/python2.5/site-packages/bla-bla-bla
in this case.
Can't say why %) Examine the behavior of PYTHON_SITELIBDIR variable
in the Makefile.

> And when I try deinstalling it, I get errors a'la:
> pkg_delete: file
> '/usr/local//usr/local/lib/python2.5/site-packages/museek/__init__.py'
> doesn't exist
> 
> Why do these files get prefixed with $LOCALBASE (or $PREFIX)?
> 

0.02$,
Alexey.
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: TeXLive

[Alexey Shuvaev]

On Wed, Dec 24, 2008 at 02:10:12PM +0100, Romain Tartière wrote:
> Hi!
> 
> There have been numerous mails about adding ports for TeXLive to FreeBSD
> [1,2,3,4], unfortunately, nothing is available so far.
> 
> 
> Since I really think TeXLive can be a plus for FreeBSD, and because I
> use TeXLive on another system, I started another effort to bring it to
> the ports tree.  In order to avoid loosing everything if I run out of
> time, I created a Google code project for working:
> 
> http://code.google.com/p/freebsd-texlive/
> 
Nice!

> 
> Some of the distfiles are sort of meta-packages, this helps grouping
> [5, Categories].  Here are some ports organisation possibilities:
> 
>  1. One port per Scheme (10 ports)
>+ very few ports;
>- low granularity;
>- each port conflict with others.
> 
>  2. One port per Collection (84 ports) + One meta-port per Scheme (10
> Meta-ports)
>+ no conflict (AFAIK);
>- low granularity.
> 
>  3. One port per Package, grouping related packages (e.g. foo,
> foo.source and foo.doc) (/[0-9]{4}/ ports) + meta-port for
> Collections (84 meta-ports) + meta-port for Scheme (10 meta-ports)
>+ high granularity;
>+ no conflict;
>- many ports.
> 
>  4. Same as #3 without grouping packages
>+ highest granularity;
>- many many ports.
> 
> 
> I am in favor of #3 since it allows TeXLive users to install a basic set
> that fit their needs (a beginner will install the full scheme
> meta-package and have everything, another will choose a minimal scheme,
> another will directory install the collections he wants, it is possible
> to install a particular package without installing loads of other
> packages (say you have a document that use svninfo for example and you
> don't have / want collection-latexextra)).
> 
> I would however be pleased to read what teTeX/TeXLive [future] users
> think about all this.
> 
As a current teTeX and Xorg user, I like your choice #3.
As a little note, you can consider sub-splitting Package port into 'meat' part
(always installed), documentation, examples, etc. (controlled by
NOPORTDOCS, NOPORTEXAMPLES, etc. variables set by the end user).
So, it is still one FreeBSD port, but user can choose whether to install
doc and so on, or not.

Just FYI, debian seems to have chosen something between #1 and #2:
~> grep ^texlive allpackages | wc
  93 7757736

Just my 0.02$,
Alexey.
___
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 install a port without install: in the Makefile

[Alexey Shuvaev]

On Fri, Jan 23, 2009 at 08:46:32AM -0700, Steve Franks wrote:
> I presume Florent's preferred method is "INSTALL_PROGRAM"?  So far,
> the only doc I've found is that it exists.  So I put INSTALL_PROGRAM
> $(WORKDIR)/$(PORTNAME) (portname just happens to be the name of the
  ^
  WRKDIR or WRKSRC? See below.
> executable) in the port Makefile, or what?  I've never been able to
> 'read' makefiles, so I'm not sure a look at ports.mk is going to cause
> anything but frustration.  We've spent minutes arguing philisophy, can
> I get a couple seconds of example? :)  Otherwise, PLIST_FILES looks
> like it will work to me...
> 
As suggested by Oliver you do in the Makefile:

[...]
do-install:
${INSTALL_PROGRAM} ${WRKSRC}/${PORTNAME} ${PREFIX}/bin/
[...]

Here you should decide yourself what is appropriate here:
WRKDIR is for example:

[wep4035] /usr/ports/x11-toolkits/slgtk> make -V WRKDIR
/usr/ports/x11-toolkits/slgtk/work

while WRKSRC is:

[wep4035] /usr/ports/x11-toolkits/slgtk> make -V WRKSRC
/usr/ports/x11-toolkits/slgtk/work/slgtk-0.7.3

So you should check in which directory your port extracts itself
(after make extract).
And you write in the pkg-plist:

bin/program_name

Here it is better not to bother with PORTNAME substitution and write
actual name of the program.

The documentation about internals of FreeBSD ports is available online:
http://www.freebsd.org/doc/en_US.ISO8859-1/books/porters-handbook/index.html

or, if you have installed (or built yourself) it, offline too:
file:///usr/share/doc/en_US.ISO8859-1/books/porters-handbook/index.html

Hope this helps,
Alexey.
___
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: libX11 dependencies

[Alexey Shuvaev]

On Tue, Jan 27, 2009 at 10:35:12AM +, Andrew Hotlab wrote:
> 
> I'm so sorry to annoy you with a question that might be stupid,
> but I'm not yet
> very experienced in managing software on the FreeBSD platform.
> 
> During my weekly ports maintainance (I'm using the ports-mgmt/portmaster)
> I've noticed that the www/drupal port seems to require the lang/python25 now,
> and this dependency is due to the latest x11/libX11 version, which wants
> x11/xcb-proto and x11/libxcb ports, which bring me lang/python25.
> Since I read that the "XCB option" should have been removed from r1.8 of the
> pkg-plist file
> (http://www.freebsd.org/cgi/cvsweb.cgi/ports/x11/libX11/pkg-plist),
> I'm wondering if such dependency is still really needed.
> 
That was an option, now it is mandatory. So you can't avoid lang/python25 :)

> Thanks you very much for your invaluable commitment in maintaing this
> great operating system!
> 
___
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 subject)

[Alexey Shuvaev]

On Mon, Jan 26, 2009 at 04:58:23PM -0300, Arthur Melo wrote:
> Dear Srs.
> 
> The error ocurred when I enter in my gmail.
> 
> [supo...@bsdteste /usr/home/suporte]$ firefox --sync
> :1: error: unexpected character `\1', expected keyword - e.g. `style'
> NP_Initialize
> New
> open dsp: No such file or directory
> SetWindow
> SetWindow
> NewStream
> WriteReady
> Write
> decoding...
> shmget: Cannot allocate memory
  ^^^
> Size = 547 x 225
> shmat: Invalid argument
> The program 'firefox-bin' received an X Window System error.
> This probably reflects a bug in the program.
> The error was 'BadAccess (attempt to access private resource denied)'.
>   (Details: serial 33 error_code 10 request_code 146 minor_code 1)
>   (Note to programmers: normally, X errors are reported asynchronously;
>that is, you will receive the error a while after causing it.
>To debug your program, run it with the --sync command line
>option to change this behavior. You can then get a meaningful
>backtrace from your debugger if you break on the gdk_x_error() function.)
> [supo...@bsdteste /usr/home/suporte]$ uname -a
> FreeBSD bsdteste.grupoatemde.com.br 7.1-RELEASE FreeBSD 7.1-RELEASE
> #0: Thu Jan  1 14:37:25 UTC 2009
> r...@logan.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC  i386
> [supo...@bsdteste /usr/home/suporte]$
> 
Any chance you have running postgresql server on this machine?
Seems you are running out of kernel's limits on SysV shared memory resources.
You could try doing what is in postgresql's pkg-message:

[snip]
To allow many simultaneous connections to your PostgreSQL server, you
should raise the SystemV shared memory limits in your kernel. Here are
example values for allowing up to 180 clients (configurations in
postgresql.conf also needed, of course):
  options SYSVSHM
  options SYSVSEM
  options SYSVMSG
  options SHMMAXPGS=65536
  options SEMMNI=40
  options SEMMNS=240
  options SEMUME=40
  options SEMMNU=120
[snip]

My 0.02$,
Alexey.
___
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: Re: Re: java/jboss5 - buildable

[Alexey Shuvaev]

On Mon, Jan 26, 2009 at 10:09:47PM +0200, Mario Pavlov wrote:
> Hi,
> I guess that cluster doesn't have internet connection for security reasons ?
> Downloading the files from the maven repo prior to building the port
> sounds a little bit complex to me...
> 
One of the examples is net/acx100 ports. It wants to download firmware.
The solution is to list everything port want to download in distinfo
and then put necessary files where port expects to find them (= where
the port automatically downloads them) in pre-build stage.

> But that's probably because I'm not very much in the ports system...
> however if you think there's anything I can help with I'd gladly do!
> ...I have a few years experience in programming
> (mostly Java, some C and some scripting), that's all
>

Hope this helps,
Alexey.
___
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: Contact for assistance

[Alexey Shuvaev]

On Fri, Jan 30, 2009 at 06:56:17PM -0500, V. M. Tame-Reyes wrote:
>
> Hello,
>
> I live in a place where the internet connection is
> very, very slow, and i feel very enthusiastic about
> freeBSD (i'm currently using Linux), therefore i
> had a friend download about 16 GB of ports from
> the official ports site, and i have them now in my
> local network.
>
> We are working on projects related to molecular
> dynamics, and other physics related topics, so we
> kind need trustworthy, robust servers to do the
> calculations, and we decided to try this OS,
> could you provide some info/howto create a ports
> server for my intranet, so i can move some servers
> devoted to do calculations to this OS ?
>
On the machine which will serve ports' distfiles you enable the ftp server
with ports' distfiles directory. This is done with this lines in /etc/rc.conf:

ftpd_enable="YES"
ftpd_flags="-Ar"

and adding user "ftp" (via adduser command). Home directory of ftp user
should be /usr/ports/distfiles and nologin shell. The entry in /etc/passwd
should look like:

ftp:*:1002:14:FTP anonymous user:/usr/ports/distfiles:/usr/sbin/nologin

On the machines which will build (and download) ports you put the following
in /etc/make.conf:

MASTER_SITE_OVERRIDE+=ftp://your_ports_sevrer/${DIST_SUBDIR}/

If you populate /usr/ports/distfiles on the ftp server with actual
tarballs you should be able to build ports on clients as usual with
cd /usr/ports/category/portname ; make install clean.

Of course, this is only one of the possible methods...

> I apologize if this is the wrong contact to reach
> while looking for the assistance i need, but actually
> was one that i found.
>
>
> Thanks in advance,
>

Good luck,
Alexey.
___
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: A plea or sanity in port options menu

[Alexey Shuvaev]

On Mon, Feb 02, 2009 at 03:39:25PM -0500, Bill Moran wrote:
> In response to Warren Block :
> 
> > On Mon, 2 Feb 2009, Bill Moran wrote:
> > 
> > > How about:
> > >
> > >   Options for port-fu
> > > [ ] BRG   Bernstein Riggs Guillotine parsing
> > > [X] QFZ   Quantum Freeze Zulu rending
> > >
> > > At least that one gives me _some_ idea what those TLAs mean.
> > >
This particular example is nonexistent and thus too far from reality.

> > 
> > [snip]
> 
> I don't think there's any need for any new features in the ports
> infrastructure.  I think it's just a matter of Makefile authors taking
> the time to describe their options.  A quick test of some ports turns
> up this one:
> 
>  [ ] OPENGL  OpenGL support 
> 
> True but useless.  How about:
> 
>  [ ] OPENGL  Use OpenGL graphics library
> 
> ...which, at least give the user _some_ idea what they're doing.
> 
I don't see any difference here. OpenGL = Open Graphics Library, so your
description is redundunt (Use Open Graphics Library graphics library).
Well, you can write 'Use Open Graphics Library', but it is again
not so much different from 'OpenGL support'.

> OpenGL probably isn't a good example, however.  It's pretty easy to Google
> OpenGL and figure out what it is.
>
As quite a number of other 'bad' option descriptions.

> Here's some more bizarre options:
> 
>  [X] EPUB  Epub modules
>  [X] EXTENSIONSExtensions
>  [X] TEMPLATE  Templates
>  [X] TOOLS Tools
> 
> I mean, if I enable "Extensions", what happens?  How do I figure out
> what happens?  I have to read the Makefile, at which point having these
> options on a menu is pretty pointless.  I mean, I can't even come up
> with a Google search to help me figure out what "tools" are involved
> here.
> 
> There are some ports that do this very well.  For example:
>  [ ] NLS   Use internationalized messages
>  [ ] PAM   Build with PAM support (server only)
^^
Exactly what you are fighting against.

>  [ ] LDAP  Build with LDAP authentication support
>  [ ] MIT_KRB5  Build with MIT's kerberos support
>  [ ] HEIMDAL_KRB5  Builds with Heimdal kerberos support
^^^
The above 2 also.

>  [ ] OPTIMIZED_CFLAGS  Builds with compiler optimizations (-O3)
>  [X] XML   Build with XML data type (server)
>  [X] TZDATAUse internal timezone database (server)
>  [ ] DEBUG Builds with debugging symbols
>  [ ] ICU   Use ICU for unicode collation (server)
>  [ ] INTDATE   Builds with 64-bit date/time type (server)
> 
> I mean, a Google on ICU is liable to bring up all sorts of medical drama
> websites, but I can do a search for "ICU unicode" and find my answer on
> the first result.  Not only am I told that optimized compiler flags are
> an option, but I'm told the exact one that will be used (-O3)
> 
> The porters handbook doesn't seem to offer any helpful advice on these:
> http://www.freebsd.org/doc/en/books/porters-handbook/makefile-options.html
> 
> In fact, the examples it provides are excellent examples of doing it
> WRONG.
> 
> Let me see about making a patch to the porters handbook to provide some
> advice ...
> 
Ok let's examine my 4 ports 3 of which do use OPTIONS.

x11-toolkits/gtkdatabox:
OPTIONS=GLADE "Enable libglade2 support" off \
GLADEUI "Enable glade3 support" off

/usr/ports/devel/libglade2> cat pkg-descr 
LibGlade allows GLADE interfaces to be handled at runtime, freeing
GUI development from code development.  This allows an interface to
be changed without requiring a re-compilation.

/usr/ports/devel/glade3> cat pkg-descr 
Glade is a RAD tool to enable quick & easy development of user interfaces
for GTK+/GNOME.  It can generate the C source code needed to create
the interfaces designed within Glade's interface editor.

Any idea here how to put all these into small line of description field?
[RAD = Rapid Application Development, hope you know what GUI is]
Do these long descriptions help you?

x11-toolkits/slgtkdatabox:
OPTIONS=SLGLADE "Enable slglade support (run-time)" off

/usr/ports/devel/slglade> cat pkg-descr 
SLglade is a S-Lang module that provides S-Lang bindings
for the libglade library. Used in conjunction with SLgtk,
it allows you to design your GUI with Glade (a GTK+ user interface builder),
save the interface description in a Glade XML file,
and then generate your S-Lang script's graphical interface
directly from the XML at runtime. This should reduce the time spent
developing SLgtk applications considerably, as it eliminates
the tedious job of writing interface-creation code by hand.

This is an update for Christopher Stawarz's SLglade module.

WWW: http://laurent.perez2.free.fr/comp/slang/modules/modules.html

Same here, short version of pkg-descr for slglade

Re: Call for potential ports maintainers

[Alexey Shuvaev]

Thomas Abthorpe (Thu 02/12/09 12:32):
> 
> This topic came up in IRC, and I was encouraged to go out, and find some new 
> maintainers.
> 
> At any given time, approximately 20 - 25% of all ports are unmaintained. Not 
> all unmaintained ports need updating, but some do. That is where you folks 
> come in. 
> 
> There are a bunch of you out there who are subscribers to this list (and 
> other 
> FreeBSD related lists too, I am sure), you have FreeBSD installed and likely 
> have quite an array of ports installed on this system of yours. You are 
> subscribed as a means of keeping up with the world of FreeBSD.
> 
> But you have been holding back, thinking "I really would like to do something 
> to contribute to the success of FreeBSD, but I am not sure what."
> 
> How do I know this? I was one, a silent observer on the mailing lists, and in 
> on IRC. Then one day, I answered a similar plea, 
> http://lists.freebsd.org/pipermail/freebsd-announce/2006-May/001065.html.
> 
> I have summarised some details on the wiki on Adopting Ports, 
> http://wiki.freebsd.org/PortsTasks#head-f018f566bce2ff96ec13fabd536d7cc6dc6f4275.
> 
> The gauntlet has been thrown down, who among you is prepared to pick it up?
> 
Well, if we go so far, could someone (you???) look at net/acx100 and
net/gacxtool ports. The related PR 129977 (2 months, still unassigned).
The port formally has a maintainer but its current state:
BROKEN= Does not compile on FreeBSD >= 6.x
DEPRECATED= Has been broken for more than 6 months
EXPIRATION_DATE=2008-09-19
says for itself.

Related discussion on -CURRENT:
http://lists.freebsd.org/pipermail/freebsd-current/2008-December/001666.html
This is the message from developer saying the driver should work on 7.0:
http://lists.freebsd.org/pipermail/freebsd-current/2008-December/001709.html

More details are in the PR description.

Thanks,
Alexey.
___
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: lyx 1.6 upgrade?

[Alexey Shuvaev]

On Mon, Feb 16, 2009 at 11:16:26AM +0100, Giuseppe Pagnoni wrote:
> Dear port developers,
> 
> is there a plan to upgrade the lyx15 port in the short term?  The
> version in the stable port tree (1.5.6) is not compatible anymore with
> the later 1.6 version, which creates difficulties for opening the same
> document under different system.
> 
> thanks for the great work
> 
Have you tried contacting print/lyx port maintainer (CC-ed)?

Alexey.
___
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: Determining if Nvidia graphics card supports widescreen modes

[Alexey Shuvaev]

On Mon, Feb 16, 2009 at 01:50:25PM +, RW wrote:
> On Mon, 16 Feb 2009 13:29:38 +
> RW  wrote:
> 
> > 
> > I need to replace my old CRT monitor. I suspect that my nvidia
> > GeForce FX 5700LE wont support a widescreen monitor, but is there
> > any way of finding-out what modes are supported.
> > 
> > I don't really want to replace the card as it's agp, and they seem to
> > be relatively expensive these days.
> 
I think video cards today support almost anything. I remeber I have played
with my GeForce4 420 Go (NV17 chipset) with manual Modeline-s in xorg.conf.
I was able to activate some totally crazy modes like 2048x4 :)

My 0.02$,
Alexey.
___
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: Possibly unbuildable ports reminder

[Alexey Shuvaev]

On Sat, Feb 28, 2009 at 10:00:07AM +, Bill Fenner wrote:
> Dear porters,
> 
>   This is just a reminder to please periodically check the list of
> unbuildable ports at http://pointyhat.freebsd.org/errorlogs/ .
> A list by MAINTAINER is
> 
> http://people.freebsd.org/~fenner/errorlogs/
> 
> so you can easily check the status of ports that you maintain.  In
> addition, the list of ports with no MAINTAINER with build problems is
> 
> http://people.freebsd.org/~fenner/errorlogs/po...@freebsd.org.html
> 
I would say that this run:
i386-6-exp-latest   Fri Feb 27 00:30:39 2009gtkdatabox-0.9.0.0.log  
1   56k x11-toolkits/gtkdatabox ld
tried to do something bad. In this case it tried to build the old version
of gtkdatabox (0.9.0.0) with the new version of gtk (2.14.7).
The ports tree was never in this state.

Just FYI,
Alexey.
___
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: [headsup] call for assistance with ports broken on -current

[Alexey Shuvaev]

On Sat, Feb 28, 2009 at 08:02:14PM -0600, Mark Linimon wrote:
> With 8.0 coming up, it's time to take a look at the ports that have
> been broken by some recent changes to freebsd-current.  I have put
> a list of these ports, categorized by which change, on the wiki at
> http://wiki.freebsd.org/PortsBrokenOnCurrent.
> 
> These changes are: tty changes, jail changes, import of strndup(3),
> ARP v2, libusb20.  (The latter has not yet been run through pointyhat,
> and is probably incomplete.)
> 
> Any help fixing these will be appreciated.
> 
palm/uppc-kmod too (it is using usb stack directly, not via libusb).

Alexey.
___
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: generate index file which respects non default environment

[Alexey Shuvaev]

On Thu, May 07, 2009 at 08:24:07PM +0400, Boris Samorodov wrote:
> Hello List,
> 
> 
> is there any possibility to generate an index file which
> respects environment, non default OPTIONS? I mean if for
> example OVERRIDE_LINUX_BASE_PORT is defined as f8, then
> I expect the INDEX should reflect it.
> 
I always thought that everything put into /etc/make.conf (or include
derivatives) would be accounted for during "make index" in /usr/ports.
Is it not true for OVERRIDE_LINUX_BASE_PORT=f8?

Alexey.
___
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"