I agree 100%, lack of motivation can kill any project.
@aparcar Thank you for bringing the service back up, it's working well now!
2 Likes
The issues, PR, and Fork buttons are pretty much right there waiting for you.
Funny how none of these "killing motivation" arguments were applied here: Warpmon - Wireless ARP Monitor in which it had nothing to do with the actual project itself, only my choice of distribution.
If I need something changed/fixed for myself only, I do it myself, e.g. Odhcp6c issue with my ISP's configuration
I rarely make use of the Firmware Selector and this was a feedback based on my own experiences with working on maintenance hell projects aswell as popular projects going the same route once it becomes too troublesome to maintain. ASU is written in Python and Python received a major refactor from 2 to 3, despite the huge unpopular opinion over issues with backwards compatibility.
But if I am going to be treated like that for well-intentioned and thoughtful feedback, I am just going back to being silent.
And then people wonder why non-big tech FOSS projects have been having decreases in number of contributions every year.
Ironic...
1 Like
can we make attendedsysupgrade to able to spit out config file for personal imagebuilder/ full compiler?
it currently talk to imagebuilder so it should be able to expose it for imagebuilder. not sure how it can used for full builder as it don't have inner package configs
That's out of scope for LuCI app and Firmware Select since they are simple image assembly tools, but
$ owut list --format config
CONFIG_PACKAGE_bind-dig=y
CONFIG_PACKAGE_btop=y
CONFIG_PACKAGE_conntrack=y
CONFIG_PACKAGE_coreutils-od=y
CONFIG_PACKAGE_curl=y
CONFIG_PACKAGE_diffutils=y
...
1 Like
Hi, sorry for the lengthy downtime of the ASU server the other week. After returning to a laptop I figured that it's not a server problem but an issue with the hypervisor. A misconfiguration broke the IPv4 access (IPv6 continued to work, duh), rendering the service unusable for most users.
The hypervisor is maintained by a small number of skilled individuals and part of a community I trust, I have no doubt this was accidental with no bad intention, just to be clear about that.
A number of people wrote me messages if I need assistance maintaining the server, thanks for those offers! I can't give anyone access to the server just like that, however I'd very much like to encourage people to spin up "rebuild" servers. Specifically, after a successful firmware build on the primary instance, your server is asked to create the same image and then firmware hashes are compared, verifying a correct image. In a perfect scenario multiple communities and individuals offer those servers, first used as rebuilders, later as redundant backups, eventually maybe replacing my involvement in maintaining it. Please reach out if you see yourself in the position host and maintain such service, if you need help and advice, I'll try my best to help you. A small VM for 5$/m should be enough for a good start.
Thanks for your patience, thanks for keeping your firmware up to date 
25 Likes
Summary
PING openwrt.org (2a03:b0c0:3:d0::1a51:c001): 56 data bytes
64 bytes from 2a03:b0c0:3:d0::1a51:c001: seq=0 ttl=52 time=46.335 ms
64 bytes from 2a03:b0c0:3:d0::1a51:c001: seq=1 ttl=52 time=45.266 ms
64 bytes from 2a03:b0c0:3:d0::1a51:c001: seq=2 ttl=52 time=45.435 ms
64 bytes from 2a03:b0c0:3:d0::1a51:c001: seq=3 ttl=52 time=45.013 ms
64 bytes from 2a03:b0c0:3:d0::1a51:c001: seq=4 ttl=52 time=45.093 ms
Perhaps this is not quite true, or not for everyone.
My provider provides IPV6 and it did not work for me either.
Even if we run diagnostics using standard LuCi tools, we get the following:
--- openwrt.org ping statistics ---
5 packets transmitted, 5 packets received, 0% packet loss
round-trip min/avg/max = 45.013/45.428/46.335 ms
Summary
PING openwrt.github.io (2606:50c0:8001::153): 56 data bytes
ping6: sendto: Network unreachable
The situation is approximately the same with tracing.
I don't think it's my provider's fault.
Is it posible to repackage ASU server in an easy to deploy docker image or virtual machine appliance?
Even if you don't run a public server people would be able to use that in case of official server long down time...
I run two servers at home in VMs, one Hyper-V Ubuntu 22.04 instance, the other is Fedora-hosted QEMU Ubuntu 24.04 (2 CPUs, 4G RAM and 32G disk). The latter is the one I use for most of my owut testing, and also for development and debugging of the ASU server itself. It's not particularly hard to get a local instance running, and the resources required are relatively small.
If you just want quick results, easily, the offline imagebuilder is trivial to use - just not 'pretty'.
1 Like
Hello, sorry to bother, I've been blocked at firmware-selector...
Plz maintainers, can you do something ?
I've not been able to customize the image and been blocked immediately with Failed message
Can you provide more info? Target/subtarget, OpenWrt version and so on...
I've just built a couple images and saw no problems... (x86/64 24.10.1, Archer c7 snapshot)
The point was more like, nowadays more and more people are running home lab servers on their home. If they could deploy a local ASU server as easily as a docker image maybe the times when official server is down (which is something that it will always happen when it's being managed by a real person with a real life as a pure labor of love) people will have an alternative to just wait and complain in the thread, and if they do you could always tell them "if you can't wait for ASU to be back online just run a local server yourself".
1 Like
https://github.com/openwrt/asu have some tutorial to run it locally by podman
1 Like
How can I find out which packet the server is complaining about with the current error message output?
Is there some kind of table or algorithm?
Hum sorry, I realize this is not immortal support forum... I just clicked on feedback link at the bottom...
In order to understand which package the OpenWrt build site complains about, I first test the list of packages on the Immortal site.
Otherwise, there is no way to understand what the OpenWrt build site needs.
Made it "very convenient".
Bravo!!! Bis!!!
Sorry about that. We are aware of the problem and will try to fix it.
Ticket: https://github.com/openwrt/firmware-selector-openwrt-org/issues/112
1 Like
Thank you! My English is very bad and it is difficult for me to formulate correctly with the help of an electronic translator. If something is not very correct, then I apologize and thank you for your response.
1 Like
Hey
Is the firmware selector down?
when trying to build for x86/64 I get "Failed to fetch"