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