Re: autogen rdeps (was: too many dependencies)

[Jan Stary]

On Dec 13 07:32:59, ryandes...@macports.org wrote:
> On Dec 13, 2015, at 06:40, Jan Stary wrote:
> > 
> > This is just insane.
> > I need jpeg and the whole TeX suite to install autoconf?
> 
> No, you (apparently) need them to install autogen. autogen and autoconf are 
> different software,
> available in different ports. If you want autoconf, install the autoconf 
> port. 

Sorry, that's a typo - I meant autogen.

To correct:
I need jpeg and the whole TeX suite to install autoconf?
___
macports-users mailing list
macports-users@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-users

autocong rdeps (was: too many dependencies)

[Jan Stary]

Now that have put -x11 +no_x11 into variants.conf,
the xorg-* stuff is not being pulled in, but still:

The following ports are dependencies of autogen @5.18.4_1:
  xz
libiconv
  gperf
gettext
  expat
  ncurses
  pkgconfig
  guile
readline
libtool
gmp
libunistring
  perl5
perl5.16
  gdbm
  texinfo
help2man
  perl5.22
  p5.22-locale-gettext
  texlive-basic
texlive-common
texlive-bin
  fontconfig
freetype
  bzip2
  libpng
zlib
  libzzip
xmlto
  getopt
  coreutils
  findutils
  libpaper
  libxml2
  libxslt
  docbook-xml
xmlcatmgr
docbook-xml-4.1.2
  unzip
  docbook-xml-4.2
docbook-xml-4.3
docbook-xml-4.4
docbook-xml-4.5
docbook-xml-5.0
  docbook-xsl
  fop
  poppler
autoconf
automake
curl
  openssl
  curl-ca-bundle
jpeg
glib2
  libffi
  pcre
libedit
cairo
  libpixman
lcms2
  tiff
openjpeg15
  jbigkit
poppler-data
gobject-introspection
  py27-mako
python27
  sqlite3
  db48
  python_select
  python2_select
py27-setuptools
py27-beaker
py27-markupsafe
  graphite2
cmake
  libarchive
lzo2
  icu
  harfbuzz
  harfbuzz-icu
  mpfr
  potrace
  ghostscript
jbig2dec
libidn
boehmgc
  libatomic_ops


This is just insane.
I need jpeg and the whole TeX suite to install autoconf?

Jan


On Dec 13 12:27:47, h...@stare.cz wrote:
> I just selfupdated 2.3.4 on my MacOSX 10.5.8
> an try to install autogen.
> 
> hans@mac:~$ sudo port install autogen
> --->  Computing dependencies for autogen
> --->  Dependencies to be installed: guile libunistring texlive-basic 
> texlive-bin cairo xorg-libXext xorg-libX11 xorg-bigreqsproto xorg-inputproto 
> xorg-kbproto xorg-libXau xorg-xproto xorg-libXdmcp xorg-libxcb 
> xorg-libpthread-stubs xorg-xcb-proto libxml2 xz xorg-util-macros 
> xorg-xcmiscproto xorg-xextproto xorg-xf86bigfontproto xorg-xtrans 
> xorg-xcb-util xrender xorg-renderproto ghostscript jbig2dec jpeg perl5 tiff 
> xorg-libXt xorg-libsm xorg-libice graphite2 cmake libarchive lzo2 harfbuzz 
> harfbuzz-icu icu libzzip xmlto docbook-xml docbook-xml-4.1.2 docbook-xml-4.2 
> xmlcatmgr docbook-xml-4.3 docbook-xml-4.4 docbook-xml-4.5 docbook-xml-5.0 
> docbook-xsl findutils fop getopt libxslt mpfr poppler gobject-introspection 
> py27-mako py27-beaker py27-setuptools py27-markupsafe lcms2 openjpeg15 
> jbigkit poppler-data potrace texlive-common xorg-libXaw groff netpbm jasper 
> libnetpbm subversion apr apr-util db46 cyrus-sasl2 serf1 scons xorg-libXmu 
> xpm xorg-libXi xorg-libXfixes xorg-fixesproto xo
 rg
>  -libXp xorg-printproto readline
> --->  Configuring xorg-bigreqsproto
> --->  Building xorg-bigreqsproto
> --->  Staging xorg-bigreqsproto into destroot
> --->  Installing xorg-bigreqsproto @1.1.2_0
> --->  Activating xorg-bigreqsproto @1.1.2_0
> --->  Cleaning xorg-bigreqsproto
> --->  Fetching archive for xorg-inputproto
> 
> Surely the xorg-* ports have nothing to do with it.
> Why is macports considerr them as dependencies?
> 
>   Jan
> 
> ___
> macports-users mailing list
> macports-users@lists.macosforge.org
> https://lists.macosforge.org/mailman/listinfo/macports-users
___
macports-users mailing list
macports-users@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-users

leaving a binary out

[Jan Stary]

I would like to leave one particular binary out of a package.
Namely, the sndfile-regtest of libsndfile is not intended
for the end user. What is the preferred way to do it?
Does macports have a 'packing list' where I could
expicitly say what to install and what not to install?

Jan

___
macports-users mailing list
macports-users@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-users

too many dependencies

[Jan Stary]

I just selfupdated 2.3.4 on my MacOSX 10.5.8
an try to install autogen.

hans@mac:~$ sudo port install autogen
--->  Computing dependencies for autogen
--->  Dependencies to be installed: guile libunistring texlive-basic 
texlive-bin cairo xorg-libXext xorg-libX11 xorg-bigreqsproto xorg-inputproto 
xorg-kbproto xorg-libXau xorg-xproto xorg-libXdmcp xorg-libxcb 
xorg-libpthread-stubs xorg-xcb-proto libxml2 xz xorg-util-macros 
xorg-xcmiscproto xorg-xextproto xorg-xf86bigfontproto xorg-xtrans xorg-xcb-util 
xrender xorg-renderproto ghostscript jbig2dec jpeg perl5 tiff xorg-libXt 
xorg-libsm xorg-libice graphite2 cmake libarchive lzo2 harfbuzz harfbuzz-icu 
icu libzzip xmlto docbook-xml docbook-xml-4.1.2 docbook-xml-4.2 xmlcatmgr 
docbook-xml-4.3 docbook-xml-4.4 docbook-xml-4.5 docbook-xml-5.0 docbook-xsl 
findutils fop getopt libxslt mpfr poppler gobject-introspection py27-mako 
py27-beaker py27-setuptools py27-markupsafe lcms2 openjpeg15 jbigkit 
poppler-data potrace texlive-common xorg-libXaw groff netpbm jasper libnetpbm 
subversion apr apr-util db46 cyrus-sasl2 serf1 scons xorg-libXmu xpm xorg-libXi 
xorg-libXfixes xorg-fixesproto xorg
 -libXp xorg-printproto readline
--->  Configuring xorg-bigreqsproto
--->  Building xorg-bigreqsproto
--->  Staging xorg-bigreqsproto into destroot
--->  Installing xorg-bigreqsproto @1.1.2_0
--->  Activating xorg-bigreqsproto @1.1.2_0
--->  Cleaning xorg-bigreqsproto
--->  Fetching archive for xorg-inputproto

Surely the xorg-* ports have nothing to do with it.
Why is macports considerr them as dependencies?

Jan

___
macports-users mailing list
macports-users@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-users

Re: [MacPorts] #49821: libsndfile - update to 1.0.26

[Jan Stary]

