Add Linux software repositories for app update support

launchpad.net
would you please release atom for ubuntu , as a launchpad ppa repository?

+1

IIRC this is blocked until Atom can be built without network access.

How does the Webupd8 PPA do it?  Perhaps their method could be used for this?

They zip up builds of atom and extract it into the deb. It isn't a great solution. Ideally we would have a command the downloads but does not build all dependencies.

+1

As a alternative to launchpad, packagecloud also offers free apt repository posting and allows you to directly upload Debian packages. It's a single command to upload and would be easy to do as part of a release process. I'd be happy to help set it up if there is interest, but it would need to mostly be done by whoever uploads the official Debian packages to the atom website.

+1000
Please, please, please.

:+1:

For the rpm side of things, the openSUSE build service could be used to provide repositories for rpm based distros.

openSUSE can also build Ubuntu packages, afaik. (See e.g. the ownCloud Client repository it builds.)

@devurandom Posting the link FWIW: http://software.opensuse.org/download/package?project=isv:ownCloud:community&package=owncloud

Since nobody else wants to take the initiative, I guess I will. I wanted to avoid doing this because I am new to Linux, but maybe it will be a good learning experience. I have never compiled source code before, so if you want to help, pls let me know.

@sudopluto the point is that many people want an "official" repository from atom developers, not a 3rd party repository.
If you want a 3rd party repository hosting exactly the release .deb which are released by atom developers, there's already my repo at www.a9f.eu

@thedaniel

IIRC this is blocked until Atom can be built without network access.

Copr (the Fedora version of ppa) has a build service that has internet access. There is already unofficial copr repo here:
It would be really nice to have an official repo for updating atom since the updates are so frequent. All you need to use Copr is a source rpm package, which should be created when the rpm is built.

@sudopluto +1 for not only a PPA (Ubuntu-only)

What if it is not a PPA repository, just a generic (but official) deb
repository, like what eg. Google has?
2015-06-15 16:11 keltezéssel, Alejandro Caravaca Puchades írta:

@sudopluto https://github.com/sudopluto +1 for not only a PPA
(Ubuntu-only)
—
Reply to this email directly or view it on GitHub
https://github.com/atom/atom/issues/2956#issuecomment-112082822.

@hendricha +1 - I use Debian and Debian doesn't support PPAs, but it still has deb packages.

FWIW, Google Chrome, in its install .deb, literally adds its own repo to /etc/sources.d, and updates apt/yum/etc. accordingly. They use the built-in plumbing to update, using their repo instead of the distro's one. They don't even touch the main PPAs.
This wouldn't be a bad idea for updating, since the need for using anything distro-specific is no longer necessary. AFAIK, Google does similar with .rpm's as well, but it's only an educated guess.

@190n PPAs are specific to Ubuntu and its "official" derivatives, such as Kubuntu and Ubuntu GNOME.

And for the whole thing, definitely +1.

Worked long and hard yesterday to get to the end of the file for beautimous atom build. I see there's a block on it right at the spot I was forced to end my work as someone/thing interfered by taking me off line. I will keep checking the repository for updates but for now I have sooo many more builds I need to finish.

For what it's worth, this is partly why I installed GDebi. So I wouldn't
have to break out a command line each time I install from a DEB.
On Tue, Jun 23, 2015, 22:19 Nora Lorinda Nattress<EMAIL_ADDRESS>wrote:

Worked long and hard yesterday to get to the end of the file for
beautimous atom build. I see there's a block on it right at the spot I was
forced to end my work as someone/thing interfered by taking me off line. I
will keep checking the repository for updates but for now I have sooo many
more builds I need to finish.
—
Reply to this email directly or view it on GitHub
https://github.com/atom/atom/issues/2956#issuecomment-114702199.

Since this is obviously never going to get fixed, here's a script to run every once in a while to upgrade.
#!/bin/bash

cd /tmp
wget https://atom.io/download/deb -O atom.deb
sudo dpkg -i atom.deb

It will. Not much thought has gone into it so far, though, but if you
search the issue tracker, you should find a more detailed bug than this.
And the current issue needing resolved is the means of transmission. PPAs
are Ubuntu-specific, DEBs are not.
On Tue, Jun 23, 2015, 23:27 Asa Ayers<EMAIL_ADDRESS>wrote:

Since this is obviously never going to get fixed, here's a script to run
every once in a while to upgrade.
#!/bin/bash
cd /tmp
wget https://atom.io/download/deb -O atom.deb
sudo dpkg -i atom.deb
—
Reply to this email directly or view it on GitHub
https://github.com/atom/atom/issues/2956#issuecomment-114717070.

@impinball What about YUM repo for RPM-based distros. In that case SUSE is the odd man out that DOESN'T use YUM for RPM package management.
Either way, a PPA and YUM repo would be really nice. Especially since Ubuntu (and derivatives) and Fedora are among the most heavily used Distros for Development (besides Arch)

I use Ubuntu exclusively, so that's what I'm most familiar with. I don't
know all the details about how Google Chrome's installers work, especially
for RPM distros, since I'm not a Googler. I know it uses APT because I
upgrade it through apt-get. And I know Debian uses apt-get as well, so it's
unlikely Google doesn't use it. I honestly know little about how either is
packaged, since I deal very little with the back end of package managers.
On Tue, Jun 23, 2015, 23:42 David Hollinger III<EMAIL_ADDRESS>wrote:

@impinball https://github.com/impinball What about YUM repo for
RPM-based distros. In that case SUSE is the odd man out that DOESN'T use
YUM for RPM package management.
Either way, a PPA and YUM repo would be really nice. Especially since
Ubuntu (and derivatives) and Fedora are among the most heavily used Distros
for Development (besides Arch)
—
Reply to this email directly or view it on GitHub
https://github.com/atom/atom/issues/2956#issuecomment-114718843.

As I stated before if the packager for atom decided to use OBS then it can build packages and repos for Ubuntu, Fedora, openSuSE and more. At this point it seems more likely that visual studio code will get repo support sooner than atom, so I have switched to that as my code editor.

In case anyone wants something to help ease the the problem now (while we wait for the atom team to get time to work on an official auto-updating solution) -- I made the following (mostly for myself so no guarantee that it works): https://www.npmjs.com/package/atom-updater
Just npm i -g atom-updater, run atom-updater, and enjoy.

Small update to the above; the package I made now does auto-update (in the background).
https://github.com/mehcode/atom-updater#auto-pilot-for-systemd

This is receiving a disappointing amount of neglect.  We should have had this implemented before 1.0.
Is this going to be resolved or should we assume that the ball will continue to be dropped for Linux?

I made the following (mostly for myself so no guarantee that it works): https://www.npmjs.com/package/atom-updater

This is really cool @mehcode.
To everyone who is interested in this feature: we're sorry we haven't gotten around to it. As always, we'd love help setting it up. All of our build scripts are in the repo.

I'll go ahead and take a swing at it, though I may be slower since I'm not all too familiar with CoffeeScript.
@maxbrunsfeld, is there any significance to the package auto-updater?  I've come across it twice now but can't find any reference to it by package.json or any other parts of the project.
Also @mehcode, me like.  Mind if I possibly steal some of atom-updater's code to get this working?

FWIW, I think it would be good to choose a direction on this before anyone gets too deep in the code. :sweat_smile:
In the past we've talked about forgoing automatic updates in Atom proper in favor of native package managers on Linux. Is that still the direction we want to go with here? (@atom/feedback)

Also @mehcode, me like. Mind if I possibly steal some of atom-updater's code to get this working?

Steal away. It's served me well. Been through 3 automatic version upgrades with no problems (so far).

Well @mnquintana until some direction is expressed, I'm going to continue to work on an upgrade mechanism that is independent of package managers, as it seems that pushing to a mainstream repo would take a lot longer to discuss than it should.

We will almost surely not use the official repos (unless necessary for individual distributions). Instead we should use the approach taken by Google for Chrome/Chromium and NVIDIA for e.g. the CUDA toolkit, and that is to release a .deb (and similar) which adds an Atom maintained repository for Atom releases. That way we can leverage the distributions' update mechanism for free, yet be able to quickly publish new releases.
I'm not convinced doing it any other way is worth it given the disparity amongst the most frequently used distributions. It's much more difficult to get something Squirrel to work across all Linux distributions compared to Windows and OS X. Although I'm not a core team member, just a highly opinionated collaborator, so take this comment with a pinch of salt :speak_no_evil:

That way we can leverage the distributions' update mechanism for free, yet be able to quickly publish new releases.

+1 - This makes a mockery of apt security but it gives a good user experience for Ubuntu (and other distributions to varying degrees). What we did for Mendeley that was very similar to Chrome was:

