Is vscode broken ?

If you run on quarterly packages right now, you can checkout the 2024Q2 branch of the ports tree and build the port. That won't clobber your packages and builds against electron27. It's what I also do for the C64 emulator Vice. That one is obviously unrelated to VSCode but it is never provided as a package due to licensing of some files, so I follow quarterly in both ports as well as packages. Occasionally I get a very minor drift, but that's never been an issue. I do the builds themselves through Poudriere so I don't get all the build-deps on my working machine, even though a quick 'pkg autoremove' would also get rid of those. I prioritize my Poudriere repo a bit higher than the FreeBSD upstream and I don't tweak my build options.
 
bvdw78 said:
If you run on quarterly packages right now, you can checkout the 2024Q2 branch of the ports tree and build the port. That won't clobber your packages and builds against electron27. It's what I also do for the C64 emulator Vice. That one is obviously unrelated to VSCode but it is never provided as a package due to licensing of some files, so I follow quarterly in both ports as well as packages. Occasionally I get a very minor drift, but that's never been an issue. I do the builds themselves through Poudriere so I don't get all the build-deps on my working machine, even though a quick 'pkg autoremove' would also get rid of those. I prioritize my Poudriere repo a bit higher than the FreeBSD upstream and I don't tweak my build options.
Click to expand...
How to you do the prioritization.
Which /usr/local/etc/pkg config file do you use ?
 
The priority is given in the priority field in the repository conf file. Higher numbers yield higher priorities. The upstream FreeBSD is 0, so I put my own repo at 10 which is a completely arbitrary number-larger-than-0. The format of the repo conf is very well documented in pkg.conf(5). Writing this out from memory rather than a copy/paste because I'm not at my own machine right now, something like:

Code: 
Area536: {
         url: "https://builder.area536.com/packages/14-0-release-2024Q2/",
         enabled: true,
         priority: 10,
         mirror_type: "http"
         }

Note: nothing is stopping you from using my builder and I won't be billed for the bandwidth so go right ahead and feel free, but please don't rely on any of it for anything. This is just my personal playground. No guarantees at all and there. If there's interest I'll write up a blog post on how to set up Poudriere for this so you can roll your own rather than leech off my unreliable server.
 
Thanks, this is now my conf file :
# /usr/local/etc/pkg/repos/Local.conf
Code: 
Poudriere: {
   url: "http://127.0.0.1:14000/packages/ap-ports",
   mirror_type: "none",
   priority: 100,
   enabled: yes
}
FreeBSD: {
   priority: 10 ,
   enabled: yes
}
 
Alain De Vos said:
Thanks, this is now my conf file :
# /usr/local/etc/pkg/repos/Local.conf
Code: 
Poudriere: {
   url: "http://127.0.0.1:14000/packages/ap-ports",
   mirror_type: "none",
   priority: 100,
   enabled: yes
}
FreeBSD: {
   priority: 10 ,
   enabled: yes
}
Click to expand...
If your packages are local, you can use file:///path instead of http://
 
I installed it yesterday from latest after upgrading to 14.1. I'm not going to touch my packages in a while now in case it disappears again!
 
Sunray said:
I installed it yesterday from latest after upgrading to 14.1. I'm not going to touch my packages in a while now in case it disappears again!
Click to expand...
Not touching your packages for this reason alone is not the greatest of ideas. You'd effectively stick your head in the sand and be missing out on potential security fixes. Continuing this line of reasoning: any package could fail to build at any time and disappear from upstream. If you don't trust upstream you could always roll your own so you can see what breaks before you expose your installed base. That's what I do in a work environment: for this specific reason as well as the restricted access servers get to the internet.
 
bvdw78 said:
Not touching your packages for this reason alone is not the greatest of ideas. You'd effectively stick your head in the sand and be missing out on potential security fixes.
Click to expand...
My approach is something of a compromise. I wait until the periodic pkgaudit_check script shows that an upgrade is available for a vulnerable package and then try to upgrade just that package. If I end up with dependency conflicts then I do a full pkg upgrade
 
freezr said:
… if I can mix Latest and Quarterly …
Click to expand...

I might try the FreeBSD-provided package for FreeBSD:13:latest (on AMD64) with 14.1-RELEASE, or 15.0-CURRENT.
 

Attachments

  • 1717947593132.png
    1717947593132.png
    24.9 KB · Views: 15
Cath O'Deray said:
I might try the FreeBSD-provided package for FreeBSD:13:latest (on AMD64) with 14.1-RELEASE, or 15.0-CURRENT.
Click to expand...
FreeBSD 13 vs 14 don't uphold the promise of a stable ABI between them. I wouldn't do that if I were you either. Any breakage on that level may be very subtle but no less painful.

