Re: querying the registry for installed files

[Vincent Habchi]

> if ‘exp’ is the expression you’re looking for (e.g. ‘%qt4%’ for all files 
> containing …qt4…)
> 
> sqlite> WITH i AS (SELECT id FROM files WHERE path LIKE exp GROUP BY id) 
> SELECT name FROM ports, i WHERE ports.id = i.id;
> 
> Assuming you want the name of the ports which provides the files you’re 
> looking for

Oh, if you want the files, a simple

SELECT path FROM ports WHERE path LIKE exp; 

is enough!

V.

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

Re: querying the registry for installed files

[Vincent Habchi]

sqlite3 register.db

if ‘exp’ is the expression you’re looking for (e.g. ‘%qt4%’ for all files 
containing …qt4…)

sqlite> WITH i AS (SELECT id FROM files WHERE path LIKE exp GROUP BY id) SELECT 
name FROM ports, i WHERE ports.id = i.id;

Assuming you want the name of the ports which provides the files you’re looking 
for

Vincent

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

Re: Moving to GitHub: Status Update, Action Required

[Vincent Habchi]

> 
> You should check with the developers of Coda on their Git support. I
> don't think a tool built especially for website editing will be the best
> choice, but maybe it works for you.

Otherwise I also use PyCharm free edition for some Python related tasks, and it 
seems to have built-in GitHub support, so maybe that should work too.

Thanks anyway for the hard work.

Vincent

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

Re: Moving to GitHub: Status Update, Action Required

[Vincent Habchi]

Guys,

I’ve bought Coda 2 when I use to do a bit of HTML development. Can I use it to 
check out - tinker with the new MacPorts GIT repository?

TIA,
Vincent

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

Re: Trac down?

[Vincent Habchi]

> On 20 Oct 2016, at 21:12, Lawrence Velázquez  wrote:
>> 
>> Yeah, I get that, but I mean: so nothing has changed yet: SVN is still 
>> supposed to work the way it always did (at least to my knowledge).
> 
> Right.

Thanks! I get out of your hair.

V.

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

Re: Trac down?

[Vincent Habchi]

Hey,

> On 20 Oct 2016, at 14:04, Ryan Schmidt  wrote:
> 
>> On Oct 20, 2016, at 6:48 AM, Peter Danecek  wrote:
>> 
>> Hi all,
>> I am current not able to reach the trac server. Is this a real issue, or 
>> just a local problem here?
> 
> Trac, svn, www-origin and guide-origin are inaccessible outside of the Apple 
> network. I'm trying to figure out why.

I’ve been very busy lately and didn’t have much time but for very perfunctory 
looks at MacPorts. Now I’m almost back but… it doesn’t work. This has nothing 
to do with migrating to git or whatever?

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

Re: tk +quartz -x11 dependency on libX11. Why?

[Vincent Habchi]

Hi Josh!

> On 13 mai 2016, at 16:30, Joshua Root  wrote:
> 
> As the comment in the quartz variant in the portfile says:
> # tk.h still includes and uses types from X11/Xlib.h

Yep, but I commented the line below, and it compiled fine. So this comment must 
somehow be outdated.

V.

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

tk +quartz -x11 dependency on libX11. Why?

[Vincent Habchi]

Hi there,

why does tk +quartz -x11 depend on libX11? I commented out that line in the 
Portfile and it compiled fine.
Leaving that (dangling) dependency alive means installing a lot of cruft.

Cheers!
Vincent

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

Re: VLC cannot play MKV files?

[Vincent Habchi]

>> I was under the impression that Apple already compressed the files and 
>> programs installed with the operating system, using HFS compression, ever 
>> since taking up less disk space was listed as a feature of Snow Leopard.
> Yeah, I thought so too, but I also have the impression that may not always 
> work as advertised after a few updates have been applied. Easy enough to 
> check with `ls -lO` (/usr/bin/ls that is).

I’ve applied René method, disabling SIP while compressing /Applications. It 
gave me some significant savings, thus I surmise all the applications are not 
compressed. Xcode is, though, but things like iWorks (Pages, etc.) are not.

I am not space savings in Snow Leopard were the result of using file 
compression. I’d rather wager Apple get rid of some universal code (ppc/ppc64) 
in 10.6. 10.5 was the final version usable with ppc, AFAIR.

Vincent

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

Re: VLC cannot play MKV files?

[Vincent Habchi]

> This typically doesn't take a lot of space, and no compiler option will 
> remove the unused code in software that was meant to support different CPUs 
> at runtime…

