Re: [QGIS-Developer] "Show selected features" is very slow in recent versions

2020-07-28 Thread Anita Graser 


On 28.07.2020 22:15, Alessandro Pasotti wrote:

Hi,

Seems pretty bad, please file a ticket.


Thanks, Alessandro!

Done: https://github.com/qgis/QGIS/issues/38018

Anita




On Tue, Jul 28, 2020, 21:45 Anita Graser mailto:anitagra...@gmx.at>> wrote:

Hi,

There seems to be a performance regression concerning "Show
selected features" in the attribute table of recent QGIS versions.
(See also
https://twitter.com/DrChrisGeoSci/status/1288120808951312389)

I've tested this with the Natural Earth dataset
ne_10m_populated_places layer. The expression "NAME" like 'A%' is
close to instantaneous but switching to "Show selected features"
takes forever and freezes QGIS master and 3.14 in a way that looks
like it crashed (i.e. "not responding" on Windows).

In 3.4 "Show selected features" is much faster. There's no freeze.

Is this a known issue or should I open a ticket?

Regards,

Anita

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

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

Re: [QGIS-Developer] Raster layers: average resampling disappeared

2020-07-28 Thread Andreas Neumann 

Hi Even,

Thanks for confirming this.

Andreas

Am 28.07.20 um 18:23 schrieb Even Rouault:


On mardi 28 juillet 2020 17:06:05 CEST Andreas Neumann wrote:

> Thanks for sharing this discussion.

>

> So when you load an old project in QGIS master, the average method would

> be replaced with bilinear now?

>

> Is "bilinear" the closest method to the previous "average"?

This is just a label change. "average" was actually implemented by 
bilinear.


Even

--

Spatialys - Geospatial professional services

http://www.spatialys.com

___
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] "Show selected features" is very slow in recent versions

2020-07-28 Thread Alessandro Pasotti 
Hi,

Seems pretty bad, please file a ticket.

On Tue, Jul 28, 2020, 21:45 Anita Graser  wrote:

> Hi,
>
> There seems to be a performance regression concerning "Show selected
> features" in the attribute table of recent QGIS versions. (See also
> https://twitter.com/DrChrisGeoSci/status/1288120808951312389)
>
> I've tested this with the Natural Earth dataset ne_10m_populated_places
> layer. The expression "NAME" like 'A%' is close to instantaneous but
> switching to "Show selected features" takes forever and freezes QGIS master
> and 3.14 in a way that looks like it crashed (i.e. "not responding" on
> Windows).
>
> In 3.4 "Show selected features" is much faster. There's no freeze.
>
> Is this a known issue or should I open a ticket?
>
> Regards,
>
> Anita
>
> ___
> QGIS-Developer mailing list
> QGIS-Developer@lists.osgeo.org
> List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
> Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
___
QGIS-Developer mailing list
QGIS-Developer@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer

[QGIS-Developer] "Show selected features" is very slow in recent versions

2020-07-28 Thread Anita Graser 

Hi,

There seems to be a performance regression concerning "Show selected
features" in the attribute table of recent QGIS versions. (See also
https://twitter.com/DrChrisGeoSci/status/1288120808951312389)

I've tested this with the Natural Earth dataset ne_10m_populated_places
layer. The expression "NAME" like 'A%' is close to instantaneous but
switching to "Show selected features" takes forever and freezes QGIS
master and 3.14 in a way that looks like it crashed (i.e. "not
responding" on Windows).

In 3.4 "Show selected features" is much faster. There's no freeze.

Is this a known issue or should I open a ticket?

Regards,

Anita

___
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 layers: average resampling disappeared

2020-07-28 Thread Even Rouault 
On mardi 28 juillet 2020 17:06:05 CEST Andreas Neumann wrote:
> Thanks for sharing this discussion.
> 
> So when you load an old project in QGIS master, the average method would
> be replaced with bilinear now?
> 
> Is "bilinear" the closest method to the previous "average"?

This is just a label change. "average" was actually implemented by bilinear.

Even

-- 
Spatialys - Geospatial professional services
http://www.spatialys.com
___
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 layers: average resampling disappeared

2020-07-28 Thread Andreas Neumann 
Thanks for sharing this discussion. 


So when you load an old project in QGIS master, the average method would
be replaced with bilinear now? 

Is "bilinear" the closest method to the previous "average"? 


On 2020-07-28 16:55, uclaros wrote:


You can have a look at the discussion at
https://github.com/qgis/QGIS/pull/37044

--
Sent from: http://osgeo-org.1560.x6.nabble.com/QGIS-Developer-f4099106.html
___
QGIS-Developer mailing list
QGIS-Developer@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer___
QGIS-Developer mailing list
QGIS-Developer@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [QGIS-Developer] Raster layers: average resampling disappeared

2020-07-28 Thread uclaros 
You can have a look at the discussion at
https://github.com/qgis/QGIS/pull/37044



--
Sent from: http://osgeo-org.1560.x6.nabble.com/QGIS-Developer-f4099106.html
___
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] Raster layers: average resampling disappeared

