Re: [QGIS-Developer] Stale bot and older requests/issues - possible enhancement

[Stefan Steiger]

>> As a user and employee of a French administration, I think what is proposed 
>> would be an excellent reminder. Open source is not free.


Wrong on so many levels.

First: GPL = Free Software
So since the license of QGIS is GPL, it’s free software.
“Free Software” means that along with the software, you get the source code for 
free, included in that is the freedom to change and redistribute it.
Free as in Freedom. That does not mean it’s gratis.

Second: “OpenSource” is not the same as 'Free Software'
“OpenSource” merely means you have the source.
It doesn’t mean you’re allowed to change or redistribute it.
It also doesn’t mean it’s gratis.
So “OpenSource” is much worse than GPL./ 'Free Software'.

Third misconception:
Free (as in freedom) doesn’t mean it’s gratis.
It just means you have the freedom to alter and redistribute the software, 
provided you abide by the license’s requirements, which means granting the same 
right to others.
It also doesn’t mean somebody else does your work for you, or pays somebody 
else to do your work for you.
Therefore QGIS is indeed free, just not gratis.

What you mean to say is that Free is not Gratis.
That’s a truism/platitude.

Also, if you use commercial software, you pay far more for the same, and you 
don’t have ANY guarantee that ANY bug is fixed, even if you can pay.
You also cannot usually pay anyone else than the original company to do some 
work on it, even if somebody else could do the same work far cheaper.
With commercial software, you also don’t have any guarantee that the product 
isn’t discontinued tomorrow, or taken into a completely different direction.

As with plugins:
As long as they are NOT distributed with the software BY DEFAULT, they don’t 
necessarily have to abide by the GPL.
As long as you only use it internally (e.g. on a WebServer), you don’t have to 
abide by the terms of the GPL (the 
Affero/Application-Service-Provider
 loophole).



Von: QGIS-Developer  Im Auftrag von JD L
Gesendet: Donnerstag, 7. Januar 2021 10:10
An: Matthias Kuhn 
Cc: qgis-developer 
Betreff: Re: [QGIS-Developer] Stale bot and older requests/issues - possible 
enhancement


Hi

As a user and employee of a French administration, I think what is proposed 
would be an excellent reminder. Open source is not free.

Le jeu. 7 janv. 2021 à 09:33, Matthias Kuhn 
mailto:matth...@opengis.ch>> a écrit :
Hi Nyall,

I would also appreciate a hint like this.
Maybe it could be done even more subtle by shortening this text and adding a 
link to a page "learn how to make things progress"?

I'd also very much appreciate the voices of users on this topic (that's a 
classical "we don't only want to hear the dev side" topic).

Matthias

On Thu, Jan 7, 2021 at 1:42 AM Nyall Dawson 
mailto:nyall.daw...@gmail.com>> wrote:
Hi list,

I've a small request to consider for stale bot and issues/feature
requests. I think that if a ticket remains open for say > 90 days
since the last comment, it would be nice if stale bot added a comment
like:

"Unfortunately this bug/feature request has not seen any solution in
the recent QGIS release. If this fix/feature is important to you or
your organisation, you can help to fast-track its development by
sponsoring this work. To do so, contact one of the QGIS commercial
support providers listed at ... to discuss how you could fund this
functionality".

I think it's a non-threatening, non-begging way to advise bug
reporters on the alternative ways they can fast track development in
QGIS.

Thoughts?

Nyall
___
QGIS-Developer mailing list
QGIS-Developer@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
___
QGIS-Developer mailing list
QGIS-Developer@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
___
QGIS-Developer mailing list
QGIS-Developer@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [QGIS-Developer] QGIS for Apple: Intel vs. arm

[Stefan Steiger]

Hi,

Well, Linux systems for ARM have existed for ages NOW.
Simply put, the energy consumption of ARM devices is far lower than intel’s 
crap.
That’s why Apple is doing it, they have announced that intention years ago.
Microsoft has started shipping tables for ARM, too, btw.
Though, MS is not quite there, yet, and they probably never will be, not within 
the next few years at least.

You can do cross-compile builds with CLANG/LLVM on a 250$ Chromebook using 
OSXcross.
https://github.com/tpoechtrager/osxcross
Chromebooks are the easiest commercially obtainable ARM-computers nowadays.
Switch to developer mode, install Crouton with ARM-Ubuntu in a chroot, and 
there you go.
Or install Chrubuntu if you don’t want to use the kernel of the underlying 
ChromeOS.
Using Chrubuntu, you might have trouble with drivers, though.

That worked for me; mono (.NET) and Java work on ARM, too.

PS:
Why not simply ship a Linux-Docker-Image for ARM processors ?
It is my understanding Linux Docker images work on OSX.
Certainly would work for server components.
GUI might be a different chapter, but since OSX can do X11 ...
Not sure how Wayland would play into that, though.

The most intelligent way would be dropping the proprietary Desktop-GUIs anyway.
Switching to a web-based editor.
Then you can drop everything but Linux, and just ship docker containers.
Users connect via browser.
Saves a lot of work.
Also a lot more secure.

All you need to ship per platform then is an icon and a startup 
link/shell-script.



Von: QGIS-Developer  Im Auftrag von 
Andreas Neumann
Gesendet: Mittwoch, 24. Juni 2020 11:11
An: QGIS Developers List 
Betreff: [QGIS-Developer] QGIS for Apple: Intel vs. arm


Hi all, esp. Peter,

So I wonder what the new announcement of Apple switching everything from Intel 
to arm architecture will mean for our project? According to Apple they will 
switch all of their devices to arm over the next 2 years.

Will it be a lot of work to adapt the build system to the new processor 
architecture? It will probably mean that we will need an additional Mac build 
server for arm architecture in our infrastructure and will have to provide 
packages for both systems for many years to come ...

Not so nice for us as a project - can we forward these costs to Apple for that 
move?

Greetings,
Andreas
___
QGIS-Developer mailing list
QGIS-Developer@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [QGIS-Developer] Fwd: Urgent: Remove windows 3.10.2 installer from site

[Stefan Steiger]

You made a mistake translating/editing:
„the important of“ ==> „the importance of“

As such, we cannot stress enough the important of updating now.
==>
As such, we cannot stress enough the importance of updating now.


Posting that would be embarrassing



Von: QGIS-Developer [mailto:qgis-developer-boun...@lists.osgeo.org] Im Auftrag 
von Mathieu Pellerin
Gesendet: Mittwoch, 22. Januar 2020 10:58
An: Paolo Cavallini ; qgis-developer 

Betreff: Re: [QGIS-Developer] Fwd: Urgent: Remove windows 3.10.2 installer from 
site

Paolo, here's the draft blog post:

