**** BEGIN LOGGING AT Thu Jan 16 02:59:59 2020
Jan 16 05:52:41 <blogic> xdarklight: i agree
Jan 16 05:53:05 <blogic> and looking at  v5.4 large parts of the target patches will get removed
Jan 16 05:53:14 <blogic> but base patches need to be reduced further
Jan 16 07:06:42 <ds_shadof> wow https://github.com/vschagen/mtk-eip93
Jan 16 07:32:33 <ynezz> ds_shadof: nice, there is even PRNG, seems like the development has stalled
Jan 16 07:41:50 <ds_shadof> ynezz, anyway this is better then nothing
Jan 16 08:37:11 <Pepe> mangix:  modemmanager, etc
Jan 16 09:32:26 <mangix> modemmanager was approved by the maintainer. It's their problem if it doesn't work, not mine.
Jan 16 09:32:47 * karlp laughs
Jan 16 10:07:50 <ynezz> no revert? :p
Jan 16 11:34:58 <owrt-snap-builds> build #192 of layerscape/armv7 is complete: Failure [failed updatefeeds]  Build details are at http://buildbot.openwrt.org/master/images/builders/layerscape%2Farmv7/builds/192  blamelist: Maxim Storchak <m.storchak@gmail.com>, Jeff Kletsky <git-commits@allycomm.com>, Tomasz Maciej Nowak <tomek_n@o2.pl>, John Crispin <john@phrozen.org>, Florian Eckert
Jan 16 11:34:58 <owrt-snap-builds> <fe@dev.tdt.de>, Thomas Nixon <tom@tomn.co.uk>, David Lam <david@thedavid.net>, Aleksander Jan Bajkowski <A.Bajkowski@stud.elka.pw.edu.pl>, Linus Walleij <linus.walleij@linaro.org>, Daniel Golle <daniel@makrotopia.org>, Johann Neuhauser <johann@it-neuhauser.de>, Andrea Dalla Costa <andrea@dallacosta.me>, Adrian Schmutzler <freifunk@adrianschmutzler.de>,
Jan 16 11:34:58 <owrt-snap-builds> Rosen Penev <rosenp@gmail.com>, Michal Cieslakiewicz <michal.cieslakiewicz@wp.pl>, Eneas U de Queiroz <cotequeiroz@gmail.com>, Kyle Copperfield <kmcopper@danwin1210.me>, David Bauer <mail@david-bauer.net>
Jan 16 11:35:09 <Pepe> mangix:  and then it is ours because it does not work. I still dont like this approach.
Jan 16 11:35:21 <owrt-snap-builds> build #262 of ipq806x/generic is complete: Failure [failed updatefeeds]  Build details are at http://buildbot.openwrt.org/master/images/builders/ipq806x%2Fgeneric/builds/262  blamelist: Maxim Storchak <m.storchak@gmail.com>, Jeff Kletsky <git-commits@allycomm.com>, Tomasz Maciej Nowak <tomek_n@o2.pl>, John Crispin <john@phrozen.org>, Florian Eckert
Jan 16 11:35:21 <owrt-snap-builds> <fe@dev.tdt.de>, Thomas Nixon <tom@tomn.co.uk>, David Lam <david@thedavid.net>, Aleksander Jan Bajkowski <A.Bajkowski@stud.elka.pw.edu.pl>, Linus Walleij <linus.walleij@linaro.org>, Daniel Golle <daniel@makrotopia.org>, Johann Neuhauser <johann@it-neuhauser.de>, Andrea Dalla Costa <andrea@dallacosta.me>, Adrian Schmutzler <freifunk@adrianschmutzler.de>,
Jan 16 11:35:21 <owrt-snap-builds> Rosen Penev <rosenp@gmail.com>, Michal Cieslakiewicz <michal.cieslakiewicz@wp.pl>, Eneas U de Queiroz <cotequeiroz@gmail.com>, Kyle Copperfield <kmcopper@danwin1210.me>, David Bauer <mail@david-bauer.net>
Jan 16 12:15:48 <adrianschmutzler> There are no squashfs images for ath79/tiny
Jan 16 12:16:15 <adrianschmutzler> normally this can be fixed by "make clean" before building tiny, I assume the buildbot does not do that?
Jan 16 12:16:39 <adrianschmutzler> for 19.07.0
Jan 16 12:17:32 <adrianschmutzler> and for ar71xx/tiny there are almost no devices available at all for 19.07.0.
Jan 16 12:18:59 <jow> adrianschmutzler: each build is made from scratch
Jan 16 12:19:08 <jow> (git clean -f -d x; rm -r bin)
Jan 16 12:19:46 <adrianschmutzler> okay, do the release builds include luci? maybe it's too big then, as I typically only did without myself ...
Jan 16 12:19:54 <jow> yes they do
Jan 16 12:20:40 <mangix> Pepe: to be fair, the guys doing the modemmanager stuff are responsive.
Jan 16 12:20:47 <adrianschmutzler> okay, that may be an explanation as well. I will have a look into it.
Jan 16 12:21:50 <adrianschmutzler> what's the precise config for release buildbot images?
Jan 16 12:21:59 <zorun> that's actually fortunate, because the switch driver is buggy in ath79
Jan 16 12:22:11 <zorun> so better stick to 18.06 on these devices anyway
Jan 16 12:22:20 <zorun> https://bugs.openwrt.org/index.php?do=details&task_id=2216 and https://bugs.openwrt.org/index.php?do=details&task_id=2730
Jan 16 12:22:39 <adrianschmutzler> zorun: The bug report is where I learned about the missing images :-)
Jan 16 12:22:42 <zorun> ah :)
Jan 16 12:23:27 <adrianschmutzler> but if those aren't built in general, we will still have to deal with it at some point (i.e. either don't build images anymore or remove something from the recipe)
Jan 16 12:23:33 <zorun> it's also been spotted by tmomas's script: https://openwrt.org/toh/tp-link/tl-wr841nd#installation
Jan 16 12:23:40 <zorun> I think it parses the download server to look for the files
Jan 16 12:23:47 <zorun> yes
Jan 16 12:24:08 <mangix> I'm guessing this upstram first methodology is why the MOX is not supported yet :)
Jan 16 12:24:40 <mangix> Then again, the mainline ag71xx is not suitable for OpenWrt.
Jan 16 12:28:53 <ynezz> mangix: who is up or down depends on the point of view
Jan 16 12:28:56 <ynezz> :)
Jan 16 12:49:23 <PaulFertser> fwiw, my ath79/tiny looks stable wrt wan ethernet link
Jan 16 14:27:09 <owrt-snap-builds> build #252 of pistachio/generic is complete: Success [build successful]  Build details are at http://buildbot.openwrt.org/master/images/builders/pistachio%2Fgeneric/builds/252
Jan 16 14:56:24 <owrt-snap-builds> build #244 of ath79/nand is complete: Success [build successful]  Build details are at http://buildbot.openwrt.org/master/images/builders/ath79%2Fnand/builds/244
Jan 16 15:02:22 <stintel> OT but does anybody know how the kernel command line option irqaffinity is supposed to work? according to documentation it takes a list like 0-19,40-59, but it seems to completely ignore this
Jan 16 15:02:31 <stintel> losing my mind here on this
Jan 16 15:03:46 <stintel> I also tried 0xfffff00000fffff00000 or 0x00000fffff00000fffff but keeps stubbornly assigning IRQs to CPUs 60-79
Jan 16 15:04:28 <stintel> even tried with acpi_irq_nobalance
Jan 16 15:05:25 <stintel> CPUs 60-79 are frequently at 100% CPU because I pinned some process there, I do not want them to handle IRQs at all
Jan 16 15:05:50 <stintel> the cpubalance daemon also does not work at all
Jan 16 15:05:54 <stintel> ehr irqbalance*
Jan 16 15:09:17 <owrt-snap-builds> build #245 of tegra/generic is complete: Success [build successful]  Build details are at http://buildbot.openwrt.org/master/images/builders/tegra%2Fgeneric/builds/245
Jan 16 15:21:06 <owrt-snap-builds> build #242 of apm821xx/sata is complete: Success [build successful]  Build details are at http://buildbot.openwrt.org/master/images/builders/apm821xx%2Fsata/builds/242
Jan 16 15:28:46 <owrt-snap-builds> build #240 of at91/sama5 is complete: Success [build successful]  Build details are at http://buildbot.openwrt.org/master/images/builders/at91%2Fsama5/builds/240
Jan 16 15:36:30 <karlp> jow: I'm having trouble with translations on a js style cbi view replacement:   s = m.section(form.TypedSection, "mrelay", _("Configuration"));
Jan 16 15:36:32 <karlp>   s.tab("general", _("General Settings"));
Jan 16 15:36:34 <karlp> gak
Jan 16 15:36:42 <karlp> https://zerobin.net/?d225cabb88029ea9#GO1D6Kp3499AvjdvVENHoj+avVNktbayxfvIDMQ8iUo=
Jan 16 15:37:02 <karlp> all the translations on the page work except a multiline string for the Map itself.
Jan 16 15:37:34 <jow> thats probably because the string scanner collapses the whitespaces while the JS engine doesn't
Jan 16 15:37:47 <karlp> with lua cbis, having m = Map("uciname", translate("title"), translate([[long multiline string]]) worked ok.
Jan 16 15:37:55 <karlp> ah. yes. so the msgid scannign fails then.
Jan 16 15:38:21 <jow> iirc JS multiline strings aren't really standardized either
Jan 16 15:38:54 <karlp> yeah, it's a ncie place to put some html help/description of the cbi options though.
Jan 16 15:39:14 <jow> can you replace that failing _() with console.log() and see how the resulting string looks like exactly?
Jan 16 15:39:26 <jow> I guess it has a bunch of embedded ...\n\t...
Jan 16 15:39:47 <karlp> I can try, it doesn't _fail_ per se, it just doesn't load anything, and I was having a hard time finding in the js runtime where it was trying to load them from
Jan 16 15:40:59 <jow> the JS engine will hash the input string and look it up against a JSON dictionary
Jan 16 15:41:05 <jow> the dictionary is at /cgi-bin/luci/admin/translations/en
Jan 16 15:41:12 <jow> or wahtever lc code applies
Jan 16 15:41:19 <karlp> looks like it, yes, https://imgur.com/a/2iUsyuA
Jan 16 15:42:04 <karlp> I'd tried using a var desc = "line one" + "line two" style (on multiple lines) which seemed to be another way of doing multiline strings, but that didn't work well either.
Jan 16 15:42:43 <jow> right, that fails for the scanner I guess
Jan 16 15:42:58 <jow> it is too dumb to concat string literals
Jan 16 15:43:00 <karlp> with a _(varname) too, but it was same behaviour as far as I could tell.
Jan 16 15:43:22 <karlp> the msgid's in the po files look ~same they break it into multi line stuff there.
Jan 16 15:43:23 <jow> the scanner only recognized literal `_("...")` expressions
Jan 16 15:44:51 <karlp> the admin/translations/en is very small.
Jan 16 15:45:04 <karlp> admin/translations/no (the one I'm testing with) is much bigger?
Jan 16 15:46:10 <jow> yeah, /en skips almost all strings since input=output
Jan 16 15:46:12 <karlp> this is in our implementation of the scanner in js, which is ~akin to build/i18n-scan.pl, and xgettext, but for javascript?
Jan 16 15:46:25 <jow> correct
Jan 16 15:46:25 <karlp> which is.. "less featureful"? :)
Jan 16 15:46:43 <karlp> where is it?  I can have a bit of a look tomorrow, but I'm out of time today.
Jan 16 15:46:47 <jow> need to revisist xgettext eventually
Jan 16 15:47:12 <karlp> well, we need this at runtime right?
Jan 16 15:47:19 <karlp> or no, I guess this can be prebuilt?
Jan 16 15:47:20 <jow> no
Jan 16 15:47:46 <jow> well, I think our dialog got out of sync :P
Jan 16 15:47:52 <jow> what do we need at runtime exactly?
Jan 16 15:49:00 <jow> there's two parts involved. At compile time, a script reads all .po files, extracts the msgid strings, hashes them and puts their msgstr counterpart into the string table, keyed by hash
Jan 16 15:49:36 <jow> At runtime, there's a .js implementation of the same hashing algortihm which takes _()'s input, calculates ithe hash value, and looks it up in the string table
Jan 16 15:50:15 <jow> if runtime input to _() does not match compile time msgid, the translation fails
Jan 16 15:50:41 <jow> this happens whenever build-i18n-scan.pl and the runtime (Lua or JS) treat the literal string input differently
Jan 16 15:52:53 <jow> I think I found the issue however
Jan 16 15:54:07 <jow> https://github.com/openwrt/luci/blob/master/modules/luci-base/src/template_lmo.c#L72
Jan 16 15:54:23 <jow> the Lua runtime hashes strings and coalesces whitespace in the process
Jan 16 15:54:56 <jow> the JS one not: https://github.com/openwrt/luci/blob/master/modules/luci-base/htdocs/luci-static/resources/cbi.js#L26
Jan 16 15:55:43 <jow> the `var desc = _("this will not be translated either");` exmaple from your paste is a different reason most likely. I suppose it is executed too early, before the string table JSON has been loaded
Jan 16 15:57:01 <jow> will take care of fixing the whitespace coalescing in JS to make it behave like the Lua environment
Jan 16 15:57:33 <owrt-snap-builds> build #233 of mpc85xx/generic is complete: Success [build successful]  Build details are at http://buildbot.openwrt.org/master/images/builders/mpc85xx%2Fgeneric/builds/233
Jan 16 16:11:39 <jow> karlp: this should fix your issue: http://sprunge.us/XlStUO
Jan 16 16:51:29 <cotequeiroz> jow: in view of yesterday's openssl-cryptodev issue, I'm wondering if we should add the alternate afalg engine to 19.07 in the packages feed as a workaround.  The original AFALG engine depends on kernel AIO support, so it is not built by the bots.  What do you think?
Jan 16 16:59:11 <jow> cotequeiroz: I do not know what the alternative afalg engine is
Jan 16 16:59:29 <jow> but if it is proven to work in master I see no reason to backport it
Jan 16 17:01:32 <cotequeiroz> It's a rewrite of the devcrypto engine, using the AF_ALG interface instead of /dev/crypto.  It would allow hw-crypto access in 19.07.0 straight from opkg.  I take you see no reason _not_ to backport it, right?
Jan 16 17:02:19 <jow> yes, correct
Jan 16 17:02:29 <jow> given that the backport is trivial and isolated enough
Jan 16 17:03:35 <cotequeiroz> You could install it in 19.07, straight from master by using opkg with a "snapshot" URL.  I've tried that.
Jan 16 17:05:47 <cotequeiroz> Thanks for the input.  I'll open a PR in the packages feed.
Jan 16 17:49:35 <FinboySlick> No rush, but is anyone here in charge of openwrt-devel mailing list?  Subscribed twice now and it doesn't seem to send me anything.  Not seeing any rejected attempts on my mail server either so I'm at a bit of a loss.
Jan 16 17:50:20 <DonkeyHotei> FinboySlick: that would be dwmw2_gone
Jan 16 17:50:51 <DonkeyHotei> well, he runs the server it's on, anyway
Jan 16 17:51:52 <FinboySlick> DonkeyHotei: Thanks.  We'll see if he notices.  Like I said it's nothing urgent, it just nags me not to know what's not working.
Jan 16 17:52:30 <FinboySlick> (and it may point out some sort of sneaky problem on my end)
Jan 16 17:56:12 <DonkeyHotei> FinboySlick: if you were subscribed to the old list, you may have been autosubscribed to the new one. last post of yours i see on openwrt-devel via Gmane is from May 2015
Jan 16 17:58:31 <FinboySlick> 2018-05-05 seems to be the last thing I got that was posted to openwrt-devel  Did anything happen around that time?
Jan 16 17:58:39 <Borromini> FinboySlick: nothing in spam either, just to be sure?
Jan 16 17:59:14 <FinboySlick> No.  I actually don't filter spam because I diligently submit all of it to spamcop.
Jan 16 18:21:22 <owrt-snap-builds> build #233 of layerscape/armv8_64b is complete: Success [build successful]  Build details are at http://buildbot.openwrt.org/master/images/builders/layerscape%2Farmv8_64b/builds/233
Jan 16 18:37:59 <dwmw2_gone> FinboySlick: what email address?
Jan 16 18:38:56 <FinboySlick> dwmw2_gone: jonathan@navigue.com
Jan 16 18:39:38 <dwmw2_gone> when?
Jan 16 18:40:19 <FinboySlick> Well, I've been subscribed for years but last message I got was 2018-05-05.  I made an attempt to re-enlist um...  Let me look it up.
Jan 16 18:40:40 <FinboySlick> 2020-01-03
Jan 16 18:40:54 <dwmw2_gone> 2020-01-03 20:10:05 +0000 1inTGi-0000Sl-3g => jonathan@navigue.com R=lookuphost T=verp_smtp H=mail.navigue.com [74.117.40.3] X=TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256 CV=yes C="250 2.0.0 Ok: queued as 94EB51400A5"
Jan 16 18:41:38 <FinboySlick> Yes, that would be the register confirmation.
Jan 16 18:41:48 <dwmw2_gone> you got that?
Jan 16 18:42:03 <FinboySlick> Yes.  Just nothing else.  Has the list really been this quiet?
Jan 16 18:42:39 <dwmw2_gone> http://lists.infradead.org/pipermail/openwrt-devel/2020-January/thread.html
Jan 16 18:43:16 <Borromini> to the contrary, pretty verbose i'd say
Jan 16 18:44:51 <dwmw2_gone> hm, the owner address for the list is wrong
Jan 16 18:44:54 <dwmw2_gone> who should be the list owner?
Jan 16 18:48:24 <dwmw2_gone> ah no, it does go to the right addresses
Jan 16 18:48:38 <dwmw2_gone> who might have the mailman mail about you being unsubscribed, if that happened. But I don't see why.
Jan 16 18:49:22 * dwmw2_gone force-subscribes
Jan 16 18:51:44 <FinboySlick> I'll attempt another subscription myself.  Maybe I got distracted mid-click on the confirmation link or somesuch.
Jan 16 18:56:58 <FinboySlick> Mailman says I'm already subscribed...
Jan 16 19:16:35 <jow> FinboySlick: maybe you somehow changed your subscription settings to only receive digests or so?
Jan 16 19:18:34 <FinboySlick> jow: I doubt it, but assuming so, I wold have received some of those since 2018.
Jan 16 19:18:35 <DonkeyHotei> mine is set to nomail, and i was using Gmane to access instead, but that may not be working atm
Jan 16 20:28:38 <blogic> narf, brcmfmac is a nugget
Jan 16 20:29:02 <blogic> ... obscenities omitted ...
Jan 16 20:29:24 <blogic> i think i'll need to spent a couple of days on it next week
Jan 16 20:29:30 <blogic> *spend
Jan 16 21:15:39 <ldir> hmmm, luci realtime graphs not working for me.  anyone else?
Jan 16 21:16:34 <Slimey> frmo master?
Jan 16 21:16:49 <ldir> yep
Jan 16 21:16:56 * karlp just always found it caused too much cpu load and never used it.
Jan 16 21:17:01 <Slimey> the luci stats package?
Jan 16 21:17:18 <ldir> Slimey: yep
Jan 16 21:17:38 * ldir has x86 cycles to spare
Jan 16 21:17:59 <DonkeyHotei> the history display was completely broken on the 18.06 branch so it was one of the first things i checked on 19.07
Jan 16 21:18:34 <DonkeyHotei> in the bandwidth monitor
Jan 16 21:19:00 <DonkeyHotei> i can now see the past history
Jan 16 21:19:46 <Slimey> ldir where can you find Mini PCIe (oversized) to desktop pcie adapter?
Jan 16 21:20:13 <ldir> I have no idea!
Jan 16 21:20:20 <Slimey> :P
Jan 16 21:20:26 <Slimey> i have no success either
Jan 16 21:21:43 <ldir> I have APU 2 as router only.  The RF is done by access points (that don't route)
Jan 16 21:21:59 <ldir> the switching is done by... a switch
Jan 16 21:22:35 <DonkeyHotei> putting a mini pcie card in a desktop shouldn't be that hard
Jan 16 21:23:09 <Slimey> i have two nice minipci cards i want to use from the broken 3040 i scavenged parts off of
Jan 16 21:23:48 <DonkeyHotei> ath9k?
Jan 16 21:23:57 <Slimey> students flooded the room above and the water flowed down to the other floor and killed it
Jan 16 21:23:59 * ldir notes jow is pushing luci updates like there is no tomorrow :-)
Jan 16 21:24:36 <Slimey> DonkeyHotei both are ath10k QCA9984 4x4:4 ac wave2
Jan 16 21:24:39 <DonkeyHotei> well, there was obviously a tomorrow yesterday :)
Jan 16 21:25:27 <jow> ldir: works here, but maybe check your browser console for errors. Need to run now but will check tomorrow
Jan 16 21:25:42 <ldir> 'k
Jan 16 21:28:01 <ldir> eeuurgh https://paste.ubuntu.com/p/th8n8xTpvT/
Jan 16 21:29:02 <Slimey> https://imgur.com/zqKcWMD
Jan 16 21:29:47 <Slimey> ill have to retake picture since i found the better camera where you can actually see shit
Jan 16 21:42:43 <stintel> looks like px5g-standalone does not build with CONFIG_PKG_ASLR_PIE_ALL=y
Jan 16 21:42:58 <stintel> PKG_ASLR_PIE:=0 the way to go to fix this?
Jan 16 21:51:54 <Slimey> https://imgur.com/TEStWWb
Jan 16 21:52:33 <stintel> mangix: libcxx is broken on x86/64: cp: cannot stat '/home/stijn/Development/LEDE/source/build_dir/target-x86_64_musl/libcxx-9.0.1/ipkg-install/usr/lib/libc++.so.*': No such file or directory
Jan 16 21:52:42 <stintel> the file is in ipkg-install/usr/lib64/.. instead
Jan 16 21:53:06 <stintel> it also seems to pick up host llvm-config: -- Found LLVM_CONFIG_PATH as /usr/lib/llvm/9/bin/llvm-config
Jan 16 21:54:17 <stintel> may I kindly request your start testing your changes with x86/64 target because there is constant breakage of random things due to your changes
Jan 16 22:08:19 <stintel> I'll push a fix for the lib64 problem
Jan 16 22:13:45 <stintel> on to the next broken pkg: libftdi1
Jan 16 22:31:40 <mangix> stintel: that LLVM_CONFIG_PATH thing sounds like an issue. I do not have it installed locally. that lib64 thing also sound bizarre
Jan 16 22:32:01 <mangix> that's normally a problem with host libraries
Jan 16 22:32:37 <mangix> I guess for x86_64, this fix is needed: https://github.com/openwrt/openwrt/commit/383abffb1179a142b4c8f86559baad5b24d391c3#diff-b8fe9644fece5f3d2571488768a6a307
Jan 16 22:33:23 <mangix> for the target options that is
Jan 16 22:34:59 <stintel> mangix: I'm on HEAD
Jan 16 22:35:07 <stintel> mangix: but I have a fix in my staging tree
Jan 16 22:35:17 <stintel> mangix: an ack would be nice
Jan 16 22:35:44 <stintel> mangix: https://git.openwrt.org/8b22d3ae
Jan 16 22:36:18 <stintel> maybe we should force LLVM_CONFIG_PATH="" too
Jan 16 22:36:25 <stintel> as we don't have llvm in OpenWrt
Jan 16 22:40:58 <mangix> correct
Jan 16 22:41:14 <mangix> ACK on that patch
Jan 16 22:41:20 <stintel> mangix: thanks
Jan 16 22:41:51 <mangix> libcxx also fails on i386 and powerpc
Jan 16 22:42:00 <mangix> I have no idea how to fix those
Jan 16 22:42:19 <stintel> mangix: powerpc target I assume?
Jan 16 22:42:29 <mangix> the issue is that GCC must be used for linking instead of LD. I haven't been able to figure out how to override
Jan 16 22:42:42 <mangix> yes
Jan 16 22:44:04 <stintel> derp. lxc breaks with new libseccomp :(
Jan 16 22:44:40 <mangix> it's not lxc that's broken. it's linseccomp
Jan 16 22:44:47 <mangix> *lib
Jan 16 22:45:04 <mangix> an extra header file needs to be copied to InstallDev
Jan 16 22:45:11 <stintel> mangix: already done that
Jan 16 22:45:42 <stintel> https://gist.github.com/4811e874a746004f32a327c72eae0384
Jan 16 22:45:43 <mangix> someone who shall remain nameless did not do test this properly.
Jan 16 22:46:02 <mangix> oh
Jan 16 22:46:05 <mangix> that is different
Jan 16 22:46:28 <stintel> yeah, that's after I installed seccomp-syscalls.h
Jan 16 22:47:00 <stintel> mangix: https://github.com/stintel/openwrt-packages/commit/9f57ab2fa8d50d5f9aa5494bef9ea350dc4df5de
Jan 16 22:47:17 <stintel> mangix: did you see other breakage because of this?
Jan 16 22:47:33 <mangix> ACK. Make sure to bump PKG_RELEASE.
Jan 16 22:48:19 <mangix> only lxc seems to really use libseccomp
Jan 16 22:48:27 <stintel> mangix: if the seccomp-syscalls.h I'm going to rewrite the commit message
Jan 16 22:48:28 <stintel> checking now
Jan 16 22:48:39 <stintel> if the seccomp-syscalls.h is new since version bump*
Jan 16 22:48:45 <mangix> Yes it is
Jan 16 22:48:58 <mangix> Added november IIRC
Jan 16 22:54:27 <stintel> mangix: while at it, care to review https://github.com/stintel/openwrt-packages/commit/ba1f3b7b5a1c5b844de7d522bd04396e84c21367 ?
Jan 16 22:54:56 <mangix> wow. ACK.
Jan 16 22:55:06 <stintel> thanks
Jan 16 22:55:21 <mangix> I don't have too much installed locally, so I don't run into these.
Jan 16 22:55:54 <stintel> I have a shitload of stuff installed locally :P
Jan 16 22:56:29 <stintel> if my strongswan bump pulls I'm going to push to packages feed with that and libseccomp fix
Jan 16 22:56:47 <stintel> does that DOCUMENTATION=OFF require a PKG_RELEASE bump?
Jan 16 22:56:53 <stintel> if it didn't build before it will build now
Jan 16 22:56:53 <olmari> I'll just lurk here and see when it's safe to press compile (like it ever ;))
Jan 16 22:56:59 <stintel> the package itself doesn't change, so I guess no
Jan 16 22:57:06 <mangix> it does not change, no
Jan 16 22:57:22 <stintel> great
Jan 16 22:57:36 <stintel> now fingers crossed I don't run into more breakage :P
Jan 16 22:57:51 <stintel> ah right, lxc
Jan 16 22:58:03 <stintel> let's ping maintainer again for 3.* bump
Jan 16 22:59:45 <mangix> the turris people I believe have a 3.x bump.
Jan 16 22:59:46 <stintel> hmmm where are the packages feed build logs
Jan 16 22:59:49 <stintel> yeah they do
Jan 16 22:59:58 <stintel> and the maintainer in packages feed is the same guy afaik
Jan 16 23:00:44 <mangix> nah marko is unaffiliated AFAIK
Jan 16 23:01:12 <stintel> hmmm
Jan 16 23:01:34 <stintel> libseccomp and libftdi1 fixes pushed to packages feed
Jan 16 23:01:44 <stintel> I might call it a day though
Jan 16 23:03:01 <stintel> libcxx fix also pushed
**** ENDING LOGGING AT Fri Jan 17 02:59:57 2020