Guest2328 has quit [Read error: Connection reset by peer]
<f00b4r0>
file-system partition too big (more than 5177344 bytes): Success
<f00b4r0>
well that's an odd "error" message
<jow>
looks like typical strerror(0) or sprintf("%m") with errno == 0
<f00b4r0>
i see
<jow>
likely because it's a "synthetic" error and not one due to a failing system function setting errno
<f00b4r0>
of course the bigger annoyance is that the error is ignored in the build process, so it continues its merry way with more failures and eventually results in a "successful" (exit == 0) build that really isn't
<f00b4r0>
not sure why we do this, maybe this is for compat with buildbot?
<jow>
exactly
<f00b4r0>
*sigh*
<f00b4r0>
we should fix buildbot to gracefully handle the error instead, imho
<jow>
half of the people want too big images to hard fial the build, the other half doesn't
<f00b4r0>
this is confusing the users
<jow>
as is not providing targets featuring several dozen images just because the image for one router model was too large
<f00b4r0>
yeah but that can (and should) be handled by the buildbot process, which is the only place where this behavior is desirable, afaict
<jow>
not sure if it was made configurable (might be a candidate for CONFIG_BUILDBOT and/or developer options)
<jow>
could also be that you can achieve hard fail semantics by not using multi rootfs image settings but building a profile specifically for one board
<f00b4r0>
that would be a good first step indeed
<jow>
well, I know of several people with custom build automations that also do not want hard fail
<f00b4r0>
it makes no sense, it breaks every unix rule ;P
<jow>
but I guess defaulting to hard fail with an option to turn it off would be fine
<f00b4r0>
you can ignore an error code, you cannot look for an error if you don't know there is one. especially since the error message varies from device to device
<jow>
no you can't really ignore the error code with a simple build wrapper
<jow>
the build will abort and other, unrelated artifacts remain unbuilt
<jow>
only way out is manually disabling the affected board profile, which obviously is not possible to automate
<f00b4r0>
well, if you're building something and actually need the build product, having the build fail when the build product isn't created seems fairly logical?
<f00b4r0>
except in the buildbot case where we go like "heh, don't care" ;)
<jow>
if the intent is to build e.g. the entire ath97/generic subtarget with 40 or so different images then "the product" is "all images that can be built"
<f00b4r0>
in a buildbot scenario, yes
<jow>
community builds
<jow>
ci
<jow>
all not using buildbot
<f00b4r0>
in a scenario where you're building images for deployment on actual devices, no
<f00b4r0>
I ended up having to code a secondary wrapper that checks for image existence and do the hard fail if it's not there. Problem is: I cannot programmatically report the error *cause*, because the error message isn't even prefixed with e.g. "Error" ;P
<f00b4r0>
anyhow, not my fight. Meanwhile I started putting together ucode bits for native curl support, is this something you'd be interested in? :)
<jow>
The error you quoted also does not stem from any of the build steps in include/image-commands.mk, it is likely generated by some random firmware-utils tool
<jow>
yeah, would be appreciated
<f00b4r0>
yep, that's why it changes from device to device
<dwfreed>
jow: make has a 'keep going'
<f00b4r0>
ok, i'll clean up what I have and will open a PR
<f00b4r0>
dwfreed: good point, indeed it does
<jow>
dwfreed: yeah but continuing after failing to build e.g. dnsmasq or packing one of fourty images because it exceeds device limits should likely be treated differently
<dwfreed>
some of it can be handled with --keep-going, some of it can be handled with a config variable for ignoring image build failures
<dwfreed>
the latter could even default to the value of buildbot
efahl is now known as Guest2330
Guest2330 has quit [Read error: Connection reset by peer]
efahl has joined #openwrt-devel
<jow>
yes
Daanct12 has quit [Quit: WeeChat 4.3.5]
* russell--
just bisected my zyxel gs1900-24e brokenness to a376508216440178184fb3ab71faf87eea637109, going to try reverting it against master and see if that fixes it
Tapper has joined #openwrt-devel
minimal has joined #openwrt-devel
ar7ch has quit [Remote host closed the connection]
<russell-->
yep, reverting a376508216440178184fb3ab71faf87eea637109 fixes zyxel gs1900-24e for me
<robimarko>
Yeah, all QSDK releases before 12.0 used kernel 4.4
<mrnuke>
Oh! New device with old QSDK! Very exciting indeed!
<robimarko>
I doubt the design is new
<robimarko>
They probably use the same codebase for all models
<robimarko>
As that makes it much easier to generate BDF-s and certify stuff
<mrnuke>
It's probably a renewed EAP610-Outdoor that's been out for a few years. The chassis looks identical
<slh>
it's a bit sad to consider what the hardware could do, if QCA would spend a little more on doing proper netdev/ netfilter development. but considering the limits it has in OpenWrt, ipq807x works pretty well and reliably for me
hurricos has joined #openwrt-devel
<hurricos>
back
<hurricos>
UPS died in the night and woke me at 4AM