*Public Service Announcement: Update to the latest point release now*
--
QGIS users who have adopted the 3.10 version when initially released at the end 
of October 2019 have likely noticed a sharp drop in reliability. The underlying 
issues have now been addressed in 3.10.2, all users are advised to update *now*.

When QGIS 3.10 was first released in the end of October 2019, a pair of 
libraries – namely GDAL and PROJ – were updated to their next-generation 
versions. The advantages are plenty: GeoPDF export[1] support, more accurate 
coordinate transformation, etc. For those interested, more technical 
information on this is available here[2].

The update of these crucial libraries led to a number of regressions. While we 
expected some issues to arise, the seriousness of the disruption caught us off 
guard. Yet, it was also somewhat inevitable: QGIS is the first large GIS 
project to expose these next-generation libraries to the masses. The large 
number of QGIS users across the globe were essentially stress testing both new 
code within QGIS as well as the libraries themselves.

Thanks to dedicated users taking time to file in report and the community 
helping out as well as our project sponsors for allowing us to fund development 
time, developers have been able to fix all known regressions in both in QGIS as 
well as underlying GDAL and PROJ libraries, benefiting a large number of open 
source projects.

As a result of this collective effort by the community, QGIS 3.10.2 is now back 
to being the reliable and stable GIS software we all love. As such, we cannot 
stress enough the important of updating now.

Once again, thanks to our community of testers, sponsors, and developers for 
their countless hours and efforts in making QGIS better.

Happy mapping!

[1] https://north-road.com/2019/09/03/qgis-3-10-loves-geopdf/
[2] https://gdalbarn.com/

On Tue, Jan 21, 2020 at 9:56 AM Paolo Cavallini 
mailto:cavall...@faunalia.it>> wrote:
Fully agreed. Mathieu, would you like to write it?
Thanks.
On 21 January 2020 06:39:08 GMT+04:00, Mathieu Pellerin 
mailto:nirvn.a...@gmail.com>> wrote:
+100 on all that's been said here.

Also, once 3.10.2 is updated to include the updated packages & above-referred 
fix, I'd suggest writing a QGIS.org blog post to inform users of the worthiness 
of updating to 3.10.2(.2) *ASAP*, and expand a bit on why 3.10.0/.1 were such 
rough releases. We can finish the post by thanking users that have reported 
bugs (an inevitable nightmare to go through as QGIS was exposing brand new 
GDAL3/PROJ6 versions to the masses). IMHO, we should not skip this 
communication to our users.

On Tue, Jan 21, 2020 at 7:27 AM Nyall Dawson 
mailto:nyall.daw...@gmail.com>> wrote:
Also, we better wait for a fix for
https://github.com/qgis/QGIS/issues/33902 (incoming)...

Gosh, will the nightmare ever end... Let's agree never to change
anything in gdal or proj or qgis ever again ;)

Nyall


-- Forwarded message -
From: Nyall Dawson mailto:nyall.daw...@gmail.com>>
Date: Tue, 21 Jan 2020 at 06:28
Subject: Urgent: Remove windows 3.10.2 installer from site
To: qgis-developer 
mailto:qgis-developer@lists.osgeo.org>>


Can we please remove the 3.10.2 installer from the website as a matter
of urgency? This installer was released using the older gdal 3.0.2 and
proj 6.2 versions, which directly lead to crashes and reprojection
failures in QGIS.

QGIS SHOULD NEVER EVER*** be
used with gdal >= 3 and gdal < 3.0.3 or proj >6 and proj < 6.3.0.

This combination is a world of hurt for users :(

Tickets filed at https://trac.osgeo.org/osgeo4w/ticket/618, and
https://trac.osgeo.org/osgeo4w/ticket/617, and later today I'm going
to commit cmake blocks which will completely prevent compilation under
the affected gdal/proj versions.

Nyall
___
QGIS-Developer mailing list
QGIS-Developer@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer

--
Please excuse my brevity.
___
QGIS-Developer mailing list
QGIS-Developer@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [QGIS-Developer] QGIS-Developer Digest, Vol 165, Issue 24

[Stefan Steiger]

A cynical joke :)

I think you are talking about something like this ? 
https://gis.stackexchange.com/questions/277677/qgis-problem-with-postgresql-postgis-column-permissions
 

Correct working depends on the SQL-statements issued by QGIS. 
If it updates values in columns where no value changed, it requires 
GRANT-UPDATE rights to this columns. 

This is more of a SQL-generation problem than a permission issue. 
It shouldn't issue updates on values that didn't change, but it does. 

And if you update values where you don't have update rights, that generates an 
SQL error. 

Besides, how are column-level permissions supposed to work ? 
What happens if you load a value from a column where you don't have permission, 
and then save/update back the fields of a record where you have permissions. 
The result is potential data garbage.  
The entire idea of partial data loading AND THEN BEING ABLE TO SAVE the loaded 
data (or parts thereof) back is a somewhat fishy concept. 
Either you can alter an entire record, or you cannot. 

At this point it would be worth pointing out that seeing a subset of available 
records (e.g. via portfolio rights) presents similar issues. 
Are different users going to see different results when they sum areas, for 
example ? 
Are they going to do some financial calculation with the result ? 
Who sets the permissions, and how do you guarantee permissions are set properly 
? 
Are any unfortunate combination of permissions gonna crash the system ? Gonna 
cause malfunctions ? 
Query performance - is it going to grind the system to a halt ? 

If anybody is going to implement any kind of permissions, you need to think 
about ALL the consequences first, and also whether or not that makes sense in 
the first place, especially considering the computational complexity this adds 
to your program.  And then you need to decide if that added value is worth the 
costs it incurs, especially including opportunity costs. 



-Ursprüngliche Nachricht-
Von: Giovanni Manghi [mailto:giovanni.man...@gmail.com] 
Gesendet: Donnerstag, 11. Juli 2019 17:20
An: Stefan Steiger 
Cc: qgis-developer@lists.osgeo.org
Betreff: Re: [QGIS-Developer] QGIS-Developer Digest, Vol 165, Issue 24

> @giovanni:
> It works if you're SuperUser :p

oh really?! column level permissions works only if the user is superuser? is 
that a feature or bug? of qgis or postgresql? :)

cheers!

-- G --
___
QGIS-Developer mailing list
QGIS-Developer@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [QGIS-Developer] QGIS-Developer Digest, Vol 165, Issue 24

[Stefan Steiger]

There's a docker file, if anybody  wants to try PostgreSQL 12:
https://github.com/docker-library/postgres/blob/87b15b6c65ba985ac958e7b35ba787422113066e/12/Dockerfile
 
 
@giovanni: 
It works if you're SuperUser :p



