=== gsilva is now known as gsilvapt === gsilvapt is now known as gsilva === gsilva is now known as gsilvapt === sil2100_ is now known as sil2100 === Elimin8r is now known as Elimin8er [13:31] tseliot: any ideas why nvidia-cuda-toolkit is not installable? see https://launchpad.net/ubuntu/+source/eztrace-contrib/1.1-7-1 https://launchpad.net/ubuntu/+source/hwloc-contrib/1.11.8-1 [13:34] * tseliot lookinh [13:34] *looking [13:35] ginggs: something probably broke in bionic. I'm creating a chroot to check that out === ricotz_ is now known as ricotz [14:07] tseliot: thanks [14:16] ginggs: apt-get build-dep eztrace works fine in the chroot [14:17] maybe the archive was temporarily broken? [14:19] tseliot: i gave them back an hour ago, and they've been retried a few times in the last 3 weeks [14:20] not a good sign... [14:20] juliank: apt-daily.service does not have to forward signals to u-u per design, u-u-s.service signals u-u, apt-daily.service just must not let all the child processes to be killed [14:20] rbalint: But I want it to. Everything else is just a bad user experience. [14:21] rbalint: Not only that, it also breaks the locking between the two apt-daily services [14:22] heck, it might even allow you to start apt-daily while u-u is still running from a previous apt-daily-upgrade job, considering that systemd considers apt-daily-upgrade to be inactive at that point. [14:24] juliank: i'm speeding up the SRU for u-u to accept SIGTERM if you would like to send the signal [14:24] juliank: would that work for you? [14:25] rbalint: I'd mostly like to avoid the dependencies between the SRUs. zesty is in sync with stretch, it would be nice to keep it that way (and I want to make it work in stretch too, so I need the SIGUSR1 dance for that) [14:27] juliank: i'm not sure what problem would be caused by starting apt-daily while apt-daily-upgrade is running [14:28] I'm not sure either, but they were not designed to be run together. [14:28] There are probably some race conditions in there. [14:28] juliank: i can do a stretch update, too, to u-u if that helps [14:29] I don't think the Debian RT would accept that. [14:29] juliank: as i see apt-daily does nothing that breaks apt-daily-upgrade thus we may be trying to fix something that nevar causes actual problems [14:30] It definitely replaces your Packages files, so depending on how far u-u is, it might get problems parsing stuff. [14:30] Or you might just end up with lock races between the two [14:30] The locking situation is a bit unclear. [14:31] juliank: as i saw the lock is held in u-u thus apt-daily may just fail, but have to check to be sure [14:32] There are 4 locks involved, and one lock is repeatedly released. [14:33] The apt code is almost 2 decades old and nobody has a clear picture of which locks are hold when [14:33] juliank: ok. [14:34] juliank: u-u handles failure gracefully in artful and up so with the backport i don't think we need signaling from apt's scripts [14:35] juliank: apt-daily failing is also ok IMO [14:36] I guess even if I signal u-u from apt's script, it's not going to be a regression, it's just setup work. [14:36] So we would not _really_ need dependencies between those two [14:37] It's just that if you upgrade from e.g. 1.5 to 1.5.2 that nothing changes [14:37] but as soon as you upgrade u-u as well, everything works as expected. [14:39] juliank: sending a signal which kills u-u instead of triggering the graceful termination would cause serious regressions [14:39] Compared to just terminating the entire cgroup? [14:40] Currently we terminate the script, u-u, and all children [14:40] the current "broken" fix is only in -proposed. [14:40] juliank: no, comparing to exiting in apt's scripts [14:41] Right, but that's irrelevant seeing as that is only in proposed and has not made it to updates. [14:42] juliank: can i help moving it to release? [14:43] Well, sure if you mark the bug as verified-done, it's basically releasable. Well, xenial needs one more test for bug 1613184 as the specified one does not apply. [14:43] bug 1613184 in apt (Ubuntu Zesty) "method mirror broken at 1.3" [Medium,Fix committed] https://launchpad.net/bugs/1613184 [14:44] But I don't really feel good about it [14:44] juliank: ok, let me take a second look and mark it as such [14:44] You also have to change the testing scenario for the u-u bug [14:44] because it says that stopping apt-daily-upgrade waits until u-u exits [14:44] juliank: yes, the test is wrong [14:44] but it stops immediately. [14:45] I would have never merged the patch if I had known that it does not work that way. [14:46] I mean, the whole timeout thing is nonsense. [14:46] I expected it to actually work as specified. [14:47] juliank: let me follow up in the bug [14:48] juliank: the after a timeout everything gets killed and upgrades can be slow, thus both the timeout and killing only the top process is a must :-\ [14:49] I don't think it does anything. [14:49] juliank: ? [14:49] I mean, the service is considered stopped as soon as the script exits, which is immediately. [14:50] so it already reaches the point we are measuring the timeout for immediately. [14:51] juliank: yes, the timeout starts ticking immediately for killing all children, but how is this a problem? [14:52] The timeout starts when you say stop (and also when you say start). [14:52] But then the service is stopped immediately [14:52] So I don't see how the timeout would work [14:52] juliank: btw instead of signaling you could use u-u --stop-only form 0.98 [14:53] s/form/from/ [14:53] Most of our targets are < 0.98? [14:53] and on 0.98: unattended-upgrade: error: no such option: --stop-only [14:54] juliank: sorry, u-u-s [14:55] juliank: the timeout should prevent killing all running children of the exited service immediately [14:55] What I'm saying is that the timeout should never be elapsing anyway, so nobody will get killed. [14:55] ever. [14:56] Well, at least not if you are stopping. [14:56] Ah it is a TimeoutStopSec [14:56] So yes, you say stop within 900s [14:56] but stopping just stops the script. [14:56] hence it stops immediately. [14:56] juliank: yes [14:57] I don't see the 900s coming into effect if systemd says the service is stopped immediately. [14:57] because 0 < 900 [14:59] https://www.freedesktop.org/software/systemd/man/systemd.kill.html [15:01] Ah you mean "If then, after a delay (configured via the TimeoutStopSec= option), processes still remain, the termination request is repeated with the SIGKILL signal (unless this is disabled via the SendSIGKILL= option)" [15:01] juliank: yes [15:02] let's see [15:02] juliank: and i think the documentation is a bit vague, and the "main" process is geussed based on rules that may end up considering u-u the main process and this case I did not want to have it SIGKILL's immediately [15:04] juliank: so the timeout is a bit of playing safe because the semantics and promises on systemd's side were not crystal-clear [15:04] It actually does not terminate anything [15:05] I just configured the service with a 5s timeout [15:05] added sleep 10000 or something [15:05] stopped it [15:05] sleep is still running [15:05] it's considered: Active: failed (Result: signal) since Thu 2017-11-23 16:04:10 CET; 1min 11s ago [15:05] So the doc is wrong [15:06] juliank: do you have your test case? [15:07] I just changed TimeOutStopSec= to 5, and added a sleep after the whole lock checking thing into the script [15:07] Output: http://paste.ubuntu.com/26028356/ [15:07] juliank: i need to check again but i say timeout taking effect in one of the logs while testing the u-u fix [15:08] rbalint: Maybe you saw the u-u-s timeout? [15:09] juliank: most likely [15:09] The point remains that the patch for apt does not do what it looks like it does. [15:09] juliank: but my bigger concert was systemd picking u-u as the main process despite being a children of apt's script [15:12] rbalint: sorry, I gotta ask: is your n near your t or do you just write concert (as opposed to concern) a lot? Because that seems a really funny typo (and I don't know your keyboard layout) ;) [15:13] I have no idea how the pid guessing works [15:14] Sleep is still running, BTW [15:14] juliank: n->t :-D [15:14] so it really seems to have no effect :) [15:15] um, :( [15:16] juliank: if you decide to go with u-u-s --stop-only in later releases instead of just sending a signal timeout will become useful [15:16] I think I want the signal forwarding for the other executed programs too [15:16] juliank: but yeah now it does not seem to have effect [15:17] my idea was just to stay with SIGUSR1 for zesty and below. I don't know how you plan to SRU them [15:17] juliank: the n->t is brobably due to a funny muscle memory caused by hunger and a screaming baby behind my back :-) [15:18] I think you once wanted to just push 0.98 everywhere, but I'm not sure that's still the plan. [15:18] I think someone said no [15:20] juliank: i could not visit the u-u SRU because i got stuff assigned with higher priorities :-\ [15:21] juliank: IMO there is absolutely no need to signal u-u from apt's scripts because u-u.service does the signaling upon shutdown and in 0.98 it works well finally [15:22] Look, all I want is systemctl stop apt-daily-upgrade to wait until the service is really stopped. [15:22] juliank: if you really want to send signals anyway please don't send them upon upgrade of apt [15:22] juliank: you mean stop when u-u is exited, too? [15:23] yes. [15:23] I don't want runaway processes. [15:23] It's ugly to have one service with runaway processes and another cleaning them up [15:23] juliank: ok, then please keep the timeout and use u-u --stop-only which does wait for you [15:24] juliank: i plan backporting that part for sure to not break on hibernation [15:24] juliank: u-u-s --stop-only [15:25] Then I can just trap "u-u-s --stop-only" SIGTERM I think [15:25] before running u-u [15:25] juliank: also please don't send signal when upgrading apt [15:26] why should I send a signal when upgrading apt? [15:26] I mean, it used to restart the service when upgrading [15:26] but that was a long time ago [15:27] fixed almost a year ago :) [15:27] juliank: ok, then np :-) [15:27] Can you backport the stop-only to stretch as well? That would be vastly useful then I think. [15:27] I'll start with bionic and artful [15:28] The patches for the next artful SRU are collected already :) [15:28] juliank: yes, i plan fixing stretch, too [15:28] juliank: i'm sorry i have to grab something to ead [15:28] eat [15:28] Then in the worst case, all you get is an error message about unsupported --stop-only if you upgrade apt before you upgrade u-u there and in <= zesty :) [15:29] OK [15:29] * juliank does not really eat during the day, he gets sleepy afterwards [15:34] Ew, I still need to forward SIGTERM from the outer apt.systemd.daily invocation to the inner. [15:34] (locking in) shell sucks [15:35] Maybe I should just not do the whole subprocess dance just to avoid fd 3 with a lock file being around. [15:36] # We hold the lock. Rerun this script as a child process, which [15:36] # can run without propagating an extra fd to all of its children. [15:36] ^ this stuff [15:36] My fear is that it leaks into an apt hook or something and never gets released. [15:59] what is the most clear way for one of many autopkgtests in a d/t/control to say "not on this arch"? [15:59] I'm looking for the restrictions spec but it hides from me [16:00] so recomendations welcome [16:02] pitti: in case you are around, I'm sure you knopw :-) ^^ [16:02] afaik that's not possible. so add a if dpkg --print-architecture ...; then in the test [16:02] cpaelzer: there is currently no declarative Architecture: field; your test has to ... that [16:02] I don't see anything in the doc either [16:03] ok, thanks [16:03] unfortunate that this is a Test-Command :-) [16:03] but ok, I know where to change it [16:03] Maybe we should have an architecture field? [16:03] cpaelzer: you can add an if [ arch ] there, too [16:03] cpaelzer: OOI, what's your use case? [16:04] (usually feature tests are preferrable to architecture tests) [16:04] bug 1734148 [16:04] bug 1734148 in resource-agents (Ubuntu) "bionic autopkgtests failing (and blocking since for whatever reason they worked once before)" [Undecided,New] https://launchpad.net/bugs/1734148 [16:04] I have a generic solution for 2/3 [16:04] but for the remaining one I need to mask it on s390x for now [16:05] in the past we usually solved that by resetting the "ever passed" flag and moved it to "always failed" [16:05] I'm so close to make this work, now I want to solve it :-) [16:05] test coverage FTW [16:06] adding an Architecture: restriction to mask a broken test seems wrong to me, particualrly as the test is not intrinsically invalid on s390x? [16:06] on this particular case I want to mask it because I give up on recteating [16:06] so not the best example to discuss such a restriction [16:07] right, understandable - but making it an alwaysfail seems preferrable to me than hacking the source? [16:07] (or more simply, a force-badtest britney hint) [16:07] pitti: this has 14 tests, 13 work [16:07] so masking the one in s390x gives coverage of 13 [16:08] and a hint will just make it go undetected [16:08] ah, ok [16:08] so [ `uname -m` = s390x ] || .. it is? [16:08] yep that is what I'm writing atm [16:08] in the Test-command [16:09] dpkg --print-architecture [16:09] is my choice usually =))))) hehe [17:23] juliank: i get sleepy, too, when i eat sugar and similar carbs, so i don't do that ;-) [17:24] I do eat some cashews [17:24] brain power! [18:03] Hi, any clue why this build has failed ? https://goo.gl/YvqqPQ [18:10] missing #include ? [18:21] mdeslaur: maybe this has something to do ? https://patchwork.kernel.org/patch/9162433 .I couldn't find any other relevant patch. [18:22] NikTh: what are you trying to build exactly? [18:23] mdeslaur: Job: linux_4.14.0-10.201711231748.dsc the log says [18:23] it failed building a userspace tool [18:23] or well, libunwind [18:25] juliank: and only on i386. [18:30] NikTh: Anyhow, probably missing include [18:33] but no, there is an #include [18:35] NikTh: http://kernel.ubuntu.com/git/ubuntu/unstable.git/commit/tools/perf/arch/x86/util/unwind-libunwind.c?id=4443d3b93af3c511e07cfc572803ebfa1f2b1c36 [18:36] NikTh: do you have that? [18:40] mdeslaur: I think you found it! This is great. Let me try building with again, but I'm quite sure that's the solution. [18:40] mdeslaur: Thank you very much ! [18:40] np [21:52] <_9_aleksandr_9_> Hello. I am new Ubuntu user. At the first time when I started Ubuntu from usb flash in live mode I had not problems. Installer had not saw any hard drives. He saw only usb flash. But when I tried to turn on my PC again from usb flash for installing Ubuntu installer not started. I have saw it http://qoo.by/3133 (the link contains also photos of bios). [21:53] _9_aleksandr_9_: hi, you might want to go to #ubuntu for user support [21:54] _9_aleksandr_9_: this channel is for development of ubuntu :) [21:56] <_9_aleksandr_9_> juliank: Unfortunately they don't help me. Maybe you can help. If yes I will be thankful) [22:00] _9_aleksandr_9_: I'm over in #ubuntu now, that's the appropriate forum to discuss this [22:06] <_9_aleksandr_9_> juliank: Ok. I am in #ubuntu also [22:35] <_9_aleksandr_9_> juliank: please watch my video in #ubuntu or ##linux === BrAsS_mOnKeY is now known as g2` [22:56] https://youtu.be/1VvCFWWt6-s