valku has quit [Read error: Connection reset by peer]
valku has joined #openwrt-devel
awgh_ has joined #openwrt-devel
awgh has quit [Ping timeout: 480 seconds]
rua has quit [Ping timeout: 480 seconds]
rua has joined #openwrt-devel
<neggles>
heh thanks :P
<neggles>
it was probably mostly pointless since this is Broadcom, but it's broadcom running u-boot, which is... unusual
<neggles>
SPL in mtd0, two u-boot parts, kernel panic dump part, ubifs partition for everything else, and the u-boot has some sort of challenge-response authentication that's...
<neggles>
well when you try to interrupt boot it says "challenge: TODO"
* neggles
slow claps
<dwfreed>
talent
<neggles>
if you let it boot the whole way it does what appears to be CRAM-MD5
valku has quit [Quit: valku]
guidosarducci has quit [Quit: ZNC 1.7.5+deb4 - https://znc.in]
guidosarducci has joined #openwrt-devel
nitroshift has joined #openwrt-devel
Tapper has joined #openwrt-devel
rmilecki has joined #openwrt-devel
Tapper has quit [Quit: Tapper]
Tapper has joined #openwrt-devel
rua has quit [Quit: Leaving.]
<aparcar>
nbd: I remember you worked on fakeroot on macOS, I'm currently seeing the error message "symbol not found in flat namespace '_fstat$INODE64'"
<aparcar>
Any ideas where this could come from? It's one of those M1 Macs, I'm guessing your intel Mac doesn't show the error?
mangix has quit [Read error: Connection reset by peer]
mangix has joined #openwrt-devel
rua has joined #openwrt-devel
<Namidairo>
TODO: Actual auth
danitool has joined #openwrt-devel
<f00b4r0>
aparcar: man fstat seems to answer that question. Specially the section "_DARWIN_FEATURE_64_BIT_INODE"
<aparcar[m]>
f00b4r0: thanks I'll look into it
<aparcar[m]>
f00b4r0: so reading this correctly, if I compile both of them with _DARWIN_FEATURE_ONLY_64_BIT_INODE the suffix shouldn't be appended
<aparcar[m]>
however it looks like APK still defines the suffixed one...
<f00b4r0>
"The _DARWIN_FEATURE_64_BIT_INODE macro should not be set directly. Instead, developers should make use of the _DARWIN_NO_64_BIT_INODE or
<f00b4r0>
_DARWIN_USE_64_BIT_INODE macros when the default variant is not desired."
<f00b4r0>
then again, scroll down to "TRANSITIONAL DESCRIPTION"
<aparcar[m]>
f00b4r0: yea wrong paste, I tried both and neither works
<f00b4r0>
it's possible the source or build is doing something it shouldn't.
<nitroshift>
stintel, ping
<aparcar[m]>
f00b4r0: I'll grep through it
<mangix>
f00b4r0: this is what happens when cmake/meson is not used.
<f00b4r0>
lol
<f00b4r0>
I have portable code that doesn't use cmake or any other automated mumbo jumbo, and builds perfectly fine everywhere :)
<mangix>
sure, but cmake/meson solves a lot of problems with bigger projects.
<f00b4r0>
I'll take your word for it. I assume that's until some other system comes along though :)
<aparcar[m]>
mangix: APK does use meson
<mangix>
yes it does
<mangix>
wonder if anyone has ran the various openwrt tools with sanitizers.
<stintel>
nitroshift: pang
<aparcar[m]>
mangix: well for now, do you have an answer for the stat issue? is it fakeroot or ask?
<aparcar[m]>
*APK
<mangix>
nope. unless I get some apple hardware I probably will not touch it again. VM is painful.
<aparcar[m]>
we should get a m1 VM to offer it to devs...
<jow>
mangix: ynezz has worked on using setting up CI including clang based sanitizers for various tools like libubox etc.
<jow>
s/using //
<mangix>
address sanitizer is amazing. exposes a lot of memory leaks.
<aparcar[m]>
jow: regarding your email, do you plan to build all community packages in a single run and offer them in that static version or to have the community figure out building community packages?
pmelange has joined #openwrt-devel
aleksander has joined #openwrt-devel
pmelange has left #openwrt-devel [#openwrt-devel]
victhor has joined #openwrt-devel
svlobanov has joined #openwrt-devel
<jow>
aparcar[m]: the former, basically what we did before LEDE 17.01
<jow>
build once, archive, never change again
<jow>
that would also mean that errors in releases would persist until the next bugfix release
rua has quit [Quit: Leaving.]
<karlp>
the only thing that concerns me with that is that some people will keep patching "security" issues in old branches, that now won't ever get built, so even if CI checks that the individual package builds, it doesn't mean the tree overall is actually healthy.
<karlp>
but absolutely, no-one's logging into their owrt every few days and doing "opkg update" to keep their 19.07 build updated...
<jow>
well, people insist that package upgrades cause soft bricks and are unreliable
<f00b4r0>
I never do package upgrades. I upgrade the whole thing or I don't :)
<jow>
and overall I got the impression that nobody actually cares about maintaining binary package repository integrity with everything that entails
floof58 has joined #openwrt-devel
<jow>
power users shrug away the issue and build from source anyway, disregarding even SDK and IB
floof58_ has quit []
<jow>
less skilled maintainers are not experienced enough to oversee the implications of abi changes, alternatives, atmoic upgrade integrity requirements, opkg's deficiencies
<jow>
and users expect package upgrades to be as reliable as on debian or ubuntu, since there existence alone implies so
<jow>
*their
srslypascal is now known as Guest8361
srslypascal has joined #openwrt-devel
Guest8361 has quit [Ping timeout: 480 seconds]
rua has joined #openwrt-devel
arnd_ has quit []
arnd has joined #openwrt-devel
<neggles>
aaaaaaaaaand nope i'm done with this stupid AP, no matter how I try I can't get the flash chip to reattach to the board, have wasted enough of my life on broadcom garbage >:(
<neggles>
just wanted to play with the insane BT setup it has, sixteen-antenna phased array for AoA direction/location finding
<neggles>
god i'm so sick and tired of companies like MiST bricking products if you don't want to pay them $400/year in licenses, and Broadcom refusing to tell you *anything* about their hardware without 17 NDAs.
<Namidairo>
did you consider a socket instead
<Namidairo>
or did you just ruin the pads
<neggles>
TSOP-I-48
<neggles>
the pads are, maddeningly, completely fine
<neggles>
I have misplaced two or three 22R resistors and 3 0.1uF caps, which isn't a big deal, and there's five more of these APs where this one came from
<neggles>
but it just, absolutely refused to melt the solder under hot air, at all
<neggles>
despite leaded solder, some particularly spicy flux, and concerningly high temperatures
<Namidairo>
at least they aren't blowing secure boot fuses on uart rx lol
<neggles>
look true :P and while this thing has got some sort of i2c crypto chip on the board, the firmware doesn't use it _at all_, and the params it uses to control whether you can log in locally are stored in a regular old 64kbit I2C EEPROM
<neggles>
it's just bloody annoying because i'm 90% sure the response u-boot wants to its 'challenge: TODO' is 'developer'
<Namidairo>
you dumped the flash though right
<Namidairo>
im assuming you're looking at it in a disassembler to know this
<neggles>
yup
<neggles>
ghidra is so very cool and good
<f00b4r0>
neggles: suggests you need a hot plate to help in that case. Probably a large ground plane is "heatsinking" your soldering attempts
<neggles>
probably, yeah
<neggles>
problem is the I2C EEPROM and the TPM-alike chip are directly behind the NAND...
<neggles>
tbh i'm pretty sure the problem is the two fluxes i was using disagreeing with each other
<neggles>
they worked okay on the zynq board I was using as a NAND reader, though, so maybe it *is* just thermal mass
Gaspare has joined #openwrt-devel
<f00b4r0>
I typically try to avoid hot air /soldering/ at all costs. It's nearly always a royal PITA
<neggles>
mood.
<f00b4r0>
good flux and good gulwing tip work wonders :)
<neggles>
i need some non-tacky flux, and, yeah, gullwing tip
<neggles>
i like doing touchups on small low-pin-count things with hot air, so they're nice and centered
<f00b4r0>
with good flux a flat chisel tip can work too. But gullwing makes it really easy :)
<neggles>
I might come back to this one, but, I can get five more
<f00b4r0>
lol
<neggles>
they're just sitting in a pile because nobody wants to throw them out but they're useless
<f00b4r0>
that's an interesting take on "throwing more hardware at a problelm" :)
<neggles>
the client they came from was quoted AU$3k for licensing/support for *one year* on six APs and one switch
<f00b4r0>
gee
<neggles>
so we spent $2500 on ubiquiti gear to replace them all
<f00b4r0>
heh.
<neggles>
put in a 48-port instead of a 12-port and replaced their Cisco ASA while we were at it
<neggles>
ubiquiti has its own problems, sure, but...
<neggles>
and the console port on these APs? it's a 2.54mm header 'hidden' in a ventilation slot
<Namidairo>
as in the one they intend you to use or the uart
<neggles>
there is no one they intend you to use
<neggles>
they're ZTP ~cloud-managed~ like meraki
<Namidairo>
I wonder if juniper do that free ap program in AU as well
<Tapper>
+1 for "I never do package upgrades. I upgrade the whole thing or I don't"
<neggles>
there’s the UART
<aparcar[m]>
jow: If I understand your proposal right it makes all the work on APK package manager obsolete?
<Namidairo>
they could have a technician debug terminal thing using that challenge response
<jow>
aparcar[m]: well not entirely, could still be used to install packages
<aparcar[m]>
but packages would be offered via the community, right?
<jow>
aparcar[m]: well there would stil lbe snapshots and auto builds, so there'll still be packages
<jow>
people could selectively install snpashot packages on releases if they know what they're doing
<aparcar[m]>
I guess I'm not understanding the proposal then. Getting rid of the two step build process reduces the number of available packages, right?
<jow>
or selectively install packages from release X.Y+1 on X.Y
<zorun>
aparcar[m]: if you manage to get a M1 Linux VM, I'm interested (for the gccfarm)
<jow>
aparcar[m]: in the past we simply built everything in one phase, like you would do when using buildroot on your pc
<aparcar[m]>
zorun: I requested a VM at scaleway within their open source sponsoring program but I forgot to check the "this is very urgent" box
<Namidairo>
I'd presume that wouldn't be possible for kmods
<jow>
scripts/feeds update; .scripts/feeds install -a; select all as =m by default
<jow>
make world IGNORE_ERRORS="n m"
<aparcar[m]>
jow: isn't that dangerous since a single malicous makefile in packages.git could "hack" our release builds?
<jow>
we would stop building packages with the SDK (and effectively stop supporting the SDK)
<aparcar[m]>
bummer since the SDK does a (mostly) fine CI job
<jow>
CI is cheap, github pays for it all
<jow>
so let's just build using the full buildroot
<aparcar[m]>
rip
<aparcar[m]>
I guess we can use the pre-compiled toolchain (once it's fixed)
<aparcar[m]>
what about the malicious makefile issue?
<jow>
I think our fine PR review processes will avoid it
<Namidairo>
that and the giant warning that yells at you not to build as root
minimal has joined #openwrt-devel
<aparcar[m]>
wouldn't it be possible that we use the CI so that community feeds are offered by the community?
<aparcar[m]>
they could still end up on official servers
<aparcar[m]>
but then we build only core packages and every other feed builds in a separate CI
<jow>
could work too
<Namidairo>
you'd probably have to trust them not to go rogue or be compromised, which would require reproducible builds, and then you're just building it anyway?
<aparcar[m]>
speaking of reproducible builds, f00b4r0 mangix are you aware of "ln -s" behavior being different on Macs compared to Linux?
<jow>
this is all technicalities though, I want to reach a clear consensus on how much "binary distro" OpenWrt wants to be / support
<jow>
so far it seems most active contributors prefer working with buildroot, building from source and testing packages with builtin functionality only
<jow>
just a fraction of the contributor base deals with optional binary packages
<jow>
of that just a small fraction deals with repositories, dependency logic, package managers and upgradability
<jow>
most people somehow want recent packages but don't want updates that break installations
<aparcar[m]>
can't we merge our repository then with alpine?
<jow>
I don't see OpenWrt in its current form to be able to support both
<jow>
yeah, maybe people should just deploy alpine chroots
<aparcar[m]>
alpine offers plenty of binary packages
<jow>
and we concentrate on kernel and networking userland
<aparcar[m]>
if you want chroot only we'd merge entirely with build root, not?
<jow>
buildroot follows a cathedral development model iirc, not sure if merging OpenWrt into it would work well
<jow>
I guess in an ideal world opkg upgrade would be gone completely and replaced with ASU
<jow>
in a second step, on-device opkg will go as well and images can be customized online through ASU
rsalvaterra has quit [Quit: rsalvaterra]
<jow>
whoever does not trust the ASU infrastructure can build images with buildroot
<jow>
(OpenWrt buildroot)
rsalvaterra has joined #openwrt-devel
<aparcar[m]>
sidenote I'm currently working on reproducibility so the same image can be requested from multiple ASU instances, if the same checksum appears, it's "trustworthy"
<aparcar[m]>
ASU uses the image builder which uses OPKG, so in case there are no feeds with packages, ASU won't do the magic anymore
<jow>
yeah, hence I wrote on-target opkg above
Tapper has quit [Quit: Tapper]
<jow>
opkg on the build-host stays (ideally replaced with APK later)
Gaspare has joined #openwrt-devel
<aparcar[m]>
wait but if there are feeds anywhere, can't they be consumed by image builder and on-target equally?
<aparcar[m]>
I'm missing the difference here
<jow>
inplace upgrades on target are unreliable
<jow>
missing abi version tracking, breaking changes (think e.g. of the recent hostapd-common or musl libc backports that introduced a lot of breakage)
<aparcar[m]>
okay but the image builder just slaps together a bunch of packages, how is that more reliable?
<jow>
a) it does not run into flash space issues since pacakges are built into the rom
<jow>
b) all packages are installed at the same point in time, so they're coherent
<aparcar[m]>
okay so from my understanding we're removing opkg/apk on-target and pushing ASU
<aparcar[m]>
ASU builds fine images, people have up2date targets
<jow>
yep
<aparcar[m]>
feeds/build chain stays the same since it's required by imagebuilders
<jow>
we could consider shipping a script by default like "install-opkg" or "install-apk" that if executed and interactively confirmed, fetch opkg or apk via curl, performs some cert checking and bootstraps the on-target package managers for those who do not want to use asu
<aparcar[m]>
ASU works also "in-releases", meaning you stay on 21.02.1 but suddenly have the latest package versions installed. Is that still a thing then?
<jow>
no since we would build release packages only once
<jow>
then the repo is frozen
<aparcar[m]>
well we could always improve a service like chef.libremesh.org which is essentially a frontend to ASU, allowing the pre-selection of packages
<aparcar[m]>
jow: so for every update of $tool I'd wait for another point release?
<jow>
yes
<jow>
or use master snapshots
<neggles>
if the pace of point releases is reasonably fast (and accelerated for major security issues) that seems reasonable
<jow>
usually every 2-4 months
<jow>
so TLDR; - phase out on-target opkg (make it optionally installable but do not ship by default anymore)
<f00b4r0>
aparcar[m]: I'm not sure what you mean? The only thing of note on mac is that the filesystem is case-/in/sensitive by default
<jow>
- stop continuously building packages after a release, build once an freeze repo; next maint release will get a newer copy of the same repo
<jow>
- encourage people to either use ASU for customization and upgrades or build from source
<aparcar[m]>
f00b4r0: I think the issue is umask, buildbots use 022 and therefore symlinks are created as 755, however if I'm rebuilding it and checking reproducibility, symlinks are created via 777
<jow>
- ramp up ASU infrastructure under *.openwrt.org
<aparcar[m]>
jow and have more than one ASU developer 😛
<aparcar[m]>
this sounds good to me then. I hoped that a big chunk of the issues with opkg would be solved by replacing opkg with apk, however if you think the basic issues still exists, let's remove it
<f00b4r0>
aparcar[m]: I think that depends on user profile. I just ran ln -s with my (admin) user on Monterey and the resulting link is 755
<jow>
apk can't solve the issue that our binary packaging is simply not good enough (and likely never will reach the level of sophistication required for a real binary distro)
<jow>
this would require entire teams devoted to just packaging technicalities
<jow>
tracking ABI changes, specifying proper dependencies, planning and managing phase-out and phase-in of providers
<jow>
alternatives, conflicts, replacers etc.
<jow>
migrations, deciding when to adopt new major releases
<jow>
parallel installation of different library versions
<jow>
the more time progresses, the more likely it is that installed package set vs. repository available package set diverges, becomes incoherent and leads to undefined results upon install/upgrade
<jow>
and the special OpenWrt specific constraint of certain "packages" being practically immutable (kernel, libc, early system services)
<aparcar[m]>
jow: ack.
<aparcar[m]>
I know it's a bit of a silly approach but couldn't openwrt snatch alpine or Debian package definitions? Like whatever they find working may also work for us
<aparcar[m]>
?
<zorun>
aparcar[m]: openwrt has a much wider (hardware) target scope
<jow>
that, and a different base userland (systemd vs. procd, dbus vs. ubus)
<aparcar[m]>
zorun: sure, we would be the ones building, but not the once keeping track of stuff
<zorun>
I didn't follow the whole discussion, but I recently tried to rebuild a 19.07.7 image with the imagebuilder, and it didn't work because of an incompatible version of libubus (iirc)
<zorun>
so +1 for "freezing" things for releases
<zorun>
I mean, it would be nice to keep the "always up-to-date packages" approach, but it seems really difficult to do
<jow>
really the idea once was to be able to cherry pick smallish fixes into the release branches and have them opkg-installable shortly after (great for hotfixing openssl heartbleed'esque issues)
<jow>
but apparently we backport too much stuff
<jow>
the recent netifd + hostapd + mac80211 bump was an example of a (binary package) backport that shouldn't have happened
<aparcar[m]>
btw I think Daniel is working on some udocker like service which integrates into apk. This way you'd have all the container fun on a OpenWrt device but also, again, APK
<f00b4r0>
I'd trade stability over bleeding edge any day. Point releases are convenient and a safe update option imho.
<aparcar[m]>
So hopefully we can give this discussion a bit more time
<jow>
sure, I don
<jow>
't plan to rush anything
<jow>
more like setting the goalposts for the next two years OpenWrt
<aparcar[m]>
oh you're writing one/
<aparcar[m]>
?
<jow>
writing what?
<aparcar[m]>
you're writing a goalpost?
<jow>
not at the moment, still in the exploration phase