-Ursprüngliche Nachricht-
Von: QGIS-Developer [mailto:qgis-developer-boun...@lists.osgeo.org] Im Auftrag 
von Giovanni Manghi
Gesendet: Donnerstag, 11. Juli 2019 13:19
An: qgis-developer@lists.osgeo.org
Betreff: Re: [QGIS-Developer] QGIS-Developer Digest, Vol 165, Issue 24

Hi all,


> Here is a quite interesting new feature in PostgreSQL 12:
>
> https://www.2ndquadrant.com/en/blog/generated-columns-in-postgresql-12
> /
>
> It is similar to virtual columns in QGIS.
>
> I suspect that users will want to use that new column type. What does 
> this mean for QGIS? I guess QGIS will have to detect this new column 
> type in the future and mark it as "immutable". So other columns are 
> read/write, but generated columns will be read only. Does QGIS already 
> support a concept like this where some columns are read/write and 
> others not

speaking about unsupported postgresql features it would also be very useful 
supporting correctly column permissions, the last time I checked (not recentli 
I admit) it didn't worked at all in QGIS.

cheers!

-- G --
___
QGIS-Developer mailing list
QGIS-Developer@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
___
QGIS-Developer mailing list
QGIS-Developer@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [QGIS-Developer] Generated columns in PostgreSQL 12

[Stefan Steiger]

One thing it potentially means is auto-generated insert/update-scripts fail, 
because they insert all fields, including computed columns.
Don’t know how PostgreSQL-12 handles inserts on computed/generated columns 
though, this is speaking from experience with SQL-server computed columns.
It’s not sure PostgreSQL throws on INSERTs/UPDATEs statements on generated 
columns though, so theoretically, this column could actually be mutable.
If this feature does nothing more than adding a hidden insert-update trigger, 
then this might be so, and that wouldn’t necessarily be bad.


Von: QGIS-Developer [mailto:qgis-developer-boun...@lists.osgeo.org] Im Auftrag 
von Andreas Neumann
Gesendet: Mittwoch, 10. Juli 2019 16:22
An: QGIS Developers List 
Betreff: [QGIS-Developer] Generated columns in PostgreSQL 12


Hi,

Here is a quite interesting new feature in PostgreSQL 12:

https://www.2ndquadrant.com/en/blog/generated-columns-in-postgresql-12/

It is similar to virtual columns in QGIS.

I suspect that users will want to use that new column type. What does this mean 
for QGIS? I guess QGIS will have to detect this new column type in the future 
and mark it as "immutable". So other columns are read/write, but generated 
columns will be read only. Does QGIS already support a concept like this where 
some columns are read/write and others not?

Greetings,

Andreas
___
QGIS-Developer mailing list
QGIS-Developer@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [QGIS-Developer] SSL Performance Overhead

[Stefan Steiger]

Uh, ah, yea, also, sending a password for a DB-user over the intranet-network 
in plain text is rather bad. 
While the data retrieved from the DB might not be confidential, maybe there is 
confidential data in the db. 
Also, the login used could have permissions onto another DB that has 
confidential data inside. 

In my opinion, the default should be SSL, including in intranet.  
If anybody changes the default for performance reasons, they can, and 
correspondingly, the blame will be theirs if anything happens. 
Nowadays, we use SSL even in development. 
Just my 0.05 $


-Ursprüngliche Nachricht-
Von: QGIS-Developer [mailto:qgis-developer-boun...@lists.osgeo.org] Im Auftrag 
von Bernhard Ströbl
Gesendet: Montag, 17. Juni 2019 15:31
An: qgis-developer@lists.osgeo.org
Betreff: Re: [QGIS-Developer] SSL Performance Overhead

Hi all,

I have to add that we use SSL to encrypt the user credentials as we use LDAP to 
authentificate users at the database. So SSL is not only relevant looking at 
data stored in the database.
Bernhard

Am 17.06.2019 um 13:56 schrieb Andreas Neumann:
> Hi Stefan,
> 
> Yes, sure. If I were a bank or the national bank I would also mandate 
> use of SSL. Also, when personal data is involved. But many gov 
> authorities have primarily publically available geoinformation (object 
> data, no personal data) in their DBs and no sensitive data.
> 
> We are just discussing the defaults, anyone can enable SSL if it is 
> useful or required in their usage scenario.
> 
> Andreas
> 
> On 2019-06-17 13:20, Stefan Steiger wrote:
> 
>> One of our customers (Swiss National Bank) mandates the use of SSL in 
>> their internal LAN, even for DB connections.
>>
>> Using anything but SSL is an insecure mode of communication, even in LAN.
>>
>> RSA/DSA Accepted key-length is 2048 bit, recommended is 3072, ECC is
>> 160 Bit, recommended 256.
>>
>> -Only latest version of OpenSSL allowed
>>
>> -Accepted TLS 1.1+, recommended TLS 1.2+
>>
>> -SSL Version 3.0 or older are explicitly forbidden
>>
>> -Sha-1 is disallowed, sha2/3 accepted @ hash length 256 Bit
>>
>> -Extended Validation certificates have to be used
>>
>> -Wildcards in fully qualified names not allowed
>>
>> -Accepted: CTR/CBC/CCM/EAX, recommended GCM
>>
>> -SSL accepted with forward secrecy Disabled, recommended Enabled
>>
>> -Recommended CryptRandom: /dev/random, /dev/urandom,
>>
>> as per IT Security Baseline 2017-07-20
>>
>> *Von:*QGIS-Developer [mailto:qgis-developer-boun...@lists.osgeo.org]
>> *Im Auftrag von *Andreas Neumann
>> *Gesendet:* Montag, 17. Juni 2019 09:05
>> *An:* Matthias Kuhn 
>> *Cc:* qgis-developer@lists.osgeo.org
>> *Betreff:* Re: [QGIS-Developer] SSL Performance Overhead
>>
>> Hi,
>>
>> I would say, that the use of SSL should be encouraged if the 
>> connection goes through public networks. If the Postgis connection is 
>> within the company LAN I don't see a strong reason for enabling SSL, 
>> unless the company LAN is designed in an "unsafe" way, or if 
>> sensitive data must be hidden from other employees in the same company.
>>
>> Personally, I never had good results (performance wise) if Postgis 
>> connections went through the public Internet, unless it is some "toy 
>> data".
>>
>> For this reason, I usually used streaming replication to replicate 
>> Postgis, so it is as close as possible to the users who need the data.
>> The streaming replication, if it goes through the public internet, of 
>> course should use SSL (or often it goes through an SSH tunnel).
>>
>> Sorry, I don't have any data on the overhead of SSL connections though.
>>
>> Andreas
>>
>> On 2019-06-17 08:48, Matthias Kuhn wrote:
>>
>> Hi,
>>
>> The documentation currently promises "massive speed-ups in PostGIS
>> layer rendering" with SSL disabled. [1
>> 
>> <https://docs.qgis.org/2.18/en/docs/user_manual/managing_data_source/
>> opening_data.html#creating-a-stored-connection>]
>>
>> I find some references to performance cost of SSL but they should
>> be compensated for with connection pooling which we use for quite
>> some time already.
>>
>> Recently, the web is more and more encrypted - and that is very
>> good! - so I think we should also start to encourage people to
>> encrypt their SSL connections. Or at least certainly not
>> discourage them from using encryption by promising performance
>> benefits.
>>
>> Is there anyone who knows why this sentence