On Dec 06 18:45:11, h...@stare.cz wrote:
> > On Nov 26 20:20:28, nore...@macports.org wrote:
> > > #49821: libsndfile - update to 1.0.26
> > > -+
> > >   Reporter:  hans@???  |  Owner:  macports-tickets@???
> > >   Type:  update  | Status:  new
> > >   Priority:  Normal  |  Milestone:
> > >  Component:  ports   |Version:  2.3.4
> > > Resolution:  |   Keywords:  haspatch
> > >   Port:  libsndfile  |
> > > -+
> > > 
> > > Old description:
> > > 
> > > > Here is a patch to the Portfile of audio/libsndfile
> > > > which brings it to the latest 1.0.26 release,
> > > > and the upgraded version of files/
> > > >
> > > > The speex.patch removes SPEEX_* from EXTERNAL_* in configure;
> > > > I believe speex.patch is a better name, and configure.patch
> > > > should be replaced with this.
> > > >
> > > > The carbon.patch is a better version of fix-include.patch
> > > > which it should replace. Not only does it remove the Carbon.h include
> > > > from sndfile-play.c, but it removes Carbon altogether.
> > > >
> > > > I am leaving src__config.h.ed as is, but I am not completely sure
> > > > about its purpose; if __BIG_ENDIAN__, __LP64__, etc, is defined,
> > > > then ./configure (which creates config.h) is supposed to figure out
> > > > the SIZEOF_LONG etc, right? If not, it's a bug in configure,
> > > > not something we should patch in the resulting config.h, right?
> > > >
> > > > I also removed the sqlite variant from the Portfile.
> > > > Only sndfile-regtest uses sqlite; does anybody use sndfile-regtest?
> > > >
> > > > Jan
> > > 
> > >  You can easily discover using "svn log" and "svn blame" that this file 
> > > was
> > >  added in r42762 to resolve #17088, when libsndfile was at version 1.0.17.
> > 
> Thanks for the pointer, I have my svn tree now.
> 
> The root cause seems to be
> http://www.mega-nerd.com/libsndfile/FAQ.html#Q018
> Please help me understand it clearly (author cc'd).
> The chunks of the diff between the original config.h
> and the patched one look like this:
> 
>   +#ifdef __LP64__
>   +#define CPU_CLIPS_NEGATIVE 0
>   +#else
>   #define CPU_CLIPS_NEGATIVE 1
>   +#endif
>   
>   +#ifdef __BIG_ENDIAN__
>   +#define CPU_IS_BIG_ENDIAN 1
>   +#else
>   #define CPU_IS_BIG_ENDIAN 0
>   +#endif
> 
> Why do we need this?
> The defines are used in code like this:
>  
>if (CPU_CLIPS_POSITIVE == 0 && scaled_value >= (1.0 * 0x7FFF)) {
> dest [count] = 127 ;
> continue ;
>} ;
>  
>  
> The condition (CPU_CLIPS_POSITIVE == 0) is decided at compile time,
> whether it is defined to be 0 or 1. So even with the patch,
> libsndfile is compiled to behave this way, or it is compiled
> to behave the other way.
>  
> I don't have a BIGENDIAN mac or a LP64 mac to test on,
> but doesn't ./configure just define the constants
> to be the appropriate value, on a LP64 machine?
> Can people with BIGENDIAN or LP64 machine please test?
> 
> Maybe I am missing something obvious, but how exactly does this
> patch result in a universal binary, as opposed to without it?

Ah, it gets configured once but compiled *twice*, inside Xcode, right?
So my "compile time" argument above misses the point, right?
(Please excuse my UB ignorance, never used it.)

Jan

___
macports-users mailing list
macports-users@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-users

Re: [MacPorts] #49821: libsndfile - update to 1.0.26

[Jan Stary]

> On Nov 26 20:20:28, nore...@macports.org wrote:
> > #49821: libsndfile - update to 1.0.26
> > -+
> >   Reporter:  hans@???  |  Owner:  macports-tickets@???
> >   Type:  update  | Status:  new
> >   Priority:  Normal  |  Milestone:
> >  Component:  ports   |Version:  2.3.4
> > Resolution:  |   Keywords:  haspatch
> >   Port:  libsndfile  |
> > -+
> > 
> > Old description:
> > 
> > > Here is a patch to the Portfile of audio/libsndfile
> > > which brings it to the latest 1.0.26 release,
> > > and the upgraded version of files/
> > >
> > > The speex.patch removes SPEEX_* from EXTERNAL_* in configure;
> > > I believe speex.patch is a better name, and configure.patch
> > > should be replaced with this.
> > >
> > > The carbon.patch is a better version of fix-include.patch
> > > which it should replace. Not only does it remove the Carbon.h include
> > > from sndfile-play.c, but it removes Carbon altogether.
> > >
> > > I am leaving src__config.h.ed as is, but I am not completely sure
> > > about its purpose; if __BIG_ENDIAN__, __LP64__, etc, is defined,
> > > then ./configure (which creates config.h) is supposed to figure out
> > > the SIZEOF_LONG etc, right? If not, it's a bug in configure,
> > > not something we should patch in the resulting config.h, right?
> > >
> > > I also removed the sqlite variant from the Portfile.
> > > Only sndfile-regtest uses sqlite; does anybody use sndfile-regtest?
> > >
> > > Jan
> > 
> >  You can easily discover using "svn log" and "svn blame" that this file was
> >  added in r42762 to resolve #17088, when libsndfile was at version 1.0.17.
> 
Thanks for the pointer, I have my svn tree now.

The root cause seems to be
http://www.mega-nerd.com/libsndfile/FAQ.html#Q018
Please help me understand it clearly (author cc'd).
The chunks of the diff between the original config.h
and the patched one look like this:

+#ifdef __LP64__
+#define CPU_CLIPS_NEGATIVE 0
+#else
#define CPU_CLIPS_NEGATIVE 1
+#endif

+#ifdef __BIG_ENDIAN__
+#define CPU_IS_BIG_ENDIAN 1
+#else
#define CPU_IS_BIG_ENDIAN 0
+#endif

Why do we need this?
The defines are used in code like this:
 
   if (CPU_CLIPS_POSITIVE == 0 && scaled_value >= (1.0 * 0x7FFF)) {
  dest [count] = 127 ;
  continue ;
   } ;
 
 
The condition (CPU_CLIPS_POSITIVE == 0) is decided at compile time,
whether it is defined to be 0 or 1. So even with the patch,
libsndfile is compiled to behave this way, or it is compiled
to behave the other way.
 
I don't have a BIGENDIAN mac or a LP64 mac to test on,
but doesn't ./configure just define the constants
to be the appropriate value, on a LP64 machine?
Can people with BIGENDIAN or LP64 machine please test?

Maybe I am missing something obvious, but how exactly does this
patch result in a universal binary, as opposed to without it?
 
Jan
 
___
macports-users mailing list
macports-users@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-users

Re: Get MacPorts to forget about my Fink install

[Jan Stary]

On Sep 30 16:09:13, stephen.but...@gmail.com wrote:
> I'm transitioning from Fink to MacPorts. When I initially setup my MacPorts
> install I *thought* I had removed all my Fink stuff from my path.

How exactly did you remove all your Fink stuff?
Be removing it "from your path", do you mean that you left it
installed in /sw, just removed /sw from your PATH?

> Everything was working and I was happy, so I deleted my /sw directory.
> But now I see that the MacPorts build system has picked up /sw/bin/gnutar
> (among, possibly, other things I haven't discovered).

This means that you have *not* removed /sw before building MacPorts.


___
macports-users mailing list
macports-users@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-users

Re: [MacPorts] #47790: pstree: update to 2.39 2.39)

[Jan Stary]

On Jun 08 14:27:33, h...@stare.cz wrote:
> On Jun 08 02:32:01, nore...@macports.org wrote:
> > #47790: pstree: update to 2.39
> > -+--
> >   Reporter:  hans@???  |  Owner:  mww@???
> >   Type:  update  | Status:  closed
> >   Priority:  Normal  |  Milestone:
> >  Component:  ports   |Version:
> > Resolution:  fixed   |   Keywords:  haspatch
> >   Port:  pstree  |
> > -+--
> > Changes (by ryandesign@???):
> > 
> >  * status:  new => closed
> >  * cc: ryandesign@??? (added)
> >  * resolution:   => fixed
> > 
> > 
> > Comment:
> > 
>  I've updated pstree to 2.39 in r137283, but I haven't made all the changes
>  you proposed, because many of them are regressions.

Thanks.

>  For example, pstree does not install any libraries, and it correctly
>  indicates this via the line `installs_libs no`, but your patch removes
>  this line. There are no ports that depend on pstree, so it doesn't really
>  affect anything, but since the port maintainer has already gone out of his
>  way to indicate that the port does not install libraries, there's no
>  reason to remove this indication.

Are the ports that install no libraries supposed to say so?
>From the top of my head, there are many ports that don't.
Maybe I am missing something, but shouldn't the ports that _do_ install
libraries explicitly say so, with 'installs_libs no' being the default?
(And if 'installs_libs no' _is_ the default, why have it in the Portfile?)

>  The existing configure script records the values of the CC, CFLAGS and
>  LDFLAGS variables into the Makefile and uses them at build time, which
>  means it's UsingTheRightCompiler and `-arch` flags. Your proposed change
>  doesn't do any of this, so a wrong compiler might be used, and the build
>  will always use the compiler's default architecture even if the user
>  requested something different.

Please excuse my ignorance: how does a macport user specify, say,
the exact CC to use when installing a port? The provided Makefile
then also uses the specified CC and CFLAGS and build time, right?

>  The README should still be installed, even if there is also a manpage.

Why?

>  I did apply some of your other changes: r137280 r137281
>  I also made some additional changes of my own: r137279 r137282

Thanks.

___
macports-users mailing list
macports-users@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-users

Re: Undelivered Mail Returned to Sender

[Jan Stary]

> On Jun 08 02:32:01, nore...@macports.org wrote:
> > #47790: pstree: update to 2.39
> > -+--
> >   Reporter:  hans@???  |  Owner:  mww@???
> >   Type:  update  | Status:  closed
> >   Priority:  Normal  |  Milestone:
> >  Component:  ports   |Version:
> > Resolution:  fixed   |   Keywords:  haspatch
> >   Port:  pstree  |
> > -+--
> > Changes (by ryandesign@???):
> > 
> >  * status:  new => closed
> >  * cc: ryandesign@??? (added)
> >  * resolution:   => fixed
> > 
> > 
> > Comment:
> > 
> >  I've updated pstree to 2.39 in r137283, but I haven't made all the changes
> >  you proposed, because many of them are regressions.

Thanks.

> >  For example, pstree does not install any libraries, and it correctly
> >  indicates this via the line `installs_libs no`, but your patch removes
> >  this line. There are no ports that depend on pstree, so it doesn't really
> >  affect anything, but since the port maintainer has already gone out of his
> >  way to indicate that the port does not install libraries, there's no
> >  reason to remove this indication.

Are the ports that install no libraries supposed to say so?
>From the top of my head, there are many ports that don't.
Maybe I am missing something, but shouldn't the ports that _do_ install
libraries explicitly say so, with 'installs_libs no' being the default?
(And if 'installs_libs no' _is_ the default, why have it in the Portfile?)

> >  The existing configure script records the values of the CC, CFLAGS and
> >  LDFLAGS variables into the Makefile and uses them at build time, which
> >  means it's UsingTheRightCompiler and `-arch` flags. Your proposed change
> >  doesn't do any of this, so a wrong compiler might be used, and the build
> >  will always use the compiler's default architecture even if the user
> >  requested something different.

Please excuse my ignorance: how does a macport user specify, say,
the exact CC to use when installing a port? The provided Makefile
then also uses the specified CC and CFLAGS and build time, right?

> >  The README should still be installed, even if there is also a manpage.

Why?

> >  I did apply some of your other changes: r137280 r137281
> >  I also made some additional changes of my own: r137279 r137282

Thanks.

___
macports-users mailing list
macports-users@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-users

Re: [MacPorts] #47790: update pstree to 2.39

[Jan Stary]

(ping)

On May 21 13:54:29, nore...@macports.org wrote:
> #47790: update pstree to 2.39
> -+--
>   Reporter:  hans@???  |  Owner:  mww@???
>   Type:  update  | Status:  new
>   Priority:  Normal  |  Milestone:
>  Component:  ports   |Version:
> Resolution:  |   Keywords:  haspatch
>   Port:  pstree  |
> -+--
> Changes (by mf2k@???):
> 
>  * cc: mww@??? (removed)
>  * owner:  macports-tickets@??? => mww@???
>  * version:  2.3.3 =>
> 
> 
> -- 
> Ticket URL: 
> MacPorts 
> Ports system for OS X
___
macports-users mailing list
macports-users@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-users

Re: [MacPorts] #46947: sox: please update to @14.4.2

[Jan Stary]

ping

> On Apr 26 19:40:17, nore...@macports.org wrote:
> > #46947: sox: please update to @14.4.2
> > -+
> >   Reporter:  mopihopi@???  |  Owner:  hans@???
> >   Type:  update  | Status:  new
> >   Priority:  Normal  |  Milestone:
> >  Component:  ports   |Version:
> > Resolution:  |   Keywords:
> >   Port:  sox |
> > -+
> > 
> > Comment (by hans@???):
> > 
> >  Replying to [comment:13 mf2k@???]:
> >  > You have whitespace changes in this patch which makes it hard to
> >  evaluate the changes you are proposing. We prefer a separate patch for
> >  that. Doing this will greatly increase your odds of getting the patch
> >  committed.
> > 
> >  A cleaner diff attached.
> > 
> > -- 
> > Ticket URL: 
> > MacPorts 
> > Ports system for OS X
___
macports-users mailing list
macports-users@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-users

Re: what was up with ntp again?

[Jan Stary]

> > The last release of http://www.openntpd.org/portable.html
> > happened about a month ago and explicitly states that it is
> > "known to build and work" on Mac OS X (10.9).
> 
> yay!
> 
> I think more recent openntpd fixed many of the issues that made it a poor 
> generic choice. Some interested party should probably make sure macports has 
> the most recent version and maybe report back on how well it works. (looks 
> like the compat implementation of adjfreq just returns ENOSYS, though).

Exactly. It configures and builds fine on my 10.5.8,
but fails immediately with an adjfreq error.

___
macports-users mailing list
macports-users@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-users

Re: what was up with ntp again?

[Jan Stary]

> > To put it in context: my computers all use the same ntp server (
> > fr.ntp.pool.org) so that in theory they share the same clock. Turns out
> > that my Mac is about 5min (a bit over 300 seconds) ahead of the others, and
> > also of Bradley's VM. I've tried deactivating and reactivating (after
> > setting time manually) network time in System Preferences, but it just
> > jumps back to the future.
> >
> > Is this related to the issue that was discussed a while back, and to
> > Apple's conflicting service (pacekeeper?)?

> sudo launchctl
> unload /System/Library/LaunchDaemons/com.apple.pacemaker.plist
> sudo rm /etc/ntp.drift
> sudo launchctl stop org.ntp.ntpd
> # wait an hour or so for ntpd to establish the current drift
> sudo
> launchctl load /System/Library/LaunchDaemons/com.apple.pacemaker.plist

So ntpd and pacemaker are supposed to run simultaneously?
What exactly is pacemaker's job if I have ntpd running?

> The longer version I'll briefly gloss: Apple replaced traditional ntp with
> one that uses less power and is more laptop friendly, when it works right.

Does "traditional ntp" mean ntp.org's implementation?
Is "pacemaker" the new implementation, or is there
an "Apple ntpd" now with the "pacemaker" on top?

Can you please give some pointers to how much less power
the new ntpd uses and how much more "laptop friendly" it is?

> But it assumes that the clock drift of a brand new machine is the same as
> that of a fully burned-in and deployed machine, which it might well not be.
> The above commands are a "quick reset" of the clock drift, but as Apple
> removed some parts of ntp they may not be sufficient to determine the
> current clock drift; in that case, you need to use a full ntpd to
> characterize the drift, then switch back to Apple's for the improved
> performance and power management.

So the Apple NTPd is a stripped down ntp.org implementation?
Or is it a different implementation, decidedly omitting some
aspects of NTP (nanosecond precission)?

> The real fix for this is someone needs to rehabilitate open(s)ntp, which is
> lighter weight by design but these days only supported on OpenBSD. I'm not
> holding my breath.

The last release of http://www.openntpd.org/portable.html
happened about a month ago and explicitly states that it is
"known to build and work" on Mac OS X (10.9).

> > When I tried using the Apple NTP and pacemaker, what I discovered
> > essentially is that NTP does NO clock adjustment at all. All the clock
> > adjustment comes from pacemaker. Unfortunately, it did not do a good job of
> > synchronizing for me. In particular, the Apple NTP was never able to get
> > past a poll of 256, and almost always was at 64. The drift file wanted to
> > be over 500 no matter what I did with the stock config.
> 
> Yes, this is why I added the caveat about possibly needing full ntpd. Some
> people *have* had it work; Apple's ntpd doesn't update the time itself, but
> can determine drift in simple cases, and as this doesn't require installing
> more software it's preferred. If it doesn't work then you're stuck with
> installing full ntpd at least temporarily.

I don't get it. If Apple's ntpd does not update the time,
what does it do?

> (Somewhere on my rather large to-do list is writing this up in detail
> somewhere, probably the MacPorts Trac wiki.)

That would be most appreciated.

On Mar 23 12:43:04, dl...@geeklair.net wrote:
> There's also work going on a new daemon (ntimed) that will likely eventually 
> be the 'best' ntpd replacement (it doesn't work on Mac OS X yet either, 
> though).

And it won't work on OS X for some time, judging by page 35 of
https://fosdem.org/2015/schedule/event/ntimed_ntpd_replacement/attachments/slides/788/export/events/attachments/ntimed_ntpd_replacement/slides/788/ntimed.pdf


Jan

___
macports-users mailing list
macports-users@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-users

Re: MacPorts 2.3.2 and "port provides"

[Jan Stary]

On Mar 05 09:17:22, allber...@gmail.com wrote:
> On Thu, Mar 5, 2015 at 9:13 AM, Jan Stary  wrote:
> 
> > > Those aren't hardlinks, but /tmp is a symlink to /private/tmp. Your
> > > vim just happens to realpath(3) before saving, it seems.
> >
> > It's not a symlink, they have the same inode number.
> > A symlink would look like this:
> >
> 
> Your observation would be valid if the file /tmp/whatever were symlinked.
> But it's not that specific file, but the directory /tmp that is symlinked.

Right. Thanks.
Anyway, does anyone know why this even exists?

___
macports-users mailing list
macports-users@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-users

Re: MacPorts 2.3.2 and "port provides"

[Jan Stary]

On Mar 05 14:26:37, c...@macports.org wrote:
> I don't know why it exists, but a couple of top-level directories
> are symlinked into /private.

In my case,

$ ls -l /private/
total 0
drwxr-xr-x  103 root  wheel  3502 Mar  2 21:21 etc/
drwxr-xr-x2 root  wheel68 Sep 24  2007 tftpboot/
drwxrwxrwt   35 root  wheel  1190 Mar  5 14:41 tmp/
drwxr-xr-x@  26 root  wheel   884 Jan 17  2011 var/

> > For example,
> > 
> >  $ vi /tmp/foo
> > 
> > creates "/tmp/foo" (obviously), but once I save it (:w),
> > it gets saved as "/private/tmp/foo"; at that moment,
> > there are two hardlinks for the same inode:
> > 
> >  $ ls -li /tmp/foo /private/tmp/foo
> >  15307909 -rw-r--r--  1 hans  wheel  6 Mar  5 12:55 /private/tmp/foo
> >  15307909 -rw-r--r--  1 hans  wheel  6 Mar  5 12:55 /tmp/foo
> 
> Those aren't hardlinks, but /tmp is a symlink to /private/tmp. Your
> vim just happens to realpath(3) before saving, it seems.

It's not a symlink, they have the same inode number.
A symlink would look like this:

$ ln -s foo bar
$ ls -li foo bar
15368325 lrwxr-xr-x  1 hans  wheel  3 Mar  5 15:12 bar -> foo
15307909 -rw-r--r--  1 hans  wheel  6 Mar  5 12:55 foo

___
macports-users mailing list
macports-users@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-users

Re: MacPorts 2.3.2 and "port provides"

[Jan Stary]

On Oct 18 19:22:43, ryandes...@macports.org wrote:
> MacPorts should be in /opt/local, not /private/opt/local.
> Is it possible that /opt is a symlink to /private/opt? Ancient versions of 
> the Cisco VPN installer were known to have moved /opt to /private/opt, then 
> placed a symlink at /opt.

The /private thing seems to be a more general MacOS thing.
Sorry for the OT, but can someone please elaborate?

For example,

  $ vi /tmp/foo

creates "/tmp/foo" (obviously), but once I save it (:w),
it gets saved as "/private/tmp/foo"; at that moment,
there are two hardlinks for the same inode:

  $ ls -li /tmp/foo /private/tmp/foo 
  15307909 -rw-r--r--  1 hans  wheel  6 Mar  5 12:55 /private/tmp/foo
  15307909 -rw-r--r--  1 hans  wheel  6 Mar  5 12:55 /tmp/foo

Even after I finish editing it and exit vi (:wq),
these two names for the inode exist.

This is the system vi, which is /usr/bin/vi, on 10.5.8.
What is this /private directory for?

Jan


___
macports-users mailing list
macports-users@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-users

Re: [MacPorts] #46947: sox: please update to @14.4.2

[Jan Stary]

On Feb 26 15:38:53, rai...@macports.org wrote:
> On 2015-02-26 15:19, Jan Stary wrote:
> > Going through the log of the build,
> > I see that it not only checks for the libraries
> > mentioned as dependencies in the Portfile,
> > but also checks for ncurses and libiconv.
> > 
> > I don't see them mentioned anywhere in SoX;
> > is this somehow internal to macports?
> > 
> > The resulting sox binary does not depend on them.
> 
> The complete hierarchy of dependencies is checked to ensure that
> everything is in place as it should be.
> 
> You can see the hierarchy with the following command:
> 
> $ port rdeps sox

The following ports are dependencies of sox @14.4.2_0:

  lame
ncurses
libiconv
  gperf
  libid3tag
zlib
  xz
gettext
  expat
  libmad
pkgconfig
autoconf
  m4
  perl5
perl5.16
  gdbm
automake
libtool
  libmagic
  libpng
  libogg
  libopus
  libsndfile
flac
libvorbis
  opencore-amr
  opusfile
openssl
  twolame
  wavpack

In the build log, the following are checked:

DEBUG: lame 3.99.5_0  is the latest installed
DEBUG: ncurses 5.9_2  is the latest installed
DEBUG: libiconv 1.14_0  is the latest installed
DEBUG: libid3tag 0.15.1b_2  is the latest installed
DEBUG: zlib 1.2.8_0  is the latest installed
DEBUG: libmad 0.15.1b_3  is the latest installed
DEBUG: libmagic 5.22_0  is the latest installed
DEBUG: libpng 1.6.16_0  is the latest installed
DEBUG: libogg 1.3.2_1  is the latest installed
DEBUG: libopus 1.1_0  is the latest installed
DEBUG: libsndfile 1.0.25_0  is the latest installed
DEBUG: flac 1.3.1_2  is the latest installed
DEBUG: libvorbis 1.3.4_0  is the latest installed
DEBUG: opencore-amr 0.1.3_0  is the latest installed
DEBUG: opusfile 0.6_1  is the latest installed
DEBUG: openssl 1.0.2_0  is the latest installed
DEBUG: twolame 0.3.13_1  is the latest installed
DEBUG: wavpack 4.70.0_1  is the latest installed


Why is it then that e.g. gperf, xz, gettext, expat etc
are not checked in the "complete hierarchy of dependencies"?

Full log below.

Jan


DEBUG: Changing to port directory: /Users/hans/ports/audio/sox
DEBUG: OS darwin/9.8.0 (Mac OS X 10.5) arch i386
DEBUG: adding the default universal variant
DEBUG: Reading variant descriptions from 
/opt/local/var/macports/sources/rsync.macports.org/release/ports/_resources/port1.0/variant_descriptions.conf
DEBUG: Running callback portconfigure::add_automatic_compiler_dependencies
DEBUG: Finished running callback 
portconfigure::add_automatic_compiler_dependencies
DEBUG: Running callback portbuild::add_automatic_buildsystem_dependencies
DEBUG: Finished running callback 
portbuild::add_automatic_buildsystem_dependencies
DEBUG: Attempting ln -sf 
/opt/local/var/macports/build/_Users_hans_ports_audio_sox/sox/work 
/Users/hans/ports/audio/sox/work
DEBUG: changing euid/egid - current euid: 0 - current egid: 0
DEBUG: egid changed to: 504
DEBUG: euid changed to: 505
DEBUG: Starting logging for sox
DEBUG: epoch: in tree: 0 installed: 0
DEBUG: lame 3.99.5_0 exists in the ports tree
DEBUG: lame 3.99.5_0  is the latest installed
DEBUG: lame 3.99.5_0  is active
DEBUG: Merging existing variants '' into variants
DEBUG: new fully merged portvariants: 
DEBUG: Changing to port directory: 
/opt/local/var/macports/sources/rsync.macports.org/release/ports/audio/lame
DEBUG: OS darwin/9.8.0 (Mac OS X 10.5) arch i386
DEBUG: adding the default universal variant
DEBUG: Reading variant descriptions from 
/opt/local/var/macports/sources/rsync.macports.org/release/ports/_resources/port1.0/variant_descriptions.conf
DEBUG: Running callback portconfigure::add_automatic_compiler_dependencies
DEBUG: Finished running callback 
portconfigure::add_automatic_compiler_dependencies
DEBUG: Running callback portbuild::add_automatic_buildsystem_dependencies
DEBUG: Finished running callback 
portbuild::add_automatic_buildsystem_dependencies
DEBUG: No need to upgrade! lame 3.99.5_0 >= lame 3.99.5_0
DEBUG: epoch: in tree: 0 installed: 0
DEBUG: ncurses 5.9_2 exists in the ports tree
DEBUG: ncurses 5.9_2  is the latest installed
DEBUG: ncurses 5.9_2  is active
DEBUG: Merging existing variants '' into variants
DEBUG: new fully merged portvariants: 
DEBUG: Changing to port directory: 
/opt/local/var/macports/sources/rsync.macports.org/release/ports/devel/ncurses
DEBUG: OS darwin/9.8.0 (Mac OS X 10.5) arch i386
DEBUG: adding the default universal variant
DEBUG: Reading variant descriptions from 
/opt/local/var/macports/sources/rsync.macports.org/release/ports/_resources/port1.0/variant_descriptions.conf
DEBUG: Running callback portconfigure::add_automatic_compiler_dependencies
DEBUG: Finished running callback 
portconfigure::add_automatic_compiler_dependencies
DEBUG: Running callback portbuild::add_automatic_buildsystem_dependencies
DEBUG: Finished running callback 
portbuild::add_a

Re: [MacPorts] #46947: sox: please update to @14.4.2

[Jan Stary]

Going through the log of the build,
I see that it not only checks for the libraries
mentioned as dependencies in the Portfile,
but also checks for ncurses and libiconv.

I don't see them mentioned anywhere in SoX;
is this somehow internal to macports?

The resulting sox binary does not depend on them.

Jan


___
macports-users mailing list
macports-users@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-users

libpqxx on MacOSX 10.5.8

[Jan Stary]

This is MacOSX 10.5.8/i386 using MacPorts 2.3.3
Darwin mac.stare.cz 9.8.0 Darwin Kernel Version 9.8.0: Wed Jul 15
16:55:01 PDT 2009; root:xnu-1228.15.4~1/RELEASE_I386 i386

I am trying to install databases/libpqxx.
The build fails with main.log saying (full log below):

:info:build make[3]: Entering directory 
`/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_ports_databases_libpqxx/libpqxx/work/libpqxx-4.0.1/include/pqxx'
:info:build make[3]: *** No rule to make target `config-internal-compiler.h', 
needed by `all-am'.  Stop.
:info:build make[3]: Leaving directory 
`/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_ports_databases_libpqxx/libpqxx/work/libpqxx-4.0.1/include/pqxx'
:info:build make[2]: *** [all] Error 2
:info:build make[2]: Leaving directory 
`/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_ports_databases_libpqxx/libpqxx/work/libpqxx-4.0.1/include/pqxx'
:info:build make[1]: *** [all-recursive] Error 1
:info:build make[1]: Leaving directory 
`/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_ports_databases_libpqxx/libpqxx/work/libpqxx-4.0.1/include'
:info:build make: *** [all-recursive] Error 1
:info:build make: Leaving directory 
`/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_ports_databases_libpqxx/libpqxx/work/libpqxx-4.0.1'
:info:build Command failed:  cd 
"/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_ports_databases_libpqxx/libpqxx/work/libpqxx-4.0.1"
 && /usr/bin/make -j2 -w all 
:info:build Exit code: 2
:error:build org.macports.build for port libpqxx returned: command execution 
failed
:debug:build Error code: CHILDSTATUS 92730 2
:debug:build Backtrace: command execution failed
while executing
"system -nice 0 $fullcmdstring"
("eval" body line 1)
invoked from within
"eval system $notty $nice \$fullcmdstring"
invoked from within
"command_exec build"
(procedure "portbuild::build_main" line 8)
invoked from within
"portbuild::build_main org.macports.build"
("eval" body line 1)
invoked from within
"eval $procedure $targetname"
:info:build Warning: targets not executed for libpqxx: org.macports.activate 
org.macports.build org.macports.destroot org.macports.install
:notice:build Please see the log file for port libpqxx for details:

/opt/local/var/macports/logs/_opt_local_var_macports_sources_rsync.macports.org_release_ports_databases_libpqxx/libpqxx/main.log


Not having config-internal-compiler.h seems like a compiler issue.

$ cc -v
Using built-in specs.
Target: i686-apple-darwin9
Configured with: /var/tmp/gcc/gcc-5493~1/src/configure
--disable-checking -enable-werror --prefix=/usr --mandir=/share/man
--enable-languages=c,objc,c++,obj-c++
--program-transform-name=/^[cg][^.-]*$/s/$/-4.0/
--with-gxx-include-dir=/include/c++/4.0.0 --with-slibdir=/usr/lib
--build=i686-apple-darwin9 --with-arch=apple --with-tune=generic
--host=i686-apple-darwin9 --target=i686-apple-darwin9
Thread model: posix
gcc version 4.0.1 (Apple Inc. build 5493)

The log also says
:debug:main compiler clang blacklisted because it's not installed or it doesn't 
work

Is this related? Or am I missing something obvious?
I haven't found any libpqxx issues in trac.

Jan



version:1
:debug:main epoch: in tree: 0 installed: 0
:debug:main pkgconfig 0.28_0 exists in the ports tree
:debug:main pkgconfig 0.28_0  is the latest installed
:debug:main pkgconfig 0.28_0  is active
:debug:main Merging existing variants '' into variants
:debug:main new fully merged portvariants: 
:debug:main Changing to port directory: 
/opt/local/var/macports/sources/rsync.macports.org/release/ports/devel/pkgconfig
:debug:main OS darwin/9.8.0 (Mac OS X 10.5) arch i386
:debug:main adding the default universal variant
:debug:main Reading variant descriptions from 
/opt/local/var/macports/sources/rsync.macports.org/release/ports/_resources/port1.0/variant_descriptions.conf
:debug:main Running callback portconfigure::add_automatic_compiler_dependencies
:debug:main Finished running callback 
portconfigure::add_automatic_compiler_dependencies
:debug:main Running callback portbuild::add_automatic_buildsystem_dependencies
:debug:main Finished running callback 
portbuild::add_automatic_buildsystem_dependencies
:debug:main No need to upgrade! pkgconfig 0.28_0 >= pkgconfig 0.28_0
:debug:main epoch: in tree: 0 installed: 0
:debug:main libiconv 1.14_0 exists in the ports tree
:debug:main libiconv 1.14_0  is the latest installed
:debug:main libiconv 1.14_0  is active
:debug:main Merging existing variants '' into variants
:debug:main new fully merged portvariants: 
:debug:main Changing to port directory: 
/opt/local/var/macports/sources/rsync.macports.org/release/ports/textproc/libiconv
:debug:main OS darwin/9.8.0 (Mac OS X 10.5) arch i386
:debug:main Reading variant descriptions fro

Re: FOR FUTURE REFERENCE: when rsync.macports.org is down hard...

[Jan Stary]

> > You will be using the mirror until you revert your changes. I would restore 
> > the default configuration so you don't get caught mistakenly thinking that 
> > 'rsync.macports.org' is down when it's your mirror that went down!

On the contrary, you should be using
a mirror close to you for regular operation.


___
macports-users mailing list
macports-users@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-users

Re: install a por

[Jan Stary]

On Sep 27 09:53:02, allber...@gmail.com wrote:
> On Sat, Sep 27, 2014 at 6:59 AM, Jan Stary  wrote:
> 
> > Generaly, I find the precompiled defaults quite sensible
> > in most of the packaging systems, having subpackages/flavors/variants etc.
> > it surprises me that you "always" need to compile the port yourself.
> >
> Linux-like package systems tend to split things up so you can add
> functionality with plug-in ports, at a cost in maintainability of the
> package system. Build from source setups (pkgsrc/ports) tend to use build
> options/variants instead, and the packages become less useful as a result.

I must be missing your point. What's a "linux-like" package system
as opposed to a "build-from-port" system? Every package built from a port.
How does using options/variants of a port make the resulting package
less usefull (then having a lot of separate packages).

___
macports-users mailing list
macports-users@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-users

Re: install a por

[Jan Stary]

On Sep 23 10:57:22, allber...@gmail.com wrote:
> On Tue, Sep 23, 2014 at 10:55 AM, Jan Stary  wrote:
> > Have a look at OpenBSD's pkg_add(1)
>
> pkg is great if you can get away with defaults for everything. I always
> find myself forced into ports


Putting back the context that you stripped:

On Sep 05 16:48:44, allber...@gmail.com wrote:
> >> I've used FreeBSD's port system for ages, and yeah,
> >> the Mac beats it hands down.
> >
> > Well, it is very good but I feel the FBSD's is just as good. And AFAIK the
> > former is based/inspired on the latter, or am I mistaken?
> 
> MacPorts is based on the *BSD pkgsrc/ports system, but greatly improved; it
> took years for BSD ports to come up with a reasonable way to handle
> upgrading ports, and `port upgrade outdated` still handles cases that
> `portupgrade` and `portmaster -a` don't (checking for manual upgrade
> actions in /usr/ports/UPDATING is still essential). I'm just getting back
> into the FreeBSD world and ports still feels rather primitive after
> MacPorts.

Have a look at OpenBSD's pkg_add(1).
My point being specifically 'pkg_add -u'
which handles the updates _very_ well.

> pkg is great if you can get away with defaults for everything.
> I always find myself forced into ports

The difference between being happy with the precompiled package
and finding oneself in the need to recompile the port with some option
is not particular to pkg_add, macports, or any other packaging system:
the same situation can arise in any of those, depending just on
whether the packager likes the same defaults that you like.

Generaly, I find the precompiled defaults quite sensible
in most of the packaging systems, having subpackages/flavors/variants etc.
it surprises me that you "always" need to compile the port yourself.

Jan

___
macports-users mailing list
macports-users@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-users

Re: install a por

[Jan Stary]

On Sep 05 16:48:44, allber...@gmail.com wrote:
> On Fri, Sep 5, 2014 at 4:43 PM, Alejandro Imass  wrote:
> 
> > On Fri, Sep 5, 2014 at 4:36 PM, Dave Horsfall  wrote:
> >
> >> On Fri, 5 Sep 2014, Alejandro Imass wrote:
> >> > Yeah MacPorts is the most awesome piece of software you will ever have
> >> > on your Mac. It's very easy, friendly and robust.
> >>
> >> I've used FreeBSD's port system for ages, and yeah, the Mac beats it hands
> >> down.
> >
> >
> > Well, it is very good but I feel the FBSD's is just as good. And AFAIK the
> > former is based/inspired on the latter, or am I mistaken?
> >
> 
> MacPorts is based on the *BSD pkgsrc/ports system, but greatly improved; it
> took years for BSD ports to come up with a reasonable way to handle
> upgrading ports, and `port upgrade outdated` still handles cases that
> `portupgrade` and `portmaster -a` don't (checking for manual upgrade
> actions in /usr/ports/UPDATING is still essential). I'm just getting back
> into the FreeBSD world and ports still feels rather primitive after
> MacPorts.

Have a look at OpenBSD's pkg_add(1).

___
macports-users mailing list
macports-users@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-users

Re: eveyshi.sty is missing from my TeX installation

[Jan Stary]

> http://trac.macports.org/wiki/TeXLivePackages
> The above indicates ms is part of texlive-latex-recommended.

Thanks, the above link is what i was missing.

Jan

___
macports-users mailing list
macports-users@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-users

eveyshi.sty is missing from my TeX installation

[Jan Stary]

I am getting the following error while trying to compile a LaTeX file:

! LaTeX Error: File `everyshi.sty' not found.

I have the following texlive-* package installed:

texlive-basic  @34245_0+doc 
texlive-bin@2014_1+x11 
texlive-common @2014_0 
texlive-lang-czechslovak   @34201_0+doc 
texlive-latex  @34192_0+doc 
texlive-pictures   @34010_0+doc 

Can someone please advise me on which of the other texlive
packages I need to install to have thr everyshi.sty style?

Thank you

Jan


___
macports-users mailing list
macports-users@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-users

Re: Lost "port" command

[Jan Stary]

On May 03 12:27:18, billc_li...@greenbuilder.com wrote:
> I installed a non-MacPorts package on my server the other day -
> WordPress command line interface (wp-cli) which uses the "wp"
> command.  It's working properly.
> 
> But I just went to do my regular updates using MacPorts, and I've
> lost my "port" command.  I'm getting "command not found".

Are you sure this installation did not fuck up your PATH?
Some insane installations do.

> How do I (a) re-establish the port command

It is most probably still there, just not in your PATH.
Can you run /opt/local/bin/port ?

> and (b) keep the wp command?

Install this software into /usr/local (or somewhere)
and set your PATH accordingly. Better yet, create
a proper macport of this software,
then install it via macports.

___
macports-users mailing list
macports-users@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-users

Re: port command & arguments

[Jan Stary]

> > At this point, one could tell that you conme from linux
> > even if you hadn't said so .
> 
> So? What's the point? What if I had suggested reading the table from a plist?

"I don't remember the names of these commands.
Please change your utility so that it lets me
specify a table that replaces these command names
with some other command names that I like better
(because that's what some other utility on some
other system is calling them)".

Are you even serious? If you can't be bothered
to remember the seven or so command names,
just write yourself some shell wrapper
around calling them something else,
as opposed to imposing needless cruft upon others.


> > > all of ls's options without referring to the docs :)
> > 
> > So why do you care about remembering port's options without the docs?
> 
> Please reread my remark, paying special attention
> to both ends of the part I quoted.

You are not using _all_ of ports options/commands, are you.
You are using about seven of them; remember their names.
There, solved.

___
macports-users mailing list
macports-users@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-users

Re: port command & arguments

[Jan Stary]

On Apr 08 09:00:24, rjvber...@gmail.com wrote:
> These days I spend my time switching back and forth between Linux/Debian and 
> OS X. The various package management tools I use on the former (apt, apt-get, 
> aptitude) all have a very similar syntax, but port has a number of 
> just-or-completely different command names. The one that I mix up most is 
> info vs. show, but I rarely get the commands for listing dependencies right 
> at the first try either.
> I've created a duplicate of the action_array's info entry so that I can do 
> 'port show', but how possible would it be to create aliases?

You can easily create aliases in your shell,
without any need to touch 'port'.

> (One could even think of a table that's read from file...)

At this point, one could tell that you conme from linux
even if you hadn't said so .

> I admit, my memory is no longer what it used to be,
> but nowadays I don't really care anymore if I can master
> all of ls's options without referring to the docs :)

So why do you care about remembering port's options without the docs?

___
macports-users mailing list
macports-users@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-users

Re: Incorrect $PATH value for root user

[Jan Stary]

On Apr 11 07:55:47, h...@stare.cz wrote:
> On Apr 10 18:48:01, vit...@yandex.ru wrote:
> > Yes, but MacPorts can control this.
> > Instead of specifying "export PATH=/opt/local/bin:/opt/local/sbin:$PATH"
> > in ~/.bash_profile it can (and should) specify it system-wide
> > in /etc/bashrc
> 
> Absolutely not. Don't any program dare touch things in /etc.
> These are to be edited manually, under the assumption that
> you know what you are doing.

Also, the role of ~/.profile and ~/.shrc is not what you think.

___
macports-users mailing list
macports-users@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-users

Re: Incorrect $PATH value for root user

[Jan Stary]

On Apr 10 18:48:01, vit...@yandex.ru wrote:
> Yes, but MacPorts can control this.
> Instead of specifying "export PATH=/opt/local/bin:/opt/local/sbin:$PATH"
> in ~/.bash_profile it can (and should) specify it system-wide
> in /etc/bashrc

Absolutely not. Don't any program dare touch things in /etc.
These are to be edited manually, under the assumption that
you know what you are doing.

___
macports-users mailing list
macports-users@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-users

Re: [MacPorts] #42846: libsndfile @1.0.25 fails linking phase on mavericks 10.9.2

[Jan Stary]

> #42846: libsndfile @1.0.25 fails linking phase on mavericks 10.9.2
> -+
>   Reporter:  mtb19@??? |  Owner:  hans@???
>   Type:  defect  | Status:  new
>   Priority:  Normal  |  Milestone:
>  Component:  ports   |Version:  2.2.1
> Resolution:  |   Keywords:
>   Port:  libsndfile  |
> -+
> 
> Comment (by jwhowse4@???):
> 
>  The new configure.patch works for me on 10.8.5 but I am still troubled by
>  the fact it is using the wrong architecture...

So what exactly is your architecture
and what does your build_arch say in macports.conf?

___
macports-users mailing list
macports-users@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-users

Re: dvdrip confusion

[Jan Stary]

On Oct 28 00:21:19, macpo...@metaspasm.org wrote:
> On Mon, 28 Oct 2013, Brandon Allbery wrote:
> 
> > On Sun, Oct 27, 2013 at 5:12 PM, bunk3m  wrote:
> > 
> > >   /opt/local/libexec/perl5.12/sitebin/dvdrip
> > >   /opt/local/libexec/perl5.12/sitebin/dvdrip-exec
> > >   /opt/local/libexec/perl5.12/sitebin/dvdrip-master
> > >   /opt/local/libexec/perl5.12/sitebin/dvdrip-multitee
> > >   /opt/local/libexec/perl5.12/sitebin/dvdrip-progress
> > >   /opt/local/libexec/perl5.12/sitebin/dvdrip-replex
> > >   /opt/local/libexec/perl5.12/sitebin/dvdrip-splash
> > >   /opt/local/libexec/perl5.12/sitebin/dvdrip-splitpipe
> > >   /opt/local/libexec/perl5.12/sitebin/dvdrip-subpng
> > >   /opt/local/libexec/perl5.12/sitebin/dvdrip-thumb
> > >   /opt/local/libexec/perl5.12/sitebin/execflow
> > >
> > 
> > These are the programs you expect. They're not in /opt/local/bin because
> > you could also install dvdrip in perl5.14 and perl5.16 and probably some
> > other Perl versions... which one wins? What happens if they install
> > something different in a different Perl version? It's the price we pay for
> > supporting more than one concurrently installed version of Perl.
> > 
> > Yes, we have port select, but it rapidly becomes unwieldy when applied to
> > dependents of Perl. Instead you can add something to $PATH --- your choice
> > which one comes first, not MacPorts', which is why MacPorts doesn't do it
> > for you --- or symlink them somewhere on $PATH, as you prefer.
> >
> 
> How about putting a note in the Portfile?  I don't recall seeing any mention 
> of
> manual configuration during the install.

The user is not supposed to be reading the Portfile.


___
macports-users mailing list
macports-users@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-users

Re: dvdrip confusion

[Jan Stary]

On Oct 27 17:12:56, bun...@gmail.com wrote:
>sudo port content dvdrip shows:
> 
>  /opt/local/libexec/perl5.12/sitebin/dvdrip
>  /opt/local/libexec/perl5.12/sitebin/dvdrip-exec
>  /opt/local/libexec/perl5.12/sitebin/dvdrip-master
>  /opt/local/libexec/perl5.12/sitebin/dvdrip-multitee
>  /opt/local/libexec/perl5.12/sitebin/dvdrip-progress
>  /opt/local/libexec/perl5.12/sitebin/dvdrip-replex
>  /opt/local/libexec/perl5.12/sitebin/dvdrip-splash
>  /opt/local/libexec/perl5.12/sitebin/dvdrip-splitpipe
>  /opt/local/libexec/perl5.12/sitebin/dvdrip-subpng
>  /opt/local/libexec/perl5.12/sitebin/dvdrip-thumb
>  /opt/local/libexec/perl5.12/sitebin/execflow

These are the binaries of dvdrip.
If you symlink them to /opt/local/bin
or add /opt/local/libexec/perl5.12/sitebin/ to your PATH,
everything should work as expected. Does it?

>  /opt/local/share/doc/dvdrip/COPYRIGHT
>  /opt/local/share/doc/dvdrip/Changes
>  /opt/local/share/doc/dvdrip/Changes.0.46
>  /opt/local/share/doc/dvdrip/Credits
>  /opt/local/share/doc/dvdrip/README
>  /opt/local/share/doc/dvdrip/TODO

Have you read the README? Does it mention this situation,
i.e. binaries not in PATH that need to be symlinked?
If it doesn't, it probably should, right?

>  /opt/local/share/perl5.12/siteman/man1/dvdrip-progress.1pm
>  /opt/local/share/perl5.12/siteman/man1/dvdrip-splitpipe.1pm
>  /opt/local/share/perl5.12/siteman/man1/dvdrip.1pm
>  /opt/local/share/perl5.12/siteman/man3/AE.3pm
>  /opt/local/share/perl5.12/siteman/man3/...

Similar situation as with the binaries: you should add
/opt/local/share/perl5.12/siteman/ to your MANPATH.
And the port message should mentions that.
See manpath(1).


On Oct 28 00:03:36, allber...@gmail.com wrote:
> 
> These are the programs you expect. They're not in /opt/local/bin because
> you could also install dvdrip in perl5.14 and perl5.16 and probably some
> other Perl versions... which one wins?

Do we really have other versions of dvdrip?
The Portfile says explicitly it depends on

port:p5.12-libintl-perl
port:transcode \
port:p5.12-gtk2

> It's the price we pay for
> supporting more than one concurrently installed version of Perl.

Should a message be displayed to the user
after installing such a port? In the same situation
(many possible pythons), OpenBSD's port system says


  Information for inst:python-2.7.5

  Install notice:
  If you want to use this package as your default system python, as root
  create symbolic links like so (overwriting any previous default):
ln -sf /usr/local/bin/python2.7 /usr/local/bin/python
ln -sf /usr/local/bin/python2.7-2to3 /usr/local/bin/2to3
ln -sf /usr/local/bin/python2.7-config /usr/local/bin/python-config
ln -sf /usr/local/bin/pydoc2.7 /usr/local/bin/pydoc


___
macports-users mailing list
macports-users@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-users

tmux needs an older file on 10.4.11

[Jan Stary]

I am trying to build sysutils/tmux on MacOSX 10.4.11
It fails because 10.4.11 (Darwin 8.11.0) does not have
libproc.h that is included by tmux's osdep-darwin.c:

  osdep-darwin.c:22:21: error: libproc.h: No such file or directory

This problem has been encountered before,
and there is even a known workaround.
use an older version of osdep-darwin.c

http://sourceforge.net/mailarchive/forum.php?thread_name=51A035A8.6090504%40gmail.com&forum_name=tmux-users

I would like to prepare a diff to the tmux Portfile
so that it builds on my 10.4.11, but I am not sure
what is the right way to do this.

Does macports have the ability to say, in a Portfile,

  "if we are pre-10.5, replace osdep-darwin.c with
  git checkout c1b994852594b23b7443e01e05257c991684ba4e -- osdep-darwin.c" ?

Or would it be better to just hold a copy of that version of the file
in the port's files/, and conditionally use it on pre-10.5?

Jan

___
macports-users mailing list
macports-users@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-users

Re: homebrew and macports together?

[Jan Stary]

On Jul 04 09:44:06, rai...@krugs.de wrote:
> Hi
> 
> I am using homebrew at the moment, but there are certain packges, which
> are not on homebrew (e.g. awesome and kde apps).

Create a homebrew port of awesome.

That way, not only will you get what you wanted,
but everyone will benefit from the fruits of your labor.

___
macports-users mailing list
macports-users@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-users

Re: Suggestion

[Jan Stary]

On Jun 11 07:53:22, pixi...@macports.org wrote:
> 
> On Jun 11, 2013, at 6:46 AM, Jan Stary wrote:
> 
> > On May 28 21:36:58, jon...@hep.phy.cam.ac.uk wrote:
> >> Hi,
> >> 
> >> On 28 May 2013, at 08:12 PM, Jean-François Caron  
> >> wrote:
> >> 
> >>> While download statistics might not be a good system, I do concur that 
> >>> MacPorts very much would benefit from having a "discovery" mechanism by 
> >>> which users find out about useful ports.  Searching is nice, but it's not 
> >>> discovery.  Some kind of "top ports" list (however implemented) would be 
> >>> useful, imho.
> >> 
> >> Personally, I fail to see how a 'top ports' list would tell me much. The 
> >> ports i find essential are likely very different from others, so i don't 
> >> see how using some sort of a list showing the most used ports would help 
> >> me in any way in choosing new ones to install. Some ports likely have a 
> >> low user base, but never less are critical to those that need them, such 
> >> as more esoteric ports from the science section.
> > 
> > +1
> > 
> > let's say it turns out people download firefox a lot.
> > then what?
> 
> Say we need/want to update a port that has many dependents; knowing the 
> install base of the dependents could help us determine the support 
> ramifications of different update approaches.

"determine the support ramifications
of different update approaches"?
What on Earth are you talking about?

> ie:

You mean "e.g."
http://www.imdb.com/title/tt0113161/

> moving apache2 install files to conform to porthier.

What does that mean, speicifically?
Is there a problem with the apache2 port?
Do apache2 install files need to be "moved"?
Why? Is there a ticket for this?


> Are 10 or 10,000 people likely to hit the MP mailing list
> asking what the bleep happened.

If there is a reason to change a port,
what does it matter how many users does the port have?

(Is this a "support ramification of an update approach"?)

___
macports-users mailing list
macports-users@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-users

Re: Suggestion

[Jan Stary]

On May 28 21:36:58, jon...@hep.phy.cam.ac.uk wrote:
> Hi,
> 
> On 28 May 2013, at 08:12 PM, Jean-François Caron  wrote:
> 
> > While download statistics might not be a good system, I do concur that 
> > MacPorts very much would benefit from having a "discovery" mechanism by 
> > which users find out about useful ports.  Searching is nice, but it's not 
> > discovery.  Some kind of "top ports" list (however implemented) would be 
> > useful, imho.
> 
> Personally, I fail to see how a 'top ports' list would tell me much. The 
> ports i find essential are likely very different from others, so i don't see 
> how using some sort of a list showing the most used ports would help me in 
> any way in choosing new ones to install. Some ports likely have a low user 
> base, but never less are critical to those that need them, such as more 
> esoteric ports from the science section.

+1

let's say it turns out people download firefox a lot.
then what?

> Maybe such a list might be of some limited interest to developers, so we know 
> which ports are most used, and perhaps more usefully those without users, but 
> beyond that i doubt such a list would tell us much or help users. What would 
> help users i think would be to have a much better search/browsing interface, 
> to allow them to browse available ports.
> 
> Chris
> 
> > 
> > I do like the idea of opt-inable call-home reporting about which ports are 
> > installed.  Even if a minority opts-in, it would be useful.  Ubuntu does a 
> > similar thing IIRC.  For non-end-users, it would also inform port 
> > maintainers about how many people depend on their work.
> > 
> > Jean-François
> > 
> > Begin forwarded message:
> > 
> >> Re: Suggestion
> > 
> > ___
> > macports-users mailing list
> > macports-users@lists.macosforge.org
> > https://lists.macosforge.org/mailman/listinfo/macports-users

> ___
> macports-users mailing list
> macports-users@lists.macosforge.org
> https://lists.macosforge.org/mailman/listinfo/macports-users

___
macports-users mailing list
macports-users@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-users

Re: link gmake to make (and also manpage)?

[Jan Stary]

On May 26 11:19:24, pengyu...@gmail.com wrote:
> Hi,
> 
> Besides manually link gmake to make (also manpage), is there a way in
> macports to like gmake to make?

Why would you want to do that?

>Also man gmake shows the following.
> Should it be updated?
> 
> COPYRIGHT
>Copyright (C) 1992, 1993, 1996, 1999, 2007 Free Software
> Foundation, Inc.  This file is part of GNU make.
> 
>GNU  Make  is free software; you can redistribute it and/or
> modify it under the terms of the GNU General Public License as
> published by the Free Software Foundation; either version 3 of the
> License, or (at
>your option) any later version.
> 
>GNU Make is distributed in the hope that it will be useful, but
> WITHOUT ANY WARRANTY; without even the implied warranty of
> MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
> General  Public
>License for more details.
> 
>You should have received a copy of the GNU General Public
> License along with this program.  If not, see
> http://www.gnu.org/licenses/.
> 
> 
> 
> GNU
> 22 August 1989
>MAKE(1)
> 
> 
> -- 
> Regards,
> Peng
> ___
> macports-users mailing list
> macports-users@lists.macosforge.org
> https://lists.macosforge.org/mailman/listinfo/macports-users
___
macports-users mailing list
macports-users@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-users

Re: Can't do anything in Terminal Due To Macports Installer Never Quitting

[Jan Stary]

On Mar 25 00:33:21, scottclau...@mac.com wrote:
> Hello,
> 
> After a recent update of Macports I now have the following constantly running 
> in Mountain Lion terminal:
> 
> # MacPorts Installer addition on 2009-11-22_at_17:22:04: adding an 
> appropriate PATH variable for use with MacPorts.
> export 
> PATH=/opt/local/bin:/opt/local/sbin:/usr/bin:/bin:/usr/sbin:/sbin:/usr/local/bin
> # Finished adapting your PATH environment variable for use with MacPorts.
> # export PATH=/usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin:/usr/local/bin
> # export PATH=usr/local/bin:/usr/local/sbin:/usr/local/mysql/
> ~
> # Setting PATH for MacPython 2.6
> # The orginal version is saved in .bash_profile.pysave
> PATH=/Library/Frameworks/Python.framework/Versions/2.6/bin:/usr/bin:/bin:/usr/sbin:/sbin:/usr/local/bin
> export PATH
> 
> ##
> # Your previous /Users/Scott/.bash_profile file was backed up as 
> /Users/Scott/.bash_profile.macports-saved_2009-11-22_at_17:22:04
> ##
> 
> # MacPorts Installer addition on 2009-11-22_at_17:22:04: adding an 
> appropriate PATH variable for use with MacPorts.
> export 
> PATH=/opt/local/bin:/opt/local/sbin:/usr/bin:/bin:/usr/sbin:/sbin:/usr/local/bin
> # Finished adapting your PATH environment variable for use with MacPorts.
> # export PATH=/usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin:/usr/local/bin
> # export PATH=usr/local/bin:/usr/local/sbin:/usr/local/mysql/

It seems you are using bash.
Can you show us your /.profile, ~/.shrc, ~/.bash_profile and ~/.bashrc ?

Anyway, does this mean that macports now fiddles with my ~/.profile?

Jan

___
macports-users mailing list
macports-users@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-users

Disable antivirus when building this port.

[Jan Stary]

While looking at various package's notes
(during the ongoing install notes debate),
I noticed a port with the following notes:

virtuoso has the following notes:
Disable antivirus when building this port.

Arguably, it is not of much use to the user
displaying this note _after_ the port has
been installed.

How do we generally deal with such a situation?
Surely the user is not supposed to play catch
with port(1)'s output. Should the port build
exit/pause with this note? Should the port
job recognize notes that need to displayed
_before_ the build even starts, display them
up front and pause?

BTW, why does the virtuoso port need
to have "the antivirus" dissabled?
(Whichever antivirus it may be.)

Jan

___
macports-users mailing list
macports-users@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-users

Re: Notes...that flash by and are gone...(was Re: any good audio/video editing apps in macports?)

[Jan Stary]

On Feb 26 22:01:36, ctrelea...@cogeco.ca wrote:
> At 11:56 PM +0100 2/26/13, Chris Jones wrote:
> > > A simple "notes happened above" message would be ideal.
> >>
>  Conversely, we'd be spewing twice as many messages
>  if the install isn't interrupted.
> >>>
> >>> Why? If the messages were _only_ printed at the end?
> >>
> >> Why move where we're printing them when a simple "hey, scroll
> >>up" will suffice?
> >
> >Not everyone has their scroll history set to a reasonable size (in
> >fact the default is often quite small) so if a lot of ports where
> >installed, it may not even be possible to scroll up enough to see
> >them... So I don't think you can just assume this will always
> >work.

It won't.

> >I think the messages should probably be printed at the end, in one
> >place. I don't particularly care either way if they are printed as
> >well when the port in question is installed, but would tend toward
> >yes, they should.
> 
> So, my observation and proposal generated a substantial volume of 
> discussion...
> 
> The good:  this seems to indicate that a number of people recognize
> the current situation is less-than-ideal.

Yes.

> The bad:  no clear consensus on how to improve.
> 
> For consideration:  it was a user's problem with the port kdenlive
> that prompted the discussion.  Of its 270 dependencies, 6 use Notes
> (aspell, dbus, ffmpeg, kdelibs4, hunspell and python27; thanks
> pixilla) or approximately 2%.  [1]  So, for a new user who comes
> here specifically to install kdenlive as their first--maybe
> only--port, it would be a miracle if they actually noticed ANY of
> these messages.

Yes. That is one part of the problem:

(I) The user does not even know that some of the installs
that happened above produced install messages he should read.

The second part is:

(II) Even if the user does know about the messages above,
he has no _convenient_ way to go read them:

(II.1) They are interspersed among all the other output.
 The user needs to _look_for_them_ in the other output.

(II.2) The messages exist after the install finishes in
 a. the scroll buffer of the terminal window where the install
   happened. It is suggested that the user scrolls this buffer,
   possibly back to package one. This means proper 'port install'
   functionality relies on the user's terminal window's scroll buffer
   being large enough (and it assumes the user is in a 'window'
   in the first place). That's just plain wrong.
 b. the 'notes' of the installed/updated packages.
To see those, it requires the user to take further action
(namely, run 'port notes' with the right package's names).
That's also less then ideal, and some packages don't even
use notes, they use ui_msg (which is another thing we need
to get rid of).

The solution I propose solves all af the above:
just print all the install notes at the end of the port run,
possibly followed by a line 'read the install notes above'.

It solves (I) because it's what the user sees
when the port job finishes.

It solves (II.1) because the notes are all in one place.

As for (II.2), if the messages fit one screen, which is
the majority of cases: just read them.
If they don't fit on screen (what would be an example?),
you have to either scroll back _BUT_ scroll back the few lines
that didn't fit the screen (as opposed to scrolling back
to package 7 of 270!) or run the port job through less
or tee or whatever and see the bottom of it (as opposed
to searching for it among other output).

Another possibility is to just inform the user that
certain packages have install notes, and simply name
those packages. 25 lines should be enough for that.

For comparison, the OpenBSD package system recognizes
'install messages' that get printed at the bottom of
an install output, and 'package readmes' - longer texts
that are just mentioned to exist in /usr/local/doc/pkgname
at the bottom of the install output (example: the document
that comes with  a DB server describing how to set the DB up).


> Using a TextEdit window--for the 2% of ports needing to pass
> post-activation information to the user--would act much like the
> ReadMe window many .dmg installers finish with.

God, no. Do not _open_a_window_ to display text.
(1) It's completely unneeded.
(2) It won't work for remote installs.

> To be clear, I was
> suggesting one window containing all the notes from that install
> run. It won't happen that often but it sure highlights important
> info for new users.

That's desirable, but not via _opening_a_window_.
It's text for christsakes! Printf it out and be done with it.

> For MacPorts experts, a command line switch and/or configuration
> setting could suppress these abominations.  (Jan, please don't
> bother reiterating your opinion...you've made yourself crystal
> clear.  I'd like to hear from others.)

Ah, too late; sorry :-)
However, I believe I have only made the argument crystal clear above.

> T

Re: Notes...that flash by and are gone...(was Re: any good audio/video editing apps in macports?)

[Jan Stary]

On Feb 26 15:37:45, sewebs...@gmail.com wrote:
> On Tue, Feb 26, 2013 at 3:04 PM, Jan Stary  wrote:
> > I agree, in such situations we cannot do anything.
> > How does that make install messages interspersed
> > in various places in the install output better
> > than having them at one place?
> >
> 
> Perhaps it is minor, but because if you are watching the install you
   ^^^
You mean you launch 'port install' and watch it
line by line, playing the game of
read-it--before-it-scrolls-away?
Are you serious?

> can still see the notes get printed,

Possibly, if you spend the entire time an install
takes to run staring into the screen. Laughable.

> before your system crashes.

What's with the crashes? I am talking about
a normal routine port job.

___
macports-users mailing list
macports-users@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-users

Re: Notes...that flash by and are gone...(was Re: any good audio/video editing apps in macports?)

[Jan Stary]

On Feb 26 17:35:45, jer...@lavergne.gotdns.org wrote:
> > And even if he wanted to kill the ongoing installation,
> > why would he close the window, as opposed to simply
> > killing the process in that (terminal) window?
> 
> There's a button there, the user can hit it.
> 
> > To lose any possibility of looking at the output?
> 
> "It was an accident!" Tell me you've never accidentally closed anything in 
> your life.

Jesus, yes.

Are you avoiding it on purpose?
The user accidentally closes the window;
the system reboots; you forgot - the whole
computer crashes.

I agree, in such situations we cannot do anything.
How does that make install messages interspersed
in various places in the install output better
than having them at one place?


___
macports-users mailing list
macports-users@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-users

Re: Notes...that flash by and are gone...(was Re: any good audio/video editing apps in macports?)

[Jan Stary]

On Feb 26 23:22:46, h...@stare.cz wrote:
> On Feb 26 16:56:23, jer...@lavergne.gotdns.org wrote:
> > > Surely the install process does some maintenance at its exit
> > > (read: catches signals), and can spit out those messages even
> > > if it is exiting due to being interrupted (as opposed to
> > > finishing without error).
> > 
> > If MacPorts is quitting because the user is closing the window
> > mid-process or the computer is rebooting, what difference will
> > any messages make?
> 
> What? Whay would the user be closing a window where an installation
> he started is running?

And even if he wanted to kill the ongoing installation,
why would he close the window, as opposed to simply
killing the process in that (terminal) window?
To lose any possibility of looking at the output?

Even if you kills the installation,
you still want to see the install messages
of everything that got istalled so far.


___
macports-users mailing list
macports-users@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-users

Re: Notes...that flash by and are gone...(was Re: any good audio/video editing apps in macports?)

[Jan Stary]

On Feb 26 16:56:23, jer...@lavergne.gotdns.org wrote:
> > Surely the install process does some maintenance at its exit
> > (read: catches signals), and can spit out those messages even
> > if it is exiting due to being interrupted (as opposed to
> > finishing without error).
> 
> If MacPorts is quitting because the user is closing the window
> mid-process or the computer is rebooting, what difference will
> any messages make?

What? Whay would the user be closing a window where an installation
he started is running?

Of course, if that is the case, or even a restart,
then there will be no install messages either way;
that's not what we're talking about.

> If it alone was being killed by the user

(or anything)

> then we'd be flooding the screen with notes,

What "flooding"? We would display the install
messages of the package that got installed so far.

> when something (quite possibly displayed on the screen)
> made the user want to kill the command.

Fair point. But he can scroll back to that too, right?

Also, the majority (IMHO) of the port jobs, the typical run,
is just that stuff gets installed/updated and that's it.
So let's let the user have all the install messages in
one convenient place for_such_typical_run, and have him
scroll back _if_ there were errors. Right?

> A simple "notes happened above" message would be ideal.

No, it's not ideal. That's my whole point.
Having to scroll back and actively search
for what packages wanted to tell me is not ideal.

> >> Conversely, we'd be spewing twice as many messages
> >> if the install isn't interrupted.
> > 
> > Why? If the messages were _only_ printed at the end?
> 
> Why move where we're printing them when a simple "hey, scroll up"
> will suffice?

Yes, it will _suffice_.
It will also suffice to write the logs and let the user read them
after every run, so why are we even printing the pkg messages?

> > Yes, the user can scroll up and look for those messages.
> > This inconvenience (not that serious of course) is my
> > whole point here: that the user has to scrool and look
> > for it.
> 
> If there are more than 24 lines of notes, the user is already scrolling up.
> A simple message alerting you to the need to scroll up address the real
> concern (not knowing anything happened until after having scroll up
> --now you know before scrolling).

The "problem" here is not scrolling (of course it takes nothing
to scroll up), but that the messages from the various packages
are dispersed all over the output and the user has to search
for them in the whole output.

The modification I am proposing is SOLELY to have them
at one place (namely, the bottom; where else).

> > What duplicate notes?
> 
> I was thinking we couldn't print notes solely at the end
> as we'd be pummeling the screen when the program exits.

What "pumelling the screen"?
Why are we printing the messages at all then?
If they are printed after each individual package,
there is not any less of them.

___
macports-users mailing list
macports-users@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-users

Re: [meta] reply to the list

[Jan Stary]

On Feb 26 15:27:57, spooky1...@gmail.com wrote:
> On Tue, Feb 26, 2013 at 09:41:18PM +0100, Jan Stary wrote:
> > 
> > Increasingly often, I see people replying To: the original
> > poster, with Cc: to the list. Such a message does reach
> > the recipients, but
> > 
> > (1) it breaks the list functionality:
> > none of the List-* headers is present in the message.
> > Many people, me included, filter by sych headers.
> 
> There is a better way (with procmail, at least) that I use, which
> gets all list e-mail filtered to the mbox I set aside for the list,
> private responses to me in my own mbox, and replies to the list
> that are CC'd to me ONLY sent to the list.  I do not use List-
> headers---as you say, they aren't reliable.

I use procmail similarly, and the messages can indeed
be filtered by other ways too ("macports anywhere
in To: or Cc:"). But isn't one of the purposes of
the List-* headers to have a definite one line for that?
What else is List-Id for?

___
macports-users mailing list
macports-users@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-users

Re: Notes...that flash by and are gone...(was Re: any good audio/video editing apps in macports?)

[Jan Stary]

On Feb 26 16:34:07, jer...@lavergne.gotdns.org wrote:
> > The suggested 'port notes' works for a given package;
> > for example, if I run 'port install package', I can run
> > 'port note depof:package' after that and get all the notes,
> > in one place. But:
> > 
> > (1) this should happen automatically
> >as a part of the 'port install'.
> 
> Well, we shouldn't put the messages solely at the end because an install
> can be interrupted for any number of reasons.

Surely the install process does some maintenance at its exit
(read: catches signals), and can spit out those messages even
if it is exiting due to being interrupted (as opposed to
finishing without error).

> Upon retry, those packages are then already installed and will not
> re-emit their messages unless you explicitly ask for them.

Yes.

> Conversely, we'd be spewing twice as many messages
> if the install isn't interrupted.

Why? If the messages were _only_ printed at the end?

> I propose a simple counter be used instead of a list:
> if we encountered any notes during an install,
> we alert the user to scroll up and read the notes.

Yes, the user can scroll up and look for those messages.
This inconvenience (not that serious of course) is my
whole point here: that the user has to scrool and look
for it.

Isn't it trivial to cat all the install messages to a file,
and cat that file upon exit (succesful or not)?

> This avoids duplicate notes

What duplicate notes?

___
macports-users mailing list
macports-users@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-users

Re: Notes...that flash by and are gone...(was Re: any good audio/video editing apps in macports?)

[Jan Stary]

On Feb 26 15:44:12, jer...@lavergne.gotdns.org wrote:
> > There is nothing wrong with that;
> > apparently I need to re-read the port manpage.
> > 
> > However, this still requires an action of the user besides 'install';
> > I believe that the notes of the newly installed packages (if any)
> > should be displayed as a part of 'install' automatically.
> 
> A port's notes are printed as a package is installed.
> 
> This is just semantically different than the request to get them all printed 
> at once at the end of all operations.

Well, that's exactly the difference as I understood it
- there is currently no comfort way to get to the messages
of all the things that got installed in a 'port install' job
that just ended; the user needs to read and scan the whole
output; a bit of searching makes it easier of course,
but it would IMHO be desirable to have them all at the end
(and therefore in one place).

The suggested 'port notes' works for a given package;
for example, if I run 'port install package', I can run
'port note depof:package' after that and get all the notes,
in one place. But:

(1) this should happen automatically
as a part of the 'port install'.

(2) it is bit of typing if it's actually
port install one two three four five six
port notes depof:one depof:two depof:three ...

(3) as an extreme case, after 'port update outdated',
there is no 'port notes depof:outdated';
the only way to get to all the install messages
of everything that got installed or updated
in this 'port update outdated' run is to
scan through the whole output. Right?


Jan


___
macports-users mailing list
macports-users@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-users

[meta] reply to the list

[Jan Stary]

If you reply to a message to this list on this list
(as opposed to off-list), please reply To: the list.

Increasingly often, I see people replying To: the original
poster, with Cc: to the list. Such a message does reach
the recipients, but

(1) it breaks the list functionality:
none of the List-* headers is present in the message.
Many people, me included, filter by sych headers.

(2) it is redundant - the original poster
is subscribed to the list.

(Obviously, this is irrelevant to replies
that are willingly private and off-list.)

Thank you

Jan

___
macports-users mailing list
macports-users@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-users

Re: Notes...that flash by and are gone...(was Re: any good audio/video editing apps in macports?)

[Jan Stary]

On Feb 26 10:12:57, pixi...@macports.org wrote:
> On Feb 25, 2013, at 3:42 PM, Jan Stary wrote:
> 
> > The modification IMHO belongs to port(1) itself:
> > remember what was installed in this run, then
> > print out all the messages (as opposed to printing
> > every message just after the given port is installed),
> > so that they are in one place and the user doesn't
> > have to watch for it or scan the output.
> 
> Re-posting all the notes at the end of an install/upgrade run
> may not give all the details you are looking for.

Such as?

If there is notes for a package, it's because the package wants
to say something to the user; the installing user IMHO
is not 'looking for details' himself.


> What if all the dependencies were already installed
> and the current version?

Then none of them was installed in this run (no need),
and there is nothing to display.

> What is wrong with this current functionality for getting at the notes:
> $ port notes depof:kdenlive
> 
> or more complete:
> $ port notes rdepof:kdenlive
> 
> and less noisy:
> $ port notes rdepof:kdenlive | grep -v "has no notes."

There is nothing wrong with that;
apparently I need to re-read the port manpage.

However, this still requires an action of the user besides 'install';
I believe that the notes of the newly installed packages (if any)
should be displayed as a part of 'install' automatically.

___
macports-users mailing list
macports-users@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-users

Re: Notes...that flash by and are gone...(was Re: any good audio/video editing apps in macports?)

[Jan Stary]

On Feb 25 16:12:12, spooky1...@gmail.com wrote:
> Back way before I expected to be able to return.  Strange.
> 
> On Mon, Feb 25, 2013 at 08:13:39PM +0100, Jan Stary wrote:
> > On Feb 25 07:42:04, spooky1...@gmail.com wrote:
> > > On Mon, Feb 25, 2013 at 02:05:07PM +0100, Jan Stary wrote:
> > > > On Feb 24 20:50:52, ctrelea...@cogeco.ca wrote:
> > > 
> > > > > 3) Deliver the messages in another manner:  eg, cause them to open
> > > > > in TextEdit or a browser window.
> > > > 
> > > > That needs the capability to "open a window".
> > > > No way.
> > > 
> > > There may be something I'm missing here, but why "No way" ?
> > 
> > Because it wants to open new windows.
> 
> Yeah, you said that, and someone else asked about using it in a non-GUI
> environment.  Ok, but it doesn't HAVE to be a GUI version.  Switching
> it from using a text widget and scrollbars would mean changing a few
> lines of code (e.g., instead of "$w.t insert end $message\n" d
> just use "puts $message").  If the idea is to add it at the end, so it
> doesn't scroll right past whatever the user's scrollback buffer is set
> to, that's just a few more lines:
> 
> for each text sent:
> 
>lappend mlist $message
> 
> and later, when it's all finished (or crashes):
> 
>foreach line $mlist { puts $line }

You still don't get it, do you.

> > Running a server application that opens new windows
> > just to _display_a_few_lines_of_text_ ??
> 
> First, I was told that it's often a lot more than a "few" lines of text.
> But second, it seemed like the easiest way to do it.  You start up the
> server with a one-line command, which then accepts the text to display
> via a simple Tcl socket command from the client (puts $chan $message)
> and displays it.  Wow...very difficult.  Yeah, very tough to code.  :-)

Repaet after me:
if you want to display some text in a port(1) job,
do not "start up a server" for it.

> But there's another point here, and that is, with one app running to
> display the text (whether in a text widget or just printing to a
> terminal, perhaps using less as a pager, you'd have to keep some type
> of interface to it open.  A simple second app that sends it the text
> to display, and is its own one-line (or longer for longer text) command,
> seems, to me, to be the easiest way to implement it:
> 
>add_text.tcl normal "you need to do something now to make this work"
> 
> OR in a GUI, if you want larger, bold, red text to emphasize something,
> 
>add_text.tcl boldred "you need to do something now to make this work"
> 
> I could add more than just a bold/red/larger option if needed, but that's
> what's in there right now.
> 
> > (Using various fonts, for sure.
> 
> Yep.  It's currently set up for Courier, but that's easy to change (two
> lines---one for normal and one for larger, bold, red text) set in the
> server app.
> 
> > But where's the piechart?
> 
> What pie chart are you referring to?  Nobody told me that was a
> requirement.
> 
> > Where is the XML, I ask.)
> 
> Same question for XML.  Nobody said anything about that to me.

I am genuinely not sure now whether you are trying
to be funny or actually are that thick.

> > How's about you just display all the packages messages
> > after the port(1) job finishes, and the user, uh, I don't know,
> > reads them?
> 
> You mean something like others and I were discussing both on-list
> and off-list earlier this morning, and also mentioned above?
> Yeah, in a text-only version, that would be, in my opinion for
> what it apparently is not worth crap here, would be the best
> way to do that.

Yes. Displaying a message would probably be
best done in text. Yes. With a printf. Yes.

> > Whether you have ever heard about the Keep It Simple, Stupid
> > principle before or not, you are trying to fsck it in the ear.
> 
> You consider 75 lines of code for both the client and the server
> (including all blank lines and comments---basically just
> "wc -l *" output) NOT simple?

No. I consider launching two totally unneeded
client-server processes not simple.

> Not only that, but the idea was to also keep the IMPLEMENTATION
> simple, too.  I think my idea would have done that quite well.

Your idea is stupid.


The modification IMHO belongs to port(1) itself:
remember what was installed in this run, then
print out all the messages (as opposed to printing
every message just after the given port is installed),
so that they are in one place and the user doesn't
have to watch for it or scan the output.

___
macports-users mailing list
macports-users@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-users

Re: Notes...that flash by and are gone...(was Re: any good audio/video editing apps in macports?)

[Jan Stary]

On Feb 25 08:57:09, ctrelea...@cogeco.ca wrote:
> At 2:05 PM +0100 2/25/13, Jan Stary wrote:
> >On Feb 24 20:50:52, ctrelea...@cogeco.ca wrote:
> >> At 5:23 PM -0600 2/24/13, Jim Graham wrote:
> >> >On Sun, Feb 24, 2013 at 11:03:54PM +, Chris Jones wrote:
> > > >> On 24 Feb 2013, at 10:59pm, Jim Graham  wrote:
> >[...]
> >> 3) Deliver the messages in another manner:  eg, cause them to open
> >> in TextEdit or a browser window.
> >
> >That needs the capability to "open a window".
> >No way.
> 
> Um, OS X includes this graphical user interface thingy.  We don't
> have to ignore it _all_ the time!

Which clearly is a reason to _display_text_ with a GUI.
Right.

We also have the say(1) command.
I'd like my install message in a southern Irish voice please.

> > > I think a few lines of Applescript
> >> would be enough to create a new window and display all the Notes
> >> messages from an install.  (We would even have the option to use rtf
> >> or html to format the messages to improve delivery.)
> >
> >No fucking way.
> 
> Interesting.  Which part offends you so much:  Applescript or formatting?

Opening new windows, rtf and hmtl.

> >How about: print all the meesages at the very end
> >of the whole install. That's how OpenBSD does it.
> 
> That would be an improvement as long as users aren't left hanging on
> cancelled or failed installs.

Display all the messages of all that has been installed,
whether the port(1) job as a whole finished successfully or not.
Of course.

An install that't "left hanging"
does nothing either way.

___
macports-users mailing list
macports-users@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-users

Re: Notes...that flash by and are gone...(was Re: any good audio/video editing apps in macports?)

[Jan Stary]

On Feb 25 11:18:38, spooky1...@gmail.com wrote:
> On Mon, Feb 25, 2013 at 07:56:13AM -0800, Bradley Giesbrecht wrote:
> > 
> > On Feb 25, 2013, at 5:42 AM, Jim Graham wrote:
> > 
> > > On Mon, Feb 25, 2013 at 02:05:07PM +0100, Jan Stary wrote:
> > >> On Feb 24 20:50:52, ctrelea...@cogeco.ca wrote:
> > > 
> > >>> 3) Deliver the messages in another manner:  eg, cause them to open
> > >>> in TextEdit or a browser window.
> > >> 
> > >> That needs the capability to "open a window".
> > >> No way.
> > > 
> > > There may be something I'm missing here, but why "No way" ?
> > 
> > Where would the window open for remote installs via ssh?
> 
> As long as Tcl/Tk is built as an X11 app, I would assume that it would be
> opened as any other X11 app would be opened remotely.

Would it be in color too?

___
macports-users mailing list
macports-users@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-users

Re: Notes...that flash by and are gone...(was Re: any good audio/video editing apps in macports?)

[Jan Stary]

On Feb 25 07:42:04, spooky1...@gmail.com wrote:
> On Mon, Feb 25, 2013 at 02:05:07PM +0100, Jan Stary wrote:
> > On Feb 24 20:50:52, ctrelea...@cogeco.ca wrote:
> 
> > > 3) Deliver the messages in another manner:  eg, cause them to open
> > > in TextEdit or a browser window.
> > 
> > That needs the capability to "open a window".
> > No way.
> 
> There may be something I'm missing here, but why "No way" ?

Because it wants to open new windows.

> I've already written a command-line pair of Tcl/Tk scripts
> that should work fine, and last night, e-mailed them to
> Craig (off-list) in a response to the post you're responding
> to.
> 
> It works like this:
> 
> First, there's a server app that opens a text widget in Tk, and listens
> on a port (by default, port 12345). When it receives a message, it
> displays it in the text window.  I wrote it with two fonts for the
> text:  {Courier 18 bold} (and a tag to make it red for stuff that needs
> to be stressed) and {Courier 16} for normal text.  An arg to the client
> determines which, and that is then sent to the server before the message
> itself.

Are you trolling or just high?
Running a server application that opens new windows
just to _display_a_few_lines_of_text_ ??

(Using various fonts, for sure.
But where's the piechart?
Where is the XML, I ask.)

> The client app can take the message text from either the second arg (the
> first is the text "mode" described above) OR from stdin.
> 
> The idea is, you start the server at the very beginning, a text widget
> (with a scrollbar and, if the autoscroll extension is included, the
> scrollbar will only show up if needed).  Then, when you have a message
> (say, "this is a text message") with an important header ("important
> header") you could do something like this (after starting the server
> at the beginning):
> 
> add_text.tcl boldred "important header"
> add_text.tcl normal "this is a text message"
> 
> It would also be trivial to modify the server to put a blank line between
> text messages, but last night, I was trying to finish up between
> thunderstorms

How's about you just display all the packages messages
after the port(1) job finishes, and the user, uh, I don't know,
reads them?

Whether you have ever heard about the Keep It Simple, Stupid
principle before or not, you are trying to fsck it in the ear.

___
macports-users mailing list
macports-users@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-users

Re: Notes...that flash by and are gone...(was Re: any good audio/video editing apps in macports?)

[Jan Stary]

On Feb 25 00:05:09, jer...@lavergne.gotdns.org wrote:
> Crown was a lovely autocorrect for cron

Crown job sounds a bit nasty though.

___
macports-users mailing list
macports-users@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-users

Re: Notes...that flash by and are gone...(was Re: any good audio/video editing apps in macports?)

[Jan Stary]

On Feb 24 20:50:52, ctrelea...@cogeco.ca wrote:
> At 5:23 PM -0600 2/24/13, Jim Graham wrote:
> >On Sun, Feb 24, 2013 at 11:03:54PM +, Chris Jones wrote:
> >> On 24 Feb 2013, at 10:59pm, Jim Graham  wrote:
> >
> >> There is nothing wrong with KDE, as long as you properly install the
> >> dependencies it requires. My reading of this rather long thread is all
> >> of the problems would have been avoided if the OP had followed the
> >> instructions as presented to them. You cannot blame KDE for the
> >> problems that arose because they didn't.
> >
> >But as the OP in question, I didn't KNOW about any of the KDE stuff
> >AT ALL.  I didn't know that I needed this, that, and the other bit.
> >I didn't know that I needed to run other stuff first, or that macports
> >does not actually install aoo of the dependent stuff for KDE as I'd
> >assumed it did.  The errors I saw were completely alien to me.  I'd
> >never run into stuff like that before.  So excuse me if I can't read
> >minds.  Oh, and I didn't install KDE.  It was installed by something
> >else (maybe it was kdenlive, maybe something a long time ago...I don't
> >know).
> 
> Jim likely missed some important info while installing kdenlive but
> it is easy to see how it happened.  If you look at the rdeps for
> kdenlive, there are _270_ lines!  I don't know how many of those
> dependencies use Notes to inform the user of some important fact or
> other.  I *do* know that they scroll by very quickly in the midst of
> what may be a long, unattended install.  Important information is
> interspersed amongst reams of output that requires no action.
> 
> Right now, some ports use basic text formatting to try to draw
> attention to these messages (lines of asterisks, etc).  That's good,
> but could we do more?
> 
> Options:
> 1) Make users acknowledge messages:  ie, "Press any key to proceed".
> (Shades of CPAN!)  My take:  please God, no!!!

