18:59:15 <StevenC99_> #startmeeting
18:59:15 <MeetBot> Meeting started Mon Nov 16 18:59:15 2015 UTC.  The chair is StevenC99_. Information about MeetBot at http://wiki.debian.org/MeetBot.
18:59:15 <MeetBot> Useful Commands: #action #agreed #help #info #idea #link #topic.
18:59:20 <StevenC99_> #chair christoph
18:59:20 <MeetBot> Current chairs: StevenC99_ christoph
18:59:22 <StevenC99_> hello!
18:59:39 <christoph> ohi!
19:00:38 <StevenC99_> this should be fairly quick i think.  i don't have a lot of time
19:00:39 <StevenC99_> #topic since last time
19:00:54 <StevenC99_> we did hope to have debian-installer ready for people to  test... but some things are not done yet
19:01:05 <StevenC99_> kfreebsd-10 waits for next dinstall run after 19:52UTC
19:01:34 <christoph> ah right. that's mostly my fault there
19:02:03 <StevenC99_> i left it a bit late.  some other things are not ready either:
19:02:12 <StevenC99_> partman-zfs still has the issue with guessing partition size
19:02:23 <StevenC99_> i'll try to find a quick solution for that so it's done in time for the next debian-installer upload
19:02:35 <StevenC99_> #action StevenC99_ to fix partman-zfs partition size bug
19:03:20 <StevenC99_> i got a bit distracted with something after mini-debconf cambridge
19:03:32 <StevenC99_> i was looking to see if debian-installer could build reproducible netboot iso's
19:04:17 <StevenC99_> it seems we *could* do that.  is it worth trying to rush this into jessie, or should we be more focused on getting the release done?
19:04:40 <christoph> depends a bit on what is needed
19:04:50 <StevenC99_> i would need to make a small patch to 'makefs', and patch debian-installer itself.  then i think builds reproducible mini.iso and/or netboot.tar.gz
19:05:02 <christoph> I'd not do anything that is not pretty safe from regressions
19:06:07 <StevenC99_> in makefs:  accept new command-line option to 'clamp' timestamps to some value
19:06:20 <StevenC99_> that works really well, and shouldn't be able to break anything other than maybe timestamps
19:06:50 <StevenC99_> it stops unnecessary variance in timestamps, in the d-i ramdisk it generates
19:06:55 <StevenC99_> the bits in d-i, are
19:07:09 <StevenC99_> changing 'tar' and such to sort files into order, turn off timestamps in gzip headers
19:07:29 <StevenC99_> nothing too complex, but done in quite a lot of places
19:07:53 <StevenC99_> is it a highly desirable feature for the stable release?  or should it just be worked on in sid?  or...?
19:08:27 <christoph> it's probably more useful for stable than it is for sid
19:08:34 <StevenC99_> actually the makefs part only affects the d-i build, so that can be reverted easily if it's a problem
19:08:37 <christoph> I wouldn't personally push for it now
19:08:53 <christoph> but if you're interested in doing so there's no reason to not do it I guess
19:09:05 <StevenC99_> it's done, i just wonder whether to apply it
19:09:37 <christoph> oh right
19:09:42 <christoph> in that case go for it!
19:10:02 <StevenC99_> #action StevenC99_ to need sponsor/privileges for a makefs package upload
19:10:32 <StevenC99_> should we take over maintainership of that package btw?
19:10:39 <StevenC99_> it's orphaned and we need it for d-i builds
19:10:43 <StevenC99_> our d-i builds*
19:11:10 <StevenC99_> its from netbsd, builds a ffs filesystem as ordinary user
19:11:11 <christoph> we need it or d-i needs it?
19:11:16 <christoph> I see
19:11:21 <StevenC99_> d-i needs it to build kfreebsd images
19:11:30 <christoph> makes sense to have as part of debian-bsd then
19:12:12 <StevenC99_> #agreed take over as maintainers of makefs
19:12:21 <christoph> wait tg and it was in git not CVS?
19:12:23 <christoph> :-)
19:12:58 <StevenC99_> lol that's odd
19:13:59 <StevenC99_> ok so *if* we can patch that quickly, our next debian-installer upload might hopefully be reproducible
19:14:39 <StevenC99_> #info kfreebsd-jessie's netboot images may be reproducible in time for release
19:15:02 <StevenC99_> so, that VM you built
19:15:17 <StevenC99_> did you send patches to vmdebootstrap folks?  are they public somewhere?
19:15:37 <christoph> they are on https://git.siccegge.de/?p=forks/vmdebootstrap.git;a=summary
19:15:45 <christoph> I sent them to vmdebootstrap folks
19:15:56 <StevenC99_> ah, good.  did you make any changes after my feedback?
19:15:56 <christoph> but they asked for them to be rebased on their development branch
19:15:59 <StevenC99_> oh
19:16:04 <christoph> which was cooked up during cambridge
19:16:11 <StevenC99_> yeah it probably changed a lot
19:16:14 <christoph> not yet
19:16:15 <StevenC99_> have you looked at it since then?
19:16:24 <christoph> was away most of last week
19:16:45 <christoph> but as the patches were pretty easy to do in the first place I'm pretty positi8ve I can get to that point again in an afternoon
19:17:00 <StevenC99_> don't *have* to be using the latest vmdebootstrap though
19:17:05 <StevenC99_> as long as you can built a VM
19:17:09 <christoph> jep
19:17:12 <StevenC99_> and preferably fix some of the things i said
19:17:42 <christoph> and debug the ufsid problem jub
19:17:51 <StevenC99_> can you remind me what was happening there?
19:18:00 <StevenC99_> grub-probe thought the ufsid was different than it really was after a reboot?
19:18:16 <christoph> grub was unable to find the ufsid abter doing a grub-install from the running system
19:18:34 <StevenC99_> unable to find one;  or finding an incorrect one?
19:18:35 <christoph> booting worked fine untill you did the grub-install
19:18:41 <StevenC99_> oooh right
19:18:49 <christoph> and continued to work after a chroot-in ; grub install from a kfreebsd host
19:19:10 <christoph> as in: doing a grub-install from the chroot environment got it back to what it was during install
19:19:15 <StevenC99_> okay
19:19:50 <StevenC99_> i did some more install tests
19:20:03 <StevenC99_> security.debian.org definitely is set up correctly for jessie-kfreebsd, by default
19:20:04 <christoph> my current plan is doing a binary diff with only the latest step done or so
19:20:08 <christoph> \o/
19:20:56 <StevenC99_> netcfg seems fixed now
19:21:04 <StevenC99_> doesn't hang at DHCPv6 prompt
19:21:23 <StevenC99_> anna and net-retriever should be okay now for using proposed-updates - but i didn't figure out yet how to preseed/enable that easily
19:22:14 <StevenC99_> i can figure that out after d-i is uploaded, and then have jenkins.d.n do this when testing it
19:22:53 <christoph> ok
19:23:56 <StevenC99_> uhhhm what else is to do?
19:24:05 <StevenC99_> did you look at syslogd?
19:24:06 <StevenC99_> rsyslogd*
19:24:13 <christoph> no sorry.
19:24:16 <christoph> still on my todo
19:24:22 <StevenC99_> #action christoph to look at rsyslogd
19:24:39 <christoph> guess I can get that done untill say sunday
19:24:51 <StevenC99_> #action StevenC99_ still needs to test on 586, to make sure it picks the right kernel
19:25:14 <StevenC99_> #action StevenC99_ still needs to look at firmware loading in d-i
19:25:37 <StevenC99_> #action StevenC99_ still needs to test root or /boot on msdos logical partitions
19:26:07 <StevenC99_> otherwise, i'd say my test installs have gone rather well
19:26:15 <StevenC99_> i've deployed a few new kfreebsd systems quite easily
19:26:50 <StevenC99_> i would like to stress the importance of live/rescue media though
19:27:03 <StevenC99_> #topic VM images
19:27:12 <StevenC99_> any ideas if the VM images could work as a live system?
19:27:21 <StevenC99_> i understand live-boot is being rewritten to use vmdebootstrap
19:27:42 <christoph> for some server-like system certainly
19:28:01 <christoph> I'm not sure how much work it will be to have a live desktop system on top of that
19:28:06 <christoph> needs looking at the code
19:28:11 <StevenC99_> i was thinking just console-based/rescue
19:28:38 <christoph> I guess that'll be doable
19:28:42 <StevenC99_> AIUI on Linux they use an initrd to make the rootfs writable in memory
19:28:51 <StevenC99_> like a overlay of tmpfs on read-only squashfs
19:29:04 <StevenC99_> but - on kfreebsd our root ramdisk is writable already
19:29:42 <StevenC99_> #action StevenC99_ to try booting christoph's VM image off a USB stick
19:29:45 <christoph> so the main issue is how to keep the thing clean or decide we don't need to
19:29:48 <StevenC99_> i think it may be just work already
19:29:56 <StevenC99_> how do you mean?
19:29:59 <christoph> I'd guess it does
19:30:19 <christoph> well mounting a tmpfs over also means you get the same system every time you boot up
19:30:30 <christoph> while our system preserves all kinds of chagnes
19:30:41 <christoph> which may or may not be desirable/a problem
19:30:54 <StevenC99_> oh, you mean it would be persistent...
19:31:26 <StevenC99_> didn't realise that
19:31:30 <StevenC99_> that actually sounds good
19:31:47 <StevenC99_> usually it takes extra work to get that with Linux live
19:32:00 <StevenC99_> only in cases like Tails do they specifically not want that
19:32:45 <StevenC99_> i'm happy for our live system to be writable by default, and maybe at some later time look into other ways to run it
19:32:48 <christoph> I guess no matter wether it's actually preferred or not it's something that shouldn't be a real problem for us
19:32:54 <christoph> jub
19:32:55 <StevenC99_> right
19:33:08 <StevenC99_> mainly, someone should be able to write this thing to a USB stick to rescue an unbootable kfreebsd system
19:33:38 <christoph> and hopefully get something slightly more comfortable than the d-i based rescuesystem
19:33:45 <StevenC99_> exactly ;)
19:33:56 <StevenC99_> i went through this only the other week
19:34:21 <StevenC99_> i had to use Linux live, KVM, and a kfreebsd d-i .iso combined
19:34:40 <christoph> oO
19:35:12 <StevenC99_> #topic d-i release candidate
19:35:27 <StevenC99_> sooo i think in 1-2 days we could have a debian-installer release candidate uploaded
19:36:27 <StevenC99_> we'll then contact -bsd@ and -devel@ about testing it
19:36:41 <StevenC99_> once ftpmaster has installed it
19:37:16 <StevenC99_> if it's working, we can proceed to merge kfreebsd-p-u into stable...
19:37:31 <StevenC99_> then try to get debian-cd images built
19:37:33 <StevenC99_> and we're done
19:37:37 <christoph> :-)
19:37:53 <StevenC99_> #action d-i release candidate to be announced on -bsd@ and -devel@ when ready
19:37:54 <StevenC99_> #topic any other business
19:38:03 <StevenC99_> anything else to discuss?
19:38:27 <christoph> noting on my list
19:38:48 <StevenC99_> oh, i was thinking about 'minimum supported hardware'
19:39:25 <StevenC99_> i'm trying to think of some minimum required spec that 'should' be able to run kfreebsd, then see if it actually works
19:39:51 <StevenC99_> it's too late for us to vary d-i ramdisk size;  that'll set a lower limit on required RAM
19:40:19 <StevenC99_> something that is annoying, is gnupg2 brings in a lot of extra stuff into a minimal install
19:40:48 <christoph> which ends up being a problem for the ramdisk?
19:41:06 <StevenC99_> no, in the install target
19:41:09 <StevenC99_> the target disk
19:41:48 <StevenC99_> it installs some extra packages like GTK libs i think, and dbus-daemon;  taking up 10% more space than otherwise
19:42:17 <christoph> well guess that's how it is
19:42:32 <StevenC99_> yeah, i suppose we can't really fix this because
19:42:43 <StevenC99_> gnupg2 will likely get security updates
19:42:50 <StevenC99_> we don't want jessie-kfreebsd-p-u to get into the way of those
19:43:00 <StevenC99_> or have to rebase our patches on top of those each time
19:43:13 <christoph> jah I'd really want to avoid having to care about gnupg2 ourselves
19:44:10 <StevenC99_> #info partman in d-i is slow
19:44:25 <StevenC99_> this is too complex to fix for jessie
19:44:41 <StevenC99_> it belongs in release notes as errata i think
19:44:54 <StevenC99_> on some disks it stalls for a minute or two
19:44:58 <christoph> jah and it's "just" slow
19:45:05 <StevenC99_> well, it's broken
19:45:10 <StevenC99_> slowness is a symptom of that...
19:45:27 <StevenC99_> but fixing it is going to be complicated
19:46:03 <StevenC99_> oh, another random thing:
19:46:13 <StevenC99_> Xorg in sid is moving to run as regular user
19:46:24 <StevenC99_> are you running kfreebsd sid at all?
19:46:38 <christoph> the notebook's still a mix between jessie and sid
19:46:50 <StevenC99_> Xorg from jessie or sid?
19:46:51 <christoph> I don't think anything pulled in X from sid yet
19:46:53 <StevenC99_> ok
19:47:19 <christoph> guess some time I will have to just go sid but right now it still works with that mix
19:47:23 <StevenC99_> #info someday look at Xorg in sid, see if it needs to run as root, or just in a special group for /dev/mem
19:48:04 <christoph> probably also one of the things I want to make sure sshd works and has stable network on boot
19:48:28 <christoph> though not as bad as when the VTs didn't work with modesetting
19:48:53 <StevenC99_> kfreebsd 10.2 needs testing carefully
19:49:06 <christoph> running on my notebook fine so far
19:49:08 <StevenC99_> shouldn't be as bad as 9->10
19:49:18 <christoph> with only updated kernel
19:49:23 <StevenC99_> that's good then
19:49:56 <StevenC99_> #info kfreebsd-amd64 and -i386 rebootstraps are at about the same stage as linux
19:50:03 <christoph> -11 will be fun again probably but untill then it seems to work well enough
19:50:38 <StevenC99_> well, 10.3 is coming next year?  and -11 maybe not until the year after
19:50:50 <StevenC99_> 10.3 would be a long-term stable kernel
19:50:53 <StevenC99_> 11.0 probably not
19:51:09 <christoph> right
19:51:16 <StevenC99_> so that's quite a while away
19:51:24 <StevenC99_> rebootstrapping:  we can rebuild most of kfreebsd toolchain from Linux, thanks to helmut
19:51:41 <StevenC99_> kfreebsd-armhf doesnt' get very far yet, still need to patch gcc or binutils
19:52:31 <StevenC99_> we have a related kfreebsd-kernel-headers transition coming up soon, for multiarch
19:53:14 <StevenC99_> glibc 2.21... aurelien has done a ton of work on this, not sure if it is ready yet
19:54:03 <StevenC99_> #topic next meeting
19:54:04 <christoph> I hope aurel32 mails if he wants help
19:54:23 <StevenC99_> i hope he doesn't need my help, i really have no clue!
19:54:49 <christoph> petr has always been reachable when anything about libc was up
19:55:15 <christoph> anyway. for next meeting .. I should be available untill congress basically any time
19:55:18 <christoph> just no thursdays
19:55:25 <StevenC99_> same
19:56:13 <christoph> december 1th ?
19:56:55 <StevenC99_> maybe sooner?
19:57:18 <StevenC99_> we should have d-i ready to test by next week
19:57:30 <christoph> ok
19:57:36 <StevenC99_> maybe weds/friday next week?
19:57:39 <christoph> ok
19:57:42 <StevenC99_> which
19:57:52 <christoph> maybe weds?
19:58:08 <StevenC99_> 19:00 UTC?
19:58:10 <christoph> hm ructf is this weekend so shouldn't matter much
19:58:13 <christoph> works for me
19:58:18 <StevenC99_> #info next meeting: 2015-11-25 19:00Z
19:58:45 <StevenC99_> okay, great!  thanks for your time
19:59:16 <christoph> :-)
19:59:16 <StevenC99_> #endmeeting