Re: [QGIS-Developer] SSL Performance Overhead

[Stefan Steiger]

One of our customers (Swiss National Bank) mandates the use of SSL in their 
internal LAN, even for DB connections.
Using anything but SSL is an insecure mode of communication, even in LAN.
RSA/DSA Accepted key-length is 2048 bit, recommended is 3072, ECC is 160 Bit, 
recommended 256.


-  Only latest version of OpenSSL allowed

-  Accepted TLS 1.1+, recommended TLS 1.2+

-  SSL Version 3.0 or older are explicitly forbidden

-  Sha-1 is disallowed, sha2/3 accepted @ hash length 256 Bit

-  Extended Validation certificates have to be used

-  Wildcards in fully qualified names not allowed

-  Accepted: CTR/CBC/CCM/EAX, recommended GCM

-  SSL accepted with forward secrecy Disabled, recommended Enabled

-  Recommended CryptRandom: /dev/random, /dev/urandom,

as per IT Security Baseline 2017-07-20


Von: QGIS-Developer [mailto:qgis-developer-boun...@lists.osgeo.org] Im Auftrag 
von Andreas Neumann
Gesendet: Montag, 17. Juni 2019 09:05
An: Matthias Kuhn 
Cc: qgis-developer@lists.osgeo.org
Betreff: Re: [QGIS-Developer] SSL Performance Overhead


Hi,

I would say, that the use of SSL should be encouraged if the connection goes 
through public networks. If the Postgis connection is within the company LAN I 
don't see a strong reason for enabling SSL, unless the company LAN is designed 
in an "unsafe" way, or if sensitive data must be hidden from other employees in 
the same company.

Personally, I never had good results (performance wise) if Postgis connections 
went through the public Internet, unless it is some "toy data".

For this reason, I usually used streaming replication to replicate Postgis, so 
it is as close as possible to the users who need the data. The streaming 
replication, if it goes through the public internet, of course should use SSL 
(or often it goes through an SSH tunnel).

Sorry, I don't have any data on the overhead of SSL connections though.

Andreas

On 2019-06-17 08:48, Matthias Kuhn wrote:
Hi,

The documentation currently promises "massive speed-ups in PostGIS layer 
rendering" with SSL disabled. 
[1]

I find some references to performance cost of SSL but they should be 
compensated for with connection pooling which we use for quite some time 
already.

Recently, the web is more and more encrypted - and that is very good! - so I 
think we should also start to encourage people to encrypt their SSL 
connections. Or at least certainly not discourage them from using encryption by 
promising performance benefits.

Is there anyone who knows why this sentence was introduced? And if there is 
(still) an issue with performance when using SSL?

Best regards

Matthias

[1] 
https://docs.qgis.org/2.18/en/docs/user_manual/managing_data_source/opening_data.html#creating-a-stored-connection

[2] https://github.com/qgis/QGIS-Documentation/pull/3840

___
QGIS-Developer mailing list
QGIS-Developer@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer


___
QGIS-Developer mailing list
QGIS-Developer@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [QGIS-Developer] New version notifications

[Stefan Steiger]

And for that reason, just use docker, and you don't have that problem. 
 ( instead, you might have others ;)   )

Works fine for me with MSSQL-Server 2017 & Viber on Ubuntu 19.04, with OpenSSL 
1.1. 


-Ursprüngliche Nachricht-
Von: QGIS-Developer [mailto:qgis-developer-boun...@lists.osgeo.org] Im Auftrag 
von Jürgen E. Fischer
Gesendet: Mittwoch, 5. Juni 2019 22:17
An: qgis-developer@lists.osgeo.org
Betreff: Re: [QGIS-Developer] New version notifications

Hi Cory,

On Wed, 05. Jun 2019 at 11:03:26 -0400, Cory Albrecht wrote:
> Except I got the package from QGIS's *own* repo, as I indicated. If 
> QGIS is going to be alerting me that there is a new version, shouldn't 
> that new version be available in the QGIS repo?

Depends.  If you're using a distribution that doesn't have the necessary 
dependencies for the newer version, the newer version will never reach the repo 
for that distribution.

But you'll still get the notification about the latest version and in this case 
it just means that you not only have to upgrade QGIS to get it. 


Jürgen

-- 
Jürgen E. Fischer   norBIT GmbH Tel. +49-4931-918175-31
Dipl.-Inf. (FH) Rheinstraße 13  Fax. +49-4931-918175-50
Software Engineer   D-26506 Nordenhttps://www.norbit.de
QGIS release manager (PSC)  GermanyIRC: jef on FreeNode
___
QGIS-Developer mailing list
QGIS-Developer@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [QGIS-Developer] Windows only version of a QGIS 2.18x plugin

[Stefan Steiger]

Yea, but I preferably don’t want to have to lookup a website for every plugin 
if somebody gives me a list of plugins to install.

If you have plugins, there will generally be a few categories:

1)  The ones that only use Python

2)  The ones that use Python and custom python modules, or native binaries

3)  The ones that use Python R/Java/.NET/C/C++/Ruby/Whatever


Now 1) goes into all platforms, everything else into a platform repository, 
because it anyway has to. (JRE in the proper version is not necessarely 
installed)
And done. No metadata necessary.

Since the QGIS maintainers know for which platforms they compile QGIS, that 
limits the list of necessary platform repositories.
If a third-party wants to support another platform, they can make their own 
repo.
If it gets traction, it can be added to the main, if not, then it’s good the 
way it is.

Anyway, since there might be native dependencies, the whole thing would belong 
into apt/yum/pacman/whatever in the first place, because that is where package 
management happens, and plugin management is exactly that.
If I want to update qgis to the latest version, I should at the very least get 
warnings if plugin X is not ready – and I should get that warning the moment I 
want to update qgis.
Which is why it would belong into the package manager.


Von: Matthias Kuhn [mailto:matth...@opengis.ch]
Gesendet: Mittwoch, 6. Februar 2019 17:46
An: Stefan Steiger ; C Hamilton 

Cc: qgis-dev 
Betreff: Re: [QGIS-Developer] Windows only version of a QGIS 2.18x plugin


Hi
On 2/6/19 5:28 PM, Stefan Steiger wrote:

The problem with metadata is that if you use it, you have no way to easily know 
if something (a  group of plugins) uses a platform-specific plugin.

