Re: [QGIS-Developer] C Hamilton Plugin Continunity

[Greg Troxel via QGIS-Developer]

Emma Hain via QGIS-Developer  writes:

> This is very interesting and a real part of OS software management in
> regards to maintainance once the creator wishes to retire (and rightly
> so!). On top of that, if the ownership sits with an organisation. For
> clarification, does NGA or do you, Calvin, own them?
>
> I imagine if it is from one person to another, this is an informal
> handover, but what happens when it is an organisation? Does an Assignment
> of Ownership need to take place?

This is a little complicated.  I have no knowledge of the details of
this situation but have dealt with open source licensing in the context
of US government contractors and US law.  Generally:

  When a person writes code, they hold copyright to it, except:

If they have executed a copyright assignment, they don't.  This is
typically either for contractors (either when the parties pretend it
isn't employment or when it really isn't) or for individuals who
assign to e.g. FSF.  Less happily, it can be some forms of CLA to
some company.

When an employed person writes code "within the scope of
employment", then the employer holds copyright.  This is the "work
for hire" doctrine.

Works of the US government are not subject to copyright and are in
the public domain.  (Different countries are different here,
massively.)

  Code under an open source license does not need assignment for others
  to improve and distribute it, because the license grants those
  permissions.

  A plugin is arguably a derived work of qgis, and thus must be
  distributed under a compatible license.  (I think the project should
  express this as doctrine and decline to support or interact with
  (shun) plugins that don't have compatible licenses.)  So even if the
  US government does not hold copyright in their code, the resulting
  code is a derived work of qgis and can only be distributed under the
  GPL.

  Contributions to the plugin from others (e.g. if someone submitted a
  non-trivial change and it was merged) are copyrighted by them and thus
  a declared license leads to inbound=outbound terms, making it clear
  that the submitted change is licensed under the plugin's license.

  There are social issues about forks, separately from copyright, but
  Calvin's message is quite clear that someone who wants to maintain
  them (and have the updated/maintained code exist in the qgis world
  under the original names) would be good.

___
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] Is it allowed to sell data in a QGIS plugin?

[Greg Troxel via QGIS-Developer]

Info OpenGIS  writes:

> I agree that the descriptions must highlight that the plugin is used to 
> purchase geodata and I would be happy if there
> was some sort of "in app purchases" label but let's not make the plugin 
> repository become a new playstore or applestore. 
> At least I would manage the issue of user privacy externally.  I'm thinking 
> about the fact that if you want to sell
> something you have to view the web page of your shop with qtwebengine and 
> then manage user data through your site, then
> with the API you manage the data download via plugin.  It would also be ideal 
> for users to run a single online shop. 
> What do you think?  I'm looking for a way to not get qgis in trouble if 
> problems arise with user data.  By outsourcing to
> a site the problem would be the site's.

I don't really follow "not a new playstore or applestore".  The problem
with those places is that they are often the sole means, and enforce a
commission.  What we're talking about is totally different, following
f-droid's lead, which is just formalizing longstanding norms that Free
Software is expected to act in the user's interest, not the interest of
the people that distribute it.

The real issue here is that people are at least being seen as maybe
getting close to the line.  I'm suggesting being explicit to stay ahead
of that.
___
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] Is it allowed to sell data in a QGIS plugin?

[Greg Troxel via QGIS-Developer]

Sandro Santilli via QGIS-Developer 
writes:

> On Tue, Jun 11, 2024 at 09:56:15AM +0200, Alessandro Pasotti via 
> QGIS-Developer wrote:
>> On Tue, Jun 11, 2024 at 9:44 AM Christopher Frank via QGIS-Developer <
>> qgis-developer@lists.osgeo.org> wrote:
>> 
>> > We would like to implement in the plugin the whole order process, open
>> > source of course. The user will feel like shoping the data in a geoshop. To
>> > provide the necessary information we communicate with an api of a real
>> > geoshop. Before we start to implement this idea, we would like to be sure
>> > that this is allowed.
>> 
>> As long as the plugin license is compatible with QGIS license, the source
>> code is available and you don't package any binaries with the plugin.
>> I don't see any issue with that.
>
> Would it be possible to add some metadata for plugins doing so,
> like "in-app purchases" ?

Agreed.  This is not a license violation, but I do see it as a
significant anti-feature.  I would also see a plugin that only works if
you have a subscription as having an anti-feature.

I do think we should require descriptions for plugins that access
paywalled data (in-app purchase or not) to say that loudly, at least as
loudly as touting the benefits, so that nobody is mislead.  I don't mean
to discourage people that want to do this, more "This plugin exists to
support access paid data from X, making it easier for those with
subscriptions to get that data.  It further enables plugin users to buy
a subscription from within the plugin." rather than "This plugin lets
you access [description of wonderful data]."

Also from the F-Droid world is the antifeature of tracking.  I think we
should also be careful to not allow that, and I'd be inclined to just
not allow it, vs labeling it.  Obviously when a user asks to do
something that would make a reasonable person expect data to be sent
over the net, that's ok.  But it's a slippery slope, and I think it's
reasonable to have an expectation of data minimization.  One such
minimization might be not sending exact canvas coordinates, but no finer
granularity than 0.1 degree lat/lon, at least until it's clear what it's
doing.  For the actual fetching, I realize that is an issue with all
configured sources, so here I really mean for the signup part.

And, the plugin should not communicate off-host until the user asks it
do do so.  Phoning home isn't ok either.  (Again, not accusing this
not-written-yet plugin of doing that -- thinking in general.)

Separately from the ethical concerns, there's a security question that
comes up from in-plugin purchases which is handling of personal
information and presumably credit card/bank details.  I'm not saying
qgis is insecure -- but it has not really been thought of as handling
that kind of data (just sensitive geodata) before, and adding it brings
us in to new territory.
___
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] High load on plugins.qgis.org

[Greg Troxel via QGIS-Developer]

  [high plugin load]

Three suggestions:

  is this a distributed problem, or a few abusive addresses?  In
  openstreetmap I think they would just firewall the addresses in
  questio.

  please don't use google recapcha or anything else without stellar
  privacy policies

  consider rate-limiting IP addresses instead, 1s delay for a few, then
  30s or something like that.
___
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] Post-mortem of application to Google Summer of Code

[Greg Troxel via QGIS-Developer]

Emma Hain  writes:

> Hi Greg
> Thanks for replying - that is a very interesting read - and somewhat
> disheartening. So my response is, is this something we get involved with or
> not?
> My thoughts on getting involved in this was additional funding to build up
> and mentor up and coming QGIS developers. Is there are way to triage this
> process so it does benefit us?
>
> Thanks
> Em

My take is that people sort into

  A) generally able and willing to spend some time helping new people
  trying to contribute, but who may be a little confused, for the good
  of the project

1) GSoC is fine and they are happy to volunteer to GSoC-mentor
(written that way to separate from helping people separately from an
explicit GSoC agreement).

2) they don't want to volunteer for Google and they just step back

  B) they aren't able/willing to spend time helping out new people

and that A1 people do GSoC-mentoring and the rest don't.  That's fine,
and I don't think the project needs to do anything in particular.

I don't think it's a good idea to try to move people from B to A1 by
paying GSoC-mentors.  I think it causes too many issues that have downsides
in terms of the overall social contract.

I don't think it's feasible to move people from A2 to A1 by paying
enough, as the org stipend for GSoC isn't going to pay GSoC-mentors
$500/hr, and arguably it shouldn't.  If one is paid and others aren't,
that's going to cause trouble.  And if mentors get paid more than people
doing paid development, that's also trouble.  And then there's people
helping out random contributors.

Certainly it is normal for open source projects to participate in GSoC,
and I don't mean to suggest that QGIS not do that.  Clearly in many
organizations there are a significant number of people willing to
GSoC-mentor.

Overall, I would only suggest the the project be sensitive to the fact
that A2 people exist (and not treat them like they are crazy or
unreasonable, which so far has been entirely a non-problem).  This is
mostly a tone thing, perhaps a bit of "If you're comfortable
volunteering as a mentor".  I wrote because it appeared that people
didn't realize this.

Greg
___
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] Post-mortem of application to Google Summer of Code

[Greg Troxel via QGIS-Developer]

Emma Hain via QGIS-Developer  writes:

> Mentors to be put forward - I see this information
> :
> *Mentors are people from the community who volunteer to work with a GSoC
> contributor. Mentors provide guidance such as pointers to useful
> documentation, code reviews, etc. In addition to providing GSoC
> contributors with feedback and pointers, a mentor acts as an ambassador to
> help GSoC contributors integrate into their project’s community. Some
> organizations choose to assign more than one mentor to each of their GSoC
> contributors. Many members of the community provide guidance to their
> project’s GSoC contributors without mentoring in an “official” capacity,
> much as they would answer anyone’s questions on the project’s mailing list
> or chat channel. *

(I'm here as a packager and not currently deeply enough involved in qgis
to function as a mentor, but my opinion is based on other communities
where I feel qualified to be a mentor.)

A contrarian view: I view GSoC as a google recruiting activity; it's
like having interns, except you care even less if they do anything
useful or cause trouble.  For those who haven't been a manager at a
company and dealt with labor law: interns are awesome because after 10
weeks or whatever they terminate on schedule.  That means if they are
unsuitable you can just take them to lunch and say it's been great and
not rehire them, and this is vastly less costly and painful than firing
someone.  If they are suitable you can invite them back for next summer
or for a permanent position, and you've taken a bunch of risk off the
table.  I'm not saying I know that this is google's plan; it's just
obviously what a company would do.  It's entirely reasonable of them to
do this.

However: I don't want to be staff for a company's recruiting activity,
basically at all, but if so only at a proper consulting rate with
acceptable terms -- which is obviously out of the question.  So I simply
step back and ignore GSoC.

I do try to be helpful to people, regardless, as long as they have met
their half of the social contract around asking for help.  I have found
GSoC and non-GSoC people to be on both sides of that, and am not
claiming there is a correlation.  I do see people showing up in another
project's list saying "I'm interesting in this project [listed as GSoC
fodder but needing doing anyway, that they obviously know nothing about
and know almost nothing about the project] - can you tell me how to
proceed?".  I think many people ignore them, and some tell them to first
install the project, learn how it works and start reading the code.
That's usually the end of that!  Others come from a place of more clue
and more importantly more effort, and that goes much better.

> I also see there is a fair amount time required by the mentor and that a
> stipend is provided to the project at the end of the GSoC. Would this
> stipend be then passed onto the Mentor to assist with the time applied?

That's an interesting question.  I would guess the project is set up to
provide payments and deal with the required tax reporting in the first
place.  There is also the question what's in the GSoC org agreement and
if that's ok.  I would not assume it is ok; it seems structured to hand
money to projects not mentors, perhaps as part of claiming the entire
program expense as charity.  Speculation of course -- the point is that
these are surely agreements written by their lawyers, and it's best not
to make assumptions.

> Contributors - I see this is for individuals - is this something we can
> broadcast on our channels and within our user groups?

Mildly, I see asking more than a small number of times as crossing over
into advertising for google's recruiting activity and thus into spammy.

I don't know if I'm an extreme outlier or part of the silent 50% in my
opinions.  I am pretty sure I'm an outlier in being willing to outright
say them!

I'm writing this partly because when project leaders ask "why aren't
more people volunteering to be mentors" it may not have occured to them
that some (fraction unclear) just outright wouldn't because of the
structural issue, before you get to the other considerations.

Greg
___
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] Build problems using install instructions

[Greg Troxel via QGIS-Developer]

Tony Bazeley via QGIS-Developer  writes:

> Not having much luck I'm afraid
>
> I've done a completely new reinstall and followed the instructions down to 
> git fetch /qgis/master

Can you point to the instructions?  This all seems very strange.
I would just expect to clone the repo and checkout the branch you want.

(I also don't follow what you are rebasing if you are just trying to
build from git.)

you left out os/version/etc. and didn't show the clone command.



Also, are you already quite familiar with git, and have you successfully
cloned, made changes on a branch, pushed it, with sometthing else?
___
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] Maintainance of QGIS Plugin repository

[Greg Troxel via QGIS-Developer]

Admire Nyakudya via QGIS-Developer 
writes:

> Over the years there has been a steady increase in plugins that are
> not approved . This is
> due to a number of reasons:

> * Duplication of functionality. Plugin functionality already exists in QGIS.
>
I think it's good to reject plugins.  To the extent that there are fewer
while still being able to do things, it makes the user's job easier.
That's an argument about rules like duplication.

> * Plugin authors not willing to address issues raised during the
>   approval process.

I think the review committee should have high standards about
cooperation and it's ok to just close requests.

> * Plugins containing binaries (Not really sure about the policy here).

I haven't read it, but I think the rule should be  that plugsin
  - have a license which is compatible with qgis's license (they are
derived works after all)
  - have a public repository and bug tracker

I also think that because qgis is broadly portable, a plugin needs to
have a story about how it's going to work on any computer which can run
qgi and run plugins.  that pretty quickly lands you at "no binaries",
but does admit "needs to build foo library".  For context, I use qgis on
NetBSD, and the modern world is dreadful at both "have this binary wheel
- it runs on 3 operating systems, 2 cpus each" and "to use this run
docker because our build system and instructions are such a mess that we
don't think you can build it".

Obviously (to me) proprietary binaries are totally out of the question.

> * Plugins which are a fork of an existing plugin and then they get
>   renamed to something else without permission from the original
>   author or the author is no longer interested i.e
>   https://plugins.qgis.org/plugins/active_fire2/.

Not clear why this is a hard no.  Could be failed as noise, could be
failed as failing to comply with community norms.  But if the original
is no longer maintained, and its a continuation fork, then it seems best
to unpublish the original and publish the fork.

> * Old plugins that still use the old architecture i.e Python2.

sure, that's a technical fail.

> Could we either implement the following changes to maintain/cleanup
> the plugin repository.
>
> * Old plugins that were never approved because the author did not care
>   to resolve issues flagged be deleted from the repository i.e
>   https://plugins.qgis.org/plugins/ban_adresse_locator/
>
> * Plugins that have vague names and offer functionality that is
>   ambiguious i.e https://plugins.qgis.org/plugins/upload/ be deleted.
>
> * We could automate the deletion of plugins where feedback has been
>   received but the author hasn't done any corrective measure maybe
>   after a month or couple of months.
>
> * Automatically flag the plugins which are not approved to Deprecated
>   after some time.
>
> I think the above and other recommendations will encourage people to
> use the plugin repository properly as currently it feels like a
> dumping ground.

I'm unclear on how the repository works, but it seems like it should be
a curated list of things that are ok and that involves kicking things out.

> On a side note: What is the policy for plugin names. I know it is up
> to the author to give his plugin a suitable name but something like
> https://plugins.qgis.org/plugins/transfer_layerfilegdb_to_geopackage/#plugin-versions
> looks like a description rather than a name.

agreed.


All in all, I think the repository approval team should be empowered to
be heavy handed, with appeal to PSC.

___
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] PKI Certs with QGIS

[Greg Troxel via QGIS-Developer]

Joshua Tomlin via QGIS-Developer 
writes:

> Dear QGIS Support Team,

This is not a support list.  It's for discussion among developers.

> I'm currently working on a script that will allow the CAC reader to
> pull PKI Certs off the CAC card. I'm currently working with the CAC support
> team and they have a few questions that I'm not familiar with that you may
> know:
>
> Does the opensource application support PKI?
>
> How does the opensource application process FIPS 140 cryptography?

I've worked with CAC/PIV before, and your situation doesn't really make
sense to me, even though I can see how you might have ended up where you
did, and I could guess what's really going on -- but won't.

> I believe QGIS does support PKI based on the authentication block I've
> attached to this email but would you happen to know the answers to the
> other question?

It looks like you attached a picture, which my mail reader didn't
display.  That's ok; I don't like to look at screenshots vs. text.

More or less, qgis can fetch GIS resources over https, and thus follows
pkix in much the same way other programs do.  I realize that's probably
not that helpful.

My impression is that you probably need a consultant.  You didn't
mention the purpose of your work.  As you know, ITAR is a real concern,
and it would be good to be clear that it is not related to a defense
service.  If you do need help with a defense service, you'll of course
need to find a US-based consultant.

___
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-user] Announce - migrate our mailing lists to Discourse