Generate a .deb package, configured to install /etc/apt/sources.list.d/appname.list when installed and also register the key for the repository via a post-install script at the same time. This ensures that future updates must at least come from the same source as the original provider.
Use apt-ftparchive to generate a repository containing the .deb package. We use the newer 'pool' format which stores all the packages in one directory and the various metadata files under a separate directory. This enables multiple release channels and rollbacks - I'll come back that in a second.
Upload generated repository to S3 and serve it from there

The principle downside of using the system update mechanism is that the update installation experience is not as good as a custom one could be - it requires the user to type their password and is (relatively) slow if you haven't recently installed any other packages because of the way that apt reads the entire package cache of thousands of files before installing a package.

The current solution for updating that I'm working on implementing is as follows:

Detect distro
Get update information from https://atom.io/api/updates
Compare update.version from API's response, grab either https://atom.io/download/deb or https://atom.io/download/rpm depending on distro
Schedule install with quitAndInstall function, remove file afterwards

From what I understand, this is a rough equivalent of the Windows update mechanism, as per SquirrelUpdate and auto-updater-win32.
The advantages of this solution are:

Compatibility with auto-update-manager with virtually no modification of it
No additional hosting needed
Security is uncompromised; installs update as if manually downloaded, no circumventing repository lists security
Since update info is grabbed with curl -L each time, there is no need to update the mechanism if the repository location changes-- it will follow location headers

Another solution would be to have apm start handling the updates, though I can imagine this would require a lot of a work to get working.

You could also see how nodesource and docker do it:
https://docs.docker.com/installation/ubuntulinux/#installation
https://github.com/nodesource/distributions

I created a unofficial debian repository at https://packagecloud.io/joshua-anderson/atom if anyone is interested.
It is connected to travis-ci and a heroku cronjob to check hourly for atom updates and publishes them.
You can read more at joshua-anderson/atom-uploader

Dear @kevinsawicki @thedaniel,
I'll just leave this here:
https://gist.github.com/paulcbetts/4981ccdaa45398d3405b
I bet if you replaced all of the words 'slack' with 'atom', then signed up for packagecloud.io, and put these scripts in /etc/cron.daily in both mkrpm and mkdeb, a cool thing might happen!
Love and Free Software,
@paulcbetts

Dear @kevinsawicki @thedaniel,
I'll just leave this here:
https://gist.github.com/paulcbetts/4981ccdaa45398d3405b
I bet if you replaced all of the words 'slack' with 'atom', then signed up for packagecloud.io, and put these scripts in /etc/cron.daily in both mkrpm and mkdeb, a cool thing might happen!
Love and Free Software,
@paulcbetts

:heart::heart::heart:

@alanfranz is there something wrong with your repo? I just did a dnf upgrade --refresh and it says there are no updates. I checked the actuall files and atom-1.0.13.x86_64.rpm is there but the repodata file seems to be outdated.

@amayer5125 thanks for your report. It seems that an invalid RPM package had been published in the Atom releases feed, and that caused my createrepo invocation to break. It's fixed now. Next time please report at https://github.com/alanfranz/atom-text-editor-repository , I happened to read your comment almost by chance!

It seems that an invalid RPM package had been published in the Atom releases feed

@alanfranz I wasn't aware of this. What was the problem with the package?

@maxbrunsfeld I've double checked the issue (it was quite late last night); it seems that it was rather a glitch with my own upload system caused by unexpected data in the releases feed. There has been in the xml feed of the releases a release labeled v1.0.13 (Rather than just 1.0.13, probably a wrong release name since it's now gone or renamed) and there still is a 1.1.0-beta without RPM or DEB artifacts; when downloading them the library I used did not check for errors as I expected, so a rogue html file with GitHub's own 404 page became an RPM file.
Now the thing is getting corrected.

@alanfranz thanks :)

This issue is becoming very frustrating to watch. Well past the 1.0 release Linux support in Atom still lags far behind OS X and Windows. No automatic updates, no official repositories, no code signing ... This is strange given that Linux is actually more popular than Windows with Atom users according to this poll. In fact, Ubuntu alone accounts for more responses than Windows 8, and equals OS X Yosemite.
To add insult to injury, a PR implementing an update mechanism for Linux is still being ignored by the Atom team after two and a half months(!). :disappointed:
I would love to help bringing proper Linux update support to Atom, but I'm unsure how. Looking at the fate of the aforementioned pull request, "implement it yourself" is clearly not the answer. An official deb/rpm repository would be ideal IMO, and, as the third-party repos posted above show, almost trivial to implement in its simplest form (auto-publish of stable versions). This, however, is the one part where community work alone just doesn't cut it – official maintenance by GitHub and package signing with their keys is a must for many people to add a new repository to their Linux system's package manager (Chrome repo being maintained by Google works for the same reason).

GitHub has also set up a repository for git-lfs on packagecloud.io: http://www.theguardian.com/environment/2015/oct/09/mercedes-honda-mazda-mitsubishi-diesel-emissions-row
Perhaps they could do the same for atom?

@sgoblin I think you linked the wrong URL :P.

For anyone out there building Atom on a non-deb/rpm distro, I have a script I use that builds Atom from source and always grabs the latest version by parsing the release page:
https://github.com/ryanpcmcquen/ryanpc-slackbuilds/tree/master/unofficial/atom
Although it is geared toward Slackware, it could easily be modified to work on any distro (probably by changing the makepkg line).

This issue is not closed, the pull request at #9425 was rejected. Please reopen this issue immediately. Also, please tell me who I should contact in order to help setup an offical PPA.

@amingilani This issue is not closed. This remains something that we want to add, but the core team hasn't had time for this yet. This will happen eventually though.

This should be on a repository, and not a separate package download.

It was argued before what Google do. What Google do with Chrome and other packages on Debian/Ubuntu is to provide with an initial .deb download that, once installed, it also sets up the required repositories so that these are covered by the OS's normal software management tools.

@luispabon Google also does that for Chrome on RPM-based distributions using YUM or DNF as well

:+1: I'd been amazed if they hadn't.

+1

Although I agree with this issue, you should take time to open bugs in your preferred distros to ask them to package Atom, the same way they package other IDEs.

+1

@Yajo Although it might be nice to eventually have Atom in official distribution repositories this is not very convenient for projects with fast development. It takes quite a long time to publish new versions so the distribution would always be several versions behind.
Can't wait to have an official atom repo, don't quite understand what's taking so long... But I'll be patient and use one of the unofficial ways to update :)

+1

+1

+1

+1
ppa:webupd8team/atom works but an official package would be better.

A big +1 from me too

Don't we just need a Debian Developer to make this happen? Then it will just sync down to Ubuntu and Linux Mint and such.
FWIW +1

@tsimonq2 Ideally atom would host their own repository. I love the Debian software repository and hope that atom gets into there, but it also takes ~ 1 year for updates to trickle down from upstream release to Ubuntu, making it non-ideal for applications like atom with a fast development cycle.

@Joshua-Anderson At first I was going to respond with an "I don't think so," but after reviewing both release cycles and talking to a few DDs, you might be right, so what's the progress?

Atom still not support automatic update via repos in Ubuntu. So sad :(

I also created a unofficial Fedora repository. It has the following features:

split package atom, nodejs-atom-package-manager and electron
reduced rpm package size

I want to add atom to the Fedora official repository. Now it has the following problems:

need to build electron from source code
continue split atom

For Fedora/RHEL7 end user, please execution follows command:
$ sudo dnf copr enable mosuqito/atom
$ sudo dnf install atom

Please visit https://copr.fedorainfracloud.org/coprs/mosquito/atom

Since atom-updater stopped working with atom 1.7.0, and the maintainer seems to have abandoned the project, I decided to create a new cli tool in node for keeping atom up to date: atom-check-updates (acu).
install using npm i -g atom-check-updates and run as acu. Can also be used for updating beta releases acu -b. Prompts for confirmation before install by default, but can be overridden with acu -y.
Should work on any debian och rpm-based distro. Open an issue if it doesn't!

Thank you @simonkberg, works perfectly!

@ames89 @simonkberg please remember there's always https://github.com/alanfranz/atom-text-editor-repository . I don't plan to drop it soon :-)

The webupd8 ppa is still the best one for Ubuntu if someone is curious.

@1dot75cm Could you update please? I use your package and am having some bugs that I think are fixed on last release.

https://discuss.atom.io/t/why-isnt-atom-in-any-official-repository/29294/4
Too bad...
<3

I has been updated atom to 1.7.4. Currently, it is working properly.  @Yajo

atom  1.7.4-2.git6bed3e5
nodejs-atom-package-manager   1.10.0-5.git87b4bcb
electron      1.2.0-1.prebuilt