For example, in ubuntu, I can choose:

-  Official  (secure)

-  Universe (insecure/half-legal)

-  Partner (copyrighted/patented)

-  and of course custom repos

So if somebody or some tutorial tells me to add the « universe » repo, I know 
instantly not to do that on a server or in a security-critical situation.

If it instead would tell me to install package x, which then installs 20 other 
packages, which then each install more packages – how do I even filter that 
information if I have per-package metadata ?  I wouldn’t even use metadata for 
that, because something might run on Linux, but not on your specific version, 
for example ARM processor on Linux Chromebook. You’ll have to subdivide by 
processor for binaries.  Plugins can depend on other plugins.

It might be even better to have 5 repositories:
All-platforms, Windows-only, Linux-Only, Mac-Only, Rest-of-the-world
So if your plugin works on Windows and Linux, you just upload it to the 2 
repositories, and finished.

If somebody then tells me to add a „windows only“ plugin, I know to steer clear 
of that shit if I use Linux, and vice-versa.
And that without having to lookup metadata.



I agree that if we want to have plugins sorted by their legality or other 
somehow dubious practices, separate repositories are a good way to go.

Plugins which only support a subset of possible platforms are in no way more 
nor less critical than any other plugin which claims to support all platforms.

The metadata we talk about here is not something to lookup by people on a 
regular basis, but for

- the plugin manager to check if it's suitable for the current platoform (i.e. 
it will not even offer me to install it on my Linux machine), just like Ubuntu 
won't even offer arm packages if it's running on a x86_64 machine.

- general information purpose on the plugin website

Matthias
___
QGIS-Developer mailing list
QGIS-Developer@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [QGIS-Developer] Windows only version of a QGIS 2.18x plugin

[Stefan Steiger]

The problem with metadata is that if you use it, you have no way to easily know 
if something (a  group of plugins) uses a platform-specific plugin.

For example, in ubuntu, I can choose:

-  Official  (secure)

-  Universe (insecure/half-legal)

-  Partner (copyrighted/patented)

-  and of course custom repos

So if somebody or some tutorial tells me to add the « universe » repo, I know 
instantly not to do that on a server or in a security-critical situation.

If it instead would tell me to install package x, which then installs 20 other 
packages, which then each install more packages – how do I even filter that 
information if I have per-package metadata ?  I wouldn’t even use metadata for 
that, because something might run on Linux, but not on your specific version, 
for example ARM processor on Linux Chromebook. You’ll have to subdivide by 
processor for binaries.  Plugins can depend on other plugins.

It might be even better to have 5 repositories:
All-platforms, Windows-only, Linux-Only, Mac-Only, Rest-of-the-world
So if your plugin works on Windows and Linux, you just upload it to the 2 
repositories, and finished.

If somebody then tells me to add a „windows only“ plugin, I know to steer clear 
of that shit if I use Linux, and vice-versa.
And that without having to lookup metadata.





Von: C Hamilton [mailto:adenacult...@gmail.com]
Gesendet: Mittwoch, 6. Februar 2019 17:02
An: Stefan Steiger 
Cc: Martin Dobias ; Paolo Cavallini 
; qgis-dev 
Betreff: Re: [QGIS-Developer] Windows only version of a QGIS 2.18x plugin

I have been following this interesting discussion and thought I would make a 
couple of comments. I understand the different views people have. Ideally it 
would be nice for all plugins to work on all platforms, but I can see the 
benefit from certain plugins accessing external libraries that are not 
available on all platforms. I have considered doing this myself in accessing 
some of the excellent astronomical packages on Windows, but have been concerned 
that I could no post the plugin in the official repo. Yes you can set up a 
separate repo, but it makes it very difficult for the plugin to be found and it 
would not be worth it to me to put in the effort to have it not be officially 
recognized and be discoverable.

I personally think it is important that there be some mechanism for people to 
publish plugins that have platform dependencies. Ideally, they would first try 
to find alternative solutions before making the decision to link to platform 
specific resources, but some very important capabilities will require this. I 
wouldn't want to discourage developers by insisting that all plugins must work 
on all platforms.

I am not sure that having two separate repositories is the best approach 
either. I don't think that a separate repo should be classified as 'dirty', 
etc. I would think that this could be addressed by the metadata associated with 
the plugin.

Calvin

On Wed, Feb 6, 2019 at 10:36 AM Stefan Steiger 
mailto:stei...@cor-management.ch>> wrote:

Is it not possible to create two official repositories ?
One for "all-platforms", one for "dirty/fishy/phony/dubious/in-progress"


-Ursprüngliche Nachricht-
Von: QGIS-Developer 
[mailto:qgis-developer-boun...@lists.osgeo.org<mailto:qgis-developer-boun...@lists.osgeo.org>]
 Im Auftrag von Martin Dobias
Gesendet: Mittwoch, 6. Februar 2019 15:50
An: Paolo Cavallini mailto:cavall...@faunalia.it>>
Cc: qgis-dev 
mailto:qgis-developer@lists.osgeo.org>>
Betreff: Re: [QGIS-Developer] Windows only version of a QGIS 2.18x plugin

On Wed, Feb 6, 2019 at 12:04 PM Paolo Cavallini 
mailto:cavall...@faunalia.it>> wrote:
>
> On 06/02/19 09:42, Richard Duivenvoorde wrote:
>
> > If you prefer to put it in QGIS repo: just add a big note in the
> > metadata.txt description that this plugin is only usable with vesper
> > and windows. And maybe do an OS check in the __init__ for illiterate
> > users ;-)
>
> I respectfully disagree with that: at the very core of the QGIS
> project it stands the idea of letting everybody use the best possible
> GIS, without discrimination. This kind of approach would in fact
> favour Windows users.

My preference would be to keep the official QGIS plugin repo more open and 
allow plugins that do not support all QGIS platforms. Often there are useful 
tools that are only available for one platform and plugin author does not have 
power to change that. But we should not make life of users on the supported 
platform more complicated just because other platforms cannot be supported.

As it was suggested already, if there would be a larger amount of plugins that 
are not multi-platform, we could have a piece of metadata so that users on 
other platforms could be warned.

For example, Crayfish plugin for QGIS 2.x did not support macOS - it was a 
known limitation and it would be sad

Re: [QGIS-Developer] Windows only version of a QGIS 2.18x plugin

[Stefan Steiger]

Is it not possible to create two official repositories ? 
One for "all-platforms", one for "dirty/fishy/phony/dubious/in-progress" 


-Ursprüngliche Nachricht-
Von: QGIS-Developer [mailto:qgis-developer-boun...@lists.osgeo.org] Im Auftrag 
von Martin Dobias
Gesendet: Mittwoch, 6. Februar 2019 15:50
An: Paolo Cavallini 
Cc: qgis-dev 
Betreff: Re: [QGIS-Developer] Windows only version of a QGIS 2.18x plugin