No way.

> 2) Make such messages stand out more:  use more distinct visual cues
> such as colour or font.

No.

> Could definitely help but I don't know what
> is supported by all the versions of Terminal.  (Let alone other apps
> or remote connections.)  What do others think?

That still needs me to watch the terminal closely
as the installation progresses. No.

> 3) Deliver the messages in another manner:  eg, cause them to open
> in TextEdit or a browser window.

That needs the capability to "open a window".
No way.

> I think a few lines of Applescript
> would be enough to create a new window and display all the Notes
> messages from an install.  (We would even have the option to use rtf
> or html to format the messages to improve delivery.)

No fucking way.

> The user would
> essentially have an action list after the install.  Drawbacks:
> doesn't work for ssh-type connections to remote machines.  I think
> this could be very helpful

> Thoughts?

How about: print all the meesages at the very end
of the whole install. That's how OpenBSD does it.

___
macports-users mailing list
macports-users@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-users

Re: THANKS (WAS: Re: any good audio/video editing apps in macports?)

[Jan Stary]

On Feb 24 17:48:04, spooky1...@gmail.com wrote:
> On Mon, Feb 25, 2013 at 12:41:17AM +0100, Jan Stary wrote:
> 
> > 
> > That's not how macport's ports are installed.  You don't have to move
> > any icon anywhere.
> 
> No, of course you don't.  But as you already know, having read my post
> before commenting, I wasn't talking about macports installs for that
> small mention of ports downloaded from the 'Net.  And no, you
> don't have to move that little icon anywher there, either.  It's
> just a quick and convenient option for directly adding the app's
> listing into finder's Applications listing.  And as I added on that
> part, I don't fscking give a crap whether it's in there or not.  If
> it's on the dock, I don't need it in finder's Application list
> (i.e., the one in the finder app itself).  If you don't know what
> I'm talking about, look in the dock, at the far right (by default,
> anyways) and you'll see a square blue/bluish-off-white face.  Click
> that, select Applications, and there you are.

