| === cpaelzer__ is now known as cpaelzer | ||
| === ricab is now known as ricab|bbl | ||
| 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:19 |
| 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:30 |
| 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:32 |
| 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:33 |
| 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:34 |
| ricotz | let's wait for the next upload | 11:35 |
| mwhudson | ah right | 11:35 |
| ricotz | upload is quite slow here, but should be up within the next hour | 11:37 |
| ricotz | mwhudson, btw you are allowed to use +dfsg0.x to avoid issues with debian tarballs | 11:40 |
| 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:41 |
| 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:42 |
| mwhudson | ricotz: ok | 11:43 |
| 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:48 |
| 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:49 |
| mwhudson | _finally_ https://launchpad.net/~mwhudson/+archive/ubuntu/rust-stuff/+build/16795765 | 11:51 |
| 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:52 |
| ricotz | mwhudson, should be fine if the tests are passing | 11:56 |
| oSoMoN | mwhudson, yes that's fine | 11:58 |
| 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:00 |
| mwhudson | which fails with 'thread 'main' panicked at 'no entry found for key', src/libcore/option.rs:1038:5" | 12:01 |
| 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:06 |
| ricotz | mwhudson, fyi, to keep an eye on https://launchpad.net/~ubuntu-mozilla-daily/+archive/ubuntu/ppa/+build/16796388 | 12:53 |
| === ricab|bbl is now known as ricab | ||
| 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) | 13:34 |
| seb128 | rbasak, hey, I reuploaded those xenial SRUs with non private bugs references, sorry for not catching that before uploading | 14:36 |
| rbasak | seb128: np. I tried to ping you before but you didn't appear to be online | 14:42 |
| seb128 | rbasak, right, I'm at a sprint this week | 14:43 |
| rbasak | Oh, right. | 14:43 |
| 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:44 |
| sarnold | ow :( | 17:55 |
| bdmurray | xnox: ^^? | 18:09 |
| ddstreet | bdmurray per xnox that bug was intentionally regressed under the conditions i mention in comment 20 | 18:46 |
| 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:48 |
| 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:49 |
| ddstreet | i was overruled by vorlon and xnox at the time we had the discussion | 18:50 |
| 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:52 |
| ddstreet | that's been on my long list for a while actually, as using any resolvers besides systemd can introduce problems | 18:53 |
| 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:04 |
| 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:05 |
| 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:07 |
| Pici | 25 | 19:08 |
| 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:17 |
| 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:18 |
| 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:19 |
| 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:21 |
| 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:22 |
| 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:23 |
| 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:24 |
| alkisg | TJ-: oh, so it passed the previous one there, not the last one? Hm... | 19:25 |
| 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:26 |
| mwhudson | rbasak: LD_PRELOAD etc are filtered out by glibc for any setuid binary fwiw | 19:31 |
| TJ- | alkisg: weird, there's only one "set -- ..." and that is in mask2cidr() ! | 19:37 |
| 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:52 |
| TJ- | alkisg: it doesn't though. See "ro" "no_console_suspend" as well as "splash" | 19:57 |
| 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:58 |
| 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 :) | 19:59 |
| 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:01 |
| alkisg | I put "echo $*" in various places of initramfs-tools/init; they're all not showing the var=value parts | 20:03 |
| TJ- | alkisg: they won't, the values are all in /proc/cmdline | 20:04 |
| 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:05 |
| 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:06 |
| 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:08 |
| TJ- | alkisg: and start_kernl() has after_dashes = parse_args("Booting kernel", | 20:09 |
| TJ- | alkisg: aha! see static int __init unknown_bootoption() ... "/ * Unknown boot options get handed to init, unless they look like ..." | 20:11 |
| alkisg | ...I can't make any sense of that. In what point would one want /bin/bash to receive a "quiet splash" parameter? :/ | 20:14 |
| 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:16 |
| 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:17 |
| 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:19 |
| TJ- | alkisg: and indeed, in the initialramfs do "env" you see all the key=value options | 20:20 |
| 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:22 |
| TJ- | alkisg: it's essential, it would handle passing systemd.log_level= and all other such options to init | 20:23 |
| alkisg | TJ-: the kernel will remove that parameter and will not pass it to init, because it contains the equals sign | 20:25 |
| 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:32 |
| manjo | bdmurray, looking | 20:33 |
| manjo | bdmurray, ouch.. I think that is a cut and past mistake | 20:34 |
| 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:35 |
| bdmurray | manjo: Instead of just changing Hypervisor vendor to horizontal? | 20:36 |
| manjo | ah or I can do that .. let me modify the description | 20:37 |
| manjo | bdmurray, fixed description | 20:38 |
| bdmurray | manjo: cool, accepted | 20:39 |
| manjo | thanks! | 20:39 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!