<bkallus>
I'm working on a build of openwrt for the actiontec mi424wr rev i, and I got something booting. However, when I add DEVICE_PACKAGES := kmod-ath9k to my device's config in the kirkwood image makefile, it tells me that certain packages are "incompatible with the architectures configured"
<bkallus>
where do I go from here?
CaptFrito1 has joined #openwrt-devel
<mangix>
aparcar[m]: sent new autoconf patch
bkallus has quit [Quit: Leaving]
Tapper has quit [Ping timeout: 272 seconds]
<mangix>
aclocal.m4:6: error: Exactly version 2.69 of Autoconf is required but you have 2.70
<mangix>
what the hell
<aparcar[m]>
heh
<mangix>
that's a glibc error
<aparcar[m]>
mangix: keep me posted
<mangix>
going to try a musl build now
Katana_Steel has quit [Read error: Connection reset by peer]
Katana_Steel has joined #openwrt-devel
<mangix>
I think it's because the glibc is subtly broken
<mangix>
I remember an issue on CentOS 7 where it doesn't compile due to old make version
<mangix>
it's supposed to use tools/make but uses OS make
<mangix>
musl compiled
goliath has joined #openwrt-devel
danitool has quit [Ping timeout: 240 seconds]
hbug___ has joined #openwrt-devel
Tost has quit [Ping timeout: 265 seconds]
hbug__ has quit [Ping timeout: 268 seconds]
silverwhitefish has joined #openwrt-devel
silverwhitefish has quit [Quit: One for all, all for One (2 Corinthians 5)]
<mangix>
aparcar[m]: meh ignore it. a bunch of packages fail
<mangix>
someone else can deal with it
black_ant has joined #openwrt-devel
black_ant has joined #openwrt-devel
dorf has joined #openwrt-devel
dorf_ has quit [Ping timeout: 256 seconds]
tobleminer-tSYS has quit [Quit: AS4242423214]
tobleminer-tSYS has joined #openwrt-devel
Huntereb has joined #openwrt-devel
<philipp64>
Anyone want to review PR #14489? Thanks
<philipp64>
mangix: that's surprising. glibc gets built in so many places (though not all of them appropriate, given its footprint).
linzst has joined #openwrt-devel
<mangix>
philipp64: ummmm not in OpenWrt
slh64 has joined #openwrt-devel
rmilecki has joined #openwrt-devel
massoud has quit [Ping timeout: 272 seconds]
massoud has joined #openwrt-devel
<philipp64>
mangix: I meant regarding building glibc on Centos7, unless I've missed something...
daregap has joined #openwrt-devel
nitroshift has joined #openwrt-devel
dedeckeh has joined #openwrt-devel
<mangix>
philipp64: i assume a newer make is available with whatever backports they have
valku has quit [Quit: valku]
dedeckeh has quit [Quit: Ping timeout (120 seconds)]
linzst_ has joined #openwrt-devel
Huntereb has quit [Ping timeout: 256 seconds]
Pix has quit [Remote host closed the connection]
linzst has quit [Ping timeout: 256 seconds]
Pix has joined #openwrt-devel
linzst_ is now known as b4today
grift has quit [Quit: Bye]
grift has joined #openwrt-devel
grift has quit [Remote host closed the connection]
<stintel>
for the gentoo folks, there's an ebuild for git-pw in my overlay ;)
<Tapper>
Wow we got more press for the forum hack than when we put out a new build!
<Borromini>
stintel: debian testing has git-pw 2.0 :P
<mangix>
Borromini: second the git-pw from pip
<Tapper>
I am just checking the twitter.
<Borromini>
Tapper: one would alsmost think you ordered it ;)
<mangix>
works on centos 7 as well
<Tapper>
lol
* Borromini
has once set up a virtualenv but hasn't really bothered so far, don't do that much with python
nitroshift has joined #openwrt-devel
decke has quit [Quit: Leaving.]
<olmari>
mm, with python "programs", virtualenv is generally the way to go, one can install stuff with pip to there to hearts contents and not mess up global stuff
<olmari>
which, with pip, is easy
<mangix>
same with cargo
dedeckeh has quit [Quit: Ping timeout (120 seconds)]
<olmari>
or with global stuff it is "default thought" that OS/repo provided python stuff is to be used, pip in otherhand gets whatever versions and packages one desires, hence venv is useful there
<mangix>
btrfs-progs: scrub status: print percents of scrubbed bytes
<mangix>
finally
<olmari>
so in good and bad, python makes it easy to "virtualize" python enviroment, and then free to use whatever versions needed for the exact project... Without needing to think what the next one needs
<Borromini>
so a virtualenv per 'package' is recommended?
hsp has quit [Ping timeout: 260 seconds]
<Borromini>
great. just forgot to do sysupgrade -n :-/
* Borromini
preps for breakage
<stintel>
what's the point of sysupgrade anyway if you use it with -n ¯\_(ツ)_/¯
<olmari>
Borromini: generally yes, per package or per project, etc... "one unit of program(s) you provide" :D
<mangix>
Borromini: DSA?
<stintel>
I sysupgraded my dir860l from >2yo image to master without -n but with -f and it worked :P I did prepare /etc/config/network for it though, don't remember what exactly I did
<Borromini>
mangix: no just an mtdsplit series
<stintel>
but I've got so many configs on most of my devices, if I can't reliably sysupgrade without doing -n I'd find another distro
<olmari>
most python based packages from any OS repos has venv baked in them at some method (because OFCOURSE there has to be multime methods for that too 😀 )
<Borromini>
but it seems i did, since it's reset itself to default IP and settings :)
<Borromini>
stintel: i learnt to make backups :P
<olmari>
s/packages/random python-based program that is available at a repo
<stintel>
Borromini: too many devices to be restoring backups all the time. the backups also contain the incompatible config so you'd be messing about anyway
<Borromini>
stintel: oh. yeah :(
<stintel>
Borromini: all my OpenWrt devices have automated nightly sysupgrade --create-backup ..
<Borromini>
eh? :P
<grift>
i use sysupgrade without -n all the time
<grift>
it doesnt matter if you are on-top of things
<stintel>
Borromini: well running master soft-bricks stuff every now and then, I need those backups :P
<Borromini>
true :P
* Borromini
looks at his second bricked tl-wr1043nd v2
<stintel>
eh, 4MB flash right? throw it in the bin ;)
<stintel>
8MB isn't even enough anymore for my dumpAP images :/
<mangix>
stintel: get that soldering iron
<mangix>
Borromini: isn't that thing 2.4ghz n only?
<Borromini>
stintel: i thought the v2 had 8 MiB
<Borromini>
mangix: it is, but i kept it around as an ath79 testing device
hsp has joined #openwrt-devel
<stintel>
mangix: pfft that thing is too slow anyway
<stintel>
I remember borrowing one from a friend for stress-testing some ath9k bugfixes
<stintel>
for the 17.x release or so
<Borromini>
:)
feriman has joined #openwrt-devel
<Borromini>
svanheule[m]: sorry i don't recall - did the patch set work for you with and without keeping settings?
adrianschmutzler has joined #openwrt-devel
<mangix>
stintel: i tried overclocking it. was only successful in doing a 20 mhz overclock
plntyk has quit [Quit: Leaving]
dedeckeh has joined #openwrt-devel
<Borromini>
svanheule[m]: nevermind, works both ways here with my mt7621 device at least :-)
<jow>
Borromini: DigitalOcean, our hoster for forum, wiki, mail
<Borromini>
oh :)
<Hauke>
I think that most forum admin even with similar number of suers would not detect such a problem, the ones who detect it probably most of them just change the password and thats it, I would be supprised if the rate of forums which inform thgeir users in such a cases is bigger than 5%
<Hauke>
the dnsmasq updates are pushed now, please test them again and then someone can create 19.07.6
daregap has quit [Quit: daregap]
hbug___ has quit [Ping timeout: 268 seconds]
hbug___ has joined #openwrt-devel
xback has quit [Ping timeout: 240 seconds]
Darkmatter66 has joined #openwrt-devel
<Borromini>
honestly i try to set 2FA on all the accounts that allow it but i wasn't aware discourse already allowed that.
<stintel>
Borromini: I recently found out and added all my U2F keys
<stintel>
now I'm actually thinking to retire my yubikeys if they can actually be cloned
<Borromini>
:)
<stintel>
and I just got them :P (well 2 out of the 4 I have)
<Borromini>
:P
<Borromini>
so you have yubi *and* the solos?
<stintel>
yeah, I got the new yubi's (5+NFC and 5C+NFC) at the time our mother company got pwnd
<stintel>
a bit of an impulse buy
<stintel>
then I remembered the open alternatives
<Borromini>
:)
<Borromini>
i'm not sure if the keys allow cloning. what i read last time i researched was you just need to register two keys with e.g. google or whatever site you'd like to use it with
<Borromini>
so not a real backup, but just another key you keep safe somewhere in case the first gets lost
<stintel>
yes. and the problem there is: you cannot register the "backup" key when you're on the go and register on a new website
<stintel>
I still have to check if the U2F/FIDO2 implementations of Ledger or Trezor Cryptocoin wallets will generate the whatever key this standard uses from your seed
<stintel>
in this case, that problem would be irrelevant
<stintel>
as you will be able to have n "identical" keys
<stintel>
actually I can test that as I have 2 ledger wallets
* stintel
find the 2nd one
<stintel>
imagine that works via bt
<stintel>
I'd immediately order another Ledger Nano X
<stintel>
apparently it does
<Borromini>
:)
<stintel>
but no fido2 yet
<stintel>
derp
<olmari>
Apparently solokey v2will have ed25519 key support too, they answered (for sideways relating)
<stintel>
oooh and #478 will implement this possibly on the v1
<ynezz>
FATAL ERROR: Couldn't open "/builder/shared-workdir/build/build_dir/target-aarch64_generic_musl/linux-layerscape_armv8_64b/linux-4.14.215/arch/arm64/boot/dts/freescale/fsl-ls1043a-rdb-sdk.dtb.tmp": No such file or directory
<Hauke>
ynezz: I assume this is a concurrency problem because these build bots have different number of core or speed
<Hauke>
I retriggered it
state has joined #openwrt-devel
gch9812133289452 has joined #openwrt-devel
shibboleth has quit [Quit: shibboleth]
CaptFrito1 has left #openwrt-devel [#openwrt-devel]
numero53 has joined #openwrt-devel
state has quit [Ping timeout: 272 seconds]
dannyAAM has quit [Remote host closed the connection]
dannyAAM has joined #openwrt-devel
eduardas has joined #openwrt-devel
Darkmatter66 has joined #openwrt-devel
eduardas has quit [Quit: Konversation terminated!]
swex has quit [Read error: Connection reset by peer]
swex has joined #openwrt-devel
Darkmatter66 has quit [Read error: Connection reset by peer]
<aparcar[m]>
adrianschmutzler: I'm about to push the AUTORELEASE patch for base-files, it would raise the relase once from 242 to 1401, do you think that's a problem?
<adrianschmutzler>
increasing is never a problem
<adrianschmutzler>
only decreasing
<aparcar[m]>
ack
<adrianschmutzler>
if unsure, i.e. if the syntax changes, use the opkg compare tool
<aparcar[m]>
adrianschmutzler currently the release reset happens on either bump or update, should I add any other "codeword"?
<adrianschmutzler>
well, I don't really understand the mechanics, so I don't know ...
blb4393 has joined #openwrt-devel
<aparcar[m]>
if using AUTORELEASE as PKG_RELEASE the number of commits since a commit with subject including "update to" or "bump to" is used
<aparcar[m]>
meaning no more manual modification of PKG_RELEASE and still knowing how many downstream releases we had since the last upstream version change
<adrianschmutzler>
okay, so this is useless for base-files where we have no upstream
<adrianschmutzler>
let me check uboot-envtools
<adrianschmutzler>
how will you deal with stable branches? just live with collisions in the PKG_RELEASE, as it does refer to a specific state anymore anyway?
<adrianschmutzler>
... does _not_ refer ...
<adrianschmutzler>
For uboot-envtools there is "update to" and "bump to", rarely also with capital first letter
<adrianschmutzler>
Note that just "update" won't work there, as one might just "update flash location of device X" etc.
<aparcar[m]>
it works for both base-files and uboot-envstuff
<adrianschmutzler>
I see
<adrianschmutzler>
Though the use of that $(1) argument is really ugly
<adrianschmutzler>
I'd consider splitting that into two functions ...
<adrianschmutzler>
commitcount and commitsinceupdate
<adrianschmutzler>
or like that
<adrianschmutzler>
and I'm not sure whether I like the date as fallback
madwoota has quit [Ping timeout: 264 seconds]
<adrianschmutzler>
If one implements that to work as commit count or "autorelease", it should fail if no data is available
<adrianschmutzler>
and not switch to a totally different scheme without notice
<aparcar[m]>
it's pretty much what luci does, using date as fallback
<aparcar[m]>
so failing here is not an option
<adrianschmutzler>
well, what you do depends on what you want to do with it
<adrianschmutzler>
if you want a global mechanism that is thrown onto any package, you will choose something like that
<adrianschmutzler>
but then you wouldn't distinguish between COMMITCOUNT and AUTORELEASE, but just go fully automatic
<adrianschmutzler>
but if you assume the user will choose and apply a specific scheme to a specific package (like COMMITCOUNT vs. AUTORELEASE), I'd serve a specific scheme
<adrianschmutzler>
which would severely reduce the ifs
<adrianschmutzler>
two commands for AUTORELEASE, one for COMMITCOUNT
<adrianschmutzler>
if I'm not mistaken
<aparcar[m]>
what is ifs?
<adrianschmutzler>
conditions
<aparcar[m]>
oh no abbreviation ;}
<adrianschmutzler>
let me just put something together, mom
<aparcar[m]>
ideally I want it fully automated, but for a smoother transition I don't want to change release numbers for 6000 packages
<adrianschmutzler>
both variants will be fully automatic, the question is whether the user has a choice or not
<adrianschmutzler>
user=the person defining the variable in the package
<adrianschmutzler>
Should the tarball builder get his own versioning scheme ...?
Acinonyx has joined #openwrt-devel
danitool has joined #openwrt-devel
<aparcar[m]>
I think that's not really our concern as none of our infra does that
<aparcar[m]>
but it should still be possible to build
<aparcar[m]>
as it uses SOURCE_DATE_EPOCH it's at least reproducible and can therefor be pointed back to a specific release
<adrianschmutzler>
how will that matter in the context of a tarball builder?
<aparcar[m]>
opkg list-installed on a running device maybe
goliath has joined #openwrt-devel
<adrianschmutzler>
but then I must say I would make it fully automatic and remove the argument
aliceussr has joined #openwrt-devel
<aparcar[m]>
people building outside a git repo likely build a static image they use internally and don't maintain a public package repository.
<adrianschmutzler>
I.e. having only one variable
<aliceussr>
Hello! Who haver latest drivers for MediaTek RT5390 for full speed WiFi?
<aparcar[m]>
sure we could do that as well as the only case where commitcount seems usable is base-files
<adrianschmutzler>
would be interesting how expensive the git log --grep is
<adrianschmutzler>
because with the current more specific scheme, we circumvent that
<aparcar[m]>
that's true. I'll give it a quick try
<adrianschmutzler>
just checked in /target, gives me about 1.5 s for each of the git commands
krm has joined #openwrt-devel
<aparcar[m]>
adrianschmutzler: ugh
<aparcar[m]>
i got 0.3 seconds
<adrianschmutzler>
well, target is not really the smallest to test
<adrianschmutzler>
that why I chose it ...
<adrianschmutzler>
anyway, did you copy this 1:1 from luci?
<aparcar[m]>
wait I'm talking about packages, how is target a package?
<adrianschmutzler>
i just threw the two git commands about a huge history
<adrianschmutzler>
so I have some waiting time which can be reasonably measured
<adrianschmutzler>
anyway, maybe we should just keep your version
<adrianschmutzler>
the tarball issue is valid, and though the "1" parameter is ugly, I didn't find a better idea in several minutes so let's just keep it
<krm>
I'm having a weird problem with dnsmasq returning incorrect results for SRV records. I'm building from the same source tree both archer c7 v2 and archer c7 v5. The v5 build works, the v2 build doesn't. dnsmasq related options are the same in the configs...
<krm>
also building for two ipq806x targets from the same source tree that also don't work
<aparcar[m]>
adrianschmutzler: so let's just give it a try?
<adrianschmutzler>
I have not validated the code in detail
<adrianschmutzler>
but I give up my objections from above
<adrianschmutzler>
And I still don't understand how the semicolons are put there ;-)
<aparcar[m]>
try & error
<aparcar[m]>
only `then` and `else` don't require a following semicolon
<adrianschmutzler>
but some fi do have one and others don't
<aparcar[m]>
oh sorry I got a corrected version in my local msater branch
<aparcar[m]>
problem is that git log --grep also checks the commit message. Now it requires a chain of git log --oneline | grep "update" | cut -f 1 -f " "
<aparcar[m]>
I thought maybe you have a better idea or know a git command
state has quit []
<adrianschmutzler>
I'm not sure whether text-parsing is the way out here ...
<adrianschmutzler>
Maybe we should just drop resetting on update and keep just commitcount
<jow>
afair there is no builtin way to only grep the commit subject
<aparcar[m]>
well the git | grep | cut chain shouldn't be too expensive?
<adrianschmutzler>
but it's even more ugly, and we have to either "print" the full history first or grep twice
<adrianschmutzler>
apart from the fact that I don't know how stable git output is supposed to be
<adrianschmutzler>
I'd say implement the commit count for now and then we can still expand it with the autorelease functionality later when we have a good idea about that
<adrianschmutzler>
and personally, I could even live with not resetting the commit count for a few packages
<adrianschmutzler>
uboot-envtools currently has 297 commits, 2020.04-297 would not be that terrible
<aparcar[m]>
adrianschmutzler: I'd assume it's very stable, specially as we can manually define the format to be "$commit_hash $subject". By using grep -m 1 it will close the stdin after a first match and thereby stops git from running. It doesn't print the full log
<adrianschmutzler>
interesting, for a long history the latter is actually faster
shibboleth has joined #openwrt-devel
<adrianschmutzler>
(obviously because only the title is parsed)
<aparcar[m]>
Hah!
<adrianschmutzler>
what I do is going into target/ and then trying to match something that isn't there
<adrianschmutzler>
e.g. time git log --pretty=format:'%h %s' | grep -m1 "xxxxxxxxxxxxxxxxxx"
<adrianschmutzler>
that's where I get these long times like 1-1.5 s
caravel has joined #openwrt-devel
<adrianschmutzler>
of course, when I match something reasonable, it's much faster
<aparcar[m]>
it will never run in target
<adrianschmutzler>
yes, but I need a long history
<aparcar[m]>
oh fair
<aparcar[m]>
just use hyperfine to get real values
<adrianschmutzler>
anyway, I think your latest suggestion is simple enough
blb4393 has quit [Quit: ChatZilla 0.9.93 [Waterfox 56.3/MOZ_BUILDID]]
<adrianschmutzler>
but since we touched so many parts now, I'd be happy if you resubmit the final version and have it on the list for a few days
<aparcar[m]>
ack
<adrianschmutzler>
and don't forget to add ":[Bb]ump to "
<aparcar[m]>
🙂 never
black_ant has quit [Ping timeout: 256 seconds]
<adrianschmutzler>
but still, discussing and testing thoroughly really helps. The message-matching, which is actually obvious if you think about it, was only revealed as a problem after we talked maybe an hour about the subject
<shibboleth>
yeah, so since you... wanted to generally improve these/update them, would you be open to such a suggestion?
<shibboleth>
add tx-fifo-depth 4096?
Net147 has joined #openwrt-devel
<adrianschmutzler>
I wanted to _have them improved_ ...
<adrianschmutzler>
;-)
<shibboleth>
this would allow for setting a higher mtu and possibly work around the jumboframe/random reboot issue?
<adrianschmutzler>
... like all devices in OpenWrt. It's not like I have a specific liaison with this particular device
<adrianschmutzler>
shibboleth: I don't have the slightest idea
<shibboleth>
no, sure. but if such a patch should be posted, you won't object on spec/purity?
<adrianschmutzler>
this sounds to me like a misunderstanding. how would I object towards a patch that fixes something
<adrianschmutzler>
If it's not proper, I'd maybe give pointer to how to make it right, of course
<shibboleth>
alright then. do we have to go through all the motions or could this be sorted without all the singing and dancing?
<shibboleth>
patch, review
<adrianschmutzler>
well, what else do you have in mind, apart from "patch, review"?
<shibboleth>
apparently jacecoski filed the bugreport, submitted patches, but pri:very low for some reason
<adrianschmutzler>
ah, so now we are coming closer
<aparcar[m]>
adrianschmutzler: did I ever sneaked around reviews?
<adrianschmutzler>
so you want special priority for a specific subject
<shibboleth>
oh, no
<shibboleth>
but is a new patch in order or could the old one be dusted off?
<adrianschmutzler>
well, where is it? patchwork or github?
<shibboleth>
i'm waiting for an answer from him on that, i'll let you know :). presumably the ML and timed out on patchwork
<adrianschmutzler>
well, in patchwork you have the advantage of being able to just respond to the original mail with a "Ping." or similar
<adrianschmutzler>
beyond that, the typical means to get forward are to ping people that are active on the target or typically working with stuff similar to the problem (networking/MTU/switch etc. here)
<adrianschmutzler>
if you don't know these people from experience with the project, you may check the git history, e.g. for the relevant target etc.
<adrianschmutzler>
who is active, and also what he does-
<adrianschmutzler>
e.g. I have a lot of activity on several targets, but on many of them commits are trivial/cosmetic
<shibboleth>
sure, reason i pinged you was the convo we had about dts/syntax
<adrianschmutzler>
which won't help you with this matter
<shibboleth>
i'll bring it up once i've gotten hold of him
<adrianschmutzler>
I might be able to help you with the syntax, yes, but I probably won't understand the underlying technical problem on this arch