**** BEGIN LOGGING AT Mon Feb 29 02:59:58 2016 Feb 29 04:05:28 is there a convention for naming userspace patches, like https://wiki.openwrt.org/doc/devel/patches#naming_patches ? Feb 29 10:31:13 any tips on testing procd changes? I've clearly done something wrong, it's just rebooting all the time now :) Feb 29 11:40:42 cant I pass DBGLVL from uboot or something? Feb 29 11:40:51 pressing "4" and pressing enter doesn't seem to do anything at all Feb 29 11:41:08 f for failsafe works, Feb 29 15:23:13 ok, how about, "if I enter failsafe, can I _resume_ booting?" because then I can start procd with gdbserver maybe? Feb 29 15:30:06 karlp: you could modify your kernel to run with init=/bin/ash Feb 29 15:30:28 karlp: and then set up your stuff Feb 29 15:30:59 well, how does it normally work? I want it to run normally, just maybe under gdbserver. https://wiki.openwrt.org/doc/techref/process.boot hasn't been updated for procd (yet) Feb 29 15:31:25 I'm trying to add the pidfile reporting we spoke about a while ago, Feb 29 15:31:55 do I just run "procd" when I'm ready? Feb 29 15:32:14 where does preinit fit in? Feb 29 15:32:34 preinit does some stuff, mounts filesystems, then execs procd Feb 29 15:33:30 how do you normally do development on procd? Feb 29 15:33:43 I can hack around on init, but it doesn't sound like that's what you're doing yourself. Feb 29 15:34:36 most of the time when i work on it it runs normally and maybe only crashes occasionally Feb 29 15:34:42 if that's the case, i let it boot normally, attach gdbserver Feb 29 15:34:48 then try the stuff that makes it crash Feb 29 15:35:13 if what i did makes it crash early, i carefully review it Feb 29 15:37:40 yeah, I wasn't expecting to get crashes when I hadn't even made any init scripts try to use the code I added. Feb 29 15:37:54 bu ok, if there's no better way, I'll just remove code then until it at least boots. Feb 29 15:38:20 karlp: you could paste a diff and we could throw some eyeballs onto it Feb 29 15:38:24 do you have nfs rootfs or anything? or do you aveh to make package/procd/{clean,compile} and install each time? Feb 29 15:38:41 i skip the clean part Feb 29 15:38:45 i don't use nfs Feb 29 15:38:52 jow_laptop: just pushing it up now, was hopign to get it basically functional first :) wasn't expecting such difficulties. Feb 29 15:38:56 i use CONFIG_SRC_TREE_OVERRIDE=y Feb 29 15:38:56 When I work with procd I do (clean,)compile and testing on x86/qemu Feb 29 15:38:58 with the git-src symlink Feb 29 15:39:11 and install it on a device from my laptop's http server Feb 29 15:39:22 that provides a fully writable rootfs so I can simply repalce binaries (and loop mount in case its unbootable) Feb 29 15:39:30 plus (re)booting is fast Feb 29 15:39:39 i simply boot into failsafe if the installed procd fails Feb 29 15:39:42 so i can remove the file from overlayfs Feb 29 15:39:47 and make it revert to a working one Feb 29 15:39:57 I'm suign the git-src symlink, Feb 29 15:40:11 and yeah, I was installing the package from teh nfs export of my laptops build dir, Feb 29 15:40:44 ok, I was reflashing from bootlaoder, I hadn't thought of removing the procd file from overlay. Feb 29 15:41:15 this is what I'd started with: https://github.com/karlp/procd/commit/fbbcede8562c0d5f783fe3985f204f0f3a4bf21f Feb 29 15:42:27 it would get just after "IPv6: ADDRCONF(NETDEV_UP): eth0: link is not ready" as links were coming up and then it would just reboot. "[ 35.090000] reboot: Re�" Feb 29 15:42:32 you should remove the if (pidfile) check Feb 29 15:42:43 to avoid keeping stale data in case it goes from pidfile to no pidfile Feb 29 15:43:06 i think Feb 29 15:43:11 need to review the code again Feb 29 15:43:17 either way, that check is unnecessary, even if it might be safe Feb 29 15:43:22 another thing is: Feb 29 15:43:26 instance_config_changed Feb 29 15:43:34 you need to check if the pointers are non-NULL before calling strcmp Feb 29 15:43:45 karlp: also use the 3-argument form of open() with O_CREAT Feb 29 15:43:52 which check exactrly? (for if (pidfile)) Feb 29 15:43:55 otherwise you might end up with wierd pid file perjmissions Feb 29 15:43:59 this is why I wanted ot at least _test_ it first. Feb 29 15:44:13 jow_laptop: for that I did it deliberately so it got he perms from teh environment, Feb 29 15:44:24 doesn't the process already have the perms from teh procd user at that point? Feb 29 15:44:44 karlp: I think its undefined Feb 29 15:44:56 you should request something like 0644 as default Feb 29 15:45:47 see also http://stackoverflow.com/questions/2245193/why-does-open-create-my-file-with-the-wrong-permissions Feb 29 15:49:07 so, to the original question, is there any right way of passing the DBGLVL from the bootloader? and does pressing 4 on the console at boot work for you guys? Feb 29 16:02:53 nbd: looks like it was the strcmp causing the crash at least, thanks, I've got somewhere to move on with this now :) Feb 29 16:50:36 anybody has an idea why one seem to need LC_ALL=de_DE patched into environment when running glib-compile-resources / vala stuff ? Feb 29 16:51:39 some patch like http://paste.debian.net/410263/ fixes the issue - the issue is happening with normal build (intl-stub) and with full NLS/intl-full Feb 29 19:25:55 nbd, I think your latest ath10k-firmware backport relies on URL_FILE support, which hasn't been backported yet (r47591 and r48427) Feb 29 19:28:10 I believe something like https://raw.githubusercontent.com/freifunk-gluon/gluon/master/patches/openwrt/0032-ar71xx-backport-ath10k-calibration-data-load-changes.patch is required as well to make ath10k work without the removed 920-ath10k_allow_fallback_to_board_bin_on_empty_otp_stream.patch? (which is a backport of various trunk commits...) Feb 29 19:41:04 neoraider: thanks, i will look into it Feb 29 20:02:46 neoraider: done Feb 29 20:03:16 neoraider: anything else that you think should be backported? Feb 29 20:09:41 nbd, nothing directly related to the mac80211 backport, that looks fine now Feb 29 20:09:56 anything else? Feb 29 20:10:00 while i'm at it Feb 29 20:10:02 ;) Feb 29 20:13:06 I'll have to look through our Gluon patchset, I've been meaning to sort that out for some time now and send backport requests for lots our our patches Feb 29 20:13:35 ok Feb 29 20:14:45 nbd, should I send the revision numbers here on IRC, or should I just git send-email them to the ML? Some of them aren't trivially backportable (like r46207) Feb 29 20:15:38 git send-email as a full series is probably better Feb 29 20:15:50 should be with the git-svn-id tag replaced with "Backport of r..." Feb 29 20:15:57 Ok Feb 29 22:00:58 nbd, it seems there's still something wrong with the mac80211 backport, an ALL_KMODS build now fails with: Feb 29 22:01:01 build_dir/target-mips_34kc_uClibc-0.9.33.2/linux-ar71xx_generic/compat-wireless-2016-01-10/drivers/net/wireless/broadcom/brcm80211/brcmfmac/firmware.c:22:33: fatal error: linux/bcm47xx_nvram.h: No such file or directory Feb 29 22:03:16 target/linux/generic/patches-3.18/030-backport_bcm47xx_nvram.patch is missing from the backport Mar 01 00:34:10 jow_laptop: any comments on https://github.com/openwrt/packages/pull/2397 ? Mar 01 00:35:57 nbd: do you have any idea what could be the problem with 4.4 kernel not booting on rspro? the serial console output is at https://stewie.be.tintel.eu/openwrt/rspro-4.4.0.txt but doesn't show anything useful Mar 01 00:36:02 well at least to me it doesn't :) **** ENDING LOGGING AT Tue Mar 01 02:59:58 2016