LoopHoldYoaBrown has quit [Ping timeout: 240 seconds]
LoopHoldYoaBrown has joined #openwrt-devel
<Tapper>
Hi I tryed to update the forum about the 19.xx build, but It wont let me. It's stupid.
<Tapper>
A11y fail sorry.
LoopHoldYoaBrown has quit [Ping timeout: 246 seconds]
black_ant has quit [Ping timeout: 240 seconds]
<owrt-snap-builds>
build #869 of arc770/generic is complete: Failure [failed images] Build details are at http://buildbot.openwrt.org/master/images/builders/arc770%2Fgeneric/builds/869 blamelist: ?lvaro Fern?ndez Rojas <noltari@gmail.com>, Felix Fietkau <nbd@nbd.name>, Daniel Golle <daniel@makrotopia.org>, John Audia <graysky@archlinux.us>
<owrt-snap-builds>
build #889 of ipq806x/generic is complete: Failure [failed images] Build details are at http://buildbot.openwrt.org/master/images/builders/ipq806x%2Fgeneric/builds/889 blamelist: ?lvaro Fern?ndez Rojas <noltari@gmail.com>, Felix Fietkau <nbd@nbd.name>, Daniel Golle <daniel@makrotopia.org>, John Audia <graysky@archlinux.us>
LoopHoldYoaBrown has quit [Ping timeout: 264 seconds]
koniu has quit [Ping timeout: 268 seconds]
koniu has joined #openwrt-devel
LoopHoldYoaBrown has joined #openwrt-devel
LoopHoldYoaBrown has quit [Ping timeout: 260 seconds]
LoopHoldYoaBrown has joined #openwrt-devel
weijie0 has joined #openwrt-devel
weijie has quit [Ping timeout: 264 seconds]
weijie0 is now known as weijie
<mangix>
aparcar[m]: pong
<mangix>
docker stopped working. I have to track IRC elsewhere
<aparcar[m]>
mangix: do I have to do something about gettext or just wait until people report issues? I can't reproduce any issues
<lipnitsk>
aparcar[m]: do you want to try your CI test again - I just pushed a change to my branch to use "$GITHUB_WORKSPACE" instead of feeds
<aparcar[m]>
lipnitsk: ack
LoopHoldYoaBrown has quit [Ping timeout: 260 seconds]
hbug__ has joined #openwrt-devel
<owrt-snap-builds>
build #807 of tegra/generic is complete: Failure [failed images] Build details are at http://buildbot.openwrt.org/master/images/builders/tegra%2Fgeneric/builds/807 blamelist: ?lvaro Fern?ndez Rojas <noltari@gmail.com>, Felix Fietkau <nbd@nbd.name>, Daniel Golle <daniel@makrotopia.org>, John Audia <graysky@archlinux.us>
LoopHoldYoaBrown has joined #openwrt-devel
hbug_ has quit [Ping timeout: 268 seconds]
danitool has quit [Ping timeout: 256 seconds]
<aparcar[m]>
mangix: mangix: do I have to do something about gettext or just wait until people report issues? I can't reproduce any issues
<aparcar[m]>
lipnitsk: okay works now, thank you
<lipnitsk>
aparcar[m]: for some reason, refresh failed it seems, since it didn't display the error message
<lipnitsk>
i would have liked to see refresh succeed then git detect a problem (if $GITHUB_WORKSPACE is not a repository this method will not work)
<mangix>
git grep FIXUP | grep gett in the packages feed to see more
<owrt-snap-builds>
build #761 of malta/be is complete: Failure [failed pkgbuild] Build details are at http://buildbot.openwrt.org/master/images/builders/malta%2Fbe/builds/761 blamelist: ?lvaro Fern?ndez Rojas <noltari@gmail.com>, Felix Fietkau <nbd@nbd.name>, Daniel Golle <daniel@makrotopia.org>, John Audia <graysky@archlinux.us>
LoopHoldYoaBrown has quit [Ping timeout: 246 seconds]
LoopHoldYoaBrown has joined #openwrt-devel
goliath has quit [Quit: SIGSEGV]
zx2c4 has quit [Ping timeout: 264 seconds]
LoopHoldYoaBrown has quit [Ping timeout: 265 seconds]
zx2c4 has joined #openwrt-devel
<lipnitsk>
aparcar[m]: I think the fail is because of -e bash option in entrypoint.sh:
<lipnitsk>
-e Exit immediately if a command exits with a non-zero status.
<lipnitsk>
so when the git check fails it exits right away without going inside the if $?
<lipnitsk>
so really the "|| exit $?" clauses in the script are also redundant
<lipnitsk>
i should use the if ! make mytarget; form though
<mangix>
haha it even mentions what you said in your PR
<mangix>
Scripts that run or are called with set -e aka errexit will exit immediately if the command fails, even though they're followed by a clause that handles failure.
<lipnitsk>
yeah too bad google didn't lead me straight to that page...
<mangix>
third result on duckduckgo
<lipnitsk>
query?
<mangix>
SC2181
<lipnitsk>
maybe I just suck at searching
<lipnitsk>
well yeah, I didn't just know to search for SC2181 :)
<lipnitsk>
I'll just have to get in a habit of running shellcheck
<mangix>
notice how there's a disable directive in that file :)
<mangix>
there used to be a shellcheck thing for the CI, but it was removed because of it being too noisy
LoopHoldYoaBrown has quit [Ping timeout: 260 seconds]
<lipnitsk>
I see.. Yeah that's the issue with static analysis - false positives. But still I should use it more often, if only manually
LoopHoldYoaBrown has joined #openwrt-devel
<mangix>
basically, the issue is that busybox ash has capabilities in between debian ash and bash. The solution IIRC would be to check against ash and selectively disable warnings
<mangix>
the last part is a problem, except in shellcheck master
LoopHoldYoaBrown has quit [Ping timeout: 272 seconds]
llewellyn has quit [Ping timeout: 240 seconds]
LoopHoldYoaBrown has joined #openwrt-devel
<owrt-snap-builds>
build #652 of layerscape/armv7 is complete: Failure [failed images] Build details are at http://buildbot.openwrt.org/master/images/builders/layerscape%2Farmv7/builds/652 blamelist: ?lvaro Fern?ndez Rojas <noltari@gmail.com>, Felix Fietkau <nbd@nbd.name>, Daniel Golle <daniel@makrotopia.org>, John Audia <graysky@archlinux.us>
<Borromini>
ar71xx mach file has 1 and 0, i suppose eeprom matches what's defined as art
<PaulFertser>
Borromini: no, the number in DTS should be offset (number of bytes) from the start of partition
<PaulFertser>
Borromini: I suggest you take a look at hexdump -C of the art partition to see those MACs.
<Borromini>
PaulFertser: ah ok (i don't have that device myself)
<PaulFertser>
Borromini: probably you just need 6 instead of 1 there. Worth checking hexdump.
<Borromini>
PaulFertser: will ask the owner if he can get me a dump
<Borromini>
thanks for the advice
adrianschmutzler has joined #openwrt-devel
<Hauke>
rsalvaterra: pong
Tsesarevich has quit []
Tsesarevich has joined #openwrt-devel
<rsalvaterra>
Hauke: I'm taking a stab at porting 5.10 to mvebu, will also backport the buffer management patch, while it doesn't hit linux-stable.
<rsalvaterra>
I don't have arm64 hardware to test, though, only my Omnia.
<Borromini>
Hauke: my R6800 needs a driver that got added to the mt7621 kernel config when device support got committed, but got lost with the move to 5.4 it seems
<Borromini>
ipk is 60k. can i re-enable that driver in the kernel config for mt7621 or do i need to make a separate package and have the device profile depend on that?
<Hauke>
rsalvaterra: I have a mvebu a53 board here
<Hauke>
rsalvaterra: I was just asking about the stability becasue I think hw buffer managers are compliacted
<Hauke>
at least I have experience with it from a different SoC
LoopHoldYoaBrown has quit [Ping timeout: 246 seconds]
<Borromini>
(last file changed, config-4.14)
<Hauke>
Borromini: what driver is missing?
<Borromini>
Hauke: CONFIG_PINCTRL_SX150X is the symbol
<Hauke>
Borromini: if you do not need that driver to boot up, I would prefer to have it as a ipkg
<Borromini>
generic kconfig has it unset, kirkwood has it enabled e.g.
<Borromini>
Hauke: ok, thanks
<rsalvaterra>
Hauke: Sure, but it's rock-solid here. Like I said, they've been working since forever on other Armada 38x/XP devices, only the Omnia got snubbed due to the device tree bug. :)
<Hauke>
we have many mt7621 devices with small memory
<Hauke>
Borromini: and if it is only needed on one of them an ipkg would be better
hrw has left #openwrt-devel [#openwrt-devel]
<Hauke>
rsalvaterra: ok then I am fine with adding it also to 21.02
<Borromini>
Hauke: yeah, understand.
<rsalvaterra>
Hauke: Just to make sure, I'm not stepping on nitroshift's toes, he told me he doesn't have a lot of time to make the the changes adrianschmutzler asked, so I'm taking the liberty to try and do them myself (also as a learning exercise).
<PaulFertser>
adrianschmutzler: hi :) can I ask you about okli loader and initramfs images? I have an impression this combination is broken, unbootable images are produced.
<adrianschmutzler>
PaulFertser: you may ask, but I probably won't be able to answer anything helpful ;-)
<ynezz>
Hauke: when do you plan to commit rt3200? :P
<ynezz>
I just got the package from amazon
<Hauke>
ynezz: I haven#t booted it yet, plan to have a look at it at the weekend
<Hauke>
I have some other mt7622 device here for over a year, that should also be added
<ynezz>
:)
<ynezz>
I just probably wont have time to tackle it myself in next 2-3 weeks, but would like to include it into testbed
<PaulFertser>
adrianschmutzler: okli loader's idea is that it's a small ELF and then it finds the kernel somewhere on its own, do I get it right?
<Hauke>
rsalvaterra: I will have a look at this in the next days
<PaulFertser>
adrianschmutzler: when using initramfs images okli loader is loaded to the desired location but the kernel itself stays where it was loaded, so I can't see how it can work.
LoopHoldYoaBrown has joined #openwrt-devel
<rsalvaterra>
Hauke: Wait, mvebu?
linzst has joined #openwrt-devel
linzst has quit [Max SendQ exceeded]
linzst has joined #openwrt-devel
linzst has quit [Remote host closed the connection]
<rsalvaterra>
Hauke: I'm now going through the patches, deleting the already upstreamed ones.
<blocktrron>
PaulFertser: okli is not intended to be used with the initramfs images
<PaulFertser>
blocktrron: but currently they end up like that afaict.
<PaulFertser>
blocktrron: so either the generation should be disabled or fixed
<blocktrron>
Do they?
<blocktrron>
The Siemens WS-AP3610 for example utilizes okli only for the regular kernel
<blocktrron>
When you simply reuse the kernel build-receipt and not provide a seperate one for the initramfs, they might
<PaulFertser>
I think a generic clean-up where all okli image generation is inspected and initramfs handled specifically might be worth a shot. It's just that I do not have a single device for testing.
<adrianschmutzler>
one could only enable it per target, so issues like this don't happen
<adrianschmutzler>
one could make the packages it uses configurable, so we don't have to stuff everything into DEFAULT_PACKAGES ...
<ynezz>
so we would have different content in different images?
<adrianschmutzler>
regarding okli, the problem is that there are not so many people really understanding it
<adrianschmutzler>
ynezz: ideally, so we do not have to stuff all packages from individual devices into default packages
<adrianschmutzler>
that's only a stupid idea without having looked to much, though
<ynezz>
so why it's being now done for squashfs images?
<ynezz>
why are you trying to treat it differently?
<adrianschmutzler>
I want to treat it like squashfs images
<adrianschmutzler>
so, every device only gets the packages it needs
<blocktrron>
initramfs images and their cpio are built by the kernel
<ynezz>
I know
<blocktrron>
so you have to go through that process for each device
<ynezz>
I just don't get it, that we now have initramfs images which are working differently then other images
<blocktrron>
alternatively you could hack something to append a device-specific ramdisk. Or simply provide the ramdisk to the kernel using FIT / bootm parameters.
<ynezz>
not every bootloader supports fit
<blocktrron>
i'm aware of that
<adrianschmutzler>
so, either we drop device-specific packages, or we do a lot of additional build steps for each device?
<adrianschmutzler>
(if we want to have squashfs and initramfs the same)
<adrianschmutzler>
great
<ynezz>
this is no go for backports
<ynezz>
we might come with something better for next release, but it would be nice to have something for 21.02 and 19.07
<ynezz>
at least for devices/targets where people care and actually use/test the initramfs images
daregap has quit [Quit: daregap]
LoopHoldYoaBrown has quit [Ping timeout: 240 seconds]
<adrianschmutzler>
the alternative would be to have two categories for device packages:
<adrianschmutzler>
ynezz: though I don't really see why we need wifi packages in initramfs
<PaulFertser>
Borromini: so 0x1000 and 0x1006 looks correct
<Borromini>
0-1-2-3-4-5 are mac 1 so offset 6 like you said for mac 2 probably?
<Borromini>
ok
<Borromini>
thanks
<ynezz>
adrianschmutzler: why you need them in squashfs? for wifi?
LoopHoldYoaBrown has joined #openwrt-devel
<adrianschmutzler>
yes, but isn't the initramfs just an intermediate step until I get the "proper" image?
<adrianschmutzler>
so no need to set up wifi there?
<ynezz>
that's your understanding
<ynezz>
maybe it should be renamed to initramfs-install-only
<adrianschmutzler>
if not, why do you pick only wifi packages here and not all the others?
<ynezz>
for example?
<stintel>
who can point me to the flashing instructions for realtek devices?
<ynezz>
stintel: usually commit message for that device
<adrianschmutzler>
so you really aim at eventually have all packages in initramfs?
<ynezz>
adrianschmutzler: just want to have similar functionality as provided by the squashfs image
<stintel>
ynezz: indeed, I just found it, sorry for being lazy =)
<stintel>
funny how everybody hates realtek but now we all want it because we can run OpenWrt on a switch :D
<adrianschmutzler>
cause we have size constraints on many initramfs images already, and making them much larger won't really be a help here
<adrianschmutzler>
(don't know whether that applies to mvebu/cortexa9 in particular, though)
<rsalvaterra>
stintel: Running OpenWrt on a switch qualifies as "awesome" in my book. :P
<stintel>
aye
<stintel>
I had a go at the Unifi Switch 8 at some point
<stintel>
but I think I broke the device by shorting one of the TTL pins with the chassis
* rsalvaterra
still hasn't given up on his TL-SG2008 v1.0…
<ynezz>
adrianschmutzler: yeah, then there is luci...
<Borromini>
stintel: an unintended irony on their part I think :P
<stintel>
also at some point I think I read that some cisco switches are mvebu based
<ynezz>
adrianschmutzler: anyway, I won't be touching those corner cases where you actually need smallest initramfs image in order to flash openwrt
<stintel>
SG250-08-K9-EU IIRC
<stintel>
but I bought way too much hardware recently that I still have to get working with OpenWrt
<stintel>
+ commit upstream :P
<rsalvaterra>
stintel: But Cisco stuff is usually filled up with custom undocumented accelerator ASICs, no?
<stintel>
I have an Odroid C2 running OpenWrt for years but never got to finishing that target properly :(
<ynezz>
adrianschmutzler: maybe I'll just as well leave that initramfs hell and simply lower the number of tests from daily to weekly and use squashfs images and flash them
<stintel>
and now I have a TP-Link OC200 that is a bitch because it requires TTL header + level shifter + 4 bridges to be soldered on the PCB to get serial, the SPI NOR chip is 1.8v, this is how I killed my first OC200 by reading it with a 3.3v programmer :P
<stintel>
(it requires either serial or overwriting the RSA pubkey in the SPI NOR flash to be able to flash OpenWrt)
<ynezz>
adrianschmutzler: I wanted to use imagebuilder first to build proper initramfs images (don't know if that's even possible), but then rejected the idea as it won't be pristine image from downloads.openwrt.org
<adrianschmutzler>
well, with the current constraints I must say that having initramfs-install-only as you said seems the least-painful to me
<stintel>
and then there's the WatchGuard Firebox M200 and M300 that I managed to boot after hacking asm vector instructions out of musl, but unable to get the network interfaces to work :(
<stintel>
and the Huawei AP7060DN
<adrianschmutzler>
if it is any help, I'm really unsatisfied with the current situation as well
<stintel>
for now I'm done buying unsupported hardware and trying to get it to work :P
<stintel>
I'm clearly too dumb for this
<ynezz>
have you asked for SDK/sources? this might help a lot
shibboleth has joined #openwrt-devel
<ynezz>
without this info it's quite tedious task I would say
<Borromini>
PaulFertser: is there a way to say if that ART dump contains caldata and where it starts? I'm looking at other AR9132 DTSes and they all refer to caldata in the ART partition at 0x1000
shibboleth has quit [Remote host closed the connection]
shibboleth has joined #openwrt-devel
ericzolf has quit [Remote host closed the connection]
<PaulFertser>
Borromini: I'd try giving the same art offset as the other similar devices do
LoopHoldYoaBrown has quit [Ping timeout: 256 seconds]
Darkmatter66_ has quit [Read error: Connection reset by peer]
<PaulFertser>
Borromini: I'd just give it a try booting with caldata supposed to be at 0x1000 from art start
<Borromini>
PaulFertser: okay, thank you
Darkmatter66 has joined #openwrt-devel
LoopHoldYoaBrown has joined #openwrt-devel
<PaulFertser>
Borromini: from wnr2000.c machine file in ar71xx: u8 *eeprom = (u8 *) KSEG1ADDR(0x1fff1000); It means the last sector of flash, 0x1000 offset.
LoopHoldYoaBrown has quit [Ping timeout: 256 seconds]
fblaese has quit [Ping timeout: 258 seconds]
pavlix has quit [Ping timeout: 240 seconds]
<stintel>
oh, I need serial to flash the GS108Tv3
LoopHoldYoaBrown has joined #openwrt-devel
fblaese has joined #openwrt-devel
<rsalvaterra>
I lost the count of the number of times I've been staring at a make failure, only to realise I wrote "make donwload"…
shalzz has quit [Ping timeout: 240 seconds]
shalzz has joined #openwrt-devel
<rsalvaterra>
adrianschmutzler: Building an image with 5.10 for my Omnia, hopefully I haven't screwed up anything (my patch refresh ended up a bit different from nitroshift's).
<svanheule>
stintel: you shouldn't need serial to flash that switch
<svanheule>
stintel: from OEM GUI you need to flash the initramfs, then re-flash a sysupgrade from OpenWrt
<stintel>
svanheule: but OEM GUI requires a cloud account
<stintel>
ain't going to happen
<svanheule>
you can disable that, by preventing the switch from pinging 8.8.8.8
<stintel>
aha
<svanheule>
if the switch thinks it doesn't have internet, you can log in with the local account :-)
<adrianschmutzler>
rsalvaterra: and that's why separate patches help a lot, because then you can actually see the different refresh directly
<stintel>
svanheule: good to know, tyvm
<svanheule>
stintel: yw
* Borromini
makes mental note as well
<Borromini>
too bad it's not in the commit message :P
<stintel>
but the thing is opened up already anyway and the soldering iron is hot :P
hsp has quit [Ping timeout: 246 seconds]
<stintel>
and good to have masks at hand these days, those fumes are nasty :P
<stintel>
my air purifier and pm sensors go mad whenever I'm soldering
<svanheule>
:P
<rsalvaterra>
adrianschmutzler: I basically followed your process for bcm63xx. :)
<rsalvaterra>
Kernel config -> patch copy -> patch refresh -> patch backport (just a single one) -> kernel testing version. This is basically the patch series.
pavlix has joined #openwrt-devel
<stintel>
I'll remember that 8.8.8.8 trick for my next one :P
<stintel>
I should actually just have ordered 2 at once
<stintel>
so I don't need to yolo sysupgrade on production switch :P
<Borromini>
:P :P
LoopHoldYoaBrown has quit [Ping timeout: 256 seconds]
<stintel>
hmmm maybe I should build an image first :P
hsp has joined #openwrt-devel
<noltari>
ynezz: ping
<noltari>
ynezz: stintel and I are looking into some issues with bcm2708 and urngd, and we could definitely use some help...
<rsalvaterra>
mangix: ping
<noltari>
we don't know why, but it takes a very long time for bcm2708 (bcm2835) devices to get to "random: crng init done", which doesn't make any sense, since there's a hw random generator
<russell-->
stintel: i just fired up a gs108t-v3 after seeing the recent support commits
<grift>
i was waiting for it on the ml
<aparcar[m]>
grift: btw I tried selinux the other day and this looked problematic: [ 30.014461] audit: type=1400 audit(1613448535.993:5): avc: denied { search } for pid=3137 comm="sh" name="libubox" dev="overlay" ino=1552 scontext=u:r:ntpdhotplug.subj tcontext=u:r:libubox.datafile tclass=dir permissive=0
LoopHoldYoaBrown has quit [Read error: Connection reset by peer]
<grift>
ill just add what i think is going on but yes this is why i suggested setting the default mode to permissive for now
<grift>
beause not everyone is confident with selinux and if the default mode is enforcing then i kind of feel bad to ask "can you reproduce the event in permissive mode?"
<grift>
anyhow thanks
<grift>
was that all though?
<stintel>
hmmm realtek is pretty verbose on console
<rsalvaterra>
And I'm still being shafted by that damn GPIO IRQ storm on 5.10…! FFS…
dedeckeh has joined #openwrt-devel
<grift>
aparcar[m]: for next time, a way to reproduce something like this is probably: `setenforce 0 && service network restart && setenforce 1 && dmesg | grep -i denied | nc termbin.com 9999`
LoopHoldYoaBrown has quit [Ping timeout: 240 seconds]
LoopHoldYoaBrown has joined #openwrt-devel
<Borromini>
guys i have added a kernel module package, it's showing in openwrt's menuconfig but the package is empty... Do i need to do anything extra (sometimes touching Makefiles helps) before it works?
<Borromini>
it's basically replicating other entries and paths are correct
danitool has joined #openwrt-devel
<stintel>
Borromini: rm -rf tmp/
<Borromini>
stintel: ok thanks
<Borromini>
what's the correct way to call a kmod build?
<Borromini>
make package/mt76 e.g. works for mt76 but make/gpio-sx150x doesn't
<stintel>
good question, can't answer that
<Borromini>
ok
<Borromini>
not on the wiki page either (which is pretty complete)
<plntyk>
package/kernel/<> i think
<ynezz>
philipp64: 2021-02-19T08:19:37.4123107Z /home/build/openwrt/staging_dir/toolchain-x86_64_gcc-8.4.0_musl/bin/../lib/gcc/x86_64-openwrt-linux-musl/8.4.0/../../../../x86_64-openwrt-linux-musl/bin/ld: /home/build/openwrt/staging_dir/target-x86_64_musl/usr/lib/libgmp.a(bdiv_q_1.o): relocation R_X86_64_PC32 against symbol `__gmp_binvert_limb_table' can not be used when making a shared object; recompile
<Borromini>
plntyk: i'll give that another shot but didn't seem to work
<Borromini>
ah looks like that thing can't be compiled as a module.
<Borromini>
either y or N
<Borromini>
that explains it since per_device_rootfs sets it to m
gromero_ has joined #openwrt-devel
7JTAB7RM4 has quit [Quit: Disconnecting from stoned server.]
gromero has quit [Ping timeout: 272 seconds]
<olmari>
grift: it was me, couldn't resist temptation to see it ,while I know I prolly couldn't do anything, and it's friday evening... alt-f4 obviously made it go away, with the makeshift matrix-IM fullscreen browser I'm using this chat xD
<grift>
no problem
<grift>
dont let me intimidate you
<grift>
just do your thing
<olmari>
I was going to sleep, that is the mindset currently xD
<grift>
but remember if you kill the last pane then i would need to restart theservice
<olmari>
heh.. well... make it PW-less ssh:able or something? I mean obviously this is all fun and games offered, so any system is a system, but yeah... if it is up tomorrow I just might be urged to look with better eyes.. or generally have any thought on doings :D
<grift>
it will be up but no ssh access
<grift>
atleast unless someone takes it down at night
<grift>
which i encourage anyone to try
LoopHoldYoaBrown has quit [Ping timeout: 256 seconds]
<grift>
but yes ttyd and websockets has its limits
<grift>
thats one idea though. see if you can somehow compromise ttyd/ websockets who know
<grift>
there might be a pot of gold at the end of the rainbox
gromero_ has quit [*.net *.split]
swex_ has quit [*.net *.split]
owrt-2102-builds has quit [*.net *.split]
matteo has quit [*.net *.split]
nyt has quit [*.net *.split]
user| has quit [*.net *.split]
dxld has quit [*.net *.split]
Swant has quit [*.net *.split]
lechner has quit [*.net *.split]
paracyst_ has quit [*.net *.split]
Katana_Steel has quit [*.net *.split]
Slimey has quit [*.net *.split]
fs2 has quit [*.net *.split]
junland has quit [*.net *.split]
arnd has quit [*.net *.split]
lemoer has quit [*.net *.split]
skolev_ has quit [*.net *.split]
reiffert has quit [*.net *.split]
whitewolf has quit [*.net *.split]
Ultrasauce has quit [*.net *.split]
samueldr has quit [*.net *.split]
{Nico} has quit [*.net *.split]
malwar3hun73r has quit [*.net *.split]
yuvadm has quit [*.net *.split]
<olmari>
I was not suprised ifdown did not do anything (tho how does you run it legimately then?), I was suprised that noting but alt-f4 didn't get me out from damned browser full screen, nor to other tabs etc :D
<grift>
it just depends on how its entered
<grift>
but from "your path" it doesnt work
<olmari>
F11 :D
<grift>
but yes thats good question
<olmari>
oh.. the command... mm
<grift>
well you see everything has paths
<olmari>
but yeah... to the sleep taht I was going into :D
<grift>
something entering some command from some path migjt not work , while something entering a command from another path might work
<grift>
selinux is super flexibile
nslu2-log_ has joined #openwrt-devel
lechner has joined #openwrt-devel
swex_ has joined #openwrt-devel
matteo has joined #openwrt-devel
gromero_ has joined #openwrt-devel
fs2 has joined #openwrt-devel
dxld has joined #openwrt-devel
junland has joined #openwrt-devel
Slimey has joined #openwrt-devel
Katana_Steel has joined #openwrt-devel
paracyst_ has joined #openwrt-devel
owrt-2102-builds has joined #openwrt-devel
skolev_ has joined #openwrt-devel
nyt has joined #openwrt-devel
user| has joined #openwrt-devel
Swant has joined #openwrt-devel
lemoer has joined #openwrt-devel
arnd has joined #openwrt-devel
reiffert has joined #openwrt-devel
{Nico} has joined #openwrt-devel
Ultrasauce has joined #openwrt-devel
whitewolf has joined #openwrt-devel
samueldr has joined #openwrt-devel
yuvadm has joined #openwrt-devel
malwar3hun73r has joined #openwrt-devel
LoopHoldYoaBrown has joined #openwrt-devel
<grift>
you can define paths per process
samueldr has quit [Max SendQ exceeded]
fs2 has quit [Max SendQ exceeded]
<grift>
so you can just control every single bit
<svanheule>
Borromini: sx150x is an i2c device, I wonder why it's not buildable as a module...
<grift>
the ultimate power/control
<Borromini>
svanheule: yeah the kernel menuconfig throws me N/y instead of N/m/y
<svanheule>
Borromini: upstream has is as 'boolean', not 'tristate' :-/
<svanheule>
s/is/it
<Borromini>
you think they were just silly?
fs2 has joined #openwrt-devel
<Borromini>
like i said kernel_menuconfig just shows N/y :)
<grift>
its hard to image selinux because people think in terms of traditional access control
<Borromini>
svanheule: set it to y now but it still won't build though
<Borromini>
would you mind trying on your box?
<grift>
ie if they see "root" then the make all kinds of assumptions
<Borromini>
wait i didn't share the patches did i
<grift>
but one "root" can be totally different from another "root"
<svanheule>
Borromini: AFAIK, 'y' means 'include in kernel'
<Borromini>
it does yes
<Borromini>
m means module
<svanheule>
ok
<Borromini>
tristate is N/m/y like you said
<olmari>
grift: yeah, I know the general gist :)
<grift>
olamri i really appreciate you questioning all this
<grift>
but believe me , the router if controblable as usual by me
<grift>
so this isnt intrusive to me at all
<grift>
i can do whatever i like
<grift>
its just that you can;t
<grift>
because thats what i configured
samueldr has joined #openwrt-devel
<grift>
and anyone with selinux ccan do it
<grift>
anyone i appreciate all input
<grift>
because if i can learn from it then i can share this knowledge and make it better for all
<grift>
so i really want some of the kernel hackers to take a shot
<grift>
because i am not a super smart guy
<grift>
theres always someone smarter
<grift>
and ill be looking and learning
<grift>
thing is that i may not be the sharpest knife on the kitchen table. i am one persistent mofo
<grift>
like a pit bull . once i bite there is no letting go
<philipp64>
Borromini: seems to be 3 different IPv4 addresses for git, forum, and wiki.openwrt.org
LoopHoldYoaBrown has quit [Ping timeout: 246 seconds]
<Borromini>
ok
<philipp64>
I'm a little surprised that x86_64 seems to be the red-headed stepchild, given that x86_64 is the easiest to find cloud test resources for...
<owrt-snap-builds>
Seo Suchan <abnoeh@mail.com>, Sander Vanheule <sander@svanheule.net>, Stijn Segers <foss@volatilesystems.org>, Yangbo Lu <yangbo.lu@nxp.com>
<owrt-snap-builds>
build #794 of layerscape/armv8_64b is complete: Failure [failed images] Build details are at http://buildbot.openwrt.org/master/images/builders/layerscape%2Farmv8_64b/builds/794 blamelist: ?lvaro Fern?ndez Rojas <noltari@gmail.com>, Daniel Golle <daniel@makrotopia.org>, Sungbo Eo <mans0n@gorani.run>, Adrian Schmutzler <freifunk@adrianschmutzler.de>,
<philipp64>
i.e. it should be triivial to spin an x86_64 VM up for testing...
mangix has joined #openwrt-devel
LoopHoldYoaBrown has joined #openwrt-devel
<Borromini>
ah i'm in the blamelist <3
<Borromini>
totally unjustified of course
shibboleth has quit [Quit: shibboleth]
LoopHoldYoaBrown has quit [Ping timeout: 272 seconds]
<Grommish>
Is setting up a QEMU mips environment to build Openwrt on (not for) feasible or just a PITA?
<philipp64>
I just rebased and did a "make", and got prompted for some new kernel symbols, like CONFIG_KEXEC... what's process for figuring out what's in SCM versus what the total required pre-defined symbols should be?
<philipp64>
Grommish: what's wrong with cross-building like evertying else?
<Grommish>
Because I can't get the LLVM for x86_64 to work for mips64 and I'm trying to build native mips64 bins
<Grommish>
So I will us ethe Alpine MIPS64 LLVM, but it's precompiled'
LoopHoldYoaBrown has quit [Ping timeout: 265 seconds]
<Grommish>
So i need a mips64 build environment afaik
<philipp64>
and you can't use gcc?
<Grommish>
I'm working to build a rust-lang toolchain so that rustc/cargo are created for mips64, not x86_64 able to cross to mips64
<Grommish>
Rust uses the LLVM, which doesn't support mips64 that I can find. Alpine's does with LLVM10, but since they are already built, they are in mips64 arch already
<Grommish>
my build system x86_64 throws a fit about it
<Grommish>
When trying to cross compile rust using a precompiled mips64 llvm
<mangix>
Grommish: apk is available with openwrt. maybe install the alpine package
* mangix
hides
<Grommish>
rust works fine when I do it properly host builds
<Grommish>
Ooo
<Grommish>
But
<Grommish>
I need hte oPenWrt buid system to make the toolchain
<Grommish>
I built everything around OpenWrt making rust
<Grommish>
I am far to involved in this for something I know nothing about.. I just wanted Suricata6 on my device ;p
<grift>
try snort(3)?
LoopHoldYoaBrown has joined #openwrt-devel
<Grommish>
I have, but I wanted options
<grift>
but yes non-solution
<Borromini>
into the abyss eh Grommish ? :P
<Grommish>
So, I got rust-lang working ;p
<Grommish>
Which seems a good thing because security packages are moving to rust anyway
<Borromini>
:)
<grift>
are they?
<Grommish>
I don't program and I certainly don't know rust.. So things like llvms are.. intereting to run into