Perhaps that's what's confusing about your posts:
sometimes you speak about your macports problems,
without giving any of the details, and sometimes
it has nothing to do with macports at all.

At any rate, please, let's let this thread die already.

___
macports-users mailing list
macports-users@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-users

Re: THANKS (WAS: Re: any good audio/video editing apps in macports?)

[Jan Stary]

On Feb 24 17:30:02, spooky1...@gmail.com wrote:
> On Sun, Feb 24, 2013 at 03:08:50PM -0800, Scott Webster wrote:
> 
> > You should not have had to copy "the icon" (I assume you mean the
> > application) anywhere.  You could just run it from
> > /Applications/Macports or maybe it is /Applications/Macports/KDE4
> 
> I was referring to the install process with online stuff, where it gives
> you this neat little display where you move an icon for the app into
> an icon for Applications.

That's not how macport's ports are installed.
You don't have to move any icon anywhere.

___
macports-users mailing list
macports-users@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-users

Re: THANKS (WAS: Re: any good audio/video editing apps in macports?)

[Jan Stary]

On Feb 24 17:03:57, spooky1...@gmail.com wrote:
> On Sun, Feb 24, 2013 at 11:48:38PM +0100, Jan Stary wrote:
> > On Feb 24 15:35:58, spooky1...@gmail.com wrote:
> > > 
> > > And now the real reason for this response.  I haven't put the icon in
> > > finder's Applications folder (which I rarely use anyways), but it is in
> > > the dock, and yes, it works nicely.  Now I just need to spend some time
> > > in kdenlive to get used to it.  It looks like it's exactly what I need
> > > for both audio and video.
> > 
> > A MISSING ICON wouldn't cause any of the symptoms you described earlier.
> 
> What icon was missing?  I said I hadn't copied the icon into finder's
> Applications, and that, now that it was working, I just used the icon
> in the dock.  No missing icon that I'm aware of.

