<stintel> holy crap, sysupgraded m300 running image from mpc85xx/t208x to image from the new qoriq/generic target I just introduced, and it works like charm from the first time
<stintel> hell yeah, that worked twice in a row!
<mangix> stintel: you have mvebu devices?
clayface_ has joined #openwrt-devel
clayface has quit [Ping timeout: 480 seconds]
Tapper has quit [Ping timeout: 480 seconds]
danitool has quit [Quit: Cubum autem in duos cubos, aut quadratoquadratum in duos quadratoquadratos]
Rentong has joined #openwrt-devel
paper_ has quit [Excess Flood]
valku has quit [Quit: valku]
Rentong has quit [Ping timeout: 480 seconds]
<owrt-snap-builds> Build [#227](https://buildbot.openwrt.org/master/images/#builders/13/builds/227) of `lantiq/xway_legacy` completed successfully.
jonah1024 has joined #openwrt-devel
<jonah1024> Heyo, just a quick question. I'm pretty new to openwrt/buildroot and was wondering why gcc 7.4.0 is the only and current version as the native openwrt compiler. I'm having issues with installing some python c extensions that need at least gcc 8.4.0. I know OpenWrt/buildroot is designed with crosscompilation in mind but having a newer version of gcc on the target would solve this sole issue. Are there any reasons why gcc i
<jonah1024> Also, any chalanges I should be aware of if I'm attempting to cross compile a newer gcc version?
Rentong has joined #openwrt-devel
Tusker has joined #openwrt-devel
<Tusker> jonah1024: you can change the gcc version in Advanced... -> Toolchain options
<jonah1024> Tusker: I'm aware of that but the gcc native package will still be build with 7.4.0 source, right?
<Tusker> jonah1024: ah, OK, you want to modify the host tools... Not sure how to modify that one. Not at my PC...
<jonah1024> Tusker: I've modified the Makefile to download 8.4.0 version, replaced the hash, tried to compile it but it's failing at some patches :(
<Tusker> I am sure there are lots of packages and patches that need fixing if you upgrade host gcc to a higher version
<Tusker> Probably easier to backport fixes to your python library only
Rentong has quit [Ping timeout: 480 seconds]
<jonah1024> Tusker: Is there a way to make python 3.9 use gcc 7?
danitool has joined #openwrt-devel
rmilecki has joined #openwrt-devel
Tusker has quit [Remote host closed the connection]
Tusker has joined #openwrt-devel
Tusker has quit [Remote host closed the connection]
Tusker has joined #openwrt-devel
Tusker has quit [Read error: Connection reset by peer]
Tusker has joined #openwrt-devel
rmilecki has quit [Ping timeout: 480 seconds]
Tusker has quit [Read error: Connection reset by peer]
Tusker has joined #openwrt-devel
<Tusker> OK, I think an IRC client on my phone is not a good idea :) should use a proxy on a stable internet connection
<Tusker> Probably drop down the python version a little bit might be the easiest? Not sure who has got python 3.9 compiling with gcc7
<jonah1024> Tusker: I see. Thanks!
jonah1024 has quit [Quit: Page closed]
Borromini has joined #openwrt-devel
Tapper has joined #openwrt-devel
jlsalvador2 has joined #openwrt-devel
jlsalvador has quit [Read error: Connection reset by peer]
jlsalvador2 is now known as jlsalvador
goliath has joined #openwrt-devel
rejoicetreat has joined #openwrt-devel
clayface_ is now known as clayface
Tusker has quit [Remote host closed the connection]
jlsalvador2 has joined #openwrt-devel
jlsalvador has quit [Read error: Connection reset by peer]
jlsalvador2 is now known as jlsalvador
<stintel> mangix: yes
<mangix> Cool
floof58 has quit [Ping timeout: 480 seconds]
floof58 has joined #openwrt-devel
_lore_ has quit [Ping timeout: 480 seconds]
<stintel> fyi those changes started a discussion already (on github on the commit)
_lore_ has joined #openwrt-devel
<stintel> let's hope more people see it and think and move there favorite target to it :)
<stintel> hmmm, I might need some coffee, can't even write a proper sentence
wulfy23 has joined #openwrt-devel
<stintel> lol?
<wulfy23> will runtime-test this for a while
<stintel> wulfy23: I already decided to not push it, I don't feel comfortable implementing something fragile like suggested on the ML
<wulfy23> roger that... i'm gonna give it a shot anyway... was going to checkout hosts et. al. so i'll see how it goes
<stintel> I've been using this since at least early 2017
<wulfy23> geez... good stuff
<stintel> but I had a bunch of extra commits that move some things to use /tmp/etc directly instead of /var/etc
<stintel> never got around to massaging the whole series to something I felt comfortable sending out
<wulfy23> suspected as much /var/log/wtmp or whatever seemed a bit suspect
<stintel> let's see if more discussion will happen :)
<wulfy23> yeah... it's a great thing for future commits and whatnot to be careful about using /tmp or /var properly
<stintel> now what will I work on first, another attempt at gcc 10 by default, or continue messing around with new qoriq target
<wulfy23> i've got a bunch of custom stuff that lazily use /tmp instead of var
<stintel> well, ideally we implement /run as tmpfs in procd
<stintel> and generate all configs generated by uci in /run/etc/ or /run/uci even
<stintel> have /var persistent non-optional
<wulfy23> right
<stintel> but then ... do we want multiple tmpfs? on memory constrained devices this adds to the potential oom
<wulfy23> i think thing are pretty decent as is
<stintel> yeah, Id
<stintel> oops
<stintel> I'd just like to be a bit more in line with other distros - /run tmpfs is now pretty common, and lots of software is using that by default now for pid and sockets
<stintel> which adds to the maintaince burden of maintaining a package for openwrt - not much, but still, it could be nicer if we just had /run on tmpfs
<wulfy23> can we just not bindmount some persist>/var/something to /tmp/whatever as an interim workaround where needed
<stintel> yeah the problem with interim workarounds is that they often become permanent :D
<wulfy23> all the jail shiz and permissions add complexity
<wulfy23> roger
<wulfy23> so good to be having the discussion
<stintel> but hey cool, didn't expect to see that much response on a very simple patch in < 24h after posting :D
<wulfy23> o yeah!!!
jlsalvador2 has joined #openwrt-devel
jlsalvador has quit [Read error: Connection reset by peer]
jlsalvador2 is now known as jlsalvador
<stintel> these guys are appearing in my firewall for days
<stintel> scanning probably my entire /60
<stintel> with wan forward policy on reject, they might conclude a whole lot of online devices 😂
Tapper has quit [Ping timeout: 480 seconds]
Tapper has joined #openwrt-devel
jlsalvador2 has joined #openwrt-devel
jlsalvador has quit [Read error: Connection reset by peer]
jlsalvador2 is now known as jlsalvador
rejoicetreat has quit [Ping timeout: 480 seconds]
<stintel> ugh
<stintel> /home/stijn/Development/OpenWrt/openwrt/staging_dir/toolchain-x86_64_gcc-10.3.0_musl/include/fortify/stdlib.h:40:13: error: 'realpath' undeclared here (not in a function)
<stintel> this annoying fucker again
jlsalvador2 has joined #openwrt-devel
jlsalvador has quit [Read error: Connection reset by peer]
jlsalvador2 is now known as jlsalvador
<aiyion> Back to fun with erthernet and mdio again :/
<dangole> stintel: that's odd, realpath() should be part of stdlib. is that happening when using fortify headers with musl-1.2?
<stintel> dangole: this keeps appearing at random
<stintel> dangole: I nuked my entire build_dir and staging_dir
<stintel> I'm thinking of starting doing that more often because this is just too bloody fragile
Rentong has joined #openwrt-devel
Rentong has quit [Ping timeout: 480 seconds]
rejoicetreat has joined #openwrt-devel
goliath has quit [Quit: SIGSEGV]
Tapper has quit [Ping timeout: 480 seconds]
clayface_ has joined #openwrt-devel
clayface has quit [Ping timeout: 480 seconds]
<dangole> stintel: can you take a look at https://git.openwrt.org/?p=openwrt/staging/dangole.git;a=shortlog;h=refs/heads/sdcard-legacy-rename
<dangole> (and maybe run-time test, I don't have any mvebu devices at hand)
<stintel> dangole: please maintain the alphabetical order in the features :)
<dangole> stintel: updated already, also just noticed :)
<stintel> :P
<stintel> dangole: you should also probably squash commits, now the first one will break mvebu
<stintel> not ideal for bisecting
<dangole> ok, so i squash them, you are right.
<stintel> great
<stintel> I will try to runtime test it later today, right now building x86/64 with CONFIG_ALL_PACKAGES as part of my switch to gcc10 by default work
<stintel> but I'm meeting some friends soon, and tomorrow I'm off to the seaside for a week
<stintel> probably tonight, I'll try not to drink too many beers :P
<stintel> dangole: and maybe elaborate a tiny bit more in the commit message, just briefly some things that you mentioned in the comment on my commit ?
<dangole> stintel: I'll fix it up now and you test when ever you can, tonight or next week, no rush
<stintel> aight, I'll put a reminder for next weekend so that if I don't manage to get to it tonight, it won't be forgotten
<stintel> and thanks!
<stintel> wtf
<stintel> /home/build/openwrt/staging_dir/host/include/libubox/blobmsg.h:256:2: error: 'o' may be used uninitialized in this function [-Werror=maybe-uninitialized]
<stintel> uhttpd doesn't build?
<dangole> stintel: uhttpd builds fine for me (with gcc-8)
<stintel> strange, I don't remember running into this when I worked on this previously
<stintel> the error is also completely bogus, there is no "o" in there at all
Borromini has quit [Quit: leaving]
Tapper has joined #openwrt-devel
<stintel> wtf. problem disappeared
<stintel> oh well, have to run
<stintel> great, laundromat malfunction, didn't drain the water
<tmn505> dangole: I would rename it to mbr-sdcard to make it clear what kind of legacey is that.
<dangole> tmn505: even the modernized method without bootfs can work just fine with MBR formatted media (see mediatek/mt7623, which supports only MBR because of bootrom restrictions)
<tmn505> then what is the legacy in this case?
<aiyion> Can somebody recommend an introduction on ath79 dts files regarding mdio and eth?
Luke-Jr has quit [Ping timeout: 480 seconds]
<aiyion> the ar71xx image has a line "ag71xx-mdio.1:04 [uid=004dd041" in dmesg, my ath79 draft is consisted of zeros only in htat line...
<aiyion> I found phymask appears to modify the two digits after the double colon; but what modifies the digit in front of it?
Rentong has joined #openwrt-devel
<tmn505> dangole: do You mean uImage vs FIT? So from the angle of U-Boot that's legacy indeed, but considering more boards implement ACPI, from their perspective FIT image is also legacy :)
<dangole> tmn505: the VFAT/MSDOS formatted bootfs which presents a single point of failure (and it's a filesystem made for winchester and floppy disks from the 1980s)
<dangole> I've updated the commit description: https://git.openwrt.org/?p=openwrt/staging/dangole.git;a=commit;h=25d42ee7527bf89539fbb2ebedd56b6dde4c0ec1
<dangole> tmn505: what does ACPI have to do with all that?
<dangole> tmn505: do you actually mean UEFI?
<tmn505> Yeay
<tmn505> yeah
<tmn505> so the block devices are treated as in x86
<dangole> tmn505: because that's supported on some very modern Aarch64 targets, but I don't see it becoming a reality for OpenWrt (other than x86) in the near future.
<tmn505> btw that code that stintel move doesn't mandate VFAT
<tmn505> *moved
<dangole> tmn505: it mandates a single boot filesystem which is used to store kernel and config backup. U-Boot can't do fsck or journaling, so risk for failure, esp. when used on SD cards, is quite high.
<tmn505> yeah that's correct
<dangole> tmn505: and yes, that's exactly the thing: why would you want to handle block devices on embedded, headless and typically remote managed devices to be like your x86 desktop machine dating back to the IBM PC from 1980?
<tmn505> so from that angle it's indeed legacy
<dangole> tmn505: i understand the habitual aspect, so for low-entrance-barrier devboards like the RasbPi I understand why this decision has been made.
<dangole> tmn505: but in OpenWrt? I just struggled too much with broken filesystems and half-broken (due to lack of 'discard' op in VFAT) media, which at times made things very complicated.
<dangole> tmn505: (as in: involved physical access, which can be complicated)
<tmn505> considering rpi as the most popular that's indeed the case, but some of the U-Boot devices use ext4 so fs-checking when mounting could be implemented
<dangole> tmn505: as as the bootloader itself is typically also stored on the SD card, it's completely up to us to decide how we want the bootchain to be designed.
<tmn505> both my devices store U-Boot in NOR so not my pair of trousers :)
<dangole> tmn505: thing is that doing fsck once linux has loaded is just too late. because in case primary superblock on ext4 (or FAT index on MSDOS fs) is broken, U-Boot will stop right there and not even load environment, kernel and so on.
<dangole> tmn505: having it all on raw flash is the best anyway ;) it's not that i particularly like those black-box flash-abstraction layers built-into SD cards and eMMC.
<tmn505> yeah. So conceptually our default to go policy of creating images is prone to failure. Tbf never found myself in position of faled SD card before I could see it, so that is something I usually never conssidered.
<tmn505> thanks for the explanation, I Ack on this change
Luke-Jr has joined #openwrt-devel
<dangole> tmn505: it can even be software corruption (as in: power failure happened at the wrong moment) to destroy the boot partition. and of course, rootfs can be broken as well and using the legacy layout, U-Boot has know way to know that (and boot something else, like a recovery system, instead then)
<tmn505> dangole: so with that in consideration, the best approach is a dual-boot. I can't see it otherwise
<dangole> tmn505: exactly. and in order to have reliable dual-boot, you can't just store your two copies of the kernel in the same boot filesystem.
<tmn505> thanks, I'll try to digest this and maybe come with better image for my devices
<dangole> tmn505: very welcome :) check out BananaPi R2 (mediatek/mt7623) or R64 (mediatek/mt7622) for examples of how it can be done.
<dangole> tmn505: i'
<dangole> m about to order a cheap sunxi and a cheap rockchip sbc as well, so i can also port that method to these popular SD card targets
<fda> to reduce risk of corrumt filesystems (not only fat) it would help if sysupgrade reglary stops all services like on shutdown/reboot
<fda> sysupgrade not stopping the services prevent also to run custom backup scripts which i have to do currently manually
<Zero_Chaos> okay, this might be a crazy request, but, is there a way to boot openwrt with all wifi down, and then bring it up after *without modifying /etc/config/wireless* at runtime? I can do it by disabling all radios and then enable with uci set, but that modifies the config and causes me some pain
<Zero_Chaos> can I just, start networking but not wireless at boot and run a command to start it? like just starting in a "wifi down" state
rejoicetreat has quit [Remote host closed the connection]
rejoicetreat has joined #openwrt-devel
Rentong has quit [Remote host closed the connection]
<aiyion> I made a mistake earlier: its not phy-mask but the `reg = <4>` entry, that is responsible for the four after the colon. The question stands though, what dts-entry changes the number in front of it?
rejoicetreat has quit [Ping timeout: 480 seconds]
Rentong has joined #openwrt-devel
minimal has joined #openwrt-devel
Tapper has quit [Ping timeout: 480 seconds]
Rentong has quit [Ping timeout: 480 seconds]
clayface_ has quit [Read error: Connection reset by peer]
clayface has joined #openwrt-devel
Rentong has joined #openwrt-devel
valku has joined #openwrt-devel
Tapper has joined #openwrt-devel
Rentong has quit [Remote host closed the connection]
Borromini has joined #openwrt-devel
Luke-Jr has quit [Ping timeout: 480 seconds]
Rentong has joined #openwrt-devel
Rentong has quit [Ping timeout: 480 seconds]
Rentong has joined #openwrt-devel
Luke-Jr has joined #openwrt-devel
Rentong has quit [Ping timeout: 480 seconds]
Luke-Jr has quit [Ping timeout: 480 seconds]
Luke-Jr has joined #openwrt-devel
Luke-Jr has quit [Read error: Connection reset by peer]
Grommish has joined #openwrt-devel
rmilecki has joined #openwrt-devel
Luke-Jr has joined #openwrt-devel
rmilecki has quit [Ping timeout: 480 seconds]
fda has quit [Quit: ZNC - https://znc.in]
fda has joined #openwrt-devel
jlsalvador2 has joined #openwrt-devel
jlsalvador has quit [Remote host closed the connection]
jlsalvador2 is now known as jlsalvador
jlsalvador2 has joined #openwrt-devel
jlsalvador has quit [Read error: Connection reset by peer]
jlsalvador2 is now known as jlsalvador
jlsalvador has quit [Read error: No route to host]
jlsalvador has joined #openwrt-devel
rmilecki has joined #openwrt-devel
jlsalvador has quit [Read error: Connection reset by peer]
jlsalvador has joined #openwrt-devel
Tapper has quit [Ping timeout: 480 seconds]
rmilecki has quit [Ping timeout: 480 seconds]
arifre has quit [Remote host closed the connection]
<owrt-1907-builds> Build [#21](https://buildbot.openwrt.org/openwrt-19.07/images/#builders/52/builds/21) of `samsung/s5pv210` failed.
<owrt-1907-builds> Build [#22](https://buildbot.openwrt.org/openwrt-19.07/images/#builders/13/builds/22) of `rb532/generic` failed.
minimal has quit []
slh64 has quit [Remote host closed the connection]
slh has quit [Read error: Connection reset by peer]
<Slimey> rm -f /home/briang/openwrt/build_dir/target-mips_24kc_musl/linux-ath79_generic/image-ar7161_adtran_bsap1840.dtb.tmp
<Slimey> mips-openwrt-linux-musl-cpp: error: ../dts/_adtran_bsap1920.dts: No such file or directory
<Slimey> sl/linux-ath79_generic/image-_adtran_bsap1920.dtb.tmp ../dts/_adtran_bsap1920.dts
<Slimey> mips-openwrt-linux-musl-cpp -nostdinc -x assembler-with-cpp -I/home/briang/openwrt/build_dir/target-mips_24kc_musl/linux-ath79_generic/linux-5.4.137/arch/mips/boot/dts -I/home/briang/openwrt/build_dir/target-mips_24kc_musl/linux-ath79_generic/linux-5.4.137/arch/mips/boot/dts/include -I/home/briang/openwrt/build_dir/target-mips_24kc_musl/linux-ath79_generic/linux-5.4.137/include/ -undef -D__DTS__ -o /home/briang/openwrt/build_dir/target-mips_24kc_mu
<Slimey> mips-openwrt-linux-musl-cpp: warning: '-x assembler-with-cpp' after last input file has no effect
<Slimey> mips-openwrt-linux-musl-cpp: fatal error: no input files
<Slimey> compilation terminated.
<Slimey> make[5]: *** [Makefile:99: /home/briang/openwrt/build_dir/target-mips_24kc_musl/linux-ath79_generic/image-_adtran_bsap1920.dtb] Error 1
<Slimey> anyone know whats going on here?
<Slimey> its an older ath79 target that builds under Firmware VersionOpenWrt SNAPSHOT r11034-cf6ccef8f2 / LuCI Master git-19.310.73347-8c9ee39
<Slimey> Kernel Version4.19.72
<Slimey> trying to update it
<Borromini> i'd say that's pretty glaring
<Borromini> ../dts/_adtran_bsap1920.dts: No such file or directory
<Borromini> and please use pastebin for such a boatload of text
<Borromini> you have a typo somewhere, probably, I reckon it's that leading underscore
<Slimey> its not that way under the targets folder
<Slimey> something is adding that underscore
<Borromini> your build recipe probably
<tmn505> looks like You have botched up the tree or have dirty environment variable somewhere, before underscore there should be SOC variable in Your case ar7161. Do fresh clone and try again.
<Slimey> k
Luke-Jr has quit [Ping timeout: 480 seconds]
dangole has quit [Remote host closed the connection]
dangole has joined #openwrt-devel
Luke-Jr has joined #openwrt-devel
Borromini has quit [Quit: Lost terminal]
slh has joined #openwrt-devel
slh64 has joined #openwrt-devel