Spec URL: http://www.hmg.eti.br/static/rpm/nodejs-atom.spec SRPM URL: http://www.hmg.eti.br/static/rpm/nodejs-atom-0.123.0-1.fc20.src.rpm Description: This is a open source editor from github. I just create a rpm compiling package based on nodejs and grunt build. moving library to sub-package. https://atom.io/ https://github.com/atom/atom I would appreciate a review so that i can get into Fedora! If you got errors building this source package probably you need new version of gyp compiler. I just create another package updating the old one, based on gyp-0.1-0.11.1617svn.fc20.src.rpm http://www.hmg.eti.br/static/rpm/gyp.spec http://www.hmg.eti.br/static/rpm/gyp-0.1-0.11.1967svn.fc20.noarch.rpm http://www.hmg.eti.br/static/rpm/gyp-0.1-0.11.1967svn.fc20.src.rpm Fedora Account System Username: helber
Just a random question: Why not simply call it "atom"? At least for me it more sounded like a nodejs package while it is in fact a full application... So I would not even need to know about the fact that nodejs runs all this if i just use it... Just my 2 cent and only my opinion. Do not take this as a too strong recommendation ;) Regards, Erik
(In reply to Erik Schilling from comment #1) > Just a random question: Why not simply call it "atom"? > > At least for me it more sounded like a nodejs package while it is in fact a > full application... So I would not even need to know about the fact that > nodejs runs all this if i just use it... > > Just my 2 cent and only my opinion. Do not take this as a too strong > recommendation ;) > > Regards, > Erik Good point. This peace of software is based on chrome, and nodejs (coffescript, js). But as editor is more clear atom. I will change package name to atom. Regards, Helber
Follow Erik recommendation: I change package name just to atom. Spec URL: http://www.hmg.eti.br/static/rpm/atom.spec SRPM URL: http://www.hmg.eti.br/static/rpm/atom-0.123.0-2.fc20.src.rpm RPMs to fedora 20 URL: http://www.hmg.eti.br/static/rpm/atom-0.123.0-2.fc20.x86_64.rpm http://www.hmg.eti.br/static/rpm/atom-debuginfo-0.123.0-2.fc20.x86_64.rpm http://www.hmg.eti.br/static/rpm/atom-libs-0.123.0-2.fc20.x86_64.rpm Regards, Helber
Spec URL: http://www.hmg.eti.br/static/rpm/atom.spec SRPM URL: http://www.hmg.eti.br/static/rpm/atom-0.124.0-1.fc20.src.rpm I change the spec and submit to fedora copr. https://copr.fedoraproject.org/coprs/helber/atom/ Regards, Helber
You shouldn't "install -pm755 %{buildroot}%{_datadir}/atom/libudev.so.0 %{buildroot}%{_libdir}". It's dangerous. This package is full of craps and bundled libraries. Your copr also failed to build the latest as well. As Fedora doesn't have that version of gyp. Please, next time don't use your custom repo to build the dependencies. I don't think this package could be easily reviewed and get passed.
> probably you need new version of gyp compiler. That's what should be worked on first: http://bugz.fedoraproject.org/gyp Figure out whether a new version is needed, then submit an update request ticket in bugzilla and make it block this review ticket. Becoming a co-maintainer of "gyp" would also be one of the ways to get sponsored: https://fedoraproject.org/wiki/How_to_get_sponsored_into_the_packager_group [...] About this review request. Start with pointing the fedora-review tool at this ticket: fedora-review -b 1132661 If you follow the documentation for new packagers, the tool will evaluate the "Spec URL:" and "SRPM URL:" lines, do a test-build of the package and check many things. It isn't a full review, but very often finds issues. It also runs rpmlint on all packages, which is a MUST during review anyway > # Install gyp > svn co http://gyp.googlecode.com/svn/trunk gyp That's won't work. The Fedora Build System (http://koji.fedoraproject.org/koji/ and with Mock as build tool) does not permit accessing the network. > %package libs > Summary: Library to chromium > Group: Development/Libraries Runtime (!) libs have been in group "System Environment/Libraries" for many years. The Group tag is optional nowadays, however. https://fedoraproject.org/wiki/Packaging:Guidelines#Group_tag > Requires: %{name}-libs = %{version} https://fedoraproject.org/wiki/Packaging:Guidelines#Requiring_Base_Package > %description libs > Libraries need for atom This needs an explanation. Why does it need and include libudev.so.0 while Fedora's udev is at libudev.so.1 already. This is pretty much a blocker, not just because of the no-bundling policy: https://fedoraproject.org/wiki/Packaging:No_Bundled_Libraries It also makes no sense to ship runtime libs in a -libs subpackage just for fun. If they are a strict requirement at runtime and there is no public API either, a subpackage is the wrong choice. Nothing else would need that subpackage. > Requires: nodejs > Requires: http-parser > Requires: zsh Uncommented explicit Requires are a major source of errors: https://fedoraproject.org/wiki/Packaging:Guidelines#Explicit_Requires Too often, packagers either don't keep these requirements up-to-date, or the required packages don't really include want is needed (subpackages or changed versions and contents), or the software must be patched to fix paths. Add comment in spec files more often than not. > %install > #rm -rf $RPM_BUILD_ROOT > CFLAGS='%{optflags} -g -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64' ; export CFLAGS > CXXFLAGS='%{optflags} -g -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64' ; export CXXFLAGS Why do you need CFLAGS and CXXFLAGS in %install? Also, buildroot is deleted automatically nowadays. No need to keep the "#rm -rf $RPM_BUILD_ROOT" commented out, since %buildroot and $RPM_BUILD_ROOT should not be mixed anyway: https://fedoraproject.org/wiki/Packaging:Guidelines#BuildRoot_tag https://fedoraproject.org/wiki/Packaging:Guidelines#Using_.25.7Bbuildroot.7D_and_.25.7Boptflags.7D_vs_.24RPM_BUILD_ROOT_and_.24RPM_OPT_FLAGS > install -pm755 %{buildroot}%{_datadir}/atom/libchromiumcontent.so %{buildroot}%{_libdir} > install -pm755 %{buildroot}%{_datadir}/atom/libudev.so.0 %{buildroot}%{_libdir} rm -Rf /tmp/atom-build This is highly suspicious. Why are arch-specific libs installed into /usr/share/atom? How are they found and loaded at runtime? And why are they moved to %_libdir without a comment? At least the spec file ought to give a rationale here. > %{_datadir}/applications/Atom.desktop https://fedoraproject.org/wiki/Packaging:Guidelines#Desktop_files If desktop-file-utils are used implicitly, please add a comment. > %post > > %preun > > %postun Delete unused scriptlet sections. They will cause you major pain, if you don't want any such scriptlets but include scripts by accident (e.g. by spec file comments in a false place below them). > %clean >#rm -rf $RPM_BUILD_ROOT https://fedoraproject.org/wiki/Packaging:Guidelines#.25clean > %files > %defattr(-,root,root,-) Notice that it's the default %defattr nowadays, and you didn't add it for the -libs package either, so better get rid of it: https://fedoraproject.org/wiki/Packaging:Guidelines#File_Permissions > %dir %{_datadir}/atom > %{_datadir}/atom/* Shorter: %{_datadir}/atom/ The trailing slash would not be needed, but makes it more explicit that it's a directory to be included, not a single file. %dir only is helpful if you want to include the entry for a directory but specify individual files in it instead of the '*'-everything wildcard. Sort of: %files %dir %{_datadir}/somedir %{_datadir}/somedir/file1 %{_datadir}/somedir/file2 %{_datadir}/somedir/file3 %files subpkg1 %{_datadir}/somedir/file4 %{_datadir}/somedir/file5
Any update on this, I will love to have the editor packaged on Fedora. Also atom provides an rpm, maybe the work can be used (just guessing due the lack of RPM packaging knowledge)
https://fedoraproject.org/wiki/Category:Package_Maintainers -> https://fedoraproject.org/wiki/Join_the_package_collection_maintainers -> https://fedoraproject.org/wiki/How_to_get_sponsored_into_the_packager_group There are Packaging HOWTOs on that page, too. And in case there are questions, Fedora offers places where other packagers would answer. All that would need to happen is for somebody to be willing to volunteer as the Fedora package maintainer for this software and show interest in RPM packaging and Fedora's packaging guidelines. And review process. Else not much will happen except for "unofficial" package builds getting published in random places such as Fedora Copr.
Is this review still active? I checked the spec from https://copr-be.cloud.fedoraproject.org/results/helber/atom/epel-7-x86_64/atom-1.0.1-1.fc22/atom-1.0.1-1.el7.centos.src.rpm and i see that the changes Michael mentioned are not included (not even the small once like deleting unused snippets like %preun or %postun
Also, it's worth noting that since https://github.com/atom/atom/releases/tag/v0.140.0 (October 27), the Atom team has been building their own rpms with every release.
I'd also like to see this package added to fedora repos. Version 1.2.0 has now been released https://github.com/atom/atom/releases/tag/v1.2.0. Also as illustrated here https://github.com/atom/atom/blob/v1.2.0/docs/build-instructions/linux.md, the build instructions have been much simplified from what's included in the spec file in this review. The license mentioned in the spec file is MIT, although I can't see this clear anywhere in the sources. The licensing terms here https://github.com/atom/atom/blob/v1.2.0/LICENSE.md are a little confusing as I can't clearly map to one of the good licenses approved by fedora packaging committee https://fedoraproject.org/wiki/Licensing:Main?rd=Licensing#Good_Licenses. Is there anything I can do to reactivate this review? It's been a while since Helber was active in addressing the review findings.
Submitter of this request hasn't posted since Aug 2014, which is over a year ago. I'm going to mark this as a dead review, please re-open if you (submitter) is still interested in this.
What if the original submitter is no longer interested and I'm willing to take over the packaging for atom? I'm already a fedora packager. Should I start afresh from a new spec file(and a new review ticket) or should I base my work on the one here(addressing the review remarks raised so far)?
Start a new review, ideally based partly on the work already done here
Mohammed, are you still interested in taking up this work? I'd be willing to help package and review Atom. FWIW, the license you pointed to is clearly MIT, so that shouldn't be an issue. Compare its text with https://opensource.org/licenses/MIT
I filed a ticket here https://bugzilla.redhat.com/show_bug.cgi?id=1286303 to request npm package upgrade since atom needs a version newer than the one provided by fedora. I've since waited for npm to be upgraded. Just as I check today, I find that a new version 4.3.1 is slated for rawhide and fedora 24. I'm currently on fedora 23, so maybe I'll wait till fedora 24 is released before I set off to create an atom package. Please note that based on Rex's comment above, I'm going to start a new ticket for atom review, not continue it here.
Hi, Mohammed Safwat. I still update atom version on my copr (https://copr.fedorainfracloud.org/coprs/helber/atom/), and this is a rpm spec: https://github.com/helber/fedora-specs/blob/master/atom/atom.spec I hope this spec can help you. On your issue https://bugzilla.redhat.com/show_bug.cgi?id=1286303 Zuzana Svetlikova, ask to use "npm install -g ". On my spec lines 63 to 69 i use npm updated on alternative directory. To use new i change PATH (line 69). The alpha version of atom editor need newer version of nodejs. On near future you will need to ask nodejs maintainer to update, or use some type of alternatives. You can see here (https://github.com/helber/fedora-specs/issues/2) and here (https://github.com/FZUG/repo/issues/64). On this second one, he also want to be atom packager. If you need a help, please ask me.
(In reply to Mohammed Safwat from comment #16) > I filed a ticket here https://bugzilla.redhat.com/show_bug.cgi?id=1286303 to > request npm package upgrade since atom needs a version newer than the one > provided by fedora. I've since waited for npm to be upgraded. > > Just as I check today, I find that a new version 4.3.1 is slated for rawhide > and fedora 24. I'm currently on fedora 23, so maybe I'll wait till fedora 24 > is released before I set off to create an atom package. Note that you can easily build a package for F24/rawhide from F23 using Koji. See https://fedoraproject.org/wiki/Using_the_Koji_build_system#Scratch_Builds I'm also on F23 and I do that all the time. I sometimes find it even easier than building packages on my machine, since everything is done automatically from a clean environment. You may also be able to install manually the F24 packages for npm if you prefer.
I tried scratch builds with koji and got stuck at errors during build like the ones found here http://koji.fedoraproject.org/koji/taskinfo?taskID=13462846. The build steps for atom seem to contact github to grab some stuff related to npm and grunt(; I'm not an expert but that's what the logs are telling I assume). I guess koji build servers confine building packages inside a sandbox that wouldn't allow network access to external servers like github(and I don't blame this setup). Now I'm left with installing npm package for F24 manually as Milan suggested or building from a private recent version of npm(created during build) as Helber suggested.
(In reply to Mohammed Safwat from comment #19) > I tried scratch builds with koji and got stuck at errors during build like > the ones found here > http://koji.fedoraproject.org/koji/taskinfo?taskID=13462846. > > The build steps for atom seem to contact github to grab some stuff related > to npm and grunt(; I'm not an expert but that's what the logs are telling I > assume). I guess koji build servers confine building packages inside a > sandbox that wouldn't allow network access to external servers like > github(and I don't blame this setup). Indeed, Fedora packages must be built without network access, to ensure they can be reliably created only from the SRPM. > Now I'm left with installing npm package for F24 manually as Milan suggested > or building from a private recent version of npm(created during build) as > Helber suggested. While this is useful for development, this isn't a final solution, as the official package will have to build without Internet access. Looking at the logs from [1], it seems to me you're going to have to package grunt-coffeelint, grunt-babel, grunt-lesslint, grunt-standard, grunt-cson, grunt-contrib-coffee, grunt-shell, grunt-download-electron, grunt-electron-installer and grunt-peg. While the list might seem scary, it should be a straightforward and quite repetitive task, and there are already a load of nodejs-grunt-* RPM packages in Fedora. See instructions at https://fedoraproject.org/wiki/Packaging:Node.js. If you file a new bug for these packages, you'll probably get help from people who have already packaged hundreds of RPMs like that. 1: https://copr-be.cloud.fedoraproject.org/results/helber/atom/fedora-rawhide-x86_64/00170302-atom/build.log.gz
Hi guys, The package may not meet Fedora package guide. Because it need to download electron of precompiled when build atom. We need to split the package (atom, nodejs-atom-package-manager and electron). It's really difficult. Electron is based on https://github.com/atom/libchromiumcontent. We need to hack electron, so that it uses the local library. In addition, the package review of Fedora is also very complicated. https://fedoraproject.org/wiki/Chromium Currently, I have done split atom and nodejs-atom-package-manager packages. The RPM build pass on my copr (https://copr.fedorainfracloud.org/coprs/mosquito/atom/), and Spec file in follows URL: - https://github.com/FZUG/repo/blob/master/rpms/SPECS/atom/atom.spec - https://github.com/FZUG/repo/blob/master/rpms/SPECS/atom/apm.spec
I noticed the fact that electron was downloaded as an archive at some step during the build process. I was planning to package electron for this purpose so that atom may be made dependent on it. I spent some time looking at the build scripts of atom. The problem isn't much about packaging grunt-* tasks as it's about packaging dependencies listed in the dependencies key here https://github.com/atom/atom/blob/v1.6.2/package.json. I don't know how deep this might go, as each npm package may have its own dependencies and so on. The alternative is to bundle these dependencies with atom package, which mightn't be very welcome by FPC. Now coming to the concerns raised by sensor.wen, it seems even electron can't be packaged as there're still offending issues with libchromiumcontent(or chromium, whatever, I'm not an expert here so I'm just quoting sensor.wen's remarks). Don't know either about the necessity of separating atom and apm but given the apparently pending problems with electron, have we reached a dead end?
It looks like the Electron/Chromium issue is the most serious one. OTOH, the fact that Atom has a lot of dependencies on Node.js package isn't a big issue: there are already about 1000 such packages, so the cost of adding more of them (even if it turns out to be 50) isn't that high.
Chromium is now package in Fedora, so we should be able to make some progress if somebody is willing to try again.
Reseting to NEW so it appears in lists of opened review.
Is there still something that block the package to be add in the repo ?
Only a able/willing reviewer, and probably wouldn't hurt to get a fresh .spec/srpm/comment from the submitter helber, who last commented here many months ago (2016-03-11)
What's the valuable state here? Are you still interested in this package?
Long time ago, the fedora FZUG group ask me to continue this job. This os copr: https://copr.fedorainfracloud.org/coprs/mosquito/atom/ Atom files: https://github.com/1dot75cm/repo/tree/master/rpms/atom The spec is: https://github.com/1dot75cm/repo/blob/master/rpms/atom/atom.spec The maintainer split this package on atom, electron, electron-legacy and nodejs-atom-package-manager. Based on my suggestion. This package is very is not easy to create, and be accepted. As sensor.wen mention here: https://bugzilla.redhat.com/show_bug.cgi?id=1132661#c21
Hi sensor.wen (aka 1dot75cm, mosquito), What's the current status of your atom packaging? Do you think it is ready for review? I guess you need to turn the 'sed' lines into a separate patch.
Hi guys, The atom and nodejs-atom-package-manager packages only need little change for review. (create some patches) Electron need some time to package. If it very well, i will submit a new package request. Before submit the Atom review, I think we should review the Electron first.
Really want to package these for Atom? Koji does not permit accessing the network. How to download these nodejs packages? ``` $ ll /usr/lib64/atom/node_modules/ | wc -l 441 ``` The nodejs-atom-package-manager package has same problem. ``` $ ll /usr/lib/node_modules/atom-package-manager/node_modules/ | wc -l 158 ```
(In reply to sensor.wen from comment #32) > Really want to package these for Atom? Koji does not permit accessing the > network. How to download these nodejs packages? > > ``` > $ ll /usr/lib64/atom/node_modules/ | wc -l > 441 > ``` > > The nodejs-atom-package-manager package has same problem. > ``` > $ ll /usr/lib/node_modules/atom-package-manager/node_modules/ | wc -l > 158 > ``` I think you need to package these node modules and specify them as builddeps. (In reply to sensor.wen from comment #31) > Hi guys, > > The atom and nodejs-atom-package-manager packages only need little change > for review. (create some patches) > > Electron need some time to package. If it very well, i will submit a new > package request. > > Before submit the Atom review, I think we should review the Electron first. Please open a new review request bug for electron and let it block this bug when you have a draft build for it.
Guys, I created pure RPM package for latest Atom and APM. Previously mentioned problems do not occur, everything works as it should. How I take over this review? Or maybe I should create new one? SPEC: https://gist.github.com/I-n-d-e-r/fa7f3322e08df951b584336a886dea7e SRPM: https://copr-be.cloud.fedoraproject.org/results/inder/atom/fedora-25-x86_64/00521644-atom/atom-1.14.4-2.fc25.src.rpm PACKAGE x86_64: https://copr-be.cloud.fedoraproject.org/results/inder/atom/fedora-25-x86_64/00521644-atom/atom-1.14.4-2.fc25.x86_64.rpm PACKAGE i386: https://copr-be.cloud.fedoraproject.org/results/inder/atom/fedora-25-i386/00521644-atom/atom-1.14.4-2.fc25.i686.rpm COPR: https://copr.fedorainfracloud.org/coprs/inder/atom/
Hi Dominik, you can open a new package review request and close this one as a duplication. Your FAS seems to be inder, this user is currently not in the packager group. That means you first need to get sponsored as a packager. https://fedoraproject.org/wiki/Join_the_package_collection_maintainers#Get_Sponsored ## Now some general advice to your spec file: - Where did you download the source tarball? You have to provide a valid URL or at least explain (by comment) how to create the tarball. > Source: %{name}-%{version}.tar.xz https://fedoraproject.org/wiki/Packaging:SourceURL#Referencing_Source https://fedoraproject.org/wiki/Packaging:SourceURL#When_Upstream_uses_Prohibited_Code - You can expect implicit dependencies of gcc-c++ or the general build environment and do not need to list them explicitly: > BuildRequires: make > BuildRequires: gcc > BuildRequires: glibc-devel > BuildRequires: rpmdevtools - %description line is too long, insert a line break after 'core—a tool' to split into two lines. - Please set all %global at the beginning of the file. - Please use 'cp -p' to preserve timestamps. https://fedoraproject.org/wiki/Packaging:Guidelines#Timestamps - Please provide a link to the raw spec file to let fedora-review tool properly download: https://gist.githubusercontent.com/I-n-d-e-r/fa7f3322e08df951b584336a886dea7e/raw/bbb5dffa6cff7f5e380a8b0f0ddc86835e7692e0/atom.spec
No response since weeks. Closing here, please feel free to reopen if you still think there's an issue.
I really hope that Atom will be available into Fedora. Thanks !
(In reply to jeremy9856 from comment #37) > I really hope that Atom will be available into Fedora. > Thanks ! Copr has some builds but latest for Fedora 23 which is EOL. You could ask helber to provide more recent builds or use your own copr to build for current Fedora. https://copr.fedorainfracloud.org/coprs/helber/atom/ Maybe also ask upstream for help as done already for other distributions. https://github.com/atom/atom/issues/2956 https://discuss.atom.io/t/why-isnt-atom-in-any-official-repository/29294/2
I use the this copr repo "mosquito/atom" that provide up to date build for F25 but it would be great to have atom in the official repo.
See also http://blog.atom.io/2014/11/05/linux-packages.html
More info about Atom is present on this wiki page: https://fedoraproject.org/wiki/Atom Also don't use helber copr, use the mosquito one. I've been using it and so far so good!
I think it would make sense to split this, and start out by packaging Electron. Electron is used not only by Atom, but also VSCode, and a number of other large and small application. Two medium-sized projects that run on Electron are the Monaco text editor (part of VSCode), and DomTerm (see bug 142489). (Neither of these two projects require Electron, but electron is a convenient way to run them as standalone applications.) So an electron package would be useful in itself, in addition to being a useful stepping-stone to an atom package.
(In reply to Dominik Opyd from comment #34) > Guys, I created pure RPM package for latest Atom and APM. Previously > mentioned problems do not occur, everything works as it should. How I take > over this review? Or maybe I should create new one? Dominik are you still interested in packaging Atom ?
Packaging atom isn't even remotely a possibility until electron is able to be built on koji. It seems the gentoo guys figured out how to build it at least: https://gitweb.gentoo.org/repo/gentoo.git/tree/dev-util/electron/electron-1.3.13-r1.ebuild This is a massive undertaking that will likely needs its own SIG/Community surrounding it and the current chromium builds. (poor tom) There are hundreds of electron based apps out there that are ripe for packaging, imho. My personal interest is for Rocket.Chat.Electron. None of this is going to see any fruition until their foundation (electron) is through review and able to be consistently maintained. One of the biggest problems that I can tell is that the chromium/libchromiumcontent/electron instructions are based on pulling all sorts of precompiled nonsense from their entire ecosystem - something which I guess is to be expected from a chromium based project. This won't fly here, and as such it needs to be torn down a re-done to be able to be packaged with what's available to koji (and would probably have to be heavily based on the efforts of @spot in packaging chromium) - as it stands I couldn't even get electron to pass the bootstrap and/or build phase based on the instructions they provide (https://github.com/electron/electron/blob/master/docs/development/build-instructions-linux.md) and that includes allowing it to pull all of the bundled material. It's honestly suspect whether there are more than a handful of people out there right now that can actually build it, it seems. The next hurdle after that is going to be in automating and packaging the (what im sure are hundreds) of node dependencies needed by atom, and after that, unbundling atom and getting it to use all the previously mentioned efforts properly. I highly doubt any one person will undertake these tasks in order to actually packaged this monstrosity in such a way that would actually pass review, unless we amass a significantly large community of people willing to work on it. I'm not holding my breath, though.
(In reply to jeremy9856 from comment #43) > (In reply to Dominik Opyd from comment #34) > > Guys, I created pure RPM package for latest Atom and APM. Previously > > mentioned problems do not occur, everything works as it should. How I take > > over this review? Or maybe I should create new one? > > Dominik are you still interested in packaging Atom ? Yes, I am :) I have little time now and I work. I will be able to take care of it in about 2 weeks.
(In reply to Mike Goodwin from comment #44) > This is a massive undertaking that will likely needs its own SIG/Community > surrounding it and the current chromium builds. Good point. Maybe post about starting such a Special Interest Group on one of the mailing lists, or contacting someone in FESCO.