[Greg Troxel via QGIS-Developer]

What I meant mostly is two things:

People like me tend not to be happy about things turning into forums
  and are likely to participate less.  As an example, openstreetmap
  moved from mailinglists to forums and I have not, so I interract far
  far less and spend more time on other things.  I am probably somewhat
  unusual (started doing email in the 70s), and here probably only strk
  thinks I"m normal :-)

My perception, perhaps off base, is that discourse facilitates
  people showing up, posting a question, and getting replies to the
  question, without also getting delivered to them everything else on
  the "mailing list".  Thus I expect a lot more help desk type
  interactions, where new people ask a question and don't really engage,
  rather than joining the community.
Many projects have communities of long-term participants who get to
  know each other.  Partly from on-list, but partly from off-list
  converstations which are enabled by getting emails with the other
  person's email address.  I don't see this happening in a discourse
  world.  I'm not arguing there are no mechanisms and that people could
  not make it happen.  I am saying that I expect it to happen much less
  in practice.

I don't have any good ideas about the first pointl.

The second point could be addressed by allowing web signup, but allowing
posting only if one has email delivery of all messages, and having the
From: address be the person, and not breaking DKIM signatures.   In
short, having the email interface be a first-class non-broken
mailinglist, while also having a forum view.

(I've dropped psc because it doesn't allow non-members to send.)
___
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-user] Announce - migrate our mailing lists to Discourse

[Greg Troxel via QGIS-Developer]

Régis Haubourg via QGIS-User  writes:

> With this move, we hope that we can counter the current fragmentation
> and streamline our discussions. Please fell free to react.

I'm unhappy about this, as I suspect are others who have been in the
Free Software world a long time.  I expect that this will lead to
reduced engagement by the longer-term-FS people.  Part of this is that
tools that encourage post-and-only-see-answers lead to a help desk
feeling that than a community.

I don't expect to be listened to in any serious way, but you said "feel
free to react" :-)
___
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 Full Stack Web Developer Report

[Greg Troxel via QGIS-Developer]

"Johannes Kröger (WhereGroup) via QGIS-Developer"
 writes:

> https://github.com/qgis/QGIS-Django/pull/356;>Use Gmail
> as the email provider
>
> Does this mean that Gmail will be involved in all those mails? I
> would be strongly against proactively exposing any data to such a
> company if not absolutely necessary.
>
> Can't a OSGeo mail account be used instead?
>
> It's bad enough that so much mail is already centralized and thus
> available to a single party/company but as long as a user is not
> willingly using Gmail themselves already, it would be great if
> Google (or any other similar third party) was not involved in such
> mails.

me too

I don't really understand what is going on, but I think the less
anything uses google anything, the better.
___
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] cmake PYQT_SIP_DIR (via Python_SITEARCH) value wrong on Debian and derivatives

[Greg Troxel via QGIS-Developer]

Richard Duivenvoorde via QGIS-Developer 
writes:

> On 2/9/24 14:24, Greg Troxel via QGIS-Developer wrote:
>> How will this affect builds on other systems?   It seems there is
>> something deeper wrong, and the real problem might be that there are
>> multiple legitimate ways to install things, and that the Find script is
>> deficient.
>> How is it looking?   It would seem that finding the python directory
>> should use some python config mechanism.
>
> There are links to deeper info in my issue comment, so see:
>
> https://gitlab.kitware.com/cmake/cmake/-/issues/25113
>
> which makes it most clear.

Thanks, that helps tremendously but I am not yet fully understanding.

This helped me:

https://askubuntu.com/questions/1406304/virtualenv-installs-envs-into-local-bin-instead-of-bin

So:

  This is about Debian (and hence Ubuntu etc.) doing something unusual,
  vs every other system (Other Linux, Windows, Mac, *BSD, illumos.)

  Instead of using the default paths that python uses, they have
  configured python so that things have an extra local in the path, so
  that the prefix is $foo/local when the user asks for it to be $foo.

  This choice on Debian's part is a bug to be worked around.

  Setting DEB_PYTHON_INSTALL_LAYOUT='deb' will set the scheme to
  deb_system which is like posix_default.  This is likely ok if one is
  building a deb, but I am guessing not ok if one is building qgis with
  --prefix=/usr/foo.

  It seems like the right fix is for the cmake support that qgis is
  using to say "if scheme is posix_local, change it to posix_default",
  thus working around the Debian bug.

  However, surely Debian people don't think this is a bug.

  Other python software, build on this system, sees a different path?


It sounds like you are proposing to work around this by setting the env
var in the qgis CI environment, and perhaps to recommend to users, and
maybe even to flip it on for users, which is a workaround.

And in the glorious future, cmake will someone manage this by itself.

(I remain unclear on what happens if someone builds on Debian with
--prefix=/usr/foo, but me being unclear on that is ok.)
___
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 plugin depends on pypi package

[Greg Troxel via QGIS-Developer]

John Lindsay via QGIS-Developer  writes:

> I believe that I've solved my earlier issue with my QGIS plugin, which
> previously relied on a pip package. In order to avoid this dependency,
> I decided to include the Whitebox Workflows wheel in with my
> plugin. Unfortunately, however, this has increased the size of my
> plugin fairly substantially. The issue is that I need to included a
> wheel for each of the four supported operating systems and each are
> about 10MB. My plugin zip file is now a little less than 40MB. When I
> try to upload the new version to the QGIS plugin repo it is telling me
> that the file is too large. Does anyone know what the maximum size of
> a plugin zip file is? Thanks.

I was unaware that there was an explicit list of 4 operating systems
(and perhaps you mean 4 OS-version-CPU tuples, if this is a binary
wheel, even if those function on later os-version-cpu systems).

But even if one accepts a triculture (which I personally don't), then I
would expect you'd need wheels for

  linux-?-x86_64
  linux-?-earmv7
  linux-?-aarch64
  mac-?-x86_64
  mac-?-aarch64
  windows-10-x86_64

which is 6 not 4.  I'm unclear on Windows on ARM (because I choose to be
unclear on Windows :-).  Plus RISC-V is on the horizon.  So this rapidly
becomes unworkable.

(Certainly, I can see that qgis.org delivers binaries of qgis for a
limited set of systems, but qgis the source code obviously ought to be
buildable and runnable on any reasonable system that 99.9% meets POSIX,
plus perhaps a few extensions.)


What happens when you try to install the plugin on a system for which
you don't provide a binary wheel?

I have seen thing like Home Assistant just try "import and if that fails
call pip install" but that is a "this program has sufficient
portability/stability issues needing pinned dependencies that the only
viable path is to run inside a venv" situation.


It also strikes me that binary wheels inside plugins are a security and
licensing issue.  While I don't mean to suggest you are doing anything
improper, I expect plugins to be just python code.  From a licensing
point of view, the plugin has to be GPL and thus any included binary
wheels also have to be provided under the GPL.  If they were a
GPL-compatible permissive license, that then triggers obligatiions for
provide sources that weren't there before, and aren't presenet with "you
need to install X".  Do we have existing practice about this?

___
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] cmake PYQT_SIP_DIR (via Python_SITEARCH) value wrong on Debian and derivatives

[Greg Troxel via QGIS-Developer]

Richard Duivenvoorde via QGIS-Developer 
writes:

> Hi Devs,
>
> I kept getting the https://github.com/qgis/QGIS/issues/54184 issue: sip not 
> being able to find the Qt package sips: 'QtNetwork/QtNetworkmod.sip' could 
> not be found etc etc

I have not tried to build anything beyond 3.34.3 so far.

> You can fix this with (on Ubuntu or Debian), by using (before your cmake 
> step):
>
> export DEB_PYTHON_INSTALL_LAYOUT=deb
>
> Would it be possible/wise to add this to the standard QGIS build scripts?
>
> For more info/explanation, see 
> https://github.com/qgis/QGIS/issues/54184#issuecomment-1935855984

How will this affect builds on other systems?   It seems there is
something deeper wrong, and the real problem might be that there are
multiple legitimate ways to install things, and that the Find script is
deficient.

How is it looking?   It would seem that finding the python directory
should use some python config mechanism.

On my system this file (3.28) is in

/usr/pkg/lib/python3.11/site-packages/PyQt5/bindings/QtNetwork/QtNetworkmod.sip

which seems like it follows the standard python approach (where choosing
a prefix other than /usr is within standard).

What are the variant places it is ending up in?

Shouldn't the Find script just look in both, if there are two normal
approaches?
___
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] Theoretical discussion: A QGIS paid plugin marketplace?

[Greg Troxel via QGIS-Developer]

Nyall Dawson via QGIS-Developer  writes:

> I wanted to kick start a (hopefully!) civil, THEORETICAL discussion about
> the role of a paid plugin marketplace for QGIS plugins.
>
> - Yes, I'm aware that plugins must be GPL, and that this makes paid plugins
> a little trickier in that they're obviously still subject to the GPL.
> - The GPL does NOT prevent charging for software, or mandate making it
> public to non-paying customers. We could potentially have GPL plugins which
> are only available to paid users, and only make these plugins available
> privately to those users. YES, the GPL **DOES** mean that those paying
> customers can redistribute the plugin publicly and freely without issue if
> they want (and regardless of whether the original developer wants!)

Are you envisioning that this paid marketplace would provide sources at
the same time it provides binaries?  I would think it would have to, in
order to be really compliant.

Would you envision any social pressure for recipients not to publish
plugin sources?  I would say that even a little pressure would be
totally inappropriate.  One way around it would be to require that any
plugin have published sources before acceptance.

While you rightly point out that QGIS being GPL imposes a requirement
for plugin licensing, there is also the point that plugins would not be
possible without the base and we need to view this entire discussion
within the larger context of the social context of free software.

> - There's nothing preventing a public GPL QGIS plugin from depending on a
> subscription based back-end, and offering zero value to anyone not paying
> for that backend. And there's a growing number of these plugins, which
> depend on users paying xxx large corporate entity regular high fees to
> access the backend service. The GPL doesn't (and arguably
> shouldn't) prevent these large entities from making money off QGIS plugins.
> - But this means that the current situation is unfairly weighted toward
> these large entities! A one-person team making an excellent plugin and
> providing an awesome tool for use in QGIS has a MUCH MUCH harder time
> finding ANY financial compensation for their efforts! I don't like this
> situation at all, and I'd say it goes against the "spirit" of why QGIS was
> made under the GPL in the first place. The big corporate entities win, the
> smaller community focused developers lose out. 

I sort of see your point, but not really.  Here, I am guessing that you
are mostly not talking about a situation where the value is the plugin
code and it is being unlocked by a fake subscription.  I suspect that
the real value is in the data available by the subscription and the
plugin is just plumbing to access it.  And that if someone else had
similar data, using the plugin as base code to access that other data
would be fine.

Or am I misunderstanding?  If so, the nuance is probably helpful to the
discussion.

> - Despite the fact that a paid user could freely re-distribute a paid-for
> plugin, there's still potential financial gain for the developer in making
> a plugin available for a charge on a theoretical QGIS plugin marketplace.
> - The blender market is a great example of this. There's LOTS of GPL
> blender add ons available there at charge. Eg
> https://blendermarket.com/products/hard-ops--boxcutter-ultimate-bundle?num=2=top
> as one example. If those numbers are accurate, that developer has sold >35k
> copies of a GPL licensed add on at $39 each. I'm going to go out on a limb
> here and guess that that developer's motivation to make their add-on
> excellent is considerably higher than the developer of an equivalent QGIS
> plugin 藍 (not to mention that their time investment is much more
> justifiable). And any ONE of those 35k paid users could have made the
> plugin freely available for everyone else... but that hasn't stopped the
> sales.

In this case, is the source code really not available to the public?
If not, with 35k bought copies, then it's hard to believe that there
really is compliance, just from a statistical priors viewpoint.

> So what does everyone else think? Would there be a THEORETICAL place for a
> THEORETICAL paid QGIS plugin marketplace somewhere in the future? Or is
> there a better model we could (theoretically 浪) follow to financially
> reward plugin developers?

How (and why) do you separate plugin developers from
  contributors to the core code
  contributors to docs
  packagers
  a bunch of other categories

?
___
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] bare isnan -- why isn't CI catching this?

[Greg Troxel via QGIS-Developer]

I am in the process of building 3.34.3 for pkgsrc.  (We've been on 3.28.x,
and I am just now getting to jumping to the new LTR.)

I am using gcc 7.5.0 on NetBSD 10 amd64.

I found a case of bare isnan in a source file.  It's easy for me to
patch to std::isnan.  I see that there are a large number of std::isnan
in the sources.  I am guessing that formally bare isnan is an error, but
have not passed the bar to be a practicing C++ Language Lawyer.   I see
an include of cmath, but not "use that scope as if here" decl.

My question is:

  Is it in fact invalid code to use bare isnan instead of std::isnan, vs
  would someone claim my compiler is wrong?

  Assuming bare isnan is wrong, why isn't qgis's CI catching this?  I
  would think the CI environment should have the equivalent of
  POSIXLY_CORRECT to try to reject as much as possible in terms of using
  extensions not required by standards.

[ 56%] Building CXX object 
src/core/CMakeFiles/qgis_core.dir/raster/qgsrasterattributetable.cpp.o
/tmp/work/wip/qgis/work/qgis-3.34.3/src/core/raster/qgsrasterattributetable.cpp:
 In member function 'QgsGradientColorRamp 
QgsRasterAttributeTable::colorRamp(QStringList&, int) const':
/tmp/work/wip/qgis/work/qgis-3.34.3/src/core/raster/qgsrasterattributetable.cpp:1362:16:
 error: 'isnan' was not declared in this scope; did you mean 'std::isnan'?
 1362 | if ( ! isnan( min ) && ! isnan( max ) )
  |^
  |std::isnan
In file included from /tmp/work/wip/qgis/work/qgis-3.34.3/src/core/qgis.h:25,
 from 
/tmp/work/wip/qgis/work/qgis-3.34.3/src/core/qgsfield.h:25,
 from 
/tmp/work/wip/qgis/work/qgis-3.34.3/src/core/qgsfields.h:22,
 from 
/tmp/work/wip/qgis/work/qgis-3.34.3/src/core/raster/qgsrasterattributetable.h:19,
 from 
/tmp/work/wip/qgis/work/qgis-3.34.3/src/core/raster/qgsrasterattributetable.cpp:17:
/usr/include/g++/cmath:632:5: note: 'std::isnan' declared here
  632 | isnan(_Tp __x)
  | ^
gmake[2]: *** [src/core/CMakeFiles/qgis_core.dir/build.make:10842: 
src/core/CMakeFiles/qgis_core.dir/raster/qgsrasterattributetable.cpp.o] Error 1
gmake[2]: Target 'src/core/CMakeFiles/qgis_core.dir/build' not remade because 
of errors.
gmake[1]: *** [CMakeFiles/Makefile2:4912: 
src/core/CMakeFiles/qgis_core.dir/all] Error 2
gmake[1]: Target 'all' not remade because of errors.
gmake: *** [Makefile:166: all] Error 2

___
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 plugin depends on pypi package

[Greg Troxel via QGIS-Developer]

John Lindsay  writes:

> I would be fine with asking users to manually install the dependency
> after installing the plugin however, the problem is that QGIS seems to
> use its own version of Python, rather than the system Python.

I think it would be good to really understand this, and for it to be
documented as part of "how to write plugins".  In pkgsrc, where I am the
maintainer for the qgis package, it is definitely built against the
system python.  However, pip is its own package, and qgis does not
depend on pip.

The real issue is that pip does not play well with the packaging system
world, as pip is itself a package manager and doesn't seem to expect the
packaging system to reserve a namespace under pip for installs.   As a
result of this, I have a practice of deciding to take one of two paths:

  use the packaging system.  Install packages for anything needed.
  Package them if need be.

  create a venv and run pip in that.

When you say "qgis seems to use its own version", I wonder if that is in
the context of particular binary distribution.  And if there really is a
full extra copy of libs, or if it's about a per-user site-packages
directory.

> Opening
> a terminal and running 'pip install whitebox-workflows' is going to
> install the package in a place that my QGIS plugin is unable to
> run.

Which place does it install to?  The system site-packages?

> And the process for manually pip installing within QGIS does not seem
> that straight-forward to me (at least on MacOS).

