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