{"push_id":1564519857,"size":22,"distinct_size":6,"ref":"refs/heads/th/assume-vs-unmanaged-bgo746440","head":"789b0e7443f3d2669a4a52b9718156a8a4481337","before":"7c0e49e659d71fea86ab1d0718ce9d5687ebfdb4","commits":[{"sha":"66c45d0fdcbd9e87b5164c5f77f914141cbb9419","author":{"name":"Thomas Haller","email":"9d2a1d242d3f6644641a729c1b364077592f4cb6@redhat.com"},"message":"supplicant: rework nm_supplicant_interface_set_config() to invoke result callback\n\nInstead of having a NM_SUPPLICANT_INTERFACE_CONNECTION_ERROR signal to notify\nabout failures during AddNetwork/SelectNetwork, accept a callback to report\nsuccess/failure.\n\nThereby, rename nm_supplicant_interface_set_config() to\nnm_supplicant_interface_assoc().\n\nThe async callback is guaranteed to:\n\n - be invoked exactly once, signalling success or failure\n - always being invoked asyncronously.\n\nThe pending request can be (synchronously) cancelled via\nnm_supplicant_interface_disconnect() or by disposing the\ninterface instance. In those cases the callback will be invoked\ntoo, with error code cancelled/disposing.","distinct":false,"url":"https://api.github.com/repos/NetworkManager/NetworkManager/commits/66c45d0fdcbd9e87b5164c5f77f914141cbb9419"},{"sha":"e16bf4f3db3da36f8194195e766029d1b751b5ec","author":{"name":"Thomas Haller","email":"9d2a1d242d3f6644641a729c1b364077592f4cb6@redhat.com"},"message":"supplicant/trivial: move code around","distinct":false,"url":"https://api.github.com/repos/NetworkManager/NetworkManager/commits/e16bf4f3db3da36f8194195e766029d1b751b5ec"},{"sha":"da34034b95651d8b68eaa19d7bf115ffc1cd1fb5","author":{"name":"Thomas Haller","email":"9d2a1d242d3f6644641a729c1b364077592f4cb6@redhat.com"},"message":"supplicant: use nm_clear_g_cancellable() helper","distinct":false,"url":"https://api.github.com/repos/NetworkManager/NetworkManager/commits/da34034b95651d8b68eaa19d7bf115ffc1cd1fb5"},{"sha":"dce13b6f11105422d54ee3aa3781ae77c875ae0f","author":{"name":"Thomas Haller","email":"9d2a1d242d3f6644641a729c1b364077592f4cb6@redhat.com"},"message":"supplicant: remove unused return value from nm_supplicant_interface_request_scan()\n\nIt cannot fail, remove code that anticipates a failure of request-scan.","distinct":false,"url":"https://api.github.com/repos/NetworkManager/NetworkManager/commits/dce13b6f11105422d54ee3aa3781ae77c875ae0f"},{"sha":"c47026715ec6a9612752f469358a7251aabbdee7","author":{"name":"Thomas Haller","email":"9d2a1d242d3f6644641a729c1b364077592f4cb6@redhat.com"},"message":"supplicant: cleanup network when cancelling \"AddNetwork\" request\n\nIf the assoc-request is cancelled while an \"AddNetwork\" request is\npending, we must cleanup the added network when the request succeeds.\n\nThe issue can also happen when NetworkManager shuts down and exits\nthe mainloop. This scenario is unsolved as the cleanup action\n\"RemoveNetwork\" has no chance to run.\n\n\"AddBlob\" works differently in that blogs are added with a specific name,\nnot like \"AddNetwork\", where a new D-Bus path is created. Maybe we should\nalso cleanup blobs that were added by us, but currently we don't.","distinct":false,"url":"https://api.github.com/repos/NetworkManager/NetworkManager/commits/c47026715ec6a9612752f469358a7251aabbdee7"},{"sha":"29a53b1cd7fb48984221c71b38b049c3ced9b560","author":{"name":"Thomas Haller","email":"9d2a1d242d3f6644641a729c1b364077592f4cb6@redhat.com"},"message":"supplicant: merge NEW_BSS signal with BSS_UPDATED\n\nBefore, the NEW_BSS signal was not careful to emit the signal only when the BSS\nis seen for the first time. Consequently, supplicant_iface_new_bss_cb() checked\nwhether it already knows about the new BSS.\n\nMerge NEW_BSS and BSS_UPDATED. Now we emit BSS_UPDATED when either the\nBSS is new or changed.\n\nAlso, in supplicant_iface_new_bss_cb() (now supplicant_iface_bss_updated_cb())\nno longer constructs an @ap instance if we have a @found_ap.\n\nIn some situations there can be a value of having a separate ADD signal.\nBut only when there the consumers care, and if the consumers can trust that\nADD is not just an UPDATE. The only consumer doesn't care and it not not be\ntrusted, so merge the signals.","distinct":false,"url":"https://api.github.com/repos/NetworkManager/NetworkManager/commits/29a53b1cd7fb48984221c71b38b049c3ced9b560"},{"sha":"e3a489180b83d55c796d2162eecae01b7351327a","author":{"name":"Thomas Haller","email":"9d2a1d242d3f6644641a729c1b364077592f4cb6@redhat.com"},"message":"wifi: check for invalid BSSID in nm_wifi_ap_update_from_properties()\n\nIn nm_wifi_ap_new_from_properties(), we checked that the BSSID is valid\nand bailed out otherwise. Since we call nm_wifi_ap_update_from_properties()\non a created BSSID, we should ensure there too that an update does not cause\nthe address to become invalid.\n\nIn the unlikely case where an update would change a previously valid address\nto an invalid one, we would ignore the update.\n\nThus, move the check for addresses inside nm_wifi_ap_update_from_properties().","distinct":false,"url":"https://api.github.com/repos/NetworkManager/NetworkManager/commits/e3a489180b83d55c796d2162eecae01b7351327a"},{"sha":"e0f96770188eeaada70a299bd6dab7a50ec34a53","author":{"name":"Thomas Haller","email":"9d2a1d242d3f6644641a729c1b364077592f4cb6@redhat.com"},"message":"supplicant: delay SCAN_DONE signal until all BSS are initialized\n\nWe initialize the BSS asyncronously. Don't declare SCAN_DONE\nuntil all BSS are up.\n\nOtherwise, especially during the very first scan we declare SCAN_DONE\nwhen having no BSS yet. This wrongly removes the pending action\n\"wifi-scan\", while \"autoconnect\" cannot happen as there are not BSS\nyet. Thus we declare \"startup-complete\" too early.\n\nAnother issue is that we may start autoconnecting with an incomplete\nscan list, and thus pick a non-preferred connections.\n\nhttps://bugzilla.gnome.org/show_bug.cgi?id=777831","distinct":false,"url":"https://api.github.com/repos/NetworkManager/NetworkManager/commits/e0f96770188eeaada70a299bd6dab7a50ec34a53"},{"sha":"c9dc0eba65565d361e32200894386da5e5c2d001","author":{"name":"Thomas Haller","email":"9d2a1d242d3f6644641a729c1b364077592f4cb6@redhat.com"},"message":"wifi: only react on AP update signal when there are actual changes\n\nSince we emit BSS_UPDATED signal before SCAN_DONE, it is very likely\nthat nothing actually changed. This clutters the logs with update\nmessages.\n\nAlso move the added/removed logging messages inside ap_add_remove().\nWe would call ap_add_remove() at several places without logging the\nchange.","distinct":false,"url":"https://api.github.com/repos/NetworkManager/NetworkManager/commits/c9dc0eba65565d361e32200894386da5e5c2d001"},{"sha":"257484e7bac2813d0cf1bc922ef57e6b781b1c96","author":{"name":"Thomas Haller","email":"9d2a1d242d3f6644641a729c1b364077592f4cb6@redhat.com"},"message":"wifi: also show the NM D-Bus path for the Wi-Fi AP in nm_wifi_ap_to_string()","distinct":false,"url":"https://api.github.com/repos/NetworkManager/NetworkManager/commits/257484e7bac2813d0cf1bc922ef57e6b781b1c96"},{"sha":"2f9166e6b9c18af4801fd5cc6c01f7eaaeb9d538","author":{"name":"Thomas Haller","email":"9d2a1d242d3f6644641a729c1b364077592f4cb6@redhat.com"},"message":"device: separately handle NMDevice's autoconnect by user and internal decision\n\nThe NMDevice's autoconnect property is settable via D-Bus and is is\nalso modified by internal decision, like when no PIN is available.\n\nCertain internal actions cause clearing the internal autoconnect flag,\nbut they should not override the user desicion.\n\nFor example, when NM awaks from sleep it would reenable autoconnect,\nbut it should not reenable it for devices where the user explicitly\nsaid that autoconnect is to be disabled.\n\nSimilarly, activating a device alone is not yet an instruction to\nre-enable autoconnect. If the user consciously disables autoconnect,\nit should stay enabled. On the other hand, activating a device should\nreenable autoconnect if it was blocked by internal decision.\n\nWe need to track these two flags separately, and set them accordingly.","distinct":false,"url":"https://api.github.com/repos/NetworkManager/NetworkManager/commits/2f9166e6b9c18af4801fd5cc6c01f7eaaeb9d538"},{"sha":"6eaded9071fbf868476255adb8ee5f416e7ad134","author":{"name":"Thomas Haller","email":"9d2a1d242d3f6644641a729c1b364077592f4cb6@redhat.com"},"message":"device: add get_autoconnect_allowed() virtual function\n\nIt allows derived classes to override the autoconnect-allowed\nstate.\n\nWe already have\n\n- NM_DEVICE_AUTOCONNECT property, which is two parts:\n  - NMDevicePrivate::autoconnect_user, which is settable via\n    D-Bus by the use, to allow the device to autoconnect.\n  - NMDevicePrivate::autoconnect_intern, which is set by\n    internal decision.\n- NM_DEVICE_AUTOCONNECT_ALLOWED signal, where other devices can\n  subscribe to block autoconnect. Currently that is only used\n  by NMDeviceOlpcMesh.\n\nThese two make up for nm_device_autoconnect_allowed().\n\nAdd another way to allow derived classes to disable autoconnect\ntemporarily. This could also be achieved by having the device\nsubscribe to NM_DEVICE_AUTOCONNECT_ALLOWED of self, or by adding\na signal slot. But a plain function pointer seems easier.","distinct":false,"url":"https://api.github.com/repos/NetworkManager/NetworkManager/commits/6eaded9071fbf868476255adb8ee5f416e7ad134"},{"sha":"2ab2254dd7336b9b7baa03ea1eb1f1c72f7ab6a8","author":{"name":"Thomas Haller","email":"9d2a1d242d3f6644641a729c1b364077592f4cb6@redhat.com"},"message":"device/wifi: block autoconnect while scanning is in progress\n\nWe should only start autoconnecting after the scan is complete.\nOtherwise, we might activate a shared connection or pick a\nconnection based on an incomplete scan list.\n\nhttps://bugzilla.gnome.org/show_bug.cgi?id=770938","distinct":false,"url":"https://api.github.com/repos/NetworkManager/NetworkManager/commits/2ab2254dd7336b9b7baa03ea1eb1f1c72f7ab6a8"},{"sha":"fe6204ffc71f62c1667d0eba56f3a22d6aa9bbbd","author":{"name":"Thomas Haller","email":"9d2a1d242d3f6644641a729c1b364077592f4cb6@redhat.com"},"message":"device/wifi: merge branch 'th/device-wifi-wait-for-scan-bgo770938'\n\nhttps://bugzilla.gnome.org/show_bug.cgi?id=770938\nhttps://bugzilla.gnome.org/show_bug.cgi?id=777831","distinct":false,"url":"https://api.github.com/repos/NetworkManager/NetworkManager/commits/fe6204ffc71f62c1667d0eba56f3a22d6aa9bbbd"},{"sha":"c79e84368ae6e80279d9cb5971bbd84857a8227a","author":{"name":"Thomas Haller","email":"9d2a1d242d3f6644641a729c1b364077592f4cb6@redhat.com"},"message":"all: add new \"shared/nm-setting-metadata.h\" file\n\n\"shared/nm-setting-metadata.h\" will contain data structures\nto handle NM setting properties in a generic way.\n\nFor now, this is internal API, but shared between libnm-core (which\nextends to libnm, NetworkManager, device-plugins, settings-plugins),\nand nmcli.\n\nRelated: https://bugzilla.gnome.org/show_bug.cgi?id=732292","distinct":false,"url":"https://api.github.com/repos/NetworkManager/NetworkManager/commits/c79e84368ae6e80279d9cb5971bbd84857a8227a"},{"sha":"2c9ef8cf2e1f112fa9d4c3b852e6a95e2bee4a17","author":{"name":"Thomas Haller","email":"9d2a1d242d3f6644641a729c1b364077592f4cb6@redhat.com"},"message":"shared: move NMSetting8021xSchemeVtable to \"shared/nm-setting-metadata.h\"","distinct":false,"url":"https://api.github.com/repos/NetworkManager/NetworkManager/commits/2c9ef8cf2e1f112fa9d4c3b852e6a95e2bee4a17"},{"sha":"3da062f326828de4bacb2a7d16a57e31afbd5436","author":{"name":"Thomas Haller","email":"9d2a1d242d3f6644641a729c1b364077592f4cb6@redhat.com"},"message":"core/trivial: rename nm-generated-assumed flag to garbage-collect\n\nThe concept of assumed-collections will soon go away (as it existed until now).\nWhat is still useful is the property of a connection to get deleted once\nthe connection disconnects.","distinct":true,"url":"https://api.github.com/repos/NetworkManager/NetworkManager/commits/3da062f326828de4bacb2a7d16a57e31afbd5436"},{"sha":"1bbfc1e8cfd96322d6ff3349717d403270cfee62","author":{"name":"Thomas Haller","email":"9d2a1d242d3f6644641a729c1b364077592f4cb6@redhat.com"},"message":"device: pass the user-explict flag to nm_device_realize_start()\n\nNo change in behavior yet, because for unrealized devices the\nuser-explict unmanaged flag is always cleared.\n\nThe new option is still unused.","distinct":true,"url":"https://api.github.com/repos/NetworkManager/NetworkManager/commits/1bbfc1e8cfd96322d6ff3349717d403270cfee62"},{"sha":"8b68914ca72e988016b64c2c89a7f5c75e53cfd1","author":{"name":"Thomas Haller","email":"9d2a1d242d3f6644641a729c1b364077592f4cb6@redhat.com"},"message":"device: set user-explicit unmanaged flag based on loaded device-state\n\nOn restart, the device state may be stored in /var/run. Reuse it\nto set the managed flag.","distinct":true,"url":"https://api.github.com/repos/NetworkManager/NetworkManager/commits/8b68914ca72e988016b64c2c89a7f5c75e53cfd1"},{"sha":"537c6f397dc098cd74089603038b8a62b0172d08","author":{"name":"Thomas Haller","email":"9d2a1d242d3f6644641a729c1b364077592f4cb6@redhat.com"},"message":"device: drop NM_UNMANAGED_EXTERNAL_DOWN\n\nWe used the unmanage flag \"external-down\" for software devices that\nwere created outside of NetworkManager. The \"external-down\" flag kept\nthe device as unmanaged, until the interface was up and had an IP address.\nThat is wrong to do.\n\nInstead, replace the flag by NM_UNMANAGED_BY_DEFAULT, which marks all\nsoftware devices that were created outside of NetworkManager as unmanaged.\nThis is regardless of their IP configuration. If a software device was not\ncreated by NetworkManager it is fair to assume that the user wants to manage\nit himself and doesn't want NetworkManager to interfere.\n\nNote that the unmanged flags \"user-udev\" and \"user-explicit\" have higher\npriority then the \"by-default\" flag. This way it will be still possible to\nmanage devices that would be otherwise unmanaged.\n\nThis breaks behavior in many ways, which will be only fixed by later commits.","distinct":true,"url":"https://api.github.com/repos/NetworkManager/NetworkManager/commits/537c6f397dc098cd74089603038b8a62b0172d08"}]}
{"actor":{"display_login":"lkundrak"}}