| holman | minimal: no problem | 00:01 |
|---|---|---|
| holman | minimal: I just put up a PR which should make it possible to use OpenNebula on alpine | 00:02 |
| holman | and any distro that doesn't ship with bash by default | 00:02 |
| holman | it also makes all of the upstream unittests pass on alpine | 00:03 |
| holman | I'm guessing there are patches in alpine's package for those | 00:03 |
| holman | also heard rumblings of the xz stuff in various irc channels | 00:04 |
| holman | Haven't picked up the details yet though | 00:04 |
| holman | meena: I don't remember if freebsd has patches for that, might interest you too | 00:07 |
| meena | holman: for OpenNebula or xz? | 00:08 |
| meena | We got xz in base, but no vulnerable version | 00:08 |
| meena | As for OpenNebula, we don't have anything to run OpenNebula on FreeBSD out of the box, but I'm fairly certain that FreeBSD should just run on it fine… as long as it's got bash installed | 00:10 |
| meena | which, i assume if someone is building FreeBSD images for OpenNebula they would preinstall | 00:10 |
| minimal | holman: I'll have a look at that PR. At first glance wondering about the GNU date related change as I've run "cloud-init analyze blame/show/dump" on Alpine fine with Busybox date, it's only "boot" that currently doesn't work on Alpine | 00:14 |
| minimal | I've never looked at OpenNebula before, I guess I always assumed it was somewhat behind-the-times but it does support LXD and Firecracker so it's obviously not | 00:18 |
| minimal | holman: ah, I see now, Busybox date does accept "date +%s.%3N" with no errors but it doesn't actually output any nanoseconds value | 00:28 |
| minimal | that's because Alpine build Busybox with CONFIG_FEATURE_DATA_NANO unset | 00:33 |
| holman | OpenNebula | 00:49 |
| holman | Yeah gnu date is just a fallback helper | 00:49 |
| * meena wonders what it would take to port GNU date's functionality to BSD date | 20:31 | |
| meena | it seems like there's a lot of magic happening there | 20:31 |
| * minimal wonders why you'd not just stick to POSIX compliance | 20:34 | |
| minimal | rather than moving over to The Dark Side ;-) | 20:36 |
| meena | isn't GNU date also POSIX compliant, aside from magical? | 20:45 |
| minimal | I believe things like "+%N" are GNU-specific extensions, not defined in POSIX | 20:46 |
| minimal | yupe, %N is not defined here: https://pubs.opengroup.org/onlinepubs/9699919799/utilities/date.html | 20:48 |
| meena | yeah, but, what's the issue with defining more? | 20:50 |
| minimal | they're GNU extensions, not part of POSIX standards, and therefore scripts/code end up depending on GNU (or "compatible") implementation rather than POSIX standard | 20:51 |
| minimal | it's the same sort of issue musl has with people often building programs that fail because those programs use glibc-specific functions | 20:52 |
| minimal | i.e. musl set out to be a POSIX compliant libc, not a Glibc compatible libc, so programs failing to build on musl if they use glibc-specific functionality is not a musl bug | 20:53 |
| minimal | yet often people treat it as such a bug and complain loudly | 20:53 |
| meena | *nod | 21:21 |
| === quix is now known as quique | ||
| === quique_ is now known as quique | ||
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!