/srv/irclogs.ubuntu.com/2013/10/31/#ubuntu-bugs.txt

=== Pici is now known as TalkingMuffin
brainwashbug 1234469, once again all the duplicate reports have been removed... what up with that?10:28
ubot2Launchpad bug 1234469 in linux (Ubuntu) "Network does not come up after resuming from suspend." [Medium,Incomplete] https://launchpad.net/bugs/123446910:28
brainwashsorry, bug 1184262 is the main one10:28
ubot2Launchpad bug 1184262 in systemd (Ubuntu) "[logind] stuck in PrepareForSleep, causing network and other services to not resume" [Undecided,Confirmed] https://launchpad.net/bugs/118426210:28
penguin42brainwash: Hmm I could almost kind of understand that on the 'linux' one, because we try to avoid dupes on the 'linux' bugs unless we're 110% sure it's the same problem10:47
brainwashpenguin42: many have been converted to linux ones I think10:48
brainwashit's a mess10:48
penguin42brainwash: Nod, tbh I'd have picked Linux as the source for a suspend/resume network problem; but 1184262 seems to be actively working it on the systemd/etc side of things so it does look it's being worked10:49
brainwashfor many people is was clearly a network-manager issue in the first place10:54
penguin42well, you say that but that's not where the debug process is going in that bug10:54
brainwashit's just a bit annoying if someone messes around with reports10:54
brainwashright, because people are not familiar with systemd yet10:55
brainwashand most confirmed that the network-manager could be re-enabled manually10:56
penguin42Yeh it's a little odd, if there weren't any work around on it and it was just network-fails-after-suspend I would have put it against linux as well, but I agree with the bugs that show the workaround it does seem unlikely to be the kernel10:57
brainwashbut removing all duplicates without stating a reasons seems a bit wrong10:57
penguin42yeh should always state reasons for doing something10:58
brainwashI'll try to contact him and ask about this, so I can understand why he did this11:00
brainwashpenguin42: thanks for clarifying some things :)11:00
hggdhbrainwash: pitti has been working on this bug. If he replaced n-m by systemd-shim it is because he believes systemd-shim is the actual guilty party13:16
=== Ursinha is now known as Ursinha-afk
brainwashhggdh: I know that, because I'm bothering him all the time with my observations and log files :)14:59
hggdhheh14:59
=== Ursinha-afk is now known as Ursinha
brainwashand that's the reason I actually care about the removal of all the duplicates15:06
hggdhbrainwash: I am assuming that pitti removed them (I do not have details in the log). If he indeed removed them, it is because he considered them *not* the same issue.15:32
brainwashhggdh: very unlikely, because it is the same issue in most cases, some reports don't provide enough details, but describe the same issue (saucy, resume does not wakeup network-manager and/or session is stuck in sleep state)17:01
brainwashpitti's updated package does fix many cases of this issue, but we still investigate if the remaining people are eventually affected by another dbus timeout (systemd also)17:04
=== Ursinha is now known as Ursinha-afk
brainwashand some bug reporters have already marked their report as duplicate once again17:06
=== Ursinha-afk is now known as Ursinha
hggdhdarn! I *hate* when people change bug status without explaining why.17:39
penguin42nod17:43
hggdhOK. comment added on bug 1187005, which has seen a small flurry of wrong duplicates17:45
ubot2Launchpad bug 1184262 in systemd (Ubuntu) "duplicate for #1187005 [logind] stuck in PrepareForSleep, causing network and other services to not resume" [Undecided,Confirmed] https://launchpad.net/bugs/118426217:45
penguin42hggdh: I have a little sympathy that without noticing the work around people found, I'd have also guessed at 'linux' being the package for a suspend/resume bug, and once you've set it to linux you don't do dupes17:46
hggdhpenguin42: indeed. But, if Linux is not the correct package, undupping & dupping to a different bug strikes me as weird17:46
hggdhbrainwash: at least 1234469 was set as a dup to your bug by pitti himself...17:48
hggdhpenguin42: also, I would expect people to read the comments *and* look at the activity log. Although, I concede, if one does not know the other players, it get difficult to value their knowledge.17:52
* hggdh is now thinking this also applies to self...17:52
penguin42hggdh: tbf I don't think the bugs actually been fixed yet (or hadn't yesterday)17:52
hggdhI agree. Martin's fix does not get all, or there are different issues at play17:53
hggdhand I am pretty sure that, right now, I do not want to look at systemd, it is rather confusing, docs lacking, API seems to change suddenly, etc17:56
penguin42hggdh: Yeh I mean it sounded like a hideous interaction of systemd/nm and a bunch of other stuff - wth knows who dropped the ball17:58
hggdh<nod/>17:59
brainwashit's not actually systemd's fault, but ubuntu's own wrapper for some dbus calls -> systemd-shim18:02
brainwashsystemd-shim quits after 10sec (that too fast), this has been fixed by pitti's new package18:03
hggdhbrainwash: I understand. But the fact we *need* a translator (shim) to interact with systemd says something is blowing out known APIs18:04
brainwashwell, we had to replace consolekit (deprecated) with logind (part of systemd)18:05
brainwashand we don't ship every part of systemd, because it would replace upstart18:06
hggdhindeed. But then systemd is getting to be a monolithic beast -- replacing a lot of known/used programs with its own, and incompatible with a lot (or everything else).18:07
penguin42brainwash: rule 24: Any fixed timeout is wrong18:07
brainwashit seems that the 10sec timeout causes trouble, if the system is slow at suspending18:09
penguin42brainwash: Anything like that is a nightmare, things like suspend/resumes are really random times on different hardware18:09
penguin42brainwash: No timeout value will ever be right18:09
hggdhindeed. Or, at least, fail gracefully18:10
brainwashtrue18:10
=== wylde_ is now known as Guest32821
brainwash13.10 still feels somewhat broken and unpolished18:11
hggdhwell, this is sort of expected, 13.10 is a preparation for 14.0418:12
hggdh(so we could *sort* of look at it as a beta)18:12
brainwashyes :)18:12
penguin42tbh I think it's time to throw the towel in and use systemd - it seems to work18:14
brainwashcanonical won't like this18:15
penguin42indeed, but then users don't like bugs like this18:15
=== Ursinha_ is now known as Ursinha
=== rsalveti_ is now known as rsalveti
hggdhall in all, it will be a pity -- I like the idea of using events18:27
* hggdh remember the happiness when learning petri nets a long time ago18:30
penguin42well nowt wrong with events as long as you never lose any18:32
hggdhand you have a clear description of all events18:32
penguin42hggdh: It's like if I eat one of the M&Ms/smarties you were using to keep track of your petri net18:33
hggdhLOL18:33
hggdhindeed. And then try to prove you reach a final state...18:34
penguin42hggdh: maths/formal method stuff?18:34
hggdhyes18:35
penguin42hggdh: I spent some time doing clock-less CPUs, there were a bunch of formal guys trying to do proofs against deadlock18:35
hggdhfaded to failure, IIRC18:36
hggdhmight still be possible if we had finite state (sub)machines; we might be able to prove the machine eventually enters a final state (which would be input to the next machine)18:37
=== wylde is now known as Guest77372
penguin42it's very difficult - the complexity just explodes as soon as you do anything useful18:45
=== maxb_ is now known as maxb

Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!