For Ubuntu users who are interested in installing snaps, I came across a r/Ubuntu post at https://www.reddit.com/r/Ubuntu/comments/4mjjsu/what_snap_packaged_software_would_you_like_to_see/d3w655r where the OP made a snap for Atom.

@1dot75cm Thanks!
@atom How about a Flatpak?
https://blogs.gnome.org/mclasen/2016/06/07/modularity-and-the-desktop/
http://flatpak.org/

I think the only distro that is pushing flatpak right now is fedora. I don't think they have it up and running.

It will come by default in core GNOME in next releases, not only in Fedora AFAIK.

Honestly I'm going to switch over to vscode because they are adding deb / rpm repos soon. I think it's funny that Microsoft is better at supporting linux users when compared to GitHub. https://github.com/Microsoft/vscode/issues/2973

Not only this, but the Github interface is exclusively for Windows and Mac OSX, which sucks.

@ericoporto GitHub interface of what? I am confused by what you said.

@edwinksl this one https://desktop.github.com

@ericoporto This issue is about Atom though, not GitHub Desktop.

+1000
After encountering more than a few issues with other unofficial repositories that do rebuilds, I have to again echo a call for official yum/dnf repos!

@lucascosti I just read that Fedora supports snaps and there is a snap for Atom (find it using snap find atom).

At least it would be nice if the landing page could show the current version, one has to download the package and install it to see if there's a new version.
A "Check for updates" option on the Help menu would be much better, but the repository is a MUST

Just saying: snaps are the future.

Or Flatpak for that matter ;)
Álex
El 17/6/2016 21:28, "Shahar Or"<EMAIL_ADDRESS>escribió:

Just saying: snaps are the future.
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/atom/atom/issues/2956#issuecomment-226860053, or mute
the thread
https://github.com/notifications/unsubscribe/AGMf1F1-X20EzBPqqGc6H1poX0d3ghnxks5qMvVBgaJpZM4CMxUh
.

Just saying: snaps are the future.

No, it's npm.

Here is a notification script one could run after startup:
var base_url = "https://github.com/atom/atom/releases";

function check(resolved) {
    console.log(resolved);
    var tag = resolved.split('/').pop(-1);
    var latest = tag.slice(1);
    var current = atom.getVersion();
    if (latest != current) {
        atom.notifications.addInfo("new version available: " + resolved);
    }
}

var request = new XMLHttpRequest();
request.onreadystatechange = function () {
    var DONE = this.DONE || 4;
    if (this.readyState === DONE) {
        check(this.responseURL);
    }
};
request.open('HEAD', base_url + '/latest', true);
request.send(null);

It's based on a python update script I'm using:
https://gist.github.com/pierriko/8f64d64b9d3212d62754
Feel free to create a package out of that.

:+1:

https://bintray.com/ seems to be free for oss projects

@digitalvapor You can always subscribe to the issue. A few of us do find it annoying when we get pinged repeatedly over some popular issue.

If anybody is interested, I wrote a small package that checks for newer linux releases and notify the user at startup (or using the check command).  It's my very first package for Atom, so it may be rough around the edges.  Feeback on how to improve is welcome though. :)
You can read about it here or install directly with:
apm install atom-beta-notifier

+1
Fedora repo would allow easier and wider adoption in Linux community.
I still forget that it's not updating itself on Linux (I use all three system versions).

Whilst we wait, I can also recommend the atom-up2date package that notifies you of new releases (including showing the notable changes): https://github.com/malko/atom-up2date

Why not do an AppImage and be done with it? Many Electron-based apps already do this. There is even a binary delta updater.

Or why not do a Snap and just be done with it?

Or why not do a Snap and just be done with it?

Because then if won't run on almost all desktop operating systems out-of-the-box. In fact, on almost none.

is there a plan on going forward from the team?

Because then if won't run on almost all desktop operating systems out-of-the-box. In fact, on almost none. According to Distrowatch

While I respect & appreciate the testing effort by Distrowatch, I believe their results are obsolete or plainly wrong. There are clear instructions about enabling/installing both Flatpak (http://flatpak.org/getting.html) and Snappy (http://snapcraft.io/docs/core/install).
Furthermore, Flatpak is shipped out of the box with GNOME 3.22 (in Fedora 25, to be released soon; and jn other distros that ship GNOME):

Installing apps in the command line is quite easy, but it’s not the best user experience. In Fedora 25, Flatpak will be fully integrated in GNOME Software and you will just download a .flatpak file, double-click it and Software will take care of the rest.

The other important point is that there should be a Flatpak/Snappy repo with updates from the upstream, as opposed to single packages like those we have now. Is that possible to achieve with AppImage?

Check AppImageUpdate for binary delta updates directly from upstream.

Not that this is going to make a real repo superfluos, but in the last release of geiger we added buttons that link to the download page of the latest packages.
Not ideal, but it's a manual step less to perform.

I fail to see how this is somehow Github's responsibility. The software is open source, it's up to the Debian/Ubuntu/Mint/... maintainers to include it in their repos if they want their users to be able to update it through the package manager. This discussion really belongs on the Debian/Fedora/... lists, IMHO.

@jrial Distributions are well known for not being willing to update packages very often. (This is the case especially for Debian.) This would mean that the packages in the official repos would be out of date. For a project as fast-paced as atom this would make the official packages not very useful.
Many projects provide their own package repositories which ensures users can get new versions quickly and easily. It's very easy to do and automate, so I'm not sure why atom couldn't do it as well...

@piit79 large Debian repositories are maintained by ordinary people. You need to poke them to have software updated.

@cblp Well, with Debian it seems to be a question of policy rather than lack of resources - they seem to include the stable version at time of release and then only include security updates.
And not having to "poke" a third party and hoping something happends is exactly the reason why own repositories would be a much better solution :) Even if there was someone at Debian willing to update atom package with new versions no doubt it would take days to weeks for the new version to get to the repository.

@jrial disclaimer: this is all just a big IMHO :-)
GitHub (or atom.io or whoever it is) takes care of distributing installers for macOS and Windows platforms, as well as providing an infrastructure to keep those installs up to date (through in-app updates).
I think you either go the "here's the source, linux binaries are packager's problem" way, and do not even provide a DEB/RPM package, or the request for some update mechanism is perfectly legit.
In-app upgrades on RPM/DEB based distros are not usually feasible or easy, and a repository is the logic choice here. Even better: a DEB/RPM package to set up the repository and its stuff (eg. key to verify package signing).
Also, distributions usually have specific goals and release policies for packages in their repos, and I'd bet they do not match Atom ones.

I fail to see how this is somehow Github's responsibility. The software is open source, it's up to the Debian/Ubuntu/Mint/... maintainers to include it in their repos if they want their users to be able to update it through the package manager. This discussion really belongs on the Debian/Fedora/... lists, IMHO.

You would not say that it's up to Microsoft & Apple to pre-install Atom and keep it updated via system updates? Atom/Electron/atom.io is managing the update infrastructure on Windows & macOS, and people want them to do the same on Linux.
That being said, things like Flatpak, Snap and AppImage are not only easier for users to install & use, they also are (or intend to be) way easier for developers to create & distribute.

Yeah, please research snap. This would allow atom to release stable, beta and daily releases that should then appear in software centers of recent Linux distributions. As far as I understand it it wouldn't require a user to add another source.
There are issues on this in the Electron package, to create a general Electron solution:
https://github.com/electron-userland/electron-packager/issues/525
https://github.com/electron-userland/electron-builder/issues/509
The Snapcraft mailinglist also responded very positive:
https://lists.ubuntu.com/archives/snapcraft/2016-November/001614.html

You would not say that it's up to Microsoft & Apple to pre-install Atom and keep it updated via system updates?

I rely on Debian to maintain packages for 99% of the stuff I have installed, from vim to thunderbird, from Gnome to the Arduino IDE. So yes, that's exactly how things are done on Linux, minus the "preinstall" part. Microsoft releases an operating system, whereas Debian releases a software distribution.
I also see some misconceptions in this thread regarding how often packages get updated. If you run the "stable" or "LTS" version of your distro, you'll only get sporadic security updates. That's by design. If you want to live on the edge, pick the faster-moving variants (for Debian that would be either Testing or Unstable).
That said, I certainly don't mind having a faster moving PPA for those of us who want to stay up to date. However, if webupd8 is happy to provide this, I don't see why github should duplicate the effort. Perhaps I missed something? I only read the first and last couple of comments on this issue, about 10-20 on either end.

@jrial while everything you write is true, some users just like to get a Linux-based operating system from their distribution and use that as a platform on top of which to run applications directly downloaded from the respective application authors' dowload pages.
For example, if a user wants a debian stable operating system, he still way want the latest Arduino application from arduino.cc.
After all, this is the model the operating systems with any decent market share on the desktop have been using since decades.

