[13:31] <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:34]  * tseliot lookinh
[13:34] <tseliot> *looking
[13:35] <tseliot> ginggs: something probably broke in bionic. I'm creating a chroot to check that out
[14:07] <ginggs> tseliot: thanks
[14:16] <tseliot> ginggs: apt-get build-dep eztrace works fine in the chroot
[14:17] <tseliot> maybe the archive was temporarily broken?
[14:19] <ginggs> tseliot: i gave them back an hour ago, and they've been retried a few times in the last 3 weeks
[14:20] <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:21] <juliank> rbalint: Not only that, it also breaks the locking between the two apt-daily services
[14:22] <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:24] <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:25] <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:27] <rbalint> juliank: i'm not sure what problem would be caused by starting apt-daily while apt-daily-upgrade is running
[14:28] <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:29] <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:30] <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:31] <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:32] <juliank> There are 4 locks involved, and one lock is repeatedly released.
[14:33] <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:34] <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:35] <rbalint> juliank: apt-daily failing is also ok IMO
[14:36] <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:37] <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:39] <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:40] <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:41] <juliank> Right, but that's irrelevant seeing as that is only in proposed and has not made it to updates.
[14:42] <rbalint> juliank: can i help moving it to release?
[14:43] <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:44] <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:45] <juliank> I would have never merged the patch if I had known that it does not work that way.
[14:46] <juliank> I mean, the whole timeout thing is nonsense.
[14:46] <juliank> I expected it to actually work as specified.
[14:47] <rbalint> juliank: let me follow up in the bug
[14:48] <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:49] <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:50] <juliank> so it already reaches the point we are measuring the timeout for immediately.
[14:51] <rbalint> juliank: yes, the timeout starts ticking immediately for killing all children, but how is this a problem?
[14:52] <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:53] <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:54] <rbalint> juliank: sorry, u-u-s
[14:55] <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:56] <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:57] <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:59] <rbalint> https://www.freedesktop.org/software/systemd/man/systemd.kill.html
[15:01] <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:02] <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:04] <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:05] <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:06] <rbalint> juliank: do you have your test case?
[15:07] <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:08] <juliank> rbalint: Maybe you saw the u-u-s timeout?
[15:09] <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:12] <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:13] <juliank> I have no idea how the pid guessing works
[15:14] <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:15] <juliank> um, :(
[15:16] <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:17] <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:18] <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:20] <rbalint> juliank: i could not visit the u-u SRU because i got stuff assigned with higher priorities :-\
[15:21] <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:22] <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:23] <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:24] <rbalint> juliank: i plan backporting that part for sure to not break on hibernation
[15:24] <rbalint> juliank: u-u-s --stop-only
[15:25] <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:26] <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:27] <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:28] <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:29] <juliank> OK
[15:29]  * juliank does not really eat during the day, he gets sleepy afterwards
[15:34] <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:35] <juliank> Maybe I should just not do the whole subprocess dance just to avoid fd 3 with a lock file being around.
[15:36] <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:59] <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
[16:00] <cpaelzer> so recomendations welcome
[16:02] <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:03] <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:04] <pitti> (usually feature tests are preferrable to architecture tests)
[16:04] <cpaelzer> bug 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:05] <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:06] <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:07] <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:08] <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:09] <xnox> dpkg --print-architecture
[16:09] <xnox> is my choice usually =))))) hehe
[17:23] <rbalint> juliank: i get sleepy, too, when i eat sugar and similar carbs, so i don't do that ;-)
[17:24] <juliank> I do eat some cashews
[17:24] <juliank> brain power!
[18:03] <NikTh> Hi, any clue why this build has failed ? https://goo.gl/YvqqPQ
[18:10] <mdeslaur> missing #include <errno.h> ?
[18:21] <NikTh> mdeslaur: maybe this has something to do ? https://patchwork.kernel.org/patch/9162433 .I couldn't find any other relevant patch.
[18:22] <mdeslaur> NikTh: what are you trying to build exactly?
[18:23] <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:25] <NikTh> juliank: and only on i386.
[18:30] <juliank> NikTh: Anyhow, probably missing include
[18:33] <juliank> but no, there is an #include <errno.h>
[18:35] <mdeslaur> NikTh: http://kernel.ubuntu.com/git/ubuntu/unstable.git/commit/tools/perf/arch/x86/util/unwind-libunwind.c?id=4443d3b93af3c511e07cfc572803ebfa1f2b1c36
[18:36] <mdeslaur> NikTh: do you have that?
[18:40] <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
[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] <juliank> _9_aleksandr_9_: hi, you might want to go to #ubuntu for user support
[21:54] <juliank> _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] <juliank> _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
[22:56] <cesdo> https://youtu.be/1VvCFWWt6-s