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