It sounds like the qpip tool that you were just pointed to likely has
resolved a lot of these things.  I would suggest that trying to really
understand the details of what goes where, what the paths are, and the
boundary between system install, per-user, venv, would help a lot in
ending up with a sound approach.

___
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 plugin depends on pypi package

[Greg Troxel via QGIS-Developer]

John Lindsay via QGIS-Developer  writes:

> Besides, a better solution would be for the plugin to install this
> package via pip when it is itself first installed and launched. I
> tried to accomplish this with the following code:
>
> https://github.com/jblindsay/whitebox_workflows_for_qgis/blob/4e463262f6cfd1987afa2f3f7e0e79656eb8d27e/whitebox_workflows_for_qgis_provider.py#L56
>
> This code, which runs whenever the plugin is launched, first checks to
> see if whitebox_workflows can be imported and if not, it runs pip from
> the Python script to install it. Unfortunately, some users have
> reported issues with this not working correctly:

(Writing from the UNIX perspective.) 

Perhaps biased by my packaing background, I view any code that downloads
other code at runtime (without an explicit user request) as a security
bug.   This is especially true if it isn't getting sources pinned to a
version and validated by checksum.

That said, there's a lot of interesting questions about how to deal with
dependencies of plugins.   For qgis itself, dependencies are properly
dealt with by a packaging system and that seems ok.

For plugins, I could see treating them as python modules and packaging
them, but qgis wants to have its own package management system.

qgis is usually installed, via packaging, globally (/usr or /usr/pkg, or
similar).  The immediate question is where plugins go.  I'd expect them
to be in the user's file area vs system, unless installing them in some
administrator role.  The next question is, if they depend on something,
what prefixes and install methods are expected for those things, both
regular packages (programs and shlibs) and python modules.  Which is
partly/mostly about what the search paths are in the plugin execution
environment.

Overall, I'd rather see plugins fail with a message and leave
installation as a manual decision than have plugins run pip install.
But I get it that most people probably don't see it that way.
___
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] Adding a "solution proposed" label?

[Greg Troxel via QGIS-Developer]

Nyall Dawson via QGIS-Developer  writes:

> What do we think about adding a new label for GitHub tickets for "solution
> proposed"? This could be used for tickets like
> https://github.com/qgis/QGIS/issues/55871 where the issue is likely a user
> error and a potential solution has been suggested.
>
> Stale bot could auto close these like it does with feedback tickets.
>
> It seems wrong to just close that issue without giving the reporter time to
> reply, but at the same time it's highly likely to become just another
> invalid open ticket if it's not actively managed in some way...

My comments are based on my experience maintaining unison (file sync,
not geo), which is also on github.  I find that some combination of
forum culture and github leads to people treating issue trackers as
places to ask for help.  This is not how Free Software used to be.  I
spent a lot of time cleaning up unison issues down to a manageable
number (300 to 75ish), and adopted a strict policy that the issue
tracker is only for

  - things that are bugs in the source code, with evidence

  - well-articulated feature requests that are likely of interest to
many (fringe ones I file on a wiki page and close the ticket)

That leaves out a lot of what gets put in issues.  One of the issues is
that new issues are typically seen by maintainers while there is a
larger community on a mailinglist.

It also leaves out "random packaging system X doesn't have the version I
want".  Those should of course be filed in X's tracker.

Questions and support requests I close with a pointer to the
mailinglist.

I am entirely ok with hitting close once it is established that there is
not a bug.  I am especially ok when it was a question.  The submitter
can read it while it is closed, and even comment.  It's just that it
doesn't show up in the open ticket list.

In the case of the ticket you referenced, it's clearly not a bug.  So
once that's established, if the user needs help to do what they want,
they should seek help in a help channel, from whoever wants to help
them, rather than it being the obligation of the maintainers who garden
the tracker trying to keep it useful.  You were already more than
gracious and hitting close when you did seems 100% fine.

So I would say:

  Establish a policy that questions are not allowed in the issue
  tracker.  Follow it strictly.

  Close tickets as soon as you can tell that they are not a defect in
  the source code.  If you are wrong  and the person follows up with
  evidence, hit reopen - no big deal.

  Use feedback when it is not clear and you have asked for better
  testing and more log data, but only when you think there could be a bug.

  When there isn't feedback, maybe leave it open if you feel that there
  is a real bug lurking that ought to be addressed, and just close it if
  you don't feel it's over that line.

  For feature requests that are fuzzy, ask that they get shaken out on
  some other forum and then refiled, when they can say with some
  precision what the new feature should do.

___
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] C++17 explicit --std required?

[Greg Troxel via QGIS-Developer]

(I picked -developer rather than -user because this is in the weeds of
build issues.  Please feel free to tell me I chose wrongly if so.)

I maintain the qgis entry in pkgsrc, which is currently at 3.28.13.
(For now, we are packaging LTR.)

As part of debugging problems related to sip 6.8.0 (see
  https://github.com/qgis/QGIS/issues/55481
), I am trying to clean up the compiler situation.

pkgsrc distinguishes between

  requiring that the compiler used supports c++17

  modifying the compiler wrappers to insert --std=c++17, because
  requiring that a compiler supports c++17 is not the same as requiring
  that c++17 is default, and sometimes code sssumes it is.

My view has generally been that one cannot assume the default std of a
compiler and that if a program requires a particular level it must test
for and pass --std=c++NN (or gnu++NN if that's how it is).

I am currently building qgis with a requirement that c++17 be available
(which is satisfied because the base system compiler is gcc10) but not
set to force --std.   I see a warning:

/tmp/work/geography/qgis/work/qgis-3.28.13/src/core/settings/qgssettingsregistrycore.h:178:18:
 warning: inline variables are only available with '-std=c++17' or 
'-std=gnu++17'
  178 | static const inline QgsSettingsEntryBool 
settingsEnableWMSTilePrefetching = QgsSettingsEntryBool( QStringLiteral( 
"enable_wms_tile_prefetch" ), QgsSettings::Prefix::WMS, false, QStringLiteral( 
"Whether to include WMS layers when rendering tiles adjacent to the visible map 
area" ) );
  |  ^~

which suggests that the build is using C++17 features without having
inserted --std=c++17.   Reading
  https://gcc.gnu.org/projects/cxx-status.html
it looks like C++17 became default in gcc 11, and C++14 is the default
in gcc 6.1 through 10.

Looking at INSTALL.md, I don't see a requirement for C++17 stated at
all.

Looking at CMakeLists.txt, I see some kind of c++17 forcing for MSVC,
but I don't see anything for other cases.  I see some kind of forcing in
individual CMakeLists.

So:

  Is it an error of me to build without wrappers that force --std=c++17?

  Is this just a qgis bug, that files that require C++17 aren't
  cmake-coded to pass --std=c++17?

  Is this harmless and should be ignored?

  something else?

___
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 repository management

[Greg Troxel via QGIS-Developer]

As someone on the outside of the committer set (which is fine!) for
qgis, but familiar with the larger issues (and a packager):

  I'm going to use the word committer.  git has renamed things, but the
  point is of course placing state in the branch that matters in the
  repo that matters.

  There's a question about how the rules evolved, and how they change,
  and that's hard to answer, but it's not really a big issue.

  The rules not being written down and understandable is a big
  issue with an easy fix.
  It is quite easy for someone who knows them to just put them in a
  HACKING.md  or CONTRIBUTING.md if you lean to github vs GNU.

  Sandro's point about 1 committer approving a stranger's change has
  some merit, but I think we have to separate:
- review to avoid bugs
- review to avoid injection of malware
  Presumably, one would only approve/merge a chagne if it is clean,
  neat, meets standards, works, etc., and if it were more complicated a
  committer should ask others/wait/etc.

  If we're going to insist on CI passing to merge, then it really needs
  to pass essentially all the time.  This means disabling parts of it if
  they are flaky, or demoting them to a 2nd workflow that is not
  considered a failure.
  
___
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] Next QGIS LTR and its compatibility with older versions

[Greg Troxel via QGIS-Developer]

Nyall Dawson  writes:

>> My impression is also that 3.30, 3.32 are stable and entirely usable for
>> users.
>
> Small clarification here: the 3.x.0 releases AREN'T considered stable,
> you should wait for 3.x.1 before targeting the newer release.

Thanks; I had figured that out over the years, but great to say it
again.

This ".0" isn't considered stable, while reasonable, is pretty unusual.
Perhaps the only other example is gcc.  It might be a clue that beta/rc
don't get used, and you need a release to get feedback -- having
maintained other projects, I get that.

It would be good for all .0 releases to carry a Big Scary Warning, and
to specifically request that packages not be updated to them.  Maybe you
are already doing that; I am hazy on when and where I see release
announcements -- I am assuming there is email to the users list.

(My bias is that qgis the project releases sources and packaging systems
package and provide binaries, and that qgis the project doing binaries
is remedial because the (mostly windows) packaging world is not working
well.  Hence source announcements being the standard path and the most
important thing.)

(A packaging system might have packages for each branch, in which case a
.0 package is fine.  But a packaging system with one package should not
update.)
___
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] Next QGIS LTR and its compatibility with older versions

[Greg Troxel via QGIS-Developer]

Andreas Neumann via QGIS-Developer 
writes:

> 3.34 will be the next LTR, but not yet in October 2023, but only
> starting from end of February 2024. In the table
> https://qgis.org/en/site/getinvolved/development/roadmap.html#release-schedule
> you can check the third column labeled "Long-Term Repo" to see at what
> time frame which version is LTR.

While we are on the subject, I have a packaging question.  I maintain
the qgis package in pkgsrc, a packaging system supporting multiple
operating systems, releases of those systems, and CPU types.  Currently
qgis is at 3.28.11, because I am tracking LTR.

I have avoided trying to have both LTR and non-LTR in pgksrc.   I have
guessed that LTR is more in the interest of random users.  But I am not
the least bit sure if that's right.

(Also, qgis LTR is nowhere near what LTS packaging needs.  LTS packaging
is generally 5 years.  I am not criticizing qgis for this, just being
clear; my view is that people who want to run old code for 5+ years with
fixes should pay for that maintenance and not ask open source project
volunteers to do it for them).

I understand that the non-LTR branches have limited support lifetimes,
but pkgsrc has no aspect of LTS (we have releases every quarter and no
support for old releases at all).  So the fact that 3.32 will become
unsupported when (3.34.0 is out | 3.34 is recommended for general use)
is not important to us.

My impression is also that 3.30, 3.32 are stable and entirely usable for
users.  It's merely that one jumps branches 3 times as often.  Of course
this is more difficult in a multiplatform environment as qgis saves
projects in the current version, not the version that was opened, so
everybody needs to be on the same version.

So, assuming our users are mostly individuals (if they are companies
they should have an IT shop and help with maintenance :-), is there any
reason I shouldn't have pkgsrc track the most recent
generally-recommended version?

What do other packaging systems do, that aren't explicitly LTS?   LTR
only, stable only, both?  I would appreciate hearing what you do and why.

> About your second question: don't nail me down on this but all 3.x
> versions should open with the newest 3.x version - it should be even
> possible to open version 2 files with the latest 3.x version.

As a data point, I have been tracking LTR via pkgsrc and never had an
issue opening.

However, every time a project is saved, it is written with the version
currently running, so once you do that, I expect it would be at least
some trouble to try to read it with the older version.  However, I have
never tried to do that.
___
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] strange files in bin when building qgis server

[Greg Troxel via QGIS-Developer]

Greg Troxel writes:

> The patch basically does:
>
> +CMAKE_ARGS+=   -DWITH_SERVER:BOOL=TRUE
>
> which as you'd expect adds that to the cmake invocation.
>
> Things are mostly ok; now new files appear in $prefix/bin, in lib and in
> share and reviewing the list most seem obviously sensible.
>
> However, two files get installed in bin: admin.sld and wms_metadata.xml.

I have read the docs at:

  INSTALL.md in the 3.28 sources
  https://docs.qgis.org/3.28/en/docs/server_manual/index.html

and none of them say anything about qgis server installation, other than
'go find binary packages and add them'.   I am of course trying to
create a binary package by building from source :-)

Reading the sources, it seems there is a default to overlay cgibin into bin:

  set (DEFAULT_BIN_SUBDIR bin)
  set (DEFAULT_CGIBIN_SUBDIR  bin)

which is puzzling, because normal webserver practice is to limit cgi to
a separate directory, so that only programs intended for cgi can be run.

Further, it seems that admin.sld and wms_metadata.xml are installed in
cgibin, which also seems wrong because they belong in a webroot, not the
directory with the cgi executables.  So really we another definition for
that, and I don't see any variables that fit.

It seems obvious (dangerous I know) that cgibin should default to
libexec/cgi-bin instead.  This is where php installs things, by default
if I read our package correctly as not forcing it.

It's not entirely clear to me if these two files are examples, that the
user will have to modify for their particular use, or if they are meant
to be used as is and never modified.  Packaging treats those two cases
separately; one going in share/examles/qgis/server and the other
requiring a share/qgis/server/webroot.

issue for docs not explanining the big picture:

  https://github.com/qgis/QGIS-Documentation/issues/8475
___
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] strange files in bin when building qgis server

[Greg Troxel via QGIS-Developer]

I maintain the gpksrc entry for qgis, currently at 3.28.7.  Generally it
works pretty well.

I am reviewing a patch to add qgis server to the package.  While there
are questions as to whether it should be a split package, I'm not
worrying about that yet, and it doesn't seem like the server files are
that big.

The patch basically does:

+CMAKE_ARGS+=   -DWITH_SERVER:BOOL=TRUE

which as you'd expect adds that to the cmake invocation.  The qgis
package already had a dependency on fcgi, for reasons that are unclear
(and unimportant!).

Things are mostly ok; now new files appear in $prefix/bin, in lib and in
share and reviewing the list most seem obviously sensible.

However, two files get installed in bin: admin.sld and wms_metadata.xml.

I have appended a snippet of our manifest of installed files;
bin/qgis_mapserver and bin/qgis_mapserver.fcgi seem correct, as do the
libraries, and the things beyond that which I have omitted.

But admin.sld and wms_metadata.xml are not executables and do not have a
qgis_ prefix.  They seems like examples, not something that should be
installed.

Do other people building qgis from source see these two files?  Others
maintaining packages?

This seems like a bug in the build system to me, but this is my first
interaction with anything qgis_server.

My build host is NetBSD 10 amd64.


Thanks, Greg


--- PLIST   20 May 2023 12:28:11 -  1.23
+++ PLIST   24 Aug 2023 23:17:25 -
@@ -1,7 +1,11 @@
 @comment $NetBSD: PLIST,v 1.23 2023/05/20 12:28:11 gdt Exp $
+bin/admin.sld
 bin/qgis
 bin/qgis_bench
+bin/qgis_mapserv.fcgi
+bin/qgis_mapserver
 bin/qgis_process
+bin/wms_metadata.xml
 include/qgis/Bezier3D.h
 include/qgis/CloughTocherInterpolator.h
 include/qgis/HalfEdge.h
@@ -1699,6 +1703,8 @@ lib/libqgis_gui.so
 lib/libqgis_gui.so.${PKGVERSION}
 lib/libqgis_native.so
 lib/libqgis_native.so.${PKGVERSION}
+lib/libqgis_server.so
+lib/libqgis_server.so.${PKGVERSION}
 lib/libqgispython.so
 lib/libqgispython.so.${PKGVERSION}
 lib/qgis/crssync

___
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] How to find pxiels per meter resolution

[Greg Troxel via QGIS-Developer]

Vedran Stojnović via QGIS-Developer 
writes:

> WGS84 is not a projection, it's an ellipsoid - a mathematical model of the
> Earth.

To be pedantic (a virtue :-), WGS84 is a family of specifications,,
which define not only the ellipsoid (same for all in the family,
thankfully), but also the position/orientation of coordinates and a
definition of orthometric height.  Included in this, perhaps implicitly
since it is not really about a particular datum, is transforming from
XYZ to LLh.  But, agreed that this list of components does not include a
projection to the plane.

The OP probably meant to say that the data is in the WGS84 Coordinate
Reference System, or that the project projection is WGS84 Web Mercator.

(I agree that the OP appears to need a consultant.)

___
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] Some PROJ versions are not compatible with QGIS on Linux instances

[Greg Troxel via QGIS-Developer]

C Hamilton via QGIS-Developer  writes:

