Vscode: rpm & repository for Fedora Linux

[fnkr]

[mackenza]

see #269 for further discussion on this

[jwulf]

You could maintain the package and have it in the main Fedora repository:

https://fedoraproject.org/wiki/Packaging:Guidelines

[ncoghlan]

For a relatively standalone application like this, a COPR repo would likely be a better fit than the main Fedora package repos: https://developer.fedoraproject.org/deployment/copr/about.html

[1dot75cm]

I just packaged vscode. Can you help me test it? @fnkr
https://copr.fedoraproject.org/coprs/mosquito/vscode/

[bgse]

Edit: Ignore this comment, apparently I've managed to consistently misspell mosquito quite many times... sorry for the inconvenience.

[bgse]

Works fine, installs without any apparent issues.

I see you've decided to go for 'vscode' as command instead of 'Code' or 'code', this had me confused at first but I actually like it, I've always felt that 'code' was a little ambiguous to have in my path.

[bgse]

@1dot75cm Tested on F21 and F23, looking good so far.

[1dot75cm]

Thanks test. @bgse
In fact, I refuse to 'Shift' key. My little finger is very fragile. :)))))))))

[1dot75cm]

Hi, @bgse
I try to stripping electron from vscode package (1. rpm size reduced to 4.2 MiB; 2. share electron binary files). But the vscode do not support electron 0.36.x. It return following error.

RPM spec: http://copr-dist-git.fedorainfracloud.org/cgit/mosquito/test/vscode.git/tree/vscode.spec?id=17ce85d650470e023ff37e7412d62c5aa222b304
RPM: https://copr.fedorainfracloud.org/coprs/mosquito/test/build/163492/