What did you mean by

"I haven't put the icon in finder's Applications folder"

then?


> > Also, you have posted output of "port content kdenlive" earlier
> > which shows that it _has_ installed things under /Applications.
> 
> Yes, I know that...I knew that when I posted the output.  What are you
> trying to tell me?

That you _have_ put kdelive.app into the /Application folder

___
macports-users mailing list
macports-users@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-users

Re: any good audio/video editing apps in macports?

[Jan Stary]

On Feb 24 14:51:07, sewebs...@gmail.com wrote:
> On Sun, Feb 24, 2013 at 2:50 PM, Jan Stary  wrote:
> > Does that mean that macports installs stuff out of /opt/local?
> > For example, under /Applications?
> >
> 
> Yes.

Do we mention it in the Guide or in the FAQ?

There was this whole debate about how /usr/local is bad
and /opt/local is good, the "official" stance being that
under /usr/local, third site installs could hurt macports,
or macports could hurt them. Isn't that exactly the case
with /Applications? Maybe even more so, because the
installers that people click through tend to install
into /Applications more than into /usr/local?

___
macports-users mailing list
macports-users@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-users

Re: any good audio/video editing apps in macports?

[Jan Stary]

On Feb 24 12:07:14, allber...@gmail.com wrote:
> On Sun, Feb 24, 2013 at 10:54 AM, Jan Stary  wrote:
> 
> > > the right port command to point me to kdenlive, and installed
> > > and ran kdenlive.app.
> >
> > From macports? What's the kdenlive APP,
> > as opposed to macport's multimedia/kdenlive?
> >
> 
> KDE defaults to building native, so KDE apps end up as app bundles in
> /Applications/MacPorts.

