**** BEGIN LOGGING AT Tue Jun 23 03:03:14 2020
Jun 23 07:19:59 <luilver> I have a TM-05 successfully running GL-MT300n firmware on it (OpenWRT 15.05). Is there any way to run wireguard on it? I'm able to hack on it !
Jun 23 07:20:12 <luilver> I have a TM-05 successfully running GL-MT300n firmware on it (OpenWRT 15.05). Is there any way to run wireguard on it? I'm able to hack it !
Jun 23 07:23:38 <Borromini> luilver: one way would be to really port it to openwrt :)
Jun 23 07:23:54 <Borromini> if the gl-mt300n image runs that means you have most of the work done already, kinda.
Jun 23 07:25:47 <luilver> Borromini: I would be glad to port it ! Is there any direction to accomplish it ?
Jun 23 07:26:01 <Borromini> luilver: newer OpenWrt uses devicetree
Jun 23 07:26:15 <Borromini> you can look at the gl-mt300n to start
Jun 23 07:26:33 <luilver> Borromini: great !
Jun 23 07:26:35 <Borromini> if the devices are really identical it will be mostly cosmetical
Jun 23 07:27:58 <Borromini> luilver: see https://openwrt.org/docs/guide-developer/adding_new_device
Jun 23 07:28:30 <luilver> Borromini: Alright !
Jun 23 07:28:34 <Borromini> https://openwrt.org/docs/guide-developer/add.new.device < this might serve you as well if you'd like to double check things
Jun 23 07:29:09 <Borromini> on your present install check what's in /tmp/sysinfo/board_name
Jun 23 07:29:18 <Borromini> and in /tmp/sysinfo/model
Jun 23 07:29:26 <Borromini> you'll need the latter for your dts i think
Jun 23 07:29:30 <Borromini> erm the former
Jun 23 07:29:37 <Borromini> and the latter for your human readable device name
Jun 23 07:30:58 <Borromini> https://git.openwrt.org/?p=openwrt/openwrt.git;a=blob;f=target/linux/ramips/dts/mt7620a_glinet_gl-mt300n.dts < that's the dts of the device image you're an old image of atm
Jun 23 07:31:43 <luilver> Borromini: I'm  on it !
Jun 23 07:32:56 <Borromini> :)
Jun 23 07:33:05 <luilver> Thanks
Jun 23 07:33:24 <Borromini> yw. shouldn't be too difficult if you have some coding experience i think.
Jun 23 07:33:39 <luilver> # cat  /tmp/sysinfo/board_name
Jun 23 07:33:45 <luilver> gl-mt300n
Jun 23 07:34:00 <Borromini> to have your work included once it's done see: https://openwrt.org/submitting-patches
Jun 23 07:34:20 <Borromini> luilver: yeah... that's the hack messing up things
Jun 23 07:34:29 <luilver> # cat  /tmp/sysinfo/modelGL-MT300N
Jun 23 07:36:17 <Borromini> luilver: model value is probably "HooToo HT-TM05" (without the quotes)
Jun 23 07:36:30 <Borromini> but this is just extrapolated for the HT-TM02 which is supported
Jun 23 07:37:03 <Borromini> board_name would then be "hootoo,ht-tm05"
Jun 23 07:37:10 <Borromini> again - this is just an eduated guess.
Jun 23 07:37:19 <Borromini> you might have to play around with that
Jun 23 07:38:15 <Borromini> board_name value is what would be the first value in the compatible line in your dts
Jun 23 07:38:23 <Borromini> and model, well... model :P
Jun 23 07:38:28 <luilver> Borromini: nice to know about it .. and yes, I have a sort of coding experience ... nothing like this, but there is always a first time ;-)
Jun 23 07:38:46 <Borromini> i hear you.
Jun 23 07:41:03 <Borromini> luilver: see https://paste.debian.net/1153436/
Jun 23 07:41:11 <Borromini> i switched the values already
Jun 23 07:41:18 <Borromini> but you'll have to double check the remainder :)
Jun 23 07:41:33 <Borromini> like the led labels, they need renaming too
Jun 23 07:42:04 <Borromini> lines 24, 29, 34
Jun 23 07:42:20 <Borromini> probably ht-tm05 instead of gl-mt300n
Jun 23 07:45:48 <Borromini> luilver: i can try for you if you can test the images and have recovery in place
Jun 23 07:45:58 <luilver> Borromini: is the same gl-mt300n:{wlan,lan}
Jun 23 07:46:04 <Borromini> ie if the flash goes wrong and it doesn't boot, you need to be able to recover
Jun 23 07:47:19 <luilver> Borromini: I have no idea how to recover if I brick it ...
Jun 23 07:48:12 <Borromini> well it has a TFTP client in the bootloader, it seems
Jun 23 07:48:14 <Borromini> so that's good
Jun 23 07:49:12 <Borromini> luilver: can you pastebin the output of 'cat /proc/mtd'
Jun 23 07:50:26 <Borromini> from what i can tell you used the TFTP functionality to get openwrt onto it in the first place
Jun 23 07:51:42 <luilver> https://paste.debian.net/1153440/
Jun 23 07:53:52 <luilver> Borromini: yes, that's the way I uploaded the firmware to it: TFTP
Jun 23 07:54:57 <Borromini> yeah that's your recovery :)
Jun 23 07:55:45 <blogic> I think i found the root cause of why wifi up/down is quirky
Jun 23 07:55:46 <luilver> So If anything goes wrong I would always go back to gl-mt300n
Jun 23 07:56:16 <Borromini> luilver: i'm looking at the partition layout but for my layman's eyes they look different between what you have and what the present dts has
Jun 23 07:57:20 <luilver> Borromini: what's the difference ?
Jun 23 07:59:49 <luilver> cat /proc/partitions ?
Jun 23 08:00:40 <Borromini> luilver: if you compare to what's in the dts you'll see yours has more partitions
Jun 23 08:01:23 <Borromini> luilver: let me try cobbling something together.
Jun 23 08:02:12 <luilver> Borromini: I see !
Jun 23 08:05:48 <luilver> Borromini: first 4 partitions are the same. Even last one is the same too. I just need to remove partitions mtd-{4..6}. Isn't it ?
Jun 23 08:07:29 <Borromini> luilver: i wouldn't remove them. at least kernel, rootfs and rootfs_data are used by openwrt. probably firmware as well.
Jun 23 08:08:04 <Borromini> do you have a backup device in case you cannot recover immediately?
Jun 23 08:08:05 <luilver> Ok
Jun 23 08:08:20 <luilver> @borr
Jun 23 08:08:31 <luilver> Borromini: Yes I do !
Jun 23 08:12:26 <Borromini> alright. i'll go tinker and get back to you
Jun 23 08:12:56 <luilver> Ok
Jun 23 08:14:20 <luilver> I plugged the device into USB for getting charged
Jun 23 08:14:33 <Borromini> :)
Jun 23 08:15:16 <luilver> It has an outstanding uptime of  08:10:19 up 2 days,  7:18,  load average: 0.00, 0.01, 0.04
Jun 23 08:15:40 <luilver> It has an amazing autonomy
Jun 23 08:17:53 <Borromini> nice
Jun 23 08:18:02 <Borromini> does it have a replaceable battery?
Jun 23 08:18:11 <luilver> nope
Jun 23 08:19:07 <luilver> but it uses 4 x AA rechargeable type ;-)
Jun 23 08:25:56 <Borromini> but you can't replace them despite being AA?
Jun 23 08:27:29 <luilver> Not by default. I have fully disassembled it !
Jun 23 08:33:42 <Borromini> lol
Jun 23 08:34:11 <Borromini> luilver: can you add your openwrt bootlog to the device page? https://openwrt.org/toh/hootoo/hootoo_ht-tm05
Jun 23 08:34:14 <Borromini> that would be helpful
Jun 23 08:34:28 <Borromini> also your openwrt flash layout
Jun 23 08:35:44 <luilver> How can I do so ? bootlog and flash layout ?
Jun 23 08:37:34 <Borromini> flash layout is cat /proc/mtd
Jun 23 08:37:41 <Borromini> just like on the OEM firmware
Jun 23 08:37:57 <Borromini> bootlog is if you have serial - you didn't did you?
Jun 23 08:38:43 <Borromini> you can paste dmesg as well in there (in the bootlog)
Jun 23 08:51:48 <nick[m]1> Something wrong with uci:get("freifunk", "community", "name")? was there some API change?
Jun 23 08:52:00 <nick[m]1> it says it returns me an boolean
Jun 23 08:52:04 <nick[m]1> and not a string
Jun 23 08:52:05 <luilver> done: layout + bootlog
Jun 23 08:53:03 <jow> nick[m]1: try replacing colon with dot
Jun 23 08:53:16 <jow> nick[m]1: uci.get("freifunk", "community", "name")
Jun 23 08:53:34 <jow> since you didn't provide any context, I am not sure if "uci" refers to the module table or a curser object
Jun 23 08:53:44 <jow> *cursor
Jun 23 08:54:18 <nick[m]1> jow:  local uci = require "luci.model.uci".cursor()
Jun 23 08:55:25 <jow> also a boolean false is returned if the call fails
Jun 23 08:55:38 <jow> a second value will contain the error message
Jun 23 08:55:54 <jow> local val, err = uci:get("...")  if val == false then print(error) endf
Jun 23 08:55:57 <jow> *end
Jun 23 08:56:08 <nick[m]1> ahhhh thank u!
Jun 23 08:57:37 <Borromini> luilver: thanks. can you tell me what leds are on your device?
Jun 23 08:57:57 <luilver> Sure
Jun 23 08:58:47 <nick[m]1> jow: is there something wrong with f = SimpleForm("ffwizward", "", "")? some api change? xD I try to debug all that freifunk stuff in berlin and get it compatible with openwrt master again
Jun 23 08:59:21 <jow> not sure, haven't tried that in a while
Jun 23 09:00:07 <luilver> Borromini: https://paste.debian.net/1153448/
Jun 23 09:01:27 <Borromini> luilver: thanks. i see you replaced the OEM layout with the openwrt one
Jun 23 09:01:29 <Borromini> can you revert that?
Jun 23 09:01:42 <Borromini> and add the openwrt one below the 'openwrt flash layout' line?
Jun 23 09:01:49 <luilver> Oh, my bad, let me check !
Jun 23 09:01:59 <Borromini> thanks
Jun 23 09:02:09 <Borromini> also, can you tell me the physical leds you can see on the device
Jun 23 09:02:20 <Borromini> not just the ones exposed in the firmware
Jun 23 09:04:15 <nick[m]1> jow: how do u develop? on router directly or using some vm? xD
Jun 23 09:04:26 <jow> sftp against vm or router
Jun 23 09:04:31 <jow> or sshfs rather
Jun 23 09:05:12 <luilver> Borromini: Reverted !
Jun 23 09:05:40 <Borromini> ty
Jun 23 09:05:50 <Borromini> can you list me the physical leds you see on the device?
Jun 23 09:06:12 <luilver> Borromini: It has only one physical led (turns blue or green)
Jun 23 09:07:38 <luilver> Mmm it has also 4 white leds indicating charge level ...
Jun 23 09:07:53 <russell--> Borromini: /proc/mtd is not the flash layout, just gives the partition sizes and erase sizes, not the offsets
Jun 23 09:08:11 <russell--> you can get the offsets from dmesg
Jun 23 09:08:55 <russell--> i use 'dmesg | grep 0x'
Jun 23 09:11:40 <luilver> partition offsets: https://paste.debian.net/1153450/
Jun 23 09:12:48 <Borromini> russell--: oh ok. thanks
Jun 23 09:13:46 <Borromini> luilver: so the blue/green led is status? or just on/off?
Jun 23 09:14:06 <luilver> Borromini: status
Jun 23 09:15:15 <Borromini> ok thanks
Jun 23 09:16:22 <Borromini> luilver: can you tell me how it changes? as in: when does it turn blue, and green
Jun 23 09:19:40 <luilver> After openWRT it has been always green. With default firmware it was always blue. It might blinked with wlan0 activity with default firmware I'm not sure (can't remember)
Jun 23 09:24:27 <luilver> Should I update  OEM flash Layout section with offsets ?
Jun 23 09:26:14 <luilver> Even  OEM CPU Info section differs from my side ...
Jun 23 09:44:17 <nick[m]1> jow: just one more question? ;) if I have return uci:get("freifunk", "community", "name") or "berlin" in a cfgvalue function of a listvalue, what should be the default? "berlin" is not working
Jun 23 09:56:59 <nick[m]1> Okay, that seems to work
Jun 23 09:57:05 <nick[m]1>   return uci:get("freifunk", "community", "name") or community:value("berlin", "Berlin")
Jun 23 10:10:18 <nick[m]1> Ah the actual problem is that I get a Permission denied? :S
Jun 23 10:11:39 <Borromini> luilver: when you're back, you can find a test image (including luci and wireguard) here: https://volatilesystems.org/dl/lede/targets/HT-TM05/
Jun 23 10:12:00 <Borromini> please test it with sysupgrade (use -n -F) and with TFTP as well (as per the instructions in the wiki)
Jun 23 10:27:45 <karlp> nick[m]1: you might need new acls if you're in your own application?
Jun 23 10:28:38 <nick[m]1> karlp: thanks! I saw a forum post and now I added some ubus permissions and it seems to work! (somtetimes... xD)
Jun 23 12:32:13 <mamarley> Oh, I'm somehow subscribed to the openwrt-devel mailing list again…
Jun 23 12:35:13 <stintel> mamarley: normal. hardware failure and old backup restored
Jun 23 12:35:22 <mamarley> Ah, OK.
Jun 23 12:35:29 <stintel> https://www.mail-archive.com/openwrt-devel@lists.openwrt.org/msg53332.html
Jun 23 12:39:37 <rsalvaterra> Ouch. So that's why I couldn't read the archive.
Jun 23 12:43:09 <Borromini> 2018? :-/
Jun 23 12:45:24 <dwmw2_gone> Wheee
Jun 23 12:45:37 * dwmw2_gone has U-Boot installing OpenWrt from the SD card to the internal eMMC of the Bpi R2
Jun 23 12:46:46 <dwmw2_gone> rsalvaterra: We'll restore the archive. I'm taking a day off sysadmin tasks today though.
Jun 23 12:46:50 <dwmw2_gone> And a day off not drinking
Jun 23 12:47:35 <mamarley> Will that mean I have to rereunsubscribe?
Jun 23 12:47:54 <dwmw2_gone> actually I may be lying about the admin tasks. My shiny new backup server just arrived, and needs building.
Jun 23 12:47:59 <dwmw2_gone> mamarley: yes, sorry.
Jun 23 12:48:26 <dwmw2_gone> I figured that getting the lists running again with the 2018 config (which is from last time they were hosted on merlin.infradead.org, before they moved to bombadil (rip)), was the best option.
Jun 23 12:48:33 <dwmw2_gone> people can re-subscribe, and re-unsubscribe.
Jun 23 12:49:06 <dwmw2_gone> I sent a message to the high-traffic lists which should hopefully have been amongst the first messages received by people who are resubscribed against their will :)
Jun 23 12:49:20 <ldir> did bombadil blow up in catastrophic manner?
Jun 23 12:49:38 <dwmw2_gone> well, it had shitty Dell hardware raid which had dropped a disk for no adequately defined reason
Jun 23 12:49:45 <dwmw2_gone> so when another disk *failed*, it was toast.
Jun 23 12:50:11 <dwmw2_gone> Annoyingly, I have a friend staying with us who build himself a new backup server last week, and was mocking me into compliance. I had *almost* bought this shiny new box full of disks, last week....
Jun 23 12:50:18 <dwmw2_gone> but I hadn't quite got there.
Jun 23 12:50:23 <ldir> oh, 'helpful'
Jun 23 12:50:32 <mamarley> Something something ZFS something.
Jun 23 12:51:36 <Borromini> :P
Jun 23 12:53:14 <ldir> it's a good reminder to me that raid != backup & that I hope my nightly backup to another box in the house along with regular backup to a cloudy destination is good enough.
Jun 23 12:55:01 <PaulFertser> And backup != backup_that_you_regularly_check_is_doing_its_thing
Jun 23 12:55:05 <mamarley> I have a nightly backup to a RasPi with a big SD card tucked behind a desk at my parents' house.
Jun 23 12:55:17 <mamarley> "off-site backup"
Jun 23 12:56:31 <mamarley> The server's main disk is just an SSD with ext4 though.
Jun 23 12:57:13 <ldir> Last week I had a disc in said raid start reporting strangeness - heisendisc errors - so after giving it a quizzical look I purchased a replacement...and prayed whilst the rebuild took place.
Jun 23 12:57:38 <stintel> I actually just ordered a new 12TB backup disk
Jun 23 12:57:52 <stintel> it'll be delivered tomorrow
Jun 23 12:58:49 <Borromini> not an SMR one i hope :P
Jun 23 12:59:11 <mamarley> So far they were only using SMR for smaller ones.
Jun 23 12:59:24 <stintel> HGST SAS 4kn
Jun 23 12:59:32 <stintel> I doubt they'd use SMR in this segment
Jun 23 12:59:58 <mamarley> And while I definitely object to them sneaking SMR into disks, a backup disk might actually be an appropriate application for that technology.
Jun 23 13:00:50 <Borromini> mamarley: i might have misread. there was a big ruckus about WD and seagate sneaking it into their lineup
Jun 23 13:01:28 <mamarley> Borromini: No, you didn't misread.  It was only for certain lines of disks though (not enterprisey stuff) and only for smaller disks so far.
Jun 23 13:03:17 <rsalvaterra> Actually, they snuck SMR into the Red line of drives.
Jun 23 13:03:29 <rsalvaterra> Which are used in RAID.
Jun 23 13:03:35 <Borromini> yes NAS disks afaik
Jun 23 13:03:41 <rsalvaterra> So, yeah, that was definitely evil.
Jun 23 13:03:45 <ldir> exactly the sort of drive that I needed to purchase
Jun 23 13:04:04 <rsalvaterra> Well, don't, ldir.
Jun 23 13:04:17 <rsalvaterra> At least, not without reading the specs very carefully.
Jun 23 13:04:18 <ldir> and led to me buying a seagate ironwolf drive that does NOT have SMR
Jun 23 13:04:53 <Borromini> HGST is WD owned for a while now, i don't know how much of their own technology HGST still has.
Jun 23 13:05:26 <rsalvaterra> I remember Seagate being a tragedy. Now they seem quite good, according to the BackBlaze reports.
Jun 23 13:05:32 <mamarley> I'm pretty sure the *star drives are still HGST technology.
Jun 23 13:05:53 <Borromini> I have two HGST 10 TB drives in my home server <3
Jun 23 13:06:41 <stintel> Borromini: 2x12TB HGST SAS 4kn here. the 3rd one is backup for now but 1 day I might add it to the fs
Jun 23 13:06:42 <Borromini> mamarley: i hope so. they tended to be very reliable
Jun 23 13:07:01 <Borromini> stintel: mine are just plain S-ATA ones :P
Jun 23 13:07:04 <stintel> I used to buy WD Gold before I went to HGST
Jun 23 13:07:16 <stintel> actually pretty good experience with higher end WD's
Jun 23 13:07:29 <mamarley> I've recently gone all-flash for my own stuff, but I still recommend the ex-HGST drives for people looking for spinning rust.
Jun 23 13:07:35 <ldir> So far this seagate has 2 days 21 hours without incident ;-)
Jun 23 13:07:39 <stintel> :D
Jun 23 13:07:46 <Borromini> ldir: better than most xD
Jun 23 13:07:48 <stintel> too much data for full SSD here
Jun 23 13:07:53 <Borromini> same ^^
Jun 23 13:08:00 <Borromini> desktop, laptop: all SSD only
Jun 23 13:08:24 <Borromini> next desktop upgrade will mean all NVMe as well <3
Jun 23 13:08:56 <mamarley> My server and my laptop are both too old to support NVMe. :/
Jun 23 13:09:20 <stintel> I'm doing bcachefs though, 2x12TB + 2x900GB SATA SSD with replicas=1 and I can decide per file if the hot data is supposed to go on the HDD or SSD disk gorup
Jun 23 13:10:15 * rsalvaterra cries in 1 TB WD Green
Jun 23 13:10:26 <Borromini> mamarley: hehe. ultrabook helps with the form factor. no 2,5" storage in those anymore i reckon, anywhere.
Jun 23 13:10:48 <Borromini> it didn't help though dell delivers the xps 13 entry models with a measly 256 GB >_>
Jun 23 13:11:10 <stintel> so as the fs I'm using is pretty experimental and the data on it is now more than my largest single disk I decided to get another 12TB drive for backups :)
Jun 23 13:11:19 <mamarley> I'm actually setting up something similar for my parents' new server, a 14TB HDD and an old, re-used 120GB SSD in bcache.  The cache drive should allow for the highly-random write workload of being a TV DVR along with being a surveillance DVR and a general purpose storage server all at the same time to work.
Jun 23 13:12:01 <stintel> I used to do bcache on my workstation but have sinced added 2x2TB Samsung QVO for /home
Jun 23 13:12:14 <stintel> btrfs raid1 with nightly offside backup
Jun 23 13:12:18 <stintel> offsite*
Jun 23 13:12:41 <stintel> that bcachefs looks very promising
Jun 23 13:12:51 <stintel> and I'm crazy enough to run it in production :P
Jun 23 13:13:32 * mamarley takes the puck away from stintel and initiates a faceoff. :P
Jun 23 13:14:02 <stintel> eh?
Jun 23 13:14:26 <mamarley> That's what happens when there is an offside violation in hockey.
Jun 23 13:14:35 <stintel> oh :)
Jun 23 13:16:22 <rsalvaterra> Is bcache on an SSD that good hiding the latency of the cached HDD's?
Jun 23 13:16:37 <ldir> This raid box has 4 WD Red 2TB drives and 1204 days on the clock - one drive went last October, one has just gone in June.  I'm debating whether to buy another 3 seagates spread over the next few weeks and just replace the lot.
Jun 23 13:16:48 <DonkeyHotei> reminder: failed "hardware" raid is what happened to the old forum
Jun 23 13:17:49 <stintel> DonkeyHotei: you're a bit late to the party. we well established raid is not a substitue for backup. the forum and ml are also maintained by different parties
Jun 23 13:18:55 <DonkeyHotei> even if it's not a backup, recovery is hindered by additional abstraction
Jun 23 13:31:47 <Borromini> :)
Jun 23 13:33:10 <Borromini> my brother's home server has a ZRAID 1 setup, daily differential backup on my home server and a weekly differential backup on a local offlinedisk there
Jun 23 13:33:25 <Borromini> (but i still need to test those local backups...)
Jun 23 14:29:58 <tmn505> blocktrron: hi. I saw You prepared a support for a SonicWall device. Did You ask them for source code, and if yes, what was the result?
Jun 23 14:30:37 <blocktrron> tmn505: did not request source code, so i can't say much about that
Jun 23 14:31:52 <owrt-snap-builds> build #418 of x86/generic is complete: Success [build successful]  Build details are at http://buildbot.openwrt.org/master/images/builders/x86%2Fgeneric/builds/418
Jun 23 14:32:52 <tmn505> blocktrron: thanks, I'll try to do that.
Jun 23 14:33:40 <tmn505> got almost full support for sonicpoint ace, but there are still two issues.
Jun 23 14:50:39 <luilver1> @Borromini: https://volatilesystems.org/dl/lede/targets/HT-TM05/ is getting 404
Jun 23 14:52:04 <Borromini> luilver1: yes
Jun 23 14:52:11 <Borromini> welcome back :P
Jun 23 14:52:18 <luilver1> :)
Jun 23 14:52:57 <Borromini> luilver1: see https://forum.openwrt.org/t/hootoo-ht-tm05-recognize-hw/46844/105
Jun 23 14:53:05 <Borromini> i assume you're using the same nick on the forum
Jun 23 14:53:12 <Borromini> you'll have better luck with that ^^
Jun 23 14:53:34 <luilver> now I'm welcome back :D
Jun 23 14:53:44 <Borromini> someone has already applied to add support for your device but the kernel is too big at this point.
Jun 23 14:53:50 <Borromini> that needs to be worked around
Jun 23 14:54:00 <Borromini> see github PR https://github.com/openwrt/openwrt/pull/2645
Jun 23 14:54:26 <luilver> Nice
Jun 23 14:55:20 <Borromini> except for the kernel hiccup.
Jun 23 14:55:39 <Borromini> it might be a 5.4 issue but it could be 4.14 as well (which is what master uses for mt762O atm)
Jun 23 15:19:55 <rmilecki> jow: hey, do you have any output format preference? https://pastebin.com/rsZ2UKTQ
Jun 23 15:24:13 <owrt-snap-builds> build #412 of x86/geode is complete: Success [build successful]  Build details are at http://buildbot.openwrt.org/master/images/builders/x86%2Fgeode/builds/412
Jun 23 15:55:44 <owrt-snap-builds> build #378 of x86/legacy is complete: Success [build successful]  Build details are at http://buildbot.openwrt.org/master/images/builders/x86%2Flegacy/builds/378
Jun 23 16:06:03 <luilver> Borromini: What if `grep -lri mt762O target/
Jun 23 16:06:44 <luilver> .: Shows me none
Jun 23 16:07:50 <nick[m]1> Hmmmm, something is not working again. I took the Super user access role and converted that to the luci-app-ffwizard-berlin, but still no permissions. that can not be true :S
Jun 23 16:12:39 <luilver> found it with mt300n
Jun 23 16:17:25 <karlp> nick[m]1: they've added permissions and roles since that "super user" acl was added to the wiki
Jun 23 16:17:33 <karlp> it's probably incomplete again :|
Jun 23 16:19:27 <nick[m]1> <karlp "nick: they've added permissions "> maybe I have to add a menu.d script?
Jun 23 16:20:00 <nick[m]1> karlp: maybe I have to add a menu.d script?
Jun 23 16:30:01 <Borromini> luilver: what are you talking about?
Jun 23 16:30:45 <Borromini> luilver: the PR i linked you to suggests another device is closer to yours. kernels will usually be identical between subtargets. so you might still brick your device on master. beware.
Jun 23 16:31:15 <Borromini> luilver: use 'git grep' to grep through the codebase. easier than plain grep.
Jun 23 16:34:15 <karlp> nick[m]1: menu is just to make things appear at all, shouldn't matter for perms
Jun 23 16:34:57 <nick[m]1> karlp: thx.
Jun 23 16:40:46 <jow> rmilecki: #2
Jun 23 16:40:54 <rmilecki> jow: thanks
Jun 23 16:41:24 <jow> nick[m]1: where do you get permission denied?
Jun 23 16:44:07 <nick[m]1> jow: I think it is something else
Jun 23 16:44:08 <nick[m]1> https://github.com/freifunk-berlin/firmware/issues/816#issuecomment-648281975
Jun 23 16:46:20 <jow> get_first() looks correct
Jun 23 16:47:40 <jow> did you add an acl rule with  { "read": { "uci": [ "profile_*" ] } }  ?
Jun 23 16:47:58 <nick[m]1> nope
Jun 23 16:49:34 <nick[m]1> jow: If I just replace that with local name = uci:get("profile_"..n, "profile", "name") or "?" it works
Jun 23 16:49:45 <nick[m]1> I can try setting the permissions again
Jun 23 16:50:35 <nick[m]1> jow:  uci get profile_augsburg.community.name -> uci: Entry not found
Jun 23 16:50:53 <nick[m]1> jow: uci get profile_augsburg.profile.name -> Freifunk Augsburg
Jun 23 16:51:10 <nick[m]1> that is why I don't think it is a permission error?
Jun 23 16:51:32 <karlp> what's in "cat /etc/config/profile_augsburg" ?
Jun 23 16:52:18 <nick[m]1> https://github.com/freifunk/openwrt-packages/blob/master/contrib/package/community-profiles/files/etc/config/profile_augsburg
Jun 23 16:52:23 <nick[m]1> config 'community' 'profile'
Jun 23 16:54:04 <karlp> right...
Jun 23 16:54:19 <karlp> sounds like you're mixing up section type and section name.  (classic!)
Jun 23 16:54:24 <nick[m]1> karlp: ?
Jun 23 16:55:39 <nick[m]1> I just wanted to make the freifunk berlin software compatible with openwrt imagebuilder again. I'm debugging this for hours now. >.> Always weird erros and build stuff.
Jun 23 16:55:54 <nick[m]1> karlp: Me?
Jun 23 16:56:25 <nick[m]1> karlp: Is 'profile' right or 'community'? xD
Jun 23 16:56:49 <karlp> the one that works, I never remember either :)
Jun 23 16:57:20 <karlp> so uci.get profile_augsburg.profile.name is definititive
Jun 23 16:57:43 <karlp> but get profile_augsburg.community..name isn't, because you could have multiple community blocks
Jun 23 16:58:45 <nick[m]1> u mean I should do get_first?
Jun 23 16:59:05 <nick[m]1> ah, sry
Jun 23 16:59:49 <nick[m]1> karlp: Why is the call wrong in this ffwizard? xD It took me hours because I thought it is a permission error -.-
Jun 23 16:59:50 <karlp> I can't say what you _mean_ to do, but mixing up get/get_first with the names vs types is a classic problem, and you need to take care on what ou were trying to do
Jun 23 17:00:28 <karlp> you normally get a pretty clear permission denied error, and you're using lua cbis, so no permissions anyway...
Jun 23 17:00:42 <karlp> (acls are only on the js stuff right? or am I losing my mind)
Jun 23 17:01:42 <nick[m]1> you mean actually uci:get_first on a type could be wrong? because it gives me the first?
Jun 23 17:01:50 <nick[m]1> because I can have different communities with different ne
Jun 23 17:02:02 <nick[m]1> names `profile1`, `profile2` ...
Jun 23 17:02:25 <karlp> well, that too, but also, you need to consistently try and work out whether you are looking for types or names, and how your config will play to thos facilities
Jun 23 17:02:31 <nick[m]1> could be correct*
Jun 23 17:03:00 <karlp> it's quite reasonable to use anon sections, and assume/force there to be only one of that type...
Jun 23 17:03:09 <karlp> but that might not be useful for your application.
Jun 23 17:03:38 <nick[m]1> but get_first on the community does not work?
Jun 23 17:04:15 <karlp> it's probably line 18 that tries the get or default that's wrong?
Jun 23 17:06:08 <nick[m]1> actually line 18 is accessing a section with name community of type public xD
Jun 23 17:06:40 <karlp> I'm not sure what your original problem is, but mixing section names and types is a classsssssic problem, and will keep biting you until you get it reallllly straight in your own design
Jun 23 17:06:57 <nick[m]1> https://github.com/freifunk/openwrt-packages/blob/master/contrib/package/freifunk-common/files-common/etc/config/freifunk#L11
Jun 23 17:08:25 <nick[m]1> karlp: thanks. :) I will have a look at this
Jun 23 17:08:42 <nick[m]1> Actually, I wanted to dev different things for freifunk
Jun 23 17:09:22 <nick[m]1> now I'm stucked with closing the gap between freifunk and openwrt master
Jun 23 17:18:06 <nick[m]1> https://github.com/freifunk-berlin/firmware/issues/816#issuecomment-648298567
Jun 23 17:19:51 <nick[m]1> someone else had similar issues https://github.com/openwrt/luci/issues/1734
Jun 23 17:58:02 <nick[m]1> hmmm, somtimes I get "TypeError: "L.ui is undefined"" in the console, and somtimes not
Jun 23 18:44:43 <owrt-snap-builds> build #351 of x86/64 is complete: Success [build successful]  Build details are at http://buildbot.openwrt.org/master/images/builders/x86%2F64/builds/351
Jun 23 18:46:41 <nick[m]1> jow: Thanks again. It was like u said! :) permissions...
Jun 23 19:55:01 <owrt-snap-builds> build #355 of armvirt/64 is complete: Success [build successful]  Build details are at http://buildbot.openwrt.org/master/images/builders/armvirt%2F64/builds/355
Jun 23 22:03:41 <pkgadd> xback: btw. this https://paste.debian.net/1153570/ patch is needed to bump kernel v4.19.123 to v4.19.129, successfully tested (only) on ath79
Jun 23 22:08:40 <pkgadd> build- and runtime tested on a tl-wdr3600 (which bootloops on kernel v5.4, FS#2928)
Jun 24 02:45:33 <owrt-snap-builds> build #425 of mediatek/mt7623 is complete: Failure [failed kmodconfig]  Build details are at http://buildbot.openwrt.org/master/images/builders/mediatek%2Fmt7623/builds/425  blamelist: Catalin Patulea <catalinp@google.com>, Leon M. George <leon@georgemail.eu>, Alex Lewontin <alex.c.lewontin@gmail.com>, Sungbo Eo <mans0n@gorani.run>, Edward Matijevic
Jun 24 02:45:33 <owrt-snap-builds> <motolav@gmail.com>, Adrian Schmutzler <freifunk@adrianschmutzler.de>, Sven Roederer <devel-sven@geroedel.de>, Jose Olivera <oliverajeo@gmail.com>
**** ENDING LOGGING AT Wed Jun 24 02:59:57 2020