Re: New project member: vishnu

[Rainer Müller]

On 2018-05-09 03:49, Zero King wrote:
>> Do you want to join the MacPorts team? If you would like to be
>> considered for team membership and commit access, please read this
>> section of the Guide:
>>
>> http://guide.macports.org/chunked/project.membership.html
> 
> Was PortMgr aware of
> https://github.com/macports/macports-guide/commit/ca0e0239b69f879159927a6357f3494da59c?
> Should we revert this change or always use GitHub handle as MacPorts
> handle for future members?

Yes, PortMgr was aware of that. A recent vote decided to change this
policy, but the guide was not yet updated.

Under the new policy, using the GitHub username is still supposed to be
the default. We would ask for the GitHub username, but optionally it
should be allowed to also specify a different handle for the
@macports.org forward.

Rainer

Re: Qt5 port group

[Craig Treleaven]

> On May 8, 2018, at 5:06 AM, Vincent Habchi  wrote:
> 
> Hi there,
> 
> I was in the process of modifying the Qt5 Port group to allow for choosing 
> the Qt version one wants to link an application against using variants. 
> However, before I go further, I’d like to know if concurrent installations of 
> different Qt5 versions are supported in MacPorts. If not, what I do is just 
> futile.
> 

Um, there are subports for each Qt5 version.  Picking one at random:

$ port info qt57-qtwebkit
qt57-qtwebkit @5.7.1_1 (aqua)
Variants: debug, examples, tests, universal

Description:  Tools and Module(s) for Qt Tool Kit 5: Qt WebKit and Qt 
WebKit Widgets
Homepage: http://qt.io

Extract Dependencies: xz
Build Dependencies:   python27, pkgconfig
Library Dependencies: fontconfig, icu, leveldb, webp, libxml2, libxslt, zlib, 
sqlite3, qt57-qtdeclarative, qt57-qtlocation, qt57-qtmultimedia, 
qt57-qtsensors, qt57-qtwebchannel, qt57-qtxmlpatterns, qt57-qtbase
Conflicts with:   qt3, qt3-mac, qt56-qtbase, qt58-qtbase, qt5-qtbase, 
qt55-qtbase, qt59-qtbase
Platforms:macosx
License:  {LGPL-3 GPL-3 OpenSSLException}
Maintainers:  Email: mcalh...@macports.org, GitHub: MarcusCalhoun-Lopez
  Policy: openmaintainer

Notice that the port depends on several Qt5 ports which are all specified at 
the same level (“57”).  It conflicts with other versions of Qt.

Is that not sufficient?

Craig

Re: [macports-ports] branch master updated: libiodbc: provide variant for extra libodbc.so library

[Ryan Schmidt]

On May 7, 2018, at 10:39, Jeremy L wrote:

> Jeremy L (nerdling) pushed a commit to branch master
> in repository macports-ports.
> 
> 
> https://github.com/macports/macports-ports/commit/c175b9ba889d42decf33b787906eb70801265031
> 
> The following commit(s) were added to refs/heads/master by this push:
> 
>  new c175b9b  libiodbc: provide variant for extra libodbc.so library
> 
> c175b9b is described below
> 
> 
> commit c175b9ba889d42decf33b787906eb70801265031
> 
> Author: Jeremy Lavergne
> AuthorDate: Mon May 7 11:39:28 2018 -0400
> 
> 
> libiodbc: provide variant for extra libodbc.so library
> 
> Fixes trac 55661

Don't forget to refer to Trac tickets in Git commit messages by their absolute 
URL, so that Trac can automatically close tickets for you.


> diff --git a/devel/libiodbc/Portfile b/devel/libiodbc/Portfile
> index 411c695..1de9a3b 100644
> --- a/devel/libiodbc/Portfile
> +++ b/devel/libiodbc/Portfile
> @@ -7,7 +7,7 @@ PortGroup   active_variants 1.1
>  github.setupopenlink iODBC 3.52.12 v
>  #override name (keep it lowercase)
>  namelibiodbc
> -conflicts   unixODBC
> +revision1
>  categories  devel
>  maintainers {snc @nerdling} openmaintainer
>  license BSD
> @@ -26,6 +26,12 @@ depends_build-appendport:automake \
>  
>  patchfiles-append   patch-iodbcinst-unicode.h.diff
>  
> +configure.args-append   --disable-libodbc
> +
> +variant libodbc description {install extra libodbc.so library} {
> +configure.args-replace --disable-libodbc --enable-libodbc
> +}

This variant appears to install the file libodbc.a, not libodbc.so.

The variant needs to contain the "conflicts unixODBC" line, doesn't it?

The unixODBC port still declares that it conflicts with libiodbc. Now it only 
conflicts with libiodbc if the libodbc variant is used, but we don't have a 
syntax for specifying that directly. The simplest workaround I can think of, 
which we've used in a few other ports, is to declare the conflict in unixODBC 
only if the libodbc.a file exists on disk.