Does that mean that macports installs stuff out of /opt/local?
For example, under /Applications?

___
macports-users mailing list
macports-users@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-users

Re: THANKS (WAS: Re: any good audio/video editing apps in macports?)

[Jan Stary]

On Feb 24 15:35:58, spooky1...@gmail.com wrote:
> > So does just double clipping the app in Finder work?  It does for me...
> 
> And now the real reason for this response.  I haven't put the icon in
> finder's Applications folder (which I rarely use anyways), but it is in
> the dock, and yes, it works nicely.  Now I just need to spend some time
> in kdenlive to get used to it.  It looks like it's exactly what I need
> for both audio and video.

A MISSING ICON wouldn't cause any of the symptoms you described earlier.
Also, you have posted output of "port content kdenlive" earlier
which shows that it _has_ installed things under /Applications.

___
macports-users mailing list
macports-users@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-users

Re: any good audio/video editing apps in macports?

[Jan Stary]

On Feb 24 12:29:11, allber...@gmail.com wrote:
> On Sun, Feb 24, 2013 at 12:21 PM, Jim Graham  wrote:
> 
> > > always been flaky (and useless even when it runs, as you need to install
> > > all the KDE dependencies with debug symbols for it to be able to do
> > > anything at all useful).
> >
> > I didn't install it---if it's there, macports installed it with
> > something.  So I'm assuming (yeah, I know) that it's installed the
> > way it needs to be.
> >
> 
> Nope.
> 
> This is somewhat confusing:  drconqi is installed as part of the KDE
> runtime, and various things will fail if it's not there --- but by default
> MacPorts builds KDE without debug information because C++ debug information
> is very large (often larger than the actual program due to template
> expansion), so the produced drconqi is not very useful.  You can blame the
> upstream KDE devs for requiring that a worse-than-useless drconqi be
> present for KDE applications to work at all.

This is just one example of the utter crap that KDE is.

The original question was what is a good video editor.
If kdenlive is KDE-based (which it is), avoid it;
like anything else that is KDE-based.

___
macports-users mailing list
macports-users@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-users

Re: any good audio/video editing apps in macports?

[Jan Stary]

On Feb 24 10:48:24, spooky1...@gmail.com wrote:
> ardour2 is in macports.  The site for the binary version demands money
> for the Mac OS X working version (or you get a demo that doesn't save
> anything).  Considering that I currently have $1.38 to last until my
> next disability payment in March, that's not going to happen, but I doubt
> that would matter to anyone but meafter all, why should it?
> 
> And its build just failed:
> "Error: org.macports.build for port ardour2 returned: command execution
> failed"

That's when you need to look into the log
to see what actually happened.

> What is it with all of this stuff failing..  This is beyond absurd.
> So I'm right back to waiting for ideas on what's (probably) going wrong
> and how to fix it.

It's gonna stay hard trying to help you
unless you start telling us at least the
exact command you used and the exact output
it produced, and what the log says if needed.

___
macports-users mailing list
macports-users@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-users

Re: any good audio/video editing apps in macports?

[Jan Stary]

On Feb 24 17:30:12, n...@syndicat.com wrote:
> Am Sonntag, 24. Februar 2013, 10:27:09 schrieb Jim Graham:
> > > >From macports? What's the kdenlive APP,
> > > 
> > > as opposed to macport's multimedia/kdenlive?
> Mainly for audio ardour2 (and the upcoming 3) is worth a look as it aims to 
> provide a full featured Open Source DAW.
> 
> Not shure if ardour is still in macports but as available
> as binary packages i assume it should be still in.

(I am taking the 'shure' as a pun in this audio context :-).

Thanks for the ardour remainder; last time I tried it,
it was pretty unusable on any system I tried it on.

___
macports-users mailing list
macports-users@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-users

Re: any good audio/video editing apps in macports?

[Jan Stary]

On Feb 24 10:27:09, spooky1...@gmail.com wrote:
> On Sun, Feb 24, 2013 at 04:54:21PM +0100, Jan Stary wrote:
> > On Feb 24 08:05:02, spooky1...@gmail.com wrote:
> > > On Sun, Feb 24, 2013 at 07:24:15AM -0600, Jim Graham wrote:
> > > 
> > > > Ok...what is the command to run kdenlive?
> > > 
> > > Never mind this...I read deeper into the port man page and found
> > > the right port command to point me to kdenlive, and installed
> > > and ran kdenlive.app.
> > 
> > >From macports? What's the kdenlive APP,
> > as opposed to macport's multimedia/kdenlive?
> 
> That's where "port install kdenlive" put it, as I mentioned when I gave
> the location provided by "port location kdenlive" and it pointed to
> /opt/local/var/macports/software/kdenlive/kdenlive-0.9.4_0.darwin_11.x86_64.tbz2,
> which, when extracted, includes kdenlive.app in /Applications/MacPorts/KDE4.
> 
> /Applications/MacPorts/KDE4/kdenlive.app
> 
> But let's try that again (running port location kdenlive from vim using
> !!port location kdenlive:
> 
> Port kdenlive 0.9.4_0 is installed as an image in:
> /opt/local/var/macports/software/kdenlive/kdenlive-0.9.4_0.darwin_11.x86_64.tbz2
> 
> Now let's do bzcat /opt/./kdenlive-0.9.4 | tar tf - | grep 
> kdenlive.app:
> 
> ./Applications/MacPorts/KDE4/kdenlive.app/
> ./Applications/MacPorts/KDE4/kdenlive.app/Contents/
> ./Applications/MacPorts/KDE4/kdenlive.app/Contents/Info.plist
> ./Applications/MacPorts/KDE4/kdenlive.app/Contents/MacOS/
> ./Applications/MacPorts/KDE4/kdenlive.app/Contents/MacOS/kdenlive
> ./Applications/MacPorts/KDE4/kdenlive.app/Contents/MacOS/kdenlive.shell

OK, so it's part of the port then.

> That's what macports installed.  Should I submit a bug report, then?

No, why.

> Btw, your suggestion, port install -b kdenlive, produce the exact same
> result, including the mysterious drkonqi.app that keeps failing when
> kdenlive tries to run.  The error log says its parent app is kdenlive,
> but that's the best information I have on it or why it's failing.  I
> uninstalled and re-built kdenlive, and it didn't fix anything.  I've
> tried port info drkonqi only to have port tell me it doesn't know what
> I'm talking about (i.e., it isn't part of macports).

drkonqi is not a separate port.
It seems to be a part of KDE4.

> So basically, kdenlive is actually kadendead, unless anyone has any ideas
> on what's wrong and how to fix it.

It's a KDE application. What can you do,
all the KDE crap is inherent in it.

___
macports-users mailing list
macports-users@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-users

Re: any good audio/video editing apps in macports?

[Jan Stary]

On Feb 24 08:23:36, spooky1...@gmail.com wrote:
> On Sun, Feb 24, 2013 at 03:01:36PM +0100, Jan Stary wrote:
> > On Feb 24 07:24:15, spooky1...@gmail.com wrote:
> 
> > > This one had a pkg file, so
> > > I just double-clicked on it.  It then asked me which drive to install it
> > > on---either my main hard drive or eiither of two others.
> > > I picked the Mac OS X disk, and it said it couldn't install to that drive
> > > because it required at least Mac OS X 10.8.
> > 
> > Which you do have.
> 
> Do I?  "About This Mac" tells me I have "Mac OS X Version 10.7.5".  I
> didn't know that they were the same.  ;-}

Please excuse my weary eyes.

Anyway, what exactly did

sudo port -b install kdenlive

say?


> > Why would an install try to UNinstall stuff?
> 
> You're asking ME?  I'm the one confused by why all of this crap is going
> on with what should be a simple "port install kdenlive" (as root).
> 
> > How exactly are you running this 'install'?
> 
> port install kdenlive (again, as root)
> 
> > > --->kdenlive @0.9.4_0
> > >   Warning: Uninstall forced.  Proceeding despite dependencies.
> > 
> > What? So you _do_ have kdenlive installed?
> 
> Which is what I thought, too.  And yes, I was right---it SAID it was
> uninstalling it, but it didn't.  It just didn't install the .app itself.
> I was writing all of that up as a new post before I even saw this one.


> "drkonqi quit unexpectedly" which then takes kdenlive down.  But at the
> time you posted this, I was typing that in a new post.

drkonqi seems to be a KDE4 process that is somehow problematic:
http://trac.macports.org/ticket/26591

> > Know your tools. A first step might be
> > sudo port content kdenlive | grep bin
> 
> No need for root to run this (otherwise I'd run it from a different
> xterm, where I am currently logged in as root to work on this).  The
> port command above runs just fine as me (as do all of the ones that
> don't actually build or install something).
> 
>   (8:17) % port content kdenlive | grep bin
>   zsh: done   port content kdenlive | 
>   zsh: exit 1 grep bin
>   (8:17) % 


> Yep, that was helpful.

Indeed: your kdenlive installation does not contain anything
with "bin" in its path.

___
macports-users mailing list
macports-users@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-users

Re: any good audio/video editing apps in macports?

[Jan Stary]

On Feb 24 08:05:02, spooky1...@gmail.com wrote:
> On Sun, Feb 24, 2013 at 07:24:15AM -0600, Jim Graham wrote:
> 
> > Ok...what is the command to run kdenlive?
> 
> Never mind this...I read deeper into the port man page and found
> the right port command to point me to kdenlive, and installed
> and ran kdenlive.app.

>From macports? What's the kdenlive APP,
as opposed to macport's multimedia/kdenlive?

___
macports-users mailing list
macports-users@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-users

Re: any good audio/video editing apps in macports?

[Jan Stary]

On Feb 24 07:24:15, spooky1...@gmail.com wrote:
> On Sun, Feb 24, 2013 at 01:42:30PM +0100, Jan Stary wrote:
> > On Feb 24 06:20:53, spooky1...@gmail.com wrote:
> > > On Sat, Feb 23, 2013 at 11:33:40PM -0600, Ryan Schmidt wrote:
> 
> > What exactly is your MacOSX version (uname -a)?
> 
> Darwin n5ial-1.local 11.4.2 Darwin Kernel Version 11.4.2: Thu Aug 23 16:25:48 
> PDT 2012;
> root:xnu-1699.32.7~1/RELEASE_X86_64 x86_64
> 
> > How exactly did you try to install the binary package?
> 
> Usual procedure...open the dmg and install.

Why don't you try just installing the binary package?
sudo port -b install kdenlive

> This one had a pkg file, so
> I just double-clicked on it.  It then asked me which drive to install it
> on---either my main hard drive or eiither of two others.
> I picked the Mac OS X disk, and it said it couldn't install to that drive
> because it required at least Mac OS X 10.8.

Which you do have.

> Now the kdenlive install is whining about:
> --->  Unable to uninstall kde4-runtime @4.9.5_2, the following ports
>   depend on it:

Why would an install try to UNinstall stuff?
How exactly are you running this 'install'?

> --->kdenlive @0.9.4_0
>   Warning: Uninstall forced.  Proceeding despite dependencies.

What? So you _do_ have kdenlive installed?
What's your problem then?

> Ok...what is the command to run kdenlive?  The install finished with
> kde4-runtime (apparently it did NOT uninstall kdenlive after all), but
> it would seem that the command isn't kdenlive (and I don't know what it
> is).

Know your tools. A first step might be
sudo port content kdenlive | grep bin

___
macports-users mailing list
macports-users@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-users

Re: any good audio/video editing apps in macports?

[Jan Stary]

On Feb 24 06:20:53, spooky1...@gmail.com wrote:
> On Sat, Feb 23, 2013 at 11:33:40PM -0600, Ryan Schmidt wrote:
> 
> Well, the binary version that I found failed---it requires Mt Lion or
> better.

What exactly is your MacOSX version (uname -a)?
How exactly did you try to install the binary package?

___
macports-users mailing list
macports-users@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-users

Re: any good audio/video editing apps in macports?

[Jan Stary]

On Feb 23 18:15:16, spooky1...@gmail.com wrote:
> I'm also hoping there's some audio editing software that can do things
> like work on either channel of stereo, merge stereo into mono,
> add/delete/edit audio chunks, combine audio samples (in series), blend them,
> modify volume level (overall or normalize), etc... 

audio/sox

___
macports-users mailing list
macports-users@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-users

Re: binary pakages for darwin9

[Jan Stary]

On Feb 23 21:53:13, jon...@hep.phy.cam.ac.uk wrote:
> 
> > The top section says that macports is
> > 
> >  targeting mainly the current Mac OS X release (10.8, A.K.A. Mountain Lion)
> >  and the immediately previous two (10.7, A.K.A. Lion and 10.6, A.K.A. Snow
> >  Leopard).
> > 
> > It might be nitpicking, but "targeting mainly" is not quite the same
> > as saying explicitly "we don't build packages for your 10.5.8".
> 
> well, nitpicking back, it doesn't actually say there it builds *binary* 
> packages for any OSX version ?

Well, that's why I suggested putting it in section 3.4
of the Guide, "Port Binaries" ...

___
macports-users mailing list
macports-users@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-users

Re: binary pakages for darwin9

[Jan Stary]

On Feb 23 17:31:17, jon...@hep.phy.cam.ac.uk wrote:
> Hi,
> 
> On 23 Feb 2013, at 05:17 PM, Jan Stary  wrote:
> 
> > On Feb 23 16:17:26, jon...@hep.phy.cam.ac.uk wrote:
> >> Hi,
> >> 
> >>> Are binary packages for darwin9 being built?
> >> 
> >> I think not. They are only available for OSX 10.6 (darwin 10) onwards.
> >> https://build.macports.org/waterfall
> > 
> > I think http://guide.macports.org/#using.binaries
> > should be explicit about what versions of OSX
> > binaries are built for. Or have I missed it
> > somewhere else?
> 
> Maybe. Personally I think it's covered by the top section of
> 
> http://www.macports.org/
> 
> Which states only the current OSX release, and the two previous ones, are 
> officially supported. 

The top section says that macports is

  targeting mainly the current Mac OS X release (10.8, A.K.A. Mountain Lion)
  and the immediately previous two (10.7, A.K.A. Lion and 10.6, A.K.A. Snow
  Leopard).

It might be nitpicking, but "targeting mainly" is not quite the same
as saying explicitly "we don't build packages for your 10.5.8".

___
macports-users mailing list
macports-users@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-users

Re: Broken perl configuration

[Jan Stary]