@probonopd I don't know what you have been smoking, but last time I checked iOS and Android dominate the market without you ever having to download software from the Internet.

@ericoporto desktop ;-)

A packet manager is better to manage your software, which is why Atom has the APM. You can use Chocolatey on Windows and Brew on Mac, I don't know how well those manage updates. It's a reasonable request a ppa for Ubuntu since the packet manager is the default way to grab software in the distribution.

Yes, and now distributions are transitioning to Snaps / Flatpaks as the default ways of installing apps.

@bugaevc no one has fully transitioned away from package managers yet and that won't change fully for some time. Snaps are only funny stable in Ubuntu and they haven't fully transitioned yet and last I checked, Flatpak was still in alpha or beta stage - no where close to production ready

last I checked, Flatpak was still in alpha or beta stage - no where close to production ready

What makes you think it's this way? The major version number is 0, true, but the offcial website never mentions it being not ready. On the contrary, it has been "officially launched" (read this). There are some parts that are not fully ready yet (e.g. portals -- but the basics (more than enough for Atom) are there), but I believe it's very much production ready.

no one has fully transitioned away from package managers yet

I don't think anyone is suggesting that one should entirely transition away from package managers. They are great for managing the base system, the platform, on top of which upstream-provided applications can run. At least that's how I think about AppImage.

I've been using the webupd8 PPA for a while now, but since it has now caused me (and others) a big problem (see #13238) I've been made aware that since this is an unsupported pattern, the recommendation is to avoid it.
If that is indeed the case, the atom team needs to do more to improve this experience for Linux devs. Supporting the most popular package managers (eg: apt, yum) seems to be a very reasonable bare minimum.

On the contrary, it has been "officially launched"

A matter of days before that a Red Hat/Fedora Developer wrote a blog (in response to a Snappy Press Release) where he specifically stated:

Neither Snappy nor Flatpak is at all close to being ‘done’, in the sense of being a credible system for cross-platform app distribution with buy-in from software publishers and distributions.

And that is absolutely right. Just because something has been "launched" does not mean it is stable and ready for general use. Both systems are still missing many pieces - part of that being that sandboxing doesn't work properly in X11 (last I heard anyway). To top it off, for both to fully be feature ready, they also have to BOTH work well with AppArmor and SELinux or the security claims of each are pointless as well.

Fortunately it's not as bad as you think it is ;)

Both systems are still missing many pieces - part of that being that sandboxing doesn't work properly in X11 (last I heard anyway).