> I don't know if this is something I should report or not. I keep getting
> users submitting issues for the Lat Lon Tools plugin on Ubuntu or Fedora
> because they are using a recent pyproj library and it is causing a crash. I
> have them check to see if "import pyproj" works from the python console
> which it invariably does not. The error is not with Lat Lon Tools, it is
> likely with this call
>
> epsg4326 = QgsCoordinateReferenceSystem('EPSG:4326')
>
> which is called during initialization and it is because the newer versions
> of PROJ seem to be incompatible.


It sounds like if "import pyproj" in python crashes, without doing
anything qgis-ish, then the issue is not "pyproj not compatible" but
"broken version of pyproj".

Can you in plugin init, do essentially try import except, and display an
error that init failed because the pyproj could not be loaded, and this
is not a latlontools issue?

Which pyproj is bad? 

Is this an upstream bug or a packaging bug?

Does it happen with a bad pyproj with all proj, or all pyproj with some
proj or ?

Is there a proj or pyproj bug open?
___
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] Adding a custom projection to QGIS

[Greg Troxel via QGIS-Developer]

Jennifer Johnston via QGIS-Developer 
writes:

> Ive been working on a custom projection with Duncan Cameron and
> Im wanting to add it to QGIS.  Is this something that I could do
> myself?  If so what specifications would I need and is there any
> documentation that I could read to help?  I have been told that
> creating a prj file with the parameters would not work.

I would lean to trying to add it to proj, rather than qgis, as you
probably want to use it with gdal too.  But, if it's a new projection,
vs paramaters to an existing projection, that's not trivial.

> Here is a link to an article about the projection 
> https://www.tandfonline.com/doi/full/10.1080/00087041.2022.2097758

That link doesn't work to read the paper, at least without US$58.   Is
there really no preprint or author website copy?
___
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] missing info in INSTALL.md, partial trip report for 3.28 on NetBSD

[Greg Troxel via QGIS-Developer]

For background, I have been maintaining the pkgsrc entry for qgis for a
while, and have been staying on LTR, partly because it's easier, and
partly because it sems a packaging system with only one entry should be
LTR, with a secondary entry for the current non-LTR release (which is
sometimes the same, as I think it is now).  I run qgis on NetBSD/9 amd64
and generally it works well, with only a few spurious error messages
(which I suspect are bugs and haven't tracked down.)

In updating pkgsrc from 3.22.13 to 3.28.1, I ran into a minor issue,
which I'll be sending a PR for, but that led me to notice that in
INSTALL.md's "overview", the list of dependencies is incomplete.  (I
realize there are a number of detailed sections for particular systems,
but none of those apply to "a system that more or less complies with
POSIX but isn't listed".)

I'm running my missing list up the flagpole before sending a PR, since
I'm guessing a bit:

  - C++11 compiler (right now, it doesn't even say you need a C++
compiler).  I see C++17 in a MSVC ifdef, but perhaps that's a
workaround.  I really doubt C++03 is ok.  And yes, I realize that
qgis depends on complicated C++ things and hence inherits any
language version requirement that they export via headers.

  - GNU make, >=4.3

and questions;

  - Is python 3.7 still ok?  In pkgsrc qgis is marked not-for 3.7
because of gdal, probably because of numpy, but perhaps qgis itself
works with 3.7?  Also mapserver support is said to need >= 3.6.

  - SIP is said to be >= 4.12.  Does that mean sip 5.5.0 is ok?  6.5.0?
My impression is that SIP is not API stable, so a >= requirement
doesn't seem quite right.

  - Is it necessary that the SIP used to build qgis be the same SIP that
was used to build py-qt5?


(
The bug I found was using std::fabs without ; PR to follow

--- src/gui/plot/qgsplotrubberband.cpp.orig 2022-11-18 12:10:21.0 
+
+++ src/gui/plot/qgsplotrubberband.cpp
@@ -20,7 +20,7 @@
 
 #include 
 #include 
-#include 
+#include 
 
 QgsPlotRubberBand::QgsPlotRubberBand( QgsPlotCanvas *canvas )
   : mCanvas( canvas )
)

Thanks,
Greg



signature.asc
Description: PGP signature
___
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] Long filename/filepath causing git issues

[Greg Troxel via QGIS-Developer]

"Alexis R.L. via QGIS-Developer" 
writes:

> I'm not sure it warranted a bug report but some control image now have
> names that are frankly too long and are causing issues in git if the local
> report folder is located some level down.
>
> Would it be too crazy to shrink down some offending name to prevent error
> when switching to more recent branches? I can submit a PR if needed.
>
> Here's one of the error I got
> 'tests/testdata/control_images/labelingengine/expected_label_curved_line_allow_upside_down_hint_reversed_right_positive_offset/expected_label_curved_line_allow_upside_down_hint_reversed_right_positive_offset.png':
> Filename too long

I am not objecting to shrinking, and don't really have standing to, but
can you explain the platform and what you think is going on?

That filename is 210 bytes long, which doesn't seem that big.  Do you
know what limit is being hit, in which program or the OS kernel, and
what properties the file name needs to have to avoid the problems?

I just checked on the box I am reading mail on (NetBSD), and it looks
like PATH_MAX is 1024 bytes.  That actually seems like a low limit these
days.   I am unclear on what the values are on other systems, only that
I have ~never run into this.


signature.asc
Description: PGP signature
___
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] Revolt Chat Community Server

[Greg Troxel via QGIS-Developer]

Also, revolt's terms contain:

  You are responsible for maintaining the confidentiality of your account
  and password, including but not limited to the restriction of access to
  your computer and/or account. You agree to accept responsibility for any
  and all activities or actions that occur under your account and/or
  password, whether your password is with our Service or a third-party
  service.

which seems like it is trying to be an indemnification, and it is
clearly unreasonable.  I don't think it's ok for osgeo projects to ask
people to sign contracta with third parties as part of participating.
But, I realize I am likely viewed as an extremist.

That said, revolt's terms (for their site) are less troublesome than
many other centralized services.


signature.asc
Description: PGP signature
___
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] Revolt Chat Community Server

[Greg Troxel via QGIS-Developer]

Régis Haubourg via QGIS-Developer 
writes:

> thanks for the work with Revolt. I tried it during the developer
> meeting in Firenze, but I did not persist in using it. Let me explain
> why and please excuse me in advance, this is a pretty long mail!

I found your message to be very thoughtful and helpful.

For background, my involvement in qgis development is so far maintaining
the pkgsrc entry (also gdal, postgis, proj), portability testing on
those projects, and ranting about WGS84 ensembles.

> - mailing lists are dying. Younger won't jump in. Being at ease
> suppose a good email client and filter rules. And this is a pain. What
> is really unique is that they are indexed by search engine and
> accessible via public archives. We built a knowledge base each time we
> post a mail. Osgeo also offers a central hub where one can't explore
> existing mailing lists, and this was a really nice to me.  Now that
> Nabble is dead, there is no more forum-like web access. And let's not
> forget that some people just don't want to use apps, and would like to
> stick to mail forever.  So we can't stay without decision here.

I think it's really unfortunate that people object to using email, for
reasons that to me border on fashion.

Besides archives, mailinglists have another important point, which is
that the set of subscribers to a list are a community, a group that
makes some effort to belong, and people tend to remain.   I don't see
this with other mechanisms.

In particular, community doesn't happen with github; only the very few
dedicated contributors subscribe all, and, at least in smaller projects,
a handful of people deal with and respond to issues that mostly should
not be in issues.  I suspect this is partially github's fault for
pushing all interaction to their systems while not offering
mailinglists, and partly that people expect personalized support from
others rather than joining and being mutual.

Another point I think is very important is that email allows meaningful
participation by people who are only able to pay attention once a day or
even less.  Anything chat-like (which includes many forums in my
experience) generates a culture of instant discussion and moving on.
The things that matter actually happen on slower time scales, and using
fast-only mechanisms effectively excludes slower time scale people.

This is a tools issue, but I find that with email, the conversations
arrive (and in my case are sorted into per-project folders), and I
become aware of them.  I do not have to go to N different websites to
keep up with various projects.

> - Chats aren't efficient and generate too much traffic. I personnaly
> just don't have enough bandwidth to follow 10% of the channels I
> should follow. And I am pretty involved. Furthermore, each country
> seems to have its preferences on which too to use. I ended up in
> having 6 apps on my phone only for those channels. This is far from
> ideal. Let's not forget that some people will never leave IRC too :)
> (and some have older phones not supporting so many apps).

I agree about too much traffic.  Between it being easy to type, vs an
expectation of thoughtfulness in email, and people popping into chats,
expecting help, and then leaving, I find it too much and only follow a
few.

> - we also have issues, Pull requests and potential GitHub discussions
> to not forget here :)

We do, but that's proprietary software and relying on it more raises the
cost of leaving.

> - adding a new communication channel without stating officially which
> is the main channel just breaks the single source of truth principle
> we had with mailing lists. I have seen recently two feedback from
> community users thinking that there was no debate on major topics,
> just because the discussion on the mailing list topics stalled. But
> those discussions in fact did occur, but spread across those new
> channels, and we didn't have enough bandwidth to summarize the
> decision on the mailing list (and we also forgot). This is the most
> annoying issue.

I think this should be  fixed by declaring the mailinglist to be the
communication method of record.

> Discourse is a modern forum, that can act as a chat if you are inline,
> or a mailing list, and let users tune their notifications levels
> pretty nicely.  Just have a look to the main page, stating the
> principles of this tool [0]

This is interesting and I don't have experience with it.  I suspect that
means the kinds of projects I tend to participate in are either
mailinglist culture projects or github only.

>  - Discourse as one organized and persistent place, including the
> osgeo history discussions. This would be the main communication
> channel. I will contact OSGEO to see if the system administration
> committee want to go this way for all the osgeo mailing lists.

I am open to considering this if it functions as a non-broken
mailinglist.  That's a tall order, with From: fields correct without
messing up DKIM/DMARC, but 

Re: [QGIS-Developer] Could the H3 library be included as a core QGIS library

[Greg Troxel via QGIS-Developer]

C Hamilton via QGIS-Developer  writes:

> A few months ago I was introduced to the H3 (Hexagonal hierarchical
> geospatial indexing system) library (https://h3geo.org/) and as a part of
> testing it to see its capabilities I included it in my Density Analysis
> plugin. The library is blazing fast in creating a hex grid and in doing a
> geohash of coordinates if you are doing a vector based heatmap like I
> have done in the Density Analysis plugin. I think it would be an asset to
> have it as a core QGIS library. Would there be any interest in including it?

Everything in core has to be built by every qgis package, and becomes a
required dependency, so "it would be useful" is not really the right
test.  It's more "It is so useful to many, on balance, that the overall
benefit outweighs the increase in size, compilation time, build
complexity, and dependency footprint".

I don't really have an opinion on the specifics of this.  It might help
to explain licensing, what the library depends on, build-time and
run-time requirements (anything not already required by qgis), whether
the library has a sane build system, etc.





signature.asc
Description: PGP signature
___
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] qt5 releases, packaging impact?

[Greg Troxel via QGIS-Developer]

I'm writing as a packager of qgis (pkgsrc).

A while ago there was discussion about QT making bug fix releases of
5.15 proprietary, more or less.   I see that
  "Qt 5.15.10 LTS Commercial"
was just released on June 7.

And,
  qt-everywhere-opensource-src-5.15.5.tar.xz
available at
  https://download.qt.io/archive/qt/5.15/5.15.5/single/
appears to have been released on June 17.

I haven't seen anything about this in a long time, so I wonder:

  Obviously it seems like all packaging systems should be updating the
  5.15.x releases as they come out.  Correct?

  The future is qt6, but I wonder if qgis with qt6 is fully reliable,
  and if qt6 is considered baked enough.Should I be trying hard to
  get qt6 fully packaged and transition qgis to it?  For 3.22, or just
  for 3.26, or ?

  Anything else I should know?

Thanks,
Greg


signature.asc
Description: PGP signature
___
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] Use of NE(SW) in the showing of (ordered) coordinates within QGIS

[Greg Troxel via QGIS-Developer]

Richard Duivenvoorde  writes:

> I think we should never copy the characters, only numbers ( well,
> except when using W/S/E/N :-) )..

Having thought a bit more this seems very tricky.

> I also understood from somebody that when using latlon coordinates the
> minus sign is actually redundant, as you should use the WSEN?

I don't think it's that simple, and looking at EPSG I'm sure it's not!
(qgis should not be tied to EPSG; it should follow any defined CRS,
custom or proj-provided but I understand most are from EPSG.)

Sometimes people write any of the following

  (42, -71)
  (-71, 42)
  42N 71W

for geographic.  And sometimes DM, DMS.  If we are going to try to align
with EPSG:4326, I think that means the first form.  But looking at

  https://epsg.org/crs_4326/WGS-84.html

it says that the parameter is in degrees [supplier to define
representation], and that latitude it positive north, longitude positive
east.

Degrees are given as

  https://epsg.org/unit_9122/degree-supplier-to-define-representation.html

which means that formally, we must define a representation among the
example choices of decimal, DMSH.  Other degree formats are just numbers
and numbers with hemispheres:

  https://epsg.org/unit_9102/degree.html
  https://epsg.org/unit_9116/degree-hemisphere.html

So I guess that means qgis could choose any of

  D DH DM DMH DMS DMSH

where H means no negative sign and N/S E/W, lack of H means numbers that
could be negative and no N/S/E/W.

It is pretty obvious which representation is chosen by how it's
printed.  It's clear that for cut/paste for computer use, 42,-71 is
best, and for human use it depends.

Looking beyond WGS84, I picked ITRF2014 and that is also EPSG:9122
(which I find surprising):

  https://epsg.org/crs_7912/ITRF2014.html

>> Part of the underlying trouble is that in qgis/proj we blur:
>>   datum
>>   projection
>> into
>>   CRS
>> except that some CRS are datum only, and some are datum+projection.
>
> But isn't that the 'difference' in what QGIS (in the CRS dialog) calls
> 'Geographic Coordinate Systems' vs 'Projected Coordinate Systems'?

Yes, but in opening a project and clicking around this is really not
obvious.  I know which are which, but it's really subtle.


Someone commented about in US usage Northing preceding Easting, and I
think meant for UTM, but might have also meant for State Plane
Coordinates.  I just checked a survey plan (MA SPC Mainland, which is
LCC) and sure enough N is given before E.  That doesn't mean it's right
in all cases; GIS, geodesy, surveying are all distinct subcultures.

Looking up Mass SPC, I find:

  https://epsg.org/crs_6491/NAD83-2011-Massachusetts-Mainland.html

and that is clear:

  Cartesian 2D CS. Axes: easting, northing (X,Y). Orientations: east,
  north. UoM: m.

which means easting has to come first, and the use of E and N is
non-compliant with the EPSG definition.  Use of E/N to label those also
is fundamentally different than N/S in latitude: it's a label for whcih
coordinate is which, not a replacement for a sign bit.

My impression is that while people often write xxx.xxxN, xxx.xxxE, it is
always easting, northing when used as a coordinate in a machine-readable
way.

> So: that would make (?): if crs.isGeographic() [0] we should/could use
> WSEN, and if not then we should NOT use WSEN (and optionally x/y if
> that is more clear)... except when copying coordinates, because that
> would mess up parsers :-)

It comes back to the purpose of this.  I would say:

  - By default the rules in the CRS should be followed.  That means N/S
can be used only if the underlying degree reference is EPSG:9122.
But then it's optional.

  - Copy coordinate is intended to produce something machine-readable.
That means just numbers, to the extent that is reasonable.

  - The display format should match what is copied, to follow the
Principle of Least Astonishment.

  - If someone wants a richer display of coordinates in many formats,
that should perhaps be another right-click menu item.

My vote is for just numbers, like we have now, so the only thing
changing is making the axes compliant with the CRS definition.

And, perhaps either a preference to select a degree represenation (6
choices!), or multiple entries in the menu.  But default should be plain
decimal degrees, IMHO.

I would be ok with the chosen degree representation being used even if
the CRS specifies 9102 instead of 9122.

I would also be ok with a preference to add E/N letters to coordinates
that are defined to mean Easting and Northing by the CRS.   Default off.

Hope this helps




signature.asc
Description: PGP signature
___
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] Use of NE(SW) in the showing of (ordered) coordinates within QGIS