On Feb 23 12:43:10, pixi...@macports.org wrote:
> 
> On Feb 23, 2013, at 11:49 AM, Jan Stary wrote:
> 
> > On Feb 21 11:05:23, dl...@geeklair.net wrote:
> >> On Feb 21, 2013, at 10:05 AM, Bruce Miller  wrote:
> >>> With MacPort's perl 5.12, the executable is installed in
> >>> /opt/local/libexec/perl5.12/sitebin
> >>> which is *NOT* where people expect to find programs.
> >>> And it's NOT a directory people want to maintain in
> >>> their $PATH.
> >> 
> >> why? Why would people care whether they have /opt/local/bin or 
> >> /opt/local/libexec/perl5.12/sitebin or /my/nonstandard/macports/prefix/bin 
> >> in their $PATH?
> > 
> > People will care that they
> > (1) have to tweak their PATH at all
> > (2) have to pollute with /opt/local/libexec/version-du-jour-123
> > and keep an eye on what the exact verion is this week.
> > 
> >>> The reason for the configuration change
> >>> is to achieve the noble goal of being able
> >>> to install multiple versions of Perl, and
> >>> multiple versions of software running under
> >>> those Perls.  
> > 
> > Please excuse my Perl ignorance - what would be
> > a realistic scenario for having multiple versions
> > of Perl installed, and multiple version of Perl
> > software on top of those?
> 
> I believe there are cases where ports depend on perl modules
> that are only compatible with specific perl versions.

Could somebody please provide an example of such situation?

___
macports-users mailing list
macports-users@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-users

Re: Broken perl configuration

[Jan Stary]

On Feb 23 12:49:48, bruce.mil...@nist.gov wrote:
> On 02/23/2013 12:44 PM, Jan Stary wrote:
> >On Feb 21 11:05:23, dl...@geeklair.net wrote:
> >>On Feb 21, 2013, at 10:05 AM, Bruce Miller  wrote:
> >>>With MacPort's perl 5.12, the executable is installed in
> >>>  /opt/local/libexec/perl5.12/sitebin
> >
> >On my MacOSX 10.5.8. with macports 2.1.3 it is not, thank god:
> >
> >hans@mac:~$ cd /opt/local/bin/
> >hans@mac:bin$  ls -li perl*
> >10777214 lrwxrwxrwx  1 root  admin   8 Feb 10 17:01 perl -> perl5.12
> >10777215 lrwxrwxrwx  1 root  admin   8 Feb 10 17:01 perl5 -> perl5.12
> >10772717 -rwxr-xr-x  1 root  admin  13256 Feb 10 16:59 perl5.12
> >10772718 lrwxrwxrwx  1 root  admin   8 Feb 10 17:00 perl5.12.4 -> perl5.12
> >10777216 lrwxrwxrwx  1 root  admin 12 Feb 10 17:01 perlbug -> 
> >perlbug-5.12
> >10772719 -rwxr-xr-x  2 root  admin  45815 Feb 10 16:59 perlbug-5.12
> >10777217 lrwxrwxrwx  1 root  admin 12 Feb 10 17:01 perldoc -> 
> >perldoc-5.12
> >10772720 -rwxr-xr-x  1 root  admin244 Feb 10 16:59 perldoc-5.12
> >10777218 lrwxrwxrwx  1 root  admin 12 Feb 10 17:01 perlivp -> 
> >perlivp-5.12
> >10772721 -rwxr-xr-x  1 root  admin  12484 Feb 10 16:59 perlivp-5.12
> >10777219 lrwxrwxrwx  1 root  admin 15 Feb 10 17:01 perlthanks -> 
> >perlthanks-5.12
> >10772719 -rwxr-xr-x  2 root  admin  45815 Feb 10 16:59 perlthanks-5.12
> >
> >
> >If I reinstall now, perl will be installed in
> >/opt/local/libexec/perl5.12/sitebin ? Why?
> 
> It's not about perl itself, it's about Perl scripts that
> are not installed by a portfile, but by standard Perl methods
> (MakeMaker, CPAN...)

Why would macports even care about something
'not installed by a portfile' (which I read:
not installed via macports)?

___
macports-users mailing list
macports-users@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-users

Re: Broken perl configuration

[Jan Stary]

On Feb 21 22:02:19, dl...@geeklair.net wrote:
> On Feb 21, 2013, at 6:19 PM, Bruce R Miller  wrote:
> > But a "plain perl" used from commands like
> >  perl Makefile.PL
> > will use the more common installation directories,
> > like macports used to do, and every other OS does.

It does now, doesn't it? Running 'perl whatever'
just picks the first 'perl' in your PATH.

> which just exchanges the specific behavior you don't want
> for a different broken behavior (think about what happens
> if/when you upgrade your macports perl but you have something
> in ${prefix}/bin that you installed locally that is now
> missing components...)

If the user installed something manually into $prefix/bin
that depends on a particular perl version (from macports),
and then upgraded that perl version via macports, and it
broke his manual $prefix/bin/stuff, it's the user's
own footshooting. It's none of macports bussines
to even care whether upgrading a macports version
of something breaks some none-macports software.

___
macports-users mailing list
macports-users@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-users

Re: Broken perl configuration

[Jan Stary]

On Feb 21 18:19:56, bruce.mil...@nist.gov wrote:
> As much as you or I may like to stay within managed packages,
> you never can keep up with CPAN and shouldn't try.

Why can't you? Why shouldn't you try?

Whenever there is stuff in CPAN that you want to have
on your macos, make a port of it, and install that port.
Solved.

___
macports-users mailing list
macports-users@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-users

Re: Broken perl configuration

[Jan Stary]

On Feb 21 11:46:29, dl...@geeklair.net wrote:
> On Feb 21, 2013, at 11:37 AM, Bruce Miller  wrote:
> > And, let's be frank; Macs cater (wisely, perhaps) to
> > a group of users who don't know about, or want to know about, $PATH.
> 
> ... and those people tend to not ever use the terminal ... ;-)
> 
> If you're going to use the command line, you probably need to know
> (at least a little) about $PATH.

Of course. But that't not the same as editing it
whenever a version of something (perl or not)
bumps from 5.12 to 5.14

___
macports-users mailing list
macports-users@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-users

Re: Broken perl configuration

[Jan Stary]

On Feb 21 11:05:23, dl...@geeklair.net wrote:
> On Feb 21, 2013, at 10:05 AM, Bruce Miller  wrote:
> > With MacPort's perl 5.12, the executable is installed in
> >  /opt/local/libexec/perl5.12/sitebin
> > which is *NOT* where people expect to find programs.
> > And it's NOT a directory people want to maintain in
> > their $PATH.
> 
> why? Why would people care whether they have /opt/local/bin or 
> /opt/local/libexec/perl5.12/sitebin or /my/nonstandard/macports/prefix/bin in 
> their $PATH?

People will care that they
(1) have to tweak their PATH at all
(2) have to pollute with /opt/local/libexec/version-du-jour-123
and keep an eye on what the exact verion is this week.

> > The reason for the configuration change
> > is to achieve the noble goal of being able
> > to install multiple versions of Perl, and
> > multiple versions of software running under
> > those Perls.  

Please excuse my Perl ignorance - what would be
a realistic scenario for having multiple versions
of Perl installed, and multiple version of Perl
software on top of those?

I can imagine a Perl developer might want this,
but that hardly justifies forcing the majority
(I believe) of users who just want to have one Perl
and one p5-foo on their system, without having to tweak
their configuration to be able to run it.

> As an aside, I personally don't feel that the benefits of
> having multiple perl versions available is worth it
> - I think we would be better served by just pushing
> the current stable perl...

I agree.

Jan

___
macports-users mailing list
macports-users@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-users

Re: Broken perl configuration

[Jan Stary]

On Feb 21 11:05:23, dl...@geeklair.net wrote:
> On Feb 21, 2013, at 10:05 AM, Bruce Miller  wrote:
> > With MacPort's perl 5.12, the executable is installed in
> >  /opt/local/libexec/perl5.12/sitebin

On my MacOSX 10.5.8. with macports 2.1.3 it is not, thank god:

hans@mac:~$ cd /opt/local/bin/
hans@mac:bin$  ls -li perl*
10777214 lrwxrwxrwx  1 root  admin  8 Feb 10 17:01 perl -> perl5.12
10777215 lrwxrwxrwx  1 root  admin  8 Feb 10 17:01 perl5 -> perl5.12
10772717 -rwxr-xr-x  1 root  admin  13256 Feb 10 16:59 perl5.12
10772718 lrwxrwxrwx  1 root  admin  8 Feb 10 17:00 perl5.12.4 -> perl5.12
10777216 lrwxrwxrwx  1 root  admin 12 Feb 10 17:01 perlbug -> perlbug-5.12
10772719 -rwxr-xr-x  2 root  admin  45815 Feb 10 16:59 perlbug-5.12
10777217 lrwxrwxrwx  1 root  admin 12 Feb 10 17:01 perldoc -> perldoc-5.12
10772720 -rwxr-xr-x  1 root  admin244 Feb 10 16:59 perldoc-5.12
10777218 lrwxrwxrwx  1 root  admin 12 Feb 10 17:01 perlivp -> perlivp-5.12
10772721 -rwxr-xr-x  1 root  admin  12484 Feb 10 16:59 perlivp-5.12
10777219 lrwxrwxrwx  1 root  admin 15 Feb 10 17:01 perlthanks -> 
perlthanks-5.12
10772719 -rwxr-xr-x  2 root  admin  45815 Feb 10 16:59 perlthanks-5.12


If I reinstall now, perl will be installed in
/opt/local/libexec/perl5.12/sitebin ? Why?

___
macports-users mailing list
macports-users@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-users

Re: binary pakages for darwin9

[Jan Stary]

On Feb 23 16:17:26, jon...@hep.phy.cam.ac.uk wrote:
> Hi,
> 
> > Are binary packages for darwin9 being built?
> 
> I think not. They are only available for OSX 10.6 (darwin 10) onwards.
> https://build.macports.org/waterfall

I think http://guide.macports.org/#using.binaries
should be explicit about what versions of OSX
binaries are built for. Or have I missed it
somewhere else?

___
macports-users mailing list
macports-users@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-users

binary pakages for darwin9

[Jan Stary]

I am trying to install SoX using a binary package on my 10.5.8
which is

$ uname -a
Darwin mac.stare.cz 9.8.0 Darwin Kernel Version 9.8.0: Wed Jul 15
16:55:01 PDT 2009; root:xnu-1228.15.4~1/RELEASE_I386 i386

The attempt to install with

sudo port -v -b install sox

fails and the log says

:msg:archivefetch --->  Attempting to fetch sox-14.4.1_0.darwin_9.i386.tbz2 from
http://lil.fr.packages.macports.org/sox
:debug:archivefetch Fetching archive failed:: The requested URL returned error: 
404

Indeed, there are only binary packages for darwin_10, 11 and 12.
Same for other mirros.

Are binary packages for darwin9 being built?
I haven't found this information in the Guide
or in the FAQ.

Jan

___
macports-users mailing list
macports-users@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-users

Re: parental internet filter from MacPorts

[Jan Stary]

On Feb 19 21:38:06, guanoape...@gmx.ch wrote:
> Is there a black list for Tarot and other Black magic?

I took the liberty of creating one for you:

Tarot
Black Magic

> My customer wishes internet filter based on Catholic Church morale.

I assume your customer is demented, or at least cannot
be bothered to raise his kids. After all, we have technology.

In that case, there is a lot of companies willing
to take your customer's money in exchange for
keeping his soul pure on the internet.

If he merely wants people to stop using condoms,
there are entire websites dedicated to petitions.

> Any recommendations?

Slay a black goat and spill its blood
on your customer's DNS resolver.

___
macports-users mailing list
macports-users@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-users

Re: UNIX commands font

[Jan Stary]

On Feb 13 18:59:45, lar...@macports.org wrote:
> On Feb 13, 2013, at 6:23 PM, Alejandro Imass  wrote:
> > 
> > Linux tutorials (which are plentiful) will work as well, but remember that 
> > Mac OS X is more BSD-like with some Linux accents like the bash shell.
> 
> I don't see how bash is a Linux-ism.

Nobody said "linuxism", but the
Linuces indeed tend to use the bash shell.

> Do modern BSDs tend to default to another shell?

Yes.

> In any case, changing shells is trivial.

Yes, diverting from the default and subscribing
to something incompatible with the default shell
is indeed trivial.

___
macports-users mailing list
macports-users@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-users

PKG_PROG_PKG_CONFIG on MacOSX 10.5.8

[Jan Stary]

I am building libsndfile from git on MacOSX 10.5.8.
I know we have a port; I am experimenting with the source.

Building from the source needs ./autogen.sh to be run.
That's when I run into a problem:

> Script started on Wed Feb 20 21:41:40 2013
> hans@mac:libsndfile$ ./autogen.sh
> -n checking for autogen ...
> yes
> -n checking for autoconf ...
> yes
> -n checking for automake ...
> yes
> -n checking for libtool ...
> glibtoolize
> -n checking for pkg-config ...
> yes
> -n checking for python ...
> yes
> Generating configuration files for libsndfile, please wait ...
>   aclocal -I M4
> configure.ac:297: warning: PKG_PROG_PKG_CONFIG is m4_require'd but not 
> m4_defun'd
> M4/extra_pkg.m4:105: PKG_CHECK_MOD_VERSION is expanded from...
> configure.ac:297: the top level
> configure.ac:302: warning: PKG_PROG_PKG_CONFIG is m4_require'd but not 
> m4_defun'd
> configure.ac:302: the top level
> configure.ac:305: warning: PKG_PROG_PKG_CONFIG is m4_require'd but not 
> m4_defun'd
> configure.ac:305: the top level
> configure.ac:314: warning: PKG_PROG_PKG_CONFIG is m4_require'd but not 
> m4_defun'd
> configure.ac:314: the top level
> configure.ac:315: warning: PKG_PROG_PKG_CONFIG is m4_require'd but not 
> m4_defun'd
> configure.ac:315: the top level
> configure.ac:345: warning: PKG_PROG_PKG_CONFIG is m4_require'd but not 
> m4_defun'd
> configure.ac:345: the top level
>   glibtoolize --automake --force
>   autoheader
> configure.ac:297: warning: PKG_PROG_PKG_CONFIG is m4_require'd but not 
> m4_defun'd
> M4/extra_pkg.m4:105: PKG_CHECK_MOD_VERSION is expanded from...
> configure.ac:297: the top level
> configure.ac:302: warning: PKG_PROG_PKG_CONFIG is m4_require'd but not 
> m4_defun'd
> configure.ac:302: the top level
> configure.ac:305: warning: PKG_PROG_PKG_CONFIG is m4_require'd but not 
> m4_defun'd
> configure.ac:305: the top level
> configure.ac:314: warning: PKG_PROG_PKG_CONFIG is m4_require'd but not 
> m4_defun'd
> configure.ac:314: the top level
> configure.ac:315: warning: PKG_PROG_PKG_CONFIG is m4_require'd but not 
> m4_defun'd
> configure.ac:315: the top level
> configure.ac:345: warning: PKG_PROG_PKG_CONFIG is m4_require'd but not 
> m4_defun'd
> configure.ac:345: the top level
>   automake --add-missing
> configure.ac:297: warning: PKG_PROG_PKG_CONFIG is m4_require'd but not 
> m4_defun'd
> M4/extra_pkg.m4:105: PKG_CHECK_MOD_VERSION is expanded from...
> configure.ac:297: the top level
> configure.ac:302: warning: PKG_PROG_PKG_CONFIG is m4_require'd but not 
> m4_defun'd
> configure.ac:302: the top level
> configure.ac:305: warning: PKG_PROG_PKG_CONFIG is m4_require'd but not 
> m4_defun'd
> configure.ac:305: the top level
> configure.ac:314: warning: PKG_PROG_PKG_CONFIG is m4_require'd but not 
> m4_defun'd
> configure.ac:314: the top level
> configure.ac:315: warning: PKG_PROG_PKG_CONFIG is m4_require'd but not 
> m4_defun'd
> configure.ac:315: the top level
> configure.ac:345: warning: PKG_PROG_PKG_CONFIG is m4_require'd but not 
> m4_defun'd
> configure.ac:345: the top level
>   autoconf
> configure.ac:297: warning: PKG_PROG_PKG_CONFIG is m4_require'd but not 
> m4_defun'd
> M4/extra_pkg.m4:105: PKG_CHECK_MOD_VERSION is expanded from...
> configure.ac:297: the top level
> configure.ac:302: warning: PKG_PROG_PKG_CONFIG is m4_require'd but not 
> m4_defun'd
> configure.ac:302: the top level
> configure.ac:305: warning: PKG_PROG_PKG_CONFIG is m4_require'd but not 
> m4_defun'd
> configure.ac:305: the top level
> configure.ac:314: warning: PKG_PROG_PKG_CONFIG is m4_require'd but not 
> m4_defun'd
> configure.ac:314: the top level
> configure.ac:315: warning: PKG_PROG_PKG_CONFIG is m4_require'd but not 
> m4_defun'd
> configure.ac:315: the top level
> configure.ac:345: warning: PKG_PROG_PKG_CONFIG is m4_require'd but not 
> m4_defun'd
> configure.ac:345: the top level
> 
> 
> I _do_ have pkg-config installed, and is in my PATH:
> 
> hans@mac:libsndfile$ pkg-config --version
> 0.27.1
> 
> 
> ./configure is produced, but is unusable:
> 
> ./configure: line 26359: PKG_PROG_PKG_CONFIG: command not found
> ./configure: line 26374: syntax error near unexpected token `FLAC_CFLAGS,'
> ./configure: line 26374: `_PKG_CONFIG(FLAC_CFLAGS, cflags, flac >= 1.2.1)'

Upstream says this is likely a problem with my pkgconfig:

On Feb 21 11:28:28, er...@mega-nerd.com wrote:
> > I _do_ have pkg-config installed, and is in my PATH:
> > 
> > hans@mac:libsndfile$ pkg-config --version
> > 0.27.1
> > 
> > 
> > ./configure is produced, but is unusable:
> > 
> > ./configure: line 26359: PKG_PROG_PKG_CONFIG: command not found
> > ./configure: line 26374: syntax error near unexpected token `FLAC_CFLAGS,'
> > ./configure: line 26374: `_PKG_CONFIG(FLAC_CFLAGS, cflags, flac >= 1.2.1)'
> > 
> > 
> > What could be causing this?
> 
> That M4 macro should get installed with pkg-config. Not sure why its
> not on your system.


Could someone who knows the pkg-config internals
please enlighten me on this? Is it really the case
that our

Re: question about frequency of updates

[Jan Stary]

On Feb 09 20:30:50, listmeis...@thestoneforge.com wrote:
> On Feb 09, 2013, at 14:24, Comer Duncan  wrote:
> > I am wondering what the gurus say is a reasonable
> > update interval for macports?

This hardly takes a guru: update when you need to.

___
macports-users mailing list
macports-users@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-users

Re: Which version of "Wine", or am I on the wrong track?

[Jan Stary]

>  On Apr 15, 2012, at 10:56 AM, Michael_google gmail_Gersten wrote:
> > I am not sure which version of Wine to install from Macports (there
> > are three), or if this is even the right approach for what I want to
> > do.
> > 
> > The goal: Edit a "movie" (screen recording), from the view that 80-90%
> > of what I recorded will be tossed.