2020-07-28 Thread Andreas Neumann 
Hi, 


In QGIS master, when symbolizing raster layers, the "average" resampling
method disappeared and is now replaced by nearest, bilinear and cubic
alternatives. 

Anyone knows why "average" disappeared? 

Here a screenshot of 3.10: 

and here from master: 

Could we get the "average" method back for zooming out? 

Thanks, 


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

Re: [QGIS-Developer] SVG icons in QGIS

2020-07-28 Thread Andreas Neumann 

And in the SVG param primer, you can see examples of adjustable text in
 elements (e.g. buttons, icons, etc.): 

https://www.w3.org/TR/SVGParamPrimer/#Examples 


Given that we already have the param mechanism in QGIS, it would fell
natural to extend it to text as well. 


And - if we really want it - I think there is a fair chance to get
Inkscape to implement SVG params as well. They also implemented some SVG
extensions that unfortunately didn't make it into the browser, because
the browser companies blocked them during the standardization process. 


It is one of the advantages of XML (and SVG in that respect), that you
can extend with your own extensions. 

Andreas 


On 2020-07-28 10:46, Andreas Neumann wrote:

Hi Régis, 

In general - you are right - but the problem with standards it that they are often ignored. Browser developer companies (like Google) basically ignore 80% of the W3C standards and just implement what they want. I was involved with SVG standardization a decade ago  - and I have to say - it was a big disappointment to see what the big companies did with standards - even if it were their own employees who worked on the standards documents. 

The SVG param specification is in "working draft" stage - it is from W3C, not an invention by QGIS - but in my opinion, it is much easier to use than the i18n section that you quote. And I don't think it is implemented in any browser or authoring system (like Inkscape, Illustrator, etc.) 

See https://www.w3.org/TR/SVGParam/#AdaptTextToUse 

Adapt text in an icon or button is exactly a use case in the SVG param specification (working draft). 

Andreas 

On 2020-07-28 10:15, Régis Haubourg wrote: 

Hi,  
I think we should better follow the standard for internationalizing instead of progressively making a proprietary format.  
See https://www.w3.org/TR/SVGTiny12/i18n.html 
Cheers! 

Le mar. 28 juil. 2020 à 09:57, Andreas Neumann  a écrit : 

Hi all, 

I am only loosely following this discussion. 

But about the internationalization: couldn't we use the same param - mechanism we already have for fill-color, stroke-color, opacity, etc. and extend it to the content of  elements? 

That would solve internationalization and would also be usefuly for dynamic text in icons anyway - there might be some use cases for this even without internationalization. 

Just an idea, 

Andreas 

On 2020-07-28 02:39, Nyall Dawson wrote: 
On Mon, 27 Jul 2020 at 21:57, Jonathan Moules
 wrote: 
Hi List,


The more I look at the current SVG icons, the more I'm thinking it
really needs some TLC (Tender Loving Care). As far as I can tell, icons
are categorised by the directory they're in, so if you want an icon to
appear in two categories, you put the icon in there twice... and so
that's just what has happened! I suspect the current set has simply
accreted over time. 
For reference: I'm totally in agreement that we need to improve the

DEFAULT set of svg files, and that the resource sharing plugin isn't
the best solution here. It's a great solution for some use cases, but
we need to improve the out-of-the-box experience in this regard and
that means extending the default set.

My thoughts:
* Move the svg's into a single directory. (Though would break any
current projects symbology using them I guess?) 
Yes -- we CAN'T do this. What we've got now has to stay, in its

current structure, and without renaming.

* Use a metadata file to categorise them, so you get a list of
categories as now and a single symbol can be in multiple categories. 
We could potentially add tags to the svg files themselves to add this

information.

* Add a search feature so the user can quickly find "museum" without
having to guess where it has been categorised. 
Big +1 to this. Especially if we also add search by tag support!


