=== Pici is now known as TalkingMuffin
[10:28] <brainwash> bug 1234469, once again all the duplicate reports have been removed... what up with that?
[10:28] <ubot2> Launchpad bug 1234469 in linux (Ubuntu) "Network does not come up after resuming from suspend." [Medium,Incomplete] https://launchpad.net/bugs/1234469
[10:28] <brainwash> sorry, bug 1184262 is the main one
[10:28] <ubot2> Launchpad bug 1184262 in systemd (Ubuntu) "[logind] stuck in PrepareForSleep, causing network and other services to not resume" [Undecided,Confirmed] https://launchpad.net/bugs/1184262
[10:47] <penguin42> brainwash: 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 problem
[10:48] <brainwash> penguin42: many have been converted to linux ones I think
[10:48] <brainwash> it's a mess
[10:49] <penguin42> brainwash: 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 worked
[10:54] <brainwash> for many people is was clearly a network-manager issue in the first place
[10:54] <penguin42> well, you say that but that's not where the debug process is going in that bug
[10:54] <brainwash> it's just a bit annoying if someone messes around with reports
[10:55] <brainwash> right, because people are not familiar with systemd yet
[10:56] <brainwash> and most confirmed that the network-manager could be re-enabled manually
[10:57] <penguin42> Yeh 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 kernel
[10:57] <brainwash> but removing all duplicates without stating a reasons seems a bit wrong
[10:58] <penguin42> yeh should always state reasons for doing something
[11:00] <brainwash> I'll try to contact him and ask about this, so I can understand why he did this
[11:00] <brainwash> penguin42: thanks for clarifying some things :)
[13:16] <hggdh> brainwash: 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 party
=== Ursinha is now known as Ursinha-afk
[14:59] <brainwash> hggdh: I know that, because I'm bothering him all the time with my observations and log files :)
[14:59] <hggdh> heh
=== Ursinha-afk is now known as Ursinha
[15:06] <brainwash> and that's the reason I actually care about the removal of all the duplicates
[15:32] <hggdh> brainwash: 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.
[17:01] <brainwash> hggdh: 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:04] <brainwash> pitti'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)
=== Ursinha is now known as Ursinha-afk
[17:06] <brainwash> and some bug reporters have already marked their report as duplicate once again
=== Ursinha-afk is now known as Ursinha
[17:39] <hggdh> darn! I *hate* when people change bug status without explaining why.
[17:43] <penguin42> nod
[17:45] <hggdh> OK. comment added on bug 1187005, which has seen a small flurry of wrong duplicates
[17:45] <ubot2> Launchpad 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/1184262
[17:46] <penguin42> hggdh: 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 dupes
[17:46] <hggdh> penguin42: indeed. But, if Linux is not the correct package, undupping & dupping to a different bug strikes me as weird
[17:48] <hggdh> brainwash: at least 1234469 was set as a dup to your bug by pitti himself...
[17:52] <hggdh> penguin42: 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] <penguin42> hggdh: tbf I don't think the bugs actually been fixed yet (or hadn't yesterday)
[17:53] <hggdh> I agree. Martin's fix does not get all, or there are different issues at play
[17:56] <hggdh> and 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, etc
[17:58] <penguin42> hggdh: Yeh I mean it sounded like a hideous interaction of systemd/nm and a bunch of other stuff - wth knows who dropped the ball
[17:59] <hggdh> <nod/>
[18:02] <brainwash> it's not actually systemd's fault, but ubuntu's own wrapper for some dbus calls -> systemd-shim
[18:03] <brainwash> systemd-shim quits after 10sec (that too fast), this has been fixed by pitti's new package
[18:04] <hggdh> brainwash: I understand. But the fact we *need* a translator (shim) to interact with systemd says something is blowing out known APIs
[18:05] <brainwash> well, we had to replace consolekit (deprecated) with logind (part of systemd)
[18:06] <brainwash> and we don't ship every part of systemd, because it would replace upstart
[18:07] <hggdh> indeed. 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] <penguin42> brainwash: rule 24: Any fixed timeout is wrong
[18:09] <brainwash> it seems that the 10sec timeout causes trouble, if the system is slow at suspending
[18:09] <penguin42> brainwash: Anything like that is a nightmare, things like suspend/resumes are really random times on different hardware
[18:09] <penguin42> brainwash: No timeout value will ever be right
[18:10] <hggdh> indeed. Or, at least, fail gracefully
[18:10] <brainwash> true
=== wylde_ is now known as Guest32821
[18:11] <brainwash> 13.10 still feels somewhat broken and unpolished
[18:12] <hggdh> well, this is sort of expected, 13.10 is a preparation for 14.04
[18:12] <hggdh> (so we could *sort* of look at it as a beta)
[18:12] <brainwash> yes :)
[18:14] <penguin42> tbh I think it's time to throw the towel in and use systemd - it seems to work
[18:15] <brainwash> canonical won't like this
[18:15] <penguin42> indeed, but then users don't like bugs like this
=== Ursinha_ is now known as Ursinha
=== rsalveti_ is now known as rsalveti
[18:27] <hggdh> all in all, it will be a pity -- I like the idea of using events
[18:30]  * hggdh remember the happiness when learning petri nets a long time ago
[18:32] <penguin42> well nowt wrong with events as long as you never lose any
[18:32] <hggdh> and you have a clear description of all events
[18:33] <penguin42> hggdh: It's like if I eat one of the M&Ms/smarties you were using to keep track of your petri net
[18:33] <hggdh> LOL
[18:34] <hggdh> indeed. And then try to prove you reach a final state...
[18:34] <penguin42> hggdh: maths/formal method stuff?
[18:35] <hggdh> yes
[18:35] <penguin42> hggdh: I spent some time doing clock-less CPUs, there were a bunch of formal guys trying to do proofs against deadlock
[18:36] <hggdh> faded to failure, IIRC
[18:37] <hggdh> might 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)
=== wylde is now known as Guest77372
[18:45] <penguin42> it's very difficult - the complexity just explodes as soon as you do anything useful
=== maxb_ is now known as maxb