Script 'mail_helper' called by obssrc
Hello community,

here is the log from the commit of package python-zeroconf for openSUSE:Factory 
checked in at 2021-08-18 08:56:14
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Comparing /work/SRC/openSUSE:Factory/python-zeroconf (Old)
 and      /work/SRC/openSUSE:Factory/.python-zeroconf.new.1899 (New)
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

Package is "python-zeroconf"

Wed Aug 18 08:56:14 2021 rev:22 rq:912684 version:0.35.1

Changes:
--------
--- /work/SRC/openSUSE:Factory/python-zeroconf/python-zeroconf.changes  
2021-06-05 23:32:08.080500834 +0200
+++ 
/work/SRC/openSUSE:Factory/.python-zeroconf.new.1899/python-zeroconf.changes    
    2021-08-18 08:57:05.810891310 +0200
@@ -1,0 +2,370 @@
+Mon Aug 16 01:39:16 UTC 2021 - Fusion Future <[email protected]>
+
+- Update to 0.35.1:
+  * Only reschedule types if the send next time changes (#958)
+    @bdraco
+  * When the PTR response was seen again, the timer was being
+    canceled and rescheduled even if the timer was for the same
+    time. While this did not cause any breakage, it is quite
+    inefficient.
+  * Cache DNS record and question hashes (#960) @bdraco
+  * The hash was being recalculated every time the object was
+    being used in a set or dict. Since the hashes are effectively
+    immutable, we only calculate them once now.
+- Changes from 0.35.0:
+  * Reduced chance of accidental synchronization of ServiceInfo
+    requests (#955) @bdraco
+  * Sort aggregated responses to increase chance of name compression
+    (#954) @bdraco
+  Technically backwards incompatible:
+    * Send unicast replies on the same socket the query was received
+      (#952) @bdraco
+    * When replying to a QU question, we do not know if the sending
+      host is reachable from all of the sending sockets. We now
+      avoid this problem by replying via the receiving socket. This
+      was the existing behavior when InterfaceChoice.Default is set.
+    * This change extends the unicast relay behavior to used with
+      InterfaceChoice.Default to apply when InterfaceChoice.All
+      or interfaces are explicitly passed when instantiating a
+      Zeroconf instance.
+    * Fixes #951
+- Changes from 0.34.3:
+  * Fix sending immediate multicast responses (#949) @bdraco
+- Changes from 0.34.2:
+  * Coalesce aggregated multicast answers (#945) @bdraco
+  * When the random delay is shorter than the last scheduled
+    response, answers are now added to the same outgoing time group.
+  * This reduces traffic when we already know we will be sending
+    a group of answers inside the random delay window described
+    in datatracker.ietf.org/doc/html/rfc6762#section-6.3
+  * Ensure ServiceInfo requests can be answered inside the default
+    timeout with network protection (#946) @bdraco
+  * Adjust the time windows to ensure responses that have triggered
+    the protection against against excessive packet flooding due to
+    software bugs or malicious attack described in RFC6762 section
+    6 can respond in under 1350ms to ensure ServiceInfo can ask
+    two questions within the default timeout of 3000ms
+- Changes from 0.34.1:
+  * Ensure multicast aggregation sends responses within 620ms
+    (#942) @bdraco
+  * Responses that trigger the protection against against
+    excessive packet flooding due to software bugs or malicious
+    attack described in RFC6762 section 6 could cause the multicast
+    aggregation response to be delayed longer than 620ms (The maximum
+    random delay of 120ms and 500ms additional for aggregation).
+  * Only responses that trigger the protection are delayed longer
+    than 620ms
+- Changes from 0.34.0:
+  * Implemented Multicast Response Aggregation (#940) @bdraco
+  * Responses are now aggregated when possible per rules in RFC6762
+    section 6.4
+  * Responses that trigger the protection against against
+    excessive packet flooding due to software bugs or malicious
+    attack described in RFC6762 section 6 are delayed instead of
+    discarding as it was causing responders that implement Passive
+    Observation Of Failures (POOF) to evict the records.
+  * Probe responses are now always sent immediately as there were
+    cases where they would fail to be answered in time to defend
+    a name.
+- Changes from 0.33.4:
+  * Ensure zeroconf can be loaded when the system disables IPv6
+    (#933) @che0
+- Changes from 0.33.3:
+  * Added support for forward dns compression pointers (#934) @bdraco
+  * Provide sockname when logging a protocol error (#935) @bdraco
+- Changes from 0.33.2:
+  * Handle duplicate goodbye answers in the same packet (#928)
+    @bdraco
+  * Solves an exception being thrown when we tried to remove the
+    known answer from the cache when the second goodbye answer in
+    the same packet was processed
+  * Fixed #926
+  * Skip ipv6 interfaces that return ENODEV (#930) @bdraco
+- Changes from 0.33.1:
+  * Version number change only with less restrictive directory
+    permissions
+  * Fixed #923
+- Changes from 0.33.0:
+  This release eliminates all threading locks as all non-threadsafe
+  operations now happen in the event loop.
+  * Let connection_lost close the underlying socket (#918) @bdraco
+  * The socket was closed during shutdown before asyncio's
+    connection_lost handler had a chance to close it which resulted
+    in a traceback on windows.
+  * Fixed #917
+  Technically backwards incompatible:
+    * Removed duplicate unregister_all_services code (#910) @bdraco
+    * Calling Zeroconf.close from same asyncio event loop zeroconf
+      is running in will now skip unregister_all_services and log
+      a warning as this a blocking operation and is not async safe
+      and never has been.
+    * Use AsyncZeroconf instead, or for legacy code call
+      async_unregister_all_services before Zeroconf.close
+- Changes from 0.32.1:
+  * Increased timeout in ServiceInfo.request to handle loaded systems
+    (#895) @bdraco
+  * It can take a few seconds for a loaded system to run the
+    async_request coroutine when the event loop is busy, or the
+    system is CPU bound (example being Home Assistant startup). We
+    now add an additional _LOADED_SYSTEM_TIMEOUT (10s) to the
+    run_coroutine_threadsafe calls to ensure the coroutine has
+    the total amount of time to run up to its internal timeout
+    (default of 3000ms).
+  * Ten seconds is a bit large of a timeout; however, it is only
+    used in cases where we wrap other timeouts. We now expect the
+    only instance the run_coroutine_threadsafe result timeout will
+    happen in a production circumstance is when someone is running
+    a ServiceInfo.request() in a thread and another thread calls
+    Zeroconf.close() at just the right moment that the future
+    is never completed unless the system is so loaded that it is
+    nearly unresponsive.
+  * The timeout for run_coroutine_threadsafe is the maximum time
+    a thread can cleanly shut down when zeroconf is closed out in
+    another thread, which should always be longer than the underlying
+    thread operation.
+- Changes from 0.32.0:
+  This release offers 100% line and branch coverage.
+  * Made ServiceInfo first question QU (#852) @bdraco
+  * We want an immediate response when requesting with ServiceInfo
+    by asking a QU question; most responders will not delay the
+    response and respond right away to our question. This also
+    improves compatibility with split networks as we may not have
+    been able to see the response otherwise. If the responder has
+    not multicast the record recently, it may still choose to do
+    so in addition to responding via unicast
+  * Reduces traffic when there are multiple zeroconf instances
+    running on the network running ServiceBrowsers
+  * If we don't get an answer on the first try, we ask a QM question
+    in the event, we can't receive a unicast response for some reason
+  * This change puts ServiceInfo inline with ServiceBrowser which
+    also asks the first question as QU since ServiceInfo is commonly
+    called from ServiceBrowser callbacks
+  * Limited duplicate packet suppression to 1s intervals (#841)
+    @bdraco
+  * Only suppress duplicate packets that happen within the same
+    second. Legitimate queriers will retry the question if they
+    are suppressed. The limit was reduced to one second to be in
+    line with rfc6762
+  * Made multipacket known answer suppression per interface (#836)
+    @bdraco
+  * The suppression was happening per instance of Zeroconf instead
+    of per interface. Since the same network can be seen on multiple
+    interfaces (usually and wifi and ethernet), this would confuse
+    the multi-packet known answer supression since it was not
+    expecting to get the same data more than once
+  * New ServiceBrowsers now request QU in the first outgoing when
+    unspecified (#812) @bdraco
+  * https://datatracker.ietf.org/doc/html/rfc6762#section-5.4 When
+    we start a ServiceBrowser and zeroconf has just started up,
+    the known answer list will be small. By asking a QU question
+    first, it is likely that we have a large known answer list
+    by the time we ask the QM question a second later (current
+    default which is likely too low but would be a breaking change
+    to increase). This reduces the amount of traffic on the network,
+    and has the secondary advantage that most responders will answer
+    a QU question without the typical delay answering QM questions.
+  * IPv6 link-local addresses are now qualified with scope_id
+    (#343) @ibygrave
+  * When a service is advertised on an IPv6 address where the scope
+    is link local, i.e. fe80::/64 (see RFC 4007) the resolved IPv6
+    address must be extended with the scope_id that identifies
+    through the "%" symbol the local interface to be used when
+    routing to that address. A new API parsed_scoped_addresses()
+    is provided to return qualified addresses to avoid breaking
+    compatibility on the existing parsed_addresses().
+  * Network adapters that are disconnected are now skipped (#327)
+    @ZLJasonG
+  * Fixed listeners missing initial packets if Engine starts too
+    quickly (#387) @bdraco
+  * When manually creating a zeroconf.Engine object, it is no longer
+    started automatically. It must manually be started by calling
+    .start() on the created object.
+  * The Engine thread is now started after all the listeners have
+    been added to avoid a race condition where packets could be
+    missed at startup.
+  * Fixed answering matching PTR queries with the ANY query (#618)
+    @bdraco
+  * Fixed lookup of uppercase names in the registry (#597) @bdraco
+  * If the ServiceInfo was registered with an uppercase name and
+    the query was for a lowercase name, it would not be found
+    and vice-versa.
+  * Fixed unicast responses from any source port (#598) @bdraco
+  * Unicast responses were only being sent if the source port was
+    53, this prevented responses when testing with dig:
+        dig -p 5353 @224.0.0.251 media-12.local
+    The above query will now see a response
+  * Fixed queries for AAAA records not being answered (#616) @bdraco
+  * Removed second level caching from ServiceBrowsers (#737) @bdraco
++++ 173 more lines (skipped)
++++ between /work/SRC/openSUSE:Factory/python-zeroconf/python-zeroconf.changes
++++ and 
/work/SRC/openSUSE:Factory/.python-zeroconf.new.1899/python-zeroconf.changes

Old:
----
  disable-tests.patch
  python-zeroconf-0.31.0.tar.xz

New:
----
  python-zeroconf-0.35.1.tar.xz

++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

Other differences:
------------------
++++++ python-zeroconf.spec ++++++
--- /var/tmp/diff_new_pack.3J2z1O/_old  2021-08-18 08:57:06.222890826 +0200
+++ /var/tmp/diff_new_pack.3J2z1O/_new  2021-08-18 08:57:06.226890821 +0200
@@ -19,14 +19,13 @@
 %{?!python_module:%define python_module() python-%{**} python3-%{**}}
 %define skip_python2 1
 Name:           python-zeroconf
-Version:        0.31.0
+Version:        0.35.1
 Release:        0
 Summary:        Pure Python Multicast DNS Service Discovery Library 
(Bonjour/Avahi compatible)
 License:        LGPL-2.0-only
 Group:          Development/Languages/Python
 URL:            https://github.com/jstasiak/python-zeroconf
 Source:         %{name}-%{version}.tar.xz
-Patch0:         disable-tests.patch
 BuildRequires:  %{python_module ifaddr >= 0.1.7}
 BuildRequires:  %{python_module pytest-asyncio}
 BuildRequires:  %{python_module pytest}
@@ -46,7 +45,6 @@
 
 %prep
 %autosetup -p1
-sed -i -e "s/__version__ = '0.29.0'/__version__ = '%{version}'/" 
zeroconf/__init__.py
 
 %build
 %python_build
@@ -57,7 +55,7 @@
 %python_expand %fdupes %{buildroot}%{$python_sitelib}
 
 %check
-%pytest zeroconf/test.py -k 'not (test_integration_with_listener_ipv6 or 
test_launch)'
+%pytest tests -k 'not (test_integration_with_listener_ipv6 or test_launch or 
test_close_multiple_times)'
 
 %files %{python_files}
 %doc README.rst

++++++ _service ++++++
--- /var/tmp/diff_new_pack.3J2z1O/_old  2021-08-18 08:57:06.254890788 +0200
+++ /var/tmp/diff_new_pack.3J2z1O/_new  2021-08-18 08:57:06.254890788 +0200
@@ -2,8 +2,8 @@
   <service name="obs_scm" mode="disabled">
     <param name="url">https://github.com/jstasiak/python-zeroconf</param>
     <param name="scm">git</param>
-    <param name="revision">87ba2a3960576cfcf4207ea74a711b2c0cc584a7</param>
-    <param name="version">0.31.0</param>
+    <param name="revision">4281221b668123b770c6d6b0835dd876d1d2f22d</param>
+    <param name="version">0.35.1</param>
   </service>
   <service name="set_version" mode="disabled"/>
 

++++++ python-zeroconf-0.31.0.tar.xz -> python-zeroconf-0.35.1.tar.xz ++++++
++++ 20770 lines of diff (skipped)

Reply via email to