**** BEGIN LOGGING AT Sat Feb 09 02:59:57 2019 Feb 09 06:46:15 karlp: time: package/firmware/linux-firmware/compile#0.44#0.15#8.76 Feb 09 06:46:55 karlp: that's 2nd run on fresh Fedora 28 installed box Feb 09 08:03:38 strace shows thousands of PIDs being created. Feb 09 08:12:51 304meg of strace just for make package/firmare/linux-firmware/clean .... Feb 09 08:13:05 that _can't_ be normal :) Feb 09 08:14:21 only 65meg on the vm Feb 09 08:20:26 about the same number of "long" syscalls, 10~ and none longer than 0.3 secs, so it's all made up in just a sea of short ones then. yay Feb 09 08:23:58 BTW, why don't you create vm with fresh fedora 28 to test it? Feb 09 08:24:17 est what variable? Feb 09 08:24:36 given I'm not the only one reporting issues, I'm not sure it's a vm vs not vm issue. Feb 09 08:24:52 and I've had pretty crap times on fedora for years, and thought that was just "how it was" Feb 09 08:25:36 but I've just finished testing for you on fresh fedora 28 box on scaleway and I can't reproduce it Feb 09 08:25:45 same config, same steps, different times Feb 09 08:26:17 so try fed29 like me? Feb 09 08:26:30 ah, I've thought, that you're on 28 Feb 09 08:28:06 check out this difference in strace otuput though, it's massive: https://hastebin.com/foxapofede.pl Feb 09 08:30:10 well, I've no time for this, I'm willing to spend more time on it once I'm able to reproduce it by myself Feb 09 08:30:59 since there's no image for fedora29 on scaleway, I'll need to prepare dockerfile and try to reproduce it Feb 09 08:31:11 yeah, no problem, thanks for trying. Feb 09 08:31:31 I can try a fed29 image in a vm too, see if that is relevant. Feb 09 08:31:42 but I'm not really rich on time for this sort of thing either Feb 09 08:32:49 there's https://github.com/rocky/remake/ Feb 09 08:33:44 so then you can run `remake --trace=command package/firmware/linux-firmware/clean V=sc -j1` to get more insight into the build steps Feb 09 08:34:20 hrm, that might be interesting indeed. Feb 09 08:34:32 this is probably what I would use once I would be able to reproduce it localy Feb 09 08:36:13 one can probably get similar output from `make -d` but it's harder to parse Feb 09 08:36:36 yeah, I've had enough of a hhard time with makefile -d before, this looks nicer for first go :) Feb 09 08:42:14 aaaand it doesn't build properly because of autotools incompatibilities. hooray :) Feb 09 09:33:08 karlp: CMake needs to be more widespread so we can have CMake incompatibilities :P Feb 09 10:15:28 serious? we alrady have cmake incompatibilities Feb 09 10:16:00 got it installed, but nothing conclusive yet. Feb 09 14:09:06 ldir: jow: I just noticed, the opkg on my router refuses to upgrade dnsmasq from the repos because (according to compare_versions) 2.80test3 > 2.80, so it thinks a newer version is already installed Feb 09 14:21:16 KanjiMonster: I have no idea how opkg compare_versions works. Feb 09 14:22:15 Time to find out? :) Feb 09 14:34:20 ldir: looked at the code, and up to "2.80" they are treated as equal, then 't' is treated as higher than '\0', so 2.80test2 results in > than 2.80 Feb 09 14:42:18 Monkeh: not whilst I'm on air and busy it isn't Feb 09 14:45:24 :D Feb 09 14:49:48 I don't know about opkg, but with dpkg on Debian systems the right way to do that would be "2.80~test3" because it considers the tilde to be like a minus sign, so something like 2.80~test3 or 2.80~rc1 would be less than 2.80. Feb 09 14:50:23 The problem there is that ~test* is considered higher than ~rc* since t>r, which I ran into when I was packaging dnsmasq updates for my Ubuntu system. Feb 09 14:55:04 on ubuntu you could do 2.80~rc1~test3 Feb 09 14:58:46 on gentoo you'd use an underscore, looks better imo Feb 09 15:03:11 if underscore means "older than" then what character means "newer than" ? Feb 09 15:06:29 hmm, why would you even need that? Feb 09 15:08:17 because there can be patches added without a new version Feb 09 15:18:41 On Debian and derivatives, that would be 2.80-1, 2.80-2, etc. and for Ubuntu, they would tack an additional "ubuntu1", "ubuntu2", etc on top of the Debian number. Feb 09 17:30:10 maybe dnsmasq should just use better version numbers... Feb 09 17:32:40 but yeah, opkg compare-versions is busted. I thought I filed a ticket on it a year or two ago. Feb 09 17:34:14 https://hastebin.com/ocuwufahew.rb Feb 09 17:53:42 karlp: ">" means >=, you need to use ">>" for > Feb 09 17:55:28 karlp: dpkg behaves in the same way, so this isn't opkg's fault Feb 09 18:01:19 karlp: looks like they are deprecated and you aren't supposed to use them ;) -> https://www.debian.org/doc/debian-policy/ch-relationships.html#id10 Feb 09 18:07:34 so openwrt needs some kind of package naming convention, not necessarily more opkg logic... you don't need to name te package after the source tarball... problem solved ;) Feb 09 18:51:13 meh, framebuffer image viewers appear to be a major PITA to compile Feb 09 19:28:25 what the... Feb 09 19:28:28 opkg_install_pkg: Package size mismatch: xxd is 6010 bytes, expecting 6015 bytes Feb 09 19:28:41 that sounds like a bogus error Feb 09 20:20:43 KanjiMonster: that's not whhat the _help_ says, nor does it make any sense. Feb 09 20:20:53 I don't reallllly care what dpkg does, I care what opkg does :) Feb 09 20:21:15 karlp: it's what the "spec" says Feb 09 20:21:27 preserving that behaviour is moronic though. Feb 09 20:21:32 and the "spec" is "wrong" Feb 09 20:21:40 but sure, I get what you're saying :) Feb 09 20:21:50 opkg isn't dpkg anyway, can we jsut not fix it? Feb 09 20:22:03 either make them do what any rational person would expect or get rid of them? Feb 09 20:22:21 I mean, the help is "compare versions using <= < > >= = << >>" Feb 09 20:22:44 which to me is, "less than or equal" "less than" "greater than" "greatern than or equal" "equal" "don't know" "don't know" Feb 09 20:22:58 no matter how much debian might state somethign different. Feb 09 20:25:32 we could drop < and > from the help, but we should not modify the behaviour when parsing them Feb 09 20:26:13 that would already be an improvement. Feb 09 20:27:05 I'd personally suggest even warning on using them that "this shit might not realaly do what you think" Feb 09 20:27:21 debian be damned, preserving garbage "just because" is a terrible way to live Feb 09 20:28:24 changing the behaviour might/will change the behaviour when parsing the control files in .ipk files, no idea if this will then break something Feb 09 20:28:34 or have weird side effects Feb 09 20:33:21 yep. change is bad :) Feb 09 22:08:46 karlp: fedora 29 - time: package/firmware/linux-firmware/clean#1.20#1.99#3.14 and time: package/firmware/linux-firmware/compile#1.23#1.96#3.13 Feb 09 22:41:27 karlp: ubuntu 18.04 is ok as well, trying 16.04 Feb 09 23:11:37 karlp: To sum it up, I'm not able to reproduce what you're seeing on Fedora 28/29 and Ubuntu 14.04/16.04/18.04 Feb 10 00:01:07 Bah, looks like I need a better IRC client! Feb 10 02:41:08 Is there a way to probe for hardware on a booted image? I was porting to that eap225 AP, but I can't figure out how to get ethernet working. Feb 10 02:42:12 I tried also looking in the tp link source download, but it seems to be a very different build system, and I'm not versed well in this linux device code Feb 10 02:46:25 mvnetbiz: specs look somewhat similar to a porting effort of mine. feel free to look at it as a reference https://github.com/openwrt/openwrt/pull/1379 Feb 10 02:48:21 like what are these #defines are we bitbanging ethernet frames or is that just for configuring mac Feb 10 02:48:30 DonkeyHotei, thanks Feb 10 02:49:19 which line? Feb 10 02:50:29 example mach-eap120.c has #define EAP120_GPIO_SMI_MDIO and EAP120_GPIO_SMI_MDC Feb 10 02:51:26 are you porting to the ar71xx target, or the ath79 target? Feb 10 02:52:39 my file is target/linux/ar71xx/files/arch/mips/ath79/mach-eap225.c Feb 10 02:53:43 I have leds, reset button, wlan working I think, just not ethernet Feb 10 02:53:55 yeah, i submitted an ar71xx port for another device too: https://github.com/openwrt/openwrt/pull/1359 Feb 10 02:54:51 i'm told it's not likely to be merged because it's ar71xx Feb 10 02:56:45 mvnetbiz: Those two are for configuring realtek switch. Feb 10 02:57:38 but the eap225 has atheros ethernet, not realtek Feb 10 02:57:53 I don't get what the difference is, all the devices in ar71xx tree are in the ath79 directory? Feb 10 02:58:21 Is it just an updated build tree Feb 10 02:58:21 compare PR 1359 to PR 1379 Feb 10 02:58:26 ok Feb 10 02:58:43 one submits as ar71xx, the other as ath79 Feb 10 02:58:51 (but different devices) **** ENDING LOGGING AT Sun Feb 10 02:59:56 2019