* Clean up the current symbols by removing duplicates. 
Again, we can't do this without risking breaking people's existing

projects (which is off-limits!)

* Add the font-awesome symbols (per my thread on the User List) to fill
in the gaps and flesh out the collection. As a bonus, it comes with
metadata for categories and search terms (YAML files).

* bonus - metadata is internationalised so "museo" (IT), "muzeu" (RO),
etc would also work for finding that museum.

Thoughts? 
Sounds good to me! To clarify -- are you volunteering to lead this effort?


Nyall

Cheers,
Jonathan

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


___
QGIS-Developer mailing list
QGIS-Developer@lists.osgeo.org
List info:

Re: [QGIS-Developer] SVG icons in QGIS

2020-07-28 Thread Andreas Neumann 
Hi Régis, 


In general - you are right - but the problem with standards it that they
are often ignored. Browser developer companies (like Google) basically
ignore 80% of the W3C standards and just implement what they want. I was
involved with SVG standardization a decade ago  - and I have to say - it
was a big disappointment to see what the big companies did with
standards - even if it were their own employees who worked on the
standards documents. 


The SVG param specification is in "working draft" stage - it is from
W3C, not an invention by QGIS - but in my opinion, it is much easier to
use than the i18n section that you quote. And I don't think it is
implemented in any browser or authoring system (like Inkscape,
Illustrator, etc.) 

See https://www.w3.org/TR/SVGParam/#AdaptTextToUse 


Adapt text in an icon or button is exactly a use case in the SVG param
specification (working draft). 

Andreas 


On 2020-07-28 10:15, Régis Haubourg wrote:

Hi,  
I think we should better follow the standard for internationalizing instead of progressively making a proprietary format.  
See https://www.w3.org/TR/SVGTiny12/i18n.html 
Cheers! 

Le mar. 28 juil. 2020 à 09:57, Andreas Neumann  a écrit : 

Hi all, 

I am only loosely following this discussion. 

But about the internationalization: couldn't we use the same param - mechanism we already have for fill-color, stroke-color, opacity, etc. and extend it to the content of  elements? 

That would solve internationalization and would also be usefuly for dynamic text in icons anyway - there might be some use cases for this even without internationalization. 

Just an idea, 

Andreas 

On 2020-07-28 02:39, Nyall Dawson wrote: 
On Mon, 27 Jul 2020 at 21:57, Jonathan Moules
 wrote: 
Hi List,


The more I look at the current SVG icons, the more I'm thinking it
really needs some TLC (Tender Loving Care). As far as I can tell, icons
are categorised by the directory they're in, so if you want an icon to
appear in two categories, you put the icon in there twice... and so
that's just what has happened! I suspect the current set has simply
accreted over time. 
For reference: I'm totally in agreement that we need to improve the

DEFAULT set of svg files, and that the resource sharing plugin isn't
the best solution here. It's a great solution for some use cases, but
we need to improve the out-of-the-box experience in this regard and
that means extending the default set.

My thoughts:
* Move the svg's into a single directory. (Though would break any
current projects symbology using them I guess?) 
Yes -- we CAN'T do this. What we've got now has to stay, in its

current structure, and without renaming.

* Use a metadata file to categorise them, so you get a list of
categories as now and a single symbol can be in multiple categories. 
We could potentially add tags to the svg files themselves to add this

information.

* Add a search feature so the user can quickly find "museum" without
having to guess where it has been categorised. 
Big +1 to this. Especially if we also add search by tag support!


* Clean up the current symbols by removing duplicates. 
Again, we can't do this without risking breaking people's existing

projects (which is off-limits!)

* Add the font-awesome symbols (per my thread on the User List) to fill
in the gaps and flesh out the collection. As a bonus, it comes with
metadata for categories and search terms (YAML files).

* bonus - metadata is internationalised so "museo" (IT), "muzeu" (RO),
etc would also work for finding that museum.

Thoughts? 
Sounds good to me! To clarify -- are you volunteering to lead this effort?


Nyall

Cheers,
Jonathan

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


___
QGIS-Developer mailing list
QGIS-Developer@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer___
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] SVG icons in QGIS

2020-07-28 Thread Régis Haubourg 
Hi,
I think we should better follow the standard for internationalizing instead
of progressively making a proprietary format.
See https://www.w3.org/TR/SVGTiny12/i18n.html
Cheers!

Le mar. 28 juil. 2020 à 09:57, Andreas Neumann  a
écrit :