My advice for this case is to do any one of the following:
  1. Suck it up and wait for the Q3 packages to arrive.
  2. Build from ports on your own system. Main disadvantages are: it takes time and introduces a lot of otherwise unnecessary build dependencies onto your system. You can use pkg to get rid of this situation later though: pkg autoremove after it's done installing will get rid of the build dependencies but leaves the runtime dependencies alone.
  3. Build through a local instance of Poudriere. Disadvantage: it's quite a project if you haven't used Poudriere before. You won't get the build dependencies onto your local environment though, so no cleanups later.
  4. Use a package from some random, questionable source on the internet like my repo from a few posts up. I'm telling you that you'll be fine if you do that and it'll get you over the next few weeks until Q3 packages appear. I just wouldn't believe me if I were you though, but that choice is yours to make.

What I would definitely *NOT* do in any case, is try to mix and match between branches. VScode has quite a number of build dependencies so this will very rapidly turn into a complicated web of dependency hell.
 
Cath O'Deray said:
I might try the FreeBSD-provided package for FreeBSD:13:latest (on AMD64) with 14.1-RELEASE, or 15.0-CURRENT.
Click to expand...

I don't have 14.1 handy, I used 14.0-RELEASE-p6.

Code: 
root@mowa219-gjp4-freebsd-14-zfs-vm:/home/grahamperrin/Downloads # pkg install ./vscode-1.89.1_1.pkg
Updating FreeBSD-ports repository catalogue...
Fetching meta.conf: 100%    178 B   0.2kB/s    00:01   
Fetching data.pkg: 100%    7 MiB   7.6MB/s    00:01   
Processing entries: 100%
The provides database is up-to-date.
FreeBSD-ports repository update completed. 37921 packages processed.
Updating FreeBSD-base repository catalogue...
FreeBSD-base repository is up to date.
All repositories are up to date.
The following 4 package(s) will be affected (of 0 checked):

New packages to be INSTALLED:
        bash: 5.2.26_1 [FreeBSD-ports]
        krb5: 1.21.2_3 [FreeBSD-ports]
        sndio: 1.9.0 [FreeBSD-ports]
        vscode: 1.89.1_1 [unknown-repository]

Number of packages to be installed: 4

The process will require 333 MiB more space.
3 MiB to be downloaded.

Proceed with this action? [y/N]: y
[1/4] Fetching bash-5.2.26_1.pkg: 100%    2 MiB   1.8MB/s    00:01   
[2/4] Fetching krb5-1.21.2_3.pkg: 100%    1 MiB   1.3MB/s    00:01   
[3/4] Fetching sndio-1.9.0.pkg: 100%  120 KiB 122.7kB/s    00:01   
Checking integrity... done (0 conflicting)
[4/4] Installing bash-5.2.26_1...
Extracting bash-5.2.26_1: 100%
[1/4] Installing krb5-1.21.2_3...
[1/4] Extracting krb5-1.21.2_3: 100%
[2/4] Installing sndio-1.9.0...
===> Creating groups
Creating group '_sndio' with gid '702'
===> Creating users
Creating user '_sndio' with uid '702'
[2/4] Extracting sndio-1.9.0: 100%
[3/4] Installing vscode-1.89.1_1...
[3/4] Extracting vscode-1.89.1_1: 100%
==> Running trigger: desktop-file-utils.ucl
Building cache database of MIME types
root@mowa219-gjp4-freebsd-14-zfs-vm:/home/grahamperrin/Downloads # freebsd-version -kru ; uname -aKU
14.0-RELEASE-p6
14.0-RELEASE-p6
14.0-RELEASE-p6
FreeBSD mowa219-gjp4-freebsd-14-zfs-vm 14.0-RELEASE-p6 FreeBSD 14.0-RELEASE-p6 releng/14.0-n265417-d338712beb1 GENERIC amd64 1400097 1400097
root@mowa219-gjp4-freebsd-14-zfs-vm:/home/grahamperrin/Downloads # cd
root@mowa219-gjp4-freebsd-14-zfs-vm:~ # exit
logout
grahamperrin@mowa219-gjp4-freebsd-14-zfs-vm:~ % pkg info vscode | grep FreeBSD_version
        FreeBSD_version: 1302001
grahamperrin@mowa219-gjp4-freebsd-14-zfs-vm:~ % vscode
grahamperrin@mowa219-gjp4-freebsd-14-zfs-vm:~ %

It does run (pictured). Beyond that, I didn't test.

I'll use pkg to upgrade the OS to 14.1-RELEASE.
 

Attachments

  • 1717959406157.png
    1717959406157.png
    108.1 KB · Views: 24
I'm trying to build vscode and it's already 2 days long and still running!!!
It's an Intel i5 with 16GB RAM

What is this doing?
Compiling the whole system?
 
It's compiling Electron, NodeJS and VSCode itself.. they're pretty big! Such long build times do not surprise me to be honest.
 
If you have the correct package already installed it will use that if you're building from ports using 'make' directly. If you're building from Poudriere, it'll first build its own copies regardless of what you have on the host machine.
 
You must log in or register to reply here.
Back
Top