Fedora 25 is using Wayland by default, yay! (OTOH Atom will still go through XWayalnd, but that's not directly related to Flatpak).

To top it off, for both to fully be feature ready, they also have to BOTH work well with AppArmor and SELinux or the security claims of each are pointless as well.

I believe Flatpak works fine both on Fedora (SELinux) and Ubuntu (AppArmor), while Snappy needs SELinux disabled (set to not enforcing). And yes, the security is not quite there yet, but we're talking ease of distribution here; let's say we trust the open-source code of Atom (and its developers).

On a final note, Flatpak and Snaps are still not heavily used by Desktop Linux users and they aren't particularly user friendly to setup either.

The former -- yes, unfortunately, yet. The latter -- no, Flatpak is installed by default on F25 and it's integrated into the Software app (https://help.gnome.org/misc/release-notes/3.22/) so that installing an app takes about two clicks.

I believe Flatpak works fine both on Fedora (SELinux) and Ubuntu (AppArmor), while Snappy needs SELinux disabled (set to not enforcing). And yes, the security is not quite there yet

Check AppImage - works on both Fedora and Ubuntu out-of-the-box, no runtime or prior setup needed.

Snap, Flatpak and AppImage seem to be best choices for upstream packaging. You forget about the distro (unless you choose Snap :laughing:) and concentrate in the app. Supporting those 3 instead of .deb and .rpm would be a good exercise.
Downstream distros can also package Atom in their packaging format if they want, because it is open source as already claimed.
FWIW, as a workaround, right now I'm subscribed to their releases RSS channel, and reinstall the rpm manually when a new one is available. Not as cool as a repo, but works.

I've just put up a PR adding preliminary flatpak support, for those interested.
https://github.com/atom/atom/pull/13293

For AppImage support, see my code at https://github.com/atom/atom/issues/4980#issuecomment-250965931

If it helps justifying the workload associated with maintaining an official PPA for Atom, some employers require/mandate the use of software from official PPAs. It's my case and I'm certainly not alone. Thanks!

@alexandreleroux same can be said for Red Hat shops and yum repo requirements. It's actually quite common at places where Linux desktops are available for work as the company wants to control what is put on users' desktops

https://github.com/Microsoft/vscode/issues/2973
I made the switch from atom to vscode ages ago.....
vscode is faster / snappier than atom, and they seem to actually give a damn about linux users

@sudopluto This is the Atom issue tracker. And like any other issue tracker, it's a place where users gather to report problems and discuss ways to improve the product it's associated with. What it decidedly isn't though, is a place for latching on to random issues and venting one's frustrations through irrelevant nonsense.

@jrial Agreed.
Although there's no denying it would be very embarrassing if vscode had an official repo before Atom ;)

I have been watching this issue for a year and a half. In this time atom hasn't addressed at all or even considered adopting one of the many community repositories available. There is zero communication from the team on this issue tracker, and there has been no progress. Like I honestly do not understand this. GitHub already has a package cloud repo for their git lfs, yet they can't do the same for atom?

@sudopluto You are correct, we haven't addressed this Issue. That is why this Issue is still open. It is something that we would like to address, which is also why it is still open. There have been lots of other things that have, in our opinion, been a higher priority than addressing this given the handful of people that we have to work on Atom. I'm sure that everyone that posts here will disagree with our choices of prioritization at some level or another, that's simply the nature of the beast. If VSCode is better for you, then I'm glad that you've found something that works for you.
For others who might be interested in actually helping with this, I did ask for help in finding something that would make creating our own package repository simple and have received no response:
https://discuss.atom.io/t/why-isnt-atom-in-any-official-repository/29294/13?u=leedohm
I've also heard about Flatpak and its ilk but we're not excited about having to support several more methods of packaging Atom for Linux in addition to the ones we've already committed to. Until Flatpak et al completely supplant the tried-and-true methods of packaging, we're probably going to stick with the packaging setups we have now.

I poked around in the git-lfs repo, and found this script for package cloud: https://github.com/git-lfs/git-lfs/blob/master/script/packagecloud.rb. I think after the build is done, someone manually runs this to push the new package to the repository.

Do you remember those old times in Windows, when you had to go to your program provider website in order to download latest version of software and keep them up-to-date?
So now, we all, Linux users, are back to those happy days thanks to Electron! :car:

@Akronix

Do you remember those old times in Windows, when you had to go to your program provider website in order to download latest version of software and keep them up-to-date?
So now, we all, Linux users, are back to those happy days thanks to Electron! 🚗

What? No. Electron's not to blame. For one thing, Windows still doesn't have a built-in solution for [Win32] app updates (or if there is one, it's not being used) -- the situation only became better because most apps found some hackish way to update themselves, including Chrome famously installing itself into user's AppData directory to skip UAC prompts, and Flash Player shipping a separate updater mini-app that's hanging in the system tray distracting users.
Fortunately, Linux has a solution for app updates -- be it traditional package managers or Snap/Flatpak -- that does not involve hacks on the app's side. Even Chrome on Linux installs itself system-wide and gets updates from its repo by the means of the package manager. I'm thankful Electron doesn't have a built-in mechanism for updating on Linux. Whatever app people create with Electron can then be packaged and shipped in various ways. If they chose to distribute individual packages (like they do with Atom), we have to download each version as you describe. If they set up a repo that would be updated when new versions come out, then we'll get updates automatically, in a native-to-the-system way -- again, nothing to do with Electron.
It's just the same situation as on Android. You can distribute individual APKs and make people download & install each version manually, or you can publish your app into a store like Google Play Store and let people get updates automatically & easily. But it has nothing to do with Java and the Android Framework.

Please remain aware that each message results in emailing and notifying at least 73 people (this isn't counting those actually subscribed, but haven't actually said anything in the issue). I'd find it much easier to track the status of this issue when the signal-to-noise ratio is low, and getting pinged multiple times a week over a comment isn't going to help that much.

@bugaevc Ok, then why mac users are getting automatic updates if MAC OS X has its own updater system?
This is what happens in practise: Mac and windows users are being automatically updated but Linux users are not.

@Akronix This issue is specific to Atom not being officially distributed on any Linux software repository.  If you have an issue with the Electron update process in general, please file an issue on the Electron repository instead.  Thanks.

@50Wliu any word on using the package cloud script that git-lfs uses?

@isiahmeadows is correct, this has gotten completely off topic. If people want to discuss things not directly related to this Issue, please move them to some other venue.
@sudopluto No, still no update because nobody has had time to work on it. When we get the chance to work on it, we'll post an update.

@lee-dohm In the meantime is there anyway to at least get something that will phone home and check for an update to Atom? That way, I'm not 6 versions out of date before I realize there's been a new release.

@dhollinger There are a couple topics like this one on the Discuss forum with auto-updating shell scripts. You may want to take a look at them and see which one works best for you.

@dhollinger As already said in this post, you can use geiger package to get notified when new versions are released.

A major competitor of Atom — Visual Studio Code (VSCode) now has its own Linux repositories (both Debian and RPM package repos). Not sure if anyone else shares this opinion, but in my opinion, this fact makes Atom look like an inferior product or at least, an inferiorly distributed product. Especially seeing how Atom is older than VSCode! Can we please fix this source of embarassment?

Unwatching this bug after waiting for two years. It's not gonna happen folks. If you are on ubuntu you can try ubuntu make. Or you can just switch to vscode like I have.

@sudopluto I agree it seems like Linux will always be the underdog of the officially supported platforms of Atom, without an official auto-update mechanism, although I've developed a preference for Vim as an Atom alternative. Faster, uses less RAM and like a beloved pet will follow you anywhere (any operating system, any instruction set architecture, any user interface [graphical vs. command-line], etc.).

There is a perfectly usable ppa for Ubuntu. Just search for it.

Yeah but it's unofficial and usually lags behind by at least a day behind the latest releases. Atom also has an unofficial Copr for Fedora but it also tends to lag behind a little behind the latest releases of Atom.

I can live with a day. If I really needed it fresher than that I would build it from source.
I know people who use Arch who do exactly that.

At least a day, usually it's more than a day. Like the 1.13.x series of Atom was never even packaged by that PPA, rofl. So for over a month it was out-of-date.

Well this is open source software. If you feel strongly then help to sort it out. Start a ppa even.
I suspect that the emerging snap/flatpack approach will make packaging software for multiple Linux distributions much more straightforward.
There is always the option from building from source too.

The solution I am here supporting is not an unofficial PPA for Atom, which you seem to prefer, but that the Atom development team provide their own official Linux repositories for Atom, like VSCode's developers have for VSCode. I already have my own way of keeping Atom up-to-date using shell scripts. Users with less skill with shell scripting won't have that option, hence why a official Atom Linux repos are likely the best solution for everyone.

No I don't prefer unofficial ppas. I can however see the challenges and costs of supporting multiple Linux distributions and versions. Once snaps or flatpacks or similar become mature it should make the distribution of Linux software much simpler. When that happens I'm sure Atom will provide an official package.
In the meantime I personally am grateful for Atom given I don't pay anything for it so I'm happy with the way things stand.

Oh and I already provide a cross-distribution Linux package for Atom, specifically an AppImage https://bintray.com/fusion809/AppImages/Atom#files. I update it regularly. The only things it needs to be run are:

A 64-bit Linux distro with at least version 2.14 of glibc
FUSE setup.

Well that sounds great 😀.
Surely the way forward?

Well it doesn't have an auto-update feature though. Every new release ya have to re-download it, unless @probonopd (the original and lead developer of the AppImage format) can offer a solution. I have heard of delta downloads, is it possible for me to add an auto-update feature to this AppImage?

Absolutely, shouldn't be much of a problem.

Well I've no experience of AppImage but I've played with snaps and they do support updates.
I'm going to read up on AppImage..

Ironically they're older than snaps and flatpaks. I've added a new issue on creating an auto-updating AppImage for Atom, per the above issue reference.

A really large number of Electron-based and other applications are distributed in AppImage format for Linux these days: https://github.com/probonopd/AppImageKit/wiki/AppImages

Visual Studio Code (VSCode) now has its own official Linux repositories (both Debian and RPM package repos)

That's enough a reason to chose VSCode over Atom if you running a DEB or RPM-based Linux distribution. It is very convenient to install the package once, and then let your package manager handle the updates automatically. If Microsoft can do it for VSCode, I wonder why this cannot be done for Atom.

A really large number of Electron-based and other applications are distributed in AppImage format

Flatpak is getting a lot of traction these days, and support desirable features such as auto-updates. See this discussion.

May I note that each and every message here hits 76 people with both a notification and an email?

correction: 75 people, I'm out of here, this has become ridiculous.

I'm one of those that are switching to vscode, due to the packaging support.
PS: This kind of thread reminds me of this https://github.com/adobe/brackets/issues/10255

I am also looking for an official RPM repository for Linux. It would be great and it is not a hard task. Microsoft provides VS Code repository for a long time. It is really a great experience: you do not to download package from web page manually every month.

Atom is now available as a snap package:
sudo snap install --classic atom
The only problem is that Atom doesn't start in a independent process by default. You have to do atom & every time.
(Tested on Linux Mint 18.1)

Is this an official distribution maintained by the folk at GitHub, or still the Nth unofficial one, maintained by some good-willed person?

The snap seems to work well on Ubuntu, thank you :+1:

If it was developed by Atom's team I'd expect a member of Atom's development team to be announcing it here.

Answering one of the first comments, Chrome's deb package installs chrome repository to system along with chrome itself. I think it won't be a big headache to do the same with atom

@quasipedia It is not maintained by GitHub team.

Chiming in to request an official PPA for Atom on Ubuntu. I don't want to rely on some third-party repo and manually updating is tiring.

Elementary just released their new AppStore, maybe that's interesting?
https://developer.elementary.io/
https://medium.com/elementaryos/building-the-future-of-elementary-os-9df3fa940b67
https://medium.com/elementaryos/new-release-elementary-os-loki-0-4-1-2a756549ee76

Snaps have a long way to go before they can be as useful as a debian package. For starters, the sandboxing snaps use means that sometimes a program cannot anything outside the sandbox, so it will not recognize that other applications are installed (for example, if you want to open a file in your browser from within a "snapped" app.
Not only not an ideal solution, but a bad one.

can Anyone eplain the tasks involved in soving issue:: Add Repo During Install of Deb Package for Automatic Updates

Just a note: I think it should be enough to create the repositories. Atom is an editor for programmers, and I'm pretty sure that a programmer knows how to add an extra repository to his/her system.
I just comment that in case the problem is in creating the code that automagically adds the repository in the system when the package is installed. It makes sense with Chrome because that is a software for everyone, but I think that is not the case for Atom.
This also has the advantage of avoiding problems with people who don't want foreign repositories in their systems...

Its really mind boggling to me how there can be official .deb builds but you refuse to do a official PPA or a snap.

@nextgenthemes your comment was deleted as a violation of the Atom Code of Conduct as it was insulting or derogatory. You may consider this an official warning.

Despite the rudeness of @nextgenthemes comment, his point remains valid. No proper update channels via an official Debian repository or snap package is a problem. I had to personally request updates to the community maintained snap package.
Meanwhile, vscode maintains an official Debian repository and is in the process of releasing an official snap package. Just saying.

 Warning? What do I win if I continue to use this horrible word?
Yeah its embarrassing M$ will soon have both, official debs and snaps. That unofficial PPA might be someone who is on his way of collecting enough people updating on it and then at some point starts to ship malicious code to thousands of people. I know its the webup8 team, the risk is probably low, still its not impossible.
Well my guess is that Github staff would run around starbucks or where with ssh keys open to a official repo anyway judging by this lack of giving a ... see I behaved there. Happy?
Also I do not know in what way the unofficial repo follows a official build process as I have read something about it being complicated.

No proper update channels via an official Debian repository or snap package is a problem.

I agree, that's why this issue exists and is still open.
Also though, if someone's point is valid, then they don't need to be abusive in delivering it. The Atom maintainer team lots of work to do, it is true. We're here to work with people who want to work with us to make something awesome. In the wise words of Lieutenant General Jay Silvera, superintendent of the US Air Force Academy:

If you can't treat someone with dignity and respect, then you need to get out.

And for the record, I appreciate your ability @ghisvail to express your frustration without resorting to rudeness.

Also though, if someone's point is valid, then they don't need to be abusive in delivering it.

Totally agreed. Hence myself focusing on constructive arguments.

I appreciate your ability @ghisvail to express your frustration without resorting to rudeness.

You're very welcome. I am also in touch with the snapcrafters team which maintains the unofficial snap packaging. Ideally, it would be to converge to something more streamlined in the short future.

After the recent discussions and obvious user frustration I have to ask, is there a technical reason this can't happen at the moment (it doesn't seem like it)? If not, what would it take to get this prioritized?

The technical reason is that nobody on the Atom team is familiar with the process to set up the various auto-update infrastructures for .deb and .rpm using distributions. Snap and the like are useful for an even smaller subset of the Atom Linux user base than what we have now, so we're reluctant to go "all in" on any one of those. And supporting all of them is not sustainable for us.
We can reliably produce .deb and .rpm packages, obviously. What we need is step-by-step instructions on how to go from there to auto-update distribution endpoint for both package types in a day or less. If someone can supply that so that a Linux newbie like me can get it up and running, then I'm willing to give it a shot.
But it seems that @paulcarroty has supplied us with just that, so I'll have the team take a look.

What @paulcarroty put together looks decent enough. If that doesn't work out I've done some work with aptly in the past and it was relatively painless (I didn't originally set it up, only used it afterward) but this was also a few years ago. The major downside is that it aptly doesn't support .rpm packages (AFAIK).
See: https://www.aptly.info/tutorial/repo/ and https://www.aptly.info/doc/aptly/repo/add/

Both the main RPM distros have platforms for build and distribution that could be used:
https://copr.fedorainfracloud.org/
https://build.opensuse.org/
(Launchpad can do the same for Ubuntu)
Alternatively there are docs on how to build a hosted repo here:
https://github.com/rpm-software-management/createrepo
http://yum.baseurl.org/wiki/RepoCreate
https://wiki.centos.org/HowTos/CreateLocalRepos
Arguably though given that atom (and vscode) will no doubt want to ship more frequently than the underlying distros and have their own dependency characteristics flatpak and snap are the intended solutions for this, even if not widely adopted yet.

@carwyn why OBS, Copr, Launchpad and other distro-specific services is bad in this case, the quotes of SUSE Chairman:

If Atom had a build process that didn't need to download random crap from the internet I'd love to see it officially in openSUSE
How does that in any way verify anything? The build program could've downloaded malware for all I care, and it'd just as happily log the exact same thing.
That's what we do for Python, Ruby, and every other language. If a program depends on a dozen things, we package those dozen things independently. The fact that Node makes this a living hell is not openSUSE's fault.

Shortly, the classic Linux build services only supports the build process without Internet connection. Atom use a lot npm packages with unstable dependencies, create the needed tarball with all sources for each release isn't easy.
@lee-dohm I've added more comments. That's not the work for Senior DevOps Engineer, a boy from school will be enough :)

Shortly, the classic Linux build services only supports the build process without Internet connection. Atom use a lot npm packages with unstable dependencies, create the needed tarball with all sources for each release isn't easy.

That's why I'd rather have a flatpak for Atom (Snap is too much Ubuntu-centric in my eyes)

Snap is too much Ubuntu-centric in my eyes

I am sorry what?

@ghisvaiol

developers have to sign a CLA if they want to work on snap
snap has only one repo hardcoded (hosted by canonical). You can't use several different repos like in flatpak (e.g. flathub and gnome-apps)

@paulcarroty are these derogatory jabs at the Atom team really necessary?
I quote:

Why is it so hard to do it for the Atom Team? ~30 lines of code!

from here. And

That's not the work for Senior DevOps Engineer, a boy from school will be enough :)

in this thread. And I believe I saw another one which expressed a similar sentiment, although I could be mistaken.
These folks put a lot of effort into a piece of software which they share freely with the world. They deserve better than to constantly being attacked for the things that go wrong or that haven't been finished yet.
We now have a FOSS editor which is easy to hack, has an extensive ecosystem of useful packages, and is mature enough to use as our main development tool. Compared to that, I think a few annoyances like the occasional bug or lack of official repositories are minor issues and not something deserving of these below-the-belt remarks.

developers have to sign a CLA if they want to work on snap

And?

You can't use several different repos like in flatpak

And?
Does the end-user care?
Both flatpak and snap are worth considering from a technological merit. As an end-user however, the fact is I can install a reasonably up-to-date version of Atom via snap today. Can I do the same with flatpak, maybe?

I completely agree with @jrial.
Atom is great and we need to see some respect for those who put their time and effort towards making it so.
The bad attitude of some on this thread is not at all helpful.

Well Atom already has a cross-distribution package, besides the tarball. NixOS has an Atom package in their official repositories and their package manager, Nix, can be used on any Linux distribution. I've even used it to install packages on my Arch Linux system with the Arch packages have things wrong with them.

@paulcarroty Copr actually does allow packages internet access during the build, that's why there's a few Atom packages provided by Coprs like https://copr.fedorainfracloud.org/coprs/mosquito/atom/.

Well, I've setup the apt repo on bintray for Zulip's linux client. Here - https://bintray.com/zulip/debian/zulip-electron
@lee-dohm I can help you out if you want.

@ghisvail
a CLA means Canonical can change the license terms any time. This introduces a kind of uncertainty concering the sustainability of snap (similar to the situation at ownCloud that led to its fork Nextcloud).

Does the end-user care?

The end-user cares about being able to get the latest software release. S/he doesn't want to change technologies all the time to get the software. With snap being dependent on Canonical's goodwill (license- and infrastructure-wise) it doesn't sound like a sustainable solution at the moment. Just think of Mir and Upstart and how many technology changes it meant for Ubuntu users in the end.

Both flatpak and snap are worth considering from a technological merit.

Yes, but that is not my point. Atom can/should be offered within both formats, but only offering it as a snap and not as flatpak doesn't make sense in my eyes.

Can I do the same with flatpak, maybe?

This is not integrated into a flatpak repo so a user is still stuck with updating manually.

[...] This introduces a kind of uncertainty concerning the sustainability of snap

I don't buy it, sorry. Your statement is speculative at best, if not edging towards FUD.

The end-user cares about being able to get the latest software release

Which both snap and flatpak are designed to provide, correct?
The rest of your point (your personal assessment of Canonical's past failures and infrastructure) is purely subjective. Meanwhile, similar software such as Microsoft vscode and jetbrains intellij and pycharm are now installable via snap. It seems these major companies do not share your concerns about Canonical.

Atom can/should be offered within both formats, but only offering it as a snap and not as flatpak doesn't make sense in my eyes.

The Atom snap is essentially ready for integration with upstream, thanks to the work from the snapcrafters community. The same happened to vscode, whereby this very same community did the initial investment, and then helped integrate snap builds within the upstream release process.
How much work would be required to achieve the same with flatpak?

This is not integrated into a flatpak repo so a user is still stuck with updating manually.

So much for transparent updates then, which is the topic of this issue I reckon.

@ghisvail I never said there shouldn't be snaps for Atom. I said there should be both, snaps and flatpaks. Do you really have any objections to having both?
There are several examples of Canonical's failures (Mir, Upstart and now Unity) and they all suffered from NIH-ism and not making it part of a greater community effort. Unfortunately I see the same happening with snap. I'd be happy if it doesn't turn out the same way

So much for transparent updates then, which is the topic of this issue I reckon.

huh? It's only one commit and one pull request from https://github.com/flathub/flathub/ (or other repos) away.

The current issue with flatpak-builder (tool that automates flatpak building, also used by flathub bot) is that it still doesn't directly support custom installers such as npm/pip/yarn... When this feature is support I am certain that someone will make the pull request for atom ( If no else does I surely will :P). Have I look at https://github.com/flatpak/flatpak-builder/issues/15.

I never said there shouldn't be snaps for Atom.

Quoting yourself earlier (emphasis added):

I'd rather have a flatpak for Atom

If not said explicitly, that's strongly implied please.

Do you really have any objections to having both?

I don't. I am just questioning the amount of work required to integrate flatpak upstream. So far, your arguments have been focused on ideology and your personal assessment of technical merit.

There are several examples of Canonical's [...]

Ideology and personal assessment again...
Meanwhile, I have been asking essential questions which have yet to be answered. Can you install a recent version of Atom with flatpak today, and would the resulting packaging files be easy to integrate to the upstream release process? Perhaps @adityashah1212 could answer these.

Can you install a recent version of Atom with flatpak today

No you can't

would the resulting packaging files be easy to integrate to the upstream release process

Yes, since it is just one json (about 100 lines maybe, possibly even less).

As far as my opinion of snaps, there are a few fundamental gliches

It relies on AppArmor for sandboxing, thus any distribution not having AppArmor is going to run a snap without a sandbox. Which in itself proves that it doesn't provide the same environment across all linux distributions which is supposed to be its primary goal. Comparing flatpak to it, even though it relies on kernel namespaces (which is not be supported by all distributions), it still provides fall back to setuid based sandboxing

Size of the app, I don't know the current state but if I remember correctly firefox snap turned out to be 1GB... thats insane. It may not be that big anymore, but there is no concept of runtime, thus every application carries everything, thus bloating it. Flatpak has 3 main runtimes, namely freedesktop (bare minimum libraries), gnome (suitable for gnome and gtk based application) adn kde (suitable for kde and qt applications). Also it uses ostree to deduplicate files even across applications.

I also remember reading, Canonical asks you to sign contributors agreement when contributing to snaps and their repo (really questionable in open source world).

Advantages of snaps

It can deploy server grade application, while flatpaks are only meant for desktop gui applications. But again why do you need snaps on servers, you can always use docker.

Can you install a recent version of Atom with flatpak today

No you can't

AFAIC, the discussion should just stop right here.

It relies on AppArmor for sandboxing [...]

Irrelevant. The topic of this issue is on updates, not sandboxing.

Size of the app

snap info atom tells me the Atom v1.21.1 snap is 181MB in size. Sounds reasonable to me, what do you think?
FYI:
snap info intellij-idea-community -> 419MB
snap info pycharm-community -> 189MB
I'd be curious to hear which sizes are achieved with flatpak for these 3 apps.

if I remember correctly firefox snap turned out to be 1GB... thats insane

snap find firefox yields nothing. No idea where you got your numbers.

there is no concept of runtime [...]. Also it uses ostree to deduplicate files even across applications.

I'll ask again: does the average user care? What does it have to do with updates?

Canonical asks you to sign contributors agreement [...]

Same question: does the average user care? What does it have to do with updates?
Personally, as long as I can simply run snap install (or flatpak install) and have transparent updates provided by upstream, I don't mind the underlying piece of technology providing it. Nix packages (mentioned earlier) also look interesting.

The discussion seems to have drifted somewhat - I think the original thread was to get the existing .deb and .rpm files into a repo form so that auto-updates could work using the existing mechanisms built into the OS. Snap and Flatpak support (or any other package formats) seem to me like they should be separate issues for each new format.

@iainhallam Thank you, and I agree. Could we please try to limit discussion a little, since there's a lot of people subscribed to this issue? Also, for the discussion we do have, can we keep it specifically to stuff that will work with what is packaged within distros, like APT, RPM, and friends?

For Flatpak this separate issue is #11837 (#13293 is a pull request related to this). For AppImages it is #13118. Can't find one for Snap.

Seriously?!? This issue is >3 years old and nothing happened. Still no official repository.
I check the repository, there were multiple PoCs for pushing to repositories.
https://github.com/atom/atom/issues/15901 https://github.com/atom/atom/pull/9425 https://copr.fedoraproject.org/coprs/helber/atom/
There are so many attempts to make this happen, everywhere: https://discuss.atom.io/t/why-isnt-atom-in-any-official-repository/29294/15?u=sheogorath
You already have RPM and DEB files. All you need to do is sign and push them to some kind of provider.
Sign RPM
Sign DEB
Push them to packagecloud from TravisCI
I really don't see the problem. That's less than 4 hours of work, including debugging. And what do we get out of it? Security! And an issue with more than 200 comments and way more supporters solved.
Atom is such a wonderful project and I understand that there are sometimes more important topics, but implementing this are less than 10 lines of code in your .travis.yml and adding one or two signing keys somewhere. It's not like you need to invent anything. Of course there are more places than packagecloud to host your packages, but it's one of the simplest ways and they provide all needed docs in place.
And if it's still too much work to do this, please tell what you need to provide this so we can help to provide it. Because it would really, really help to keep our Atom setups up to date and prevents hundreds from people from reinventing the update process, like writing ugly shellscripts that run as cronjob or systemd.timer to check if there is a new atom version.
Thanks a lot and please, please provide a little bit of attention to make this happen.

And please stop posting the HOWTOs.  LOL. They just do not want to do it and probably laugh from these comments.
And yes, I saw your project and as you may notice, it's indirectly linked in the comment.
My point is: As it is not that hard, it would be nice to just make it happen or close the issue as won't fix.
But the official statement was: "We have not enough time to do this" which leads to my point that it's not that hard.
And your repository still doesn't provide signed RPM builds. your repos are signed, but not the packages since you provide them 1:1. And the other way around is way more important because signed packages can be mirrored without losing any trust.

And your repository still doesn't provide signed RPM builds

I can sign the packages with one line of code, but after the hash sums will be different and you will can't verify signed packages with original anymore.

@paulcarroty - When in a hole... stop digging!!!
What you call "emotional shit [that] is not more than screaming in emptiness", was a pretty much excellent summary of where we are at.  A 3 years old ticket that takes very little time to implement, delivers tremendous value to GNU/Linux users, and on which - most importantly - GitHub failed to communicate properly.
It was clearly also meant to "sting" GitHub devs enough for them to wake up and either make this happen or explain why it won't fix (chances of the post being effective at that: low. But I'm happy to take the risk of wasting 20 seconds of my time reading @SISheogorath post if there is even a small chance of it working).
Since you seem to have misunderstood how the security model on package repositories is supposed to work (something that @SISheogorath attracted your attention on in their closing paragraph, and that is highlighted even more from your subsequent reply) I understand that you may not appreciate fully while none of the workarounds posted so far (from yours to mine) can be considered "good enough" and while some of us cant't believe this hasn't been done already.  Your lack of understanding is not a good reason to be rude or shutting other people up though.

Indeed. The problem is trust that the app you're downloading hasn't been tampered with, and the only real way to trust that is via official repositories.
Atom has access to your ssh keys, your github account, etc.

Can somebody please lock this issue? There are almost 100 subscribers and it seems evident that all of the necessary information has been exchanged.

Since you seem to have misunderstood how the security model on package repositories

No, I completely understand that unsigned packages is bad for security. From another side, RPM and DEB repos has built-in hash sums control which guaranties the integrity of downloaded packages.
The code still open - let's suggest the better model.

hash_sum !== trust. I can't trust you haven't been messing with the code before building it.

Issue atom

50Wliu deleted a comment from zalew16

Oh and packages on debian should slowly be built reproducible.

Duplicate #16317 was mine. So sorry I didn't see this before. Here are some of my core arguments from #16317:

The recent XSS vulnerability in Atom has been a reminder, that repos for automatic updates are needed. (https://statuscode.ch/2017/11/from-markdown-to-rce-in-atom/)
Atom should ask the user on the first startup, to add the repo to the package manager. (also having an setting option to undo/repo that) Adding the repo then would mostly be an xdg-su -c '...' command.
I though about asking some major Linux distros to include Atom in their own repos. But on the one hand that would be a lot of distros and they wouldn't deliver all those Atom updates being publishes while their distro is in stable state. And on the other hand all that's needed to be done for the Atom project to run repos is providing one repo for rpm, one repo for deb and put in the already existing atom-amd64.deb and atom.x86_64.rpm files. As long as Atom doesn't need custom rpm/deb files for every distro (and it doesn't looks like it does: https://github.com/atom/atom/releases), one repo for rpm and one for deb is all that's needed.

Or just one Appimage that can run on every distribution. It somehow got rejected.

@Serkan-devel - ...and for a hoist excellent reasons, given that this issue is about adding software repositories, honouring the dependency and trust models of linux distros, and others have already remarked on how the conversation derailed. :)
I suggest you open/follow another issue if you would like portable installations (Flatpack, Appimage, Snap...).  The two have close to nothing in commonand I definitively won't delve in a comparison of their merits here... but most definitively "Appimage" (and Flatpack, and Snap, and...) is the wrong answer in this conversation. ;)

Hey everyone, early Christmas present from the Atom team: official Linux package repositories for .deb and .rpm based distributions!  You can check out the updated Linux installation steps in the Flight Manual to learn how to set this up.  Please give these package repositories a spin and let us know how they work out for you.
Thanks a lot for all the great feedback!

Works flawlessly on Fedora.  Marry Christmas (Happy holidays?) to the Atom team too! 🙇 💜 💯

Thanks a lot for this early but wonderful Christmas present! Merry Christmas and a happy new year to the Atom Team!

:tada:

Thank you Atom team. It may have taken almost three and a half years but let us not complain about the past but be grateful for the present.

Fedora 28 is not supported yet. :cry:

@Superdanby Not exactly surprising is it given that Fedora 28 hasn't been officially released yet? It's just preview releases that are available.

That is the reason   consentrate on you will need to unique placement of feet some time before   authoring. Will likely be doable to help far more suitable writing in this   fashion. | Software House


schema: Clarify module and package terminology.

This lines up the terminology with RFC 698 and avoids confusion
due to usage of 'package' with two different meanings.
I renamed one of the packages to package-descriptor as a temporary
"fix" earlier, but I finally (re-)understood what it actually meant.
Test plan
n/a

This resolves part of the discussion in https://github.com/sourcegraph/scip/pull/38/files#r887249371


Distributed inference using HF accelerate

closes #1
Due to code formatting tools the chnages are not clearly visible in diff. Use feat: distributed inference to view code changes.
Added boolean distributed flag to FactChecker. Latest run: https://sapphire-kordula-12.tiiny.site/

But using distributed inference, the output is:
{'claim_sents': [{'success': False,
                  'txt': 'CMU is a top-ranked university located in '
                         'Pittsburgh.'},
                 {'success': False,
                  'txt': 'It was formed by merging Carnegie Institute of '
                         'Technology, Mellon Institute of Industrial Research, '
                         'and the Cranberry Lemon Institute.'},
                 {'success': False,
                  'txt': 'Its business school was ranked 15th in the US by '
                         'Bloomberg Businessweek.'}],
 'reference_sents': ['Carnegie Mellon University (CMU) is a private research '
                     'university in Pittsburgh, Pennsylvania.',
                     'The institution was formed by a merger of Carnegie '
                     'Institute of Technology and Mellon Institute of '
                     'Industrial Research in 1967.',
                     'In the 1990s and into the 2000s, Carnegie Mellon '
                     'solidified its status among American universities, '
                     'consistently ranking in the top 25.',
                     "In 2018, Carnegie Mellon's Tepper School of Business "
                     'placed 12th in an annual ranking of U.S. business '
                     'schools by Bloomberg Businessweek.']}

Instead of
{'reference_sents': ['Carnegie Mellon University (CMU) is a private research university in Pittsburgh, Pennsylvania.',
  'The institution was formed by a merger of Carnegie Institute of Technology and Mellon Institute of Industrial Research in 1967.',
  'In the 1990s and into the 2000s, Carnegie Mellon solidified its status among American universities, consistently ranking in the top 25.',
  "In 2018, Carnegie Mellon's Tepper School of Business placed 12th in an annual ranking of U.S. business schools by Bloomberg Businessweek."],
 'claim_sents': [{'evidence_labels': [0, 2],
   'todelete_spans': [],
   'replacement_strings': [],
   'txt': 'CMU is a top-ranked university located in Pittsburgh.',
   'success': True,
   'edited_txt': 'CMU is a top-ranked university located in Pittsburgh.'},
  {'evidence_labels': [1],
   'todelete_spans': [[57, 58], [98, 133]],
   'replacement_strings': [' and', ''],
   'txt': 'It was formed by merging Carnegie Institute of Technology, Mellon Institute of Industrial Research, and the Cranberry Lemon Institute.',
   'success': True,
   'edited_txt': 'It was formed by merging Carnegie Institute of Technology and Mellon Institute of Industrial Research.'},
  {'evidence_labels': [3],
   'todelete_spans': [[30, 35]],
   'replacement_strings': [' 12th'],
   'txt': 'Its business school was ranked 15th in the US by Bloomberg Businessweek.',
   'success': True,
   'edited_txt': 'Its business school was ranked 12th in the US by Bloomberg Businessweek.'}]}

As in readme.

Any thoughts on the different results?
cc: @kukrishna

Any thoughts on the different results?
cc: @kukrishna

Hi. The results contain 'success': False. This just means that the inference failed. This is almost certainly because of some error such as things running out of memory or tensors being on incorrect devices.
I have a try-catch block here: https://github.com/kukrishna/genaudit/blob/703af800ed1c12c95c8388c0be20e655c039e9ed/genaudit/factcheckers/base.py#L107
It's kept there so that even in case of any error the model gracefully fails and returns so that the frontend UI does not keep waiting for it.
If you remove that try-catch block then you will get the real reason for the failure printed on screen.
Unfortunately I am occupied for the next two weeks and will be able to look at this issue only after that.
I can mention one thing that I've tried in the past with another project and had worked well for me. Passing the parameters below in the .from_pretrained() call  should distribute the weights among the given GPUs (assuming you have 2 gpus each with 24GB memory) :
    device_map="auto",
    max_memory={gpu_idx: "24GB" for gpu_idx in [0,1]}

max_memory={gpu_idx: "24GB" for gpu_idx in [0,1]} did the job without the need for hf accelerate. Thanks!


fix(blank searches on search page): fixing case where someone issues a null query on the search page

This was fixed on a few other pages successfully but this check was actually referencing an external variable. Updated to check the new query rather than the old one.
Checklist

[ ] The PR conforms to DataHub's Contributing Guideline (particularly Commit Message Format)
[ ] Links to related issues (if applicable)
[ ] Tests for the changes have been added/updated (if applicable)
[ ] Docs related to the changes have been added/updated (if applicable)

fixes https://github.com/linkedin/datahub/issues/2733


add about page

Can we close #61 now?

@CrazyMarvin Everything's alright?

For what is this string needed?
No app can handle this action.

For if a browser or email app is not available?

I see, that's good. 👍

Thank you very much! 😊


feat(driver,iocp): add WaitCompletionPacket support

This is a rework for #264 . It introduces internal NT APIs (actually documented, but internal) behind a feature gate. These internal APIs avoid creating another thread pool to wait for event objects.
This new feature is disabled by default, and users should explicit import compio-driver to enable it.

I will merge this PR because no one could review the correctness of the new feature. I will try to ensure it work. Anyway this new one is disabled by default, and the thread_pool (old) one has been proved to work for a long time.


fix(package): add babel-template

Fix unmet peer dependency on npm install

Hmm, this is a pity.  It's a requirement of my code-split-component, but babel-template comes along with the other babel dependencies of the project, it just isn't added explicitly.  Pity that the dependency check isn't intelligent enough to pick this up.

Fixed in https://github.com/ctrlplusb/react-universally/commit/36b0338e93f10a7cd3962761f09abc9a88bc5612

Nice, thanks @kvnsw


Design implementation of NFT info page

I didn't implement a small screen version yet. For small screen versions, I just would put the NFT-specific info column (on the right) between the image and the drop information on the left side.
No functionality (fetching data) is implemented except for switching the group size of the NFT card container at the bottom. Copying to clipboard works as well with older browser support.
Functionality of the NFT info page is another whole user story, maybe even two.
I implemented the designs for the different scenarios which can be seen by setting individual variables to null, false or non-null, true.
The price and "place order" button is not always shown. It's hidden if there is no price (if NFT is not for sale at the moment).

I took a long time to think about how I want to do the changes. I set the visibility of the content editing buttons to "hidden".

Could someone verify whether the Wallet works? Changing Password works for me.
When I connect the wallet, I get an AppwriteException that I cannot execute a task for role "" because my role is "member". Seems like it expects wrong permissions on my side.


fieldmap-less SDC in v. 23.2.0a2 producing odd/distorted results

What happened?
Version 23.2.0a2 of fMRIPrep is producing good-looking (non-distorted) susceptibility distortion corrected functional images for my dataset, when the SDC is based on acquired fieldmaps, which is great. But I've several subjects in this dataset for whom we don't have fieldmaps, so for them I tried the fieldmap-less SDC option (via the --use-syn-sdc option). Unfortunately this produced unusual-looking images, as shown in the attached files. (These are of my own brain, which I am happy to share.)

What command did you use?
cmd="${SINGULARITY_CMD} ${SING_BIDS_DIR} ${SING_BIDS_DIR}/${DERIVS_DIR} participant --participant-label $subject -w /work/ -vv --omp-nthreads 8 --nthreads 12 --mem_mb 30000 --output-spaces MNI152NLin2009cAsym MNI152NLin6Asym --ignore slicetiming --skip-bids-validation --use-syn-sdc --fs-no-reconall"

What version of fMRIPrep are you running?
23.2.0a2
How are you running fMRIPrep?
Singularity
Is your data BIDS valid?
Yes
Are you reusing any previously computed results?
No
Please copy and paste any relevant log output.
No response
Additional information / screenshots
No response

Yes, I thought this would come up. I've been focusing on the other methods to the exclusion of syn. I'm not positive I'll have time to track this down before the release. Possibly we should just disable it until we have time to fix it.

Hi @effigies, I also met the same problem as @atkinsonap  with  --use-syn-sdc option using fmriprep v. 23.2.0a2. The problem presents in the final image and in the "desc-coreg_boldref" image but NOT in the "desc-hmc_boldref" image. I think the problem is related to the fieldmap estimation from sdcflow.

Should have been fixed - please reopen if not


Windows Executable Fails on Zulu JDK 8

> java -version
openjdk version "1.8.0_152"
OpenJDK Runtime Environment (Zulu <IP_ADDRESS>-win64) (build 1.8.0_152-b16)
OpenJDK 64-Bit Server VM (Zulu <IP_ADDRESS>-win64) (build 25.152-b16, mixed mode)

Running exe:

Most probably your windows executable can't work with Java other then Oracle (OpenJDK in yourcase)

In case this helps someone, here's a hack
https://github.com/deathmarine/Luyten/issues/273#issuecomment-1038486326