> @@ -54,7 +60,7 @@ variant x11 {
>  configure.args-delete   --disable-gui
>  }
>  
> -default_variants +x11
> +default_variants +x11 +libiodbc

Typo: the variant name is libodbc, not libiodbc.

Re: Qt5 port group

[Ryan Schmidt]

On May 9, 2018, at 07:18, Craig Treleaven wrote:

> On May 8, 2018, at 5:06 AM, Vincent Habchi wrote:
> 
>> I was in the process of modifying the Qt5 Port group to allow for choosing 
>> the Qt version one wants to link an application against using variants. 
>> However, before I go further, I’d like to know if concurrent installations 
>> of different Qt5 versions are supported in MacPorts. If not, what I do is 
>> just futile.
> 
> Um, there are subports for each Qt5 version.  Picking one at random:
> 
> $ port info qt57-qtwebkit
> qt57-qtwebkit @5.7.1_1 (aqua)
> Variants: debug, examples, tests, universal
> 
> Description:  Tools and Module(s) for Qt Tool Kit 5: Qt WebKit and Qt 
> WebKit Widgets
> Homepage: http://qt.io
> 
> Extract Dependencies: xz
> Build Dependencies:   python27, pkgconfig
> Library Dependencies: fontconfig, icu, leveldb, webp, libxml2, libxslt, zlib, 
> sqlite3, qt57-qtdeclarative, qt57-qtlocation, qt57-qtmultimedia, 
> qt57-qtsensors, qt57-qtwebchannel, qt57-qtxmlpatterns, qt57-qtbase
> Conflicts with:   qt3, qt3-mac, qt56-qtbase, qt58-qtbase, qt5-qtbase, 
> qt55-qtbase, qt59-qtbase
> Platforms:macosx
> License:  {LGPL-3 GPL-3 OpenSSLException}
> Maintainers:  Email: mcalh...@macports.org, GitHub: 
> MarcusCalhoun-Lopez
>  Policy: openmaintainer
> 
> Notice that the port depends on several Qt5 ports which are all specified at 
> the same level (“57”).  It conflicts with other versions of Qt.
> 
> Is that not sufficient?

My understanding of the fact that they conflict is that there is some latest 
version of Qt that is compatible with each version of macOS, and that by using 
the qt5 portgroup, one automatically receives that version. However, in 
practice, that does not appear to be the case. I see build failures of my 
Qt-using ports on some macOS versions because the chosen version of Qt is not 
compatible with that version of macOS.

Re: [macports-ports] branch master updated: poedit: new port @2.0.7

[Ryan Schmidt]

On May 8, 2018, at 13:53, Rainer Müller wrote:

> I appreciate that you stepped up as the maintainer of poedit after I had 
> given up on it! [1]
> 
> However, the poedit port now bundles full builds of other software, including 
> zlib, gettext, boost, icu, and even wxWidgets.
> 
> That really should be avoided, as this software is already available in 
> separate MacPorts ports. The libraries should be shared and reused instead of 
> building the same software again. Bundling is also a nightmare for 
> maintaining a port, as it implies that any patches applied to the 
> corresponding ports also need to be applied to the sources in the poedit 
> port. Updates will also only be delivered with updates of poedit, so upstream 
> bugs can linger on for a long time.

Generally that's true. Boost is a special case, because boost's developers 
don't care about backward compatibility. It's a good idea for projects to 
bundle and use the version of boost they need.

Re: [macports-ports] branch master updated: libiodbc: provide variant for extra libodbc.so library

[Ryan Schmidt]

On May 9, 2018, at 13:03, Ryan Schmidt wrote:

> The variant needs to contain the "conflicts unixODBC" line, doesn't it?
> 
> The unixODBC port still declares that it conflicts with libiodbc. Now it only 
> conflicts with libiodbc if the libodbc variant is used, but we don't have a 
> syntax for specifying that directly. The simplest workaround I can think of, 
> which we've used in a few other ports, is to declare the conflict in unixODBC 
> only if the libodbc.a file exists on disk.

Actually, the ports still conflict in all cases, on 
/opt/local/include/odbcinst.h at least.

Re: [macports/macports-webapp] Added readme and Database design (7045274)

[Umesh Singla]

Apart from the usual commit guidelines present in the wiki, I found this
particular blog https://chris.beams.io/posts/git-commit/ really helpful.
It's quite popular as well and tries to present the solution very
practically.

Go through it in your free time.

On Wed, May 9, 2018, 10:02 Jackson Isaac  wrote:

