Some questions about Playground Repo
by Deborah Rieden
Hello,
After reading through the playground repository draft [1] I thought it would be helpful to have tooling which can display the contents and status of the playground repo. For example:
- Display the package(s) in the repository
- Display the date when the package was added
- Display the date when the package was last updated
- Display who owns the package, if a provenpackager a special symbol is displayed?
- Display the status of the package (like if it is bad, unusable, removed, terrific)
- Is package in Fedora, or moving to Fedora? Which version.
- Is the package signed? If not signed do we want to state why? Do we want to include a link to request
that this package be considered for signing?
- Are there any tests associated with this package? - automated, manual, etc.
- Does package have broken dependencies? If so, it is marked a certain way.
This information should be viewable by anyone? Any restrictions?
This information should be automatically generated. A human is not needed to create the report.
Any comments?
[1] https://fedoraproject.org/wiki/Env_and_Stacks/Playground_repository_%28dr...
Debi
--
Debi Rieden
Engineering Program Manager
(Developer Toolset (DTS), Software Collections (RHSCL), LPC Pilot and some other projects), Fedora Environment and Stacks Working Group
Westford (2S719)
Office: 978-392-1023; Cell 617-669-2934
drieden(a)redhat.com
#devtoolset, #boston, #software-collections, #fedora-stacks
10 years, 1 month
RFC: Packager's Guide - Content Specification
by Petr Kovar
Hi all,
This is not really related to the current conversations about playground
repos etc., but I wanted to bring this up anyway.
I put together a content specification of the brand new Packager's Guide
(TM), which we also mention in the PRD:
Some people prefer to use a single document to learn about concepts
and tasks rather that browsing through a number of wiki pages. Wiki
content may not feel qualified and may not invoke the same trust as
formal documentation. pkovar will be working on a new Packager's
Guide, to help people getting started with RPM packaging for Fedora
and EPEL. The goal is to share as much content as possible with
downstream RHEL/EPEL documentation, using the same format and
toolchain (DocBook, Publican). The guide will be mostly based on
the Fedora wiki pages/HOWTOs. It will reference additional
resources on the wiki (esp. in the Packaging: namespace) and/or
other content where appropriate. An outdated draft is here:
http://docs.fedoraproject.org/en-US/Fedora_Draft_Documentation/0.1/html/P...
The content specification is mostly based on
http://fedoraproject.org/wiki/How_to_create_an_RPM_package and intended to
replace the outdated and unmaintained RPM Guide [1]. It will also allow us
to get rid of some rather obsolete packaging HOWTOs on Fedora wiki, such as
[2].
But first of all, it will allow people who are getting started with RPM
packaging to find the content they are looking for in one
place, without having to try their luck with searching the somewhat bloated
Fedora wiki.
This guide fills in the gap for RPM formal documentation in Fedora. This
can help people getting started with SCLs, too: the Fedora Software
Collections Guide assumes that the readers already have substantial
knowledge of RPM packaging.
[1]
http://docs.fedoraproject.org/en-US/Fedora_Draft_Documentation/0.1/html/R...
[2] http://fedoraproject.org/wiki/How_to_create_a_GNU_Hello_RPM_package
Please let me know your comments, suggestions or questions. Thanks.
Table of Contents
* Introduction to the RPM Package Manager:
This chapter introduces the RPM Package Manager, describes the
RPM package design, defines the basic content of every RPM
package, and shows how to explore the RPM package structure
What Are Packages, and Why Manage Them?
RPM Design Goals
What Is in a Package?
Using rpm2cpio
Source Package Files and How to Use Them
* Creating and Building RPM Packages:
This chapter discusses the basics of creating and
building RPM packages and provides a spec file overview.
Preparing Your System
The Basics of Building RPM Packages
Creating a Basic spec File
spec Templates and Examples
Templates
Examples
Building a Package
Testing a Package
Testing a spec File
Testing a spec File
Testing a Binary Package
Testing a Source Package
spec File Overview
spec File Sections Explained
%prep Section
%prep Section: %setup Command
%prep Section: %patch Commands
%prep Section: Unmodified Files
%build Section
%install Section
%check Section
%files Section
%files Basics
%files Prefixes
%files and Filesystem Hierarchy Standard (FHS)
%files Example
Finding Duplicates
Scriptlets
Macros
Other Tags
Dependency Generators
Subpackages
Conditionals
* Distributing RPM Packages:
This chapter discusses configuring digital signatures and Yum
repositories to distribute software packaged with RPM.
Digital Signatures for RPM Packages
Generating a GnuPG Keypair
Signing Packages
Yum Repositories for RPM Packages
Creating a Yum Repository
* Appendix - Eclipse RPM Building:
This appendix contains information on how to build RPM
packages in Eclipse Development Environment.
Eclipse Built-in Specfile Editor
* Appendix - Java Packaging:
This appendix documents tools and techniques to help
developers create and maintain Java packages in Fedora. It is
based on http://sochotni.fedorapeople.org/java-packaging-howto/
For Packagers
Example Java Project
Build System Identification
For Java Developers Example Java Project
Java Specifics in Fedora for Users and Developers
Java Specifics in Fedora for Packagers
Directory Layout
JAR File Identification
Relative Paths
Artifact Specification
Aliases
Compat Versions
Dependency Handling
Javadoc Packages
Core Java Packages
JVM
Generic Java Builds
add_maven_depmap Macro
Generating Application Shell Scripts
Replacing JARs with Symbolic Links Using xmvn-subst
Ant
Maven
Packaging a Maven Project
Macros for Maven Build Configuration
Installing Additional Artifacts
Additional Mappings
Alternative JAR File Names
Single Artifact Per Package
Assignment of the Maven Artifacts to the Subpackages
Modifying XMvn Configuration from within the spec File
Macros for POM modification
Macros for pom.xml Modification
add_maven_depmap Macro
Replacing JARs with Symbolic Links Using xmvn-subst
Common Errors
Integration of Maven and XMvn Tools
* Appendix - Getting More Information:
Explains where to find more information, including the RPM
official project site, other RPM books and RPM documentation.
--
Petr Kovar
10 years, 1 month
Playground repo: self-hosting
by Tadej Janež
Question: Is the Playground repository self-hosting, i.e. the Playground
repository (along with the Fedora's main repository) contains all the
packages needed to build any package in the Playground repository?
Answer proposal: Yes.
Rationale: Self-hosting has been a fundamental guarantee of Fedora for a
long time and we don't want to break that with the Playground
repository.
Notes: Even though some dependencies might take a lot of time to
package, this is mitigated by the fact that the packaging guidelines for
the Playgroud repository are a lot more simple compared to the current
Fedora Packaging Guidelines. Hence, it is easier to package up all the
dependencies. Also, since library bundling is allowed, the packager
could at first just bundle all the dependencies in the package of
interest and later, if it would be practical, separate them out into
independent packages.
10 years, 2 months
Playground repo: mirroring
by Tadej Janež
Hi!
Let's try to answer/close some of the Open questions [1] of the
Playground repository requirements draft.
I suggest we start with the *easy* ones.
Question: Will the Playground repository be mirrored (and added to
mirrormanager)?
Answer proposal: The Playground repository will not be mirrored (and
added to mirrormanager) initially. If the need arises, we'll cooperate
with the Infra team to add support for mirroring.
[1] https://fedoraproject.org/wiki/Env_and_Stacks/Playground_repository_
%28draft%29#Open_Questions
10 years, 2 months
System Wide Changes
by Marcela Mašláňová
Hi,
I thought we could prepare all our goals as system wide changes and some
could be left out for addition in next Fedora if we can't make it.
We discussed only additional repo and SCL, but other goals can be also
prepared by people from our group even if we didn't discuss it yet. For
example Reviews or Taskotron don't depend on small group going to
meetings. Do you want to pick tasks and start working on proposals right
now or discuss everything on meetings?
Marcela
10 years, 2 months
Playground Repo Requirements Document
by Toshio Kuratomi
Okay, I started a requirements document for the playground repository:
https://fedoraproject.org/wiki/Env_and_Stacks/Playground_repository_%28dr...
There's three things that we need to do with this to make it useful for FESCo:
1) Add other things we need to decide on to the Open Questions. We
especially need things that will affect the work needed to implement
the repository but we can decide which things those are later.
2) Decide which features from the Open Questions we want to apply to
the Playground repository. Update the description section as we make
decisions.
3) Analyze what will be needed to implement the features we've decided
the Playground repository needs to have and fill in the Identified
Needs sections with that information.
-Toshio
10 years, 2 months
Git for Copr
by Bohuslav Kabrda
Hi all,
at last Env and Stacks WG meeting I've promised to talk to Mirek Suchy, Copr maintainer, about providing sort-of-dist-git (*), perhaps with a web interface, for Copr.
The result of the discussion from Mirek's side is, that he's ok with it as long as he doesn't have to do it, since he's fully occupied with Copr. Also, Copr should still provide the option to build packages as it does now, e.g. sort-of-dist-git should be just a frontend application (not part of Copr), not really something that would be tied directly into Copr.
However, few other people also joined the discussion and the responses to this idea were more like:
- Why do we want to do this? This seems to be like creating Koji from Copr. Copr should remain lightweight.
- Why would we need web interface? People don't need/want it.
- If we really need web interface, why don't we utilize fedorahosted.org?
- Why don't we just allow people to utilize any git (private git repo, git hosting like Github) and provide just tool that would allow users to do "copr build" and it would work automatically (actually it seems that Tito already knows how to do this [1]).
My opinion on this is:
- Utilizing git for tracking changes is important for example for the "fedora-ugly" idea, where we would like to easily track/view specfile history.
- Having a single central place for git repos and offering it to Fedora contributors to use would be a nice addition. Utilizing fedorahosted.org for this usecase might be nice and we could reuse what we already have (although personally I find fedorahosted user experience pretty clumsy).
- At the very least, we could extend the Tito Copr releaser to add some sort of meta-tag to specfile (someone mentioned that this should be possible) containing git url and hash. This way, we would be able to track the repo that srpm came from and the commit hash - again, this would improve the experience for potential contributors, who would be able to easily find where to send pull requests/patches.
Overall, I think this would improve Copr user experience and soften the sharp edges that might otherwise scare potential Fedora contributors. Also, having git repos would IMO significantly improve the possibilities of collaboration and tracking - compared to throwing bunch of srpms into Copr by hand.
I don't think that we necessarily need to provide the hosting for this, but we should definitely provide a howto guide that would describe how to _easily_ achieve this with e.g. Github/Bitbucket repos and so on. Again, we should show an easy way for potential contributors, who may enter Fedora by building in Copr.
Regards,
Slavek.
(*) By sort-of-dist-git, I mean a place for git repos that would hold specfiles/patches, etc., e.g. what Fedora's dist-git holds, but possibly without the lookaside cache... Details to be discussed.
[1] http://miroslav.suchy.cz/blog/archives/2013/12/29/how_to_build_in_copr/in...
10 years, 2 months
