**** BEGIN LOGGING AT Wed Feb 20 02:59:57 2019 Feb 20 09:14:14 dedeckeh: ping - morning :-) Feb 20 09:25:06 ldir:pong - morning as well Feb 20 09:27:40 dedeckeh: thanks for responding to Tony, I have done so as well. I have his fix in a local tree and it now looks like I get 'nstat/ss/etc' installed into the staging dir no matter whether I have tiny or full (or both) selected. I don't know whether you have done any further testing? Feb 20 09:29:08 ldir:not yet Feb 20 09:29:43 but I fear a can of worms has been opened ... Feb 20 09:31:07 I don't understand why ip-full needs to depend on libelf Feb 20 09:32:31 as I thought this was only necessary for tc Feb 20 09:34:26 Hmmm. That's what I thought too. Feb 20 09:44:35 I'm no longer involved enough nor understand enough to carry on with this 'committer/maintainer' thing. My trying to help out is causing far too much fallout. Once this is sorted out I think it best I don't have commit access any more - I'm too much of a target for people to say 'just put this in, it'll be fine' Feb 20 09:45:16 I've been thinking along these lines for a while now. Feb 20 09:47:30 ldir:don't take this personally; I don't think this is your fault at all Feb 20 09:48:40 ldir:it boils down to people not testing enough their patches Feb 20 09:50:14 and the committer (ie. me) not knowing how/what to test either - it (ideally) shouldn't have got past me. So I'm 'playing' in areas I don't understand, that isn't ideal. Feb 20 09:50:59 ldir:on the other hand it's impossible to test every PR thre will always be fallout Feb 20 09:51:22 you basically have to learn whose PRs/patches you can trust, and who tends to create PRs/patches which need more scrutiny - requiring a well worded commit message explaining why a change is necessary (and what the change tries to achieve) often helps a lot when doing code reviews without testing Feb 20 09:53:08 fully agree on that; certainly the PRs on github require more scrutiny that those on patchwork Feb 20 09:56:16 and regardless how much testing/reviewing you do, sometimes broken stuff will slip through Feb 20 10:01:11 I only trust the patches I author..and even then only barely :-) A number of occasions I've taken patches from people I regard as knowing what they're doing and had 'surprises' as a result - mind you the last one snuck past the kernel people too :-) Feb 20 10:04:02 real life interrupts so will be AFK for a bit Feb 20 10:04:37 ldir: so you see you aren't actually doing worse than even the kernel people ;-) Feb 20 11:35:35 using opkg -o and -d , what are the intended use-cases ? and also i found that post-install scripts don't honour the -o option. is this considered a bug? Feb 20 11:43:15 Piraty: if they don't honour it, then it's a bug Feb 20 11:47:40 KanjiMonster: i need to clarify a bit on that postinstall scripts: using absolute path in postinstall, that does not honour the -o (which opkg should ensure in some way, no?) Feb 20 11:51:43 in my case (not openwrt) i find the use of $DESTDIR in those scripts alot, so invocation of opkg -o ... needs to make that var available, which is redundant. is that what openwrt does too? if yes, i'll quiet down :) Feb 20 12:38:54 Piraty: actually for the postinst scripts they aren't run by default when setting -o/offline root (unless you force them to be run); the path from -d should be available as $PKG_ROOT (not sure if anything observes that though) Feb 20 12:39:47 yeah forgot to mention --force-postinstall, you're right Feb 20 12:40:16 what is the differente in -o and -d then? Feb 20 12:40:46 i didn't quite get it after reading the manpage and various online resources, which copy the manpage anyway Feb 20 13:13:15 Piraty: AFAICT -d will resolve the name to a path from opkg.conf, while -o will take an absolute path and ignore the opkg.conf (won't even try to load it) Feb 20 13:14:03 so i could use -d with the same effect as -o if i configure it correctly in opkg.conf you say? I'll quote you on that and ping you if it fails ;) Feb 20 13:14:13 Piraty: also I would assume that -d won't change where opkg stores its data, while -o does (haven't checked if this is the case) Feb 20 13:45:16 hi all, how to generate trx image? Feb 20 16:36:06 for the interested: new kernel bumps in my staging Feb 20 19:53:34 I'm trying to understand how "autosplit Feb 20 19:54:07 of partitions is done by the kernel, ipq40xx, in general, to ensure I've got the proper structure Feb 20 19:54:51 It wasn't obvious to me *how* the kernel scans the partition of interest from target/linux/generic/pending-4.14/40?-*.patch Feb 20 19:55:11 Is there a reference to where this is done? Feb 20 19:56:23 (It's a NAND-based, dual-firmware device, so can't use the "preferred" method of defining a partition by name) Feb 20 21:13:39 indy: see target/linux/brcm47xx/image/Makefile Feb 20 21:13:45 or the same for bcm53xx Feb 20 21:13:59 rmilecki, thanks Feb 20 21:14:51 indy: it's basically calling "trx" or "otrx" that you can find in tools/firmware-utils/src/trx.c and tools/firmware-utils/src/otrx.c Feb 20 21:15:19 indy: ./staging_dir/host/bin/otrx --help Feb 20 21:25:22 rmilecki, great thanks a lot Feb 20 21:25:27 np Feb 20 22:26:33 how do i increase the log verbosity? **** ENDING LOGGING AT Thu Feb 21 02:59:57 2019