=== cpaelzer__ is now known as cpaelzer
=== ricab is now known as ricab|bbl
mwhudsonricotz, oSoMoN: good morning, did you get to try my rustc 1.33 packages?11:19
mwhudsonricotz, oSoMoN: i have hopes that my 7th (!) attempt to build 1.34.1 will succeed11:19
mwhudson(haven't looked at cargo 0.35 yet)11:19
ricotzmwhudson, hi, it didn't went so well yet, https://launchpad.net/~ubuntu-mozilla-daily/+archive/ubuntu/ppa/+packages11:30
ricotzI am about to upload another snapshot11:30
mwhudsonricotz: "34:25.80 error[E0658]: use of unstable library feature 'integer_atomics' (see issue #32976)" ?11:32
mwhudsonricotz: is that the actual thing that is breaking the build?11:32
mwhudsonis that something that stabilized in 1.34?11:33
ricotzthe eoan package uses your intermediate 1.34.111:33
ricotzthe others are 1.3311:33
mwhudsonwell 1.34.1 hasn't built on amd64 yet11:34
ricotzcorrect, but on the other archs11:34
ricotzlet's wait for the next upload11:35
mwhudsonah right11:35
ricotzupload is quite slow here, but should be up within the next hour11:37
ricotzmwhudson, btw you are allowed to use +dfsg0.x to avoid issues with debian tarballs11:40
mwhudsonoh right i gues that would make sense11:41
ricotzmwhudson, please cancel https://launchpad.net/~mwhudson/+archive/ubuntu/rust-stuff/+build/1679408311:41
mwhudsonricotz: cancelled11:41
mwhudsonricotz: we won't ever collide with debian here though because we repack the tarballs differently11:42
ricotzmwhudson, correct, but if you rebase on an official debian package, it avoids confusion11:42
mwhudsonricotz: ok11:43
oSoMoNmwhudson, firefox 67.0+build1 built fine on eoan against rust 1.33 and cargo 0.3411:48
oSoMoNI didn't test other series11:48
oSoMoNI had to backport an upstream patch, but that's not a problem in rust itself (https://bugzilla.mozilla.org/1521249)11:49
ubottuMozilla 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/1679576511:51
mwhudsonoSoMoN, 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
ricotzmwhudson, should be fine if the tests are passing11:56
oSoMoNmwhudson, yes that's fine11:58
mwhudsontwo tests are failing, linkchecker which is probably the fault of my awful hacks to the docs build12:00
mwhudsonand tidy12:00
mwhudsonwhich fails with 'thread 'main' panicked at 'no entry found for key', src/libcore/option.rs:1038:5"12:01
mwhudsoni guess i'll try to figure out what this is about tomorrow but it doesn't feel like a serious problem somehow12:06
ricotzmwhudson, fyi, to keep an eye on https://launchpad.net/~ubuntu-mozilla-daily/+archive/ubuntu/ppa/+build/1679638812:53
=== ricab|bbl is now known as ricab
rbasakxnox: 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
ubottubug 1803958 in Ubuntu on IBM z Systems "[UBUNTU] zkey: Fails to run commands generated by 'zkey cryptsetup'" [High,In progress] https://launchpad.net/bugs/180395813:34
rbasak(not a blocker for SRU - I'm still reviewing)13:34
seb128rbasak, hey, I reuploaded those xenial SRUs with non private bugs references, sorry for not catching that before uploading14:36
rbasakseb128: np. I tried to ping you before but you didn't appear to be online14:42
seb128rbasak, right, I'm at a sprint this week14:43
rbasakOh, right.14:43
bdmurrayddstreet: 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
ubottubug 1811471 in systemd (Ubuntu Disco) "local resolver stub fails to handle multiple TCP dns queries" [High,Fix released] https://launchpad.net/bugs/181147117:44
sarnoldow :(17:55
bdmurrayxnox: ^^?18:09
ddstreetbdmurray per xnox that bug was intentionally regressed under the conditions i mention in comment 2018:46
ddstreetvorlon and xnox, that ^ is what i mentioned when we had the discussion about stripping out edns018:48
ddstreetwhen i mentioned that would regress people experiencing that bug18:48
ddstreetbdmurray 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 that18:48
ddstreetmaybe i should look again at the tcp pipelining support backporting18:49
bdmurrayddstreet: I don't really care about my comcast email and I know how to workaround but I worry about other people.18:49
ddstreetbdmurray as do i18:49
ddstreeti was overruled by vorlon and xnox at the time we had the discussion18:50
ddstreetan 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 resolver18:52
ddstreetthat's been on my long list for a while actually, as using any resolvers besides systemd can introduce problems18:53
alkisgHi, 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/sh19:04
alkisgIt 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
alkisgroot=/dev/sda1 init=/bin/bash ro quiet splash ==> that would run "/bin/bash vt.handoff=1", and bash would exit with error ==> kernel panic19:07
alkisg*it would run "/bin/bash splash", sorry, mistyping a lot today :/19:07
ddstreetbdmurray i opened lp #1829284 to backport tcp pipelining back to b/c :-)19:07
ubottuLaunchpad bug 1829284 in systemd (Ubuntu) "systemd-resolved doesn't support tcp pipelining in b/c" [Undecided,New] https://launchpad.net/bugs/182928419:07
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 started19:17
alkisgTJ-: 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
alkisgSo it's passing the last one left, that wasn't shifted19:18
alkisgLet me dig into it...19:18
alkisgexec run-init ${drop_caps} ${rootmnt} ${init} "$@" ${recovery:+--startup-event=recovery}19:19
alkisgWhile "$@" is whatever was left from some "set" somewhere19: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
alkisgTJ-: 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
alkisgso, 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
alkisgTJ-: `set -- quiet` can cause this too; it's not necessary to use shift to cause it19: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=719:24
alkisgTJ-: 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
mwhudsonrbasak: LD_PRELOAD etc are filtered out by glibc for any setuid binary fwiw19:31
TJ-alkisg: weird, there's only one "set -- ..." and that is in mask2cidr()  !19:37
alkisgTJ-: it seems to skip all var=value parameters; it doesn't pass those to the init cmdline, it passes all the single-word ones19:52
alkisgTJ-: 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
alkisgThis 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
alkisgTJ-: 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
alkisgI put "echo $*" in various places of initramfs-tools/init; they're all not showing the var=value parts20:03
TJ-alkisg: they won't, the values are all in /proc/cmdline20:04
alkisgThey all show the plain "word" parameters20: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
alkisgLet me try completely on top of initramfs/init; if the problem is there too, then yes it's a kernel issue20:06
alkisgTJ-: 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 after20:16
TJ-alkisg: right, because the kernel detects those20:16
alkisgAt 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 option20:19
TJ-alkisg: and indeed, in the initialramfs do "env" you see all the key=value options20:20
alkisgI really can't imagine in which case "init" will find this butchered "$@" useful20:22
TJ-alkisg: actually, you have to do "cat /proc/1/environ" to see it20:22
TJ-alkisg: it's essential, it would handle passing systemd.log_level= and all other such options to init20:23
alkisgTJ-: the kernel will remove that parameter and will not pass it to init, because it contains the equals sign20:25
bdmurraymanjo: 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
ubottubug 1764628 in util-linux (Ubuntu Xenial) "incorrect hypervisor and virtualization type reported in compat mode guest" [Medium,Fix committed] https://launchpad.net/bugs/176462820:32
manjobdmurray, looking20:33
manjobdmurray, ouch.. I think that is a cut and past mistake20:34
manjobdmurray, if you look comment #7 you should see before and after patch20:35
manjobdmurray, I will mod the description to say see comment #7 for test20:35
bdmurraymanjo: Instead of just changing Hypervisor vendor to horizontal?20:36
manjoah or I can do that .. let me modify the description20:37
manjobdmurray, fixed description20:38
bdmurraymanjo: cool, accepted20:39

Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!