Re: ITStool failed to build
I installed the default version of python27 and now it works fine. Thank you for your help David. Le 27 févr. 2014 à 16:38, David Evans dev...@macports.org a écrit : On 2/27/14 1:02 AM, Giuseppe Di Matteo wrote: Here it is: echo import libxml2 | /opt/local/bin/python2.7 - Traceback (most recent call last): File stdin, line 1, in module File /opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/libxml2.py, line 1, in module import libxml2mod ImportError: dlopen(/opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/libxml2mod.so, 2): Symbol not found: _PyUnicodeUCS2_AsUTF8String Referenced from: /opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/libxml2mod.so Expected in: flat namespace in /opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/libxml2mod.so It appears that you have python27 +ucs4 installed and py27-libxml2 was built (probably the current binary archive) using the default variant of python27 (without the +ucs4 variant). To fix the problem either install the default version of python27 sudo port install python27 Or if you really need to continue to use python27 +ucs4 then you will need to rebuild py27-libxml2 locally, from source. Note that a fix for a different problem was committed for py-libxml2 yesterday so be sure to update your ports first. sudo port selfupdate sudo port -ns upgrade --force py27-libxml2 Once this is done, you should be able to build itstool without problems. You may see this problem with other ports that link against the python library. See also https://trac.macports.org/ticket/35603 Giuseppe Di Matteo pinodimat...@icloud.com ___ macports-users mailing list macports-users@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-users
uninstalling a selected port ...
Hi all, I observe a behaviour, which I believe is due to the fact that I uninstalled an selected port (see below). This seems to leave the selection mechanism in an undesired state and should be handled. Now I wonder which is the expected behaviour, so that I can eventually file a ticket against the right component. Thanks! --- snip --- petr% sudo port select --list postgresql Available versions for postgresql: none (active) postgresql93 petr% sudo port select --set postgresql postgresql93 Selecting 'postgresql93' for 'postgresql' failed: symlink: /opt/local/etc/select/postgresql/current - postgresql93: file already exists petr% ls -la /opt/local/etc/select/postgresql/current lrwxr-xr-x 1 root admin 12 28 Feb 12:38 /opt/local/etc/select/postgresql/current - postgresql92 smime.p7s Description: S/MIME cryptographic signature ___ macports-users mailing list macports-users@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-users
Re: uninstalling a selected port ...
On Fri, Feb 28, 2014 at 8:44 AM, Jason Swails jason.swa...@gmail.comwrote: sudo port -f select --set postgresql postgresql93 In my opinion, such protection is a Good Thing (TM). There's a way to work around it if you know the reason behind the file collision, but I certainly wouldn't want a program (especially one I run as root) to go around clobbering existing files without me knowing it. Except the implication of their preamble is that that file was left around by removing the postgres92 port, because port select isn't sufficiently integrated and isn't cleared when a `select`ed port is removed. -- brandon s allbery kf8nh sine nomine associates allber...@gmail.com ballb...@sinenomine.net unix, openafs, kerberos, infrastructure, xmonadhttp://sinenomine.net ___ macports-users mailing list macports-users@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-users
Re: uninstalling a selected port ...
On Fri, 2014-02-28 at 14:53 +0100, Peter Danecek wrote: On 28 Feb 2014, at 14:44, Jason Swails jason.swa...@gmail.com wrote: On Fri, 2014-02-28 at 14:33 +0100, Peter Danecek wrote: Hi all, I observe a behaviour, which I believe is due to the fact that I uninstalled an selected port (see below). This seems to leave the selection mechanism in an undesired state and should be handled. Now I wonder which is the expected behaviour, so that I can eventually file a ticket against the right component. Thanks! --- snip --- petr% sudo port select --list postgresql Available versions for postgresql: none (active) postgresql93 petr% sudo port select --set postgresql postgresql93 Selecting 'postgresql93' for 'postgresql' failed: symlink: /opt/local/etc/select/postgresql/current- postgresql93: file already exists Try forcing the issue. sudo port -f select --set postgresql postgresql93 In my opinion, such protection is a Good Thing (TM). There's a way to work around it if you know the reason behind the file collision, but I certainly wouldn't want a program (especially one I run as root) to go around clobbering existing files without me knowing it. Well, I understand your point and it would be fine if it is decided to leave ALL untouched. But then in expect consistent information, i.e. all should be left pointing to `postgresql92` (even if it does not exist), so at least you know the status. If I am informed that it point to `none` this should be the case. I believe it is consistent. As I understand it, the simlinks created by port select are not *owned* by the selected port. Since the port itself does not maintain these simlinks (but rather 'port select' does), there are good arguments to be made that the port should _not_ own simlinks created by select. As a result, uninstalling that port should not touch those simlinks. This results in the errors you saw. An alternative when you know that you are uninstalling a port is to select none. So something like sudo port select --set postgresql none to get rid of the simlinks, then another sudo port select --set postgresql postgresql93 to set the simlinks to the new version you want to track. (This approach is untested, but I think it should work.) A feature request may be for port select to detect dangling links and print an informative message (perhaps with a suggested command to eliminate the dangling links). That's largely aesthetic, though. All the best, Jason -- Jason M. Swails BioMaPS, Rutgers University Postdoctoral Researcher ___ macports-users mailing list macports-users@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-users
Re: uninstalling a selected port ...
On Fri, Feb 28, 2014 at 9:30 AM, Peter Danecek peter.dane...@bo.ingv.itwrote: On 28 Feb 2014, at 15:17, Jason Swails jason.swa...@gmail.com wrote: An alternative when you know that you are uninstalling a port is to select none. So something like sudo port select --set postgresql none to get rid of the simlinks, then another sudo port select --set postgresql postgresql93 to set the simlinks to the new version you want to track. (This approach is untested, but I think it should work.) A feature request may be for port select to detect dangling links and print an informative message (perhaps with a suggested command to eliminate the dangling links). That's largely aesthetic, though. This does not work (tested). You cannot set new pointers after uninstalling the port, not even to none. I have not tested forcing but remove the link to be able to use port select again. I am not sure this is only aesthetic! I'll agree with you now. -f should only be required if you do something atypical -- I don't like it as part of a required workflow. I've needed it before, but that was when I deleted /opt/local to reinstall MacPorts and file collisions occurred inside other folders (like /Applications/MacPorts). (should we move this discussion on devel?) I have no opinion here. I'm not subscribed to that list and do not actively help to maintain MacPorts... All the best, Jason -- Jason M. Swails BioMaPS, Rutgers University Postdoctoral Researcher ___ macports-users mailing list macports-users@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-users
Re: uninstalling a selected port ...
[Sorry, I realise I send my replies off-list] On 28 Feb 2014, at 15:38, Clemens Lang c...@macports.org wrote: Hi, I believe it is consistent. As I understand it, the simlinks created by port select are not *owned* by the selected port. Since the port itself does not maintain these simlinks (but rather 'port select' does), there are good arguments to be made that the port should _not_ own simlinks created by select. As a result, uninstalling that port should not touch those simlinks. This results in the errors you saw. That's correct. However, the symlinks are currently not owned by the corresponding *_select port either, which they probably should and which would solve this problem to some extent, because uninstalling the *_select port would just remove the symlinks. Give ownership of the symlink to the *_select port probably makes sense, but would not resolve the described problem, right? Of course we could also add a check to MacPorts that would somehow notice that you're currently deactivating a port that's currently selected, but that wouldn't be easy, because updates of a port also deactivate (and later re-activate) it and shouldn't destroy your selection. Okay, so leaving the pointer to the deactivated port makes sense to keep it valid after reactivation. But would be a simple solution to make it possible to set the a new version of the port even in the described case, i.e. overwrite the symlink when requested by the user (without -f flag, no need to remove the symlink before). This operation should be always possible, independent of the fact that some port is installed or not. The other thing is, if this pointer is really set to an deactivated/uninstalled port, which (see above) we judge is a valid state, this should be reported to the user. I the concrete case: sudo port select --list postgresql Available versions for postgresql: none postgresql93 Active version set to / Currently not available versions for postgresql: postgresql92 (active) Or some similar output. This would imply the ticket would be compiled against … (well) *_select, the select port group ??? Thanks! ~petr I was actually planning on registering the created symlinks to the *_select ports for a while now so trace mode can reliably hide stuff created by the select feature while building (because the selection should never affect how a port builds). -- Clemens Lang smime.p7s Description: S/MIME cryptographic signature ___ macports-users mailing list macports-users@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-users
Re: uninstalling a selected port ...
[Sorry, I realise I send my replies off-list] On 28 Feb 2014, at 15:17, Jason Swails jason.swa...@gmail.com wrote: An alternative when you know that you are uninstalling a port is to select none. So something like sudo port select --set postgresql none to get rid of the simlinks, then another sudo port select --set postgresql postgresql93 to set the simlinks to the new version you want to track. (This approach is untested, but I think it should work.) A feature request may be for port select to detect dangling links and print an informative message (perhaps with a suggested command to eliminate the dangling links). That's largely aesthetic, though. This does not work (tested). You cannot set new pointers after uninstalling the port, not even to none. I have not tested forcing but remove the link to be able to use port select again. I am not sure this is only aesthetic! (should we move this discussion on devel?) ~petr smime.p7s Description: S/MIME cryptographic signature ___ macports-users mailing list macports-users@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-users
Re: uninstalling a selected port ...
[Sorry, I realise I send my replies off-list] On 28 Feb 2014, at 14:44, Jason Swails jason.swa...@gmail.com wrote: On Fri, 2014-02-28 at 14:33 +0100, Peter Danecek wrote: Hi all, I observe a behaviour, which I believe is due to the fact that I uninstalled an selected port (see below). This seems to leave the selection mechanism in an undesired state and should be handled. Now I wonder which is the expected behaviour, so that I can eventually file a ticket against the right component. Thanks! --- snip --- petr% sudo port select --list postgresql Available versions for postgresql: none (active) postgresql93 petr% sudo port select --set postgresql postgresql93 Selecting 'postgresql93' for 'postgresql' failed: symlink: /opt/local/etc/select/postgresql/current- postgresql93: file already exists Try forcing the issue. sudo port -f select --set postgresql postgresql93 In my opinion, such protection is a Good Thing (TM). There's a way to work around it if you know the reason behind the file collision, but I certainly wouldn't want a program (especially one I run as root) to go around clobbering existing files without me knowing it. Well, I understand your point and it would be fine if it is decided to leave ALL untouched. But then in expect consistent information, i.e. all should be left pointing to `postgresql92` (even if it does not exist), so at least you know the status. If I am informed that it point to `none` this should be the case. And I am not sure if setting the current link to `none` would harm here. ~petr smime.p7s Description: S/MIME cryptographic signature ___ macports-users mailing list macports-users@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-users
questions about writing Portfile
Hello,
I have several Portfile in the pipe and more questions arising which don't
find solutions in the guide.
- when updating an existing port, is it recommended to copy in your own
depot (own user) or work on the existing one (as root)? in the first case,
it seems that not all action are prioritizing repositories in the same
order (install and before).
- there is a startupitem option but it does not seem any way to include a
cron-like job through launchd? script/exec to launch every day/month. So I
suppose for now, we include our own file.
- but in this case, what is the variable for the port/files dir. or files
is supposed to be only patchfiles?
- any way to reinplace w a newline?
tried the following and failed (but it seems depending on which sed, there
are different options)
stackoverflow.com/questions/6111679/insert-linefeed-in-sed-mac-os-x
\\\n
\\`echo -e '\n\r'`
- the official packages are signed, right? as
http://blog.infobytesec.com/2011/07/pwning-mac-os-x-with-evilgrade-macports.html
For your own repository, there is
https://trac.macports.org/wiki/archives
There is also for pkg/mpkg (not sure if still valid)
http://trac.macports.org/ticket/30562
- any option/script mirror macports install. something like
port installed requested --dump mylist
port install --load mylist
- I have few ports which reacts differently in macports call than manually
(firebird, beltane)
They are not building in macports but if I launch manually the command in
${worksrcdir}, it's ok.
I tried to look to env var but nothing found for now.
- is there some test framework/command, so I can ask: for all my
repository, compile ports and all variants up to destroot and report any
errors.
- is it necessary for python/perl/web modules to Updating database of
binaries / Scanning binaries for linking errors: ?
- any example of library which have both lib and python-bindings? do we try
to make subport or not?
- for now, there is now test section in Portfile to ensure it is running
correctly at least for some commands, right? (like calling 'make tests' or
a defined exec)
Thanks a lot.
Best regards,
Julien
___
macports-users mailing list
macports-users@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-users
Re: questions about writing Portfile
At 10:43 AM -0500 2/28/14, Julien T wrote: - there is a startupitem option but it does not seem any way to include a cron-like job through launchd? script/exec to launch every day/month. So I suppose for now, we include our own file. I won't try to handle all your questions! ;) launchd handles periodic execution on OS X. The logrotate port can install a launchd plist that causes it to run at 5:30 each morning. See: https://trac.macports.org/browser/trunk/dports/sysutils/logrotate/Portfile https://trac.macports.org/browser/trunk/dports/sysutils/logrotate/files/org.macports.logrotate.plist.example Craig ___ macports-users mailing list macports-users@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-users
Re: questions about writing Portfile
Hi,
- when updating an existing port, is it recommended to copy in your own depot
(own user) or work on the existing one (as root)? in the first case, it
seems that not all action are prioritizing repositories in the same order
(install and before).
I'd recommend copying it so
(1) you can generate a unified diff for submission
(2) you don't accidentally lose your changes with the next selfupdate
- there is a startupitem option but it does not seem any way to include a
cron-like job through launchd? script/exec to launch every day/month. So I
suppose for now, we include our own file.
There's no option to do that with the startupitem.* options, but you can
provide your own launchd plist. See the mpstats port in my user directory [1]
that does exactly that (along with randomizing the execution time).
- but in this case, what is the variable for the port/files dir. or files
is supposed to be only patchfiles?
You can put any file you need there, as the mpstats ports does. $filespath is
the variable you're looking for.
- any way to reinplace w a newline?
tried the following and failed (but it seems depending on which sed, there
are different options)
stackoverflow.com/questions/6111679/insert-linefeed-in-sed-mac-os-x
\\\n
\\`echo -e '\n\r'`
I don't know about that one, sorry.
- the official packages are signed, right? as
http://blog.infobytesec.com/2011/07/pwning-mac-os-x-with-evilgrade-macports.html
This attack is no longer possible. The ports tree containing the hash values,
the base tarball for selfupdate, the MacPorts installer and the binary packages
are signed.
For your own repository, there is
https://trac.macports.org/wiki/archives
That and https://trac.macports.org/wiki/howto/ShareArchives2
There is also for pkg/mpkg (not sure if still valid)
http://trac.macports.org/ticket/30562
pkg and mpkg packages are currently not signed automatically by MacPorts. You
can sign them manually just like you'd sign installers if you have the
necessary certificates from Apple (i.e. the Mac Dev program). In fact, that's
how the MacPorts installers are created.
MacPorts does also not automatically sign the binary archives it builds and
internally used. Our buildbots use
http://trac.macports.org/browser/contrib/buildbot/deploy_archives.sh to do that.
- any option/script mirror macports install. something like
port installed requested --dump mylist
port install --load mylist
I guess you can use port installed -q requested and write a script to call port
install for this list. See
https://trac.macports.org/browser/contrib/restore_ports/restore_ports.tcl which
does something similar.
- I have few ports which reacts differently in macports call than manually
(firebird, beltane)
They are not building in macports but if I launch manually the command in
${worksrcdir}, it's ok.
I tried to look to env var but nothing found for now.
That might be due to a lot of reasons like sandboxing, privilege separation,
etc.; without a main.log it's unlikely anybody will be able to help you.
- is there some test framework/command, so I can ask: for all my repository,
compile ports and all variants up to destroot and report any errors.
No, no such thing exists.
- is it necessary for python/perl/web modules to Updating database of
binaries / Scanning binaries for linking errors: ?
The updating database of binaries is always necessary, the other wouldn't be
necessary in theory, but MacPorts will always run it after install/upgrade by
default. You can turn that off in macports.conf, if you want.
- any example of library which have both lib and python-bindings? do we try
to make subport or not?
Can't help you there either, sorry. Somebody else might be able to.
- for now, there is now test section in Portfile to ensure it is running
correctly at least for some commands, right? (like calling 'make tests' or a
defined exec)
To call make tests when sudo port test $portname is run, put the following in
a Portfile:
test.run yes
test.target tests
# test.cmd make (defaults to ${build.cmd}, which often is make)
[1] http://trac.macports.org/browser/users/cal/ports/macports/mpstats
--
Clemens Lang
___
macports-users mailing list
macports-users@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-users
MySQL Server with SSL Support
Hi, Is there a port for MySQL Server that is built with SSL support? Thanks, Tony S. Wu tonyswu@gmail.com smime.p7s Description: S/MIME cryptographic signature ___ macports-users mailing list macports-users@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-users
Re: questions about writing Portfile
2014-02-28 11:09 GMT-05:00 Clemens Lang c...@macports.org:
- when updating an existing port, is it recommended to copy in your own
depot
(own user) or work on the existing one (as root)? in the first case, it
seems that not all action are prioritizing repositories in the same order
(install and before).
I'd recommend copying it so
(1) you can generate a unified diff for submission
(2) you don't accidentally lose your changes with the next selfupdate
yeah, that's what I decided to do but sometimes, it mixed between
install/build between both repository.
still, not too annoying.
- there is a startupitem option but it does not seem any way to include a
cron-like job through launchd? script/exec to launch every day/month. So
I
suppose for now, we include our own file.
There's no option to do that with the startupitem.* options, but you can
provide your own launchd plist. See the mpstats port in my user directory
[1] that does exactly that (along with randomizing the execution time).
Thanks. 2 differents example w craig's. interesting.
- I have few ports which reacts differently in macports call than
manually
(firebird, beltane)
They are not building in macports but if I launch manually the command in
${worksrcdir}, it's ok.
I tried to look to env var but nothing found for now.
That might be due to a lot of reasons like sandboxing, privilege
separation, etc.; without a main.log it's unlikely anybody will be able to
help you.
Firebird is here http://trac.macports.org/ticket/42128.
just added the main.log
still try to review beltane but will probably submit in the next days.
Thanks a lot to both of you for the answers.
Hope to clean things enough to be easy review :-)
Cheers,
Julien
___
macports-users mailing list
macports-users@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-users