On Wed, Feb 6, 2019 at 12:04 PM Paolo Cavallini  wrote:
>
> On 06/02/19 09:42, Richard Duivenvoorde wrote:
>
> > If you prefer to put it in QGIS repo: just add a big note in the 
> > metadata.txt description that this plugin is only usable with vesper 
> > and windows. And maybe do an OS check in the __init__ for illiterate 
> > users ;-)
>
> I respectfully disagree with that: at the very core of the QGIS 
> project it stands the idea of letting everybody use the best possible 
> GIS, without discrimination. This kind of approach would in fact 
> favour Windows users.

My preference would be to keep the official QGIS plugin repo more open and 
allow plugins that do not support all QGIS platforms. Often there are useful 
tools that are only available for one platform and plugin author does not have 
power to change that. But we should not make life of users on the supported 
platform more complicated just because other platforms cannot be supported.

As it was suggested already, if there would be a larger amount of plugins that 
are not multi-platform, we could have a piece of metadata so that users on 
other platforms could be warned.

For example, Crayfish plugin for QGIS 2.x did not support macOS - it was a 
known limitation and it would be sad if the plugin would be rejected from the 
official QGIS plugin repo just because of that.

Cheers
Martin
___
QGIS-Developer mailing list
QGIS-Developer@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
___
QGIS-Developer mailing list
QGIS-Developer@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [QGIS-Developer] Exporting from QGIS to CAD format - is it possible to offer DWG export

[Stefan Steiger]

You could use the ODA File-Converter to convert dwg to dxf and vice-versa. 
https://www.opendesign.com/guestfiles/oda_file_converter 

It can also run as batch-process. 
Runs natively on Linux/Mac/Windows, 32&64 Bit.
It's Freeware, AFAIK. 
That way you can guarantee it will always be able to read and write the latest 
DWGs. 


You can also use the Teigha Online File Converter, which converts .dwg/.dxf 
files to PDF/BMP.
https://www.opendesign.com/teigha_online_converter 


You cannot currently have a free program that reads and writes DWG on its own. 
DWG is a proprietary file format, on purpose designed to be difficult to 
understand, and it's encrypted. 
To be able to flawlessly read and write DWGs, you need to reverse-engineer the 
AutoCAD file format, by reverse-engineering AutoCAD. 
This naturally takes a lot of time, which means there are no Free-Software DWG 
libraries that implement a sufficiently large subset of the AutoCAD file 
format. 
There are currently only two software applications that offer a reliable DWG 
interface. 
One is ODA Teigha for C++/Java/.NET. 
The other is Woutware CADlib.

The problem with ODA-Teigha ist hat it takes royalties for each and every 
application deployed with Teigha. 
Which would be deadly for a free software project. 

WoutWare is better in this respect, as it requires a one-time license of 
currently 1'208 USD/year per developer. 
Also, Teigha is a pain in the ass to use. 
The problem with WoutWare is, that you need a new license each time you need to 
download a new version of WoutWare because there was a new version of AutoCAD. 
Also, WoutWare is .NET and therefore currently only works on Windows. 
There is a preview release of WoutWare for .NET Core (which works on Linux, and 
presumably on OSX too). 
.NET Core can be self-containedly deployed (Windows, Linux, Mac) , so there are 
no dependencies on a certain version of the .NET-Framwork. 

Those are the two only (working) options when you deal with DWG. 



-Ursprüngliche Nachricht-
Von: QGIS-Developer [mailto:qgis-developer-boun...@lists.osgeo.org] Im Auftrag 
von Jürgen E. Fischer
Gesendet: Mittwoch, 26. September 2018 14:23
An: qgis-developer@lists.osgeo.org
Betreff: Re: [QGIS-Developer] Exporting from QGIS to CAD format - is it 
possible to offer DWG export

Hi Rob,

On Tue, 25. Sep 2018 at 13:49:50 -0400, rjwill...@gmail.com wrote:
> Is there a proprietary licensing reason that QGIS cannot export 
> directly to *.dwg file format rather than only to the dxf format?

We could probably also use libdxfrw, that we use for our import, to write DWG.

But contentwise DXF and DWG are alike - and there's more software that can read 
DXF than DWG.  
Is using DXF not an option?  
Do you require a certain version of DWG (the format changed quite a bit, 
although the content actually didn't that much).



Jürgen

-- 
Jürgen E. Fischer   norBIT GmbH Tel. +49-4931-918175-31
Dipl.-Inf. (FH) Rheinstraße 13  Fax. +49-4931-918175-50
Software Engineer   D-26506 Norden http://www.norbit.de
QGIS release manager (PSC)  GermanyIRC: jef on FreeNode
___
QGIS-Developer mailing list
QGIS-Developer@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [QGIS-Developer] Sign in options for readmine

[Stefan Steiger]

Redmine also has a REST-API (JSON & XML).  
Since github also has an API (and also hooks), you could also synchronize 
GitHub/GitLab issues with Redmine and vice-versa. 
All you'd need to do is add custom-field on the redmine issues, so you could 
determine which issues are already synchronized. 
Potentially add a custom-datetime-field "last_synchronized", if 
synchronization/updates should work both ways.
Then you can add a service/daemon to hourly run over all redmine issues and 
synchronize them to github. 
And then pull all github issues and feed them into redmine. 
If you could store the redmine-issue-id into a github issue, that should be 
fairly simple. 
Via hooks you might also be capable of live-synchronizing github issues as they 
are created. 

That way you could receive issues via github, and still only have to look at 
redmine. 
I've worked with redmine in the past, and redmine has web-service support for 
custom-fields. 

The only question would be if the github-api provides custom fields ? 



-Ursprüngliche Nachricht-
Von: QGIS-Developer [mailto:qgis-developer-boun...@lists.osgeo.org] Im Auftrag 
von Jürgen E. Fischer
Gesendet: Montag, 19. Februar 2018 10:51
An: qgis-developer@lists.osgeo.org; qgis-psc 
Betreff: Re: [QGIS-Developer] Sign in options for readmine

Hi Nathan,

On Mon, 19. Feb 2018 at 10:46:34 +1000, Nathan Woodrow wrote:
> If we don't move off Redmine in the near future (although I do a see a 
> GitLab/Github move inevitable) what sign in options do we have that we 
> can implement for our sites?  If we can't move off Redmine it would be 
> nice if we could make the sign in process for issues.qgis.org and 
> plugins.qgis.org a more pleasant one.
 
> Is it possible to wire in Gtihub, Facebook, Google, and all those 
> kinds of providers into the site? If so what kind of work is required 
> for that to happen.