> Try to keep the commit messages in active voice. Take care of
> capitalization too.
>
> For e.g., "Add README and database design"
>
> Here I have kept README in all caps since that is how the filename also is.
>
> —
> You are receiving this because you are subscribed to this thread.
> Reply to this email directly, view it on GitHub
> ,
> or mute the thread
> 
> .
>

Re: kmymoney4 not working!

[Mojca Miklavec]

Dear Ben,

On 9 May 2018 at 23:15, Ben W wrote:
>
> Hello Mojca,
>
> Sorry if e-mailing directly is not proper bug reporting etiquette, but I'm 
> not familiar with how or where to do that,

There are three major ways:
- ask on IRC channel #macports on Freenode
- ask on the macports[-devel] mailing list (I'm forwarding your email now)
- login with a github account on our trac.macports.org, search on
https://trac.macports.org/wiki/Tickets for any open tickets against
the port in question and open a new one if one doesn't exist yet.

There are a couple of open tickets, but mostly request(s) to update
the port to a newer version:

https://trac.macports.org/query?0_port=kmymoney&0_port_mode=%7E&0_status=%21closed

I'm forwarding this email to the mailing list, hoping that someone
else can provide a more relevant answer.

Sadly the previous maintainer passed away and there might not be that
many experts familiar with this piece of software.
And KDE is particularly tricky anyway, also because of lack of testing
(I guess that KDE developers usually don't test as much on Mac as they
do on Linux).

> and I found you and your e-mail address on one of the boards recently.

I might have contributed to random semi-unrelated discussion in the
past, but I'm not even sure if I ever attempted to run it.

> In any case, I've recently gotten an older 2010 MacBook Pro running High 
> Sierra to replace my equally old Windows laptop, and I've been able to get 
> everything working to my liking except my accounting program, KMyMoney, and 
> I'm wondering if someone like you could help me!
>
>I'm hardly familiar with this piece of software.
>
> After many hours of trying to figure out how to make it work via the insanely 
> un-user-friendly
> MacPorts/Xcode system, I still have not been able to get it to work, except 
> via a Windows 7
> install inside of Parallels, which takes forever to boot up (I'm not very 
> patient...). On the
> MacPorts page for KMyMoney, it says the 12 dependencies are: xz cmake qt4-mac
> aqbanking5 automoc kde4-runtime kdepimlibs4 libalkimia libofx oxygen-icons 
> phononpkgconfig
> and yet when I install KMyMoney4 via Terminal, I end up getting 298 other 
> ports installed
> alongside KMyMoney4,

Those 12 dependencies are direct dependencies. If each one of them had
12 dependencies on its own, you already end up with half of that
number without even thinking of a few levels deeper. Yes, when one
wants to install just one package, it's often weird to install so many
others, and there are certainly cases where the number could be
reduced at the cost of providing less functionality (lots of packages
have optional dependencies, many dependencies are just build
dependencies). When installing a lot of other packages, the
dependencies are heavily duplicated though. You don't notice that on
Linux because the system already come prepackages with most important
core packages.

> which took hours to download and install, and God knows how much space on my 
> hard drive!

I find it at least a bit strange that it would take long hours to
install. If everything is configured properly, most of the time you
should get the packages from binary archives which - unless you have a
super slow internet connection - should be pretty quick to install.
Not all dependencies install from binary though, those can indeed take
a bit longer, and with 300 dependencies, even if just some of them are
installed from source ... ok, that may sum up. In any case you should
double-check that you are getting binary packages in the first place.

> It appears to have all installed correctly, though when I try to open 
> KMyMoney4, the icon just
> bounces in the dock, along with 'drkonqi', for about 20 seconds, and then 
> just quits and never
> opens. That's all I get.

These "bounces and never opens" is one of the most nasty things on Mac
that's most difficult to debug. If a piece of software fails to build
(due to a minor problem), it's ofter straightforward to fix it, or at
least straightforward to know that compiler is not compatible etc.

> Any ideas/insight? Thanks!

One of developers should probably try to reproduce the problem and see
if or how we can help you. The best first step might be to try to
upgrade the port to the latest version and then take it from there.

Mojca


> Ben
>
> PS Here are the 299 ports that installed...
>
>   akonadi @1.13.1.20141210_4+mariadb55 (active)
>   aqbanking5 @5.6.12_0 (active)
>   aspell @0.60.6.1_1 (active)
>   aspell-dict-en @2018.04.16_0 (active)
>   at-spi2-atk @2.26.2_0 (active)
>   at-spi2-core @2.26.2_0 (active)
>   atk @2.28.1_0 (active)
>   attica @0.4.2_2 (active)
>   autoconf @2.69_5 (active)
>   automake @1.16.1_0 (active)
>   automoc @0.9.88_9 (active)
>   avahi @0.7_1+gtk+gtk3+x11 (active)
>   bison @3.0.4_3 (active)
>   bison-runtime @3.0.4_2 (active)
>   boost @1.66.0_3+no_single+no_static+python27 (active)
>   botan @1.10.17_2 (active)
>   bzip2 @1.0.6_0 (active)
>   cairo @1.14.12

Re: [macports/macports-webapp] uploaded static files online on neocities.org (bd08ef0)

[Umesh Singla]

Afair you just need to specify a static directory variable STATIC_URL
(which is usually present by default) in settings.py and access the files
(img, css, js) in your templates using relative path ("{% static
"my_app/style.css" %}").

Heroku shouldn't affect it in any manner.

I'll emphasize to read the same link Mojca suggested:
https://docs.djangoproject.com/en/2.0/howto/static-files/, at least first
few steps definitely.


On Wed, May 9, 2018, 12:36 Mojca Miklavec  wrote:

> Don't use third-party sites for hosting css. The files should be inside
> this repository and django should be configured properly to find them. I
> don't believe that this does not work.
>
> —
> You are receiving this because you are subscribed to this thread.
> Reply to this email directly, view it on GitHub
> ,
> or mute the thread
> 
> .
>

Re: Qt5 port group

[Craig Treleaven]

> On May 9, 2018, at 2:07 PM, Ryan Schmidt  wrote:
> 
> 
> On May 9, 2018, at 07:18, Craig Treleaven wrote:
> 
>> On May 8, 2018, at 5:06 AM, Vincent Habchi wrote:
>> 
>>> I was in the process of modifying the Qt5 Port group to allow for choosing 
>>> the Qt version one wants to link an application against using variants. 
>>> However, before I go further, I’d like to know if concurrent installations 
>>> of different Qt5 versions are supported in MacPorts. If not, what I do is 
>>> just futile.
>> 
>> Um, there are subports for each Qt5 version.  Picking one at random:
>> 
>> $ port info qt57-qtwebkit
>> qt57-qtwebkit @5.7.1_1 (aqua)
>> Variants: debug, examples, tests, universal
>> 
>> Description:  Tools and Module(s) for Qt Tool Kit 5: Qt WebKit and 
>> Qt WebKit Widgets
>> Homepage: http://qt.io
>> 
>> Extract Dependencies: xz
>> Build Dependencies:   python27, pkgconfig
>> Library Dependencies: fontconfig, icu, leveldb, webp, libxml2, libxslt, 
>> zlib, sqlite3, qt57-qtdeclarative, qt57-qtlocation, qt57-qtmultimedia, 
>> qt57-qtsensors, qt57-qtwebchannel, qt57-qtxmlpatterns, qt57-qtbase
>> Conflicts with:   qt3, qt3-mac, qt56-qtbase, qt58-qtbase, qt5-qtbase, 
>> qt55-qtbase, qt59-qtbase
>> Platforms:macosx
>> License:  {LGPL-3 GPL-3 OpenSSLException}
>> Maintainers:  Email: mcalh...@macports.org, GitHub: 
>> MarcusCalhoun-Lopez
>> Policy: openmaintainer
>> 
>> Notice that the port depends on several Qt5 ports which are all specified at 
>> the same level (“57”).  It conflicts with other versions of Qt.
>> 
>> Is that not sufficient?
> 
> My understanding of the fact that they conflict is that there is some latest 
> version of Qt that is compatible with each version of macOS, and that by 
> using the qt5 portgroup, one automatically receives that version. However, in 
> practice, that does not appear to be the case. I see build failures of my 
> Qt-using ports on some macOS versions because the chosen version of Qt is not 
> compatible with that version of macOS.

The automatic upgrading that the portgroup does is a bit scary.  It seemed like 
it was no time at all that we went from 5.7.1 to 5.10.  (Even though Qt, at the 
time, said that they didn’t support the latest MacOS version.)  MythTV needed 
some fixes for Qt 5.10 for some months after MacPorts moved forward.  I still 
need to do some testing to see if some interface glitches are present with both 
5.10 and (say) 5.5.  

I wish the portgroup gave some way to say “I don’t want to be on the bleeding 
edge but I don’t want to be stuck at Qt 5.x forever, either”.  After all, the 
vast majority of Linux installs are still running Qt 5.5.  Maybe this is where 
variants could help.  I don’t have a good solution.

Craig

MacPorts 2.5.0-beta1 now available for testing

[Joshua Root]

Source code and pkgs for MacPorts 2.5.0-beta1 are now
available [1]. Testing of either of these install methods is helpful.

Be prepared to encounter bugs. As always, having a recent backup would
be wise. Please report any bugs that you find [2] (after first searching
Trac [3], of course!)

There are a large number of changes in this release. See the ChangeLog
[4] for a list of most of the major ones. You may like to focus your
testing on the new features in that list, as well as your normal usage.

Cheers,
Josh

[1] 
[2] 
[3] 
[4]