Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

FS#1543 - Many packages in snapshot failing on one build, ok on next but no code changes. #6495

Open
openwrt-bot opened this issue May 11, 2018 · 8 comments
Labels
core packages pull request/issue for core (in-tree) packages flyspray

Comments

@openwrt-bot
Copy link

bluewavenet:

Snapshot/Packages
Occurs on all architectures apparently at random with faillogs.
After next build some that failed will be ok and some that previously built will fail.
eg submit a PR on https://github.com/openwrt/packages
Travis shows fail on dependencies. After next automated build, Travis errors will be different, or if lucky will pass, only to fail again after the next build.
It seems the build system is chasing its tail somehow.

@openwrt-bot
Copy link
Author

jow-:

Not sure what to make out of this ticket. Do you have any specific examples I can investigate? I need at least some pointers to correlate things...

@openwrt-bot
Copy link
Author

bluewavenet:

A long story, so I will try to keep it short.
I noticed this after one of my custom image builds began having a problem with lighttpd after 25th April (LEDE 17.01.4)
The version in snapshot should have the fix but a line in Makefile was missed out.
I noticed lighttpd was missing in snapshot/packages so looked at faillogs and found many errors.
However later the faillog was different and in fact seemed to change every time the build system re-ran.
I looked at other packages and found the same pattern of apparently random things happening.
The other day lighttpd re-appeared in snapshots, but later failed again (but no changes in the code).
This morning it was back again.
I tried resubmitting my previous PR and Travis failed again (with different errors yet again).
Looking at faillogs for many other packages I can see similar things going on.

I might be misunderstanding how this all works, but it seems to me to be a package will fail to build if a dependency has also failed, which seems reasonable, but this seems to be leading to the build system chasing its tail, or somehow there was a "storm of errors".
Here is my last Travis log:
https://travis-ci.org/openwrt/packages/builds/377700000

My past experience in IT support made me imagine maintainers tearing their hair out trying to fix something causing this, hence my initial sketchy ticket details. If I am doing something wrong, or there is something wrong with the package, then I can look in depth there, but the same pattern seems to appear in the faillogs for other packages...

@openwrt-bot
Copy link
Author

bluewavenet:

See also:
openwrt/packages#6012

@openwrt-bot
Copy link
Author

jow-:

The travis build job is totally unrelated to the snapshot mirrors though, it uses the SDK to build the package and all its dependencies locally. It does not utilize the opkg repositories at all.

@openwrt-bot
Copy link
Author

bluewavenet:

I guessed that, but the errors seemed to be the same or similar, although both change without the code changing.
Looking at it at this moment, it does seem to have stabilised, whereas couple of days ago, some architectures had no packages at all.
I still can't get Travis to pass my PR though. Feeling very frustrated by it all!

@openwrt-bot
Copy link
Author

jow-:

I can understand that... will see if I can take a deeper look at it later. Note that the travis integration is not directly administered by OpenWrt/LEDE, it is local to the Github package repository. The toplevel travis scripts in the repo should probably get adjusted to actually show the compile logs (or to build the package with V=s in the first place).

@openwrt-bot
Copy link
Author

bluewavenet:

Much appreciated, along with all your other efforts!

@openwrt-bot
Copy link
Author

bluewavenet:

The 25th of April seems to be a common date.
The version of lighttpd in lede 17.01.4 jumped from 1.4.45-3 (working with SSL) to 1.4.28-1 (broken for SSL) on that date.

I thought package version jumps did not push into the stable release but stayed only available in snapshots, or have I got that wrong?

@aparcar aparcar added the core packages pull request/issue for core (in-tree) packages label Feb 22, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
core packages pull request/issue for core (in-tree) packages flyspray
Projects
None yet
Development

No branches or pull requests

2 participants