=== cpaelzer__ is now known as cpaelzer
=== ricab is now known as ricab|bbl
[11:19] <mwhudson> ricotz, oSoMoN: good morning, did you get to try my rustc 1.33 packages?
[11:19] <mwhudson> ricotz, oSoMoN: i have hopes that my 7th (!) attempt to build 1.34.1 will succeed
[11:19] <mwhudson> (haven't looked at cargo 0.35 yet)
[11:30] <ricotz> mwhudson, hi, it didn't went so well yet, https://launchpad.net/~ubuntu-mozilla-daily/+archive/ubuntu/ppa/+packages
[11:30] <ricotz> I am about to upload another snapshot
[11:32] <mwhudson> ricotz: "34:25.80 error[E0658]: use of unstable library feature 'integer_atomics' (see issue #32976)" ?
[11:32] <mwhudson> ricotz: is that the actual thing that is breaking the build?
[11:32] <ricotz> yes
[11:32] <mwhudson> hmm
[11:33] <mwhudson> is that something that stabilized in 1.34?
[11:33] <ricotz> the eoan package uses your intermediate 1.34.1
[11:33] <ricotz> the others are 1.33
[11:34] <mwhudson> er
[11:34] <mwhudson> well 1.34.1 hasn't built on amd64 yet
[11:34] <ricotz> correct, but on the other archs
[11:35] <ricotz> let's wait for the next upload
[11:35] <mwhudson> ah right
[11:37] <ricotz> upload is quite slow here, but should be up within the next hour
[11:40] <ricotz> mwhudson, btw you are allowed to use +dfsg0.x to avoid issues with debian tarballs
[11:41] <mwhudson> oh right i gues that would make sense
[11:41] <ricotz> mwhudson, please cancel https://launchpad.net/~mwhudson/+archive/ubuntu/rust-stuff/+build/16794083
[11:41] <mwhudson> ricotz: cancelled
[11:42] <mwhudson> ricotz: we won't ever collide with debian here though because we repack the tarballs differently
[11:42] <ricotz> mwhudson, correct, but if you rebase on an official debian package, it avoids confusion
[11:43] <mwhudson> ricotz: ok
[11:48] <oSoMoN> mwhudson, firefox 67.0+build1 built fine on eoan against rust 1.33 and cargo 0.34
[11:48] <oSoMoN> I didn't test other series
[11:49] <oSoMoN> I had to backport an upstream patch, but that's not a problem in rust itself (https://bugzilla.mozilla.org/1521249)
[11:49] <ubottu> Mozilla bug 1521249 in Internationalization "--enable-rust-simd fails to build using Rust 1.33" [Normal,Resolved: fixed]
[11:51] <mwhudson> _finally_ https://launchpad.net/~mwhudson/+archive/ubuntu/rust-stuff/+build/16795765
[11:52] <mwhudson> oSoMoN, ricotz: would uploading rustc 1.34.1 to eoan be appropriate at this stage? (I'm not going to do it now, maybe in the morning)
[11:56] <ricotz> mwhudson, should be fine if the tests are passing
[11:58] <oSoMoN> mwhudson, yes that's fine
[12:00] <mwhudson> two tests are failing, linkchecker which is probably the fault of my awful hacks to the docs build
[12:00] <mwhudson> and tidy
[12:01] <mwhudson> which fails with 'thread 'main' panicked at 'no entry found for key', src/libcore/option.rs:1038:5"
[12:06] <mwhudson> i guess i'll try to figure out what this is about tomorrow but it doesn't feel like a serious problem somehow
[12:53] <ricotz> mwhudson, fyi, to keep an eye on https://launchpad.net/~ubuntu-mozilla-daily/+archive/ubuntu/ppa/+build/16796388
=== ricab|bbl is now known as ricab
[13:34] <rbasak> xnox: I think I agree about where you're going with PATH in bug 1803958, but in addition, what about all the other "dangerous" environment variables - LD_LIBRARY_PATH, etc? Seems to me that the environment should be cleaned up properly if it needs to be cleaned at all.
[13:34] <ubottu> bug 1803958 in Ubuntu on IBM z Systems "[UBUNTU] zkey: Fails to run commands generated by 'zkey cryptsetup'" [High,In progress] https://launchpad.net/bugs/1803958
[13:34] <rbasak> (not a blocker for SRU - I'm still reviewing)
[14:36] <seb128> rbasak, hey, I reuploaded those xenial SRUs with non private bugs references, sorry for not catching that before uploading
[14:42] <rbasak> seb128: np. I tried to ping you before but you didn't appear to be online
[14:43] <seb128> rbasak, right, I'm at a sprint this week
[14:43] <rbasak> Oh, right.
[17:44] <bdmurray> ddstreet: Can you explain to me how bug 1811471 was fixed again for Ubuntu 18.04? I ask as it seems to have regressed for me.
[17:44] <ubottu> bug 1811471 in systemd (Ubuntu Disco) "local resolver stub fails to handle multiple TCP dns queries" [High,Fix released] https://launchpad.net/bugs/1811471
[17:55] <sarnold> ow :(
[18:09] <bdmurray> xnox: ^^?
[18:46] <ddstreet> bdmurray per xnox that bug was intentionally regressed under the conditions i mention in comment 20
[18:48] <ddstreet> vorlon and xnox, that ^ is what i mentioned when we had the discussion about stripping out edns0
[18:48] <ddstreet> when i mentioned that would regress people experiencing that bug
[18:48] <ddstreet> bdmurray sorry if it's a problem on your systems :(  i had originally suggested backporting the actual upstream systemd fix, which i still think is the best option, but xnox seemed rather against that
[18:49] <ddstreet> maybe i should look again at the tcp pipelining support backporting
[18:49] <bdmurray> ddstreet: I don't really care about my comcast email and I know how to workaround but I worry about other people.
[18:49] <ddstreet> bdmurray as do i
[18:50] <ddstreet> i was overruled by vorlon and xnox at the time we had the discussion
[18:52] <ddstreet> an alternate approach could be to reinstate edns0 into resolv.conf but amke sure there are no cases where /etc/resolv.conf has any nameservers added besides the systemd stub resolver
[18:53] <ddstreet> that's been on my long list for a while actually, as using any resolvers besides systemd can introduce problems
[19:04] <alkisg> Hi, initramfs-tools passes the last cmdline parameter to pid 1 as its cmdline. For example, this tells bash to run sh: init=/bin/bash -c /bin/sh
[19:04] <alkisg> It affects at least bionic and buster. Should I file a bug about it in launchpad/debian?
[19:05] <alkisg> (that also means that if someone puts init=/bin/bash somewhere in the middle of his kernel cmdline, he gets a kernel panic, as bash can't understand its command line, e.g. "quit")
[19:05] <alkisg> *quiet
[19:07] <alkisg> root=/dev/sda1 init=/bin/bash ro quiet splash ==> that would run "/bin/bash vt.handoff=1", and bash would exit with error ==> kernel panic
[19:07] <alkisg> *it would run "/bin/bash splash", sorry, mistyping a lot today :/
[19:07] <ddstreet> bdmurray i opened lp #1829284 to backport tcp pipelining back to b/c :-)
[19:07] <ubottu> Launchpad bug 1829284 in systemd (Ubuntu) "systemd-resolved doesn't support tcp pipelining in b/c" [Undecided,New] https://launchpad.net/bugs/1829284
[19:08] <Pici> 25
[19:17] <TJ-> alkisg: interesting; I cannot see how 'splash' is getting onto the cmdline of /sbin/init - certainly nothing else from the kernel cmdline does, and I don't see anything in the plymouth script that does that, it sets SPLASH=true and that just causes plymouthd to be started
[19:18] <alkisg> TJ-: I think the "read parameters" loop of /usr/share/initramfs-tools/init, reads all the parameters, and "shifts", and then it calls init "$@"
[19:18] <alkisg> So it's passing the last one left, that wasn't shifted
[19:18] <alkisg> Let me dig into it...
[19:19] <alkisg> exec run-init ${drop_caps} ${rootmnt} ${init} "$@" ${recovery:+--startup-event=recovery}
[19:19] <alkisg> While "$@" is whatever was left from some "set" somewhere
[19:21] <TJ-> alkisg: but the loop is reading /proc/cmdline not the init script's args array... or did I miss it reading its own command line?
[19:22] <alkisg> TJ-: I haven't found the exact point yet; true, it's using a for loop without "shift"; also, the kernel doesn't pass any parameters to initramfs' init; finally, in that run-init line, it's using "$@",
[19:23] <alkisg> so, so far, I'm thinking that this comes from some "set -- $var" command somewhere, which sets the last kernel parameter into "$@"
[19:23] <TJ-> alkisg: there are only 3 occurences of "shift" in scripts/functions and none related to the shell command-line (but to function args)
[19:23] <alkisg> TJ-: `set -- quiet` can cause this too; it's not necessary to use shift to cause it
[19:24] <TJ-> alkisg: i just checked here on "cat /proc/1/cmdline" and I see "splash" where /proc/cmdline contains  BOOT_IMAGE=/vmlinuz-4.15.0-49-lowlatency root=/dev/mapper/VG02-rootfs ro no_console_suspend acpi_osi=! "acpi_osi=Windows 2013" splash vt.handoff=7
[19:25] <alkisg> TJ-: oh, so it passed the previous one there, not the last one? Hm...
[19:26] <TJ-> alkisg: right... I agree that the end of init script with $@ does appear to be the source, but I'm not seeing how right now!  exec run-init ${drop_caps} ${rootmnt} ${init} "$@" ...
[19:31] <mwhudson> rbasak: LD_PRELOAD etc are filtered out by glibc for any setuid binary fwiw
[19:37] <TJ-> alkisg: weird, there's only one "set -- ..." and that is in mask2cidr()  !
[19:52] <alkisg> TJ-: it seems to skip all var=value parameters; it doesn't pass those to the init cmdline, it passes all the single-word ones
[19:52] <alkisg> TJ-: which in your example above, is only "splash"
[19:57] <TJ-> alkisg: it doesn't though. See "ro" "no_console_suspend" as well as "splash"
[19:58] <alkisg> This happens from some point and on; e.g. I tried with "a test with var1=value and var2=value" and I got "a test with and"
[19:59] <TJ-> alkisg: interesting, I'm doing:  sudo qemu-system-x86_64 -kernel /boot/vmlinuz-$(uname -r) -initrd /boot/initrd.img-$(uname -r) -append "ro no_console_suspend splash break=top"
[19:59] <TJ-> alkisg: and at the initramfs shell "cat /proc/1/cmdline" shows "/sbin/init" "splash"
[19:59] <TJ-> alkisg: which means *kernel* is passing it :)
[20:01] <alkisg> TJ-: I tried that previously with break=premount and a stock buster vbox vm, and the kernel didn't pass anything to init. Hm...
[20:03] <alkisg> I put "echo $*" in various places of initramfs-tools/init; they're all not showing the var=value parts
[20:04] <TJ-> alkisg: they won't, the values are all in /proc/cmdline
[20:05] <alkisg> They all show the plain "word" parameters
[20:05] <alkisg> ==> e.g. I tried with "a test with var1=value and var2=value" and I got "a test with and"
[20:05] <TJ-> alkisg: kernel's init/main.c::run_init_process() calls the init and sues arg_init[] which is populated thus:
[20:05] <TJ-> /* Anything after -- gets handed straight to init. */
[20:05] <TJ-> static int __init set_init_arg(char *param, char *val,
[20:06] <TJ-> alkisg: so is that somehow getting confused?
[20:06] <alkisg> Let me try completely on top of initramfs/init; if the problem is there too, then yes it's a kernel issue
[20:08] <alkisg> TJ-: oh my, yup, indeed. If "word1 var1=value word2 var2=value" is used in grub, then the kernel calls init with "word1 word2"
[20:09] <TJ-> alkisg: and start_kernl() has after_dashes = parse_args("Booting kernel",
[20:11] <TJ-> alkisg: aha! see static int __init unknown_bootoption() ... "/ * Unknown boot options get handed to init, unless they look like ..."
[20:14] <alkisg> ...I can't make any sense of that. In what point would one want /bin/bash to receive a "quiet splash" parameter? :/
[20:16] <alkisg> ...and it's receiving only the "single words that follow" init=/sbin/init; not the ones before; not the var=value parameters after
[20:16] <TJ-> alkisg: right, because the kernel detects those
[20:17] <alkisg> At least this allows for clean instructions: "put init=/bin/bash at the end of the cmdline, or else hell will break loose"
[20:19] <TJ-> in unknown_bootoption() any key=val is treated as an environment variable, anything without a value is treated as an init_arg *if* all prior tests did not 'consume' the option
[20:20] <TJ-> alkisg: and indeed, in the initialramfs do "env" you see all the key=value options
[20:22] <alkisg> I really can't imagine in which case "init" will find this butchered "$@" useful
[20:22] <TJ-> alkisg: actually, you have to do "cat /proc/1/environ" to see it
[20:23] <TJ-> alkisg: it's essential, it would handle passing systemd.log_level= and all other such options to init
[20:25] <alkisg> TJ-: the kernel will remove that parameter and will not pass it to init, because it contains the equals sign
[20:32] <bdmurray> manjo: The test case in bug 1764628 contains the same output for expected behavior and actual behavior... so is the SRU necessary or does the test cased need fixing?
[20:32] <ubottu> bug 1764628 in util-linux (Ubuntu Xenial) "incorrect hypervisor and virtualization type reported in compat mode guest" [Medium,Fix committed] https://launchpad.net/bugs/1764628
[20:33] <manjo> bdmurray, looking
[20:34] <manjo> bdmurray, ouch.. I think that is a cut and past mistake
[20:35] <manjo> bdmurray, if you look comment #7 you should see before and after patch
[20:35] <manjo> bdmurray, I will mod the description to say see comment #7 for test
[20:36] <bdmurray> manjo: Instead of just changing Hypervisor vendor to horizontal?
[20:37] <manjo> ah or I can do that .. let me modify the description
[20:38] <manjo> bdmurray, fixed description
[20:39] <bdmurray> manjo: cool, accepted
[20:39] <manjo> thanks!