Should be.  There are plugins for redmine to do this (github at least; also
oauth) - but we didn't have enough time in Essen to get them to fly after the 
migration and people wanted to start working on tickets - and this wasn't 
revisited AFAIK after we put the new instance into production.

BTW osgeoids are not required for redmine - you can register directly, but for 
uploading plugins you need one (and if you don't already have one the mantra; 
which you get quickly if you use a mail address that suggest that it's real and 
that you will not spam - for gmail.com, hotmail etc. we first try to establish 
that the person is real - so that might take longer).  Recently we had two 
redmine tickets issued by (a) spammer(s).

While I agree that the mantra could be a large enough obstacle to turn people 
away from filing tickets (hence it's not used there), I don't think the same 
applies for plugins.


Jürgen

-- 
Jürgen E. Fischer   norBIT GmbH Tel. +49-4931-918175-31
Dipl.-Inf. (FH) Rheinstraße 13  Fax. +49-4931-918175-50
Software Engineer   D-26506 Norden http://www.norbit.de
___
QGIS-Developer mailing list
QGIS-Developer@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [QGIS-Developer] Ubuntu Package Releases and GDAL Dependencies

[Stefan Steiger]

Stable isn't necessarely more "unstable" than unstable - since "stable" is 
almost never really well tested.
Maybe that depends on your definition of "really well", but anyway, just saying.
Also, stable doesn't mean bug-free, it just mean stable, that ist o say, 
staying as is. 

If you have issues with default-packages/dependecies, why don't you just 
containerize it and create a snapcraft-package ? 
Maybe someone also wants to have 2 different applications that both use the 
GDAL of a (different) specific version each on the same system ...
That could never be stable since one oft he two would probably not work. 

Snappycraft also has the advantage that you need to create only ONE package for 
all the major distros, such as Ubuntu, Debian, Fedora/CentOS, Arch, 
Suse, ScientificLinux, Gentoo, etc.

Then you can test that one package, and then you know it works or doesn't, and 
dependencies only get updated when your snapcraft package gets updated.
This would be my definition of "stable". 

Also, snapcraft would make it possible to distribute commercial packages, e.g. 
with google-maps material, through snapcraft-store
https://docs.snapcraft.io/reference/snap-command  
snap buy 


https://snapcraft.io 
https://askubuntu.com/questions/743068/how-to-install-snapcraft-on-14-04  
https://developer.ubuntu.com/core  
https://arstechnica.com/information-technology/2016/06/goodbye-apt-and-yum-ubuntus-snap-apps-are-coming-to-distros-everywhere/
 

You can also get snapcraft on 14.04:
sudo apt install snapcraft snapd

to install package:
sudo snap install 

to update package:
sudo snap refresh 

to remove package: 
sudo snap remove 

search for package:
snap find 

list installed packages:
sudo snap list

e.g. 
sudo snap install nmap 
sudo snap refresh nmap









-Ursprüngliche Nachricht-
Von: QGIS-Developer [mailto:qgis-developer-boun...@lists.osgeo.org] Im Auftrag 
von Sebastiaan Couwenberg
Gesendet: Dienstag, 9. Januar 2018 07:37
An: qgis-developer@lists.osgeo.org
Betreff: Re: [QGIS-Developer] Ubuntu Package Releases and GDAL Dependancies

On 01/09/2018 06:28 AM, Jeremy Palmer wrote:
> I've been taking a close look at a way to install QGIS with >= GDAL 2 
> on 64bit Ubuntu 14.04 and 16.04 for production desktops.
> 
> It's not possible to install QGIS using the https://qgis.org/debian 
> package archive as the ubuntu  14.04 archives only supports GDAL 
> 1.10.1 and 16.04 only supports GDAL 1.11.3.
> 
> With https://qgis.org/ubuntugis it is possible to install QGIS with >= 
> GDAL
> 2.2 as this archive requires ubuntugis-unstable which currently 
> supports GDAL 2.2.2.
> 
> The issue I have is I'm reluctant to use ubuntugis-unstable for 
> production use. I would rather use ubuntugis-stable. However this 
> archive only supports GDAL 2.1 and doesn't provide the minimum 
> dependency of GDAL 2.2.2 for https://qgis.org/ubuntugis requires.
> 
> I was wondering why ubuntugis stable isn't used as the debian archive 
> for https://qgis.org/ubuntugis and ubuntugis-unstable is only used for 
> the development (e.g 2.99) nightly builds? This makes more sense to me.

You should have a look at UbuntuGIS development to see that it is mostly the 
work of one person now. Packages are updated for OSGeo-Live and copied to 
ubuntugis-unstable, after a while (no policy or guidelines) the packages from 
ubuntugis-unstable get copied to ubuntugis-stable.
This generally happens during an Ubuntu releases lifecycle, not ideal for 
production systems.

For production systems one should not rely on 3rd party repositories, other 
than the one the company maintains itself where it does all the integration 
work.

> I've also noted that the 2.18 binaries produced for the 14.04 and 
> 16.04 packaging has inconsistent dependency requirements. e.g 2.18.15 
> 14.04 64bit :
> 
> qgis - gdal-abi-2-2-2, libgdal20 (>= 1.8.0) qgis-providers = libgdal20 
> (>= 2.2.0) qgis-server - libgdal20 (>= 1.8.0) libqgis-dev - 
> libgdal-dev (>= 1.10.1-0~) libqgis-core - libgdal20 (>= 2.2.0)
> libqgis-app2 libgdal20 (>= 2.0.1)

The version requirement for libgdal20 are determined based on which symbols the 
code in the dependent package uses, qgis & qgis-servers don't use any symbols 
introduced after GDAL 1.8.0, libqgis-dev does but no symbols introduced after 
GDAL 1.10.1, etc.

Kind Regards,

Bas
___
QGIS-Developer mailing list
QGIS-Developer@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
___
QGIS-Developer mailing list
QGIS-Developer@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [QGIS-Developer] php-cgi not found after installing QGIS Server on Windows

[Stefan Steiger]

Hi Martin,

No, this means that PHP uses the 32-bit PDO-PostgreSQL-driver.
The driver accesses PostgreSQL via TCP-IP/pipes/Unix-domain-sockets, thus you 
can have whatever bitness-server you want.
Your PG server could just as well run on an ARM or a PPC or a 
MIPS-Godson/Loongson processor.
You might potentially run into problems if the PG server is > 9.6 - but since 
9.6 is the most current main release, that's unlikely to happen.
For 9.6.X, this should be OK.

But if you have an x64-server, this means you should update your PHP-version to 
64-bit,
because 32-bit software is usually compiled for 80-386 instead of 80-686, which 
means it is very slow, and could easily be much faster, if only you actually 
used x64...
Unless of course you use Arch Linux - they just compile 32-Bit for 80-686.  But 
since your screenshot says win32...

Also, if you use Windows, do yourselfs a favour and don't use Apache.
Use IIS, and if you use Linux, use nginx.
https://trends.google.com/trends/explore?date=all=apache,nginx
Apache is s**t, and gonna die for good.

If you need to install the latest PHP version (PHP7) on Windows, refer to my 
answer here:
https://stackoverflow.com/a/16427988/155077

If you have an IIS-version > 9, you need to switch
HKLM/System/CCS/Services/W3SVC/Parameters/MajorVersion
to 9 before installing PHP-Manager,  and after-installation, switch the value 
back.


Kind regards

Stefan


Von: QGIS-Developer [mailto:qgis-developer-boun...@lists.osgeo.org] Im Auftrag 
von Aitor Gil Martin
Gesendet: Dienstag, 28. November 2017 13:33
An: René-Luc Dhont ; qgis-developer@lists.osgeo.org
Betreff: Re: [QGIS-Developer] php-cgi not found after installing QGIS Server on 
Windows

Hi René-Luc,

I have been following your excellent guide without issues. It's hard to find on 
internet such a detailed guide on the geeky task of installing Qgis server + 
lizmap.

I installed Apache and PHP  (x64 both) succesfully so far.

I wanted to install PostgreSQL + Postgis. My doubt arrives when I see in the 
php properties:

[cid:image001.png@01D36867.BBB1FAC0]


The libpq library says PostgreSQL 9.6.2(win32).

Does this mean that I need to install a x32 PostgreSQL versión and not x64?

Can I install PostgreSQL 10 version?

Can I install PostgresQL 9.6.6 (newer than 9.6.2)?

The installation before 9.6.2 I have found is postgresql (x32) 9.5.10: 
https://www.enterprisedb.com/download-postgresql-binaries . Is this the one it 
is recommended to install?

Thank you very much for you incredible work with lizmap and your help to the 
community.

Regards,

Aitor

De: QGIS-Developer [mailto:qgis-developer-boun...@lists.osgeo.org] En nombre de 
René-Luc Dhont
Enviado el: lunes, 27 de noviembre de 2017 14:14
Para: qgis-developer@lists.osgeo.org
Asunto: Re: [QGIS-Developer] php-cgi not found after installing QGIS Server on 
Windows


Hi Aitor,

Did you use this documentation ?

https://docs.3liz.com/en/install/windows.html#qgis-server-installation

Regards,

René-Luc

Le 27/11/2017 à 13:30, Aitor Gil Martin a écrit :
I installed QGIS Server 2.18, apache, QGIS Desktop 2.18 and all their 
dependencies using OSGeo4w x32 setup wizard on a Windows Server 2008 R2 SP1 x64 
virtual server.
After the installation I type localhost on my chrome browser to see the 
Apache's landing page and I am getting the following error:
Not Found
The requested URL /cgi-bin/php-cgi.exe/index.phtml was not found on this server.
I uninstalled and installed everything several times using OSGeo4w but I keep 
getting the same message. Something is not properly installed or missing.
Can anyone give me a clue on what might be happening?





___

QGIS-Developer mailing list

QGIS-Developer@lists.osgeo.org

List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer

Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer

___
QGIS-Developer mailing list
QGIS-Developer@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [QGIS-Developer] QGIS-Server on Windows with IIS - missing methods in dlls

[Stefan Steiger]

Why not cygwin ? Because it doesn't produce Windows native executables ...

https://stackoverflow.com/questions/27678988/run-cygwin-built-exe-in-windows-without-cygwins-environment

Use MinGW + msys instead.

Strange that this still needs to be said in 2017.

This explains why qgis-server didn't run on my machine...





-Ursprüngliche Nachricht-

Von: QGIS-Developer [mailto:qgis-developer-boun...@lists.osgeo.org] Im Auftrag 
von Jürgen E. Fischer

Gesendet: Mittwoch, 15. November 2017 10:02

An: qgis-developer@lists.osgeo.org

Betreff: Re: [QGIS-Developer] Merging raster-save dialog change and Windows 
workflow



Hi,



On Wed, 15. Nov 2017 at 01:02:48 +, Tisham Dhar wrote:

> 1)  Checkout as standard on windows with git-bash (line endings are an

> issue). Will have to try a fresh clone in WLS to see what difference