Version 0.10.11
Commit 8b7f21e10bf69745bde4330a337e9501972e983b
Shell 0.36.8
Renderer 47.0.2526.110
Node 5.1.1
$ dnf install https://copr-be.cloud.fedoraproject.org/results/mosquito/test/fedora-23-x86_64/00163492-vscode/vscode-0.10.11-1.fc23.x86_64.rpm
$ export ELECTRON_ENABLE_LOGGING=1
$ export ELECTRON_ENABLE_STACK_DUMPING=1
$ electron /usr/lib64/vscode
[6978:0227/175217:INFO:CONSOLE(133360)] "IRequestService.makeRequest: Url is required.: Error: IRequestService.makeRequest: Url is required.
    at RequestService.makeRequest (file:////usr/lib64/vscode/out/vs/workbench/workbench.main.js:137627:23)
    at GalleryService.queryCache (file:////usr/lib64/vscode/out/vs/workbench/workbench.main.js:121102:40)
    at GalleryService.query (file:////usr/lib64/vscode/out/vs/workbench/workbench.main.js:121057:30)
    at ExtensionTipsService._getAvailableExtensions (file:////usr/lib64/vscode/out/vs/workbench/workbench.main.js:92773:41)
    at ExtensionTipsService._init (file:////usr/lib64/vscode/out/vs/workbench/workbench.main.js:92735:46)
    at new ExtensionTipsService (file:////usr/lib64/vscode/out/vs/workbench/workbench.main.js:92705:18)
    at create (file:////usr/lib64/vscode/out/vs/workbench/workbench.main.js:5252:14)
    at file:////usr/lib64/vscode/out/vs/workbench/workbench.main.js:61565:45
    at AccessLock.runUnlocked (file:////usr/lib64/vscode/out/vs/workbench/workbench.main.js:61393:24)
    at ServicesMap.createInstance (file:////usr/lib64/vscode/out/vs/workbench/workbench.main.js:61564:31)", source: file:////usr/lib64/vscode/out/vs/workbench/workbench.main.js (133360)
......
[6978:0227/175219:INFO:CONSOLE(109401)] "%c[Plugin Host]", source: file:////usr/lib64/vscode/out/vs/workbench/workbench.main.js (109401)

I think, we needs to solve this problem for Linux platform. However, the PR is marked as cla-not-required. @bpasero

[bgse]

@1dot75cm The cla-not-required label just means the contributor does not need to sign a license agreement, for example when it is a small change, in the case of @bpasero because he's Microsoft.

I'm sure it's pretty high up on the agenda though.

[1dot75cm]

Just now, I try to update electron to 0.36.10. It seems to work fine. How to conduct a comprehensive test? @bgse

Version 0.10.10
Commit 97d4ad1c55a82369f65078406ed770e8a34055fc
Date 2016-03-07T21:55:23.885Z
Shell 0.36.10
Renderer 47.0.2526.110
Node 5.1.1

https://copr.fedorainfracloud.org/coprs/mosquito/vscode/build/166475/

[Tyriar]

FYI an official rpm file is going to be provided with the March release https://github.com/Microsoft/vscode/issues/3595, the repository will likely come later.

[bgse]

@1dot75cm I've tried updating to the latest F23 build, but didn't get far, dnf skipped the package due to dependency issues. Might be able to investigate more towards the weekend.

[Tyriar]

Signing the repo pushed to May.

[Tyriar]

Still waiting on signing.

[bgse]

@Tyriar Any news on this? Also, I'm wondering if there are plans to also have the coming daily insiders builds in repo, this would be a huge benefit for those of us who like to live on the wild side ;-)

[Tyriar]

@bgse I know what you mean, I've been on daily builds for months and I'm always behind because of no auto updating.

There is some progress that will be made this month, but it won't be happening in v1.3.0, see https://github.com/Microsoft/vscode/issues/2973#issuecomment-224149317 for more details.

[iavael]

As I see from rpm postinst script (I uncommented code)

if [ "code" != "code-oss" ]; then
       if [ -d "/etc/yum.repos.d" ]; then
               REPO_FILE=/etc/yum.repos.d/code.repo
               rm -f $REPO_FILE
               echo -e "[code]\nname=Visual Studio Code\nbaseurl=https://vscode-update.azurewebsites.net/api/rpm/stable/x86_64/rpm" > $REPO_FILE
       fi
fi

you gonna change user's repo configuration unconditionally on every package install/update. I have custom repo naming scheme and this kind of "service" from google-chrome was driving me nuts for a long time until I finally learned about a "magic" variable, which disabled this behaviour.

It's a bit sad that you gonna adopt this bad practice to change user's configuration in postinst script without asking him/her and it would be really nice if you'll adopt community approved method to provide repo for user which keeps in user's hands control over his/her configs.

A good example of such practice is described in Fedora wiki (https://fedoraproject.org/wiki/EPEL#How_can_I_use_these_extra_packages.3F)

[Tyriar]

@iavael thanks for your comments, at the very least we'll also adopt the magic variable and document it on the installation page. Once it's all working we will also provide documentation on adding the repository/key manually so you don't even need to touch the deb if you don't want to. A disclaimer could also be added to the deb's description if touching yum.repos.d/sources.list.d is a concern for many people.

If you're interested, here are some discussions we've had around the topic of individual distro repositories #7412

[mcepl]

Can I suggest something like this instead?

if [ "code" != "code-oss" ]; then
       if [ -d "/etc/yum.repos.d" ]; then
               REPO_FILE=/etc/yum.repos.d/code.repo
               if [ -f "$REPO_FILE" ] ; then
                   REPO_FILE="$REPO_FILE.rpmnew"
                   echo "Creating $REPO_FILE" 1>&2
               fi
               echo -e "[code]\nname=Visual Studio Code\nbaseurl=https://vscode-update.azurewebsites.net/api/rpm/stable/x86_64/rpm" > $REPO_FILE
       fi
fi

This a way more follows the standard platform practices.

Or Adobe Flash used to have just *.repo file for download with instructions "put this into /etc/yum.repos.d". I think it was a good practice.

[iavael]

This a way more follows the standard platform practices.

It doesn't. You won't meet any package with such package script in native Fedora/CentOS/RHEL repos (moreover, it's FORBIDDEN) or in RpmFusion or any other 3rdparty repo running by sane maintainer who is familiar with how things should be done properly.

REPO_FILE="$REPO_FILE.rpmnew"

don't touch .rpmnew or .rpmsave files in package scripts. They are managed by rpm itself.

And, for example, I have repo config in /etc/yum.repos.d/vendor-microsoft.repo. Why do you want to come and automagically ruin order in MY config files?

[mcepl]

It doesn't. You won't meet any package with such package script in native Fedora/CentOS/RHEL repos (moreover, it's FORBIDDEN) or in RpmFusion or any other 3rdparty repo running by sane maintainer who is familiar with how things should be done properly.

Well, I tried to be constructive, and we are not talking about pushing this package to any official repo anyway. I thought we are talking only about package on https://code.visualstudio.com/ . And yes, I said, that I would be more happy with just distributin .repo file on the site and having a proper repository somewhere. See https://get.adobe.com/flashplayer/download/?installer=FP_11.2_for_other_Linux_64-bit_(YUM)&standalone=1

[iavael]

@mcepl Sorry, if my words looked rough, I'm not very good in english. And some of you ideas (e.g. moving code.repo.rpmnew to code.repo unconditionally) were strange and could make user experience even worser than just writing repo file in package script directly.

[mcepl]

@iavael don't worry about rough (I am a Czech myself, so English is my second/third language as well). I just though that my idea was less brutal than yours proposal in https://github.com/Microsoft/vscode/issues/229#issuecomment-225062801 . However, more and more I am looking at VS Code less I like it, so I don't care that much anyway.

[ismail]

It should also support openSUSE, Chrome on Linux does this.

[Tyriar]

Update: SQL Server for Linux is now being shipped on the new Microsoft Linux repositories that we've been waiting on. I should have access soon to start integrating it into our build process :tada:

See https://docs.microsoft.com/en-us/sql/linux/sql-server-linux-setup-ubuntu and https://docs.microsoft.com/en-us/sql/linux/sql-server-linux-setup-red-hat for an idea of what's going to be available.

[Tyriar]

I have some more information on the system now, unlike with .deb files, .rpm signing is not fully automated yet. As such we will not be able to ship .rpm to Insiders builds until that is automated (I was told the ETA is mid-2017). We will probably manually sign for stable builds though as there are only 2-3 in a typical month, expect this to come around the same time as .deb packages start shipping to stable.

[ismail]

Please also don't forget about openSUSE/zypper support.

[Tyriar]

A yum repo is now available for stable only, insiders needs to wait until our signing story is automated. Here are the key links:

• Repository: https://packages.microsoft.com/yumrepos/vscode
• Repository key: https://packages.microsoft.com/keys/microsoft.asc

This is how you can install using yum:

# Install key
wget -O- -q https://packages.microsoft.com/keys/microsoft.asc > microsoft.asc
sudo rpm --import microsoft.asc
# Install repo
​​sudo sh -c 'echo -e "[code]\nname=Visual Studio Code\nbaseurl=https://packages.microsoft.com/yumrepos/vscode\nenabled=1\ngpgcheck=1\ngpgkey=https://packages.microsoft.com/keys/microsoft.asc" > /etc/yum.repos.d/vscode.repo'
# Update yum's cache
yum check-update
# Install
sudo yum install code

Please test it out and let me know how it goes.

Follow ups

• I created https://github.com/Microsoft/vscode-docs/issues/850 to follow up documenting this on the website, if anyone wants to help by providing non-yum/dnf instructions that would be helpful.
• Ideally the repo would detect the package manager and be installed automatically when installing the .rpm https://github.com/Microsoft/vscode/issues/20895

[jrick]

@Tyriar appears to work (tested with dnf on F25) although your example to install the repo is missing a double quote.

[Tyriar]

@jrick fixed, thanks :sweat_smile:

[ismail]

Should I open a new bug to create an openSUSE repo?

[Tyriar]

@ismail you should be able to use this repo, I'm hoping someone familiar with zypper can suggest the right script based on the yum one above.

[ismail]

@Tyriar you are right, after installing the Microsoft signing key, just put a vscode.repo file under /etc/zypp/repos.d with the content

[vscode]
name=vscode
enabled=1
autorefresh=1
baseurl=https://packages.microsoft.com/yumrepos/vscode/
type=rpm-md
keeppackages=0

[LenzGr]

@Tyriar rpm can actually import the GPG key via http directly, simply run:
sudo rpm --import https://packages.microsoft.com/keys/microsoft.asc

[LenzGr]

Turns out the GPG key import can be skipped altogether, if the .repo file contains the key's URL in the gpgkey configuration variable. dnf install code will notice that the key is missing and prompts the user about downloading it:

Downloading Packages:
code-1.9.1-1486597190.el7.x86_64.rpm                                                                                                                           1.9 MB/s |  50 MB     00:26    
-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
Total                                                                                                                                                          1.9 MB/s |  50 MB     00:26     
warning: /var/cache/dnf/code-1a27fa61fdd77ffb/packages/code-1.9.1-1486597190.el7.x86_64.rpm: Header V4 RSA/SHA256 Signature, key ID be1229cf: NOKEY
Importing GPG key 0xBE1229CF:
 Userid     : "Microsoft (Release signing) <[email protected]>"
 Fingerprint: BC52 8686 B50D 79E3 39D3 721C EB3E 94AD BE12 29CF
 From       : https://packages.microsoft.com/keys/microsoft.asc
Is this ok [y/N]: y
Key imported successfully
Running transaction check
Transaction check succeeded.
Running transaction test
Transaction test succeeded.
Running transaction
  Installing  : code-1.9.1-1486597190.el7.x86_64                                                                                                                                           1/1 
  Verifying   : code-1.9.1-1486597190.el7.x86_64                                                                                                                                           1/1 

Installed:
  code.x86_64 1.9.1-1486597190.el7                                                                                                                                                             

Complete!

[LenzGr]

I wrote a short HOWTO for Fedora (and other yum-based distributions): Installing Microsoft Visual Studio Code on Fedora Linux

[Tyriar]

@LenzGr Apparently dnf understands yum repos, that's cool! That's pretty similar to the setup for the apt repo, see https://github.com/Microsoft/vscode/issues/2973#issuecomment-280575841

Not sure it would work with plain yum though on older OS's.

[bgse]

@Tyriar Should work, my guess is that something else will break on a 10 year old distro before yum refuses to play.

[LenzGr]

@Tyriar dnf is actually the "next upcoming major version of yum" (according to the man page), so this should not be surprising ;)

And SUSE's zypper is capable to work with plain yum repos as well. Less work on your end. ;)

[ncoghlan]

I can confirm @LenzGr's variant works for dnf. I'm not sure older versions of yum have the automatic GPG key import feature though, so it probably makes sense to keep that step separate in any yum-specific docs.

[iavael]

@ncoghlan

I'm not sure older versions of yum have the automatic GPG key import feature though

yum had this feature for a long time

[Tyriar]

Thanks for the help everyone!

If anyone would like to contribute tested instructions similar to the the new RHEL install section for zypper (use heading "openSUSE and SLE based distributions") that would be awesome. This could be done via a PR to the vnext branch of vscode-docs :smiley:

[hughsie]

Would it be possible to export the AppStream metadata on this repo too? This will make the app show up in the software center when the repo is installed. See https://blogs.gnome.org/hughsie/2016/04/27/3rd-party-fedora-repositories-and-appstream/ for the fix. Please yell if you have any questions or worries. Thanks!