[08:22] <eoli3n> Hi
[08:23] <eoli3n> https://bugs.launchpad.net/subiquity/+bug/1905296
[08:23] <eoli3n> i'm on it
[08:27] <eoli3n> mwhudson is there a way to stop for subiquity to loop on errors ?
[08:27] <eoli3n> sometimes it loops, sometimes not
[08:28] <mwhudson> eoli3n: i don't really understand, sorry
[08:28] <eoli3n> to be able to test correctly, i need subiquity to attempt only one run
[08:28] <eoli3n> mwhudson when subiquity crash, it restart itself
[08:28] <eoli3n> in a endless loop
[08:28] <mwhudson> oh right yes
[08:28] <mwhudson> well it shouldn't for a non-interactive install
[08:29] <eoli3n> maybe i need to open a bug for this too
[08:29] <eoli3n> ?
[08:31] <eoli3n> CTRL+C doesnt work
[08:31] <eoli3n> it works, but it restarts anyway
[08:32] <mwhudson> hmm yes a bug would be good
[08:32] <mwhudson> eoli3n: which version are you using?
[08:33] <eoli3n> ok, if i chroot when install is goiing on it fails to restart installer with "/target is in use"
[08:33] <eoli3n> mwhudson https://github.com/eoli3n/vagrant-pxe/blob/dev/roles/ubuntu/tasks/main.yml#L4
[08:33] <mwhudson> thanks
[08:33] <eoli3n> forget the chroot way, it's not ok
[08:35] <mwhudson> so yes it really shouldn't be crashing for a non-interactive install, it should stop and wait
[08:35] <mwhudson> if you can get logs for when it's crashing that would be great
[08:35] <eoli3n> but it doesn't :/
[08:36] <eoli3n> mwhudson -> https://bugs.launchpad.net/subiquity/+bug/1905296
[08:36] <eoli3n> first file
[08:36] <eoli3n> is that what you want ?
[08:36] <eoli3n> yesterday, i took a screenshot, just before it loops
[08:36] <eoli3n> wait a min
[08:36] <mwhudson> no
[08:37] <mwhudson> because that file is written by the installer before it exits/waits/whatever
[08:37] <eoli3n> mwhudson written where ?
[08:38] <eoli3n> what's the path of that file
[08:38] <mwhudson> eoli3n: i mean, i want to know what is written to the console as the process crashes
[08:39] <mwhudson> eoli3n: are you running this on tty1 or over serial?
[08:39] <eoli3n> ok that's what i'm searching
[08:39] <eoli3n> tty1
[08:39] <eoli3n> that one : https://x0.at/5eL.png
[08:40] <mwhudson> on the topic of the other bug, can you try "chroot /target apt -o Debug::Acquire::file=true update"
[08:40] <eoli3n> just after that, terminal clears itself i can see tty1 prompt then it restart
[08:40] <mwhudson> not sure it will be useful, but worth a try perhaps
[08:40] <eoli3n> mwhudson anyway, unless i can stop the loop, i can't test anything
[08:40] <mwhudson> hmm that's not quite enough
[08:40] <eoli3n> as /target is clear at each iteration
[08:40] <mwhudson> yes
[08:41] <eoli3n> sometimes, when python crash, it stops then i can test,
[08:41] <mwhudson> i guess you could kill -STOP it while the crash report is being generated or something?
[08:41] <eoli3n> but i want to be able to reproduce that behaviour
[08:41] <mwhudson> from tty2
[08:41] <eoli3n> mwhudson the screenshot state is 0,5s
[08:41] <eoli3n> maybe less
[08:42] <mwhudson> alternatively if you can run on serial it might be easier to capture the output
[08:42] <mwhudson> eoli3n: is this a VM or bare metal?
[08:42] <eoli3n> both
[08:43] <eoli3n> i use kvm
[08:43] <eoli3n> i don't get what you ask
[08:43] <mwhudson> eoli3n: do you have error commands in your autoinstall config?
[08:43] <eoli3n> kvm is an type1 hypervisor so both
[08:43] <mwhudson> wait no i've seen your config, it doesn't
[08:43] <eoli3n> yes
[08:43] <eoli3n> yes i don't
[08:43] <eoli3n> ^^
[08:43] <eoli3n> what should i add
[08:43] <mwhudson> eoli3n: right but KVM vs an actual server in a rack
[08:44] <TJ-> mwhudson: yesterday we did test with Debug::Acquire::cdrom=true but it didn't reveal much more
[08:44] <mwhudson> i'm just looking at the code trying to understand why it could be misbehaving
[08:44] <eoli3n> hm for me no differences, but yes qemu/kvm on my host
[08:44] <mwhudson> TJ-: it's not using the cdrom method though, the sources.list has file:/// urls in it
[08:45] <eoli3n> mwhudson you can fully reproduce if you want to : https://github.com/eoli3n/vagrant-pxe/tree/dev
[08:45] <TJ-> mwhudson: did it? I thought we saw cdrom! ... shows how tired I was then
[08:45] <TJ-> mwhudson: that'd explain why there wasn't more info :D
[08:46] <mwhudson> TJ-: it is a bit confusing
[08:46] <TJ-> mwhudson: yeah, what gets me is, it successfully reads Release{,.gpg} but then fails on Packages.gz !
[08:46] <eoli3n> mwhudson lets focus just a min on the loop thing, because without workaround this, i can't test anything
[08:46] <mwhudson> wait the title of the bug report is python segfaulting
[08:47] <eoli3n> oh no loop at this run: i'm ready to test
[08:47] <mwhudson> that would explain some things
[08:47] <eoli3n> it seems that just opening tty breaks the loop
[08:47] <mwhudson> although why it would segfault i have no idea
[08:48] <eoli3n> that's the first problem of that issue, that error needs to be catch
[08:48] <eoli3n> by python
[08:48] <eoli3n> whatever is going on
[08:49] <mwhudson> eoli3n: so what commands do i type to reproduce this?
[08:49] <eoli3n> that's what i get stuck on when it crash : https://github.com/eoli3n/vagrant-pxe/tree/dev
[08:49] <mwhudson> (i don't use vagrant)
[08:49] <eoli3n> mwhudson with my env ? follow the readme
[08:49] <eoli3n> you can't if you don't
[08:49] <eoli3n> do you use libvirt on your host ?
[08:49] <mwhudson> well i mean i've never used vagrant
[08:49] <TJ-> mwhudson: I had a running theory yesterday this could be due to the fork into a separate PID namespace, but couldn't put my finger on anything. eoli3n did test using 'unshare' manually - eoli3n  can you recall if when we tried 'unshare' that apt-get update failed or succeeded ?
[08:50] <eoli3n> mwhudson you use libvirt/qemu/kvm on ubuntu right ?
[08:50] <mwhudson> i use libvirt or just kvm on the command line
[08:50] <eoli3n> so install qemu and vagrant packages
[08:50] <eoli3n> then vagrant install the plugin
[08:50] <eoli3n> then nothing to do
[08:50] <eoli3n> just vagrant up
[08:50] <eoli3n> open virt-manager
[08:51] <eoli3n> you will see server ploping
[08:51] <eoli3n> then vagrant up client, to create a pxe client
[08:51] <eoli3n> just follow the readme
[08:51] <eoli3n> its as simple as it is, i will help if something goes wrong
[08:51] <eoli3n> but nothing should
[08:52] <mwhudson> it's downloading a debian10 image now, is that right?
[08:52] <eoli3n> yes it does
[08:52] <mwhudson> ok
[08:52] <eoli3n> thats the box for the server
[08:52] <mwhudson> ah i see
[08:52] <eoli3n> pxe server runs on debian 10
[08:52] <mwhudson> anyway it's nearly 10pm here so i'll have to drop soon
[08:52] <mwhudson> but if i can reproduce i'll have a look
[08:53] <eoli3n> did you install ovmf too ?
[08:53] <eoli3n> lets finish the vagrant env, that will be useful for you, if you want
[08:53] <eoli3n> you need ovmf package to be able to run client in EFI mode
[08:54] <mwhudson> i have that already yes
[08:54] <eoli3n> then confirm me that the file : /usr/share/qemu/OVMF.fd
[08:54] <eoli3n> exists
[08:54] <eoli3n> does it ?
[08:54] <mwhudson> yes
[08:54] <eoli3n> ok
[08:54] <eoli3n> wait for the server's ansible to finish
[08:54] <eoli3n> then "vagrant up client"
[08:55] <mwhudson> ok
[08:55] <mwhudson> biab
[08:55] <eoli3n> you will be able to connect to server with "vagrant connect ssh" then "sudo -i"
[08:55] <eoli3n> oups
[08:55] <eoli3n> vagrant ssh server
[08:56] <eoli3n> one thing we will need to ensure is that you client VM use same IF name than me
[08:56] <eoli3n> (open virt-manager)
[08:56] <eoli3n> if not, i will force IF names
[08:58] <TJ-> eoli3n: launching here as well
[09:00] <eoli3n> please open VM in virt-manager then go to tty2 with menu
[09:00] <eoli3n> i don't know the name of the menu in english
[09:01] <eoli3n> but at the top of VM you should be able to send CTRL+ALT+2
[09:01] <eoli3n> then sudo ip a, and please give me IF names, just to be sure
[09:01] <TJ-> eoli3n: on client it starts at tty1 asking for a login
[09:01] <eoli3n> no subiquity launch ?
[09:02] <eoli3n> that not client, that's your server i think
[09:02] <TJ-> eoli3n: no
[09:02] <TJ-> eoli3n: client
[09:02] <eoli3n> ok
[09:02] <eoli3n> did you see PXE booting ?
[09:02] <eoli3n> you do, if not, no system
[09:03] <seb128> waveform, hey, did you see the regression comment on bug #1903048 ?
[09:03] <seb128> sil2100, ^
[09:03] <eoli3n> reboot your client and describe a bit what steps you see ?
[09:03] <eoli3n> it should be nothing
[09:03] <TJ-> eoli3n: yes, in the launch shell on the host, currently at "==> pxe_client: Waiting for domain to get an IP address..."
[09:03] <eoli3n> that's normal
[09:04] <eoli3n> ah no its not
[09:04] <TJ-> eoli3n: I've checked both server and client guests are on the pxe_network
[09:04] <TJ-> eoli3n: we should move to #ubuntu-server to avoid cluttering -devel with this debug chatter
[09:04] <eoli3n> TJ- vagrant destroy client
[09:04] <eoli3n> then vagrant up client just to be sure
[09:05] <eoli3n> mwhudson is not on #ubuntu-server
[09:05] <mwhudson> bah i am now
[09:05] <eoli3n> hey TJ-
[09:05] <eoli3n> you're not on the dev branch !
[09:05] <eoli3n> git checkout dev
[09:05] <eoli3n> mwhudson too
[09:06] <eoli3n> vagrant destroy -f && git checkout dev && vagrant up
[09:06] <juliank> eoli3n: Heya, it seems you missed the part about -o Debug::PkgAcquire::Worker=1; although I'm not sure why there's no cdrom debug output :/
[09:07] <juliank> eoli3n: Oh, you do not actually use the cdrom method
[09:07] <juliank> you use file:
[09:07] <eoli3n> i don't use anything, the installer does
[09:07] <juliank> well you use the installer :D
[09:07] <juliank> I'm not sure if debug::acquire::file would add anything
[09:08] <juliank> i don't see debugging comments in there
[09:09] <juliank> Oh I see you guys moved to #-server
[09:32] <sil2100> seb128: looking!
[10:12] <juliank> doko: apt is blocked by gcc-snapshot E: Unable to locate package gdc-11
[10:12] <eoli3n> (i'm looking at you sicherboot, i will try this on archlinux)
[10:13] <eoli3n> not sure i can, because i use zfs and bootenv managed by zectl (https://github.com/johnramsden/zectl)
[10:13] <doko> juliank: thanks, will fix it later
[10:20] <juliank> rbalint: There are a lot of kodi addons in release pocket that build-depend on kodi-addons-dev, which is not in the archive, as can be seen in https://magenta.jak-linux.org/ubuntu-archive/distcheck/hirsute/release.txt
[10:20] <juliank> rbalint: What should we do about those?
[10:20] <juliank> Should I request removal?
[10:30] <doko> was kodi-addons-dev removed? did it exist before?
[10:31] <juliank> doko: kodi itself was removed from hirsute
[10:31] <juliank> doko: So yeah, remove all kodi-* and kodiplatform
[10:31] <juliank> removed from Debian testing, depends on removed python-pil; Debian bug #936805
[10:32] <doko> yep, then remove it as well
[10:32] <juliank> OR: demote to proposed so they can migrate again when new kodi enters
[10:49] <TJ-> juliank: eoli3n's issue was wrong file-system permissions on the server-side NFS export; only UID was allowed, and in the PXE client we believe apt-get was dropping to _apt user. In any event, the fix on server-side was to simply apply go+x to directories and go+r to files in the exported unpacked ISO installer file-system
[11:43] <rbalint> doko, juliank i'd have kept python-pil until the new kodi upstream release is out
[11:51] <rbalint> since kodi 19 beta is already out most likely we can have all the packages back soon
[11:58] <juliank> rbalint: yeah, that's why I think demoting them to proposed so they can migrate when kodi is back makes most sense
[12:01] <juliank> rbalint: Having them around in the release pocket doesn't help much, and they might have regressions with kodi 19
[12:01] <juliank> But they probably don't have autopkgtests either
[12:01] <juliank> but I assume they need to be rebuilt anyway
[12:01] <juliank> ?
[12:02] <juliank> I need to get lunch and write my +1 status down
[12:52] <rbalint> juliank, all the addons need to be updated for the new upstream, so they can't come back
[12:53] <rbalint> juliank, new upstream is already in experimental, imo it is ok to not have kodi for some time in devel
[12:56] <juliank> ack
[13:08] <eoli3n> TJ- juliank mwhudson maybe thoses perms need to be applied in futur isos
[13:08] <eoli3n> ?
[13:10] <eoli3n> and a "try except" should be added
[13:13] <eoli3n> because using nfsroot should be a default handled way to go, the "fix" looks actually a workaround to me
[13:26] <ItzSwirlz> Cinnamon Desktop (upstream) 4.8.0 has been released
[13:26] <ItzSwirlz> choo choo, I'll go tell Norbert to get it in experimental
[15:37] <ItzSwirlz> sil2100, mhudson: I've updated the information for Bug #1882375 (SRU), got some time to help?
[15:47] <sil2100> ItzSwirlz: sure! The same debdiff as before?
[15:47] <ItzSwirlz> Yes, debdiff has been the same-it's the  regression potential
[15:48] <ItzSwirlz> regression pot has changed
[15:51] <sil2100> Awesome, on it in a few minutes!
[15:51] <ItzSwirlz> thx
[16:11] <seb128> sil2100, vorlon, L_aney, could one of you review https://code.launchpad.net/~seb128/debian-cd/layerfs-canary-option/+merge/394137 ? (I'm fine doing the style change Dimitri suggested if that's a oreferred style)
[16:29] <xnox> seb128:  the change is obviously correct, and we must have it back to unbreak canary images....
[16:29] <xnox> seb128:  but yeah, i can't merge it.
[16:29] <sil2100> seb128: I can take a look at that and merge once I finish this thing here real quick
[16:29]  * xnox ponders if i should apply to be in ~ubuntu-cdimage
[16:30] <seb128> xnox, right, I was just pointing out that I don't care about the shell syntax so whoever wants to merge it just feel free to change to suit your taste: )
[16:30] <seb128> sil2100, thanks!
[16:30] <ItzSwirlz> xnox: Would always appreciate extra help for UCR's iso-builder
[16:30] <ItzSwirlz> :P
[16:40] <sil2100> seb128: done o/
[16:40] <seb128> sil2100, thanks!
[16:40] <sil2100> seb128: I'll deploy the change on ancientminister so that it gets picked up with the next build
[16:41] <seb128> sil2100, speaking of which, the canary image was commented out from the cronjob since unmaintained and failing to build, with the recent livecd-rootfs and that one merged it should build again, could be get it enabled again?
[16:55] <sil2100> seb128: oh, I didn't know (or forgot) about that! Sure
[16:56] <sil2100> seb128: is it still done via a SUBPROJECT?
[16:59] <sil2100> seb128: done
[17:00] <sil2100> I remember that it being done via a SUBPROJECT but still using the same image type as regular Ubuntu was a bit problematic, with those double-timestamps etc.
[17:01] <sil2100> Would be nice if that got re-visited, so we can properly publish the images
[19:42] <seb128> sil2100, yes, still a subproject, I just fixed the problems that impacted build and ack for changing to a proper image, we will try to do that this cycle
[22:49] <ItzSwirlz> Are SRU's allowed if it is just basically making sure that the program doesn't divide by 0?
[22:49] <ItzSwirlz> because it essentially may or may not have a user impact
[23:41] <tumbleweed> ItzSwirlz: does the program divide by 0 because of user input / misconfiguration? Or is this a bug
[23:58] <ItzSwirlz> It can happen due to user input/misconfig
[23:59] <ItzSwirlz> It is a bug, but I can't find any possible way to replicate it
[23:59] <ItzSwirlz> If it can be replicated somehow and I'm not aware, regardless of wether it is a problem or not should it just never div by 0