network-manager updated to unstable version?

  • Done
  • quality assurance status badge
Details
4 participants
  • John Kehayias
  • Ludovic Courtès
  • Maxim Cournoyer
  • Csepp
Owner
unassigned
Submitted by
John Kehayias
Severity
normal
J
J
John Kehayias wrote on 29 Mar 2023 07:47
(name . Guix Bugs)(address . bug-guix@gnu.org)(name . Maxim Cournoyer)(address . maxim.cournoyer@gmail.com)
87r0t8f6sb.fsf@protonmail.com
Hi Guix,

(cc'ing Maxim as author of last few network-manager version updates.)

I noticed a recent up date to network-manager to 1.43.4 (previously 1.41.2 and 1.40.0) but can't find a record of that release. In their docs there is no mention of anything newer than the 1.42 release [0, 1] and they mention the even-numbered releases being the stable series [2]. Indeed, Arch only has 1.42.4 in their repos [3]. I only see "dev" tags for these 1.43 versions in their gitlab.

Should we be on a 1.42.y version instead?

I noticed this because the update to 1.43.4 has an issue with my (wired) connection not resuming from sleep when previously it did. I have to restart the service. I had some logs I can dig up, but in discussing on IRC (no logs that day it seems) there was nothing out of the ordinary and the shepherd service seemed normal.

I've since reconfigured to a commit before the most recent version change, namely 5174820753be045ba4fc7cc93da33f4e0b730bc3 and cannot reproduce the issue so seems due to newer versions of network-manager after 1.41.2 at least.

Note that this may have been reported upstream [4], but I haven't tested with the current stable release. So this may be a separate (upstream) issue.

Anyway, the first question is what version we should have of network-manager?

Thanks!
John






M
M
Maxim Cournoyer wrote on 29 Mar 2023 14:42
(name . John Kehayias)(address . john.kehayias@protonmail.com)(address . 62513@debbugs.gnu.org)
87fs9n3f18.fsf@gmail.com
Hi John,

John Kehayias <john.kehayias@protonmail.com> writes:

Toggle quote (13 lines)
> Hi Guix,
>
> (cc'ing Maxim as author of last few network-manager version updates.)
>
> I noticed a recent up date to network-manager to 1.43.4 (previously
> 1.41.2 and 1.40.0) but can't find a record of that release. In their
> docs there is no mention of anything newer than the 1.42 release [0,
> 1] and they mention the even-numbered releases being the stable series
> [2]. Indeed, Arch only has 1.42.4 in their repos [3]. I only see "dev"
> tags for these 1.43 versions in their gitlab.
>
> Should we be on a 1.42.y version instead?

The GNOME versioning scheme is a bit of a mess; they stopped using
stable/unstable oven/odd release cycles since GNOME 40 I think, but left
each of the components the luxury to keep using it, which NetworkManager
appears to be doing.

'guix refresh -u' picked 1.43 and I didn't give it much of an thought.
In general, I think it's OK to carry the "unstable" releases of GNOME
components, which in my experience are usually stable :-).

Toggle quote (15 lines)
> I noticed this because the update to 1.43.4 has an issue with my
> (wired) connection not resuming from sleep when previously it did. I
> have to restart the service. I had some logs I can dig up, but in
> discussing on IRC (no logs that day it seems) there was nothing out of
> the ordinary and the shepherd service seemed normal.
>
> I've since reconfigured to a commit before the most recent version
> change, namely 5174820753be045ba4fc7cc93da33f4e0b730bc3 and cannot
> reproduce the issue so seems due to newer versions of network-manager
> after 1.41.2 at least.
>
> Note that this may have been reported upstream [4], but I haven't
> tested with the current stable release. So this may be a separate
> (upstream) issue.

So it seems that even if we used the "stable" 1.42.x release, we'd still
have this problem. It's been reported 4 days ago; I guess let's wait to
see if a hotfix will be made, as that seems a serious issue.

Otherwise, if many Guix users are affected and no hotfix is on the
horizon, we could consider reverting back to our older version.

Does that sound reasonable?

--
Thanks,
Maxim
L
L
Ludovic Courtès wrote on 29 Mar 2023 15:39
Re: bug#62513: network-manager updated to unstable version?
(name . Maxim Cournoyer)(address . maxim.cournoyer@gmail.com)
87ilej7k34.fsf@gnu.org
Hi,

Maxim Cournoyer <maxim.cournoyer@gmail.com> skribis:

Toggle quote (5 lines)
> The GNOME versioning scheme is a bit of a mess; they stopped using
> stable/unstable oven/odd release cycles since GNOME 40 I think, but left
> each of the components the luxury to keep using it, which NetworkManager
> appears to be doing.

Could the weird nm-applet schema discrepancy found in

Thanks,
Ludo’.
C
(name . Maxim Cournoyer)(address . maxim.cournoyer@gmail.com)
87ileiifvz.fsf@riseup.net
Maxim Cournoyer <maxim.cournoyer@gmail.com> writes:

Toggle quote (50 lines)
> Hi John,
>
> John Kehayias <john.kehayias@protonmail.com> writes:
>
>> Hi Guix,
>>
>> (cc'ing Maxim as author of last few network-manager version updates.)
>>
>> I noticed a recent up date to network-manager to 1.43.4 (previously
>> 1.41.2 and 1.40.0) but can't find a record of that release. In their
>> docs there is no mention of anything newer than the 1.42 release [0,
>> 1] and they mention the even-numbered releases being the stable series
>> [2]. Indeed, Arch only has 1.42.4 in their repos [3]. I only see "dev"
>> tags for these 1.43 versions in their gitlab.
>>
>> Should we be on a 1.42.y version instead?
>
> The GNOME versioning scheme is a bit of a mess; they stopped using
> stable/unstable oven/odd release cycles since GNOME 40 I think, but left
> each of the components the luxury to keep using it, which NetworkManager
> appears to be doing.
>
> 'guix refresh -u' picked 1.43 and I didn't give it much of an thought.
> In general, I think it's OK to carry the "unstable" releases of GNOME
> components, which in my experience are usually stable :-).
>
>> I noticed this because the update to 1.43.4 has an issue with my
>> (wired) connection not resuming from sleep when previously it did. I
>> have to restart the service. I had some logs I can dig up, but in
>> discussing on IRC (no logs that day it seems) there was nothing out of
>> the ordinary and the shepherd service seemed normal.
>>
>> I've since reconfigured to a commit before the most recent version
>> change, namely 5174820753be045ba4fc7cc93da33f4e0b730bc3 and cannot
>> reproduce the issue so seems due to newer versions of network-manager
>> after 1.41.2 at least.
>>
>> Note that this may have been reported upstream [4], but I haven't
>> tested with the current stable release. So this may be a separate
>> (upstream) issue.
>
> So it seems that even if we used the "stable" 1.42.x release, we'd still
> have this problem. It's been reported 4 days ago; I guess let's wait to
> see if a hotfix will be made, as that seems a serious issue.
>
> Otherwise, if many Guix users are affected and no hotfix is on the
> horizon, we could consider reverting back to our older version.
>
> Does that sound reasonable?

This also affects two of my recently reconfigured/upgraded machines. My
guess is there are probably many others affected.
M
M
Maxim Cournoyer wrote on 30 Mar 2023 22:09
(name . Csepp)(address . raingloom@riseup.net)
87y1neyp9t.fsf@gmail.com
Hi,

Csepp <raingloom@riseup.net> writes:

Toggle quote (55 lines)
> Maxim Cournoyer <maxim.cournoyer@gmail.com> writes:
>
>> Hi John,
>>
>> John Kehayias <john.kehayias@protonmail.com> writes:
>>
>>> Hi Guix,
>>>
>>> (cc'ing Maxim as author of last few network-manager version updates.)
>>>
>>> I noticed a recent up date to network-manager to 1.43.4 (previously
>>> 1.41.2 and 1.40.0) but can't find a record of that release. In their
>>> docs there is no mention of anything newer than the 1.42 release [0,
>>> 1] and they mention the even-numbered releases being the stable series
>>> [2]. Indeed, Arch only has 1.42.4 in their repos [3]. I only see "dev"
>>> tags for these 1.43 versions in their gitlab.
>>>
>>> Should we be on a 1.42.y version instead?
>>
>> The GNOME versioning scheme is a bit of a mess; they stopped using
>> stable/unstable oven/odd release cycles since GNOME 40 I think, but left
>> each of the components the luxury to keep using it, which NetworkManager
>> appears to be doing.
>>
>> 'guix refresh -u' picked 1.43 and I didn't give it much of an thought.
>> In general, I think it's OK to carry the "unstable" releases of GNOME
>> components, which in my experience are usually stable :-).
>>
>>> I noticed this because the update to 1.43.4 has an issue with my
>>> (wired) connection not resuming from sleep when previously it did. I
>>> have to restart the service. I had some logs I can dig up, but in
>>> discussing on IRC (no logs that day it seems) there was nothing out of
>>> the ordinary and the shepherd service seemed normal.
>>>
>>> I've since reconfigured to a commit before the most recent version
>>> change, namely 5174820753be045ba4fc7cc93da33f4e0b730bc3 and cannot
>>> reproduce the issue so seems due to newer versions of network-manager
>>> after 1.41.2 at least.
>>>
>>> Note that this may have been reported upstream [4], but I haven't
>>> tested with the current stable release. So this may be a separate
>>> (upstream) issue.
>>
>> So it seems that even if we used the "stable" 1.42.x release, we'd still
>> have this problem. It's been reported 4 days ago; I guess let's wait to
>> see if a hotfix will be made, as that seems a serious issue.
>>
>> Otherwise, if many Guix users are affected and no hotfix is on the
>> horizon, we could consider reverting back to our older version.
>>
>> Does that sound reasonable?
>
> This also affects two of my recently reconfigured/upgraded machines. My
> guess is there are probably many others affected.

I take this as a "no" :-).

Reverted with be5e280e5fe26f93bd5a6e3f76e4502edb913a94.

Closing.

--
Thanks,
Maxim
Closed
?
Your comment

This issue is archived.

To comment on this conversation send an email to 62513@debbugs.gnu.org

To respond to this issue using the mumi CLI, first switch to it
mumi current 62513
Then, you may apply the latest patchset in this issue (with sign off)
mumi am -- -s
Or, compose a reply to this issue
mumi compose
Or, send patches to this issue
mumi send-email *.patch