> it makes



Why not cygwin?  That's what I use and recommend.   WLS means WSL?





Jürgen



--

Jürgen E. Fischer   norBIT GmbH Tel. +49-4931-918175-31

Dipl.-Inf. (FH) Rheinstraße 13  Fax. +49-4931-918175-50

Software Engineer   D-26506 Norden http://www.norbit.de

___
QGIS-Developer mailing list
QGIS-Developer@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer

[QGIS-Developer] QGIS-Server on Windows with IIS - missing methods in dlls

[Stefan Steiger]

Hi,

I've got a question regarding QGIS 2.18.10
I need QGIS to display maps on a website.

I tried on Ubuntu, and got the fastcgi to work more or less, in the little time 
that I had - thus far missing the PHP front-end.
Now, our admin doesn't want a Linux-machine around, and I can't convince him 
otherwise.
So I need to get QGIS to work on Windows, completely, including with IIS and 
not Apache.


I tried the OSGeo4W installer, both 32&64 Bit, on my Windows-10 machine.
http://download.osgeo.org/osgeo4w/osgeo4w-setup-x86.exe
http://download.osgeo.org/osgeo4w/osgeo4w-setup-x86_64.exe

Running the installer, I got the following errors:

The procedure entry point jpeg_abort could not be located in the dynamic link 
library C:\OSGEO4~1\bin\gdal202.dll
The procedure entry point xmlSchemaNewDocParserCtxt could not be located in the 
dynamic link library C:\OSGEO4~1\bin\spatialite.dll
Package qgis-common exit code -1073741511
package qgis-ltr-common exit code -1073741515

In other words, I didn't even get to the point to where I could worry about 
integrating QGIS into IIS, because qgis-server doesn't work in the first-place.

Now the question:
Does qgis-server at present run under Windows (10) at all ?  (QGIS-Desktop 
works fine - but this is of no use to me).
If yes, I saw different options as mapserver.
What is actually the recommended way to run QGIS maps on the web on Windows ?
Because no matter what I tried to install on this so-called osgeo4w-installer, 
it ended in fatal error messages, always indicating that some methods in some 
dlls are missing...
Did the one uploading the installer actually ever run the Windows-binaries 
before putting them up there ?


Kind regards

Stefan


[cid:image001.png@01D33941.D30ABC70]

[cid:image002.png@01D33941.D30ABC70]

[cid:image003.png@01D33941.D30ABC70]

[cid:image004.png@01D33941.D30ABC70]



[cid:image005.png@01D33941.D30ABC70]

___
QGIS-Developer mailing list
QGIS-Developer@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer