* [Buildroot] [autobuild.buildroot.net] Build results for 2019-06-10 @ 2019-06-11 6:00 Thomas Petazzoni 2019-06-12 5:33 ` Sam Bobroff 0 siblings, 1 reply; 8+ messages in thread From: Thomas Petazzoni @ 2019-06-11 6:00 UTC (permalink / raw) To: buildroot Hello, Build statistics for 2019-06-10 =============================== branch | OK | NOK | TIM | TOT | 2019.02.x | 17 | 2 | 0 | 19 | 2019.05.x | 23 | 2 | 0 | 25 | master | 188 | 21 | 1 | 210 | Results for branch '2019.05.x' ============================== Classification of failures by reason ------------------------------------ kvm-unit-tests-kvm-unit-tes... | 1 openjdk-jdk-12+33 | 1 Detail of failures ------------------ x86_64 | kvm-unit-tests-kvm-unit-tes... | NOK | http://autobuild.buildroot.net/results/77d159d935ffc351bfc6e18d2a637803ecd8d573 | powerpc64 | openjdk-jdk-12+33 | NOK | http://autobuild.buildroot.net/results/6afebe3ff4221cd6cfc67af02b20f1fe05a299a8 | Results for branch 'master' =========================== Classification of failures by reason ------------------------------------ host-mender-artifact-3.0.0 | 5 libwebsock-3c1615eeadb0b582... | 3 vdr-plugin-vnsiserver-v1.8.0 | 2 cups-2.2.10 | 1 host-efl-1.22.2 | 1 host-mfgtools-v0.02 | 1 host-xapp_mkfontscale-1.1.3 | 1 libssh-0.8.7 | 1 mesa3d-19.0.6 | 1 mimic | 1 mimic-1.1.0 | 1 network-manager-1.18.0 | 1 poppler-0.77.0 | 1 udpxy-1.0.23-9-prod | 1 wireshark-3.0.2 | 1 Detail of failures ------------------ powerpc64le | cups-2.2.10 | NOK | http://autobuild.buildroot.net/results/c4e0f6a3c79c9cb083a08f811b7d4838efef50f9 | arm | host-efl-1.22.2 | NOK | http://autobuild.buildroot.net/results/b4744a79697777b0d40c6e070ac5c1c95076271d | m68k | host-mender-artifact-3.0.0 | NOK | http://autobuild.buildroot.net/results/c82b10b6db02b2a87c45f41bd35bc0c5d5beddc6 | arm | host-mender-artifact-3.0.0 | NOK | http://autobuild.buildroot.net/results/0fc486fc037c697b7605f330aafc6a64dd2bc675 | i686 | host-mender-artifact-3.0.0 | NOK | http://autobuild.buildroot.net/results/1a62dba60f96275ea15471ee7f8588475b2ce5f9 | arm | host-mender-artifact-3.0.0 | NOK | http://autobuild.buildroot.net/results/f9ba64ab4c8d7fa6cb301fab37ee4141ba442f61 | m68k | host-mender-artifact-3.0.0 | NOK | http://autobuild.buildroot.net/results/71853edaac4d9ed2a29b579e4abf62a68691dbfb | arm | host-mfgtools-v0.02 | NOK | http://autobuild.buildroot.net/results/42644ede89ad15b2ebcc307a9121d5b647629978 | arm | host-xapp_mkfontscale-1.1.3 | NOK | http://autobuild.buildroot.net/results/b5ec2d2d17e64ca7b85ebd7e4d0d880eaa661170 | xtensa | libssh-0.8.7 | NOK | http://autobuild.buildroot.net/results/f03d4225b6c3a3ec8558f96a6a8c91c0318aa6bc | aarch64 | libwebsock-3c1615eeadb0b582... | NOK | http://autobuild.buildroot.net/results/bfbb6d3e31033cc598f2288bce8f1447e79f09b0 | aarch64 | libwebsock-3c1615eeadb0b582... | NOK | http://autobuild.buildroot.net/results/e2cbd9396caea7890996dd6b9e88e7236e46fd1a | riscv32 | libwebsock-3c1615eeadb0b582... | NOK | http://autobuild.buildroot.net/results/3bc54e2fdce307007b68f5323594666b15343d62 | sh4 | mesa3d-19.0.6 | NOK | http://autobuild.buildroot.net/results/1ea031c402f5416851e2a5467cee76f906a6be2a | or1k | mimic | TIM | http://autobuild.buildroot.net/results/751953b121670bb51e3f16f63a9223311f119b6e | powerpc | mimic-1.1.0 | NOK | http://autobuild.buildroot.net/results/0f0e7521f47cb92ea3ceab6af56a0618c4cf218a | nios2 | network-manager-1.18.0 | NOK | http://autobuild.buildroot.net/results/e47c7d855b452079a165ad4540b2e5ccd4162e19 | ORPH powerpc | poppler-0.77.0 | NOK | http://autobuild.buildroot.net/results/2c8695b75c3241359e739d88726430cbfe47a5bd | i686 | udpxy-1.0.23-9-prod | NOK | http://autobuild.buildroot.net/results/114adf08cd94473b59ff46819b27578466647e4a | riscv32 | vdr-plugin-vnsiserver-v1.8.0 | NOK | http://autobuild.buildroot.net/results/40268ca7d9ba32963de239923cd2ca18a0011b37 | arm | vdr-plugin-vnsiserver-v1.8.0 | NOK | http://autobuild.buildroot.net/results/de2e7db30aec888419c22dea08f4f769d9577afd | powerpc | wireshark-3.0.2 | NOK | http://autobuild.buildroot.net/results/1284723ae2886cfe05b8337d6cdd184ba1d7e5c7 | ORPH Results for branch '2019.02.x' ============================== Classification of failures by reason ------------------------------------ glm-0.9.8.4 | 2 Detail of failures ------------------ i686 | glm-0.9.8.4 | NOK | http://autobuild.buildroot.net/results/b01e79868cb2ec843adcf1f72662a23018eb1a0c | ORPH i686 | glm-0.9.8.4 | NOK | http://autobuild.buildroot.net/results/f02e8842bcae2fb69294def3fc29bd305cefe007 | ORPH -- http://autobuild.buildroot.net ^ permalink raw reply [flat|nested] 8+ messages in thread
* [Buildroot] [autobuild.buildroot.net] Build results for 2019-06-10 2019-06-11 6:00 [Buildroot] [autobuild.buildroot.net] Build results for 2019-06-10 Thomas Petazzoni @ 2019-06-12 5:33 ` Sam Bobroff 2019-06-12 6:49 ` Thomas Petazzoni 0 siblings, 1 reply; 8+ messages in thread From: Sam Bobroff @ 2019-06-12 5:33 UTC (permalink / raw) To: buildroot On Tue, Jun 11, 2019 at 06:00:42AM -0000, Thomas Petazzoni wrote: > Hello, [snip] > Detail of failures > ------------------ > > powerpc64le | cups-2.2.10 | NOK | http://autobuild.buildroot.net/results/c4e0f6a3c79c9cb083a08f811b7d4838efef50f9 | [snip] This failure building cups seems to be caused by an interaction between buildroot and the cups package: a) Buildroot setting the environment variable "GZIP" to "-n", and b) the cups package internally using a Make variable "GZIP" for the path to the gzip binary (i.e. "/bin/gzip"). So, when Make executes the rules for "install-data", the existance of GZIP in Make's environment causes it to export it's value of GZIP into the environment for the rules. Unfortunately for gzip, which is expecting to see command line arguments in $GZIP, it now sees it's own path as a command line option and the build fails with: gzip: /bin/gzip.gz: Permission denied I think the real fix should be in cups, because I *think* what all this means is that it's always a bad idea to use a Make variable called 'GZIP' and they should rename it there. It fails the same way on the master branch of cups so I've filed a bug report on their github issue tracker. However, it's easy to work around on the buildroot side with a hack in the package file: CUPS_MAKE_ENV = env -u GZIP ... but it does seem a bit cheeky to sneak a call to "env" in there. Is there a better way to remove a variable from make's environment? Should I post a patch for that fix, or a better one, for buildroot to use before upstream fixes it? (Assuming they do.) Cheers, Sam. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 488 bytes Desc: not available URL: <http://lists.busybox.net/pipermail/buildroot/attachments/20190612/028e8b72/attachment.asc> ^ permalink raw reply [flat|nested] 8+ messages in thread
* [Buildroot] [autobuild.buildroot.net] Build results for 2019-06-10 2019-06-12 5:33 ` Sam Bobroff @ 2019-06-12 6:49 ` Thomas Petazzoni 2019-06-12 7:02 ` Sam Bobroff 0 siblings, 1 reply; 8+ messages in thread From: Thomas Petazzoni @ 2019-06-12 6:49 UTC (permalink / raw) To: buildroot Hello Sam, First of all, thanks for the investigation. Adding Atharva, Arnout and Yann in Cc, since the issue is due to BR2_REPRODUCIBLE=y. On Wed, 12 Jun 2019 15:33:53 +1000 Sam Bobroff <sbobroff@linux.ibm.com> wrote: > > powerpc64le | cups-2.2.10 | NOK | http://autobuild.buildroot.net/results/c4e0f6a3c79c9cb083a08f811b7d4838efef50f9 | > > [snip] > > This failure building cups seems to be caused by an interaction between > buildroot and the cups package: > > a) Buildroot setting the environment variable "GZIP" to "-n", and > b) the cups package internally using a Make variable "GZIP" for the path to > the gzip binary (i.e. "/bin/gzip"). > > So, when Make executes the rules for "install-data", the existance of > GZIP in Make's environment causes it to export it's value of GZIP into > the environment for the rules. Unfortunately for gzip, which is > expecting to see command line arguments in $GZIP, it now sees it's own > path as a command line option and the build fails with: > > gzip: /bin/gzip.gz: Permission denied > > I think the real fix should be in cups, because I *think* what all this > means is that it's always a bad idea to use a Make variable called > 'GZIP' and they should rename it there. It fails the same way on the > master branch of cups so I've filed a bug report on their github issue > tracker. > > However, it's easy to work around on the buildroot side with a hack in > the package file: > CUPS_MAKE_ENV = env -u GZIP > ... but it does seem a bit cheeky to sneak a call to "env" in there. Is > there a better way to remove a variable from make's environment? Dropping the GZIP environment variable is maybe not going to work well either: the reason why GZIP = -n is because of BR2_REPRODUCIBLE=y. The -n option of gzip tells gzip to not store the file name and timestamp, which is necessary for reproducible builds. Of course, it all depends if the files that are being compressed by the cups build end up on the target. If they don't, we can live without the -n option. However, if they end up on the target, we really need to keep the -n option. Best regards, Thomas -- Thomas Petazzoni, CTO, Bootlin Embedded Linux and Kernel engineering https://bootlin.com ^ permalink raw reply [flat|nested] 8+ messages in thread
* [Buildroot] [autobuild.buildroot.net] Build results for 2019-06-10 2019-06-12 6:49 ` Thomas Petazzoni @ 2019-06-12 7:02 ` Sam Bobroff 2019-06-12 7:06 ` Thomas Petazzoni 0 siblings, 1 reply; 8+ messages in thread From: Sam Bobroff @ 2019-06-12 7:02 UTC (permalink / raw) To: buildroot On Wed, Jun 12, 2019 at 08:49:27AM +0200, Thomas Petazzoni wrote: > Hello Sam, > > First of all, thanks for the investigation. Adding Atharva, Arnout and > Yann in Cc, since the issue is due to BR2_REPRODUCIBLE=y. > > On Wed, 12 Jun 2019 15:33:53 +1000 > Sam Bobroff <sbobroff@linux.ibm.com> wrote: > > > > powerpc64le | cups-2.2.10 | NOK | http://autobuild.buildroot.net/results/c4e0f6a3c79c9cb083a08f811b7d4838efef50f9 | > > > > [snip] > > > > This failure building cups seems to be caused by an interaction between > > buildroot and the cups package: > > > > a) Buildroot setting the environment variable "GZIP" to "-n", and > > b) the cups package internally using a Make variable "GZIP" for the path to > > the gzip binary (i.e. "/bin/gzip"). > > > > So, when Make executes the rules for "install-data", the existance of > > GZIP in Make's environment causes it to export it's value of GZIP into > > the environment for the rules. Unfortunately for gzip, which is > > expecting to see command line arguments in $GZIP, it now sees it's own > > path as a command line option and the build fails with: > > > > gzip: /bin/gzip.gz: Permission denied > > > > I think the real fix should be in cups, because I *think* what all this > > means is that it's always a bad idea to use a Make variable called > > 'GZIP' and they should rename it there. It fails the same way on the > > master branch of cups so I've filed a bug report on their github issue > > tracker. > > > > However, it's easy to work around on the buildroot side with a hack in > > the package file: > > CUPS_MAKE_ENV = env -u GZIP > > ... but it does seem a bit cheeky to sneak a call to "env" in there. Is > > there a better way to remove a variable from make's environment? > > Dropping the GZIP environment variable is maybe not going to work well > either: the reason why GZIP = -n is because of BR2_REPRODUCIBLE=y. The > -n option of gzip tells gzip to not store the file name and timestamp, > which is necessary for reproducible builds. Of course, it all depends > if the files that are being compressed by the cups build end up on the > target. If they don't, we can live without the -n option. However, if > they end up on the target, we really need to keep the -n option. Ah, right. So that hack is no good, and it suggests that no hack on the buildroot side can work as long as GZIP is being overwritten by the package's build system. I'll have a go hacking the build system in cups to rename the GZIP variable but hopefully their upstream will fix it soon :-) At least some of the compressed files are part of some kind of test data, so I'll see if they're the only ones and could perhaps be left out entirely. > Best regards, > > Thomas > -- > Thomas Petazzoni, CTO, Bootlin > Embedded Linux and Kernel engineering > https://bootlin.com > -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 488 bytes Desc: not available URL: <http://lists.busybox.net/pipermail/buildroot/attachments/20190612/22a470e2/attachment.asc> ^ permalink raw reply [flat|nested] 8+ messages in thread
* [Buildroot] [autobuild.buildroot.net] Build results for 2019-06-10 2019-06-12 7:02 ` Sam Bobroff @ 2019-06-12 7:06 ` Thomas Petazzoni 2019-06-12 8:26 ` Arnout Vandecappelle 0 siblings, 1 reply; 8+ messages in thread From: Thomas Petazzoni @ 2019-06-12 7:06 UTC (permalink / raw) To: buildroot Hello, On Wed, 12 Jun 2019 17:02:01 +1000 Sam Bobroff <sbobroff@linux.ibm.com> wrote: > Ah, right. So that hack is no good, and it suggests that no hack on > the buildroot side can work as long as GZIP is being overwritten by the > package's build system. I'll have a go hacking the build system in cups > to rename the GZIP variable but hopefully their upstream will fix it > soon :-) > > At least some of the compressed files are part of some kind of test data, > so I'll see if they're the only ones and could perhaps be left out > entirely. Alternatively, Buildroot could use a gzip wrapper, installed in $(HOST_DIR)/bin to pass this -n option when BR2_REPRODUCIBLE=y. The gzip man page says that using the GZIP environment variable is "obsolescent": The obsolescent environment variable GZIP can hold a set of default options for gzip. These options are interpreted first and can be overwritten by explicit command line parameters. As this can cause problems when using scripts, this feature is supported only for options that are reasonably likely to not cause too much harm, and gzip warns if it is used. This fea? ture will be removed in a future release of gzip. You can use an alias or script instead. For example, if gzip is in the directory /usr/bin you can prepend $HOME/bin to your PATH and create an exe? cutable script $HOME/bin/gzip containing the following: #! /bin/sh export PATH=/usr/bin exec gzip -9 "$@" Of course, if we go in this direction, we have to take care of what happens if host-gzip is installed, as it would overwrite the wrapper. Best regards, Thomas -- Thomas Petazzoni, CTO, Bootlin Embedded Linux and Kernel engineering https://bootlin.com ^ permalink raw reply [flat|nested] 8+ messages in thread
* [Buildroot] [autobuild.buildroot.net] Build results for 2019-06-10 2019-06-12 7:06 ` Thomas Petazzoni @ 2019-06-12 8:26 ` Arnout Vandecappelle 2019-06-12 10:04 ` Atharva Lele 2019-06-12 15:35 ` Yann E. MORIN 0 siblings, 2 replies; 8+ messages in thread From: Arnout Vandecappelle @ 2019-06-12 8:26 UTC (permalink / raw) To: buildroot On 12/06/2019 09:06, Thomas Petazzoni wrote: > Hello, > > On Wed, 12 Jun 2019 17:02:01 +1000 > Sam Bobroff <sbobroff@linux.ibm.com> wrote: > >> Ah, right. So that hack is no good, and it suggests that no hack on >> the buildroot side can work as long as GZIP is being overwritten by the >> package's build system. I'll have a go hacking the build system in cups >> to rename the GZIP variable but hopefully their upstream will fix it >> soon :-) >> >> At least some of the compressed files are part of some kind of test data, >> so I'll see if they're the only ones and could perhaps be left out >> entirely. > > Alternatively, Buildroot could use a gzip wrapper, installed in > $(HOST_DIR)/bin to pass this -n option when BR2_REPRODUCIBLE=y. That sounds like the right thing to do. We only need to do install that wrapper if BR2_REPRODUCIBLE=y. However, I'm afraid this will turn up packages that explicitly use /bin/gzip without looking at $PATH... So those will have to be fixed again... > The > gzip man page says that using the GZIP environment variable is > "obsolescent": > > The obsolescent environment variable GZIP can hold a set of default options > for gzip. These options are interpreted first and can be overwritten by > explicit command line parameters. As this can cause problems when using > scripts, this feature is supported only for options that are reasonably > likely to not cause too much harm, and gzip warns if it is used. This fea? > ture will be removed in a future release of gzip. > > You can use an alias or script instead. For example, if gzip is in the > directory /usr/bin you can prepend $HOME/bin to your PATH and create an exe? > cutable script $HOME/bin/gzip containing the following: > > #! /bin/sh > export PATH=/usr/bin > exec gzip -9 "$@" > > Of course, if we go in this direction, we have to take care of what > happens if host-gzip is installed, as it would overwrite the wrapper. Didn't we say at some point that under BR2_REPRODUCIBLE, we should always build all host packages? So the wrapper would be installed as part of host-gzip. Atharva, better put this on your list of things to do :-) Regards, Arnout ^ permalink raw reply [flat|nested] 8+ messages in thread
* [Buildroot] [autobuild.buildroot.net] Build results for 2019-06-10 2019-06-12 8:26 ` Arnout Vandecappelle @ 2019-06-12 10:04 ` Atharva Lele 2019-06-12 15:35 ` Yann E. MORIN 1 sibling, 0 replies; 8+ messages in thread From: Atharva Lele @ 2019-06-12 10:04 UTC (permalink / raw) To: buildroot > Didn't we say at some point that under BR2_REPRODUCIBLE, we should always build > all host packages? What is the reason behind this? I looked for it but did not find much valuable information. > Atharva, better put this on your list of things to do :-) Of course :) Regards, Atharva Lele On Wed, Jun 12, 2019 at 1:56 PM Arnout Vandecappelle <arnout@mind.be> wrote: > > > On 12/06/2019 09:06, Thomas Petazzoni wrote: > > Hello, > > > > On Wed, 12 Jun 2019 17:02:01 +1000 > > Sam Bobroff <sbobroff@linux.ibm.com> wrote: > > > >> Ah, right. So that hack is no good, and it suggests that no hack on > >> the buildroot side can work as long as GZIP is being overwritten by the > >> package's build system. I'll have a go hacking the build system in cups > >> to rename the GZIP variable but hopefully their upstream will fix it > >> soon :-) > >> > >> At least some of the compressed files are part of some kind of test > data, > >> so I'll see if they're the only ones and could perhaps be left out > >> entirely. > > > > Alternatively, Buildroot could use a gzip wrapper, installed in > > $(HOST_DIR)/bin to pass this -n option when BR2_REPRODUCIBLE=y. > > That sounds like the right thing to do. We only need to do install that > wrapper > if BR2_REPRODUCIBLE=y. > > However, I'm afraid this will turn up packages that explicitly use > /bin/gzip > without looking at $PATH... So those will have to be fixed again... > > > The > > gzip man page says that using the GZIP environment variable is > > "obsolescent": > > > > The obsolescent environment variable GZIP can hold a set of > default options > > for gzip. These options are interpreted first and can be > overwritten by > > explicit command line parameters. As this can cause problems > when using > > scripts, this feature is supported only for options that are > reasonably > > likely to not cause too much harm, and gzip warns if it is used. > This fea? > > ture will be removed in a future release of gzip. > > > > You can use an alias or script instead. For example, if > gzip is in the > > directory /usr/bin you can prepend $HOME/bin to your PATH and > create an exe? > > cutable script $HOME/bin/gzip containing the following: > > > > #! /bin/sh > > export PATH=/usr/bin > > exec gzip -9 "$@" > > > > Of course, if we go in this direction, we have to take care of what > > happens if host-gzip is installed, as it would overwrite the wrapper. > > Didn't we say at some point that under BR2_REPRODUCIBLE, we should always > build > all host packages? So the wrapper would be installed as part of host-gzip. > > Atharva, better put this on your list of things to do :-) > > > Regards, > Arnout > > -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.busybox.net/pipermail/buildroot/attachments/20190612/51e59f93/attachment.html> ^ permalink raw reply [flat|nested] 8+ messages in thread
* [Buildroot] [autobuild.buildroot.net] Build results for 2019-06-10 2019-06-12 8:26 ` Arnout Vandecappelle 2019-06-12 10:04 ` Atharva Lele @ 2019-06-12 15:35 ` Yann E. MORIN 1 sibling, 0 replies; 8+ messages in thread From: Yann E. MORIN @ 2019-06-12 15:35 UTC (permalink / raw) To: buildroot Arnout, All, On 2019-06-12 10:26 +0200, Arnout Vandecappelle spake thusly: > On 12/06/2019 09:06, Thomas Petazzoni wrote: > > On Wed, 12 Jun 2019 17:02:01 +1000 > > Sam Bobroff <sbobroff@linux.ibm.com> wrote: > >> Ah, right. So that hack is no good, and it suggests that no hack on > >> the buildroot side can work as long as GZIP is being overwritten by the > >> package's build system. I'll have a go hacking the build system in cups > >> to rename the GZIP variable but hopefully their upstream will fix it > >> soon :-) > > Alternatively, Buildroot could use a gzip wrapper, installed in > > $(HOST_DIR)/bin to pass this -n option when BR2_REPRODUCIBLE=y. > That sounds like the right thing to do. We only need to do install that wrapper > if BR2_REPRODUCIBLE=y. Yes, the wrapper thinggy is the best. > However, I'm afraid this will turn up packages that explicitly use /bin/gzip > without looking at $PATH... So those will have to be fixed again... Yup, but that's not like we are not used to these kind of stupidity, aren't we? ;-) > > The > > gzip man page says that using the GZIP environment variable is > > "obsolescent": [--SNIP--] That alone mandates the use of the wrapper. > > Of course, if we go in this direction, we have to take care of what > > happens if host-gzip is installed, as it would overwrite the wrapper. > Didn't we say at some point that under BR2_REPRODUCIBLE, we should always build > all host packages? So the wrapper would be installed as part of host-gzip. Hmm.. I usually advocate for maximising the number of host packages to build, so as to indeed improve reproducibility. But ultimately, I'd like we identify those host tools that indeed generate non-reproducible output, and so we build our. Otherwise, rely on the host provided tools. And ultimately, I'd like that the reproducible option also applies to the host packages too, so that we can produce reproducible toolchains and SDKs as well. So, where do we draw the line? Surely, we're not going to build our own host toolchain. so reproducibility of the host packages will be limited to some extent, and only guaranteed on the system (i.e. the machine and distribution) that actually did the build. So, we'd have two levels of reproducibility: a high level for things that go in target/ and staging/ (since we handle more tools), and a lower level for things that go in host/ (since we can't handle all tools). Regards, Yann E. MORIN. > Atharva, better put this on your list of things to do :-) > > > Regards, > Arnout > -- .-----------------.--------------------.------------------.--------------------. | Yann E. MORIN | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: | | +33 662 376 056 | Software Designer | \ / CAMPAIGN | ___ | | +33 561 099 427 `------------.-------: X AGAINST | \e/ There is no | | http://ymorin.is-a-geek.org/ | _/*\_ | / \ HTML MAIL | v conspiracy. | '------------------------------^-------^------------------^--------------------' ^ permalink raw reply [flat|nested] 8+ messages in thread
end of thread, other threads:[~2019-06-12 15:35 UTC | newest] Thread overview: 8+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2019-06-11 6:00 [Buildroot] [autobuild.buildroot.net] Build results for 2019-06-10 Thomas Petazzoni 2019-06-12 5:33 ` Sam Bobroff 2019-06-12 6:49 ` Thomas Petazzoni 2019-06-12 7:02 ` Sam Bobroff 2019-06-12 7:06 ` Thomas Petazzoni 2019-06-12 8:26 ` Arnout Vandecappelle 2019-06-12 10:04 ` Atharva Lele 2019-06-12 15:35 ` Yann E. MORIN
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.