**** BEGIN LOGGING AT Tue Sep 24 02:59:59 2019 Sep 24 05:09:04 hellooo Sep 24 05:09:29 I am trying to squash the commits of my PR, anyone can help me? Sep 24 05:17:28 msgito: you could use interactive rebase (git rebase -i) for that. I believe Google could show you several excellent tutorials :) Sep 24 05:20:48 msgito: assuming you want to squash e.g. three commits, you would run "git rebase -i HEAD~3" Sep 24 05:21:17 msgito: in the interactive editor, you would change the second and third commit action verb from "pick" to "squash" Sep 24 05:21:45 msgito: then save & exit the editor, another editor session will pop up showing you the commit text for the three merged commits Sep 24 05:21:55 addjust the commit message to your liking, save & quit again Sep 24 05:22:10 git will now merge the second and third commit into the first Sep 24 05:36:54 the thing is that my PR have 9 commits, I did a merge onto the branch to update the branch, now the log show my 9 commits when I list them (git log | grep "^Author: Manuel" -B1 -A 5) Sep 24 05:39:01 but when I do git rebase -i HEAD~12, I see a long list of commits to pick, at the beginning I se mine, but I don't see 9 in the long list... and I am not sure if I should remove the lines of everything else, or that would cause to lose that commit overall, not just "ignore" from my squash commit Sep 24 05:39:25 this is the PR: https://github.com/openwrt/openwrt/pull/2434 Sep 24 06:10:05 msgito: sounds like merge commits Sep 24 06:17:05 also I read about not doing git push force, but looks like to fix things I need to force Sep 24 06:20:42 I'd do git rebase origin/master Sep 24 06:20:53 for further changes, just git commit --amend Sep 24 06:30:01 msgito: for an open pr, a force push is fine Sep 24 06:40:34 I see Sep 24 07:02:20 jow: I'm trying to extract the signature form some ath79 binaries and the content is literally "# fake certificate ", where is this attached? Sep 24 07:02:41 lynxis: same question to you, am I missing something here? Sep 24 07:05:04 this is driving me crazy... Now I just can't ignore local changes/repository: Sep 24 07:06:08 openwrt$ git reset --hard Sep 24 07:06:09 target/linux/ath79/base-files/etc/hotplug.d/firmware/11-ath10k-caldata Sep 24 07:06:59 looks like git and me don't get along together very well Sep 24 07:08:06 aparcar[m]: its added by the buildbots Sep 24 07:09:11 aparcar[m]: the introduction of the ucert stuff made it impossible to build usign enabled images (as in on-device opkg signing support) without also signing the image on the builder, which we donÄt want to do Sep 24 07:09:23 so I had a number of hacks to bypass this Sep 24 07:10:18 uh I'm sorry for that Sep 24 07:10:46 I have spent more time fighting/learning with git, than actually doing things... hahaha Sep 24 07:11:11 someone needs to invest work to untangle build-time ucert/usign support from run-time ucert/usign support Sep 24 07:11:28 basically separate the bits involving private keys from the ones involving public keys Sep 24 07:11:30 jow: I'm trying to figure out why the images are not reproducible, do you have another clou? The sqashfs is reproducible now right? https://rebuild.aparcar.org/SNAPSHOT/ath79/generic/ Sep 24 07:12:21 msgito: https://xkcd.com/1597/ Sep 24 07:13:39 aparcar[m]: uhm, maybe multithreaded lzma issues Sep 24 07:13:53 just a random guess Sep 24 07:13:56 I though this was fixed some time ago via squashfskit4? Sep 24 07:14:15 lynxis worked on that if I remember it right Sep 24 07:14:35 not sure, all I rmemeber is that we disabled / didn't enable multi threaded xz because it was not reproducible Sep 24 07:14:37 also looking here https://rebuild.aparcar.org/SNAPSHOT/x86/64/ it seems reproducible Sep 24 07:14:52 when packing IB; SDK Sep 24 07:14:58 maybe it slipped in elsewhere Sep 24 07:15:07 jow, this is where I am right now... thinking that the best would be to download, but seems too stupid... Sep 24 07:16:03 msgito: it takes quite some while to master git, especially the less usual things like retroactively modfying the history, rewriting (non-topmost) commits, filtering etc. Sep 24 07:16:29 specially, because I have at least 10 copies of openwrt git on my hdd already Sep 24 07:16:51 msgito: it's worth the hussle :) Sep 24 07:17:23 you could also try some shotgun approach like: git diff origin/master..HEAD > all-my-own-changes.patch; git reset --hard origin/master; patch -p1 < all-my-own-changes.patch; git add ...; git commit -s Sep 24 07:17:25 going to count all the copies, just so we can all lol at me :D Sep 24 07:18:30 jow: please hit me with any idea regarding preproducing the image... Sep 24 07:19:12 msgito: at some point this comes in handy https://whatthecommit.com/ Sep 24 07:19:15 aparcar[m]: I have no immediate ideas, maybe start with figuring out what the first lines in https://rebuild.aparcar.org/SNAPSHOT/ath79/generic/openwrt-ath79-generic-8dev_carambola2-squashfs-sysupgrade.bin.html are and why they differ Sep 24 07:20:44 24 copies of openwrt, some of them pointing to the main project, others to my fork. and I have some extra more compressed to reduce space... Sep 24 07:20:50 not too bad... hahahaha Sep 24 07:22:55 msgito: git remote add comes in handy Sep 24 07:23:12 jow: thanks I'll try to figure it out Sep 24 07:23:46 I have the remote configured: Sep 24 07:23:48 git remote -vorigin https://github.com/mgiganto/openwrt (fetch)origin https://github.com/mgiganto/openwrt (push)upstream https://github.com/openwrt/openwrt.git (fetch)upstream https://github.com/openwrt/openwrt.git (push) Sep 24 07:24:21 jow: so you say the problem is that an installed ucert causes the buildroot to add the signature which isn't desired, but you would want to have ucert preinstalled to allow future sig checks? Sep 24 07:25:31 no. the problem is that in order to have usign support in the image, you need to enable CONFIG_SIGNED_PACKAGES which in turn will trigger host usign/ucert building which in turn will generate a keypair locally which is then baked into the image Sep 24 07:25:51 the only way to prevent this, is shipping a known to-be-used keypair to the untrusted builders Sep 24 07:26:18 which means exposing the secret private key to 3rd party build infrastructure Sep 24 07:26:55 what is needed is the ability to: Sep 24 07:27:08 - only ship a public key Sep 24 07:27:31 - skip image signing, package list signing etc. if no private key is present Sep 24 07:27:50 - yet enable usign support in opkg within the image using the public key present in buildroot Sep 24 07:28:02 if I do git reset --hard origin/master, what would be the impact to my PR? Sep 24 07:28:44 if you take a look at the code in buildroot you see that it has various places like [ -f key && -f key.pub ] || generate keys Sep 24 07:29:32 and the whole ucert business fails hard when no private key is present, there also is support for shipping pregenerated certificates required Sep 24 07:30:41 basically signing and handling secrets must be decoupled from the build process Sep 24 07:31:07 it can still reside in buildroot and be called as skipable make target for the normal "end user" case Sep 24 07:31:35 but for the authorative build infra I do want the signing of stuff happen off-line, as in not on random 3rd party builders Sep 24 07:32:00 but only on the trusted buildmasters or even on the repository servers itself Sep 24 07:33:10 msgito: the reset hard will basically wipe any of your local work and reset your branch to the exact same state as the origin Sep 24 07:33:39 should I use then the branch name? or master Sep 24 07:33:44 msgito: if you'd force-push that without further commits, your PR branch would contain zero commits as it would be even with master Sep 24 07:34:24 msgito: you should use origin/master as reset target Sep 24 07:34:29 ok Sep 24 07:34:34 going to try, thanks :D Sep 24 07:35:05 msgito: also note that this will reset the state to your local known version of origin/master Sep 24 07:35:26 afterwards best is to run a "git pull origin master" to update to the latest changes Sep 24 07:35:33 then re-add your changes Sep 24 07:37:43 jow: so not even generating checksums as they change once the images are signed right? Sep 24 07:39:28 correct Sep 24 07:39:48 well, checksums can be generated, its no problem to calculate them again after signing Sep 24 07:40:07 iirc the buildbot also actively uses sha256sums to check which files to transfer Sep 24 07:42:48 this is giving me a headache.... :D Sep 24 07:43:16 I am beginning to hate git hahaha Sep 24 07:44:45 so I did the reset, I have pending the git commit, but because I have to do it, I lost the commit message, it's fine, I can recover it from another copy Sep 24 07:45:05 jow: right I remmeber the sha256sum transfer requirement Sep 24 07:45:15 I'll look into that once the rebuild-project is finished Sep 24 07:46:04 thanks Sep 24 07:47:24 jow: can you say if any of the "Unreproducible and otherwise broken packages" packages (a bit scrolling down) is installed by default in the images? that could cause the trouble...https://rebuild.aparcar.org/SNAPSHOT/ath79/generic/ Sep 24 07:47:42 but I really want to finish the commit/pr, maybe because I don't know how to handle git and keep up the branch... the more changes/divergences I get//apply, the more openwrt local git copies I have Sep 24 08:02:47 jow this is what happens now after doit what you said, when I try to push: Sep 24 08:02:49 To https://github.com/mgiganto/openwrt ! [rejected] devolo_magic-2-wifi -> devolo_magic-2-wifi (non-fast-forward)error: failed to push some refs to 'https://github.com/mgiganto/openwrt'hint: Updates were rejected because the tip of your current branch is behindhint: its remote counterpart. Integrate the remote changes (e.g.hint: 'git Sep 24 08:02:49 pull ...') before pushing again.hint: See the 'Note about fast-forwards' in 'git push --help' for details. Sep 24 08:04:23 I did git diff origin/master..HEAD > all-my-own-changes.patch; git reset --hard origin/master; git pull origin master ; patch -p1 < all-my-own-changes.patch; git add ...; git commit -s Sep 24 08:06:10 Shall I force? Sep 24 08:20:35 msgito: if you want to replace the top commit, you need to force - by default git only allows you adding commits, but not modifying commits (that already exist remotely) Sep 24 08:26:31 once I do that, the problem would be to sync the other copies of git that I have Sep 24 08:35:46 I think what I should do is sync my local repository from github, and if there is any conflict, or local comits/rebases/ local branches diverging... don't care, what I really want is to ignore local and override with my github branch, Sep 24 08:36:51 If I am able to do that, I would be able to sync all the openwrt folder copies and work from there... I delete the folder and download, but then I will have to recompile everything... Sep 24 08:52:20 msgito: exactly Sep 24 08:59:42 aparcar[m]: it's not the signature different (of corse also). but a lot more. maybe you're building the wrong commit. i don't think it will work, just building master and hope snaphots is in sync (from the commit) with it. however all release won't be reproducible, because some patches are missin Sep 24 09:07:05 lynxis: wait what? I'm checking out the same commit as on master, trying to do the same steps as buildbots do and the x86/64 squashfs image is even reproducible Sep 24 09:10:05 even chmodding the public key to fit the buildbots... https://gitlab.com/aparcar/rebuild/blob/master/rebuild.py#L236 Sep 24 09:21:38 lynxis: anyway gotta sleep, if you find the time please have a quick look Sep 24 09:21:45 will catch up in 8 hours Sep 24 09:30:06 do you know where do we use get_mac_label() ? I don't see when we call it anywhere Sep 24 09:31:04 it is defined in /lib/functions/system.sh Sep 24 09:34:33 msgito: iirc it has been recently added for future use by board definitions Sep 24 09:34:45 did we ever allow codefresh on the openwrt github organisation? I need to test this for my day job, and for this I need to allow access to my account, and in the list of organizations I cannot disable access to the openwrt organization Sep 24 09:35:21 what kind of access doe it require? Sep 24 09:35:58 ok, so we really don't use it yet? that explains why I couldn't find any reference... I was wondering what was it for, and if I had to use it in a different way :D Sep 24 09:36:20 by the way Jow, thank you for your patience with me :D Sep 24 09:36:47 jow: `Read-only access Sep 24 09:36:47 This application will be able to read your organization, team membership, and private project boards. ` Sep 24 09:37:23 it's probably not an issue, but the fact that I cannot revoke the organization access for openwrt completely just makes my head explode Sep 24 09:37:51 okay, as long is it has no writable access or code access its fine I guess Sep 24 09:37:53 it is not like that for my other 2 orgs, for those I have to grant explicitly Sep 24 09:38:34 I granted it for the organization of my own company (it's empty), then revoked, and now that is in the opposite state as the openwrt org, it has a red cross and the grant button is gone Sep 24 09:38:54 well let's see if I can fix that afterwards Sep 24 09:38:56 bloody github :P Sep 24 09:40:35 https://github.com/organizations/openwrt/settings/oauth_application_policy/confirm Sep 24 09:40:43 interesting Sep 24 09:41:07 ah, for lede-project this is enabled Sep 24 09:41:24 jow: do you agree to do this for openwrt organisation too? Sep 24 09:41:58 stintel: in principle yes, but smells like something that has the potential to blow up Sep 24 09:42:09 like breaking the circleci stuff etc. Sep 24 09:42:22 yeah, quite possible Sep 24 09:42:28 bug tracker login, wiki login Sep 24 09:57:18 let's try, it is possible to remove the restrictions entirely again Sep 24 09:57:18 ok Sep 24 09:57:18 hmmm Sep 24 09:57:18 it is enabled Sep 24 09:57:18 circleCI config is on the org itself, these things linked to the org itself are not impacted by this **** BEGIN LOGGING AT Tue Sep 24 09:57:36 2019 Sep 24 10:02:04 aep: not building one usually means not possible.. that said, I think it's usually factory ine that's impossible if any :/ Sep 24 10:02:32 aep: if you mean sysupgrade images, some devices don't require separate sysupgrade images, so just the factory image works fine for sysupgrade Sep 24 10:04:07 (I didn't taught this, makes sense) Sep 24 10:05:14 Though doesn't factory image usually work anyway even when sysupgrade ones exist too? I know mine tplunks does Sep 24 10:07:59 olmari: yeah, we often support flashing factory as well (I guess it also makes it easier to go back to stock) Sep 24 10:09:27 I know mine sample size is still small in grand scheme, but I don't think I've had any device yet that didn't take factory too :) Sep 24 10:10:25 aep: which device are you talking about? Sep 24 10:24:56 KanjiMonster: orange pi zero. its a sunxi h3 Sep 24 10:25:06 currently only building an sdcard.img.gz Sep 24 10:25:17 with an rw ext4 Sep 24 10:26:28 my guess is that whoevber did the port didnt care about sysupdate because most people will probably just change the sdcard. Sep 24 10:27:40 aep: sysupgrade should work with sdcard images (it uses the vfat/boot partition for storing the kept files) Sep 24 10:27:45 Then again x86 sysupgrade (the program) in general takes in ext4-combined.img.gz Sep 24 10:28:03 well, that's how e.g. raspberry pi sdcard images work Sep 24 10:28:24 Yeah.. my thoughts too, at same time (: Sep 24 10:29:28 errr. you just give sysupgrade the img.gz? Sep 24 10:29:30 weird Sep 24 10:30:08 yepp, that's how it works Sep 24 10:30:23 there's a bootloader in it tho. scary Sep 24 10:30:43 also does the platform check work on a gziped image? Sep 24 10:30:48 yes Sep 24 10:30:53 well nice Sep 24 10:31:25 we really should remove extensions like .tar or .gz from images Sep 24 10:31:43 thy simply raise questions Sep 24 10:31:57 nope it doesnt check anything. i just gziped /dev/random and sysupgrade accepted it Sep 24 10:32:29 but actually didnt flash anything. now i'm very confused Sep 24 10:32:33 jow: in case of the sdcard images we can't, since you can't write the gzipped image directly to a sdcard for the initial "installation" Sep 24 10:32:53 uh you can't? thats what i did Sep 24 10:33:25 aep: zcat | dd vs. dd if=... Sep 24 10:33:32 jow: also, for x86 the general.imagr is same one I need to write by hand first time, so in that sense renaming it to something obacure wouldn't help there Sep 24 10:33:53 oooh you mean remove the extension but keep it gzipped. no that would be more confusing than now Sep 24 10:34:48 how about just putting "update" _and_ "sdcard" in the file name somewhere? i would have just tried then Sep 24 10:35:01 I think that those images that does have zip.gz or whatever package extension is that for a reason, at least from experience of x86 Sep 24 10:36:01 Well one could symlink maybe... duplicating same exact file doesn't make sense alone Sep 24 10:36:23 i mean just put it in the same file Sep 24 10:36:37 openwrt-sunxi-cortexa7-sun8i-h2-plus-orangepi-zero-ext4-sdcard.update.img.gz Sep 24 10:38:07 Ah.. mm.. maybe.. all this needs still not to be made too overcomplicated Sep 24 10:38:20 the filename is already quite long Sep 24 10:38:36 well imo the best solution is to just have better documentation by image type :D Sep 24 10:38:39 Not saying couldn't possibly be improved but at what method Sep 24 10:38:47 its really simple actually Sep 24 10:38:57 Even documenting would be one form :) Sep 24 10:39:06 is the file supposed to unpacked or decompressed by the user? Give it a .tar or .gz extension Sep 24 10:39:27 is it supposed to be passed to sysupgrade as-is? Call it .bin and treat it as opague Sep 24 10:39:53 jow: well the x86 combined .gz is both Sep 24 10:39:59 we used to have (or still have?) blahblah-sysupgrade.tar files and people unpack them, wondering what to do with the pieces Sep 24 10:40:04 then copy it Sep 24 10:40:18 that'll make it very confusing when all you got is a .bin file and are just trying it for the first time Sep 24 10:40:23 aep: IIRC the naming is usually to omit factory or sysupgrade from the filename if one image can be used for both, and only use it if there need to be separate images for it Sep 24 10:40:23 call one copy sysupgrade.bin and the other factory.img.gz Sep 24 10:40:30 sdcard.gz is very obvious Sep 24 10:40:45 KanjiMonster:right. consistency always wins :) Sep 24 10:40:46 aep: why is it confusing? Sep 24 10:41:02 jow: because how are you supposed to know how to put it on an sdcard then? Sep 24 10:41:09 if I am not supposed to unpack the image, I find having a .gz extension very confusing Sep 24 10:41:22 you need to, on first install Sep 24 10:41:32 For images having exactly one method this is easy indeed, but like said, x86 one can as well be made by hand (first time usually) or showe it later to sysupgrade Sep 24 10:41:34 thats why I said there should be a differently named copy Sep 24 10:41:39 aah Sep 24 10:41:48 factory.img.gz and sysupgrade.bin Sep 24 10:41:55 yes that makes alot of sense Sep 24 10:42:09 Doubling the space (stupid) or sym/hardlink (bettee)? Sep 24 10:42:25 the source code is massive compared to the sdcard images. i dont think it matters Sep 24 10:42:30 coming up with complicated naming algorithms like "if its usable for both its called that but if not you'll this and that) is programmer think, no casual user will guess it right Sep 24 10:42:44 but symlink would be nice because it makes it obvious to the user they're identical Sep 24 10:42:49 Ofcourse, opinions;) Sep 24 10:43:42 (also someone might store both images, not knowing you only need one) Sep 24 10:47:30 Also, space in buildroot is rarely an issue, I just like not to waste space just because possible :) Sep 24 10:50:48 olmari: you haven't seen the concerns of mirror server providers, noticing the build artifact take over more and more space ;) Sep 24 10:51:11 yeah buts likely not due to a handful of 4-10MB images getting duplicated Sep 24 10:51:23 its due to the kmod archive and the ever more frequent kernel version bumps Sep 24 10:54:23 if we are talking only about sdcard images then yes, but e.g. brcm63xx is almost completely "dual use" images Sep 24 10:57:38 the kmod archive for brcm63xx is currentls 2.2G in size, all *.bin images together 353M Sep 24 10:59:07 we'll need some image duplication mechanism first anyway Sep 24 10:59:54 might be also useful for those images that multiple devices though, providing an appropriately named image for each supported device Sep 24 11:00:05 *support Sep 24 11:00:10 symlink would be a simple and robust solution Sep 24 11:00:15 yeah Sep 24 11:06:04 interesting report: https://forum.openwrt.org/t/reliably-reproducible-kernel-oops-after-adding-a-new-server-to-znc/45176 Sep 24 11:06:17 wonder if it is somehow flow offloading related Sep 24 11:13:59 that would also be my first guess Sep 24 11:17:21 a7-v5 is ath79 Sep 24 11:20:27 target/linux/ath79/patches-4.14/910-unaligned_access_hacks.patch ? Sep 24 11:22:00 first suspect for weird kernel networking issues when flow offloading is enabled is flow offloading; unaligned hacks after that Sep 24 11:28:13 given that an upstream change in the kenrel broke offloading in 4.19 for good due to apparently swapped if indexes, I am not so sure if our offloading is secure and production ready to begin with Sep 24 11:29:41 https://github.com/openwrt/openwrt/pull/2266#issuecomment-515375810 Sep 24 11:30:05 also hints at the fact that our xt_OFFLOAD target is improperly implemetned Sep 24 12:18:16 * ldir thinks flow offloading is the work of the devil anyway - returns to secret underground lair Sep 24 13:55:50 does somebody with knowledge about /dev/mem in openWRT have spare time to do a payed work for libmraa? Sep 24 15:33:52 novski_: but https://01.org/mraa says "THIS PROJECT IS CURRENTLY ARCHIVED, AND IS NO LONGER SUPPORTED" Sep 24 15:34:45 maybe by intel, but not by novski? Sep 24 15:35:40 the amount of work they put into making their own complete stack for libmraa, and then just binning the whole lot amazes me. Sep 24 15:54:34 No its transfaired to eclipse foundation Sep 24 15:55:32 Realized that today. PR must be done to the new repo at eclipse foundation. Sep 24 15:58:41 novski_: The problem with /dev/mem is that it's a security risk so you don't want it on by default. Build a custom kernel and turn it on for your stuff. Sep 24 15:59:16 No i don‘t whant that. Sep 24 16:00:39 Im interested in a long term solution because the mraa is so broad solution for sensors Sep 24 16:01:46 Is there no chance to change the libmrsa to work with recent openWRT public builds? Sep 24 16:02:18 The long term solution is to rewrite that device to not use /dev/mem Sep 24 16:03:24 And use what instead? Sep 24 16:03:39 The appropriate APIs? Sep 24 16:04:41 Can you name a possibility of IPA Sep 24 16:04:47 API Sep 24 16:07:30 I am at a loss for why a sensor layer needs to use /dev/mem at all so no. Sep 24 16:08:55 Do you know a different way to use sensors easy? Sep 24 16:09:00 Perhaps they used it to access a sensor class for which there is no driver support. Sep 24 16:09:00 In that case build it without support for that sensor class and then it won't depend on /dev/mem anymore. Sep 24 16:09:44 Use the APIs? Sep 24 16:09:59 Like sysfs? Sep 24 16:10:03 For trivial stuff you don't even need to write code, you can peek sysfs - yes Sep 24 16:10:44 Otherwise there's a kernel interface for gpio, spi, et. al. Sep 24 16:14:55 How is that kernel interface named? Sep 24 16:34:14 ioctl Sep 24 16:36:42 could need some (native) english speakers opinion on an option label Sep 24 16:37:11 "Use DHCP advertised NTP servers" - does this make sense? Sep 24 16:37:18 is this legal grammar? Sep 24 16:38:18 I find it nonoffensive but I am not quite a grammar nazi Sep 24 16:39:20 You could try.. "Use NTP servers offered by DHCP" Sep 24 16:39:34 yeah, thats probably simpler and clearer Sep 24 16:41:44 thanks! Sep 24 16:41:53 np Sep 24 17:21:52 jow: Offered is an incorrect connotation as it implies you take ownership (someone gives something to you. Advertised is more accurate (someone tells you something). Sep 24 17:23:36 Offered makes sense regarding the IP address /offered/ by the DHCP server because the client can accept or reject it and if it accepts it then that IP now belongs to it. You never take ownership of the NTP server; you either use the information or you don'.t Sep 24 17:25:12 I need it a little bit short. Would "Use DHCP advertised servers" (in the context of NTP config) work? Sep 24 17:25:16 *shorter Sep 24 17:25:35 Yeah Sep 24 17:27:05 Anyone familiar with the hotplug process/scripts? Sep 24 17:27:05 I need to configure a wwan device as raw_ip as the iface is already up by the time the qmi script gets around to checking (so it fails). Sep 24 17:27:05 I can't quite figure out where to sneak this in (e.g. echo Y > .../raw_ip) Sep 24 17:29:29 maybe /etc/hotplug.d/usb/ (ACTION=add plus vid/pid match) Sep 24 17:29:46 or /etc/hotplug.d/net/ (ACTION=add plus netdev match) Sep 24 17:42:12 USB add is too soon the raw_ip node doesn't exist yet Sep 24 17:42:22 I need a pre-up hook Sep 24 18:23:53 jow: On net add appears to work, ty Sep 24 20:22:21 jow: how would you do the post build signing? currently it's done in append-metadata Sep 24 21:50:33 4.14 is still available for ath79 Sep 24 21:50:35 good Sep 24 21:51:04 hrm what's with all these kernel CVEs Sep 24 21:53:44 it's a hint, that you should switch to BSD :p Sep 24 21:54:06 mostly marvell wifi driver. Sep 24 21:54:10 * mangix doesn;t care Sep 24 21:54:35 poor xback Sep 24 21:56:17 don't care about BSD that is Sep 24 23:25:13 build #365 of x86/geode is complete: Success [build successful] Build details are at http://release-builds.lede-project.org/17.01/images/builders/x86%2Fgeode/builds/365 **** ENDING LOGGING AT Wed Sep 25 02:59:57 2019