[Greg Troxel via QGIS-Developer]

Richard Duivenvoorde via QGIS-Developer 
writes:

> In 3.24 you will see something like "WGS84 5.2 52,3"
> While in master it shows: "WGS84 52.3N 5.2E"  (note the N and E)
>
> For WGS84 I think this is normal (to show WSEN), but for other crs's I
> think it is overkill?
>
> In 3.24: "EPSG:28992 (15,45)"
> In master now I see: "EPSG:28992 (150702E,466216N)"

I think the real question is if these are expected to be useful for
humans to look at, or if they are expected to be machine-processable
somehow.

And if they are for humans, what are the humans doing with them?

And if they are hints for what will be copied, but the copied string has
just numbers and a comma so that copied string is machine procesable.
Or if it's a mini geojson point object (just kidding; that seems a bit
much).

As for x and y, those are projection concepts, and for WGS84:

  using x for latitude and y for longitude is basically declaring a
  projection, and for 4326, that isn't so even that's what people often
  choose to do when displaying 4326 for nerds

  WGS84 ECEF has axes, and they aren't the same as how you are using
  them.  WGS84 geographic does not have x and y axes.

For UTM/LCC sorts of CRSes, the axes are (usually) easting and northing
and I don't see then written x and y.


There is some messiness in that if one sets a project CRS to 4326, then
the display is x=lon, y=lat, which is a projection.  Basically if you
have have a project CRS that isn't a projection, then there is further
step to relate the CRS axes to display x and y, and that's implicit.
For many things, given the dominance of north up, there is an obvious
answer, but it's still an assumption.


Part of the underlying trouble is that in qgis/proj we blur:

  datum
  projection

into

  CRS

except that some CRS are datum only, and some are datum+projection.



signature.asc
Description: PGP signature
___
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] WFS3 API POST PUT Methods

[Greg Troxel]

"Carlo A. Bertelli (Charta s.r.l.)"  writes:

> The GeoJSON Specification (RFC 7946) mandates the use of WGS84:
>
> The coordinate reference system for all GeoJSON coordinates is a
>> geographic coordinate reference system, using the World Geodetic
>> System 1984 (WGS 84) [WGS84
>> ] datum, with
>> longitude and latitude units
>> of decimal degrees.
>
> (chapter 4)
>
> OAPIF can use GeoJSON (very often) and in this case using another reference
> system is not allowed, but it can also use GML level 0 or level 2 and in
> these cases there is no limit to what CRS you can use.

Yes, but either

  Because geojson can only use WGS84, it is a deficient format, and
  unsuitable for anyhthing where accuracy at the 2m level matters.

or

  Because geojson in practice is widely observed to have datum tags, one
  can and should take the view that there is an error in the geojson
  format spscification and treat it as geojson+ that allows specifying
  crs.

I personally hold the latter view.

However, if one is dealing with tools that don't honor crs in geojson,
agreed that one has to hold the first view.



An example follows (hand redacted, may be messed up) of a geojson
produced from qgis/gdal, in ITRF2014 as a way to get a good transfrom
from NAD83 and be sensible in the web world.  i didn't do any
contortions to get this; just

  ogr2ogr -f GeoJSON -t_srs "EPSG:7912" -s_srs "EPSG:6319" 
%TRAILS/BAR/invasive-points.geojson bar.gpkg invasive-points


{
"type": "FeatureCollection",
"name": "foo-invasive-points",
"crs": { "type": "name", "properties": { "name": "urn:ogc:def:crs:EPSG::7912" } 
},
"features": [
{ "type": "Feature", "properties": { "species": "bittersweet", "todo": false }, 
"geometry": { "type": "Point", "coordinates": [ -71.5, 42.5, 80 ] } },
]
}

  


signature.asc
Description: PGP signature
___
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] 3.16.16 build failure (NetBSD 9, pkgsrc)

[Greg Troxel]

Greg Troxel  writes:

> It sort of looks like there is a test for an optional feature that isn't
> guarded; I'm not building with qtwebkit.

That is exactly the issue; idfdefing one function that relies on webkit
gets the build to finish.  PR soon.


signature.asc
Description: PGP signature
___
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] 3.16.16 build failure (NetBSD 9, pkgsrc)

[Greg Troxel]

I'm trying to do an update of pkgsrc from 3.16.15 to 3.16.16, and got a
build failure in test code.  (It seems building tests is on by default
which is perfectly ok, and I should try to run them.)  Immediately prior
to building 3.16.16, I built 3.16.15 which was clean all the way to a
binary package.  I did the build of 3.16.16 without qgis installed at
all, in case that old headers were leaking into the new build.  (All
previous micro updates have been without issue, except perhaps adding a
file or two to the manifest.)

It sort of looks like there is a test for an optional feature that isn't
guarded; I'm not building with qtwebkit.   I would hope it isn't really
necessary to have that, as it is truly enormous and takes hours  to
build.  I've been running without it for a few years and haven't noticed
anything missing.

I will look into this more but I thought I'd see if anyone else has seen
a similar failure.

  [ 96%] Built target qgis_externalresourcewidgetwrapper_autogen
  Consolidate compiler generated dependencies of target 
qgis_externalresourcewidgetwrapper
  [ 96%] Building CXX object 
tests/src/gui/CMakeFiles/qgis_externalresourcewidgetwrapper.dir/testqgsexternalresourcewidgetwrapper.cpp.o
  
/tmp/work/geography/qgis/work/qgis-3.16.16/tests/src/gui/testqgsexternalresourcewidgetwrapper.cpp:
 In member function 'void 
TestQgsExternalResourceWidgetWrapper::testBlankAfterValue()':
  
/tmp/work/geography/qgis/work/qgis-3.16.16/tests/src/gui/testqgsexternalresourcewidgetwrapper.cpp:141:27:
 error: 'class QgsExternalResourceWidget' has no member named 'mWebView'
 connect( ww.mQgsWidget->mWebView, ::loadFinished, , 
::quit );
 ^~~~
  
/tmp/work/geography/qgis/work/qgis-3.16.16/tests/src/gui/testqgsexternalresourcewidgetwrapper.cpp:141:48:
 error: incomplete type 'QWebView' used in nested name specifier
 connect( ww.mQgsWidget->mWebView, ::loadFinished, , 
::quit );
  ^~~~
  In file included from /usr/pkg/qt5/include/QtTest/qtest.h:45:0,
   from /usr/pkg/qt5/include/QtTest/QtTest:11,
   from 
/tmp/work/geography/qgis/work/qgis-3.16.16/src/test/qgstest.h:19,
   from 
/tmp/work/geography/qgis/work/qgis-3.16.16/tests/src/gui/testqgsexternalresourcewidgetwrapper.cpp:18:
  
/tmp/work/geography/qgis/work/qgis-3.16.16/tests/src/gui/testqgsexternalresourcewidgetwrapper.cpp:145:27:
 error: 'class QgsExternalResourceWidget' has no member named 'mWebView'
 QVERIFY( ww.mQgsWidget->mWebView->isVisible() );
 ^
  
/tmp/work/geography/qgis/work/qgis-3.16.16/tests/src/gui/testqgsexternalresourcewidgetwrapper.cpp:151:27:
 error: 'class QgsExternalResourceWidget' has no member named 'mWebView'
 QVERIFY( ww.mQgsWidget->mWebView->isVisible() );
 ^
  
/tmp/work/geography/qgis/work/qgis-3.16.16/tests/src/gui/testqgsexternalresourcewidgetwrapper.cpp:152:28:
 error: 'class QgsExternalResourceWidget' has no member named 'mWebView'
 QCOMPARE( ww.mQgsWidget->mWebView->url().toString(), QStringLiteral( 
"about:blank" ) );
  ^
  At global scope:
  cc1plus: warning: unrecognized command line option '-Wno-redundant-move'
  gmake[2]: *** 
[tests/src/gui/CMakeFiles/qgis_externalresourcewidgetwrapper.dir/build.make:90: 
tests/src/gui/CMakeFiles/qgis_externalresourcewidgetwrapper.dir/testqgsexternalresourcewidgetwrapper.cpp.o]
 Error 1
  gmake[1]: *** [CMakeFiles/Makefile2:19308: 
tests/src/gui/CMakeFiles/qgis_externalresourcewidgetwrapper.dir/all] Error 2
  gmake: *** [Makefile:166: all] Error 2
  *** Error code 2



Sort of related, I could not tell from tests/README.md if the tests all
run with the not-yet-installed qgis, or if it's like gdal where it tests
the installed version.  I'm guessing not-yet-installed.


signature.asc
Description: PGP signature
___
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-psc] QGIS LTR releases -- is it time to pull the plug?

[Greg Troxel]

Jürgen E. Fischer  writes:

> Hi Bo,
>
> On Tue, 16. Nov 2021 at 18:41:31 +0100, Bo Victor Thomsen wrote:
>> So yes, the LTR point releases are used. Not all point releases will be
>> installed every time, but some will.
>
> So you could agree that a monthly frequency it to high and a point release
> every two or three month could suffice?

From my view as a user and packaging in pkgsrc, every 2 or 3 months is
fine, especially if there haven't been any serious bugs.

My experience has been that the LTR point releases have all been totally
boring from a packaging/install point of view, which is good.  But I'm
just using the source tarballs, and my doing an update of qgis to a new
point LTR does not cause changes in dependencies.




signature.asc
Description: PGP signature
___
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 LTR releases -- is it time to pull the plug?

[Greg Troxel]

Nyall Dawson  writes:

My comments are mostly meta...

> I'd like to start some conversation about the dire condition of the
> QGIS LTR release and what we can do to remedy/avoid this in future.
>
> If you've missed the conversation, our QGIS 3.16 windows releases have
> been completely broken for nearly a month now. 3.16.12 had a critical
> issue which caused lockups in Python code, and now 3.16.13 has
> completely broken projection handling (resulting in loss of CRS,
> hangups when opening projects, etc).

I did miss the conversation about the .13 problems, and I think I'm
subscribed to qgis-developer@.  I admit to not reading a lot of messages
carefully, as I am really here in aid of keeping the qgis packages in
pkgsrc working.

If the conversation was entirely in github issues, I would suggest that
serious things be brought up on the mailinglist, because subscribing to
everything on a repo like qgis seems only feasible for people who have
qgis development as a main focus, and thus github discussions don't
involve the wider community.

I think it is important to keep clear in all communications between "the
release is broken" (which implicates the sources for all platforms), vs
"the official binary packages (flavor X) for platofrm Y is broken".  I
would also want to have "the release" be the sources and have words like
"official binary packages of the release" be used when something that
isn't the source tarball is being talked about.

For example:

  https://blog.qgis.org/2021/11/16/qgis-ltr-3-16-13-reverted-to-3-16-11/

says "QGIS LTR 3.16.13 reverted to 3.16.11" but then in the finer
printer "This is true for Windows only as other OS will keep delivering
the latest 3.16.13.".   So this is really "On windows only,...".

(As an aside I find the download URL
  https://qgis.org/downloads/macos/qgis-macos-ltr.dmg
unclear as I can't tell what release that actually is, without
downloading and unpacking it, or going to the URL up one level and
inferring from dates, which points at .13, which makes sense.)

> - Put out a massive apology (and ask users to step up their funding to
> better maintain QGIS releases in future ;)

My view is that it's reasonable to ask people using Windows in a
non-personal environment to pay a small pseudo-license fee, because
Windows culture goes along with paying for software I don't mean to
depart from Free Software, just sort of a posted moral obligation to pay
something like 5% of what the ESRI licenses would have cost towards
maintenance.  I think the trick is to structure it somehow that it is
like a license/support fee to the above-the-nerds part of companies,
which is easier said than done.

> - Mark 3.16 as an early EOL. (I can't see anyone interested in
> resolving the actual issue, so we've no way forward here in releasing
> a "good" 3.16 release again.)

I updated pkgsrc to 3.16.13 on pkgsrc, and running it on NetBSD 9 it
seems to work just fine.  I even used geoscience plugin to create a
custom transform from a local grid and transformed data back into that.

So I don't see how it's reasonable to withdraw 3.16 from users of POSIXy
operating systems because Windows packaging is troubled.

> - Write the LTR releases off as a failed concept. (i.e. if we don't
> have the resources to maintain them properly, we shouldn't be offering
> them at all and should resort back to the single maintained release at
> any one time situation.)

I agree with previous commenters that this isn't a good approach and
won't repeat the ideas.

It's still not clear to me if there are actual problems in the 3.16.13
source tarball, or if this is about windows packages that have some
other kind of trouble.

In theory I'll create a package for the non-LTR release, but in practice
I haven't gotten to it yet, multiplexing gdal/geos/postgis/proj updates,
and now I'm looking at creating a 3.22 package to make the migration
faster when that is blessed as LTR.

It might be that the amount of structural changes in packaging is small
enough that this is easier than I think it's going to be, but I don't
know that.

> - Lower the supported period of a LTR release to 6 months?

That's very short.   To me, the point of stable releases is so that
users can avoid upgrading for some yearish at least period of time,
where "micro updates" don't count as upgrades.

I don't even see 1 year as a "long term release".  That's a medium term
release.  The "Long Term Stable" label in the GNU/Linux world tends to
apply to distributions that try to go for 5 years, with bug fixes only.

In maintaining pkgsrc, the point releases have been very fast, basically
a few minutes of work, do something else while it builds (thansk to
cache-busting revision headers), and then start it and see if it works
and then commit, maybe 20 minutes of paying attention.  Jumping branches
was a lot more the last time, and it's not the branch jump per se, but
things like new dependencies, requirements for particularly recent
versions of 

Re: [QGIS-Developer] URGENT AS CAN BE: QGIS 3.16.12 and sip 6?

[Greg Troxel]

Thanks to both of you for explaining.

I'm going to ignore sip 5, as it seems like some things need 4 (which
today means 4.19.25), and some things support "modern sip" and are thus
ok with 6.

So as I see it:

  In packaging, given that qgis is at 3.16, I need to keep sip at
  4.19.25 because 3.16.x does not support sip 6 at all.  (Or have
  multiple sip versions, but I don't want to go there.)

  3.22.0 has broken support for sip 6.  I should be able to build it
  with 4.19.25, but not 6.

  The 3.22 maintenance branch has a fix for sip 6, so 3.22.1, when it
  appears, will be ok with sip 6.

  3.22 is headed for LTR, but the LTR label has not yet been moved to
  it.  So in pkgsrc, I should leave qgis at 3.16 for now.  January would
  be a good time to change pkgsrc, given our release schedule, and by
  then 3.22 might or might not be blessed as LTR.

  3.22 will work fine with sip 4, and thus I can upgrade qgis to 3.22,
  and ask if any other sip users need 4 vs 6, and then see about a sip
  ugprade.

and

  In INSTALL.md on 3.16.x, it says that sip must be >= 4.12, and doesn't
  mention < 5.


signature.asc
Description: PGP signature
___
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] URGENT AS CAN BE: QGIS 3.16.12 and sip 6?

[Greg Troxel]

Nyall Dawson  writes:

> Mmm... I really don't think that works for end users though. Someone
> who has installed qgis 3.16.12 from last week's installer has no way
> of telling that they'll be affected by the bug vs someone who only
> just downloaded the installer. There's no way we can put out any
> announcement and say "check the about screen and if your version says
>  then you need to update".

I'm not trying to suggest that the plan be changed.

The problem here is that what's being released by these binary
installers is a packaging system, not the source and in general
packaging systems need another place to put a version they can increment
when there is a change to the packaging configuration (included patches,
build options, etc.).

I suspect that because this is "qgis binary release" it isn't being
viewed as a packagaging system.


As an example, in pkgsrc had we backported a patch for wip, and we ha

  qgis-3.16.12

and then if we fixed  that we'd have

  qgis-3.16.12nb1

which says that it is a packaging change but the same upstream tarball.

As I understand things Debian etc. does the same thing (but the version
numbers look different, I think "-N" suffix).


signature.asc
Description: PGP signature
___
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] URGENT AS CAN BE: QGIS 3.16.12 and sip 6?

[Greg Troxel]

Jürgen E. Fischer  writes:

