18:59:18 #startmeeting 18:59:19 Meeting started Fri Oct 30 18:59:18 2015 UTC. The chair is StevenC99_. Information about MeetBot at http://wiki.debian.org/MeetBot. 18:59:19 Useful Commands: #action #agreed #help #info #idea #link #topic. 18:59:24 #chair christoph 18:59:24 Current chairs: StevenC99_ christoph 18:59:42 #topic see if the MeetBot is working and figure out how to use it 18:59:55 seems to work I'd say 18:59:59 #info it works! http://meetbot.debian.net/debian-kbsd/2015/debian-kbsd.2015-10-30-18.59.log.txt 19:00:15 #agreed the MeetBot is working 19:02:01 #topic blocking issues for a jessie-kfreebsd release 19:02:56 okay, so I wanted to brainstorm all of the things that stop us from releasing jessie-kfreebsd 19:03:38 first of, all, bugs; and try to decide what is important enough to delay the release for 19:04:30 during DC15 we released a debian-installer 20150422+kbsd, and ftpmaster has by-hand processed it for us 19:04:55 here are some issues I know of in that installer: 19:05:29 it fetches udebs from stable, rather than stable-kfreebsd; that means it doesn't have the fixed version of debootstrap, for example - and fails to install the base system at all 19:06:08 annoying, because we can't simply point people at that mini.iso in order to help test 19:06:27 but that can be fixed, no? 19:06:47 ah or you're referring to the dauily "testing" builds? 19:07:12 it's not 'testing' ,but similar to that, we have one for jessie-kfreebsd-p-u 19:07:13 ftp://ftp.debian.org/debian/dists/jessie-kfreebsd-proposed-updates/main/installer-kfreebsd-amd64/ 19:07:30 netboot mini.iso or PXE images 19:07:38 and that still goes for stable? 19:08:24 i'm not sure what you mean, we don't have a "stable"? 19:08:33 the stable-kfreebsd one? 19:08:50 StevenC99_: you were talking about fetching udebs from wrong target? 19:09:09 okay, if we use the jessie-kfreebsd-proposed-updates d-i build, the one that recently got through BYHAND 19:09:22 it fetches udebs from jessie-kfreebsd 19:09:33 which are the ones 'snapshotted' from when official jessie released 19:09:55 this is because the new versions in jessie-p-u haven't been merged into jessie yet 19:09:58 sorry 19:10:06 new versions from jessie-kfreebsd-p-u haven't been merged into jessie-kfreebsd yet 19:10:17 ok got it 19:10:27 i understand we need to do that eventually, but 19:10:38 until it's done, it's hard to test the netboot images 19:11:05 if it helps to have that I'm pretty sure ansgar can be asked to do that 19:11:06 we could build full release media, with the debian-cd tools - which can bundle newer udebs onto them i believe 19:11:26 the jessie-kfreebsd-p-u -> jessie-kfreebsd merge 19:11:43 okay, can we come back to that in a moment 19:11:56 i'll mention some other bugs first 19:12:22 that debian-installer build has some issues, in udebs that are built into it 19:12:31 busybox: #618920 (debootstrap: needs more robust download error handling) 19:12:45 fixed with a new udeb, but will require a new debian-installer build to integrate that 19:13:41 this actually affects anna as well as debootstrap; depending on the network (DNS resolver behaviour?) its possible to get lots of errors downloading udebs or debs 19:14:02 this is busybox wget trying to connect to the mirror via IPv6 even if IPv6 wasn't configured 19:14:27 i made an upload, busybox 1:1.22.0-9+deb8u1+kbsd8u1 which should work around it 19:14:38 one other bug: 19:14:47 netcfg: #768188 (Jessie Installer hangs after processing DHCPv6 stateful addressing) 19:16:20 depending on the network, maybe only when a DHCPv6 server responds, the installer can get stuck, and you can't cancel it 19:16:58 i think it's quite simple to fix that (we're missing the "-1" option) 19:17:42 similar to #769189 (isc-dhcp-client: dhclient -6 -r waits 1m, affecting finish-install on !linux) 19:18:31 that's something that really depends on local network configuration; if you don't have a DHCPv6 server you'd never see this 19:18:49 we're missing -1 option as in dhclient on kbsd doesn't understand it? 19:19:12 on kfreebsd, we invoke "dhclient -1" for IPv4 and "dhclient -6" for IPv6 19:19:15 or the installer should use that option 19:19:16 ah 19:19:18 that rather should be "dhclient -1 -6" i think 19:19:43 wasn't totally clear when browsing through the buglog 19:19:59 well, bug #768188 required a different for for linux 19:20:16 they actually kill it after it gets a lease 19:20:20 because it can't fork 19:20:39 the issue i saw, was that it tried forever to get a lease and never timed out 19:21:47 so, assuming we fixed these things, i'd like people to be able to help test 19:21:54 some people will have DHCPv6 and some of us won't 19:22:20 I'd guess it's rather uncommon especially on VMs 19:22:34 (not saying we should skip the fix) 19:22:46 within Qemu it seems to skip DHCPv6 almost immediatelyt 19:23:02 so i never noticed it, until i tried installing at some cloud provider 19:23:43 any more bugs? 19:23:51 issues within the installer 19:24:05 partman-zfs is a bit awkward 19:24:43 it's pretty confusing if you understand zfs and aren't thinking of it as build ontop of lvm interface jep 19:25:14 it has some bugs relative to partman-lvm 19:25:29 you have to choose a volume size, and... 19:25:44 turns out it is never used anyway, but it still asks for it and it has to fit the available space in the pool 19:25:47 right 19:25:50 but it sometimes gives a wrong suggestion 19:26:24 if you create ~20GB pool, it might suggest to create a 20000MB volume within it, fails, and you have to check the Alt-F4 log to see that it was too big 19:27:52 i think there is code that tries to allow for this, but clearly it still over-estimates the available space 19:28:56 but considering it doesn't even *use* these size limits, I think we should tweak that to suggest something much smaller 19:29:19 so if you create a 20GB pool, maybe suggest a 18GB filesystem or something 19:29:33 plus put that into some sort of release notes / errata (on the wiki?) 19:29:34 no space is wasted because it doesn't even consider these values later 19:29:46 well, it's only the auto-suggestion that is wrong 19:30:02 if we make that much more conservative it should be fine 19:30:05 sure it's still going to confuse users 19:30:10 ah, yeah. 19:30:14 another confusing thing... 19:30:29 it seems to handle units a little differently to other d-i menus 19:30:52 most partman menus say "20 GiB" or "20 GB" 19:30:57 if you put a space here, i think it fails 19:30:59 i think... 19:31:46 i'll look at the source later, but if it's true, i'd like to fix that so it handles that 19:32:05 the value is given to `zfs create size=$size` or similar 19:32:12 so we should just ignore spaces 19:32:20 and possibly the letter "i" if they say "MiB" 19:34:14 though I'd like some advice, whether trivial bugs like these are important enough to stall putting out a release 19:34:49 I'd say they shouldn't 19:35:24 we're still somewhat getting at expert user-ish people 19:35:39 and can document that stuff 19:35:50 would be reat if it can be fixed 19:36:01 great 19:36:02 i too often work around, then forget about, bugs like these 19:36:18 then when a newcomer tries kfreebsd, they hit lots of these small, annoying bugs 19:36:21 lose patience 19:36:22 we should have a wiki page with current installer errata I think 19:36:28 sure 19:36:34 not saying we should ignore them 19:37:22 #agreed better document known issues, in case we don't manage to fix them before release 19:38:14 any more installer bugs you can think of? 19:38:35 to be honest I haven't stress tested the installer recently 19:38:54 okay, lets discuss testing 19:38:59 #topic jessie-kfreebsd release testing 19:39:00 I've used in a few times the last year and it worked so far 19:39:53 i also do most testing by hand. i did have some scripts making it easier to run or preseed, but never really set these up permanently 19:39:59 i merged some of that work into jenkins.debian.net 19:40:41 but that's still using the old debootstrap udeb, and can't complete 19:41:30 we *could* build big debian-cd release media and have it test those, having newer udebs on them 19:41:35 but IMHO that's going the wrong way 19:41:42 we want to be able to test small changes after less effort 19:41:49 i.e. not making some small fix 19:42:21 then having to rebuild d-i, upload to p-u, have ftpmaster process it by-hand, then build debian-cd images to test with 19:42:43 i'd like to reduce the latency/work between making some change and being able to test 19:42:47 so i have an idea for this 19:43:11 it shouldn't be too hard to make d-i's anna udeb fetcher, support fetching udebs from jessie-kfreebsd-p-u 19:43:40 as a preseed option 19:43:57 so, on jenkins.debian.net or in manual testing, we can enable that, and it'll be testing the latest udebs in p-u 19:44:26 so, should i try to get that feature into our next debian-installer build? 19:44:37 I was talking with KiBi about something like that before I got bussy moving 19:45:07 would be great 19:45:28 it is odd to add a new feature right before 'release' 19:45:43 but i think it would really help us to actually test it, before releasing 19:46:03 true certainly 19:46:21 it shouldn't change default behaviour, unless specifically preseeded to use p-u 19:46:31 so, let's have that in the next d-i build? 19:46:59 jep 19:47:00 #agreed add support for jessie-kfreebsd-proposed-updates, to next build of debian-installer netboot 19:47:23 d-i should have some USE_PROPOSED_UPDATES already fwiw 19:47:28 yes we have that 19:47:43 that only chooses which udebs are put into the image 19:47:54 debootstrap is actually one of the 'optional' udebs fetched later 19:48:01 ah 19:48:10 actually for a while, for my own testing, i made debootstrap an always-included udeb 19:48:16 that might have been a quicker workaround, but 19:48:27 it can break things to have too many udebs in the d-i ramdisk 19:48:56 so i don't want to change the list of built-in udebs at this time 19:49:26 right. it's kind of non-optional but it's also not needed right away 19:49:48 so, if we built a new debian-installer, fixing the bugs already mentioned, and having support for udebs from p-u... 19:49:59 could that be a release candidate for people to start testing? 19:50:38 i guess it's not user-friendly that they have to enable p-u for it to work at all... but after the p-u -> stable migration it should be okay 19:50:52 just to make sure 19:51:07 do we have the proper channels activated for seurity updates? 19:51:19 on a "standard" install 19:51:24 AFAIK enabled properly by default 19:51:44 ok 19:51:48 #action StevenC99_ will test that the proper security.debian.org suite is enabled by default 19:52:07 was about to say I can check later but all the better :-) 19:52:25 actually, i did an install this week 19:52:43 its apt sources.list already has: 19:52:44 deb http://security.debian.org/ jessie-kfreebsd/updates main 19:53:01 perfect 19:53:21 so, the timeline i think would be 19:53:34 #action StevenC99_ to upload netcfg fixing known issues 19:53:56 #action StevenC99_ to upload new debian-installer, having busybox and netcfg fixes, and support for udebs from p-u 19:54:16 then that's something an expert user can test, by enabling p-u from the command line or preseed 19:54:31 and by jenkins.debian.net 19:54:58 assuming that's okay, we could move on to migrate jessie-kfreebsd-p-u into jessie-kfreebsd 19:55:10 then, the same debian-installer image, should be usable without enabling p-u any more 19:55:25 i think we could then call it a release candidate? and have even more people test it 19:55:41 with the copy done? 19:55:44 jep 19:55:47 certianly 19:55:56 #topic steps to release jessie-kfreebsd 19:56:23 what else would need to be done after that 19:56:24 debian-cd builds? 19:57:01 jep 19:57:08 i'd maybe try to do those earlier if possible, before the p-u -> stable migration 19:57:10 don';t think we need full sets 19:57:24 i was also thinking VM images would be nice 19:57:33 true 19:57:45 also usefull before the release I'd say 19:57:47 but again, do we want to delay release because we're still working on those... 19:58:28 building VM images does make testing easier 19:59:48 maybe we should just try it - even if we don't *finish* making VM images, we'll at least have got some testing meanwhile 20:00:10 do you have any knowledge there already? 20:00:17 I could get into it I guess 20:00:29 i'm not familiar with the trendy tools for this now 20:00:57 alright then I take care of that 20:01:14 i don't have much available hardware for doing this, yet 20:01:25 most of my spare machines don't have VMM / AMD-V 20:01:51 I do have some VM host with space capacity 20:02:01 on the list was a discussion of using vagrant to build virtualbox images 20:02:06 it requires virtualbox, but also Packer... 20:02:18 that's written in Google Go, which we don't have on kfreebsd, so would have to be done on Linux anyways 20:02:46 and it's not Debian packaged, so it may involve trusting compiled binary packages... 20:03:00 kfreebsd based virtualization hosts are still not much of a thing jet 20:03:02 i really went off the idea and decided, if i was to try to do this, i'd find some other way to do it 20:03:05 meh 20:03:15 riiight, yes it'd be lovely to have bHyVe 20:03:34 definitely. 20:03:37 can always use qemu with either linux-kvm, or software emulation on kfreebsd... 20:03:38 but post jessie-kfreebsd 20:04:25 OTOH jenkins.debian.net... 20:04:40 runs d-i on qemu+KVM to produce installed images and test them 20:06:16 that may be a simpler way to do this, and then clean up the image (ensure SSH keys are regenerated at boot etc.)... and convert to qcow2, virtualbox vdi, or other formats 20:06:20 but anyway, 20:06:45 #agreed after debian-installer is fixed, we'll look into building VM images, hoping to have something in time for release 20:07:02 or mvdebootstrap maybe 20:07:08 vmdebootstrap 20:07:23 was pretty pleasant to build linux images fwiw 20:08:09 seems to be linux-any but maybe can be used somehow 20:08:37 does it run debian-installer? 20:08:42 or just call debootstrap directly 20:08:44 don't think it does 20:08:51 it just uses debootstrap 20:08:56 okay. so you could try that any time, not waiting for d-i bugs to be fixed 20:09:03 plus some magic to get bootloader and things going 20:09:54 what else needs to be done for release 20:09:55 the announcement... 20:10:00 release notes? 20:10:03 where do they go exactly 20:10:22 mostly on the website for "proper" releases 20:11:09 but we weren't in the release https://www.debian.org/releases/jessie/releasenotes 20:11:23 jep I guess we can get jessie-kfreebsd there 20:11:32 like https://www.debian.org/releases/jessie-kfreebsd/releasenotes 20:11:39 but I'll need to check 20:11:48 hopefully we can do that; otherwise we can just dump them anywhere? like our wiki 20:12:09 wiki or glibc-bsd's alioth webspace 20:12:12 jep 20:13:00 /releases/jessie-kfreebsd/ looks nicest to me 20:13:15 certainly if possibl 20:13:20 and in the release announcement, we'll probably quote the most important bits from it 20:13:55 jep. maybe try to submit it to lwn also in addition to d-d-a to get some publicity 20:14:40 can we request testing that way also? 20:14:43 there are two stages 20:15:01 1) testing by experts who can enable p-u, before the migration is done 20:15:05 maybe announce that via -bsd@ only@ 20:15:06 d-d-a for sure 20:15:10 but the main test 20:15:20 2) after migration of p-u -> stable, when the installer should just work 20:15:25 announce that one via d-d-a? 20:15:42 jessie-kfreebsd RC via d-d-a I'd do jep 20:16:29 #topic any other business/bugs 20:16:44 should we fix rsyslogd? 20:16:57 oh that one :-/ 20:17:00 i'm pretty sure it doesn't work! without an extra file in /rsyslog.d/ 20:17:09 yes we should 20:17:16 this is something i routinely fix, and then forget all about it 20:17:26 #action christoph will look at properly fixing rsyslogd 20:17:37 before the p-u -> stable migration obviously 20:17:37 ja fixing it "all the time" as well 20:18:04 some other things on my mind: 20:18:32 partman allows to use MSDOS logical partitions for root or boot. and then grub can't use them 20:18:43 pabs asked about serial interfaces wheezy vs jessie -> https://pbot.rmdir.de/JubmLnw3zEEZr7oFIMb-nw 20:19:03 StevenC99_: it can't boot? 20:19:13 sounds like something that's also broken on linux? 20:19:18 it can't install the bootloader if root or boot is on msdos logical 20:19:54 ah 20:19:55 i think it's mainly because the freebsd kernel can't use msdos logical as root? 20:20:10 right probably 20:20:13 which is kind of odd 20:20:31 maybe should test that again. assuming it is broken, what do we do? 20:20:43 just write it up in release/install notes? or is there something we can do about it 20:21:09 not really 20:21:17 we could try to warn (like, when the user doesn't create any swap space) but tbh that isn't very user-friendly and it'd be awkward to code it 20:22:52 just write it up as a limitation? 20:23:12 after confirming it is really true 20:23:41 #action StevenC99_ to test installing root or /boot onto msdos logical partitions 20:23:55 jub 20:24:05 re: pabs question about serial interfaces, i did address that in jessie-p-u already; uncomment GRUB_TERMINAL=console and it does all that for you 20:24:18 alright great 20:24:40 wrt infrastructure 20:24:45 building mostly works 20:25:02 but if building jessie-kfreebsd-security fails for some reason the logs are pretty much lost currently 20:25:28 as in 20:25:43 they'll land in some security-team mbox somewhere but noone's really looking at them 20:25:56 something i can do, without having any infrastructure access, is to check package versions between security packages on stable vs. stable-kfreebsd 20:25:56 I'll subscribe myself to that alias in a few minutes 20:26:05 what i'd love to have 20:26:10 is a dashboard of package versions in 20:26:15 if you want you can get *all* security build logs as well 20:26:23 stable, stable-p-u, stable-kfreebsd-p-u, and then regular and kfreebsd security suites 20:26:37 it'd be nice if i could get those logs, yes 20:27:37 as we'lre not building anything embargoed I can just write mailadresses into that config 20:27:46 perhaps to steven-buildd@pyro.eu.org ? 20:27:56 the build log itself shouldn't be embargoed anyway? 20:28:04 should we also ask ansgar to copy jessie -> jessie-kfreebsd-p-u somewhen in preparation of the release? 20:28:56 #action christoph will put christoph and StevenC99_ into config to get seucirty buildlogs 20:28:57 you mean, this is an extra step before jessie-kfreebsd-p-u -> jessie-kfreebsd ? 20:29:39 StevenC99_: we don't get any updates from jessie{,-p-u} so far 20:29:59 oooh of course 20:30:21 then i guess that should be done soon 20:30:23 because noone cam up with a clean solution for doing that automatically 20:30:45 it's not like missing security builds but still something we want in the release 20:31:02 i assume this really *should* happen before p-u -> stable 20:31:09 #action christoph will ask ansgar how to do a (manual?) import from jessie to jessie-kfreebsd 20:31:11 so we could do that right now? 20:31:18 jep 20:31:22 or in a week or so 20:31:38 okay 20:31:49 other bugs 20:31:49 still also depends on availability of ftp-masters 20:32:19 well, we'll need that, and d-i will be landing in byhand probably this week 20:32:47 then we just wait until ftpmaster is available, meanwhile we're doing d-i testing 20:32:52 and working on vm images 20:33:07 there's plenty for us to be doing while we wait for ftpmaster 20:33:10 ack 20:33:20 few more bugs: 20:33:31 kfreebsd-i386 asks to pick a kernel, 486 or 686 20:33:47 sometimes it seems to autodetect wrong, or just not let me choose 686 even when that's what i should use 20:34:18 i guess not really all that important? 20:34:32 as long as it's not the other way round 20:34:39 i haven't seen that happen 20:35:06 #action StevenC99_ to test kfreebsd-i386 onto some pre-686 hardware 20:35:11 installing* 20:35:28 can qemu emulate something like that? do you have old enough hardware around? 20:35:48 forgot about qemu, i'll try changing the machine type in that 20:35:55 i do have some 586 hardware around 20:36:05 afaik it worked okay on it 20:36:23 but will check again sometime 20:36:41 qemu... 20:37:08 i tried installed kfreebsd-amd64 with qemu -enable-kvm -smp 4 20:37:25 that would crash toward the end of install 20:37:32 no panic, just immediate reboot 20:38:03 any ideas why? 20:38:03 i then remembered #758757 (kfreebsd-10: d-i bugs caused by qemu-system-i386) 20:38:40 likely a qemu or freebsd kernel bug 20:38:53 maybe i could confirm it on 'real' freebsd 20:38:56 but it's not a regression 20:39:10 wheezy crashes even quicker 20:39:23 and it's smp related I gather 20:39:26 in fact, i think GRUB was crashing, non-deterministically under qemu+KVM with SMP 20:39:48 i suspect it only happens under SMP 20:39:56 unfortunately a lot of cloud environments are KVM and SMP 20:40:12 all our debian infrastructure is KVM and SMP 20:40:20 yeah, i also tested on some KVM+SMP cloud 20:40:25 and have never seen it happen there 20:40:32 where i did see this, was... 20:40:49 on live.debian.net stable, using the command-line Qemu with -enable-kvm -smp 4 20:41:18 with about 8GB of memory and swap in the guest, so it wasn't memory exhaustion 20:41:27 but would often fail after installing the base system 20:41:34 right after the kernel selection dialog 20:41:38 and even if i select "no kernel" 20:42:27 i think we should try to get more install reports from users, and see if we can work out when it does / does not happen 20:42:52 agreed 20:43:17 thinking of which .. when announcing to d-d-a we may also want to generally invite people to help 20:43:31 #agreed get install reports from virtual environments, trying to triage #758757 20:43:45 also outside of release testing 20:44:18 i struggle to answer people when they ask how they can help 20:44:31 we need a list; release testing will be high on that list 20:44:40 but by all means we can mention other things, including in sid 20:44:48 the wiki is a bit of a mess 20:45:03 #info we could use help cleaning up the Wiki ;) 20:45:43 :-) 20:45:59 #agreed we need a list (perhaps on the Wiki) of things newcomers can help with - including but not limited to release testing 20:47:19 anything else? 20:47:20 #info begin writing some release notes, known bugs in d-i release candidates 20:47:44 i've seen at least two people misconfigure virtualbox when trying to use kfreebsd 20:48:10 unless we distribute an actual preconfigured VM, it would help to explain this somewhere 20:49:09 lets have a Wiki page just for VMs 20:49:22 if we manage to build some VM images, we'll mention them there 20:49:35 and we'll also put notes there on creating VMs to install kfreebsd 20:49:54 #info create Wiki page about VMs, how to properly use kfreebsd in virtualbox 20:50:48 one other complaint 20:50:51 firmware... 20:51:29 we only build d-i without firmware 20:51:41 and i don't think we have any mechanism to load it from other media, as linux does 20:52:04 that firmware thing in d-i is linux-specific? 20:52:25 i've not seen it during kfreebsd installs 20:52:30 I mean it would work *exactly* as on linux 20:53:00 #action StevenC99_ to take a look at d-i's firmware loading dialog 20:53:18 i'll see how easily it could be made to work. i suspect it won't work for us 20:53:49 in some cases, we simply don't support firmware loading - like bge microcode (broadcom Gb ethernet) 20:54:26 but then in cases where we do support firmware loading (e.g. intel wifi, radeon graphics), i don't think we offer to install it at all - the user has to look through log files and realise it's missing 20:54:31 that doesn't work? assume at least bxe was working 20:55:17 i think some of the bge cards still work without microcode 20:56:13 well right 20:56:32 i definitely couldn't get Broadcom BCM5785 PCI-X working at all 20:56:32 and the server I used to run kfreebsd with broadcom on doesn't do kfreebsd any more 20:57:14 i have something with an older broadcom NIC i could possibly test on 20:57:22 that did run kbsd before 20:57:33 though i wonder if i maybe used a nonfree kernel on it 20:58:00 anyway, i'd like missing firmwares to be at least mentioned to the user 20:58:16 even if it prompts them to find a new NIC 20:58:19 that's better than the current situation 20:58:30 where detail is buried in dmesg or /var/log/Xorg.0.log 20:58:59 i think that's all the issues from my list now 20:59:14 any else you'd like to discuss? 20:59:45 I think I got everything mentioned I wanted to 20:59:59 shall we schedule another meeting now, and maybe announce it more publicly? 21:00:07 jep 21:00:08 maybe around the time that debian-installer is ready for people to test? 21:00:29 sounds good 21:00:50 so i need time to fix d-i bugs, upload it, and for ftpmaster to get through BYHAND 21:00:54 kind of any evening but not thursday work if long enough in advance 21:01:24 should we allow about 2 weeks? 21:02:11 sounds about right. 21:02:40 saturday 14th maybe? 21:02:48 not that weekend, sorry 21:02:51 okay 21:02:57 monday's fine already 21:03:12