> Hi all,
>
> I am only loosely following this discussion.
>
> But about the internationalization: couldn't we use the same param -
> mechanism we already have for fill-color, stroke-color, opacity, etc. and
> extend it to the content of  elements?
>
> That would solve internationalization and would also be usefuly for
> dynamic text in icons anyway - there might be some use cases for this even
> without internationalization.
>
> Just an idea,
>
> Andreas
>
> On 2020-07-28 02:39, Nyall Dawson wrote:
>
> On Mon, 27 Jul 2020 at 21:57, Jonathan Moules
>  wrote:
>
>
> Hi List,
>
> The more I look at the current SVG icons, the more I'm thinking it
> really needs some TLC (Tender Loving Care). As far as I can tell, icons
> are categorised by the directory they're in, so if you want an icon to
> appear in two categories, you put the icon in there twice... and so
> that's just what has happened! I suspect the current set has simply
> accreted over time.
>
>
> For reference: I'm totally in agreement that we need to improve the
> DEFAULT set of svg files, and that the resource sharing plugin isn't
> the best solution here. It's a great solution for some use cases, but
> we need to improve the out-of-the-box experience in this regard and
> that means extending the default set.
>
> My thoughts:
> * Move the svg's into a single directory. (Though would break any
> current projects symbology using them I guess?)
>
>
> Yes -- we CAN'T do this. What we've got now has to stay, in its
> current structure, and without renaming.
>
> * Use a metadata file to categorise them, so you get a list of
> categories as now and a single symbol can be in multiple categories.
>
>
> We could potentially add tags to the svg files themselves to add this
> information.
>
> * Add a search feature so the user can quickly find "museum" without
> having to guess where it has been categorised.
>
>
> Big +1 to this. Especially if we also add search by tag support!
>
> * Clean up the current symbols by removing duplicates.
>
>
> Again, we can't do this without risking breaking people's existing
> projects (which is off-limits!)
>
> * Add the font-awesome symbols (per my thread on the User List) to fill
> in the gaps and flesh out the collection. As a bonus, it comes with
> metadata for categories and search terms (YAML files).
>
> * bonus - metadata is internationalised so "museo" (IT), "muzeu" (RO),
> etc would also work for finding that museum.
>
> Thoughts?
>
>
> Sounds good to me! To clarify -- are you volunteering to lead this effort?
>
> Nyall
>
>
> Cheers,
> Jonathan
>
>
> ___
> QGIS-Developer mailing list
> QGIS-Developer@lists.osgeo.org
> List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
> Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
>
> ___
> QGIS-Developer mailing list
> QGIS-Developer@lists.osgeo.org
> List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
> Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
>
>
> ___
> QGIS-Developer mailing list
> QGIS-Developer@lists.osgeo.org
> List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
> Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
___
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] SVG icons in QGIS

2020-07-28 Thread Andreas Neumann 
Hi all, 

I am only loosely following this discussion. 


But about the internationalization: couldn't we use the same param -
mechanism we already have for fill-color, stroke-color, opacity, etc.
and extend it to the content of  elements? 


That would solve internationalization and would also be usefuly for
dynamic text in icons anyway - there might be some use cases for this
even without internationalization. 

Just an idea, 

Andreas 


On 2020-07-28 02:39, Nyall Dawson wrote:


On Mon, 27 Jul 2020 at 21:57, Jonathan Moules
 wrote: 


Hi List,

The more I look at the current SVG icons, the more I'm thinking it
really needs some TLC (Tender Loving Care). As far as I can tell, icons
are categorised by the directory they're in, so if you want an icon to
appear in two categories, you put the icon in there twice... and so
that's just what has happened! I suspect the current set has simply
accreted over time.


For reference: I'm totally in agreement that we need to improve the
DEFAULT set of svg files, and that the resource sharing plugin isn't
the best solution here. It's a great solution for some use cases, but
we need to improve the out-of-the-box experience in this regard and
that means extending the default set.


My thoughts:
* Move the svg's into a single directory. (Though would break any
current projects symbology using them I guess?)


Yes -- we CAN'T do this. What we've got now has to stay, in its
current structure, and without renaming.


* Use a metadata file to categorise them, so you get a list of
categories as now and a single symbol can be in multiple categories.


We could potentially add tags to the svg files themselves to add this
information.


* Add a search feature so the user can quickly find "museum" without
having to guess where it has been categorised.


Big +1 to this. Especially if we also add search by tag support!


* Clean up the current symbols by removing duplicates.