> Hi Nyall,
>
> On Fri, 05. Nov 2021 at 08:28:33 +1000, Nyall Dawson wrote:
>> > We also then need to push out a news feed item advising that 3.16.12
>> > has critical issues and that all users should update to 3.16.13.
>  
>> Any response to this? I feel SO strongly that we need to push this out
>> as a matter of urgency.
>
> Hm, I don't.  The affected windows packages are already fixed.  People just
> need to update to the latest packages.  Doing another release wouldn't change
> nothing more than the version number and trigger a lot of otherwise useless
> rebuilds - even on platforms that were not even affected.   And the next point
> release is only two weeks away.

As someone who thinks releases are fundamentally about source code, I
find the "official binaries" being considered as "project releases"
tightly bound to the code being an unfortunate situation.  It took me a
minute to realize this was all about choices of dependencies in releases
of compiled binaries, and nothing about the actual 3.16.12 source
release.

WIth packager hat on, I wonder if sip 5 or 6 is truly broken, or if qgis
has a bug where sip6 is not actually buggy but does something bad on
qgis, or something else.  I didn't see a bug URL and am wondering if I
should be sticking a note in our py-sip package to  ask that it not be
updated past the current 4.19.25.


signature.asc
Description: PGP signature
___
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] Default QgsFeatureFid ?

[Greg Troxel]

Sandro Santilli  writes:

> On Fri, Oct 15, 2021 at 08:12:07AM -0400, Greg Troxel wrote:
>
>> There's a larger question lurking behind that, which is something about
>> if tables in SQL can have NULL values and how that NULL is mapped into
>> qgis's main internal representation and then back out to various
>> formats.  (I know there's a great CJ Date rant about NULL not belonging
>> in SQL and how it is a symptom of denormalized data, but it is how it is
>> these days.)
>
> I don't think QGIS needs to support "null" values for feature id.
> Features *need* to have an not-null identifier.

Sounds perfectly reasonable, but in that case I would expect that it is
a non-optional argument to a constructor, and there should not be a way
to have a default value.

There might also be a non-duplicate integrity constraint.


signature.asc
Description: PGP signature
___
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] Default QgsFeatureFid ?

[Greg Troxel]

Sandro Santilli  writes:

> On Fri, Oct 15, 2021 at 10:45:52AM +0200, Alessandro Pasotti wrote:
>> Hi,
>> 
>> maybe you can use
>> 
>> #define FID_NULLstd::numeric_limits::min()
>
> Maybe, but the question is more generic: *should* a QgsFeatureId have
> a default value ?

There's a larger question lurking behind that, which is something about
if tables in SQL can have NULL values and how that NULL is mapped into
qgis's main internal representation and then back out to various
formats.  (I know there's a great CJ Date rant about NULL not belonging
in SQL and how it is a symptom of denormalized data, but it is how it is
these days.)

That said, it seems obvious that SQL NULL should map to FID_NULL on
reading.

About

  std:numeric_limits::min()

that would seem to end up with a different value on different systems,
although if QgsFeatureId is a fixed-width type that might require 2s vs
1s complement.

I guess something like FeatureId really does need to have a reserved
NULL value, or we need a rule that it can't be.

Not about qgis, but in an unusual corner Home Assistant I have run into
a problem with varying representations of the same semantics, leading to
incorrect behavior.


signature.asc
Description: PGP signature
___
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-psc] Developer support channels

[Greg Troxel]

It seems implicit in the discussion that you are only considering open
protocols for which there is first-class open source software, client
and server.  Maybe I missed that earlier, but I wanted to say it
explicitly.

I've been using matrix for similar purposes in other communities, and
it's been reasonable.  Often bridged to IRC or (not-open) Telegram.

I don't really have an opinion on invite-only.  It does strike me as
unusual.


signature.asc
Description: PGP signature
___
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] network analyst in qgis

[Greg Troxel]

Nils Nolde  writes:

> It's mostly about making a self-contained plugin really. It's
> definitely not an option to have users install that stuff from source,
> there's thing like boost, protobuf etc involved and the very latest on
> Windows people will (rightfully) never even try. The Python bindings
> are pre-packaged as wheels, so installation becomes trivial. In that
> sense users could do it themselves potentially, but code can as well
> and I'd like that for UX. And my feeling is that the extra effort for
> automating that process is probably dwarfed compared to the tickets
> we'd get from users who don't manage to install things into OSGeo4W
> python.

Thanks, that is understandable, although I disagree about
"rightfully"

>>> I know it's strongly discouraged to submit binary components to the
>>> official plugin store. Also that wouldn't make much sense, some of
>>> those dependencies weigh like 30 MB or more (per platform). Can
>>> someone point us to a plugin that has a similar logic of pulling
>>> binary libs? I'd like to avoid to leave it to the user to install
>>> those dependencies, rather have it done automatically.
>> And 'per platform' is going to support only a handful of platforms,
>> compared to all the places where one can build qgis.

> Haha true! At least it's a manylinux distribution for linuxes with
> glibc 2.24 (didn't wanna go down the rabbit hole of earlier versions
> with that many dependencies). 3 distros (mac 10.9, win amd64,
> manylinux) would amount to well over 300 MB, of which only a third is
> relevant to a single platform.

And then there are other operating systems, including ones that
mainsteram qgis culture hasn't heard of -- so there really needs to be a
"you must first install X, Y and Z", even if there is pre-built versions
for popular systems.

>> It could be that I'm asking questions about the broader plugin
>> architecture and portability, more than your situation.

> I guess the consent is to trust binaries being executed on a user's
> machine (I figured that's the reason QGIS doesn't want it). To a

That would be my concern, but I'm on the paranoid side.

> lesser extent maybe size. Licenses will be mostly GPL, maybe some
> closed (only for the bindings and packaging, the underlying engine is
> FOSS), still an ongoing discussion.

I am surprised it is considered ok to have non-free software as part of
a plugin.  Usually in Free Software plugins are considered derived works
of the project, so them including code not compatible with GPL2 seems
problematic.  I wasn't clear on the project's stance, but it seems to be
exactly this typical norm:

  https://blog.qgis.org/2016/05/29/licensing-requirements-for-qgis-plugins/
  
(I'm just a random user and packager, not speaking with any official
hats.)


signature.asc
Description: PGP signature
___
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] network analyst in qgis

[Greg Troxel]

Nils Nolde  writes:

That all sounds like great progress.

Speaking as a packager for systems that are somewhat unusual:

> solvers, that's above our heads. For everything we need a performant
> routing engine, so we have to include several third-party FOSS
> projects for routing & solving, those dependencies are unfortunately
> all binary. So after the (hopefully encouraging) announcement, my
> question:

I do not understand how depending on Free Software projects maintained
by others leads to "binary dependencies".  Can these really not be built
from source?  Do you just mean "on the system that uses the plugin, a
bunch of other packages (and presumably their python bindings?) must be
installed?  Is this just about making a self-contained plugin for
Windows where expecting qgis users to manage other code is wishful
thinking?

> I know it's strongly discouraged to submit binary components to the
> official plugin store. Also that wouldn't make much sense, some of
> those dependencies weigh like 30 MB or more (per platform). Can
> someone point us to a plugin that has a similar logic of pulling
> binary libs? I'd like to avoid to leave it to the user to install
> those dependencies, rather have it done automatically.

And 'per platform' is going to support only a handful of platforms,
compared to all the places where one can build qgis.

> Are there other recommendations to handle this situation? I guess at
> the very least the user should agree to download those binaries. Since
> we have to download 4 different libraries, do you think the user
> should consent to each one individually (the routing engines are
> crucial, but location/allocation & VRP not really)?

Is the consent about license, about trusting the code with one's data
(since it runs in user context), about the space, or something else?

It could be that I'm asking questions about the broader plugin
architecture and portability, more than your situation.

Greg


signature.asc
Description: PGP signature
___
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] expected ccache hit ratio on new micro release?

[Greg Troxel]

(If people feel this query belongs on -user, please feel free to tell
me that.)

I maintain the qgis entry in pkgsrc, a multi-OS multi-CPU packaging
system, and use qgis 3.16.x on NetBSD.  So I am talkiing below about
NetBSD 9 amd64.

I use ccache, to save compilation time, since in doing packaging I am
often rebuilding X that depends on updated Y, but most of X's
compilations are the same headers and sources.  And, I often rebuild a
package after I just built it, to verify I didn't break something, after
making a minor change to the packaging files.

On September 5, I updated the package to 3.16.10 (was behind for no good
reason).  I always build, make a package, install it, and then run qgis
from the installed package before pushing the update to the rest of
pkgsrc.  So far, it's been smooth, and qgis seems not to have any
NetBSD-specific issues.

Just now I changed the version in the control file to 3.16.11 and am
building.  I zeroed stats before and have done only a tiny bit of other
building.  So far, ccache reports:

  cache directory /home/gdt/.ccache
  primary config  /home/gdt/.ccache/ccache.conf
  secondary config  (readonly)/usr/pkg/etc/ccache.conf
  stats updated   Wed Sep 15 13:16:01 2021
  stats zeroedWed Sep 15 09:17:16 2021
  cache hit (direct)13
  cache hit (preprocessed)  80
  cache miss  4056
  cache hit rate  2.24 %
  called for link   94
  called for preprocessing2101
  compile failed14
  preprocessor error26
  autoconf compile/link106
  no input file 24
  cleanups performed 4
  files in cache206471
  cache size   9.0 GB
  max cache size  10.0 GB

This means qgis will take about 8h to build, on a machine that was
fairly high end in 2014, with 1 core in use (for heat), and plenty of
RAM.  This matches my memory of previous updates.

It surprises me that a bug fix release would have almost hits, but
perhaps there is a version number in a header that every program reads,
and thus every file misses.  But I am not arguing that it is a bug, of
course.

I am curious if anyone else uses ccache, and if this is what they see as
well.

Thanks,
Greg


signature.asc
Description: PGP signature
___
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-psc] How to handle upstream Qt fixes

[Greg Troxel]

Nyall Dawson  writes:

> I'd never make the KDE fork a requirement for a bulid -- we'd always
> have to ensure that users can build using the official releases.
> They'd just potentially suffer from upstream Qt bugs which have since
> been fixed in the community fork. (And if we do nothing, they'd be in
> exactly the same situation!!)

I guess then I'm not sure what the question is.  It seems clear:

  qgis source code should build against qt 5.15.2 and also against qtx
  5.15.next (or whatever it's called), and perhaps against some earlier
  qt 5.x

  if something goes wrong that's a qt bug, then probably some reasonable
  effort might be made to accomodate it, but if it's fixed in qtx and
  not in qt-frozen, then perhaps not so much

  maybe qgis would declare that the fork is the preferred source of qt5.

  people who build binaries will choose what they choose.  Maybe there
  would be some sort of "the standard approach is [version-x] for qt"
  guidance statement, and maybe there wouldn't be.

  project-built binaries need to choose

So I'm still not entirely clear what question is on the table

>> Maybe it's time for another 'big gap' in QGIS releases? As in: after
>> 3.22 (LTR) there will be a probably not so stable 4.0 which will
>> have a thorough api cleanup (first), while maybe partially trying to
>> do some pre-work for Qt6? And so hopefully we will have Qt6 packaged
>> more easily at that time?
>
> See https://github.com/qgis/QGIS-Enhancement-Proposals/issues/198 for
> my proposal on how we handle this. I'd suggest that (when we're ready)
> we do a "soft break" and support Qt 6 builds of QGIS 3.x, with the
> intention of moving the Windows and Mac builds to Qt 6. We don't allow
> ANY api breaks which aren't directly related to making QGIS qt6
> compatible, so that plugins will only have to make very minimal
> changes (if any)

comments on QEP198

  I do not follow how qt 5.15.2 won't work on Apple aarch64.  Presumably
  it can be built on Linux/BSD aarch64, and the apple interfaces at the
  source level remain.  Maybe that's out of date, maybe I'm confused.
  Maybe it is fixed in the fork.

  I don't really see how cleaning up deprecation warnings in 5.15, while
  keeping the codebase entirely ok when built with 5.15, is a break,
  other than from older qt5.  If that's what you mean, that's fine  -
  but if you mean something else, I did not follow.

  It's almost a year later, so I wonder how the build w/o deprecation
  warnings is going.  I think you said there's about 4 FTE-weeks more
  work.

  It would be really nice if the next LTR was dual 5.15/6.  (Sorry, I
  have no spare ponys for you.)

>> What is the Qt6 status in Fedora or Suse?
>
> Fedora has qt 6.1 packages from Fedora 34 (we use these on the CI to
> test builds of the core/analysis library on Qt 6). Not sure about SUSE
> personally.

pkgsrc has qt5 5.15.2 currently, and has qt6 packages in our separate
draft repository.  I am not hearing a lot about imminently moving them
to pkgsrc proper.  Overall I get the sense that qt6 has not fully
arrived.  I realize it's been a while formal release of 6.0, but it
seems like enough of a departure that it's difficult.


signature.asc
Description: PGP signature
___
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] How to handle upstream Qt fixes

[Greg Troxel]

Nyall Dawson  writes:

> - Qt Co effectively ended open source support of Qt 5 at the 5.15.2
> release, and have moved all focus to Qt 6.
> - While some preliminary work has been done, QGIS doesn't currently
> support Qt 6 based builds, and likely won't be ready for this for some
> time (even completely ignoring all the stable API questions a Qt 6
> build raises entirely!)
> - QGIS often depends on fixes and enhancements which need to be made
> upstream in Qt, and can't be resolved or worked-around in QGIS alone
> - KDE and other open source projects forked Qt 5.15 at
> https://invent.kde.org/qt/qt/qtbase/-/commits/dev/, and are actively
> backporting fixes from Qt6 to that branch. Fedora recently started
> using the KDE branch for Qt 5 library builds, so users of that
> platform once again are getting bug fixes deployed [1]. I'm unaware if
> other distributions or builds of Qt are using this currently.
> - Similarly, there's a KDE fork of Qt 3d at
> https://invent.kde.org/qt/qt/qt3d/-/commits/kde/5.15/

I'm speaking as the maintainer of the qgis package in pkgsrc, a multi-OS
multi-CPU packaging system.  Currently this is 3.16.x, and it is built
against 5.15.2 (only).

I think you have posed semi-separable questions and it's good to
semi-separate them:

  - 1. should qgis target the KDE fork of QT, or 5.15.2, or both, as the
library that is expected to be used, and tested in CI?

  - 2. when qgis.org produces binary builds, should qt-kde or qt be used?

  - 3. should qgis.org attempt to engage with KDAB to work on a fork of a
branch discontinued by the original maintainers?

  - 4. Given what I see as concerning behavior by Qt Co in placing Free
Software users in a bad spot, what should be the future approach to
Qt?  Perhaps, it should be KDE Qt 5.15, and not Qt 6.)

and I think this is informed in large part by understanding the degree
to which the various packaging systems (a term that I use to include
GNU/Linux distributions) switch the KDE fork.  In my view where Debian
lands, if at all, is very influential.

I will inquire within pkgsrc about the KDE fork and intent to have our
Qt 5 packages track them.  I am guessing that it's meant to be just a
continuation of maintenance, for now, and thus quite compatible.

I think that (1) is the current primary question.  Choice (2) mostly
flows from the answer to (1), in that it's reasonable to target
5.15.2(release) but also test with 5.15.2.kde.x, and use .kde for
binaries on the theory that it has bugfixes.  It's also reasonable -- if
enough packaging systems move or provide the KDE fork -- to just say
that testing is only against that -- but qgis seems to support older Qt
anyway, and it would seem radical to demand a particular rev of 5.15 at
this point.

If (1) is decided in favor of the fork, then (3) seems reasonable.

(4) is a hard discussion that I think should be deferred a bit until we
see how the Free Software world's approach to Qt settles out.  It
reamains to be seen how that's going to go between extremes of being
content about the withdrawal of support and just moving to 6, and
deciding that qt's model wasn't such a good idea after all and that it's
best to use a truly Free fork or start to get away from it entirely.
Pretty obviously neither extreme is likely, but I have little confidence
in guesses about where we'll land.

Greg


signature.asc
Description: PGP signature
___
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 on Freenode

[Greg Troxel]

techdude1996  writes:

> I don't mean to be rude, but can we please move to the 21st century? (As I'm
> responding to a mailing list) IRC very dated and lacks a lot.

If you don't mean to be rude, then perhaps it would be good to address
things a little more evenhandedly, rather than using terms like 21st
century with an implicit claim that all older things are bad.

