[09:25] <xnox> Laney:  juliank: vorlon: was there something about ARM64 scalingstack and needs-restart autopkgtests? I.e. we don't have a proper way to reboot arm64 instances in such a way, that autopkgtest markers are preserved, etc?
[09:26] <vorlon> xnox: not that I recall.  The only issue I remember is that reboot requests from outside the instance don't work cleanly
[09:26] <xnox> vorlon:  which is what autopkgtest driver does, no?
[09:27] <Laney> not that I know of
[09:27] <Laney> https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-groovy/groovy/arm64/s/systemd/20200919_200612_1c759@/log.gz
[09:27] <Laney> look for "with marker"
[09:27] <xnox> vorlon:  we see dissapearing files in reboot tests as if the VM got shutdown not cleanly.
[09:27] <Laney> and you can see an error in systemd's boot-smoke test, but :>
[09:28] <vorlon> if it's doing a soft OS reboot, I believe that should work as well on arm64 as elsewhere
[09:32] <Laney> I think it executes 'reboot' inside the testbed
[09:32] <Laney> BICBW, do feel free to check the code
[09:33] <xnox> slyon:  why does the cloud-init test do "trap 'rm -f /etc/netplan/00test.yaml' EXIT INT QUIT PIPE TERM" ?
[09:33] <Laney> There's a fallback to doing it via "nova reboot" though, I think, if the "reboot" fails to work
[09:37] <slyon> xnox: Well.. I copied that from the other needs-reboot test (named 'autostart', which works fine on arm64), it is basically just cleaning up the netplan config created during the test
[09:41] <xnox> slyon:  but you don't want it cleaned up, you want it to persist across the reboot, given that you do check for it to be active in the second part of the test.
[09:41] <xnox> slyon:  maybe it should be cleaned up, after being checked for in config) case?
[09:44] <slyon> xnox: hmm I'm not sure which signal autopkgtest uses to stop the process before reboot... probably SIGKILL, as it logs 'bash: line 1:   795 Killed                  /tmp/autopkgtest.SC2r0g/build.fPX/src/debian/tests/cloud-init 2> >(tee -a /tmp/autopkgtest.SC2r0g/cloud-init-stderr >&2) > >(tee -a /tmp/autopkgtest.SC2r0g/cloud-init-stdout)'
[09:45] <slyon> xnox: That file is not delete during the reboot. The netplan YAML is still there and netplan is configured accordingly. The problem is the /netplan-dummy.service file, missing after reboot on arm64
[09:45] <slyon> The trap does not catch SIGKILL and thus should be OK
[10:07] <Laney> slyon: Are you talking about e.g. https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-groovy/groovy/arm64/n/netplan.io/20200917_111620_974b3@/log.gz ?
[10:08] <xnox> Laney:  yeah.
[10:08] <slyon> Laney: yes, exactly
[10:09] <xnox> Laney:  we wrote file to $ cat <<EOF > /netplan-dummy.service successfully, and yet after reboot it is not there
[10:09] <Laney> Bit odd
[10:09] <slyon> The test creates 3 files: /etc/netplan/00test.yaml /netplan-dummy.service /etc/systemd/system/cloud-init-dummy.service
[10:09] <Laney> You also write that dummy cloud-init unit
[10:09] <xnox> as if we need fsync, or like the instance drive is connected with unsafe io
[10:09] <Laney> and that one is still there
[10:09] <slyon> The file /netplan-dummy.service is gone after reboot (on arm64 only)
[10:10] <xnox> as if there was one more reboot inbetween that we didn't know about?!
[10:11] <slyon> xnox: the reboot is triggered via /tmp/autopkgtest-reboot ... I would assume that autopkgtest is doing a sync before cutting power, no?
[10:11] <xnox> slyon:  if clean shutdown is done, yes.
[10:11] <xnox> slyon:  i am actually not sure where in the autopkgtest/cloud code reboot is done.
[10:11] <Laney> why's the file which you write *after* this one still present?
[10:11] <Laney> not sure this sync theory pans out
[10:12] <xnox> slyon:  i wonder if sync would help or not; or if changing mv to cp would help.
[10:12] <xnox> slyon:  because that unit can only succeed once and is in a way self-destructive.
[10:12] <Laney> maybe somehow the service is being started on arm64
[10:12] <Laney> and so the mv happens before the reboot
[10:12] <Laney> and you trash it for the next run
[10:13] <xnox> i would still move the "trap" code to the cleanup at the end of the success too.
[10:13] <slyon> Right.. it shouldn't be a sync issue as the file written afterwards is still there... But doing 'cp' instead of 'mv' might help (although I cannot explain why/how the service would be started in between)
[10:15] <slyon> xnox: I'm fine with moving the trap code. I can prepare an update for that + mv->cp. Shall we then somehow run it through bileto or just give it another shot in -proposed?
[10:16] <xnox> slyon:  your call. I say bileto; vorlon always say just do it in the archive.
[10:17] <xnox> if it's good, doing it in the archive saves rerunning all the things. if it fails, it is still just one run of things.
[10:17] <xnox> doing via bileta, and if everything is fine, results in double usage of our infrastructure
[10:18] <slyon> Yeah.. I'm kind of feeling bad because of bumping the version of that package for the 3rd time for this single issue... So I'm in favor of bileto as well
[10:29] <slyon> xnox, cloud you push that into bileto for me? https://code.launchpad.net/~slyon/netplan/+git/ubuntu/+merge/391039
[10:44] <Laney> I'll run that manually if you want
[10:47] <slyon> Laney: sure, that'd be great. I would just like to have it run somewhere on the infrastructure before moving it to -proposed, as I'm not feeling very confident about this test anymore (too many issues in the past 2 weeks). But I think we're getting close :-)
[10:48] <Laney> :>
[10:48] <Laney> slyon: ok, stand by
[10:53] <Laney> slyon: works
[10:55] <slyon> Laney: wow, that was quick. Thanks! I'll look for sponsoring then
[10:55] <Laney> well I just ran that one test
[10:56] <slyon> yeah, that should be enough
[10:56] <Laney> but the others didn't change, so
[11:43] <Laney> LocutusOfBorg: shall I take a look at gstreamer? we need to get this moving I think
[12:08] <Laney> doing so
[12:12] <ginggs> Laney: on Friday : they still meson-fail to configure : see my ppa locutusofborg-ppa, help is appreciated
[12:13] <Laney> yeah I saw that, thanks
[12:19] <LocutusOfBorg> Laney, I got it building some minutes ago
[12:21] <Laney> k, it needs some work, you can leave it to me
[12:21] <LocutusOfBorg> let me upload it first please
[12:22] <LocutusOfBorg> I need only to recreate the pkgconfig file
[12:25] <Laney> ...
[12:25] <Laney> let me review it then
[12:25] <Laney> do a git merge proposal
[12:27] <LocutusOfBorg> uploaded there https://launchpad.net/~costamagnagianfranco/+archive/ubuntu/locutusofborg-ppa/+packages
[12:28] <xnox> slyon:  pr looks good, I would just rm the 00test.yaml, instead of using trap for it.
[12:28] <xnox> slyon:  afterall you are removing everything else too.
[12:30] <slyon> xnox: right, that looks a bit weird. I just pushed that change to the git repo
[12:31]  * slyon crossing fingers that it passes this time
[12:32] <slyon> thank you for having a look at it!
[12:35] <xnox> well, i bet it only passes when it is run as a single test; rather than with the others muahahhahahhaa
[12:40] <xnox> sil2100:  re:https://bugs.launchpad.net/ubuntu/+source/secureboot-db/+bug/1890835 slow phasing is in place I believe, so we could release focal secureboot-db
[12:41] <xnox> and then like observe that it is phasing slowly
[12:46] <LocutusOfBorg> Laney, I can directly commit on git if needed
[12:46] <LocutusOfBorg> the build looks like finishing, let me check the built debs for sanity and I'll commit
[13:14] <sil2100> xnox: hey! hm, ok, so the phasing machinery is modified and it will be slowly phased as expected, right? I'd still do it one-series-at-a-time if possible
[13:42] <Laney> LocutusOfBorg: ok, you can commit it if you want
[14:14] <xnox> sil2100:  so the branch is merged, and i was told it auto updates.
[14:14] <xnox> sil2100:  so yeah, it would be nice if you could only release focal secureboot-db.
[14:15] <xnox> sil2100:  and then we should monitor the phased-updates report
[14:15] <xnox> sil2100:  to ensure that 12h later, it's still <10% phased.
[14:44] <xnox> bdmurray:  you did see the branch from me that got merged for slow phasing? it was always to slow phase "slow" packages, of which there is currently secureboot-db.
[14:44] <xnox> as we will always want it to be phased slowly.
[14:54] <bdmurray> xnox: I did see that and I could double check the code on whatever server its on just to be sure it landed there
[14:54] <xnox> bdmurray:  ooooh, yes, please.
[14:56] <bdmurray> xnox, sil2100: its good on the server
[14:56] <xnox> hotay
[15:02] <rafaeldtinoco> !dmb-ping
[15:09] <sil2100> Ok, let me look into releasing secureboot-db for focal in that case
[16:01] <abyssangel> hello:)
[16:08] <abyssangel> hello
[16:26] <slyon> netplan's cloud-init test passed, finally! But still the arm64 test needs another retry, due to a timeout in one of the OVS tests... This one passed before, tho, and it should be fine if we re-trigger it. So it would be great if somebody could kick 0.100-0ubuntu4/arm64 here again: https://autopkgtest.ubuntu.com/packages/netplan.io/groovy/arm64
[16:33] <ItzSwirlz> Hey guys, anyone know what happened to gvfs-bin? It's out of the Groovy repos.
[16:34] <ItzSwirlz> It seems libglib2.0-dev is the replacement, correct?
[16:56] <Laney> ItzSwirlz: Yeah, use `gio`
[16:56] <ItzSwirlz> thx
[17:06] <Laney> LocutusOfBorg: https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/4271/+packages
[17:06] <Laney> wish pull-lp-debs downloaded the .changes file too
[17:13] <LocutusOfBorg> thanks Laney <3
[17:14] <LocutusOfBorg> well, the bad needs some i386 fixes
[17:14] <LocutusOfBorg> I already know that...
[17:15] <Laney> rm ? :)
[17:16] <xnox> slyon:  retried
[17:39] <Laney> yeah this needs some more fixing, but I'm timing out noww
[17:39] <Laney> o/
[19:12] <arnatious> sil2100 can I get https://bugs.launchpad.net/ubuntu/+source/python-flake8/+bug/1883175 patches put back into proposed? Or do I need to have my sponsor raise it again?
[19:51] <ahasenack> I have a globbing in debian/foo.install, like /usr/share/foo/*.so
[19:52] <ahasenack> but I want to move some of those *.so files to another package
[19:52] <ahasenack> is there a nice way to exclude the files I'm moving from foo.install without having to list all the ones that should remain?
[19:53] <ahasenack> I thought of an override where, after dh_install, I would just move the files I wanted excluded to the other package's directory
[19:53] <ahasenack> like mv debian/foo/usr/share/foo/{file1,file2}.so debian/foo-bar/usr/share/foo/
[19:54] <ahasenack> I don't think there is an exclude syntax in debian/foo.install
[19:54] <ahasenack> I know of dh_install -X, I'll try that too. I briefly tried with globbing, didn't work, so I'll try again listing the exact files I want excluded
[21:01] <sergiodj> ahasenack: what if you keep the globbing and explicit move the files after it?  you will have to move them from debian/tmp/usr/share/foo/{file1,file2}.so into the new path you want, but it works
[21:01] <ahasenack> yeah
[21:01] <sergiodj> you won't need an override this way
[21:01] <ahasenack> I'm just giving -X another chance
[21:01] <ahasenack> I just found ot about debheper's --remaining-packages
[21:01] <sergiodj> yeah
[21:02] <sergiodj> that's helpful, but in your case I think it's easier to do everything inside the .install file
[21:02] <ahasenack> hm, where should I do the mv then, if not in d/rules?
[21:03] <sergiodj> ah, the problem with doing inside the .install file is that it's just a cp.  you will still need to rm the files
[21:04] <sergiodj> ok, scratch that.  you will need to override the target anyway
[21:04] <ahasenack> ok
[21:04] <sergiodj> sorry about the noise :)
[21:05] <ahasenack> np at all, I want a discussion :)
[21:05] <ahasenack> noise is what I'm hearing outside my window now (rush hour) :D
[21:06] <sergiodj> ;)
[21:08] <sergiodj> I'd override dh_install and be done with it.  not sure if I'd bother using -X, since you will be moving the files anyway
[21:15] <ahasenack> hm, I think it worked
[21:15] <ahasenack> just with -
[21:15] <ahasenack> just with -X
[21:15] <ahasenack> https://pastebin.ubuntu.com/p/FFbKw4QCtR/
[21:16] <ahasenack> I used dh_install -Xglusterfs.so -Xglusterfs_fuse.so -Xvfs_glusterfs.8 -Xvfs_glusterfs_fuse.8 -psamba-vfs-modules
[21:16] <ahasenack> I think I could have used just -Xglusterfs, as docs say it's a substring search
[21:16] <sergiodj> ah, you have multiple packages being generated
[21:16] <sergiodj> I thought it was only one
[21:17] <ahasenack> many indeed
[21:17] <ahasenack> and now one extra
[21:17] <sergiodj> which means you're just interested in not installing certain files into a specific package
[21:17] <sergiodj> cool
[21:18] <sergiodj> makes sense using -X, indeed
[21:19] <ahasenack> debian has the gluster deps as a recommends, instead of depends
[21:19] <ahasenack> meaning a samba share using gluster would break if the gluster libs were removed
[21:19] <ahasenack> but it works by default out of the box, as being a recommends will install the dep
[21:19] <ahasenack> I thought about relaxing to a suggests, then we could do it without a new package, and without pulling gluster into main
[21:20] <ahasenack> but we would be broken out-of-the-box regarding gluster, because it would be just a suggests
[21:20] <ahasenack> so i still think a new bin package is best
[21:21] <LocutusOfBorg> Laney, I'm publishing -good once I confirm the testing is good
[21:50] <LocutusOfBorg> Laney, uploaded the -good one with a minor fix in dh_gstscancodecs
[21:50] <LocutusOfBorg> will let it build everywhere, and check the bad one tomorrow (and upload)