|
Size: 7920
Comment: Haguu(*(((( HELP+SUPPORT))))$$$$$1-844-240-8386Norton antivirus helpline number, Norton antivirus tech support phone number USA@@@@@@@1-844-240-8386@@@@@@Norton Antivirus Tech support phone number, No
|
Size: 18337
Comment:
|
| Deletions are marked like this. | Additions are marked like this. |
| Line 1: | Line 1: |
| Haguu(*(((( HELP+SUPPORT))))$$$$$1-844-240-8386Norton antivirus helpline number, Norton antivirus tech support phone number USA@@@@@@@1-844-240-8386@@@@@@Norton Antivirus Tech support phone number, Norton Antivirus support phone number1-844-240-8386 Norton Antivirus Tech support phone number,Template:1(844)^(420)^(8386) Norton Antivirus Phone number USA, Canada,1(844)^(420)^(8386) Norton tech Support Phone Number, Norton 360 Phone number,Norton Helpline number,Norton AntiVirus Phone Number: How to install {{{{1(844)^(420)^(8386))}}} Norton Phone number USA, Canada, Norton tech Support Phone Number, Norton 360 Phone number,Norton Helpline number??? US Norton tech support number 1(844)^(420)^(8386) Norton antivirus tech support number Norton antivirus Norton uninstaller free Norton antivirus Norton antivirus Norton antivirus phone number support northon Norton helpline Norton antivirus login how to get phone numbers Norton antivirus Norton antivirus trial Norton number Norton log in Norton antivirus free phone numbers free Norton disk doctor Norton system works Norton antivirus download internet security Norton virus removal Norton account phone number Norton live chat buy Norton antivirus Norton internet security login Norton search Norton software phone number anti virus software Norton tech support phone number free Norton Norton mobile Norton free Norton antivirus software Norton free antivirus Norton antivirus phone number customer service Norton online backup Norton antivirus phone support notron quick heal Norton toll free number #$#1(844)^(420)^(8386)*##$Norton download manager Norton identity safe download Norton antivirus Norton install Norton internet security8448 Norton anti virus phone number phone number for Norton customer service Norton customer phone number Norton customer support phone number canada symantec removal tool Norton safe search Norton price Norton toolbar Norton av Norton antivirus coupon Norton nz phone number Norton 844 number Norton downloads Norton antivirus free trial Norton internet security 2012 Norton cancellation phone number Norton updates phone book phone numbers in usa telephone number Norton helpline number phone directory contact Norton by phone Norton subscription Norton ghost download Norton com support phone number Norton antivirus contact Norton antivirus contact number technical support phone number Norton phone antivirus Norton free Norton support phone number us Norton removal tool phone number for Norton antivirus customer service Norton update Norton antivirus number Norton antivirus phone number canada Norton phone support canada Norton spyware toll free numbers Norton store Norton online family find free phone numbers Norton account antivirus Norton gratis Norton antivirus account Norton contact phone number Norton system works Norton internet security support phone number symantec #$#1(844)^(420)^(8386)*##$Norton Norton utilities 86 contact Norton antivirus Norton s Norton antivirus renewal Norton support phone number usa Norton customer service phone number billing Norton internet security support usa number Norton review Norton annual renewal free antivirus Norton anti virus Norton Norton renewal Norton antivirus online trend antivirus how to contact Norton antivirus by phone Norton anitvirus norotn support Norton Norton security contact number us numbers Norton phone support number Norton technical support number Norton customer care Norton help desk phone number contact Norton antivirus by phone Norton antivirus tech support number Norton antivirus tech support Norton customer service Norton anti virus software #$#1(844)^(420)^(8386)*##$Norton anti virus protection search for phone numbers Norton activation what is Norton Norton full Norton support phone Norton contact us Norton renewal code antivirus Norton free symantec technical support phone number Norton security customer service phone number Norton usa Norton security support tech support number antivirus support install Norton antivirus phone number for Norton antivirus support live chat phone numbers Norton customer service phone number usa phone number in us Norton internet security 2010 Norton ghost 15.0 symantec tech support phone number Norton customer support phone number vanity numbers phone number service Norton my account login symantec technical support Norton antivirus support number antivirus Norton symantec support number Norton for phone phone number of usa phone number for business Norton 1 844 number phone number for Norton internet security Norton hotline Norton internet security contact phone number symantec #$#1(844)^(420)^(8386)*##$Norton antivirus phone number for Norton tech support Norton customer support phone number usa Norton support symantec contact Norton security symantec customer service phone number Norton antivirus 2011 Norton customer service phone number Norton technical support number Norton tech support phone number Norton 360 Phone Number Norton 360 technical support phone number Norton antivirus technical support phone number Norton antivirus phone number 1(844)^(420)^(8386) Norton antivirus contact number Norton customer service number Norton antivirus customer service Helpline Number 1(844)^(420)^(8386) Norton 360 customer service phone number Norton antivirus customer service phone number Norton support number Norton help number Norton antivirus phone support number Norton tech support telephone number Norton tech support number Norton antivirus support phone number Norton technical support phone number Norton antivirus tech support phone number Norton 360 phone number customer service Norton 1(844)^(420)^(8386) technical support telephone number Norton antivirus Tech Support Toll Free Number Norton antivirus support phone number Norton antivirus help phone number Norton 1844 number Norton internet security customer service phone number Norton antivirus 1844 number Norton Toll Free Number Norton 360 login Phone Number Norton 360 login to account my Norton 360 account login Norton 360 my account Norton activation Norton product activation how do i activate my Norton product Norton 360 activation install Norton 360 how to activate my Norton antivirus product key Norton antivirus customer service phone number 1(844)^(420)^(8386) Norton antivirus phone number support Norton support contact number Norton contact number for billing Norton customer service phone number activate Norton 360 with product key how do i activate my Norton product register Norton product i have Norton product key Norton 360 activation install Norton 360 Norton account activation Norton 360 my account Norton 360 telephone number Norton 1 844 number symantec Norton security contact phone number 1 844 Norton number Norton online help Norton 360 contact number contact Norton customer support Norton customer care number Norton customer care Norton symantec telephone number Norton internet security telephone number Norton internet security customer service number symantec customer service number 1(844)^(420)^(8386) symantec customer service phone number Norton 360 telephone number Norton internet security telephone number Norton technical support phone number Norton technical support phone number us Norton 360 contact number Norton antivirus customer service number phone number for Norton customer service Norton contact phone number Norton antivirus telephone number phone number for Norton antivirus Norton security contact number 1(844)^(420)^(8386) Norton toll free number Norton antivirus number phone number for Norton antivirus customer service Norton security customer service phone number Norton 360 technical support phone number Norton phone number Norton customer service phone number Norton contact number Norton security phone number Norton support phone number Norton customer service number Norton number Norton support number Norton 360 phone.. | ## page was renamed from OldContributorsPage ## page was renamed from Contributors #pragma section-numbers on == Contributing to RPM Fusion == So, you've decided to become a contributor to RPM Fusion? This guide will lead you through your first package submission and teach you how to update your package(s) in the future. Please also have a look on the Fedora counterpart https://fedoraproject.org/wiki/Join_the_package_collection_maintainers <<TableOfContents(10)>> == Becoming a RPM Fusion contributor == Having packaging experience in Fedora is much preferred, but newcomers are welcome too. However if you are a newcomer (i.e. you're not a Fedora sponsored packager) you must first get sponsored, which means find someone to guide you while you learn the procedures. === Create a Bugzilla Account === In either scenario you should create your first RPM Fusion package and submit it for review as described below. The review process is handled through Bugzilla, as will be any bugs reported against your packages. Make sure you have an account in Bugzilla. The email address that you use for your Bugzilla account should be the same email address as you use for all other things related to RPM Fusion. === Join the Mailing List === Once this is done, join the [[https://lists.rpmfusion.org/archives/list/rpmfusion-developers@lists.rpmfusion.org/|Developers Mailing Lists]] and introduce yourself there. Include a link to the review request for your first package in your introduction, and if you're a newcomer also mention that you need someone to sponsor you. If you have questions about the packaging process, this is the place to ask. Also join the RPM Fusion [[https://lists.rpmfusion.org/archives/list/rpmfusion-commits@lists.rpmfusion.org/|GIT commits]] mailing list. The GIT commits mailing list is used for commit messages from the GIT repository. You should subscribe to this list to track the changes to all the packages. == Submitting a new package == === Read the packaging guidelines === RPM Fusion follows the Fedora packaging guidelines, make sure you've read and understood these: * [[http://fedoraproject.org/wiki/Packaging/NamingGuidelines|Naming Guidelines]] * [[http://fedoraproject.org/wiki/Packaging/Guidelines|Guidelines]] It is also a good idea to read the items which will be checked during the review of your package and to verify yourself that these are all ok: * [[http://fedoraproject.org/wiki/Packaging/ReviewGuidelines|Review Guidelines]] Please read the Kmod standard if you will be packaging an external kernel module: * [[Packaging/KernelModules/Kmods2|Kmods2: Packaging kernel modules]] === Create a package review request === Before posting a review request, you should upload your SRPM and SPEC file to any accessible location on the internet. Before your package can become part of RPM Fusion it must first be reviewed, [[https://bugzilla.rpmfusion.org/enter_bug.cgi?product=Package%20Reviews|create a new bug report as follows]] : * Choose "Package Reviews" as Product. * Choose "Review Requests" as Component. * Set `Summary` to: "`Review request: %{name} - %{summary}`", with %{name} and %{summary} from the package. * Put the following in the Description: * Full URLs to the spec file and source rpm of the package. * A short description for the package (usually, the %description from the spec file). * Why this package is not eligible to be included in Fedora. * The output `rpmlint` gives on both the source and binary packages. Explain for each message why you've chosen to ignore it. * Mention if this is your first RPM Fusion package. * Mention that you are seeking a sponsor if you are not a Fedora sponsored packager or an RPM Fusion sponsored packager. * The request should also be set to block the tracker bug: `RF_NEW` (bug #2). This way, other contributors can easily check for packages that need reviewing. If you want to help others by doing reviews yourself go to [[https://bugzilla.rpmfusion.org/show_bug.cgi?id=2|bug #2]]. * If you are seeking a sponsor you must also be set to block the tracker bug: `NEEDSPONSORS` (bug #30). Thus, some potential sponsors will look at the NEEDSPONSORS bug to find packages to review. The only allowed sponsors in RPM Fusion are Fedora sponsors. Please do not submit more than one package per per Bugzilla entry. It would be very very difficult to follow the review otherwise. If you have related packages, it can be handy to trace all the dependencies using the "Depends On" or "Block" Bugzilla features. === Wait for your package to be reviewed === As time permits, a reviewer will review your package. A reviewer is either a Fedora sponsored packager or an RPM Fusion only sponsored packager. If you need a sponsor, the reviewer must be a Fedora sponsors. Sometimes other people add a few comments, this does not constitute a review. When a proper review gets done the reviewer will assign the bug to him, remove the blocker on `RF_NEW` and set it to block the tracker bug `RF_REVIEW` (bug #3). This indicates that a review is in progress. The reviewer should follow the [[http://fedoraproject.org/wiki/Packaging/ReviewGuidelines|Fedora Review Guidelines]] as close as possible, obviously taking into account any differences between Fedora and RPM Fusion. As RPM Fusion is more permissive with the content it allows, exceptions to these guidelines are allowed in some circumstances but care and common sense should prevail. The reviewer should ensure that any deviations from the [[http://fedoraproject.org/wiki/Packaging/Guidelines|Fedora Packaging Guidelines]] are sane and justified in the package they are reviewing. If in doubt, please ask on the RPM Fusion mailing list. The reviewer should inform the contributor of any changes that need to be made to their package, if any. The contributor should update their package as necessary, including bumping the release version and submit the new SPEC file and source rpm URL. The reviewer should verify the changes. This is repeated as many times as necessary until the contributor and reviewer are happy with the final package. === Get an RPM Fusion Account === Create an account in the RPM Fusion Account System * Visit the account system home: https://admin.rpmfusion.org/accounts/ * Click on `New account` and fill in the blanks. * fas email must be the same of bugzilla email (to allow be added as PoC). * After you create your account, please be sure to sign the CLA (if you click on the "My Account" link in the top right, you should see CLA: `CLA Done`). * Edit your account and upload your Public RSA SSH Key (see `man ssh-keygen` for more information) which is required for CVS authorization.<<BR>> . {i} It takes up to 24 hours before the new key is synced with the rest of the infrastructure. * Once you get email confirmation that your account has been created and you're a member of the `cla_done` group, return to edit your account: * Apply for the packager group ==> https://admin.rpmfusion.org/accounts/group/view/packager . * Once this is done, your account will show up as "pending" to all of the RPM Fusion sponsors (who will receive an email). * When you are sponsored, you will be automatically added/approved to the `rpmfusionbugs` group as well. This will allow you to make changes to the state of bugs in Bugzilla, which is what you'll need to do to get them checked in. It will also allow you to do complete package reviews, including approving packages yourself! === Your package gets approved === When the reviewer approves the package, he adds a comment saying that the package has been approved, he removes the blocker `RF_REVIEW` bug and sets fedora-review flag to "+". (only RPM Fusion packagers can do this). After that, you can submit a package admin request in [[https://admin.rpmfusion.org/pkgdb/|RPM Fusion pkgdb]] as in Fedora. As a reminder, the namespace tag specifies the repository in which you want to import your package: * '''free''' for Open Source Software (as defined by the [[http://fedoraproject.org/wiki/Licensing|Fedora Licensing Guidelines]]) which the Fedora project cannot ship due to other reasons * '''nonfree''' for redistributable software that is not Open Source Software (as defined by the [[http://fedoraproject.org/wiki/Licensing|Fedora Licensing Guidelines]]); this includes software with publicly available source-code that has "no commercial use"-like restrictions. A '''free''' package that depends on a '''nonfree''' package goes to this repository too. === Install RPMFusion packager tools and set your environment === Before starting next steps (importing your package or request a build) install rpmfusion-packager and rfpkg {{{ sudo dnf install rpmfusion-packager }}} This provides a set of utilities that helps a RPMFusion packager in setting up automatically their environment to access to the git-dist and build server. The package already includes installation of others useful packages like the rfpkg. And after, just run rpmfusion-packager-setup with no options as a non-root user. {{{ rpmfusion-packager-setup }}} Next, set your environment : Start ssh-agent to ensure that git uses your id_rsa key: {{{ ssh-agent $SHELL }}} or {{{ keychain -q ~/.ssh/id_rsa }}} <<Anchor(import_package)>> === Import your package === Once the git module has been created, the package must be imported.<<BR>> The only file that you have to import is the "src.rpm" file, no more and one at a time. Then, checkout the common tool and import your SRPM as follow : {{{ rfpkg clone <namespace>/<my_new_package> cd <my_new_package> rfpkg import ~/foo.src.rpm rfpkg ci -c rfpkg new-sources my_packager-1.0.tar.gz rfpkg commit rfpkg push }}} During the GIT import procedure, your source files will be automatically tagged for the requested branch.<<BR>> {i} <namespace> is the section where your git module should be imported/go ('''free''' or '''nonfree'''). === Request a build === If you have already setup your environment (see two items ago), go on and request a build. Move to the directory where the source files are: {{{ rfpkg clone free/my_package cd my_package vim my_package.spec }}} You may also request a scratch build to test build before do a git commit and push . {{{ rfpkg --release f34 scratch-build --arches ppc64le --srpm }}} And finally upload source , commit changes and push it {{{ rfpkg new-sources my_packager-1.0.tar.gz rfpkg commit rfpkg push }}} Then request a build to the koji server {{{ rfpkg build }}} This will trigger a build request for the branch. Easy! You can check the status of the build process from the [[http://koji.rpmfusion.org/koji/tasks|koji web interface]]. Once the package built successfully, go back to your bug review and add a comment to the review to notify the import and build have been done correctly. Then close the bug as `RESOLVED` `FIXED`. If there is a request for your package in the [[Wishlist|RPM Fusion Wishlist]], please remove the related entry and commit the change in the wiki with a comment saying that the package is now in RPM Fusion. === If SSL certificate expired === If during import you get the following error: {{{ Could not execute import_srpm: (35, 'Peer reports failure of signature verification or key exchange.') }}} Since rpmfusion-packager-0.6.1 we got rpmfusion-cert rpmfusion-cert -v for verify rpmfusion-cert -n to create a new certificate If ~/.rpmfusion-server-ca.cert or ~/.rpmfusion-upload-ca.cert were generated before Apr 24 2018 (due these certificates has expired), you need update them, first remove them with rm ~/.rpmfusion-upload-ca.cert and ~/.rpmfusion-server-ca.cert, next run fedora-package-setup and after renew your client cert with rpmfusion-cert -n The old method which is download manually a client-side certificate from: https://admin.rpmfusion.org/accounts/user/gencert and save it as ~/.rpmfusion.cert still working, if you need it for some reason as alternative. == Co-maintaining an existing package == You can offer to co-maintain a package in RPM Fusion. Please see Fedora's documentation on [[http://fedoraproject.org/wiki/Package_maintainer_policy#Co-Maintainership|co-maintainership]]. To get commit privileges to an existing package, see "Package Change Requests for existing packages" in the [[Contributors/CVSRequests|CVS Requests]] documentation. Even if you don't have an RPM Fusion account, it can be useful to anonymously checkout a package's GIT module for various reasons. In such case, you can use the following command : {{{ rfpkg clone -a <namespace>/<module> }}} where <namespace> is either free or nonfree and <module> is the package's name. == Updating an existing package == Make sure you have your environment set as in the [[http://rpmfusion.org/Contributors#import_package|Import your package]] subsection. You can then follow the [[http://fedoraproject.org/wiki/PackageMaintainers/UpdatingPackageHowTo|Fedora Package Update HOWTO]]. '''Example:''' {{{ # Set the environment: rfpkg clone <namespace>/<module> # Download the new upstream source and save it to the branch directory you are updating (if applies): cd module wget -N http://dl.sf.net/foo/foo-0.0.2.tar.bz2 # Upload the tarball to an external lookaside cache (not yet working) rfpkg new-sources "foo-0.0.2.tar.bz2" # Small patches, initscripts or otherwise plain text files can be commited directly to GIT: git add foo-fix-the-bar.patch # Change the required things in the specfile: emacs foo.spec # Check that the changes you made are correct: git diff # Create a changelog entry (clog) and commit the changes: rfpkg ci -c # check what you going to push git show # Tag and request build (ex make tag build ) : rfpkg push #we may also do: rfpkg tag (but not required) rfpkg build # Resubmit a failed build: koji-rpmfusion resubmit <taskID> (note is not the buildID) # or as alternative git checkout f24; rfpkg build; git checkout master #"rfpkg build" is safe because check before if we already built it, if build is already #done, reply something like: #Could not execute build: Package mpgtx-1.3.1-9.fc23 has already been #built #Note: You can skip this check with --skip-nvr-check. See help for more #info. }}} A package built for devel (i.e. rawhide) will directly go to the "devel" repository. A package built for a stable release (e.g. f24, f23) will go to the "updates-testing" repository. You'll have to wait a period ranging from 10 to 14 days for your package to be transferred to the "updates" repository. It's a manual action, somebody real actually does that, so don't panic. You can also find packages which are built but not yet pushed here: http://koji.rpmfusion.org/mash/ == Requesting a new branch for a package == You can request new branches for a package at https://admin.rpmfusion.org/pkgdb == Retiring a package == In order to retire a branch of a package, the maintainer needs to delete all but a '''dead.package''' file containing an explanation of why the package/branch has been retired. A package cannot be retired in stable branches, only in master (rawhide) and branched (e.g. f31 until Fedora 31 is released). An EL branch can be retired at any time. Once that's done, the maintainer must file a [[https://bugzilla.rpmfusion.org/enter_bug.cgi?product=Infrastructure&component=Repo|bugzilla ticket in the '''Infrastructure''' product and '''Repo''' component]] asking the package to be blocked in koji. This can be done using the following command: {{{ rfpkg retire }}} At this time, the command cannot retire the package in [[https://admin.rpmfusion.org/pkgdb/|pkgdb]]. You need to orphan then retire it manually from the web interface on the related branches. Then file a ticket for the package to be properly retired in koji. == Orphaning a package == FIXME : Work out and describe the process to orphan a package. == Requesting a buildroot override == You can use the following command to request a buildroot override : {{{ koji-rpmfusion tag-build f2?-{,non}free-override your_rpmfusion_build_nvr }}} After wait for repo be ready: {{{ koji-rpmfusion wait-repo f2?-{,non}free-build --build=your_rpmfusion_build_nvr }}} Exemplify {{{ koji-rpmfusion tag-build f25-free-override VirtualBox-5.1.4-3.fc25 koji-rpmfusion wait-repo f25-free-build --build=VirtualBox-5.1.4-3.fc25 }}} It's not possible to tag a fedora package, that's a manual task. In this case, please file a bug in product "Infrastructure" and component "Build System". It is currently not possible to expire a buildroot override, but that is being worked on. == Requesting a buildroot override but for one package from Fedora == As we do not build with updates-testing repos enabled, it's sometime needed for a package to be build and pushed in sync with others fedora packages. Please submit a specific bug for the package you want to build and block this bug: https://bugzilla.rpmfusion.org/show_bug.cgi?id=4501 == Making the build available in the repository == RPM Fusion doesn't use Bodhi like Fedora to request moving package to testing repository then stable repository.<<BR>> Packages are '''pushed manually by the admins''' from time to time. == Manually moving a package from testing repository to updates repository == In some rare cases, packages needs to be moved in sync with packages in Fedora. For example, chromium, qt-webengine, etc.... For such cases, and only such cases, one can move a package using '''koji-rpmfusion move-build''' command. Here is an example : {{{ koji-rpmfusion move-build f29-free-updates-testing f29-free-updates package-version-release }}} {X} WARNING: Never move a package from candidate to testing, or from updates to stable. Only testing to stable is safe, because packages in candidate have not been signed yet. CategoryContributing |
1. Contributing to RPM Fusion
So, you've decided to become a contributor to RPM Fusion? This guide will lead you through your first package submission and teach you how to update your package(s) in the future. Please also have a look on the Fedora counterpart https://fedoraproject.org/wiki/Join_the_package_collection_maintainers
Contents
- Contributing to RPM Fusion
- Becoming a RPM Fusion contributor
- Submitting a new package
- Co-maintaining an existing package
- Updating an existing package
- Requesting a new branch for a package
- Retiring a package
- Orphaning a package
- Requesting a buildroot override
- Requesting a buildroot override but for one package from Fedora
- Making the build available in the repository
- Manually moving a package from testing repository to updates repository
2. Becoming a RPM Fusion contributor
Having packaging experience in Fedora is much preferred, but newcomers are welcome too. However if you are a newcomer (i.e. you're not a Fedora sponsored packager) you must first get sponsored, which means find someone to guide you while you learn the procedures.
2.1. Create a Bugzilla Account
In either scenario you should create your first RPM Fusion package and submit it for review as described below. The review process is handled through Bugzilla, as will be any bugs reported against your packages.
Make sure you have an account in Bugzilla.
The email address that you use for your Bugzilla account should be the same email address as you use for all other things related to RPM Fusion.
2.2. Join the Mailing List
Once this is done, join the Developers Mailing Lists and introduce yourself there. Include a link to the review request for your first package in your introduction, and if you're a newcomer also mention that you need someone to sponsor you.
If you have questions about the packaging process, this is the place to ask.
Also join the RPM Fusion GIT commits mailing list. The GIT commits mailing list is used for commit messages from the GIT repository. You should subscribe to this list to track the changes to all the packages.
3. Submitting a new package
3.1. Read the packaging guidelines
RPM Fusion follows the Fedora packaging guidelines, make sure you've read and understood these:
It is also a good idea to read the items which will be checked during the review of your package and to verify yourself that these are all ok:
Please read the Kmod standard if you will be packaging an external kernel module:
3.2. Create a package review request
Before posting a review request, you should upload your SRPM and SPEC file to any accessible location on the internet.
Before your package can become part of RPM Fusion it must first be reviewed, create a new bug report as follows :
- Choose "Package Reviews" as Product.
- Choose "Review Requests" as Component.
Set Summary to: "Review request: %{name} - %{summary}", with %{name} and %{summary} from the package.
- Put the following in the Description:
- Full URLs to the spec file and source rpm of the package.
- A short description for the package (usually, the %description from the spec file).
- Why this package is not eligible to be included in Fedora.
The output rpmlint gives on both the source and binary packages. Explain for each message why you've chosen to ignore it.
- Mention if this is your first RPM Fusion package.
- Mention that you are seeking a sponsor if you are not a Fedora sponsored packager or an RPM Fusion sponsored packager.
The request should also be set to block the tracker bug: RF_NEW (bug #2). This way, other contributors can easily check for packages that need reviewing. If you want to help others by doing reviews yourself go to bug #2.
If you are seeking a sponsor you must also be set to block the tracker bug: NEEDSPONSORS (bug #30). Thus, some potential sponsors will look at the NEEDSPONSORS bug to find packages to review. The only allowed sponsors in RPM Fusion are Fedora sponsors.
Please do not submit more than one package per per Bugzilla entry. It would be very very difficult to follow the review otherwise. If you have related packages, it can be handy to trace all the dependencies using the "Depends On" or "Block" Bugzilla features.
3.3. Wait for your package to be reviewed
As time permits, a reviewer will review your package. A reviewer is either a Fedora sponsored packager or an RPM Fusion only sponsored packager. If you need a sponsor, the reviewer must be a Fedora sponsors. Sometimes other people add a few comments, this does not constitute a review.
When a proper review gets done the reviewer will assign the bug to him, remove the blocker on RF_NEW and set it to block the tracker bug RF_REVIEW (bug #3). This indicates that a review is in progress.
The reviewer should follow the Fedora Review Guidelines as close as possible, obviously taking into account any differences between Fedora and RPM Fusion. As RPM Fusion is more permissive with the content it allows, exceptions to these guidelines are allowed in some circumstances but care and common sense should prevail. The reviewer should ensure that any deviations from the Fedora Packaging Guidelines are sane and justified in the package they are reviewing. If in doubt, please ask on the RPM Fusion mailing list. The reviewer should inform the contributor of any changes that need to be made to their package, if any. The contributor should update their package as necessary, including bumping the release version and submit the new SPEC file and source rpm URL. The reviewer should verify the changes. This is repeated as many times as necessary until the contributor and reviewer are happy with the final package.
3.4. Get an RPM Fusion Account
Create an account in the RPM Fusion Account System
Visit the account system home: https://admin.rpmfusion.org/accounts/
Click on New account and fill in the blanks.
- fas email must be the same of bugzilla email (to allow be added as PoC).
After you create your account, please be sure to sign the CLA (if you click on the "My Account" link in the top right, you should see CLA: CLA Done).
Edit your account and upload your Public RSA SSH Key (see man ssh-keygen for more information) which is required for CVS authorization.
It takes up to 24 hours before the new key is synced with the rest of the infrastructure. Once you get email confirmation that your account has been created and you're a member of the cla_done group, return to edit your account:
Apply for the packager group ==> https://admin.rpmfusion.org/accounts/group/view/packager .
- Once this is done, your account will show up as "pending" to all of the RPM Fusion sponsors (who will receive an email).
When you are sponsored, you will be automatically added/approved to the rpmfusionbugs group as well. This will allow you to make changes to the state of bugs in Bugzilla, which is what you'll need to do to get them checked in. It will also allow you to do complete package reviews, including approving packages yourself!
3.5. Your package gets approved
When the reviewer approves the package, he adds a comment saying that the package has been approved, he removes the blocker RF_REVIEW bug and sets fedora-review flag to "+". (only RPM Fusion packagers can do this).
After that, you can submit a package admin request in RPM Fusion pkgdb as in Fedora.
As a reminder, the namespace tag specifies the repository in which you want to import your package:
free for Open Source Software (as defined by the Fedora Licensing Guidelines) which the Fedora project cannot ship due to other reasons
nonfree for redistributable software that is not Open Source Software (as defined by the Fedora Licensing Guidelines); this includes software with publicly available source-code that has "no commercial use"-like restrictions. A free package that depends on a nonfree package goes to this repository too.
3.6. Install RPMFusion packager tools and set your environment
Before starting next steps (importing your package or request a build) install rpmfusion-packager and rfpkg
sudo dnf install rpmfusion-packager
This provides a set of utilities that helps a RPMFusion packager in setting up automatically their environment to access to the git-dist and build server. The package already includes installation of others useful packages like the rfpkg. And after, just run rpmfusion-packager-setup with no options as a non-root user.
rpmfusion-packager-setup
Next, set your environment :
Start ssh-agent to ensure that git uses your id_rsa key:
ssh-agent $SHELL
or
keychain -q ~/.ssh/id_rsa
3.7. Import your package
Once the git module has been created, the package must be imported.
The only file that you have to import is the "src.rpm" file, no more and one at a time.
Then, checkout the common tool and import your SRPM as follow :
rfpkg clone <namespace>/<my_new_package> cd <my_new_package> rfpkg import ~/foo.src.rpm rfpkg ci -c rfpkg new-sources my_packager-1.0.tar.gz rfpkg commit rfpkg push
During the GIT import procedure, your source files will be automatically tagged for the requested branch.
<namespace> is the section where your git module should be imported/go (free or nonfree).
3.8. Request a build
If you have already setup your environment (see two items ago), go on and request a build. Move to the directory where the source files are:
rfpkg clone free/my_package cd my_package vim my_package.spec
You may also request a scratch build to test build before do a git commit and push .
rfpkg --release f34 scratch-build --arches ppc64le --srpm
And finally upload source , commit changes and push it
rfpkg new-sources my_packager-1.0.tar.gz rfpkg commit rfpkg push
Then request a build to the koji server
rfpkg build
This will trigger a build request for the branch. Easy! You can check the status of the build process from the koji web interface.
Once the package built successfully, go back to your bug review and add a comment to the review to notify the import and build have been done correctly. Then close the bug as RESOLVED FIXED.
If there is a request for your package in the RPM Fusion Wishlist, please remove the related entry and commit the change in the wiki with a comment saying that the package is now in RPM Fusion.
3.9. If SSL certificate expired
If during import you get the following error:
Could not execute import_srpm: (35, 'Peer reports failure of signature verification or key exchange.')
Since rpmfusion-packager-0.6.1 we got rpmfusion-cert
rpmfusion-cert -v for verify
rpmfusion-cert -n to create a new certificate
If ~/.rpmfusion-server-ca.cert or ~/.rpmfusion-upload-ca.cert were generated before Apr 24 2018 (due these certificates has expired), you need update them, first remove them with rm ~/.rpmfusion-upload-ca.cert and ~/.rpmfusion-server-ca.cert, next run fedora-package-setup and after renew your client cert with rpmfusion-cert -n
The old method which is download manually a client-side certificate from: https://admin.rpmfusion.org/accounts/user/gencert and save it as ~/.rpmfusion.cert still working, if you need it for some reason as alternative.
4. Co-maintaining an existing package
You can offer to co-maintain a package in RPM Fusion. Please see Fedora's documentation on co-maintainership. To get commit privileges to an existing package, see "Package Change Requests for existing packages" in the CVS Requests documentation.
Even if you don't have an RPM Fusion account, it can be useful to anonymously checkout a package's GIT module for various reasons. In such case, you can use the following command :
rfpkg clone -a <namespace>/<module>
where <namespace> is either free or nonfree and <module> is the package's name.
5. Updating an existing package
Make sure you have your environment set as in the Import your package subsection. You can then follow the Fedora Package Update HOWTO.
Example:
# Set the environment: rfpkg clone <namespace>/<module> # Download the new upstream source and save it to the branch directory you are updating (if applies): cd module wget -N http://dl.sf.net/foo/foo-0.0.2.tar.bz2 # Upload the tarball to an external lookaside cache (not yet working) rfpkg new-sources "foo-0.0.2.tar.bz2" # Small patches, initscripts or otherwise plain text files can be commited directly to GIT: git add foo-fix-the-bar.patch # Change the required things in the specfile: emacs foo.spec # Check that the changes you made are correct: git diff # Create a changelog entry (clog) and commit the changes: rfpkg ci -c # check what you going to push git show # Tag and request build (ex make tag build ) : rfpkg push #we may also do: rfpkg tag (but not required) rfpkg build # Resubmit a failed build: koji-rpmfusion resubmit <taskID> (note is not the buildID) # or as alternative git checkout f24; rfpkg build; git checkout master #"rfpkg build" is safe because check before if we already built it, if build is already #done, reply something like: #Could not execute build: Package mpgtx-1.3.1-9.fc23 has already been #built #Note: You can skip this check with --skip-nvr-check. See help for more #info.
A package built for devel (i.e. rawhide) will directly go to the "devel" repository.
A package built for a stable release (e.g. f24, f23) will go to the "updates-testing" repository. You'll have to wait a period ranging from 10 to 14 days for your package to be transferred to the "updates" repository. It's a manual action, somebody real actually does that, so don't panic.
You can also find packages which are built but not yet pushed here: http://koji.rpmfusion.org/mash/
6. Requesting a new branch for a package
You can request new branches for a package at https://admin.rpmfusion.org/pkgdb
7. Retiring a package
In order to retire a branch of a package, the maintainer needs to delete all but a dead.package file containing an explanation of why the package/branch has been retired.
A package cannot be retired in stable branches, only in master (rawhide) and branched (e.g. f31 until Fedora 31 is released). An EL branch can be retired at any time.
Once that's done, the maintainer must file a bugzilla ticket in the '''Infrastructure''' product and '''Repo''' component asking the package to be blocked in koji.
This can be done using the following command:
rfpkg retire
At this time, the command cannot retire the package in pkgdb. You need to orphan then retire it manually from the web interface on the related branches.
Then file a ticket for the package to be properly retired in koji.
8. Orphaning a package
FIXME : Work out and describe the process to orphan a package.
9. Requesting a buildroot override
You can use the following command to request a buildroot override :
koji-rpmfusion tag-build f2?-{,non}free-override your_rpmfusion_build_nvrAfter wait for repo be ready:
koji-rpmfusion wait-repo f2?-{,non}free-build --build=your_rpmfusion_build_nvrExemplify
koji-rpmfusion tag-build f25-free-override VirtualBox-5.1.4-3.fc25 koji-rpmfusion wait-repo f25-free-build --build=VirtualBox-5.1.4-3.fc25
It's not possible to tag a fedora package, that's a manual task. In this case, please file a bug in product "Infrastructure" and component "Build System".
It is currently not possible to expire a buildroot override, but that is being worked on.
10. Requesting a buildroot override but for one package from Fedora
As we do not build with updates-testing repos enabled, it's sometime needed for a package to be build and pushed in sync with others fedora packages.
Please submit a specific bug for the package you want to build and block this bug: https://bugzilla.rpmfusion.org/show_bug.cgi?id=4501
11. Making the build available in the repository
RPM Fusion doesn't use Bodhi like Fedora to request moving package to testing repository then stable repository.
Packages are pushed manually by the admins from time to time.
12. Manually moving a package from testing repository to updates repository
In some rare cases, packages needs to be moved in sync with packages in Fedora. For example, chromium, qt-webengine, etc.... For such cases, and only such cases, one can move a package using koji-rpmfusion move-build command.
Here is an example :
koji-rpmfusion move-build f29-free-updates-testing f29-free-updates package-version-release
WARNING: Never move a package from candidate to testing, or from updates to stable. Only testing to stable is safe, because packages in candidate have not been signed yet.