FWIW, I see IRC as entirely functional with lots of clients, for public
non-structured chat.

> There's an Unofficial QGIS Discord server  Discord Invite Link
>    (Currently, it's small due to lack of
> publicity) that could be more official, or an official one could be created. 
> Rocket Chat    is a FOSS, self-hostable option if you
> don't want to use Discord.

I think Free Software projects should decline to use proprietary
interaction platforms.

My impression is that people who both don't like IRC and care about Free
Software are tending to move to matrix, which is reasonably easily self
hostable.


signature.asc
Description: PGP signature
___
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] Release Cycle update

[Greg Troxel]

Marco Bernasocchi  writes:

I'm writing with my packager hat on (pkgsrc), mostly, although I'm also
a user.

> We think that adding release candidates would benefit the project a lot
> since we would not be shipping code that has not been tested at large and
> we would have a simple way to tell people that we're getting a new version
> ready and it is now time to test it heavily.

That's great.  The really hard part is getting people to test before a
release, and this will probably help.

> Release plan:
>
>- .0 packages will be called “release candidate” allowing us to improve
>expectation management and collect user feedback
>- during the .0 release candidate period, the release is first branched
>and master un-frozen to allow the next cycle development to start
>- The splash screen will include “release candidate”
>- .1 would be the first “proper” release

I don't think that naming plan is good, because it's contrary to what
everybody knows about release numbering.  3.20.0 is obviously a real
release to many, even if you say it isn't (and therefore it actually
isn't).

There's been a problem in the world of a proliferation of version
formats.  Long ago, GNU autotools had a great scheme where the release
leading up to 3.20 would be

3.19.80 alpha
3.19.81
3.19.90 beta
3.19.91

but it seems nobody uses this.  The great thing is that they sort
correctly.

The new scheme is to call

3.20a1
3.20a2
3.20b1
3.20b2
3.20b3
3.20rc1
3.20rc2

The advantage of using this is that it's really obvious (to those that
are used to release candidates in general) that rc1 is a release
candidate.  And, packaging systems have had to deal with this for
others, and using the exact same scheme means no special-case coding for
qgis.

When I can, I update pkgsrc locally to an rc (and don't publish it).
I'm doing this for two programs I'm an upstream maintainer of, and I
have often done it for postgis.  That means that I've tested the entire
source tarball to package path, and then run the package.  qgis is so
big, and I'm not as active, so I don't quite get to this.  But I think a
number of people will.

So really the only quibble I have is that if something is an RC, name it
with rcN, rather than declaring that qgis is going to use version
numbers to use what everybody else knows (without reading your
definition) mean something else.



As an aisde, a reason I would find this hard to deal with is that the
qgis data package format seems to change with every release and I've
seen the notion that e.g. if I'm working in 3.16.4 on something and I
open it with 3.20.0rc1 and change something trivial and save it, I won't
be able to open with 3.16.4.  I realize this would be hard but I would
like to see write support for the previous formats, with upgrade only
when requested.   I may be off base or out of date, in which case please
ignore me.   But I think it would be good to articulate and document how
to test new versions without messing up existing data.

Greg


signature.asc
Description: PGP signature
___
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] Raster with CC-0 license

[Greg Troxel]

I realize this is regional, but imagery as well as raster topo maps
published by the US government are in the public domain, which can
treated as matching CC-0.


signature.asc
Description: PGP signature
___
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] Stale bot and older requests/issues - possible enhancement

[Greg Troxel]

I am not a fan of a bugtracker pushing people to sponsored development
by spamming each issue with it.   It's perfectly reasonable to assign a
label that means basically "this issue appears legitimate but no one has
expressed interest in working on it", and make the pointer to either 1)
maybe you should write the code yourself (that has to be there!) or 2)
you migth wish to sponsor someone once in the top-level README that
explains the labels.


signature.asc
Description: PGP signature
___
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] Message to list

[Greg Troxel]

Hannah Wait  writes:

> I work at a land surveying company and have a question on QGIS and QField if 
> anyone can help with.
>
> We are currently looking at uploading the 'Survaid' data with accurate
> positioning and exporting as a shapefile with the attributes in to
> QGIS. Do you know if there is a way to get the higher accuracy of
> external GPS to feed into QField on our tablet at all?

QField is on my list of things to try, but I haven't yet.
(Unfortunately it is not on f-droid so I'll have to build it from
source.)

This query probably belongs on the QField mailinglist, but that appears
to be remarkably difficult to find.

On Android, I can see three approaches.

  I use Vespucci, which is an openstreetmap editor.  It has support for
  an external NMEA source, via a TCP connection.  One can put a phone in
  hotspot mode and have the external device (e.g. Ardusimple WiFi NTRIP
  Master with a simpleRTK2B F9P, and you are almost certainly using
  something higher end!) get RTCM3 data, and have Vespucci get the RTK
  solutions as high-precision NMEA.  This takes you out of GIS proper
  into OSM, which uses tags instead of layers, even though it's
  basically the same thing.

  Modify QField to have the same sort of feature as Vespucci.  You are
  apparently not the first to want this:
https://github.com/opengisch/QField/issues/536

  Use Android's "mocking" debug feature, which involves some program to
  talk to the external GNSSr and inject location into the system, so
  that programs see that location information.   I gather people do this
  with QField, from skimming their github repo.  See
https://qfield.org/docs/fieldwork/gps.html
  
Greg


signature.asc
Description: PGP signature
___
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-user] Phasing out 32-bit support in QGIS for

[Greg Troxel]

Marco Bernasocchi  writes:

> tl;dr QGIS will drop 32-bit support on Windows after the QGIS 3.16 release
> when we update our Qt dependencies to Qt 5.15.

Two questions from a packaging viewpoint (I help maintain the qgis entry
in pkgsrc):

  I am guessing that this "dropping 32-bit on Windows" is mostly if not
  entirely about project-built binaries, and does not mean that the
  source code will stop compiling on various CPU architectures.   I
  would expect a continued notion that qgis source code should not make
  assumptions about CPU architecture.

  I don't quite follow "update our dependencies to Qt 5.15".  This seems
  to be tied to Windows packaging in the announcement, but I think it's
  about declaring a requirement of 5.15 for building the source code,
  and then modifying the source code to use 5.15 interfaces and not use
  any deprecated interfaces, so that the code will be buildable also
  with Qt 6, which promises to supporting building any code which builds
  against 5.15 without deprecation warnings.  Is that right?
  


signature.asc
Description: PGP signature
___
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] QEP: Aggressive Dependency Bump for 3.18

[Greg Troxel]

Nyall Dawson  writes:

> Please see https://github.com/qgis/QGIS-Enhancement-Proposals/issues/197
> for a proposal to perform an aggressive dependency bump following the
> release of the QGIS 3.16 LTR version.
>
> The build dependency versions for QGIS have not been raised in many
> years, and as a consequence we are dragging around many thousands of
> lines of duplicate code designed to work around older dependency
> versions.
>
> It is proposed that for QGIS 3.18 we perform an aggressive dependency
> bump and remove support for many older, unsupported library versions.

I was fearing this to be really aggressive, but it seems that it will
mostly only impact "LTS", aka people that choose to run old software :-)

From the pkgsrc point of view, I don't see any problems.  We tend to be
slightly behind when there are reasons, but not to maintain versions
static for years.

I'm pretty sure you mean "proj 6 or later is ok" and "proj 5.x is NOT
ok" in which case that sounds good to me.  At this point it feels a bit
early to demand 7.   That said, I expect this to be the biggest issue in
practice.

For QT, I don't have any issue with 5.12 instead or even 5.15.  In
general I don't think what's available on LTS distributions should be
much of a guide, as LTS users should be using LTS qgis.

For compiler, C++17 is hard to parse into what it really means.  For
each C++nn, it seems that there are a number of language features and
that support for them comes in stages to gcc, so there are gcc versions
that mostly support the version, and then it takes a really recent gcc
to 100% support it.

I would like to see qgis be buidlable with gcc 7.   There is only one
thing in C++17 that isn't supported there:
  https://gcc.gnu.org/projects/cxx-status.html

so if you mean "C++17, with the caveat that gcc 7 is usable"

For clang, it looks like clang 5 will be needed, whereas before 3.4 was
ok.:
  http://clang.llvm.org/cxx_status.html


gcc 7 and clang 5 were both released in 2017, so that feels a bit
aggressive.

If you mean full-on C++17 and thus gcc 8 that ws released in 2018 and is
even more aggressive.

I am sensitive to compiler versions because upgrading a compiler in a
system is much harder than other things.   A system being released and
having a perhaps 3 year maintenance interval where people use it seems
reasonable - actually doing system upgrades is disruptive and people
often wait a bit to upgrade base, while keeping other things up to date,
even without intending to cross into LTS.

How much gain is there from allowing C++17, vs onlyC++14?  To me this is
the only questionable bump in terms of benefit/pain.


signature.asc
Description: PGP signature
___
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 build fails with cmake 3.18.2, NetBSD, quoting of $

[Greg Troxel]

Greg Troxel  writes:

> Peter Petrik  writes:
>
>> Hi,
>> looks like duplicate  of https://github.com/qgis/QGIS/pull/38103
>> I fixed it by using of ninja instead of make
>
> Are you saying:
>
>   qgis has code to change $ to $$ for quoting, and has for a long time
>
>   cmake 3.18 now quotes $ to $$, and thus we end up with area
>
>   This has nothing to do with NetBSD or BSD make
>
> ?
>
> If so, then I suppose that should be merged to LTR, and/or I should
> basically cherry-pick it into pkgsrc.

I commented in the PR, but after reading more, including some cmake
sources, I believe my three statements above are correct, that the
change in the PR is in 3.10.10.  3.10.10 builds  find in NetBSD/pkgsrc
with cmake 3.18.2.

Thanks again for the hint/pointer - that saved me a tremendous amount of
time.


  


signature.asc
Description: PGP signature
___
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 build fails with cmake 3.18.2, NetBSD, quoting of $

[Greg Troxel]

Peter Petrik  writes:

> Hi,
> looks like duplicate  of https://github.com/qgis/QGIS/pull/38103
> I fixed it by using of ninja instead of make

Are you saying:

  qgis has code to change $ to $$ for quoting, and has for a long time

  cmake 3.18 now quotes $ to $$, and thus we end up with area

  This has nothing to do with NetBSD or BSD make

?

If so, then I suppose that should be merged to LTR, and/or I should
basically cherry-pick it into pkgsrc.


signature.asc
Description: PGP signature
___
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 build fails with cmake 3.18.2, NetBSD, quoting of $

[Greg Troxel]

I co-maintain the pkgsrc entry for qgis (and also look after proj, gdal,
postgis).

pkgsrc uses gmake because there are file names with spaces (json help),
and there is some quoting problem with BSD make.  (Also because of the
present issue with $ quoting.)

pkgsrc currently has 3.10.7 (yes, I know I should update to 3.10.10),
which builds fine with cmake 3.17.3 on NetBSD, when qgis is built with
gmake.

With our current cmake 3.18.2 (or .1), the build fails because a
generated makefile:

  work/qgis-3.10.7/build/src/core/CMakeFiles/qgis_core.dir/build.make

escapes e.g. resources/function_help/json/$area to have four dollar signs:

  src/core/qgsexpression_texts.cpp: ../resources/function_help/json/area

rather than the two $ that gmake expects.  (However, BSD make, which we
don't use, wants 4, for complicated and perhaps not valid reasons.)

My working (but unsupported by reality) theory is that cmake is trying
to accomodate BSD make and overquoting $, but is doing so because it is
running on NetBSD, rather than because it knows BSD make will be used to
build.  However, I don't see this in the release notes.

So far there have not been reports of other programs not building, but
qgis is unusual in that it has files with $ in them.

I am looking for a minimal fix to patch qgis or cmake to make this
build.

Hints would be appreciated on the following subjects:

  cmake really did or didn't change quoting of $

  The extra quoting is or isn't something somehow done by qgis.

  The questions I really should have asked, if I understtood this
  better.

  This is fixed in 3.10.10 :-)

Thanks,
Greg


signature.asc
Description: PGP signature
___
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] using conda for development

[Greg Troxel]

Ari Meyer  writes:

> Matthias, WADR, your statement seems, at least on the surface, to indicate
> an incredibly fragile process.  How can you possibly maintain stability and
> reproducibility if the dependencies can be changed at will?

I can understand how you would say this, but I find your statement odd
from an open source development norms viewpoint.   It is entirely
typical for a project to specify a list of dependencies with a miniumu
version (because of API changes), with the notion that if built against
that version or later, all will be ok.  That leads to the application
being judged buggy, if it doesn't cope, and the dependency being judged
buggy, if it doesn't meet the interface specification.   Certainly
hard-core testing will be against particular versions.  The history of
open source projects is that usually things are ok with this fuzzy >=
binding.

In my little corner, qgis makes releases, and they are built within
pkgsrc, which means against whatever version is in pkgsrc that minute.
Aside from upstream instability of some packages, this is mostly ok.

I have only been using qgis the last month or two, but have been lurking
and thinking about packaging for much longer.  I am curious how many
documented cases of incompatibilitiies due to versions of something --
when the qgis build says both are acceptable -- there have been, and if
in hindsight the bug is in qgis or the dependency.
___
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] using conda for development

[Greg Troxel]

Nyall Dawson  writes:

> There's a related proposal at
> https://github.com/qgis/QGIS-Enhancement-Proposals/issues/179 --
> probably best to keep the discussion on that page.

Not really about the details of using conda but about the concept:

  conda's documentation says it runs on "Windows, macOS and Linux" but
  qgis also runs on at least NetBSD and almost certainly other BSDs.

  it seems that to build something, including qgis the requirement is
  that the things it depends on are present in some way that is found by
  the build.  People can choose to do that however they want, and it
  seems funny to me to impose a requirement.   If this is really "let's
  publish a conda config file so that people who want to do that can do
  less work", that's of course fine, but if it's more "if you don't have
  conda then you can't build qgis", that's something else.
___
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 and Qt 6: A proposal

[Greg Troxel]

Nyall Dawson  writes:

> On Mon, 6 Jul 2020 at 22:38, Greg Troxel  wrote:
>>
>> Bo Victor Thomsen  writes:
>>
>> > 3. I like the idea, that you can build QGIS with both the QT ver 5.x
>> >and QT ver 6.x in a (limited) time period. That gives the plugin
>> >developer some peace of mind, having both the "old" and the "new"
>> >QGIS as a testing ground before plugin release
>>
>> I like this too, but given many packaging systems and many reasons, I
>> see "limited" as being like a year and maybe more.  Basically it would
>> be nice if qgis worked on both until very few people had a reason to use
>> qt5, and I think that just means  sticking to the non-deprecated API in
>> 5.15.
>
> Actually I'd be perfectly fine if we start adding new features which
> rely on functionality added in Qt 6, so long as these are
> automatically disabled on the Qt 5 builds. We have precedent for this
> in the past -- when QGIS 3D was introduced it was only available if
> the Qt library version was sufficiently recent, and also when GeoPDF
> export was added we only enabled it for GDAL 3 builds.

That's fine with me from the packager perspective.  I wasn't thinking
about new features that are "#ifdef QT6".  I indeed meant not moving
existing things to require qt6.

Basically packaging systems get forced into choices by various things
and end up not being able to satisfy all of them.  So as long as qgis
still builds with 5.15 and that remains at least a mostly reasonable
choice for a while, that's fine.
___
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 and Qt 6: A proposal

[Greg Troxel]

Another thought is the spectre of "long term stable" OS releases.

In various projects, I run into people who choose to run old software
(otherwise known as "using a LTS distribution"), but at the same time
insist on compiling the most recent release of X, and they expect X to
build against old things.   I'm not a fan of this, but it seems to be a
signficant part of Linux culture.

So qgis will have to think about how long qgis will build:

  against older qt5 stable branches (5.12?)
  against qt5 5.15

because stopping that will more or less mean people that choose old
software can't easily run recent qgis (unless they use a secondary
packaging system like pkgsrc that builds it all).   I think this is
fine; if you want old, therefore the older qgis is fine.  But many
people want it both ways.

___
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 and Qt 6: A proposal

[Greg Troxel]

Bo Victor Thomsen  writes:

