<ynezz>
I would like to provide simple command for dnsmasq upgrade
<ynezz>
it should be copy&paste stuff, something like `opkg update; opkg upgrade dnsmasq`
<ynezz>
but dnsmasq has 3 variants: dnsmasq, dnsmasq-full and dnsmasq-dhcpv6
<ynezz>
how to handle this case?
<ynezz>
I wanted to use `opkg list-upgradable` with some grep/sed foo, but it OOMs here :p
<rsalvaterra>
aparcar[m]: pong
noltari has quit [Quit: Bye ~ Happy Hacking!]
noltari has joined #openwrt-devel
<dorf_>
ynezz: you probably want to do an opkg list-installed to determine which dnsmaq package is installed first, no?
<dorf_>
that said, list-upgradable should show you what you have installed.
<dorf_>
if it ain't installed, it ain't upgradeable :)
noltari has quit [Quit: Bye ~ Happy Hacking!]
noltari has joined #openwrt-devel
<ynezz>
yeah, but this is quite long: opkg update; opkg upgrade $(opkg list-installed | sed -n '/dnsmasq/ s/\([a-z]*\) - .*/\1/p')
<aparcar[m]>
rsalvaterra: are you sure the kernel things adds 24kb alone? I though in combination with ip-full
<ynezz>
d'oh, I can't even run that upgrade
<ynezz>
`opkg upgrade dnsmasq` OOMs
<ynezz>
Out of memory: Killed process 3468 (opkg) total-vm:53736kB, anon-rss:52688kB, file-rss:0kB, shmem-rss:0kB, UID:0 pgtables:136kB oom_score_adj:0
<aparcar[m]>
opkg still produces ooms?
<ynezz>
this is x86/64 under qemu with 128MB RAM
<rsalvaterra>
aparcar[m]: It's the total image, no the kernel, sorry. It's written in the commit it fixes, though "Increases imagesize by 24.125 KiB.".
<rsalvaterra>
Anyway, it's quite perplexing to enable a feature like that, without even giving the chance to disable it.
Tapper has quit [Ping timeout: 240 seconds]
<rsalvaterra>
I know it's only enabled by default for the targets which specify the small_flash feature, but that means anything with > 4 MiB of flash. 24 kiB on an 8 MiB device is a non-negligible amount of space, imho.
dorf has joined #openwrt-devel
<rsalvaterra>
*which don't specify
Tapper has joined #openwrt-devel
dorf_ has quit [Ping timeout: 265 seconds]
<aparcar[m]>
rsalvaterra: okay I added your patch thank you
<rsalvaterra>
aparcar[m]: No, I thank you! :)
xback has quit [Remote host closed the connection]
dorf has quit [Remote host closed the connection]
poljar has joined #openwrt-devel
feriman has joined #openwrt-devel
poljar1 has quit [Ping timeout: 240 seconds]
numero53 has joined #openwrt-devel
jas4711 has joined #openwrt-devel
Borromini has joined #openwrt-devel
noltari has quit [Quit: Bye ~ Happy Hacking!]
Net147 has quit [Read error: Connection reset by peer]
Net147 has joined #openwrt-devel
dorf has joined #openwrt-devel
noltari has joined #openwrt-devel
noltari has quit [Client Quit]
<russell-->
ynezz: not ooming for me on ath79
noltari has joined #openwrt-devel
nitroshift has quit [Quit: Gone that way --->]
noltari has quit [Client Quit]
feriman has quit [Quit: WeeChat 3.0]
noltari has joined #openwrt-devel
ivanich has joined #openwrt-devel
noltari has quit [Quit: Bye ~ Happy Hacking!]
feriman has joined #openwrt-devel
rsalvaterra1 has joined #openwrt-devel
noltari has joined #openwrt-devel
rsalvaterra has quit [Ping timeout: 246 seconds]
noltari has quit [Client Quit]
black_ant has joined #openwrt-devel
black_ant has joined #openwrt-devel
noltari has joined #openwrt-devel
black_ant has quit [Changing host]
victhor has joined #openwrt-devel
noltari has quit [Client Quit]
goliath has quit [Quit: SIGSEGV]
hbug___ has quit [Remote host closed the connection]
kontaxis has quit [Remote host closed the connection]
kakaka has quit [Remote host closed the connection]
<romany>
have anyone thought of using json for UCI to store config files?
<stintel>
uhhh plz no
<Borromini>
:P
<SpaceRat>
Arrrrgh
<romany>
:) why not? what are the cons?
<ynezz>
xml!
* ynezz
hides
<romany>
cmon, xml is not for humans :)
<mangix>
but uci is
<romany>
you mean basically ini format which uci currently uses
<romany>
it has 2 level limitation which is preventing it to be used with more complex things requiring more levels
<romany>
and json is human readable too
<romany>
so, why not?
<stintel>
it's human readable but hardly writeable
<stintel>
it's very error prone. there are people who edit those files manually instead of using uci set foo or luci
<stintel>
now if there would be a cisco/huawei/... style cli with full command tab-completion, I wouldn't care
<grift>
if its not broken then dont fix it? besides no matter what format, its internal and you should use uci to edit config. also if you add support for more complexity to the format then uci needs to support that and that makes uci more complex, is there a need for more levels on complexity?
<stintel>
using uci to edit config is simply not user friendly enough
<stintel>
hence I edit my config files manually
<stintel>
I'm sure I'm not the only one
<f00b4r0>
indeed not :)
<grift>
changing the config format is hardly a solution to that challenge
<grift>
anyway i guess for the audience that doesnt like uci theres luci
<stintel>
I'm not the one suggesting it. I'm *against* it, as it would make manually editing config files even harder
<grift>
yes but youre assuming that you would still be manually editting it. gives me the impression that you just like manually editing configs
<stintel>
editing config files is easier than uci set blah or using luci
<grift>
maybe in that case an idea to by-pass to unified config interface all together
<stintel>
or do you know all uci keys by heart ?
<stintel>
I for sure don't
<grift>
uci --help?
feriman has quit [Ping timeout: 265 seconds]
<stintel>
I was talking about the things returned from "uci show"
<grift>
just simple key value pairs, but i rest my case. we have different view but they lead to the same conclusion
Darkmatter66 has joined #openwrt-devel
<stintel>
yeah, very simple. with sometimes @, sometimes not, foo[n], etc. totally not user friendly. editing files is much easier. it's also the file format that is usually documented, not the uci keys
Night-Shade has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<Borromini>
uci commands can be a b*tch to figure out
<Borromini>
named, unnamed sections, ...
<grift>
i admit that
<grift>
but the config format is not at issue here
<romany>
IMO uci as such is very good and needed abstraction but it's current limitations are preventing OpenWrt to become a more serious product, which it has a potential for
<romany>
like a modern NOS would require FRR, which has pretty complex configuration but can be represented in json
<grift>
it might help of you give us a tangible problem statement and a solution to your multi level idea
<grift>
not just "it doesnt support multi-level"
csrf has joined #openwrt-devel
<romany>
converting FRR config into current uci format is a nightmare and clurrer
<grift>
ie where do you need multi level and how would using json solve it in a proof of concept
<grift>
if youre convinced of your case then i guess send a [RFC PATCH]
<grift>
would be a huge undertaking to change this tree-wide
noltari has joined #openwrt-devel
<grift>
might need compatibility for a transition
<stintel>
if this is something we even want to consider, I think it should be something new, keep uci as is, let the user decide what he uses
<stintel>
and if ever good enough, switch default
<romany>
yeah, for transition I was thinking that it could read old uci and save to json and if json exists it prefers json
reiffert has quit [Read error: No route to host]
reiffert has joined #openwrt-devel
black_ant has quit [Quit: simplicity does not kill]
<plntyk>
is somebody working on "lantiq/Easybox 904 xDSL" ? i saw this in some commit messages as "run tested" however this box isnt supported in mainline openwrt and the pull requests for that box are old & closed
<plntyk>
last commit w. that box in build & run tested was 667f6c7f49c94213ca43a42ad5a9e23abfd81861 (Kernel 5.4.77 bump)
Misanthropos has quit [Read error: Connection reset by peer]
Borromini has quit [Ping timeout: 260 seconds]
Misanthropos has joined #openwrt-devel
swex has quit [Quit: swex]
swex has joined #openwrt-devel
zjason has joined #openwrt-devel
adrianschmutzler has joined #openwrt-devel
valku has joined #openwrt-devel
rsalvaterra1 has quit [Quit: Leaving.]
rsalvaterra has joined #openwrt-devel
hurricos1 has quit [Quit: WeeChat 2.8]
hurricos has joined #openwrt-devel
<hurricos>
what's preventing multiple tabs from being used to make further levels in uci?
<hurricos>
other than that tabs/spaces differentiation is a horrifying abomination?
<hurricos>
err s/uci/file-based config storage/
goliath has joined #openwrt-devel
<romany>
hurricos, what are you talking about? uci is section.option style config, tabs/spaces don't mean anything
Darkmatter66 has joined #openwrt-devel
luke-jr has quit [Read error: Connection reset by peer]
luke-jr has joined #openwrt-devel
gch9812133289452 has joined #openwrt-devel
Darkmatter66 has quit [Ping timeout: 260 seconds]
Darkmatter66 has joined #openwrt-devel
numero53 has quit [Quit: Connection closed]
quark_ has quit [Ping timeout: 264 seconds]
quark_ has joined #openwrt-devel
Darkmatter66 has quit [Ping timeout: 264 seconds]
Darkmatter66 has joined #openwrt-devel
Borromini has joined #openwrt-devel
kakaka has quit [Remote host closed the connection]
kakaka has joined #openwrt-devel
noltari has quit [Ping timeout: 240 seconds]
noltari has joined #openwrt-devel
Misanthropos has quit [Read error: Connection reset by peer]
kontaxis has quit [Remote host closed the connection]
kontaxis has joined #openwrt-devel
Borromini has quit [Quit: Lost terminal]
Darkmatter66 has quit [Ping timeout: 256 seconds]
<aparcar[m]>
20 more commits untils 50k
astylian has quit [Remote host closed the connection]
<rsalvaterra>
adrianschmutzler: ping
<adrianschmutzler>
rsalvaterra: pong
SAn has joined #openwrt-devel
<rsalvaterra>
Anything blocking my x86 dead code and data elimination patch?
<adrianschmutzler>
I don't do x86 ...
<rsalvaterra>
It's 200 kB For Free™…
<adrianschmutzler>
It's too different from the rest
<adrianschmutzler>
Unless it's really trivial
<rsalvaterra>
Ah, right.
<rsalvaterra>
Who's the x86 boss, then? :)
<adrianschmutzler>
well, I don't think anybody cares about size on x86
<adrianschmutzler>
so, probably they have better things to do .....
<rsalvaterra>
That's something that strikes me as really odd. I care about size *everywhere*… :/
<rsalvaterra>
It's a matter of efficiency, to me.
<rsalvaterra>
But whatever…
<adrianschmutzler>
well, it's also a matter of efficiency where a reviewer will invest time in when there is more to review than time
<adrianschmutzler>
but I'm just guessing ...
<adrianschmutzler>
I won't review/merge it because it's x86 ...
<rsalvaterra>
Sure, I just wanted to know if I needed to fix anything more. Thanks, anyway. :)
<aparcar[m]>
rsalvaterra: which patch? also x86 has various container-foo options enabled which requires size, it doesn't make sense to me hunting down single kBs
<aparcar[m]>
rsalvaterra: does that patch work for other targets too?
<rsalvaterra>
ARM (not 64, mind you) POWER and MIPS already have similar patches. Mine applies to x86 and x86-64.
<aparcar[m]>
¯\_(ツ)_/¯
<aparcar[m]>
I can compile and run check it, not that I actually understand what it does... not sure if that's of much help
<rsalvaterra>
Well, I just mark the unreferenced sections which mustn't be garbage-collected and specify the architecture supports dead code and data elimination. The kernel build system does the rest. :)
<rsalvaterra>
Anyway, don't worry about it, I'll just wait for a x86 specialist to curse at me. :P
adrianschmutzler has quit [Quit: ~ Trillian - www.trillian.im ~]
muhaha has joined #openwrt-devel
<aparcar[m]>
mangix: squashfs-tools wasn't maintained for a while, patches piled up on upstream so lynxis forked it at some point, e.g. to have reproducible images. Eventually the maintainer did things but OpenWrt is still on the (now outdated) fork
<aparcar[m]>
squashfs-tools is the initial implentation, squashfskit is lynxis fork and squashfs-tools-ng is the proposed reimplementation
<mangix>
aparcar[m]: what's the advantage?
<mangix>
can lynxis fork be backported to upstream?
<lynxis>
mangix: we could try to change just back to the upstream
<lynxis>
or use squashfs-kit
kakaka has quit [Ping timeout: 240 seconds]
<aparcar[m]>
a switch to upstream is fine for me too, however it lacks still multiple patches which are used in tree
<aparcar[m]>
the dev of -ng was very helpful in reacting and fixing things, so that'd be a plus
<aparcar[m]>
seems like upstream got some traction lately, I'm open to any of the three solutions
astylian has joined #openwrt-devel
<aparcar[m]>
mangix: can you give me an example on how to test your libusb patch? I guess I should try something with usbmode?
rmilecki has quit [Ping timeout: 246 seconds]
Tsesarevich has quit [Read error: Connection reset by peer]
grift has quit [Remote host closed the connection]