Today, I stumbled over this thread on forums: https://forums.freebsd.org/threads/is-vscode-broken.88334/ As packages *temporarily* missing is pretty common, I decided to investigate a bit, only to find the reason for editors/vscode missing from repositories is that some electron ports (including devel/electron19) are currently blacklisted. Asking about it on IRC, I learned they took excessively long time to build, sometimes even failing with a "runaway process". Still they build fine for me locally, and someone else on IRC confirmed. So there seems to be a "hidden issue" that hopefully could be solved. Furthermore, as long as "blacklisting" is the only option, I kindly ask to find some solution to make that transparent to package users. IMHO, just leaving them with missing packages and no accessible information about it is less than ideal.
Also adding tagattie as the maintainer of these ports, just in case he has some idea what exactly could go wrong.
Assign to maintainer.
(In reply to Mark Linimon from comment #2) How exactly can the maintainer do anything about local configuration decisions on the package builders?
I missed CC was changed as well, so changing assignee back myself now: It seems there was a misunderstanding, this PR is about some local configuration on the package builders that blacklist electron*. I only added tagattie as the maintainer because he might be able to give some input. I'm not 100% sure the configuration of the builders belongs to "Package Infrastructure", so please correct the assignment if needed, but it's certainly not a problem with an individual port or something a port maintainer could solve.
^Triage: Did you mean pkgmgr@ (as Assignee) instead of pkg-manager@ ? According to /etc/aliases on freefall the latter doesn't exist. As pkgmgr@ has no assigned bugs (even closed) you may have more luck going through portmgr@ first. See also https://www.freebsd.org/administration/#t-pkgmgr https://lists.freebsd.org/archives/freebsd-ports/2022-October/002788.html
(In reply to Jan Beich from comment #5) Interesting! It's too long ago now to remember how I ended up with that assignee, maybe got it from IRC and failed to verify ... Well, it's certainly about the build cluster configuration, but based on your comment, I'll now reassign it to portmgr. Thanks!
<http://beefy18.nyi.freebsd.org/build.html?mastername=main-amd64-default&build=p563c845130a1_sfafb03ab42> in progress, has: * four electron ports listed (not blacklisted), queued, not yet building or built. Context (from a log of success for a different port): > building for: FreeBSD main-amd64-default-job-02 15.0-CURRENT FreeBSD 15.0-CURRENT > 1500000 amd64
(In reply to Graham Perrin from comment #7) > * four electron ports listed (not blacklisted), queued, not yet building or built. That was probably a temporary experiment to see current status. 124amd64 and 124i386 still fail in "build/timeout" because the assigned machines are very slow e.g., full rebuild on 124amd64 takes 170:05:09 (7 days) vs. 132amd64 takes 100:25:10 (4 days). For some reason, www/*chromium are not blacklisted despite hitting the same issue as "runaway_process". https://pkg-status.freebsd.org/beefy18/build.html?mastername=main-amd64-default&build=pbb08d6248767_s04c8bfc176 https://pkg-status.freebsd.org/beefy16/build.html?mastername=132amd64-default&build=da42697af50c https://pkg-status.freebsd.org/beefy6/build.html?mastername=124amd64-default&build=da42697af50c https://pkg-status.freebsd.org/beefy15/build.html?mastername=132i386-default&build=08943441f26e https://pkg-status.freebsd.org/beefy5/build.html?mastername=124i386-default&build=ecb3f8a4918b vs. (blacklisted again) https://pkg-status.freebsd.org/beefy18/build.html?mastername=main-amd64-default&build=pf36f3675dc48_sbb679b0c49 https://pkg-status.freebsd.org/beefy16/build.html?mastername=132amd64-default&build=b18316019742 https://pkg-status.freebsd.org/beefy6/build.html?mastername=124amd64-default&build=1fa9afdc10b7 https://pkg-status.freebsd.org/beefy15/build.html?mastername=132i386-default&build=f36f3675dc48 https://pkg-status.freebsd.org/beefy5/build.html?mastername=124i386-default&build=f36f3675dc48
@portsmgr: why are all the electron ports blacklisted on the builder? I have *several* complaints from users because signal-desktop is not available as a package
At the moment we do not have resources to build 4 versions of electron (not enough disk + not enough cpu + not enough ram). If there was only 1 version in the ports tree, maybe this could be reconsidered.
I have removed electron22 yesterday so it makes 3 now. electron26 do not have any consumers so can be easily ignored. The rest of the consumers are as following: - editors/vscode(electron25) - net-im/signal-desktop(electron25) - textproc/obsidian(electron24) So I think it would be better to give electron25 a chance and see how it goes. And on the other hand also check if obsidian can be updated to use electron25.
Looks like obsidian does not build in the cluster also due to the licensing issues and can be safely ignored.
(In reply to Muhammad Moinur Rahman from comment #12) net-im/signal-desktop and editors/vscode now use electron27 graphics/drawio requires electron25 (latest release 23.0.2 requires electron28) textproc/logseq requires electron25 (latest release 0.10.6 requires electron27) www/vieb requires electron25 (latest release 11.0.0 requires electron28) Can we unlock electron27 please?
signal-desktop now uses electron28
Can electron27 and electron28 be whitelisted on the cluster? editors/vscode needs electron27, and net-im/signal-desktop needs electron28. Thanks!
No, there is not enough resource to build multiple versions of electron.
What versions of electron are whitelisted on the cluster now? electron25 is EOL, and electron26 is EOL on 2024/04/16. Shouldn't electron27 and electron28 be whitelisted now that the two oldest versions are either no longer being supported or soon to be unsupported? I get that electron is a heavy/intensive package to build, but being able to have updates to packages that require both (current) versions seems like it'd be advantageous to FreeBSD to have those dependent packages available for users. I appreciate everyones support and time devoted to making FreeBSD and packages available!
We do not have resources to build 2 versions of electron, only 1. Please coordinate yourself to use only 1 in ports depending on electron.
(In reply to Antoine Brodin from comment #18) It's not possible to use the same electron version between ports due to API incompatibilities. Again, I received a lot of complains from our user base because signal-desktop is not available as a package. I'm asking again to unlock electron29 on the builder.
(In reply to Antoine Brodin from comment #18) Hello, This has broken all Electron-dependent packages, especially including net-im/signal-desktop. Signal requires that paired desktops ("linked devices") access Signal at least every 30 days [0], failing which their pairing is lost and the entire message history from last connection is also lost. As a result, users who are trying trying to heed the common advice of not mixing ports and packages are running out of time before data loss will occur. As Mikael said, users cannot "coordinate themselves"; apps may not work correctly if built with a version of Electron other than what is intended by the developer. Can you please stop obstructing the building of packages which are important to desktop users of FreeBSD, or should we give up and move back to Linux? [0]: https://support.signal.org/hc/en-us/articles/360007320551-Linked-Devices
Hello, Again, please coordinate to build other electron-dependent ports with electron29. We don't have enough resources to build multiple versions of electron. If some users need electron29, they can build it themselves.
(In reply to Antoine Brodin from comment #21) Hi Antoine, How is building Electron 29 myself going to get me any closer to a working package of net-im/signal-desktop? Thanks in advance.
(In reply to Alexander Burke from comment #22) net-im/signal-desktop works fine if you build it as well as the required electron version yourself. I haven't tested the current signal-desktop version 7.7.0, but I use version 6.48.1_6 which I built last month together with electron28 and it works as expected. Just be ready for a significant build time. Building electron took about half a day on my hardware.
(In reply to bsduck from comment #23) Hello, Building and installing net-im/signal-desktop as a port would contradict the advice in section 4.5 of the FreeBSD Handbook to avoid mixing ports and packages on the same box, and frankly if FreeBSD wants to be taken seriously as a desktop OS this kind of fsckery needs to not happen. (Plus, if I wanted to build everything from source, I'd be running Gentoo.) Since there has been no resolution on this issue in time to avoid data loss from Signal becoming unpaired, I've been forced to back up my home folder, wipe FreeBSD, install Linux, and restore the Signal data dir (which, to my great surprise, worked perfectly upon Signal's first launch on Linux, picking up right where it left off under FreeBSD). Those who obstruct critical-path packages should be ashamed of themselves. (A shiny new $100K cluster that can't handle building two versions of Electron instead of one? Come on.) As it turns out, ZFSBootMenu works great even with native ZFS encryption, so I was able to entirely avoid the nightmare which is GRUB. I can't say I didn't try. ¯\_(ツ)_/¯
(In reply to Alexander Burke from comment #24) When you know what you're doing, there's nothing wrong with mixing official packages and a few ports you build yourself, as long as you keep both on the same branch (quarterly or latest). This used to be a common problem when most people used portsnap (which can only track latest) together with the default quarterly packages. Nowadays, thanks to git, it is much easier to track a quarterly branch for the ports tree. The warning in section 4.5 of the handbook sounds very much like an exaggeration in today's context. That being said, I admit that this situation with signal-desktop is an inconvenience that should not happen. But I can live with that, and it will be solved eventually. Good for you if you're happy on Linux, personally it would take much more for me to trade my FreeBSD desktops for penguins ;)
I also find it quite inconvenient to build electron from ports and every time there's a version bump etc, so I avoid installing anything from ports that needs it. If there are not enough hardware resources to provide different versions what can we as users do to help solve the fundamental problem? I'm thinking along the lines of either increasing the resources (hardware donations? cloud compute credits? smiling sweetly at companies?) or distributing the package building differently. I'm sure a number of us in this thread would be happy to build electron from source if it meant that the package was available to other users.
Antoine, if I'm not mistaken, we have new builders available in Chicago beefy{20,21,22}. Are we closer to being able to remove devel/electron28 and devel/electron29 from the blacklist (at least for 140amd6) so that we can have packages for net-im/signal-desktop and devel/vscode? If not, what do we need to make this happen?
(In reply to Joseph Mingrone from comment #27) I think I will blacklist electron25 and un-blacklist electron28. If only upstreams/maintainers of vscode and signal agreed to use a single version of electron... I currently use beefy21 and beefy22 for exp-runs as the previous exp-run builders were more than 11 years old.
We need more builders. While we have three new package builders in Chicago, half of the production builders we have are still well past their use-by date. beefy11-beefy12 were installed in January 2013. beefy13-beefy16 were installed in October 2016. beefy17-beefy19 were installed in 2019 - these are borderline beefy20-beefy22 were installed in 2024 - these are new The gohans (pkgexp builders) are a bit younger: gohan01-gohan03 were installed in 2019 gohan04 was installed in 2020 gohan05 was installed in 2021 gohan06 was installed in 2024 I would say we need at least nine new builders now (replacing beefy11-beefy16). While I like to replace hardware after three years, five years is probably okay for package builders. We should be thinking of replacing beefy17-beefy19 next year. Considering how long it takes to get hardware: if it were up to me, I'd order twelve new package builders right now.
(And I can't count: that should be six new builders to replace beefy11-beefy16 or nine builders to replace beefy11-beefy19. Having three new gohans to replace gohan01-gohan03 wouldn't hurt either though. Five years is when they start getting long in the tooth.)
... and I was recently wondering WHY there is no Signal Desktop in packages for such a LONG time :ASD Seriously its THAT bad that we need to blacklist quite important packages (Electron) 'just' to have such basic things as Signal Desktop? Is it not possible to agree on ONE version of Electron to build 'devel/electron29' as dependency for both 'net-im/signal-desktop' and 'devel/vscode'? It REALLY sucks to NOT have such basic things such as Signal ... Thanks, vermaden
Created attachment 250717 [details] Screenshot: Signal 7.6.0 for FreeBSD version 1303001 (13.3-BETA3), started from the command line on FreeBSD 1500018 (15.0-CURRENT) A few days ago, the maintainer of net-im/signal-desktop kindly made available a package for amd64. A link to the repo, from which I downloaded the one package, was given on page three of 'signalapp / Signal-Desktop' in The FreeBSD Forums: - <https://forums.freebsd.org/posts/654633> Defocusing from Signal, and from any other application that may be affected by package infrastructure constraints, I should draw attention to: - <https://wiki.freebsd.org/Bugzilla/DosAndDonts> In particular, do remember the Golden Rule. > treat others as you would like others to treat you — > what you wish upon others, you wish upon yourself …
(In reply to Philip Paeps from comment #29) What can people interested in supporting the addition of more builder machines committers do? Can committers get the foundation to start a fundraising campaign? This is typically the kind of tangible problem to which people are inspired to contribute (such and such popular can no longer be offered as packages because we lack build machines, help us purchase more). I feel this is the actionable item required by this bug, otherwise this discussion will keep going circle.
(In reply to Misso Works from comment #33) Maybe creation of Flare [1] port would be possible? [1] https://gitlab.com/schmiddi-on-mobile/flare
(In reply to Misso Works from comment #33) Instead of asking the foundation to start a fundraiser, doing one directly would probably helpful. The question is: what should be the target sum ? 50K US$ ? Higher ? Lower ?
(In reply to Slawomir Wojciech Wojtczak from comment #34) That's off-topic from package infrastructure. Instead, please: <https://forums.freebsd.org/threads/93514/>
(In reply to Antoine Brodin from comment #28) > … upstreams/maintainers of vscode and signal … I don't know about upstream, but we do have devel/electron29 at both <https://www.freshports.org/editors/vscode/#requiredbuild> and <https://www.freshports.org/net-im/signal-desktop/#requiredbuild>. For the former: <https://github.com/FreeBSD/freebsd-ports/commit/e0776945fd6a164ae242bfe211276748999f5e6a#diff-beb3ff4ba9f97b5a693e90fb204e4670b4f4f789b84ad1b12c52456ad64413dbL105-R104> (2024-06-07). Regards
Hi all, currently, both ports (signal-desktop and vscode) depend on electron30. What's the show stopper then in this case? Kind regards kaltheat
(In reply to kaltheat from comment #38) Also would love to get answer to that ...
We have a few new builders going online this week. I'm not sure if that will let us build multiple versions, but it's worth trying out how long they take.
(In reply to Philip Paeps from comment #40) What can be done to have ONE major 'always buildable' version of 'electron' that 'vscode' and 'signal-desktop' depends on - so they will always be built?
(In reply to kaltheat from comment #38) I'll update signal-desktop to the latest version "soon", it'll use electron31
https://forums.FreeBSD.org/threads/signalapp-signal-desktop.79340/post-667609 > what can I do as someone who relies on Signal-desktop to make sure it is recognised as an important (desktop) application? I seccond.
(In reply to Marcus Rohrmoser from comment #43) +1 The 'signal-desktop' is also a critically important app for me.
(In reply to Philip Paeps from comment #40) That sounds great. If that still is not enough compute resources, a fundraising drive by the Foundation would be something I definitely would support (I mean, not just verbally but financially... :-) ) as Signal is also critical for me.
thanks for 7.27.0
Both vscode and signal-desktop use electron32. Can we unblock this version and block v30?
(In reply to Mikael Urankar from comment #47) Done for ports main
As more of a user than a developer, I'd like to make the point that messenger type applications such as Signal-desktop are often more important than much bigger, more complex applications. Therefore, I'd like to make a plea to make these "side" operations easier to access, update etc. Thanks,