> 3. I like the idea, that you can build QGIS with both the QT ver 5.x
>and QT ver 6.x in a (limited) time period. That gives the plugin
>developer some peace of mind, having both the "old" and the "new"
>QGIS as a testing ground before plugin release

I like this too, but given many packaging systems and many reasons, I
see "limited" as being like a year and maybe more.  Basically it would
be nice if qgis worked on both until very few people had a reason to use
qt5, and I think that just means  sticking to the non-deprecated API in
5.15.

A really big question is how packaging systems are going to deal with
qt6.  With qt4->qt5, pkgsrc had qt4 and qt5 packages.   qt4 remains,
although less and less uses it.   I am pretty sure some useful code that
uses qt5 is going to take a really long time to build against qt6, and
thus qt5 is likely to remain for several years.  This leads to needing
to have qt6 packages, rather than updating qt5 to "qt5-6.0.0".

I epxect Debian and Fedora are going to add qt6 that can be installed
alongside qt5, rather than just updating the qt5 packages to qt6,
because replacing qt5 with qt6 would lead to removing all qt5-using
packages  that don't have a release that works with qt6.  Certainly I
expect pkgsrc to head that way, and it would be interesting to hear from
Debian, FC, FreeBSD ports, the various mac-oly packaging systems, etc.
___
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

[Greg Troxel]

Surely the code ought to all build on arm64 (and earmv7, sparc, sparc64,
RISC-V, and many others).  If not it needs fixing anyway.

(No disagreement with your points about CI and build servers.)

I suspect there will be a lot of aarch64 and RISC-V hardare in the open
source world over the next few years.
___
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-psc] Position on Qt wrt The QT Company announcements

[Greg Troxel]

Nyall Dawson  writes:

> 3. A community fork would likely end up being great for Qt (my
> opinion). It certainly had a huge positive impact on
> OpenOffice/LibreOffice. Qt is currently REALLY difficult for new
> contributors to contribute to, so it's possible a community driven
> fork with more of a collaborative focus would see a bunch of new
> contributors coming in. Certainly the talk on the Qt mailing lists
> over the last 1-2 years has shown a huge amount of dissatisfaction
> with the leadership and direction taken by the Qt Company, and
> complaints about how out of touch they are with their user's needs.

I think the CLA issue is a huge one, and I'm commenting only because you
didn't explicitly say "proprietary relicensing CLA".

I am uncomfortable with signing a CLA with an entity that is not a Free
Software charity (definitions vary by country, but the point is that
charities are legally obligated to act in the public interest).  I also
don't think that free software developers should have to grant
permission for proprietary relicensing.  While these views are certainly
not universal, I think they are reasonably mainstream.

Even among those who do not have conceptual objections, many would be
cautious about signing a formal agreement.  (I'd want to get legal
advice before doing that, and I certainly don't want to pay a lawyer in
order to give a company the right to engage in proprietary relicensing!)

If Qt were forked to continue as an Free Software project (as opposed to
a joint proprietary/Free project), then I would expect participation
from people who didn't before because of either a distaste for
proprietary relicensing or discomfort with a corporate CLA.

___
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] Why does QGIS frequently get flagged by Trend Micro?

[Greg Troxel]

"Moskovitz, Bob@DOC"  writes:

> Hello All,
>
> I've noticed that QGIS 3.10.2-2 (and previous versions) would crash and then 
> get flagged by Trend Micro with the following 2 "Security Threat":
>
>   *   TSC_GENCLEAN 
> https://www.trendmicro.com/vinfo/us/threat-encyclopedia/malware/TSC_GENCLEAN
>   *   Unauthorized File Encryption 
> https://www.trendmicro.com/vinfo/us/threat-encyclopedia/search/unauthorized%20file%20encryption
>
> I don't know if the crashes are caused by the Trend Micro, but it would be 
> great if I can figure out what QGIS is doing to trigger Trend.  Can anyone 
> tell me how these "Security Threats" are related to how QGIS works?

This question should be addressed to Trend Micro, to explain what it is
they are flagging, and why it is a legitimate complaint.  Software like
Trend Micro is almost always proprietary and opaque, so people other
than the company simply cannot answer questions like the one you are
asking.  I would not be surprised if it is some pattern-matching false
positive.
___
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] iOS prototyping

[Greg Troxel]

Paolo Cavallini  writes:

> thanks for this discussion. I'm also pretty sure getting a property
> transfer from all developers will be difficult if not impossible (quite
> a few devs even disappeared from the radar, not easy to find them again).
>
> A possible intermediate step would be to:
>
> * get the transfer of code property to QGIS.ORG only from those
> developers who are happy to do it

That makes sense, but wrapped up in that question is:

  what is the reciprocal covenant about future licensing that goes with
  the copyright assignment?

or perhaps you really mean "assignment with no reciprocal covenant at
all, from those who are happy to do it".

The FSF assignment form that my company executed long ago (for
contributions to GNU Radio) had a covenant to make the code available
under Free licenses (and I can't remember the exact details), plus a
grant back to the contributor of a license under copyright law.

This text is old, but is an example

  The Foundation promises that all distribution of the Work, or of any
  work "based on the Work," that takes place under the control of the
  Foundation or its assignees, shall be on terms that explicitly and
  perpetually permit anyone possessing a copy of the work to which the
  terms apply, and possessing accurate notice of these terms, to
  redistribute copies of the work to anyone on the same terms. These
  terms shall not restrict which members of the public copies may be
  distributed to. These terms shall not require a member of the public
  to pay any royalty to the Foundation or to anyone else for any
  permitted use of the work they apply to, or to communicate with the
  Foundation or its agents in any way either when redistribution is
  performed or on any other occasion.

> * ask a more specific question to others (e.g. are you willing to move
> from GPL2 to GPL3?).
>
> I think this is more feasible, will help building trust, will help
> moving forward, and will make it easier (less people to contact) to do
> further changes in the future.
___
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] iOS prototyping

[Greg Troxel]

Andreas Neumann  writes:

> Before we go to far with the discussion here, I would first ask all of
> the core devs if they really would like to do that. 
>
> Without an agreement in place, the code is owned by each contributor
> separately. I know of quite a few core devs who are not keen on ceding
> their copyright to QGIS.ORG, if the goal is to undermine the GPL
> license. 
>
> I am also not sure if QGIS.ORG is ready to prepare such an ownership
> agreement. 
>
> Personally, I fail to understand what the benefits are, if we go this
> route. On the contrary - I think we are risking to loose many core
> contributors if we do that. 

I'm a lurker who has not contributed to qgis, but someday might.  Within
pkgsrc.org, a multi-os multi-arch portable packaging system, I'm one of
the people that most frequently gets asked license questions.  I
maintain the geos/postgis entries in pkgsrc.

I have contributed to a number of open source projects -- but I tend to
find something else to do when I'm asked to sign any kind of CLA or
copyright assignment.

I think there are multiple things going on:

  How do people feel about accomodating Apple's ban on GPL software for
  the iOS app store?  People have talked about qgis having an exception,
  but nobody has brought up talking to Apple to get them to change their
  terms.  I suspect those who really believe in the GPL's purpose don't
  want to make an exception, and there will be enough such people that
  rewriting all their code is not sensible.

  Evolution of the license as the licensing landscape change.  If we are
  talking about changing GPL2 or later to GPL3 or later, that seems
  straightforward, and I think all it takes is for core to accept some
  nontrivial code that is GPL3 or later.  There is the serious question
  about not letting people copy/modify/redistribute under GPL2, but
  that's a group social question, not something that needs every
  contributor to sign off on.

  Change to permissive.  Perhaps because of wanting to accomodate Apple,
  or for other reasons, some may want a permissive license.  This is a
  huge cultural change, and I would expect a significant number of
  people would not be ok with this.

  Copyright assignment.  This opens up the fear of a change in license
  later (to permissive or to accomodate Apple's GPL ban), which leads to
  wanting to have terms in the assignment that constrain the future
  choice.  And it means asking people to sign copyright assignments
  before their code can be merged.  In my view, this alienates potential
  contributors.  So if qgis stays on the GPL "N or later" track, I don't
  see why this helps, and it will definitely hurt.
___
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] Adding default OSM backround maps

[Greg Troxel]

For context, I've only been lurking and intend to use QGIS when I get
time.  I have been an OSM mapper for 8 years.

Paolo Cavallini  writes:

> Il 21/03/2017 15:58, Jorge Gustavo Rocha ha scritto:
>
>> 1. The UserAgent is already a configurable feature in QGIS (under
>> Options/Network). Any user can change it, but we can propose another
>> default value.
>
> thanks - so, which could be the right default?

OSM data is freely usable, but there is a tile usage policy for the OSM
Foundation's servers:

  https://operations.osmfoundation.org/policies/tiles/

According to the policy, QGIS would probably need permission to offer
tiles from OSM servers.  The server admins might well be ok with this --
generally cooperation among Open Data and Free Software is great -- but
they are trying to serve tiles to the world without a big budget.

One of the guidelines is about user agent, which is aimed at less
configurable programs, to be able to identify and/or block things that
use too much server capacity.  So the notion of easily user-configure
UserAgent string sent to OSM tileservers should probably be discussed
with the OSM server admins.  I find configuration here strange; I would
expect the UserAgent string to be something that just looks like "QGIS
2.18".   But probably I have misunderstood.

Note that bulk downloading of tiles is not allowed.  If they are loaded
only when the user pans/zooms, that's ok.  But you can't prefetch a
large area to make that work faster or offline.  (See local rendering
commenta at the end.)

Another part of the usage policy is caching.  Clients must cache tiles
for at least 7 days by default.

I'm unclear if this discussion is only about using OSM as a base layer
within QGIS, or also extends to publishing created maps on the web such
that web users would load tiles.  Generally, OSM tileservers are
intended to support OSM itself, and for low-usage applications.  So it
might be that for publishing it would be good to ask people to check
that they've read the tile usage policy.


>> 2. The QGIS community is very much aware of OpenStreetMap. If we really
>> need to make our users more aware, does it make sense to add a new
>> button to QGIS to report map errors? (context dependent, when the
>> OpenStreetMap layer is shown) It would have the same functionality of
>> the notes in OpenStreetMap web interface.
>
> sounds good to me, and I assume also for OSM board

Yes, but as a mapper I would really like to see people sign up for an
account and have non-anonymous notes.  It's not that I need to know
their True Name, but two other things:

  An anonymous note cannot be used as the basis for editing, only to go
  check yourself, because the anonymous note writer has not necessarily
  agreed to the contributor terms and we don't know where the info came
  from (could be copied from another map).

  You can't ask for clarification.

Still, anonymous notes are useful, if one is local enough to be going by
or make a small detour at some point, or if the issue can be confirmed
by acceptably-licensed sources.

>> 3.1 On the "add layer" dialog, we can show the OpenStreetMap url (which
>> might change over time) and licenses (for data and tiles) taken from
>> settings or an (external) resource. We can make this not hard coded, to
>> be modified easily, without upgrading QGIS. We can also check if the
>> service is enabled for us, before allow users to add that layer (related
>> with 4.).
>
> sounds good

I am guessing you have some new-layer database which is kept fresh, and
enabling QGIS as a project to disable/change the OSM layer if there are
issues sounds good.  (I realize nothing stops anyone from doing
anything, but the point is to be able to protect OSM servers from large
numbers of users of a program who did not actually evaluate the
decision.)

>> 3.2 When the tiles are used in the composer or on the web client, we can
>> not enforce an attribution string. We might add or suggest it, but users
>> should be free the create and edit the attributions. It the
>> responsibility of the user, not a QGIS responsibility.
>
> sounds good to me, have to check with OSM

Legally, you may well be right.

Socially, if you have a facility to add OSM, then by default, adequate
attribution should be added, so that someone who does not understand how
to set up attribution or does not understand that they must will end up
doing thte right thing.

It's fairly frequent for OSM people to come across unattributed use and
ask for correction.  So I think the OSM community would appreciate it if
by default this came out right.  Not adding attribution by default is
sort of like offering to download a copy of QGIS'S source code with all
the copyright statements removed :-)

The fact that someone can remove it intentionally is not your
fault/problem.

>> 4. We have to handle when tiles are not loading, either because there
>> are network problems, server busy, etc. We can customize the user's

Re: [Qgis-developer] issue move to gh stalled

[Greg Troxel]

Sandro Santilli  writes:

> On Mon, Aug 29, 2016 at 03:37:37PM +0200, Luigi Pirelli wrote:
>
>> I tried again... before logging to osgeo wiki to be sure about my
>> credentials... and than to osgeo gitlab, but... no way :(
>
> Note that the OSGeo Wiki does *NOT* use the LDAP credentials.
> What you could try is logging into a trac instance (where you could
> report the issue), or into Gogs (https://git.osgeo.org/gogs)

FWIW, I have had an osgeo account (trac for postgis etc.) for a long
time, and I was able to log into the gitlab instance.

Also, with respect to migration, I think free software orgs self-hosting
is a good thing, but using gitlab hosting seems nice because it's free
software (unlike github) and most importabtly because gitlab is said to
have export/import so one has the option to switch to self-hosting
later.


signature.asc
Description: PGP signature
___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
List info: http://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: http://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [Qgis-developer] Plugin licence

[Greg Troxel]

"Vincent Picavet (ml)"  writes:

> Hello,
>
> On 25/05/2016 11:42, Tom Chadwin wrote:
>> Vincent Picavet (ml) wrote
>>> I may be wrong, but if qgis2web is like qgis2three, it generates
>>> projects containing OL3 or leaflet code ?
>>> In this case, there is no code link between the Python plugin and
>>> Leaflet nor OL3
>> 
>> Yes, this is how it works. However, the code it generates *does* link to the
>> other libraries in code. I think it would therefore be egregious to say no
>> link exists between the Python code and the third-party JS libraries.
>
> The term "link" is very subtle, and is key to the issue here. There is
> absolutely no "link" in the sense of the GPL between your Python module
> and the code you generate. The generated code can be considered as data
> for your plugin ( template, replacement values).

Programmers focus on link, but it's really not the point.  The question
in copyright law is "derived work" or "a work based on the program".  So
the typical view among hard-core licensing nerds is that the source of a
plugin -- because it is fundamentally an extension to the main program
-- is a derived work.  Thus one needs permission from the original
copyright holders to distribute it.  The GPL only grants such permission
if the plugin is licensed under the GPL.

As to being derived works of multiple things at once, yes, that may well
be true.  One needs permission from all.  That doesn't mean matching
license.  It means that given the plugin license, the copyright holders
of all underlying programs must be willing to grant permission.  For BSD
licenses, there is no issue (other than preserving the notice, more or
less).


signature.asc
Description: PGP signature
___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
List info: http://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: http://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [Qgis-developer] Why is ellipsoidal calculation tied to project OTF setting?

[Greg Troxel]

"Blumentrath, Stefan"  writes:

> I am no geodesist, so I do not have the expertise to judge which type
> of measure should be favored / the default. But I would expect the
> other packages have their reasons for using Cartesian
> measurements... Given that the code for the ellipsoidal measurement is
> actually copied from GRASS, which mostly does not use it, I – as a lay
> person in this matter – would be a bit concerned to have an
> ellipsoidal area/distance measure as the default...

I'm not an actual geodesist either, just someone who has read too many
books.

I do not understand the notion of tying ellipsoidal distance
("geodesic", presumably) to whether reproject is going on.  If the data
is in a datum, then an ellipsoid is known and the points can be reduced
to the ellipsoid (to remove the effects of longer distance from
elevation) and then the distance along the ellipsoid computed.  In
geodetic survyeing, this seems to be the standard approach.

I'm unclear on what "cartesian" means.  Presumably that's an
approximation to ellipsoidal distance assuming small distances from some
point.   That's an ok thing to show but it is an approximation.  Another
value to show is the distance computed in some projected coordinate
system, like UTM.  But that's different than an actual distance.

For computing ellipsoidal distance, the best open source code these days
seems to be from geographiclib, which is now in proj.

It seems to me that if coordinates are in some lat/long system,
ellipsoidal distnace/area is the right default.  If in UTM, then in UTM
space seems right.  But it should be clear which is which, and the user
should be able to get the other, or at least to get ellipsoidal when in
UTM or some other projected coordinates.




signature.asc
Description: PGP signature
___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
List info: http://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: http://lists.osgeo.org/mailman/listinfo/qgis-developer