Again, we can't do this without risking breaking people's existing
projects (which is off-limits!)


* Add the font-awesome symbols (per my thread on the User List) to fill
in the gaps and flesh out the collection. As a bonus, it comes with
metadata for categories and search terms (YAML files).

* bonus - metadata is internationalised so "museo" (IT), "muzeu" (RO),
etc would also work for finding that museum.

Thoughts?


Sounds good to me! To clarify -- are you volunteering to lead this effort?

Nyall


Cheers,
Jonathan

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

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

Re: [QGIS-Developer] SVG icons in QGIS

2020-07-28 Thread Raymond Nijssen 




On 28-07-2020 02:44, Nyall Dawson wrote:

Oh, also they'd need to be "parameterised", so that users can set the
fill/stroke color, opacity and stroke width from within QGIS.


I've made some quick and dirty scripts in the past to add these tags to 
sets of svg symbols. If needed I can help with it.


https://github.com/IFRCGo/IFRC-Icons/blob/master/OCHA_Icons_2018/scripts/convert_to_qgis.py

Raymond
___
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] Deploying 3.10.8 LTR on Debian 10

2020-07-28 Thread Patrick Dunford 
OK so comparing dependencies has not found any that appear significant. 
Only differences found were in a couple of OpenJDK packages.


Methodology:

1. Create a list of packages and versions from the entire system using 
dpkg-query:


    dpkg-query -W -f='${binary:Package}|${Version}\n' >pkglist.txt

2. Compare two package lists using this Python script:

# pkgcheck.py
# compare package lists and version details

# declarations
import argparse

# set up command line argument parser
parser = argparse.ArgumentParser(prog='pkgcheck')
parser.add_argument('firstfile')
parser.add_argument('secondfile')

# get arguments
argList = sys.argv[1:]  # drop the script 
name parameter

args = parser.parse_args(argList)
firstFile = args.firstfile
secondFile = args.secondfile

# read files as CSV
firstCSV = open(firstFile, mode = 'r')
firstPkgs = firstCSV.readlines()
secondCSV = open(secondFile, mode = 'r')
secondPkgs = secondCSV.readlines()
outFile = open('pkgcheck.txt','w+')
# first iteration with each line of firstPkgs look up in secondPkgs and 
compare

print(firstFile + " >< " + secondFile)
for firstPkg in firstPkgs:
    firstLine = firstPkg.split('|')
    firstName = firstLine[0].strip('\n')
    firstVersion = firstLine[1].strip('\n')
    firstFound = False
    for secondPkg in secondPkgs:
    secondLine = secondPkg.split('|')
    secondName = secondLine[0].strip('\n')
    secondVersion = secondLine[1].strip('\n')
    if firstName == secondName:
    firstFound = True
    if firstVersion <> secondVersion:
    outFile.write("Version Mismatch In Second: " + 
firstFile + ":: " + firstName + "::" + firstVersion + " <> " + 
secondFile + "::" + secondName + "::" + secondVersion + '\n')

    if firstFound == False:
    outFile.write("Package Missing in Second: " + firstFile 
+ " :: " + firstName + " :: " + firstVersion + "\n")
# second iteration with each line of secondPkgs look up in firstPkgs and 
compare

print(secondFile + " >< " + firstFile)
for secondPkg in secondPkgs:
    secondLine = secondPkg.split('|')
    secondName = secondLine[0].strip('\n')
    secondVersion = secondLine[1].strip('\n')
    secondFound = False
    for firstPkg in firstPkgs:
    firstLine = firstPkg.split('|')
    firstName = firstLine[0].strip('\n')
    firstVersion = firstLine[1].strip('\n')
    if firstName == secondName:
    secondFound = True
    if firstVersion <> secondVersion:
    outFile.write("Version Mismatch In First: "  + 
secondFile + ":: " + secondName + "::" + secondVersion + " <> " + 
firstFile + "::" + firstName + "::" + firstVersion + "\n")

    if secondFound == False:
    outFile.write("Package Missing In First: " + secondFile + ":: " 
+ secondName + "::" + secondVersion + "\n")


The only version mismatches found were

openjdk-11-jre:amd64 11.0.8+10-1~deb10u1 <> openjdk-11-jre:amd64 
11.0.7+10-3~deb10u1


openjdk-11-jre-headless:amd64 11.0.8+10-1~deb10u1 <> 
openjdk-11-jre-headless:amd64 11.0.7+10-3~deb10u1



___
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