=== thegodfather is now known as fabbione
[10:47] <cpaelzer> hi, when having autopkgtest run for the kernel I face something that surely isn't from my packages change
[10:47] <cpaelzer> it is listed as
[10:47] <cpaelzer> autopkgtest for linux/unknown: amd64: Regression ♻ , ppc64el: Regression ♻
[10:47] <cpaelzer> and the TL;DR is broken dependencies like
[10:47] <cpaelzer> linux-generic : Depends: linux-image-generic (= 4.17.0.7.10) but 4.17.0.6.9 is to be installed
[10:48] <cpaelzer> is that a kernel in flight to be released - or anything else that often happens and the way to get around it being clear?
[11:03] <smb> sforshee, ^ maybe you know?
=== vila_ is now known as vila
[12:08] <sforshee> cpaelzer: that's because there's a window when linux-meta has been built but linux-signed has not yet, during that window you could end up with something like that
[12:10] <sforshee> and in some cases that window can be long if there are signed bits waiting in the unapproved queue, which linux-signed needs to build
[12:16] <cpaelzer> sforshee: so what is my todo on this - wait an retry daily/hourly/...
[12:16] <cpaelzer> sforshee: or is there something I can look at to realize I'm unblocked and hit retry juts once?
[12:17] <cpaelzer> the transition of most recent linxu-signed or so I guess
[12:18] <cpaelzer> sforshee: so when https://launchpad.net/ubuntu/+source/linux-signed/4.17.0-7.8 hits c-release maybe?
[12:30] <sforshee> cpaelzer: yeah that would be the thing to watch for
[12:31] <sforshee> cpaelzer: or c-proposed rather
[12:37] <cpaelzer> in c-proposed it is sforshee
[12:37] <cpaelzer> maybe I need a combined trigger to pull it from there for the test
[12:47] <Saviq> hi all, I'm trying to boot ubuntu-minimal in KVM and both 16.04 and 18.04 fail to go past the bootloader, complaining about missing root or hanging with no info, any suggestions?
=== benny is now known as Guest16531
[13:02] <ahasenack> Saviq: you mean you are trying to boot the installed system, which you installed from the iso and selected "minimal installation"?
[13:02] <Saviq> ahasenack: no, trying to boot ubuntu-minimal http://cloud-images.ubuntu.com/minimal/releases/
[13:03] <ahasenack> oh, I didn't know about that, I thought it was just an installation target
[13:03] <ahasenack> those files are not isos
[13:03] <ahasenack> they are cloud images if I'm not mistaken
[13:03] <ahasenack> "The Ubuntu Minimal Cloud image can be run on your personal Ubuntu Cloud, or on public clouds that provide Ubuntu Certified Images."
[13:04] <ahasenack> there is a note about kvm: "When launching the download image from KVM, you will need to specify the virtio network driver."
[13:04] <ahasenack> but that sounds like something that would create problems only after it found the root device
[13:05] <Saviq> ahasenack: yeah, they're qcow2 images that should at least try and boot (and fail to find the networking adapter if virtio wasn't used)
[13:05] <Saviq> it seems like something's wrong with how grub is set up there
[13:12] <cpaelzer> sforshee: I just found linux-signed in proposed is 4.17.0-7.8 but the linux-meta is 4.17.0-7.10
[13:12] <cpaelzer> so while something is in proposed it is not what I waited for :-/
[13:13] <cpaelzer> I've added a linux-meta trigger on 4.17.0-7.10 and will see if that is enough
[13:21] <sforshee> cpaelzer: no that's fine, it's the 4.17.0-7 that's important
[13:22] <smoser> xnox: around ?
[13:22] <smoser> looking at update excuses for software-properties
[13:22] <smoser> https://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html
[13:23] <sforshee> cpaelzer: though note that for linux-meta it's 4.17.0.7.10
[13:24] <sforshee> but that last bit, the upload number, doesn't have to match between the two
[13:24] <cpaelzer> ok
[13:24] <cpaelzer> the autopkgtest cgi complains anyway if the version is bad, so I certainly specified a good one (with .10)
[13:32] <Odd_Bloke> Saviq: Could you file a bug in the cloud-images project on Launchpad, please?
[13:32] <Saviq> Odd_Bloke: ack
[13:47] <Saviq> Odd_Bloke: https://bugs.launchpad.net/cloud-images/+bug/1785633
[13:47] <ubottu> Launchpad bug 1785633 in cloud-images "Can't boot minimal images in QEMU" [Undecided,New]
=== thegodfather is now known as fabbione
[14:38] <Odd_Bloke> Thanks!
=== Guest26876 is now known as giraffe
=== lan3y is now known as Laney
[15:26] <Odd_Bloke> Saviq: I've added an update to https://bugs.launchpad.net/cloud-images/+bug/1785633
[15:26] <ubottu> Launchpad bug 1785633 in cloud-images "Can't boot minimal images in QEMU" [High,Confirmed]
[15:40] <Saviq> Odd_Bloke: ack!
[16:36] <kyrofa> Laney, do I remember correctly that you're the autopkgtest master these days?
[16:38] <Laney> kyrofa: There's a few of us - which is handy, because I'm going in 2 minutes. :P
[16:38] <kyrofa> Laney, ah! Good then. I can't seem to install snaps in armhf autopkgtests, do you (or anyone) know anything about that?
[16:39] <Laney> what happens?
[16:39] <Laney> I don't think we do anything specifically to prevent that working
[16:40] <kyrofa> Laney, "error: cannot communicate with server: Post http://localhost/v2/snaps/go: dial unix /run/snapd.socket: connect: connection refused"
[16:41] <Laney> dunno - is it running?
[16:41] <Laney> You can use autopkgtest-build-lxd to make a container on your system, that might help
[16:41] <kyrofa> Honestly I'm not sure. This same test works on other architectures fine
[16:41] <kyrofa> It's just armhf that has that issue
[16:41] <kyrofa> If I could only get a shell :P
[16:42] <Laney> this one runs in lxd and the others are VMs, that's the main difference
[16:42] <kyrofa> Oh interesting
[16:43]  * Laney hands you over to slangasek (if he's here)
[16:43] <kyrofa> When developing this test I ran with autopkgtest-virt-lxd, so I know it works there at least in amd64
[16:44] <kyrofa> Thanks Laney :)
[16:48] <slangasek> kyrofa: so at a glance, it appears the snapd package is not installed in the armhf autopkgtest containers by default.  That may be something we want to fix, but perhaps you want an explicit test dependency on snapd?
[16:48] <slangasek> kyrofa: which autopkgtest is failing?
[16:49] <kyrofa> slangasek, we have one, actually
[16:49] <slangasek> ok
[16:49] <kyrofa> slangasek, it's a new one we're adding, you can see a log here: https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-xenial-snappy-dev-snapcraft-daily/xenial/armhf/s/snapcraft/20180804_011910_96ebe@/log.gz
[16:50] <kyrofa> The test is integrationtests-spread
[16:53] <slangasek> kyrofa: where do I see the source for the version of the package under test?
[16:54] <kyrofa> slangasek, it's in a pull request at the moment: https://github.com/snapcore/snapcraft/pull/2188
[16:55] <kyrofa> You'll want to skip the latest commit though, it's skipping the tests that install snaps on armhf
[16:59] <slangasek> kyrofa: https://paste.ubuntu.com/p/wmjKV3q5vc/
[16:59] <slangasek> is this related to the squashfs fuse stuff not being installed by default?
[17:01] <kyrofa> slangasek, ah, interesting, I don't need that in lxd anymore since snapd started bundling something that made it work
[17:01] <kyrofa> Where is that bug...
[17:02] <kyrofa> bug #1628289
[17:02] <ubottu> bug 1628289 in snapd (Ubuntu) "snapd should depend on squashfuse (for use in containers)" [Medium,Incomplete] https://launchpad.net/bugs/1628289
[17:03] <kyrofa> Oh yeah, fuse.snapfuse, that sounds bundled
[17:05] <slangasek> kyrofa: there is no 'fuse.squashfuse' command in either the snapd or squashfuse packages in xenial (at least on armhf).  So I don't know how this is supposed to be wired up.
[17:06] <kyrofa> Yeah, me neither. mvo, are you around?
=== Pici` is now known as Pici
[17:07] <mvo> kyrofa: sort of - I hear ./usr/bin/snapfuse ?
[17:09] <kyrofa> mvo, having trouble installing snaps in armhf autopkgtests, slangasek was able to produce https://paste.ubuntu.com/p/wmjKV3q5vc/
[17:11] <slangasek> mvo, kyrofa: 'ln -s /usr/bin/squashfuse /sbin/mount.fuse.squashfuse' works around it
[17:12] <slangasek> not sure if /usr/bin/snapfuse works the same
[17:12] <slangasek> signs point to yes
[17:13] <mvo> slangasek: oh, interessting. I wonder what is going on there, fwiw, we have a automatic test that runs snaps inside lxd without squashfs-fuse or any other modifications
[17:13] <mvo> kyrofa: looking
[17:13] <mvo> kyrofa: what do I need to do to reproduce this?
[17:14] <kyrofa> mvo, indeed, this same test runs fine in amd64 lxd
[17:14] <slangasek> kyrofa: on xenial?
[17:14] <kyrofa> mvo, you need the magical shell slangasek got :P
[17:14] <kyrofa> slangasek, yes
[17:14] <slangasek> k
[17:14] <kyrofa> slangasek, to clarify, I'm running bionic, but I developed the test using `autopkgtest . -U -- lxd ubuntu:xenial`
[17:15] <slangasek> right
[17:15] <mvo> oh, so this is lxd inside armhf?
[17:15] <slangasek> well, the host is arm64
[17:16] <slangasek> the container is armhf
[17:17] <kyrofa> And Laney mentioned that this is the only arch that works that way-- the others are VMs
[17:17] <mvo> I can try this on my pi3 tomorrow
[17:18] <slangasek> yes, and "the host is arm64" is precisely why we do armhf in containers
[17:19] <slangasek> anyway, seems like a strange error message, hopefully that points to something
[17:20] <kyrofa> mvo, thank you for looking into it!
[17:21] <kyrofa> slangasek, thanks very much for your help. It sounds like I can work around this for now by symlinking /usr/bin/snapfuse to /sbin/mount.fuse.snapfuse ?
[17:22] <slangasek> kyrofa: yes, it appears that works around it
[17:22] <slangasek> at least as far as letting snapd start
[17:22] <kyrofa> slangasek, alright, I'll take a crack at it for the whole test, let's see
[17:37] <mvo> kyrofa, slangasek fwiw, the squashfuse deb also only ships./usr/bin/squashfuse  and no fuse.squashfsuse symlinks or anything like this afaict
[17:40] <kyrofa> Very interesting
[17:40] <slangasek> yeah, I have no idea how this works on !armhf
[17:44] <dami0> hi, how do i change the default command line options when respining an iso? i tried grub.cfg in /boot/grub, tried gfxboot.cfg in isolinux, searched on google and only got advice to change grub.cfg
[17:48] <TJ-> dami0: which options, for booting the ISO live, or for installing the OS?
[17:49] <dami0> installing the os
[17:49] <dami0> what i want to accomplish in the end is have a few custom entries in the boot menu for installing with different ks.cfg files predefined on the menu options
[17:57] <TJ-> I recall that you achieve that by editing the kernel command-line of the ISO boot loader (GRUB and isolinux/syslinux) and add the entries you want the installer to add to the installed system after a "--" ... e.g. for GRUB "linux vmlinuz-$VERSION param1=one param2=two -- param1=three" will boot the installer with param1=one but set the installed command-line to param1=three
[18:01] <kyrofa> slangasek, beyond copyright and docs, squashfuse indeed only includes the /usr/bin/squashfuse binary. No symlinks, as mvo said. However, something knows that all it needs is the squashfuse command: sudo mount -t fuse.squashfuse hello_20.snap foo
[18:01] <kyrofa> /bin/sh: 1: squashfuse: not found
[18:02] <kyrofa> (I removed both snapd and squashfuse for testing)
[18:02] <slangasek> interesting
[18:02] <mvo> slangasek: https://github.com/libfuse/libfuse/blob/master/util/mount.fuse.c#L103 is how the mount works, I wonder why this is different on armhf, it just strips the leading fuse. and tries to run the binary
[18:02] <mvo> kyrofa: -^
[18:03] <mvo> I mean, this is why it does not need the fuse.snapfuse
[18:03] <kyrofa> mvo, which explains what I just found
[18:03] <mvo> ups, wrong line: https://github.com/libfuse/libfuse/blob/master/util/mount.fuse.c#L137
[18:03] <mvo> this is the right one
[18:03] <mvo> kyrofa: yeah
[18:04] <slangasek> mvo, kyrofa: ok, and does something ensure mount.fuse is installed?
[18:04] <slangasek> it's only 'standard'
[18:05] <slangasek> and wasn't present in the container I was looking at
[18:06] <slangasek> so if 'mount' can't resolve either mount.fuse.squashfuse or mount.fuse, I don't expect it knows what to do here
[18:07] <kyrofa> slangasek, wait, /sbin/mount.fuse wasn't present in the container you were looking at?
[18:07] <slangasek> correct
[18:07] <kyrofa> Huh, it's here on amd64
[18:07] <slangasek> our containers use a different image
[18:08] <slangasek> autopkgtests shouldn't assume ubuntu-standard
[18:08] <slangasek> should snapd depend on fuse?
[18:08] <slangasek> or should it just install its own mount.imasnap ?
[18:10] <kyrofa> Great question
[18:12] <kyrofa> slangasek, does that mean that running `autopkgtest . -U -- lxd ubuntu:xenial` is not actually giving me a representative image?
[18:18] <mvo> slangasek: aha, nice catch!
[18:19] <mvo> slangasek: I guess we could recomment fuse - otoh we don't really need it most of the time if in-kernel squashfs is available
[18:20] <GunnarHj> infinity: Want to mention that I failed to verify the fix of bug #1762952. There seems to be more into it. It looks like the place where you dropped "grp:alt_shift_toggle" is for new installs where /etc/default/keyboard not yet exists. It's still set when you upgrade.
[18:20] <ubottu> bug 1762952 in console-setup (Ubuntu) "Alternative shortcut for layout switching Alt+Shift unexpectedly set by default" [High,Confirmed] https://launchpad.net/bugs/1762952
[18:21] <slangasek> kyrofa: appears so.  sorry, this seems to be under-documented on https://wiki.ubuntu.com/ProposedMigration/AutopkgtestInfrastructure#Worker_administration.  I'm trying to track down where the image generation actually happens
[18:22] <slangasek> kyrofa: https://git.launchpad.net/~ubuntu-release/autopkgtest/+git/development/tree/tools/autopkgtest-build-lxd
[18:28] <slangasek> kyrofa: but this just does setup on top of the generic images that have already been published; we derive from images:ubuntu/xenial/armhf which also does not have ubuntu-standard
[18:29] <slangasek> kyrofa: so I'm altogether unclear why we are using the images.linuxcontainers.org remote for these instead of cloud-images.u.c.  Laney ?
[18:59] <kyrofa> mvo, slangasek recommends aren't actually installed in the tests, right? We can just add fuse to our debian/tests/control
[19:01] <kyrofa> slangasek, thanks for digging into the lxc question, curious to know the outcome of that as well
[19:46] <Laney> slangasek: Dunno.
[19:48] <Laney> But it's always been autopkgtest-build-lxd, never using plain upstream images. Please document that in whatever appropriate place.
[23:27] <ehashman> slangasek: ping
[23:29] <ehashman> slangasek: do you have time to chat about https://bugs.launchpad.net/ubuntu/+source/nodejs/+bug/1779863
[23:29] <ubottu> Launchpad bug 1779863 in nodejs (Ubuntu Cosmic) "Ubuntu nodejs package isn't ABI compatible with mainline nodejs." [Medium,In progress]