I am pretty sure there are ways in MacOS itself to make and edit
a screen recording; you most probably do not need to bring the whole
wine monster to your system just to do that.

___
macports-users mailing list
macports-users@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo.cgi/macports-users

Re: How remove port info but not installed files?

[Jan Stary]

On Apr 18 12:01:12, Murray Eisenberg wrote:
> 1. Without using MacPorts, I directly installed TeXLive 2011 (as
> part of MacTeX).
> I didn't realize that that distribution included the source files
> and build/install instructions for the asymptote application. So ...
> 
> 2. I used MacPorts to install asymptote.
> That automatically did a MacPorts install of texlive 2011 (which,
> via #1, was already installed), on which it depended.
> 
> Now I have apparently have a great deal of duplication from texlive
> in general, and asymptote in particular

On Apr 18 13:30:38, Murray Eisenberg wrote:
> Indeed, it's space I want to conserve on my relatively small SSD boot drive.
> 
> It's the original MacTeX TeXLive 2011 installation I want to keep --
> and NOT the MacPorts version.
> 
> (Various reasons for that preference, including a very helpful GUI
> maintenance utility that's part of MacTeX.)

Well, do the right thing then: create a patch to texlive's Portfile
to include this helpful utility in the texlive port :-) Then you can
have it all via macports.

___
macports-users mailing list
macports-users@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo.cgi/macports-users

Re: UsingTheRightCompiler

[Jan Stary]

On Apr 15 23:04:58, Jeff Singleton wrote:
> Yes I am referring to the Wiki article found here...
> http://trac.macports.org/wiki/UsingTheRightCompiler
> 
> I just can't say a lot for Clang.  I have mentioned this before.  I have
> taken many suggestions.  Tried Tried and Tried some more to like Clang.
> 
> I just can't do it.
> 
> Its ugly.  It causes more problems between ports that depend on one
> another, yet some are built with Clang, other built with GCC.
> 
> I am simply fed up with Clang and I don't really want to use it anymore.
> *libtool: link: /usr/bin/clang  -o .libs/pango-basic-coretext.so

I must be missing something, but why do you even have
clang installed on your system?

___
macports-users mailing list
macports-users@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo.cgi/macports-users

Re: /usr/local question

[Jan Stary]

> > I am willing to help this with ports that interest me.
> > Is there a way in trac to specifically select the ports
> > that have this problem?
> 
> not that I know of (since you don't know what is going to be
> in /usr/local on any machine)

I tried searching in both the mailing list archives and trac;
indeed, there are ports with this problem, but most of them
have been closed quite some time ago. Or I am not searching well.
Could someone please point me to a trac ticket or a list post
describing this exact problem for some current port, i.e.,
a port that fails to build because it picks something
inappropriate from /usr/local ?

Jan

___
macports-users mailing list
macports-users@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo.cgi/macports-users

Re: /usr/local question

[Jan Stary]

> OK, here is what I propose as a relacement/extension of FAQ#defaultprefix.
> * Why is /opt/local the default install location for MacPorts?
> * So with macports under /opt/local I can use /usr/local freely?

I just commited this (fixing the typos.)

https://trac.macports.org/wiki/FAQ#defaultprefix
https://trac.macports.org/wiki/FAQ#usrlocal

I believe this should be explicitly mentioned in the Guide
(In fact, there is a four years old ticket by Ryan requesting that).
http://trac.macports.org/ticket/15077

Jan

___
macports-users mailing list
macports-users@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo.cgi/macports-users

Re: /usr/local question

[Jan Stary]

On Apr 05 08:25:49, Bradley Giesbrecht wrote:
> On Apr 5, 2012, at 12:00 AM, Jan Stary wrote:
> 
> > Again, this is not entirely true: the proper way for a port to
> > not accidently pick up unwanted dependencies is to say --disable-whatever
> > in the Portfile (and yes, I have run into that problem in ports
> > I maintain). Not all ports provide a way to declare this, so
> > you make sure it doesn't happen by removing /usr/local altgether,
> > or making the user remove his /usr/local, which you will agree is
> > a pretty extreme measure on a UNIX system.
> 
> Simply put, MacPorts does not "SUPPORT" /usr/local in the sense that if you 
> ask for help from MacPorts we are going to ask you to move /usr/local out of 
> the way rather then tediously work though the contents of /usr/local. Our 
> resources are better spent on other tasks.

I respect that.

However, I believe that if a port chokes on picking up 
some unintended dependency it found in /usr/local
(or anywhere, for that matter), it is that port's
problem: I don't think it's /usr/local's fault being
there - I think it's the port's defect geting confused
by that.

Hence in terms of the (limited) resources, I believe
it's the port maintainer's job to rectify this by
actually fixing that (broken) port so that it no
longer gets confused.

I am willing to help this with ports that interest me.
Is there a way in trac to specifically select the ports
that have this problem? (Or is there even a keyword for
that, such as 'usrlocal', 'externalconflict' or whatever?)

Jan


___
macports-users mailing list
macports-users@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo.cgi/macports-users

Re: /usr/local question

[Jan Stary]

On Apr 05 08:47:47, Arno Hautala wrote:
> On 2012-04-05, Jan Stary  wrote:
> >
> > (The XXX is where my English fails me. Could a native speaker
> > put the right verb in please that seems to slip my mind?)
> >
> > [...]
> >
> > While this could be XXXed off as the user's own error, it is a fact that
> 
> "written off as"
> "chalked up to"
> "dismissed as"

ah, dismissed, thanks.

___
macports-users mailing list
macports-users@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo.cgi/macports-users

Re: /usr/local question

[Jan Stary]

On Apr 05 19:52:23, Christopher Vance wrote:
> I'll also mention that OpenBSD exclusively uses packages which are
> compiled elsewhere; all ported software is installed from packages;
> they have already reached where NetBSD is trying to get to.
> In addition, OpenBSD culture is to install from packages,
> not by building from source yourself.

Yes. I come from OpenBSD and miss this in macports.

> Maybe they have patches which prevent GNU crapware from inspecting
> bogus locations before building packages?

No. They simply have CONFIGURE_ARGS in the Makefiles
(analogously, macports has configure.args in Portfiles)
and it is each port's bussines to set that appropriatelly.
And when a port fails to do that properly, and picks up
something unsuitable that the packaging system doesn't know about
(which does happen), it is considered that port's problem.

> OpenBSD also uses prerequisite packages and configure tweaks
> to ensure that the stuff they use is installed in /usr/local
> from OpenBSD packages,

That's not done by configure tweaks
- checksums are kept for the installed files.

___
macports-users mailing list
macports-users@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo.cgi/macports-users

Re: /usr/local question

[Jan Stary]

On Apr 05 04:13:44, Jeremy Lavergne wrote:
> The thread has pointed out that there would not be an issue
> if that were the case: it appears Gnu toolchain puts /usr/local first.

Even if the build tools put /usr/local before /usr,
the example still stands: I don't have /usr/local at all.
I have an old, incompatible version of openssl in
/usr/lib/libssl.*, and a port that fails to build
because it picks that up.

What happens then? Should I temporarily rename /usr
so that the port does not pick that up and builds successfully?


> >>> Am 05.04.2012 um 10:25 schrieb Jan Stary :
> >>>
> >>>> On Apr 05 09:00:44, Jan Stary wrote:
> >>>>> However, if a given port silently picks up something
> >>>>> incompatible in /usr/local, if might fail and often will.
> >>>>>
> >>>>> Having macports isolated in /opt/local DID NOT save you from this.
> >>>>> Removing /usr/local is what did.
> >>>>
> >>>> One more point to this: what if the colliding, incompatible
> >>>> software that stops a given port from building successfully
> >>>> is not found under /usr/local, but in /usr, which is
> >>>> even more prominently recognized by various build tools.
> >>>>
> >>>> That's not made up: /usr/lib/libssl.*
> >>>> Say the port requires a newer version of openssl
> >>>> than what /usr/lib/libssl.* provides.
> >>>>
> >>>> That's the same situation as with a port not building
> >>>> because some incompatbile software was found and
> >>>> picked up from /usr/local; except now it is /usr.
> >>>>
> >>>> What is the advice here?
> >>>> Ceratinly not to temporarily rename /usr.
> >>>>
> >>>> I argue that temporarily removing /usr/local is just as bad,
> >>>> and the problem of a port picking bad stuff from /usr/local
> >>>> is that given port's defect that needs to be fixed before
> >>>> the port gets built; not a reason to remove /usr/local.
> >>>>
> >>>> (Which doesn't change the fact that /opt/local is a better prefix,
> >>>> I am over that already.)

___
macports-users mailing list
macports-users@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo.cgi/macports-users

Re: /usr/local question

[Jan Stary]

On Apr 05 11:06:51, Dominik Reichardt wrote:
> Honoring the order in PATH so when /opt/local is in front of /usr,
> compilers will honor that.

PATH is where the binaries are looked for.
I am talking about libraries; compilers do not look
for libraries in PATH.

> So yes PATH has a lot to do with this. Opposed to the /usr/local issue.
> Check your attitude please

Check what PATH is.

___
macports-users mailing list
macports-users@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo.cgi/macports-users

Re: /usr/local question

[Jan Stary]

On Apr 05 10:49:01, Dominik Reichardt wrote:
> As far as I can tell, /usr in PATH is being honored
> opposed to /usr/local being picked up automatically.

I don't know how "honored" differs from "being picked up",
but PATH has nothing to do with this.


> Am 05.04.2012 um 10:25 schrieb Jan Stary :
> 
> > On Apr 05 09:00:44, Jan Stary wrote:
> >> However, if a given port silently picks up something
> >> incompatible in /usr/local, if might fail and often will.
> >> 
> >> Having macports isolated in /opt/local DID NOT save you from this.
> >> Removing /usr/local is what did.
> > 
> > One more point to this: what if the colliding, incompatible
> > software that stops a given port from building successfully
> > is not found under /usr/local, but in /usr, which is
> > even more prominently recognized by various build tools.
> > 
> > That's not made up: /usr/lib/libssl.*
> > Say the port requires a newer version of openssl
> > than what /usr/lib/libssl.* provides.
> > 
> > That's the same situation as with a port not building
> > because some incompatbile software was found and
> > picked up from /usr/local; except now it is /usr.
> > 
> > What is the advice here?
> > Ceratinly not to temporarily rename /usr.
> > 
> > I argue that temporarily removing /usr/local is just as bad,
> > and the problem of a port picking bad stuff from /usr/local
> > is that given port's defect that needs to be fixed before
> > the port gets built; not a reason to remove /usr/local.
> > 
> > (Which doesn't change the fact that /opt/local is a better prefix,
> > I am over that already.)
> > 
> > ___
> > macports-users mailing list
> > macports-users@lists.macosforge.org
> > http://lists.macosforge.org/mailman/listinfo.cgi/macports-users
___
macports-users mailing list
macports-users@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo.cgi/macports-users

Re: /usr/local question

[Jan Stary]

On Apr 05 09:00:44, Jan Stary wrote:
> However, if a given port silently picks up something
> incompatible in /usr/local, if might fail and often will.
> 
> Having macports isolated in /opt/local DID NOT save you from this.
> Removing /usr/local is what did.

One more point to this: what if the colliding, incompatible
software that stops a given port from building successfully
is not found under /usr/local, but in /usr, which is
even more prominently recognized by various build tools.

That's not made up: /usr/lib/libssl.*
Say the port requires a newer version of openssl
than what /usr/lib/libssl.* provides.

That's the same situation as with a port not building
because some incompatbile software was found and
picked up from /usr/local; except now it is /usr.

What is the advice here?
Ceratinly not to temporarily rename /usr.

I argue that temporarily removing /usr/local is just as bad,
and the problem of a port picking bad stuff from /usr/local
is that given port's defect that needs to be fixed before
the port gets built; not a reason to remove /usr/local.

(Which doesn't change the fact that /opt/local is a better prefix,
I am over that already.)

___
macports-users mailing list
macports-users@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo.cgi/macports-users

Re: /usr/local question

[Jan Stary]

> I agree now that /usr/local is on fact a bad choice.
> What I find cnfusing or unclear is the reasoning about it
> in the the FAQ.
> 
> The most prominent reason given to me yesterday for not having
> /usr/local as a default prefix was that people will stupidly
> rewrite the stuff in there by blindly clicking through third-party
> installers. That for example is not mentioned in the FAQ at all.

> I will try to come up with a better reformulation based
> on what people have explained to me here.


OK, here is what I propose as a relacement/extension of FAQ#defaultprefix.
Does this correctly describe the reasoning that was kindly explained
to me in the previous discussion? Obviously, I would like this OK'd here
before I mangle the wiki.

(The XXX is where my English fails me. Could a native speaker
put the right verb in please that seems to slip my mind?)


* Why is /opt/local the default install location for MacPorts?

Traditionally, the place to install third party software on many UNIX systems
is /usr/local. However, having macports under /usr/local would be error-prone.
Many other software packages and packaging systems install in there, and
would accidentaly overwrite what macports has installed, or vice versa.
While this could be XXXed off as the user's own error, it is a fact that
users click through installers blindly, and consequently collisions under
/usr/local (and other prominent directories) happen very often.
Macports doesn't want to be a victim of that, and /opt/local provides
the splendid isolation - as would any other dedicated directory, of course.
Also, /usr/local is traditionally reserved for the given system's admin
to install local tools; macports doesn't want to stomp on that either.

(For the same reasons, fink uses /sw as its prefix.)


* So with macports under /opt/local I can use /usr/local freely?

No, not entirely. Even with macports living elsewhere, /usr/local
can still interfere. Some software (especially the GNU auto* tools
and gcc) looks into /usr/local for external headers, libraries,
and binaries. Ceratin ports might (and do) fail to build because
during their build something incompatible is found and picked up
from /usr/local. Good ports avoid this by explicitly specifying
--with-libfoo=/opt/local/lib/ or explicitly disabling all such
possible dependencies altogehter with --disable-foo or --without-bar,
but not all ports are able to do that.
In some cases, it might even be necessary to
temporarily make /usr/local disappear entirely for a given port
to build successfully. Obviously this wouldn't be possible if
macports itself lived under /usr/local.

(And a third which I don't expect to be let through:

* So in order to build a given broken port with macports,
  you advice me to remove /usr/local altogether, thus
  crippling my system for the duration of the build?

Sadly, yes.)

___
macports-users mailing list
macports-users@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo.cgi/macports-users

Re: /usr/local question

[Jan Stary]

> If I keep MacPorts in its own prefix, it is easier to ensure that other
> software on my system does not get mixed up in a build.

No, not really. You have macports stuff in its own prefix, namely,
/opt/local. However, if a given port silently picks up something
incompatible in /usr/local, if might fail and often will.

Having macports isolated in /opt/local DID NOT save you from this.
Removing /usr/local is what did. This is the distinction I am
trying to make, and that's what I find confusing about the FAQ
entry as it stands now. Do you see my point now?

I agree now that /usr/local is on fact a bad choice.
What I find cnfusing or unclear is the reasoning about it
in the the FAQ.

The most prominent reason given to me yesterday for not having
/usr/local as a default prefix was that people will stupidly
rewrite the stuff in there by blindly clicking through third-party
installers. That for example is not mentioned in the FAQ at all.


> As a port maintainer, this means I can produce a port that does
> not accidentally depend on software that MacPorts doesn't know about,

Again, this is not entirely true: the proper way for a port to
not accidently pick up unwanted dependencies is to say --disable-whatever
in the Portfile (and yes, I have run into that problem in ports
I maintain). Not all ports provide a way to declare this, so
you make sure it doesn't happen by removing /usr/local altgether,
or making the user remove his /usr/local, which you will agree is
a pretty extreme measure on a UNIX system.

That's not repeatable build, that's alibism; in fact, it is
exactly what you were (rightfully) arguing against before:
such a build is only repeatable on systems that do look like
the maintainer's system, namely, they do not have anything in /usr/local.

In other words, the thing that makes your build "repeatable"
is that there is nothing around that the port might accidentally
pick up, not that macports is under /opt/local.

Obviously, to be able to do this, you must have macports
somewhere else than /usr/local, because /usr/local might
be at certain ports REQUIRED NOT TO EXIST. This explicit
reason is what I am missing in the FAQ.


> > > Isolation of the package system is part of what makes this possible.
> >
> > In what way exactly does having /opt/local make this possible
> > as opposed to having /usr/local, which would not make it possible?
> >
> Because, as you repeatedly point out, *other* software (not related to
> MacPorts) is also installed in that location.

But the problem is not that the incompatible third party software
is installed IN THAT LOCATION; the problem is that incompatbile
software is found and picked up AT ALL. Having macports in /opt/local
does not solve this; not having the other software around is what does.

> If it's all intermingled, I can't reliably keep it from being found
> and used when building software for MacPorts.

An if it's NOT intermingled (specifically, macports stuff under /opt/local,
other stuff under /usr/local) IT WILL STILL be found and used. Do you 
see my point now?

> If MacPorts is in its own tree, I can at absolute worst move
> other trees to archival storage (but usually just rename them to something
> that won't be searched automatically the way /usr/local is)

Yes, that will solve it. But only this, what you call absolute worst,
is actually the point that makes the build repeatable, isn't it.

> and now I can
> do a build which I *know* doesn't depend on some other software I'd
> forgotten about.  This is important if I intend that build (or in the case
> of MacPorts, the Portfile that does the build) to be usable by other people
> on random other machines.

Yes - as long as they also do not have /usr/local on their system,
which they most probably do.

> This is what "repeatable build" is about.

No. It would be "repeatable" if it built as fine on a system
that has shit under /usr/local as it does on your system that does not.
That would be repeatable. Requiring the user to make his system
look (temporarily) like yours is not what you could call repeatable.


> > How does that exclude stuff from any package system?
> 
> This is based on the BSD model, which as I just described above is actually
> fairly broken.  See for comparison what Linux's FHS has to say about it
> (FHS also learned from BSD's mistake).

I have been using this mistaken, broken system
for years without problems, thank you.

> > > No package system should be touching /usr/local.
> > Where did you get this? No really, where does this come from?
> Years of experience by most people who have to manage anything larger than
> their one home system,

Such as FreeBSD or OpenBSD?


I really don't mean this to be offensive in any way.
I am glad I have macports, and it helps me very much.

I just think that the explanation about /opt/local
and /usr/local in the FAQ is not very clear.

I will try to come up with a better reformulation based
on what people have explained to me here.

At any ra