Except that you can use configure to detect what model of processor you’re 
running on, and then with a -D flag eliminate all the code that is not targeted 
for your CPU (via #ifdef/#ifndef).

> My approach is to run the build on only 3 of the 4 cores I have, and with 
> "nice -15". Building Qt5 (without QtWebengine) takes just a bit over 2h that 
> way, as long as I don't use link-time optimisation (on a 2011 MBP with an i7).

> Have you tried renicing the compilation up or the VLC instance down?

No, I didn’t. I am aware I should, but Qt5 with the QtWebEngine takes forever 
to compile, I’m not sure I want the ordeal to drag on. But next time I will 
(or, more probably, I will start the compilation before leaving to work).

> Check out port:afsctool, HFS compression can make a considerable difference.

I wasn’t aware of it. Thanks! It saves more than 60% with VLC. Cool.

> Why not, but I'm not planning to do anything with VLC for the time being…

Okay, won’t bother you with it then. I’ll keep it private.

Have a great day/night, depending on your exact TZ.

Vincent


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

Re: VLC cannot play MKV files?

[Vincent Habchi]

> Sure. And it is probably also very easy to introduce regressions that way if 
> the #ifdefs aren't already in place.

Yeah, that’s right. Every cloud has its silver lining. Or the contrary for that 
matter.

> It'll do the same with your /Applications directory or the entire /opt/local 
> tree.

Except that it’s no longer possible to compress the build-in Applications with 
OS X 10.11 since Apple introduced SIP 
(http://arstechnica.com/apple/2015/09/os-x-10-11-el-capitan-the-ars-technica-review/8/#h1).
 Even root cannot modify the protected applications (it’s still possible, but 
it’s a darn intricate process to do it).

V.

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

Re: VLC cannot play MKV files?

[Vincent Habchi]

Hi René,

> Any MKV file? What VLC version?

Latest one:

port installed | grep VLC
VLC @2.1.5_7+mod+mpc+osd+qtkit+quartz (active)

> What does the VLC log tell you (either in-app or by launching the app bundle 
> executable directly from a terminal, with the -vvv argument)?

You will find the relevant part of the log hereafter. It seems VLC does not 
recognise the header, and there is an unknown error at some point that looks 
ominous.

Thanks for looking into this!
Cheers!
Vincent

—

/Applications/MacPorts/VLC.app/Contents/MacOS/VLC -vvv 
/Volumes/Archives/Vidéos/Series/MLP\ FIM\ S4/YP-7Z-04x01.mkv
VLC media player 2.1.5 Rincewind (revision 2.1.4-49-gdab6cb5)
[0x7ffca242b0b0] main libvlc debug: VLC media player - 2.1.5 Rincewind
[0x7ffca242b0b0] main libvlc debug: Copyright © 1996-2014 the VideoLAN team
[0x7ffca242b0b0] main libvlc debug: revision 2.1.4-49-gdab6cb5
[0x7ffca242b0b0] main libvlc debug: configured with ./configure  
'--prefix=/opt/local' 
'--with-contrib=/opt/local/var/macports/build/_Macports_dports_multimedia_VLC/VLC/work/vlc-2.1.5/contrib'
 '--enable-shared' '--disable-debug' '--disable-update-check' '--disable-dbus' 
'--disable-growl' '--disable-notify' '--enable-gnutls' '--disable-lua' 
'--disable-decklink' '--disable-dv1394' '--disable-gnomevfs' 
'--disable-libfreerdp' '--disable-libvnc' '--disable-linsys' 
'--disable-macosx-eyetv' '--disable-opencv' '--disable-realrtsp' 
'--disable-smbclient' '--disable-v4l2' '--disable-vcdx' '--enable-bluray' 
'--enable-dc1394' '--enable-dvdnav' '--enable-dvdread' '--enable-libcddb' 
'--enable-sftp' '--enable-vcd' '--disable-dvbpsi' '--disable-gme' 
'--disable-sid' '--disable-shout' '--enable-mkv' '--enable-mux_ogg' 
'--enable-ogg' '--disable-crystalhd' '--disable-dxva2' '--disable-fdkaac' 
'--disable-kate' '--disable-libass' '--disable-libva' '--disable-live555' 
'--disable-omxil' '--disable-omxil-vout' '--disable-quicksync' 
'--disable-quicktime' '--disable-rpi-omxil' '--disable-speex' '--disable-tiger' 
'--disable-wma-fixed' '--disable-shine' '--disable-zvbi' '--enable-a52' 
'--enable-avcodec' '--enable-avformat' '--enable-dca' '--enable-dirac' 
'--enable-faad' '--enable-flac' '--enable-fluidsynth' '--enable-mad' 
'--enable-opus' '--enable-png' '--enable-postproc' '--enable-schroedinger' 
'--enable-swscale' '--enable-telx' '--enable-theora' '--enable-twolame' 
'--enable-vorbis' '--enable-x264' '--without-x' '--disable-aa' '--disable-caca' 
'--disable-egl' '--disable-fribidi' '--disable-gles1' '--disable-gles2' 
'--disable-glx' '--disable-sdl' '--disable-sdl-image' '--disable-svg' 
'--disable-vdpau' '--disable-xcb' '--disable-xvideo' '--disable-chromaprint' 
'--disable-jack' '--disable-pulse' '--disable-macosx-dialog-provider' 
'--disable-qt' '--disable-skins2' '--enable-ncurses' '--disable-goom' 
'--disable-projectm' '--disable-vsxu' '--disable-mtp' '--disable-udev' 
'--enable-bonjour' '--enable-upnp' '--enable-macosx-vout' 
'--enable-macosx-audio' '--with-macosx-sdk=/' '--enable-macosx-vlc-app' 
'--enable-mod' '--enable-mpc' '--enable-freetype' '--enable-fontconfig' 
'--enable-macosx-qtkit' '--enable-macosx' '--enable-macosx-avfoundation' 
'--disable-samplerate' '--enable-merge-ffmpeg' '--enable-realrtsp' 
'--enable-libass' 'CC=/usr/bin/clang' 'CFLAGS=-pipe -Os -arch x86_64' 
'LDFLAGS=-L/opt/local/lib -Wl,-headerpad_max_install_names -arch x86_64' 
'CPPFLAGS=-I/opt/local/include -D__unix__=1' 'CXX=/usr/bin/clang++' 
'CXXFLAGS=-pipe -Os -stdlib=libc++ -arch x86_64' 'OBJC=/usr/bin/clang' 
'OBJCFLAGS=-pipe -Os -arch x86_64' 'CXXCPP=/usr/bin/clang++ -E'
[0x7ffca242b0b0] main libvlc debug: searching plug-in modules
[0x7ffca242b0b0] main libvlc debug: loading plugins cache file 
/Applications/MacPorts/VLC.app/Contents/MacOS/plugins/plugins.dat
[0x7ffca242b0b0] main libvlc debug: recursively browsing 
`/Applications/MacPorts/VLC.app/Contents/MacOS/plugins'
[0x7ffca242b0b0] main libvlc debug: saving plugins cache 
/Applications/MacPorts/VLC.app/Contents/MacOS/plugins/plugins.dat
[0x7ffca242b0b0] main libvlc debug: plug-ins loaded: 351 modules
[0x7ffca242b0b0] main libvlc debug: opening config file 
(/Users/vincent/Library/Preferences/org.videolan.vlc/vlcrc)
[0x7ffca242b0b0] main libvlc debug: translation test: code is "C"
[0x7ffca242b0b0] main libvlc debug: CPU has capabilities MMX MMXEXT SSE SSE2 
SSE3 SSSE3 SSE4.1 SSE4.2 FPU 
[0x7ffca24449a0] main input debug: Creating an input for 'Media Library'
[0x7ffca24449a0] main input debug: Input is a meta file: disabling unneeded 
options
[0x7ffca24449a0] main input debug: using timeshift granularity of 50 MiB, in 
path '/tmp'
[0x7ffca24449a0] main input debug: 
`file/xspf-open:///Users/vincent/Library/Application%20Support/org.videolan.vlc/ml.xspf'
 gives access `file' demux `xspf-open' path 
`/Users/vincent/Library/Application%20Support/org.videolan.vlc/ml.xspf'
[0x7ffca24449a0] main input debug: creating demux: access='file' 
demux='xspf-open' 

VLC cannot play MKV files?

[Vincent Habchi]

Hi there,

I’ve a strange problem with VLC. Clicking on a MKV file will not crash the app, 
but it will go into a sort of infinite loop, as if it was not finding anything 
to play inside the file and kept on trying again.

ffplay with the same file works fine, though, so this is not a library issue.

Any idea what could possibly be wrong?

Thanks,
Vincent

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

Re: VLC cannot play MKV files?

[Vincent Habchi]

> 
> That's indeed that latest one provided through MacPorts, but not the latest 
> VLC version. I've submitted a port for 2.2.1 on Trac months ago, but it has 
> never been committed.

There’s a “beta” 2.2.2-20150427_3 available on MacPorts, I’ll try it and let 
you know.

> Might I suggest that you download the latest VLC player from videolan.org 
> directly, and see if that one gives the same error? If it doesn't, you can 
> then probably simply uninstall the one from MacPorts.

Yep, I could do that, but I would have to uninstall all the libraries I’ve 
installed to save space, and that wouldn’t be fun.

Thanks for your help! 
Vincent

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

Re: VLC cannot play MKV files?

[Vincent Habchi]

> Ah, not mine AFAIK. The portfile I submitted on Trac *probably* contains a 
> VLC-devel port for 3.0.0-150503-g7385062d (my local copy does), but I don't 
> think I tried building or using that one since May last year (1505).

I could have a stab at compiling it, if you want.

> If you only installed those libraries for VLC then you shouldn't lose much. 
> You would however have more definite proof whether your issue is due to 
> something with the MacPorts build or in VLC itself. If the latter, you should 
> take it up on the VLC bug tracker.

The pre-packaged VLC works fine. It’s definitely something wrong with MacPorts 
somewhere.

The other reason I prefer to use the compiled VLC is, well, to optimise the 
code. I suppose compiling with -march=native gives a slightly better code than 
the standard bundle which must work on every hardware. I am not sure this is 
really signifiant, though. 

Finally, I can disable much cruft, like the LUA interface, RTP and so on, I 
don’t need.

Overall, I might be over-cautious. :B

Vincent

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

Re: VLC cannot play MKV files?

[Vincent Habchi]

René,

I compiled VLC 2.2.1 using Macports and still have the same error :(
Seems something is wrong in the MacPorts librairies, but where?

Cheers!

—

VLC media player 2.2.2 Weatherwax (revision 2.2.1-21-g2502874)
[7f9f92f00378] core libvlc debug: VLC media player - 2.2.2 Weatherwax
[7f9f92f00378] core libvlc debug: Copyright © 1996-2015 the VideoLAN team
[7f9f92f00378] core libvlc debug: revision 2.2.1-21-g2502874
[7f9f92f00378] core libvlc debug: configured with ./configure  
'--prefix=/opt/local' 
'--with-contrib=/opt/local/var/macports/build/_Macports_dports_multimedia_VLC-devel/VLC-devel/work/VLC-devel-2.2.1/contrib'
 '--disable-debug' '--disable-update-check' '--enable-gnutls' 
'--disable-notify' '--disable-dbus' '--disable-lua' '--disable-gnomevfs' 
'--disable-growl' '--enable-dvdnav' '--enable-dvdread' '--disable-smbclient' 
'--enable-vcdx' '--disable-realrtsp' '--disable-freerdp' '--disable-opencv' 
'--enable-sftp' '--enable-dvbpsi' '--enable-mux_ogg' '--enable-mkv' 
'--enable-mod' '--enable-mpc' '--disable-shout' '--enable-a52' '--enable-faad' 
'--enable-flac' '--enable-live555' '--enable-opus' '--enable-vorbis' 
'--enable-ogg' '--enable-mad' '--enable-libass' '--enable-dca' '--enable-png' 
'--disable-quicktime' '--enable-twolame' '--enable-speex' '--enable-theora' 
'--enable-x264' '--enable-postproc' '--enable-avcodec' '--enable-avformat' 
'--enable-swscale' '--disable-fluidsynth' '--enable-schroedinger' 
'--enable-vpx' '--disable-caca' '--enable-sdl' '--enable-sdl-image' 
'--without-x' '--disable-xcb' '--disable-xvideo' '--enable-freetype' 
'--enable-fontconfig' '--enable-fribidi' '--disable-svg' '--disable-jack' 
'--enable-samplerate' '--disable-qt' '--enable-ncurses' '--disable-skins2' 
'--disable-goom' '--enable-bonjour' '--enable-upnp' '--enable-macosx-eyetv' 
'--enable-macosx-vlc-app' '--enable-macosx-qtkit' '--enable-macosx' 
'--enable-macosx-dialog-provider' 'CC=/usr/bin/clang' 'CFLAGS=-pipe -Os -arch 
x86_64' 'LDFLAGS=-L/opt/local/lib -Wl,-headerpad_max_install_names -arch 
x86_64' 'CPPFLAGS=-I/opt/local/include -D__unix__=1 -DFREERDP_INTERFACE_VERSION 
-DFREERDP_VERSION_MAJOR=1 -DFREERDP_VERSION_MINOR=1 
-I/opt/local/lib/live/liveMedia/include' 'CXX=/usr/bin/clang++' 'CXXFLAGS=-pipe 
-Os -stdlib=libc++ -arch x86_64' 'OBJC=/usr/bin/clang' 'OBJCFLAGS=-pipe -Os 
-arch x86_64' 'CXXCPP=/usr/bin/clang++ -E'
[7f9f92f00378] core libvlc debug: searching plug-in modules
[7f9f92f00378] core libvlc debug: loading plugins cache file 
/Applications/MacPorts/VLC.app/Contents/MacOS/plugins/plugins.dat
[7f9f92f00378] core libvlc debug: recursively browsing 
`/Applications/MacPorts/VLC.app/Contents/MacOS/plugins'
[7f9f92f00378] core libvlc debug: saving plugins cache 
/Applications/MacPorts/VLC.app/Contents/MacOS/plugins/plugins.dat
[7f9f92f00378] core libvlc debug: plug-ins loaded: 389 modules
[7f9f92f00378] core libvlc debug: opening config file 
(/Users/vincent/Library/Preferences/org.videolan.vlc/vlcrc)
[7f9f92f00378] core libvlc debug: translation test: code is "C"
[7f9f92f00378] core libvlc debug: CPU has capabilities MMX MMXEXT SSE SSE2 
SSE3 SSSE3 SSE4.1 SSE4.2 FPU 
[7f9f92c3d438] core input debug: Creating an input for 'Media Library'
[7f9f92c3d438] core input debug: Input is a meta file: disabling unneeded 
options
[7f9f92c3d438] core input debug: using timeshift granularity of 50 MiB, in 
path '/tmp'
[7f9f92c3d438] core input debug: 
`file/xspf-open:///Users/vincent/Library/Application%20Support/org.videolan.vlc/ml.xspf'
 gives access `file' demux `xspf-open' path 
`/Users/vincent/Library/Application%20Support/org.videolan.vlc/ml.xspf'
[7f9f92c3d438] core input debug: creating demux: access='file' 
demux='xspf-open' 
location='/Users/vincent/Library/Application%20Support/org.videolan.vlc/ml.xspf'
 file='/Users/vincent/Library/Application Support/org.videolan.vlc/ml.xspf'
[7f9f92c409e8] core demux debug: looking for access_demux module matching 
"file": 15 candidates
[7f9f92c409e8] core demux debug: no access_demux modules matched
[7f9f92c3d438] core input debug: creating access 'file' 
location='/Users/vincent/Library/Application%20Support/org.videolan.vlc/ml.xspf',
 path='/Users/vincent/Library/Application Support/org.videolan.vlc/ml.xspf'
[7f9f92f1bc68] core access debug: looking for access module matching 
"file": 19 candidates
[7f9f92f1bc68] filesystem access debug: opening file 
`/Users/vincent/Library/Application Support/org.videolan.vlc/ml.xspf'
[7f9f92f1bc68] core access debug: using access module "filesystem"
[7f9f92c40c28] core stream debug: Using stream method for AStream*
[7f9f92c40c28] core stream debug: starting pre-buffering
[7f9f92c40c28] core stream debug: received first data after 0 ms
[7f9f92c40c28] core stream debug: pre-buffering done 296 bytes in 0s - 3754 
KiB/s
[7f9f92c40f28] core stream debug: looking for stream_filter module matching 
"any": 9 candidates

Re: VLC cannot play MKV files?

[Vincent Habchi]

> You might want to look at the following to clean up those libraries:
> 
> $ port info port_cutleaves

[…]

Thanks Craig!

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

Re: VLC cannot play MKV files?

[Vincent Habchi]

Craig:

> Do other mkv files play OK?

I haven’t many MKV files, all from the same source, and none plays correctly on 
VLC.
FFPLAY has no difficulty reading them.

Strange.

Output of mediainfo:

> mediainfo /Volumes/Archives/Vidéos/Series/MLP\ FIM\ S4/YP-7Z-04x02.mkv 
General
Unique ID: 
206008566657813998729350314970436825804 (0x9AFBCE86080DD11183450EA6D0E772CC)
Complete name: /Volumes/Archives/Vidéos/Series/MLP 
FIM S4/YP-7Z-04x02.mkv
Format   : Matroska
Format version   : Version 2
File size: 521 MiB
Duration : 22mn 3s
Overall bit rate : 3 304 Kbps
Encoded date : UTC 2013-11-25 19:01:06
Writing application  : mkvmerge v5.3.0 ('I could have 
danced') built on Feb  9 2012 10:38:07
Writing library  : libebml v1.2.3 + libmatroska v1.3.0

Video
ID   : 1
Format   : AVC
Format/Info  : Advanced Video Codec
Format profile   : High@L4.1
Format settings, CABAC   : Yes
Format settings, ReFrames: 9 frames
Codec ID : V_MPEG4/ISO/AVC
Duration : 22mn 3s
Width: 1 280 pixels
Height   : 720 pixels
Display aspect ratio : 16:9
Frame rate mode  : Constant
Frame rate   : 23.976 fps
Color space  : YUV
Chroma subsampling   : 4:2:0
Bit depth: 8 bits
Scan type: Progressive
Title: S04E02 : Princess Twilight Sparkle 
(2)
Writing library  : x264 core 135 r2345 f0c1c53
Encoding settings: cabac=1 / ref=9 / deblock=1:1:1 / 
analyse=0x3:0x113 / me=umh / subme=8 / psy=1 / psy_rd=0.40:0.00 / mixed_ref=1 / 
me_range=16 / chroma_me=1 / trellis=1 / 8x8dct=1 / cqm=0 / deadzone=21,11 / 
fast_pskip=1 / chroma_qp_offset=-2 / threads=3 / lookahead_threads=1 / 
sliced_threads=0 / nr=0 / decimate=1 / interlaced=0 / bluray_compat=0 / 
constrained_intra=0 / bframes=5 / b_pyramid=2 / b_adapt=2 / b_bias=0 / direct=3 
/ weightb=1 / open_gop=0 / weightp=2 / keyint=250 / keyint_min=23 / scenecut=40 
/ intra_refresh=0 / rc_lookahead=50 / rc=crf / mbtree=1 / crf=17.0 / qcomp=0.60 
/ qpmin=0 / qpmax=69 / qpstep=4 / ip_ratio=1.40 / aq=1:0.60
Language : English
Default  : Yes
Forced   : No

Audio #1
ID   : 2
Format   : AC-3
Format/Info  : Audio Coding 3
Mode extension   : CM (complete main)
Format settings, Endianness  : Big
Codec ID : A_AC3
Duration : 22mn 3s
Bit rate mode: Constant
Bit rate : 384 Kbps
Channel(s)   : 6 channels
Channel positions: Front: L C R, Side: L R, LFE
Sampling rate: 48.0 KHz
Bit depth: 16 bits
Compression mode : Lossy
Stream size  : 60.6 MiB (12%)
Title: [ENG] AC3 5.1
Language : English
Default  : Yes
Forced   : No

Audio #2
ID   : 3
Format   : AAC
Format/Info  : Advanced Audio Codec
Format profile   : LC
Codec ID : A_AAC
Duration : 22mn 3s
Channel(s)   : 2 channels
Channel positions: Front: L R
Sampling rate: 48.0 KHz
Compression mode : Lossy
Title: [ENG] AAC 2.0
Language : English
Default  : No
Forced   : No


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

Re: Vector graphic with the MacPorts logo

[Vincent Habchi]

> We have a 366x140 version:
>https://www.macports.org/img/macports-logo-top.png
> but that doesn't change anything: we still need a vector version.

Doesn’t inkscape have a vectoriser module?

Vincent

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

Re: Vector graphic with the MacPorts logo

[Vincent Habchi]

> I tried a couple of options (such as WhatTheFont.com), but no exact match.
> When looking for the font, look for the uncommon capital M and the slight
> bulge on the top of the capital P.

Best way is to vectorise it as paths.

V.

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

Re: Vector graphic with the MacPorts logo

[Vincent Habchi]

SVG version. It might need to have the font loaded, though. What we can do is 
transform the letters into paths.

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

Re: Vector graphic with the MacPorts logo

[Vincent Habchi]

Hi Mojka,

here is a version where the letters have been transformed in paths, so one may 
adjust the letters individually.

I’m not sure I’m going to have much time to do the small trimming you talk 
about. Will try to have a stab at it, though.

Vincent

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

Re: Migration woe

[Vincent Habchi]

> On 27 Nov 2015, at 19:43, Brandon Allbery  wrote:
> 
> Reinstall from the installer for that platform, yes.

Okay, that’s what I suspected.

Thanks and 73s Brandon.
Vincent

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

Migration woe

[Vincent Habchi]

Folks,

I really feel self-conscious to ask that, because I’m sure you’ve already been 
flaked with such questions a couple of month ago, but since trac is down…

I’ve been upgrading one of my boxes to 10.11. Unfortunate idea, since I can’t 
use “port” anymore, being greeted with an aggressive bark “platforms do not 
match” each time I try to punch a command.

How am I supposed to upgrade? Should I reinstall base first?

Thanks,
Vincent
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: Trac down

[Vincent Habchi]

> I can only tell you that due to high memory use, the system started killing 
> processes to free memory; that apparently included the web server and the ssh 
> server. I don’t know what caused the high memory use.

Thanks Ryan!

Have a great day!
Vincent

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

Re: QScintilla and Qwt with Qt5

[Vincent Habchi]

Hi Mojca,

> I'm not sure what the relation between Scite and QScintilla is.

Well, I’m not sure either, except that the spellchecker of my iPhone wants to 
substitute Scintilla by Scite, I guess.
And it is doggedly fixed on that. :(

> Is http://foicica.com/scintillua/README.html compatible with
> QScintilla? If so, it might be interesting to figure out if we could
> get it working.

Hmm… Will have to check out.

Cheers!
Vincent

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

QScintilla and Qwt with Qt5

[Vincent Habchi]

Folks,

I’ve been able to patch the Portfiles for QScintilla and Qwt and get something 
useable with Qt5.
If you’re interested in getting a copy of these, please let me know.

Vincent

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

Re: Qt5 port unparsable: can't read "qt_archdata_dir": no such variable

[Vincent Habchi]

Ryan,

> qt_archdata_dir should be set in the qt5 1.0 portgroup. Do you perhaps have 
> local modifications to this portgroup that are conflicting with the official 
> version?

Bullseye! But if I delete my qt5-1.0.tcl file and try to recreate it with SVN, 
I get this:

> svn update
Updating '.':
Skipped 'qt5-1.0.tcl' -- Node remains in conflict

And I get no port-group file restored.

Any idea?

Thanks,
Vincent
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: Qt5 port unparsable: can't read "qt_archdata_dir": no such variable

[Vincent Habchi]

On 23 Nov 2015, at 20:49, David Strubbe  wrote:
> 
> Do 'svn revert' on it.

Thanks! I’m really a noob when it comes to svn use.

Vincent

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

Qt5 port unparsable: can't read "qt_archdata_dir": no such variable

[Vincent Habchi]

Folks,

every time I update my tree from svn I get this message:

“Failed to parse file aqua/qt5/Portfile with subport 'qt5-qtbase': can't read 
"qt_archdata_dir": no such variable”

And of course I cannot build Qt5. Has someone a clue?

Thanks,
Vincent

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

Re: New Mac OS Forge administrator

[Vincent Habchi]

Ryan,

> I'm pleased finally to be able to tell you that I have been hired to be your 
> new Mac OS Forge administrator. I have been involved in improving MacPorts 
> for years as a committer and as a manager, and now as a Mac OS Forge 
> administrator I will work on ensuring our infrastructure runs smoothly too.

That’s great news. Your dedication to the project as well as your expertise is 
unparalleled. It’s a great move, and I’m very happy you’ve been chosen.

I’m sure you will shine in your new responsibilities!
All the best!
Vincent

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

Migration fails in images_to_archives – what am I supposed to do

[Vincent Habchi]

Folks,

I’m trying to migrate Macports properly rebuilding base, but something fails:

Air > sudo make install
===> making install in vendor
===> making install in vendor/tcl8.5.15/unix
Installing libtcl8.5.dylib to /opt/local/libexec/macports/lib/
Installing tclsh as /opt/local/libexec/macports/bin/tclsh8.5
Installing tclConfig.sh to /opt/local/libexec/macports/lib/
Installing libtclstub8.5.a to /opt/local/libexec/macports/lib/
Installing message catalog files to /opt/local/libexec/macports/lib/tcl8.5/msgs/
Installing header files to /opt/local/libexec/macports/include/
[…]
/opt/local/libexec/macports/bin/tclsh8.5 ./src/images_to_archives.tcl
This could take a while...
Processing 1 of 349: XviD-1.3.3_0.darwin_15.x86_64.tbz2
Processing 2 of 349: shared-mime-info-1.4_0.darwin_15.x86_64.tbz2
Processing 3 of 349: opencv-3.0.0_0.darwin_15.x86_64.tbz2
Processing 4 of 349: ffmpeg-2.7.2_0+gpl2.darwin_15.x86_64.tbz2
Command failed: /usr/bin/tar -cjf 
/opt/local/var/macports/software/ffmpeg/ffmpeg-2.7.2_0+gpl2.darwin_15.x86_64.tbz2
 -T /opt/local/var/macports/software/ffmpeg/tarlist > 
/opt/local/var/macports/software/ffmpeg/error.log 2>&1
Exit code: 1
command execution failed
while executing
"system "$tarcmd -cjf $newlocation -T ${targetdir}/tarlist > 
${targetdir}/error.log 2>&1""
("foreach" body line 78)
invoked from within
"foreach installed $ilist {
incr counter
set iname [lindex $installed 0]
set iversion [lindex $installed 1]
set irevision [lindex $inst..."
(file "./src/images_to_archives.tcl" line 38)
make: *** [install] Error 1

Any hint or kludge?

Thanks a lot!
Vincent

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

Re: Migration fails in images_to_archives – what am I supposed to do

[Vincent Habchi]

Rainer:

>> Bang on. I keep as little archives as possible, because my SSD is cramped (I 
>> have a 128 MB version) and I don’t want to cram it with files I seldom if 
>> ever use.
> 
> I really hope you actually got 128 GB ;-)

Oops. Well… You know, back in the ‘80s, I clearly remember a then-friend having 
an Atari Megafile 30 HD I was dreaming of. That was 30 MB… Not even 20 
floppies, but so much faster.

> Just be aware that activate/deactivate will not work when the archive
> tarball is no longer available.

Yeah, I remember a discussion involving Ryan on this particular heads-up not so 
long ago.

> You could temporarily remove the invocation of images_to_archives.tcl
> from the top-level Makefile. However, the actual install is already
> completed at that point, so you can just continue using the installed
> port command.

Great. Just what I needed to know. Thanks a lot for your help!
Vincent
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

[Personal apology] Sorry

[Vincent Habchi]

Guys,

I haven’t been much active lately and I apologise. I’d a tough September, and, 
I own up, procrastinated a bit knowing that 10.11 was about to be released. 
Will resume normal activity as soon as I get over the whole migration shebang.

Thanks for your patience!
Vincent

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

Re: Why is Python 2.7 dependent on db46 and only db46

[Vincent Habchi]

 On 21 Jul 2015, at 19:27, Daniel J. Luke dl...@geeklair.net wrote:
 
 IIRC oracle changed the bdb license after 4.6. I have a dim recollection that 
 I was going to try to look over the new license to make sure it was 
 reasonable to update the bdb that apr-util (and subversion) use, but I never 
 got around to it.
 
 If someone has looked it over and it’s OK, we should just update everything 
 to whatever the latest (compatible) version is.

Wikipedia says db60 is licenced under the GNU AGPL v3.


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

Re: Why is Python 2.7 dependent on db46 and only db46

[Vincent Habchi]

 On 21 Jul 2015, at 16:02, Brandon Allbery allber...@gmail.com wrote:
 
 On Tue, Jul 21, 2015 at 10:00 AM, Clemens Lang c...@macports.org wrote:
 - On 21 Jul, 2015, at 15:43, Rainer Müller rai...@macports.org wrote:
 
  And even if the default +db* variant selection depends on the local
  active db* version, I guess such a change would trigger more local
  builds instead of using binary archives which should be preferred for
  most users.
 
 However, what we could do -- and I'd argue we should -- is choose a single
 blessed version of db and try to use it everywhere. Normally, that would
 just be the latest version.
 
 Last I checked, upgrading existing data files was not automatic. 

And something approaching what we do with perl/python, that is using a generic 
port as a proxy for a chosen version?


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

Why is Python 2.7 dependent on db46 and only db46

[Vincent Habchi]

Hi there,

I recently had a look on the smörgåsbord of ports installed on my computer, and 
I found out three different versions of db: db44 db46 db48. Turns out a lot of 
ports have a fixed dependency on one of the db* ports, which in turn implies 
that a lot of different versions of db4 have to be installed – to no avail, 
since those ports provide the same service; worse, db5* and the most recent 
db6* are, it seems, totally ignored. Example of this is Python27 that requires 
db46, but works fine with db60.

In new the port cyrus5-imapd I committed this morning, I wrote some dynamic 
code to detect the installed db* version and go along with it, instead of 
forcing the installation of another version. Could this mechanism be extended, 
maybe though a port class?

Thanks,
Vincent

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

Re: [MacPorts] #43758: eero-devel @3.2.2012-11-18: Cannot stat: .../lang/eero-devel/files/llvm-bin, No such file or directory

[Vincent Habchi]

 On 18 May 2015, at 05:42, MacPorts nore...@macports.org wrote:
 
 #43758: eero-devel @3.2.2012-11-18: Cannot stat: 
 .../lang/eero-devel/files/llvm-
 bin, No such file or directory
 ---+-
  Reporter:  ryandesign@…  |  Owner:  vince@…
  Type:  defect| Status:  closed
  Priority:  Normal|  Milestone:
 Component:  ports |Version:  2.2.1
 Resolution:  fixed |   Keywords:
  Port:  eero-devel|
 ---+-
 Changes (by ryandesign@…):
 
 * status:  new = closed
 * resolution:   = fixed
 
 
 Comment:
 
 Yes, the (10.7 and later) buildbots built this version successfully.

Sorry for being very late on this. Blame my Internet provider. This port should 
be unplugged anyway, as the developer has tossed it. He said eero became 
irrelevant the day Swift was released.

Vincent

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

Re: [136972] trunk/dports/gis/cgal/Portfile

[Vincent Habchi]

Ryan,

 On 01 Jun 2015, at 19:24, Ryan Schmidt ryandes...@macports.org wrote:
 master_siteshttps://gforge.inria.fr/frs/download.php/file/34705/

Thanks. Done in r136973. Sorry for the flub.
Vincent


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

Re: [134799] trunk/dports/databases/postgis2/Portfile

[Vincent Habchi]

Ryan,

 I fixed the description of this variant in r134805.

Thanks. I stupidly did a copy/paste of the postgresql93 variant and overlooked 
some changes.

 -if {![variant_isset postgresql90]  ![variant_isset postgresql91]  \
 -![variant_isset postgresql92]  ![variant_isset postgresql93]} {
 +if {![variant_isset postgresql92]  ![variant_isset postgresql93]  \
 +![variant_isset postgresql94]} {
 default_variants+postgresql93
 
 }
 
 Did you want to change the default variant to postgresql94 since that is the 
 latest stable version?

Not at this point. Maybe when postgresql94 reaches version 9.4.2 or 3. It is 
always costly to migrate from one postgresql version to another one, so I 
always delay the bump a while. Besides, it lets a bit of time for the apps to 
accommodate the new version.

Thanks again!
Vincent


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

Re: [134799] trunk/dports/databases/postgis2/Portfile

[Vincent Habchi]

Ryan,

 in r129787; and in p5-dbd-pg in r130008. postgis2, py-psycopg2 and qgis 
 remain on postgresql93.
 
 Besides, it lets a bit of time for the apps to accommodate the new version.
 
 I don't recall any compatibility problems ever arising. Do you?

PostGIS is an extension to PostGreSQL and as such installs functions and code 
directly within the PostgreSQL framework rather than being an API to dialogue 
with the database. As such, it is somehow dependent on PostgreSQL guts. I 
clearly remember more than once reading in the PostGIS changelog: ‘First 
version to be compatible with PostgreSQL 9.x’, and it was not a major bump, 
like from 8.x to 9.0. That’s why I adopted a rather conservative approach.

But I’m going to upgrade at the next PostgreSQL 9.4.x sub-release.

Vincent

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

QWT 6 and Qt5

[Vincent Habchi]

Hi there,

I’m conducting a preliminary survey to switch QGis from Qt4 to Qt5.

However, said change would need QWT 6 to be linked against Qt5, which appears 
not to be case currently. I picked up on some QGis thread that QWT 6 was 
compatible with Qt5, which was not the case with the prior releases of QWT.

Could a variant be added, or maybe a specific port created?

Thanks,
Vincent

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

Re: [131354] trunk/dports/gis/cgal/Portfile

[Vincent Habchi]

 -master_siteshttps://gforge.inria.fr/frs/download.php/34150
 +master_sites
 https://gforge.inria.fr/frs/download.php/file/34403/CGAL-4.5.1.tar.bz2
 
 master_sites should be the directory the distfile is in, and should not 
 include the actual distfile name.
 master_siteshttps://gforge.inria.fr/frs/download.php/file/34403/

Done Ryan. Thanks. But for whatever reason, at the time I did update the 
Portfile, it seemed the website interface for CGAL fetched the file from this 
very directory. Hopefully the shortened form works, too.

Thanks for pointing it out.
Vincent

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

Re: [128555] trunk/dports/gis/saga

[Vincent Habchi]

Hi Ryan,

 /opt/local/Library/Frameworks should not be hardcoded here. Are you sure 
 commenting out the reinplace is correct?

Will change the hardcoded path. Thanks for pointing that out.

Yes, surprisingly it seems something has changed in the configure script 
between 2.1.3 and 2.1.4. With the new release, the configure script seems 
alright as to WxWidget configuration detection, yet somehow patching the other 
files is still necessary.

Go figure.

Have a great Sunday,
Vincent


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

Port deactivate boost hangs forever

[Vincent Habchi]

Guys,

I am in a middle of upgrading boost, but the old version seems to be a die-hard:

[…]
a 
./opt/local/include/boost/accumulators/framework/accumulators/reference_accumulator.hpp
a 
./opt/local/include/boost/accumulators/framework/accumulators/value_accumulator.hpp
---  Cleaning boost
---  Removing work directory for boost
---  Computing dependencies for boost.
---  Deactivating boost @1.56.0_1+no_single+no_static+python27
…
…
Hangs forever here. I interrupted it, tried to deactivate and de-install 
manually, to no avail.

What am I supposed to do at this point?

Thanks!
Vincent

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

Re: Port deactivate boost hangs forever

[Vincent Habchi]

Hi Chris,

 wait longer. It will take a while but will eventually finish…

Yep, it did. Thanks. But that’s really unexpected, especially since I run a MBA 
with those super-fast PCI-e SSD.
I think we ought even to warn the user about this (but I don’t think it’s 
possible).

Vincent

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

Re: Port deactivate boost hangs forever

[Vincent Habchi]

 Le 10 nov. 2014 à 10:55, Chris Jones jon...@hep.phy.cam.ac.uk a écrit :
 
 Are you running OSX 10.10 ? If so its a new issue there, somethings like this 
 are taking a lot longer than before. I guess idea is to fix it rather than 
 live with it with warnings, once someone figures out what is wrong …

Yep, I am. I just don’t know what went wrong… to quote a famous saying.

I don’t remember having had to wait so long the last time boost was updated. 
Could be it caused by a combination of:
• A high number of files;
• A high number of dependents?

Vincent

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

Re: Port deactivate boost hangs forever

[Vincent Habchi]

Hi!

 Nope, the number of files was pretty much the same on Mavericks, as was the
 number of dependents. For some reason, the performance of our SQLite database
 plummeted on 10.10; we don't know why.

Caching issue?

V.

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

Re: Please start commit message with port name.

[Vincent Habchi]

Ciao Petr,

 I'd like to propose to start commit messages with the port name. This helps 
 very much to read them for example in the Timeline.
 
 For example:
 
 https://trac.macports.org/changeset/127794 -- Correct various bugs. Bump to 
 revision 1.
 https://trac.macports.org/changeset/127795 -- Bump to version 2.1.4
 
 could become:
 
 - gdal: Correct various bugs. Bump to revision 1.
 and
 - postgis2: Bump to version 2.1.4
 respectively.

Fine. Ottima idea. 
Thanks for the suggestion!

Vincent

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

Include file clobbering / Reinplace strange behavior

[Vincent Habchi]

Guys,

I’m writing an updating port for the new version of gis/gdal.

However, the port does not compile because a .h file installed by the old 
version into ${prefix}/include masks a new version of the same .h bundled with 
the newest source.

So question 1: is there a standard workaround to address this problem?

I know the cleanest way is to switch the -I flags order so that the local 
include repertory is placed before ${prefix}/include on the compiler line 
invocation. However, that’s a pain to implement.

So, I decided to copy the culprit .h file, giving the copy a slightly different 
name, then change all #include to this new name. Finally, I use find(1) to 
locate every relevant file like this:

post-extract {
file copy ${worksrcpath}/port/cpl_port.h ${worksrcpath}/port/Cpl_port.h
set files_to_patch [exec find ${worksrcpath} -type f -exec grep -l 
cpl_port.h \{\} \;]
foreach file ${files_to_patch} {
# DEBUG
puts ${file}
reinplace s|cpl_port.h|Cpl_port.h| ${file}
}
}

However, the procedure fails at a certain point for an unknown reason:

/opt/…/frmts/grib/degrib18/degrib/grib2api.c
/opt/…/frmts/grib/degrib18/degrib/inventory.cpp
/opt/…/frmts/grib/degrib18/degrib/memendian.h
/opt/…/frmts/grib/degrib18/degrib/metaname.cpp
sed: RE error: illegal byte sequence

So it works fine (I peeked inside the printed files and the substitution has 
correctly been made) with ten or twenty files, then it suddenly breaks on a 
mundane file. 

Question 2: Does anyone have a clue why?

Thanks!
Vincent

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

Re: Non versioned ports

[Vincent Habchi]

Le 24 août 2014 à 18:53, Sean Farley s...@macports.org a écrit :

 Why not use the bitbucket port group?
 
 PortGroup   bitbucket 1.0
 bitbucket.setup petebunting rsgislib 52fb22e
 version 0.0.20140822

Uh, I tried that and it works (fetch okay), but then I have a problem.

The fetch creates a subdirectory ‘52fb22e' under ‘work’ and in this 
subdirectory, I find the ‘trunk’ directory which contains the code. Now if I 
try to modify worksrcdir to point to ‘52fb22e/trunk’, then the fetch is placed 
under this new arborescence rather than directly under ‘52fb22e’, so the code 
is now in ‘52fb22e/trunk/trunk’. Etc. Sounds like the bitbucket port uses 
‘worksrcdir’ to create the directory in which to store the code. Any workaround?

Vincent

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

Re: Non versioned ports

[Vincent Habchi]

Le 25 août 2014 à 20:07, Sean Farley s...@macports.org a écrit :

 There are a few ways to work around this. In the dolfin port, I do:
 
 configure.dir   ${worksrcpath}/build
 build.dir   ${worksrcpath}/build

Thanks, that works like a charm. I’ll commit the ports now.

Vincent


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

Re: [122649] trunk/dports/math/atlas/Portfile

[Vincent Habchi]

Ryan,

 sourceforge:project/math-atlas/Stable/${version}:atlas

Thanks. Fixed again in r122658.
Hope it works this time…

Cheers!
V.

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

Re: [122649] trunk/dports/math/atlas/Portfile

[Vincent Habchi]

Ryan,

 sourceforge:project/math-atlas/Stable/${version}:atlas

Thanks. Fixed again in r122658.
Hope it works this time…

Cheers!
V.

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

Re: MacPorts Developer Meeting?

[Vincent Habchi]

Dobro yutro Mojca,

 Location: another MacPorter lives nearby and we are willing to
 organize the event together, in the middle of Europe. We could
 choose between close to the sea and in the mountains. I would
 certainly like to avoid the cities and try to organize the event
 somewhere in the nature (but still making sure that they would have a
 decent internet connection). My preference is somewhere closer to the
 mountains (I have a few particular places in mind).

Konstanzmeer maybe? Where Germany, Switzerland and Austria meet?

‘c uskoro!

Vincent

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

Re: MacPorts Developer Meeting?

[Vincent Habchi]

Le 25 juil. 2014 à 10:55, Mojca Miklavec mo...@macports.org a écrit :

 In 2008 we had a ConTeXt meeting in Bohinj for example.
 (http://meeting.contextgarden.net/2008/, here:
 http://www.csod.si/dom/bohinj?language=en). That's not the only option
 though (and maybe not even the best one). Lodging + three meals cost
 26 EUR / day at that exact location (+ 20% for single room).

It’s clear that it’ll be very difficult to find a room at such a price around 
the lake of Constance! ;) But is there any international airport at hand? 
Trieste ? Gorizia ?

 ‘c uskoro!
 
 Wrong language, wrong input, but thanks a lot for trying ;) (Did you
 use google translate on C you soon? Also, it's jutro and a comma
 is missing in front of the name :P)

No: “vidimu s’uskoro”, that’s what I say to my janitor almost every morning. 
She is Serbian, and since she knows I dote on linguistics, she has taught me 
very basic phrases in “Yugoslavian”, what ever that means now… But I understand 
that Slovenian is slightly different. Besides, Serbian uses cyrillic, so I 
tried a transliteration a bit at random.

Cheers!
Vincent

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

Re: MacPorts Developer Meeting?

[Vincent Habchi]

 Until now up to 6 people replied that they *might* be able to show up
 in Europe. If the number stays that small, we could still meet, but it
 would be easier to just pick a location and go there without any big
 one-year-in-advance reservations of the place.

Hi !

If it’s scheduled enough in advance, I might be able to haul my rump out of my 
Paris' office and join you for one day or two, as that’d be fun. Do you have 
any blueprint yet?

Vincent

(I wouldn’t go to the US, though, over personal data privacy concerns)


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

Re: New committers: petr, ctreleaven, juanrgar

[Vincent Habchi]

 Please join us in welcoming the following new MacPorts committers:
 
 - Peter Danecek (petr)
 - Craig Treleaven (ctreleaven)
 - Juan R. Garcia Blanco (juanrgar)

Welcome to the jungle! ;)
V.

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

Orfeotoolbox 4

[Vincent Habchi]

Hi there,

would it be possible to add to the Orfeotoolbox Portfile a few lines to 
display, at the end of the install phase, a message explaining how to configure 
QGis 2.2 to use the library?

Thanks,
Vincent

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

Re: New MacPorts web site

[Vincent Habchi]

Ryan,

the new design is rad! But I wonder if it is appropriate to use floppy disk 
icons to symbolize packages. I’m pretty sure the youngest over here do not even 
know what it is about ;)

(Granted, that’s just nitpicking…)

Thanks for the wonderful work.
Vincent

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

Atlas update

[Vincent Habchi]

Folks,

I have kinda spruced up the Atlas port by moving from clang33 to clang34, 
replacing an old gcc46 variant by a new gcc49, and changing the default 
behavior (+clang instead of +clang33)

Now, my predicament is this: should I upgrade the revision, and force a general 
rebuild in all users (given that there is no Atlas binaries and it takes eons 
to build) or should I just commit the new port in a kinda stealth upgrade?

Thanks for your input!
Vincent

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

Re: Atlas update

[Vincent Habchi]

Hi Marko,

great idea. I’ll attach the new Portfile right away in one of those tickets, so 
that you can test it. If it works fine, then I’ll close the bug and commit it 
(but still, my question remains).

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

Re: Atlas update

[Vincent Habchi]

Hi Michael,

 Hi Vincent - With so many fixes / changes, once the updated Portfile is
 verified / fixed, my vote is to do the rev-bump. Makes future tickets
 easier to work with, among other things. - MLD

Noted.
By the way, I figured out it is not very wise to change the default compiler 
from macports-clang-3.3 to XCode-clang, since a lot of people out here run 
Atlas on old machine that have not the last Xcode installed. 

So I’m going to make it conditional. For the people that have Xcode 5 
installed, clang Xcode is going to be the default, but it will be 
macports-clang-3.4 for the others.

Now, does some guru out there remember me how to test against Xcode version?

Thanks,
Vincent
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: [114142] trunk/dports/python/py-spatialite

[Vincent Habchi]

Ryan:

 Well the developers seem to call it “3.0.1-alpha-0” so that’s what I would 
 put in the version field

Yes, but once the final 3.0.1 will be released, nobody will be able to upgrade, 
since 3.0.1-alpha-0 seems to be considered by Macports as newer than plain 
3.0.1 (cf. my other message on the epoch tag).

That’s why I was planning to use the revision field to track the various 
development stages instead.

Vincent

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

Re: [114136] trunk/dports/databases/postgis2/Portfile

[Vincent Habchi]

 The epoch line is no more a wart than any other line of the Portfile… it’s 
 just a syntax for accomplishing a task.

[…]
Thanks Blair Ryan for the explanation. I just wish there would be some other 
mechanism somehow able to tweak the ‘update detection’ script. E.g, considering 
that any X.Y.Z version is actually newer than X.Y.Z-…; more precisely, that any 
trailing hyphen indicates a development version.

Vincent

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

Re: [114136] trunk/dports/databases/postgis2/Portfile

[Vincent Habchi]

Le 1 déc. 2013 à 10:44, Ryan Schmidt ryandes...@macports.org a écrit :

 That’s not always the case. For example, libtcd was updated from 2.2.5 to 
 2.2.5-r3 in r114005. 2.2.5-r3 is not a development or alpha or beta or 
 release candidate version; it’s the third actual release of the stable 
 version 2.2.5; it comes after 2.2.5.

Could it have been coded 2.2.5.3 instead?

 It’s possible we could make vercmp smarter. But I would want to be careful 
 that we don’t break any existing upgrades in the process.

Maybe we could add a ‘sub-version’ or ‘dev-version’ tag, that, when set, would 
indicate that the release is not final; between two Portfiles with such tags, 
the one with the ‘highest’ one would win.

Vincent

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

Re: [114136] trunk/dports/databases/postgis2/Portfile

[Vincent Habchi]

Le 2 déc. 2013 à 04:22, Ryan Schmidt ryandes...@macports.org a écrit :

 We should not confuse users and developers. We should call things what they 
 are.

I concur with you. We’re computer scientists, not politicians :)

Vincent


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

Re: [114136] trunk/dports/databases/postgis2/Portfile

[Vincent Habchi]

Hi Ryan,

 The epoch may never be removed or decreased; please put it back.

Done in r114183.
Does that mean that we can’t never get rid of that epoch wart?

Cheers!
Vincent


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

Re: [114136] trunk/dports/databases/postgis2/Portfile

[Vincent Habchi]

Blair:
 That’s right, they can never be removed.

Thanks.
By the way, what was the ‘epoch’ meant for, initially? 

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

Re: [114142] trunk/dports/python/py-spatialite

[Vincent Habchi]

Le 1 déc. 2013 à 03:53, Ryan Schmidt ryandes...@macports.org a écrit :

 The port should not claim to be version “3.0.1” when it is actually an alpha 
 version thereof. Put the real version number in the version field.

You’re right, that was not very clever. I thought it could be managed through 
the revision field. But what do you mean by ‘real version number’?

V.

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

Re: [112580] trunk/dports/gis/gdal-grass/Portfile

[Vincent Habchi]

Ryan,

 It’s nice to commit whitespace changes separately from functional ones so 
 that the functional changes can be more easily spotted. This appears to be 
 the functional change in this commit:

I agree and apologize. The functional change was so minor I thought unnecessary 
and cumbersome to do two separate commits.

 Does this change where gdal-grass installs its files, or where it expects to 
 find grass files at runtime? If so, the revision should be increased.
 I wanted to find out for myself so I checked for binary packages, but there 
 aren’t any; the port doesn’t indicate its license so MacPorts assumes it’s 
 not distributable.
 Then I tried installing the port, but its dependency grass fails to build on 
 Mavericks.

Rats. I don’t have grass installed on this machine, so I guess it’s going to be 
a pain to sort that out. Stay tuned.

Thanks for giving a try to this.
Vincent

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

Re: [112526] trunk/dports/math/atlas/Portfile

[Vincent Habchi]

Sorry Ryan, I didn’t see your patch. I added the line very quickly as a kludge, 
being somewhat swamped at work. I’ll implement your patch on the double: 
r112566.

Thanks as usual!
Vincent


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

Re: [112016] trunk/dports/gis/sfcgal/Portfile

[Vincent Habchi]

Le 10 oct. 2013 à 03:17, Joshua Root j...@macports.org a écrit :

 This appears to be incorrect in two ways.
 
 1. The license should be GPL-3+ (only a few files are LGPL-3+ and none
 are LGPL-2)

The website states: “ SFCGAL is distributed under the terms of the GNU Lesser 
General Public License 2. ”
So what should I do?

 The license name and version need to be separated by a dash.

You mean a hyphen ‘-’ or a real dash ‘—’? 

Vincent

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

Re: [112016] trunk/dports/gis/sfcgal/Portfile

[Vincent Habchi]

Josh,

 Probably not just go ahead and call it LGPL-2 (which makes us distribute
 it). You could ask the developers for clarification.

I’ll do that right away.

 Most of the files are now LGPLv2 or later in the new version you just
 committed. However the viewer still says GPL-3+, as do the examples, and
 the included CGAL headers are GPL-3+ or LGPL-3+. (The tests are also
 GPL-3+ but tests usually aren't installed.)

 The license name and version need to be separated by a dash.
 
 You mean a hyphen ‘-’ or a real dash ‘—’? 
 
 ASCII 45.

Yep, that’s what I did. I apologize for being a little pedantic.

 BTW, the port now has redundant name and version lines, and the case of
 the parent dir does not match that of the name.

Oh, I know. But I thought a capitalized name would look terrible; what’s your 
opinion?

Vincent

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

Re: [112016] trunk/dports/gis/sfcgal/Portfile

[Vincent Habchi]

Le 10 oct. 2013 à 12:20, Joshua Root j...@macports.org a écrit :

 Well you should just remove the unnecessary (and now old) version line.
 The name line can be moved to after the github.setup to override it.

Done in r112041. 
Thanks a lot!
Vincent

PS : I got a reply from the author concerning the license. As long as the 
package is split from Cgal, it should remain LGPL-2: 
French quote 
Si tu ne packages 'que' SFCGAL c'est LGPL v2 ; Si tu packages SFCGAL + CGAL 
c'est GPLv3
/French quote


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

Re: [112006] trunk/dports/gis

[Vincent Habchi]

Ryan,

 Revision: 112006

[…]
Thanks for you ongoing alertness. I’ve taken into account all but one of your 
remarks: I couldn’t tweak the github port to fit that obviously non-standand 
repository, so I just left the master_site and all other variables as is.

Thanks once more.
Vincent


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

Re: [111764] trunk/dports/math/atlas/Portfile

[Vincent Habchi]

Le 1 oct. 2013 à 12:41, Ryan Schmidt ryandes...@macports.org a écrit :

 Version numbers are strings, not floating-point numbers. You need to use the 
 [vercmp] procedure to compare them.

Thanks Ryan. Committed in r111786.

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

Re: Temporary fixing a file in /opt/local/share… generated by another port

[Vincent Habchi]

Michael,

 I have a working relationship with the lead developer of SIP. Please
 send me your info off-list, whether a patch or just suggestion, along
 with the error you're experiencing and how to recreate it, and I'll
 forward that info to him.  In the past, he has been very responsive to
 fixing bugs quickly. - MLD

Done. Thanks for your help.
Vincent

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

Temporary fixing a file in /opt/local/share… generated by another port

[Vincent Habchi]

Folks,

The newest version of QGis does not compile because of bug in SIP 4.15.x. 
Specifically, the file qsyntaxhighlighter.sip located in 
${prefix}/share/pyXX-sip/PyQt4/QtGui is buggy, and causes an error. I own a 
fixed copy which allow a correct build.

Question: can I patch the qsyntaxhighlighter.sip file during the time of the 
build, returning it to its normal buggy version at the end, or shall I proceed 
an other way?

Thanks!
Vincent

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

Re: Another SIP API Update

[Vincent Habchi]

 I updated py*-sip in r110025 
 https://trac.macports.org/changeset/110025 , which apparently provides
 SIP API v10.0 to v10.1.  Just now I rev-bumped py-qscintilla (me),
 py-pyqt4 (me), py-pyqwt (me), and orocos-kdl (nomaintainer), just in
 case even though they work for me.  I see that Poppler was just
 updated, which address ticket #40240 fully so I'll close that.  The
 remaining ports that seem to use SIP and hence might need a rev-bump
 are:
 
 vince : qgis
[…]

4.15.x seems to be buggy. It wasn’t a good idea after all. Breaks QGis 2.0 
build, for example ;)
Vincent


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

Re: [108385] trunk/dports/gis/gdal/Portfile

[Vincent Habchi]

Hi!

 I'm concerned that the net performance gain here is going to be far 
 outweighed by the maintenance costs and user complexity. Without actually 
 measuring the gains, there's no guarantee that these changes will actually 
 improve performance, and in moving away from the optimization flags et al 
 selected by the original developers, could very possibly trigger bugs in code 
 generation output (e.g., compiler bugs, especially with bleeding-edge clang), 
 or reveal bugs in the project that aren't apparent at lower optimization 
 levels.

Well, clang-3.3 is, in principle, well known and (almost) bug free. It’s a full 
release version, not a bleeding edge compiler anymore… as for bugs in the 
project… well… they will have to be unearthed sooner or later anyhow. Remember 
that the perf variant is going to be optional anyhow, so we could easily 
restrict its use to the most advanced users.

Vincent

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

Re: [108594] trunk/dports/databases/spatialite/Portfile

[Vincent Habchi]

Le 28 juil. 2013 à 08:19, Ryan Schmidt ryandes...@macports.org a écrit :

 Are you sure it's a library dependency? Usually pkgconfig is only a build 
 dependency. Unless one of the programs installed by spatialite (a config 
 program, perhaps?) internally uses pkgconfig.

You’re right Ryan. Altered in r108641.

Vincent

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

perf-1.0 portgroup

[Vincent Habchi]

Folks,

as part of the perf variant proposal, I have written a perf-1.0 portgroup file 
that might do the job. Opinion?

Thanks,
Vincent

—

# $Id: perf-1.0.tcl  vi...@macports.org $
#
# Copyright (c) 2013 The MacPorts Project
# All rights reserved.
#
# Redistribution and use in source and binary forms, with or without
# modification, are permitted provided that the following conditions are
# met:
#
# 1. Redistributions of source code must retain the above copyright
#notice, this list of conditions and the following disclaimer.
# 2. Redistributions in binary form must reproduce the above copyright
#notice, this list of conditions and the following disclaimer in the
#documentation and/or other materials provided with the distribution.
# 3. Neither the name of The MacPorts Project nor the names of its
#contributors may be used to endorse or promote products derived from
#this software without specific prior written permission.
#
# THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
# AS IS AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
# LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR
# A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT
# OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
# SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT
# LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE,
# DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY
# THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
# (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE
# OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
#
#
# This portgroup provides a perf variant than can be used to
# optimize code at the expense of portability. It uses 
# macports-clang-3.3 as C and C++ compiler at the -O4 level (enables loop
# vectorizer and LTO) and dragonegg-3.3-gfortran-4.8 to compile
# Fortran code, thereby allowing AVX instructions even in Fortran code
#
# Usage:
# PortGroup   perf 1.0

proc get_perf_flags {} {

# Find out on which system we are running
set archflags 
set os.major [lindex [split [sysctl kern.osrelease]  ] 0]
if {(${os.major}  11  \
(![catch {sysctl hw.optional.fma} result1]  $result1 == 1)) ||
(![catch {sysctl hw.cpufamily} result2]  $result2 == 280134364)} {

append archflags -mfma 
}

if {(${os.major}  11  \
(![catch {sysctl hw.optional.avx2_0} result1]  $result1 == 1)) ||
(![catch {sysctl hw.cpufamily} result2]  $result2 == 280134364)} {

append archflags -mavx2 

} elseif {(${os.major}  10  \
(![catch {sysctl hw.optional.avx1_0} result1]  $result1 == 1)) ||
(![catch {sysctl hw.cpufamily} result2]  $result2 == 1418770316)} {

append archflags -mavx 
} elseif {${os.major}  9  \
![catch {sysctl hw.optional.sse4_2} result1]  $result1 == 1} {

set archflags   -msse4.2 
} elseif {${os.major}  9  \
![catch {sysctl hw.optional.sse4_1} result1]  $result1 == 1} {

set archflags   -msse4.1 
} elseif {${os.major}  8  \
![catch {sysctl hw.optional.supplementalsse3} result1]  $result1 == 1} {

set archflags   -mssse3 
} elseif {
![catch {sysctl hw.optional.altivec} result1]  $result1 == 1} {

# PowerPC
set archflags -maltivec -mabi=altivec 
}

append archflags -O4 -march=native

return $archflags
}

variant perf description {Optimize for current arch} {

depends_build-appendport:clang-3.3
depends_build-appendport:dragonegg-3.3-gcc-4.8

set optflags[get_perf_flags]
set fortflags   ${optflags}\
-specs=${prefix}/libexec/dragonegg/llvm33gcc48-integrated-as.specs

configure.compiler  macports-clang-3.3
configure.f77   ${prefix}/bin/dragonegg-3.3-gfortran-mp-4.8
configure.f90   ${prefix}/bin/dragonegg-3.3-gfortran-mp-4.8

configure.optflags  ${optflags}
configure.fflags${fortflags}
configure.f90flags  ${fortflags}

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

Re: wxWidgets30 libraries oddities

[Vincent Habchi]

Josh,

 Air  nm /opt/local/lib/libwx_osx_cocoau_html-2.9.dylib | c++filt | grep 
 SetHTMLWindowTitle
 0004284a T wxHtmlWindow::SetHTMLWindowTitle(wxString const)
 00063250 T wxHtmlListBox::SetHTMLWindowTitle(wxString const)
 0004285c T non-virtual thunk to 
 wxHtmlWindow::SetHTMLWindowTitle(wxString const)
 00063256 T non-virtual thunk to 
 wxHtmlListBox::SetHTMLWindowTitle(wxString const)
 
 The non-virtual thunks are an implementation detail:
 http://en.wikipedia.org/wiki/Thunk_(object-oriented_programming)

Thanks for the link; I better understand what that means, but I just can’t 
figure out why there are, at the same time, both the methods and the 
“non-virtual thunks”.

Vincent

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

Re: [108550] trunk/dports/gis

[Vincent Habchi]

Ryan,

 +pre-configure {
 +system -W ${worksrcpath} autoreconf -i
 
 This could be done with:
 
 use_autoreconf yes
 autoreconf.args -i

So be it. But how can I then patch the generated configure file before it is 
run?

Vincent

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

Re: [108550] trunk/dports/gis

[Vincent Habchi]

Le 27 juil. 2013 à 11:24, Clemens Lang neverpa...@gmail.com a écrit :

 Why do you have to? If you're running autoreconf anyway, why not just patch 
 configure.in?

Of course! Thanks! Sometimes I feel I’m just stupid! ;)

Vincent

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

wxWidgets30 libraries oddities

[Vincent Habchi]

Hi there,

When I build wxWidgets30, I get these, e.g. in libwx_osx_cocoau_html:

Air  nm /opt/local/lib/libwx_osx_cocoau_html-2.9.dylib | c++filt | grep 
SetHTMLWindowTitle
0004284a T wxHtmlWindow::SetHTMLWindowTitle(wxString const)
00063250 T wxHtmlListBox::SetHTMLWindowTitle(wxString const)
0004285c T non-virtual thunk to 
wxHtmlWindow::SetHTMLWindowTitle(wxString const)
00063256 T non-virtual thunk to 
wxHtmlListBox::SetHTMLWindowTitle(wxString const)

Those “non-virtual thunks” then give rise to errors when one tries to link 
against the missing functions, e.g.:

  non-virtual thunk to wxHtmlWindow::SetHTMLWindowTitle(wxString const), 
referenced from:
  vtable for CACTIVE_Description in active_description.o
  vtable for CACTIVE_HTMLExtraInfo in active_HTMLExtraInfo.o


Since I am totally ignorant of the arcanes of C++, can someone tell me if this 
a bug or an expected behavior under appropriate conditions?

Thanks,
Vincent

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

Re: [108550] trunk/dports/gis

[Vincent Habchi]

 Does doing so in a pre-configure block, exactly as you're doing now, not 
 work? Does that end up running before the autoreconf?

Ryan: yes. The autoreconf-configure pair seems to be atomic. Either it is run 
too early, or too late.

Clemens, this is the AM_PYTHON_DEVEL ([]) if I remember correctly. The macro 
produces wrong extra LDFLAGS and the final phase where it tests the results 
crashes. I wonder if this is caused by some bug in my python27 installation, 
but since it is 100% vanilla…

Vincent

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

Uploading a source file to packages.macports.org

[Vincent Habchi]

Folks,

I am going to add a new port in the ‘gis’ category. However, at this point in 
time, the source code is not available for download through a direct link. I 
was therefore wondering if it were possible to upload it to 
packages.macports.org so that the Portfile could download it directly from our 
main repository?

Thanks,
Vincent
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: Uploading a source file to packages.macports.org

[Vincent Habchi]

Le 26 juil. 2013 à 10:17, Ryan Schmidt ryandes...@macports.org a écrit :

 distfiles.m.o is for source code archives. You cannot manually upload 
 anything there, but you can ask the macosforge admin to do so. However there 
 should be no need to, assuming you can put the distfiles anywhere else on the 
 Internet and point the portfile to that location via the master_sites. Before 
 you do so, ensure that the license agreement allows you to do so. And 
 assuming it does, please work with the developers of the software to make it 
 available via a direct link from their site.

Yeah, I did that already, but they are a little slow to process requests… So in 
the meantime…

I uploaded the source code to some server at work, but it is an ADSL-type line, 
so it’s going to be at best slow. I hope some macports server can cache the 
file somehow.

Thanks Ryan, as usual.
Vincent

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

Re: Uploading a source file to packages.macports.org

[Vincent Habchi]

Le 26 juil. 2013 à 15:52, Daniel J. Luke dl...@geeklair.net a écrit :

 well, we used to have people put files in part of our svn repo for things 
 that didn't have a good master site (and the mirror could just be a mirror).
 
 At some point, we decided that this was bad, and told people to stop doing it 
 - without having a good self-serve replacement method.

I agree. I think it would be nice to be able to directly upload some files to 
distfiles.m.o. Does it imply some kind of security concern?

Vincent


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

Re: [108385] trunk/dports/gis/gdal/Portfile

[Vincent Habchi]

Le 22 juil. 2013 à 14:52, Ryan Schmidt ryandes...@macports.org a écrit :

 Possibly you should set configure.optflags -O3 -march=native instead of 
 dealing with cflags and cxxflags directly.

I found that setting configure.cflags and cxxflags does not seem to interfere 
with the other options. But if you say there is a more suitable way to set 
them, I’ll abide by your advice.

 Or possibly users who want performance should edit this and the compiler 
 choice into macports.conf directly. However they would also have to disable 
 the use of the precompiled binaries otherwise they would, without warning, 
 receive a binary that was not compiled with those flags. So I could 
 understand if we don't think that's the best solution.

Exactly. The idea I had is that the users that want their ports to be compiled 
and optimized for their machine should add the +perf variant in variants.conf. 
Since +perf is never enabled by default, this would never result in the 
fetching of the pre-compiled binaries. What do you think?

Vincent

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

Re: [108383] trunk/dports/math/atlas/Portfile

[Vincent Habchi]

Hi Ryan,

 Presumably the removal of the revision line was unintended? The revision 
 cannot decrease unless the version or epoch increases. 

Oops, that was a mistake. I made some attempts to bump to an unstable version 
that supports Haswell, but it produced buggy code, so I reverted to the current 
Portfile and hacked it to at least make Atlas compile on the newest MBA 2013. 
It seems the revision line got lost during the process. I’ll fix that.

Thanks for pointing that out!
Vincent

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

Tool for automated cleaning of ${prefix}/var/distfiles

[Vincent Habchi]

Dear base gurus ;),

is there a way to clean up the files stored in distfiles, especially those 
corresponding to old port versions, but that still linger in the filesystem and 
take unnecessary space?

Why ‘port clean outdated’ does not take care of this?

Just curious,
Vincent

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

Re: Tool for automated cleaning of ${prefix}/var/distfiles

[Vincent Habchi]

 Can you check to see if the version of the files left behind match the 
 oudated ones, that only the current version is being cleaned regardless of 
 which ones are outdated?

Do you mean it is impossible to figure out which version is tied to which 
distfile? Isn’t that something that could be recorded in the database?

V.

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

Re: [108385] trunk/dports/gis/gdal/Portfile

[Vincent Habchi]

Ryan,

 The default for configure.optflags is -Os in MacPorts 2.2 and was -O2 
 previously.
 The default for configure.cflags, configure.cxxflags, configure.objcflags, 
 configure.objcxxflags, configure.fflags, configure.f90flags, and 
 configure.fcflags is ${configure.optflags}.

Ok, great then. You’re right, it makes sense to use this variable rather than 
to set the flags directly.

 I think that's true. I just wanted to avoid using variants for something if 
 we already handle it at the MacPorts base level. But maybe we don't 
 completely handle it there.

My knowledge of Macports’ guts is very basic. I regret, BTW, the lack of 
developer documentation summarizing the role of the various procedures in base.
Anyhow, it is difficult to handle the setting of compilers and flags in a 
simple way. While many packages respond correctly to ‘configure.compiler’, 
other fail or require specific setting of variables during the configure phase, 
e.g., Eigen3 needs a -DCMake_Fortran_Compiler=… to take a specific value into 
account. That precludes the use of a simple system with a few variables.

 If we have settings for overriding configure.optflags and configure.compiler, 
 then maybe doing so should automatically disable the use of binaries.

That would make sense too.

Vincent

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

Re: Tool for automated cleaning of ${prefix}/var/distfiles

[Vincent Habchi]

 It might have the information available (I think we stored install-time 
 Portfiles into the database) but I'm not sure if that's what we use when 
 cleaning distfiles. A quick glance in your directory should confirm this, or 
 a base dev looking into the source for it.

For example, I just updated boost to 1.54 and uninstalled 1.53, but I still 
find both files in the corresponding distfiles subdirectory:

Air  ll /opt/local/var/macports/distfiles/boost/
total 221960
-rw-r--r--  1 macports  admin  55765258 30 jui 16:18 boost_1_53_0.tar.bz2
-rw-r--r--  1 macports  admin  57873778 22 jul 20:21 boost_1_54_0.tar.bz2

Vincent

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

Re: Tool for automated cleaning of ${prefix}/var/distfiles

[Vincent Habchi]

Le 22 juil. 2013 à 21:36, Jeremy Lavergne jer...@lavergne.gotdns.org a écrit :

 Ah, so you've already uninstalled boost 1.53, hence there is no outdated 
 boost installed and the tracking for the file is definitely gone.

Right. My question precisely was: why does ‘port uninstall’ not wipe out also 
this file during deinstallation? Isn’it supposed to do so?

Vincent


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

Re: Tool for automated cleaning of ${prefix}/var/distfiles

[Vincent Habchi]

 This might be semantic points at the end of the day, but…

And here in Paris the day is really close to its end! :)

 You installed binaries, not source code, so only the installed files are 
 uninstalled. That is, source code is only used for building. If you needed 
 the source code before, you will need it again if you go to install that 
 version again. Historically, source code is kept unless you ask for it to be 
 cleaned because bandwidth was/is harder to come by than drive space.

Granted, but this is true only for the code corresponding to the current 
version of the Portfile, not outdated code, that cannot be re-installed anyway, 
since, as Ryan pointed out in a previous message following a bug of mine, the 
version counter cannot go back in time…

V.

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

Re: [108385] trunk/dports/gis/gdal/Portfile

[Vincent Habchi]

Le 22 juil. 2013 à 21:41, Ryan Schmidt ryandes...@macports.org a écrit :

 Hmm. I think we probably want all ports to respond correctly to 
 configure.compiler, since the default differs by Xcode version, but of course 
 we haven't audited all ports for compliance, and I'm sure several don't. But 
 that would be something that could be fixed on a port by port basis as it's 
 discovered.

Well, I’m not sure it is feasible. Take, for example, py-scipy. It includes 
these lines (for the gcc45 variant):

configure.compiler  macports-gcc-4.5
…
destroot.env-append CC=${prefix}/bin/gcc-mp-4.5 \
CXX=${prefix}/bin/g++-mp-4.5
build.env-appendCC=${prefix}/bin/gcc-mp-4.5 \
CXX=${prefix}/bin/g++-mp-4.5

So in this case, a simple configure.compiler state variable does not seem to be 
enough. This is going to be real hard to fix.

Vincent

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