Re: Call for developers: rpmbuilder
by Chris Evich
> On Mon, Sep 8, 2008 at 1:30 PM, Chris Evich <cevich redhat com> wrote:
>> Hi,
>>
>> Hopefully this is the right mailing list :)
>>
>> Project rpmbuilder aims to provide a template-based approach to packaging. In
>> other words, it removes responsibility from developer to produce an RPM spec
>> file the "right" way. Instead, the package developer just feeds in his
>> project's particulars, and a template-driven engine puts the pieces together
>> and spits out a "sane" RPM and SRPM.
>>
>> https://fedorahosted.org/rpmbuilder
>
> Personally I would rather see Fedora heavily invest in reducing all
> the overhead that currently exists in packaging and putting more
> intelligence into the core of the system, rather than generating spec
> files. Editing spec files is already painful enough; editing
> generated ones sounds even less fun. Essentially if the build system
> knows about things like the Ruby gem specs, Python setup.py, Java's
> Maven, freedesktop.org autotools-based desktop packages, etc., then
> you don't need to autogenerate a lot of spec boilerplate.
>
Actually, I completely agree, and this project is intended to address the
hand-editing you describe. The templates rpmbuilder uses will be shipped
_with it_, I'm not suggesting yet-another-thing-to-edit-when-packaging :)
Then, different templates may be specified at packaging time depending on the
"thing" to be packaged.
For example, I could envision a template for packaging python "stuff" that
uses a setup.py when resolving a python-rpmbuilder template. In other words,
it should be as simple as:
# rpmbuilder --mode=python --pkgname=MyRPMPackageName
--version=1.2.3 --release=4 --sourcedir=. --destdir=.
The result would be, ./MyRPMPackageName-1.2.4-4.noarch.rpm and/or
./MyRPMPackageName-1.2.4-4.noarch.srpm are written to CWD.
Though this could easily extend to other scripting languages / build
environments as well. All that's needed is someone to develop a template once.
15 years, 9 months
Re: Call for developers: rpmbuilder
by Chris Evich
> On Mon, Sep 8, 2008 at 1:30 PM, Chris Evich <cevich redhat com> wrote:
>> Hi,
>>
>> Hopefully this is the right mailing list :)
>>
>> Project rpmbuilder aims to provide a template-based approach to packaging. In
>> other words, it removes responsibility from developer to produce an RPM spec
>> file the "right" way. Instead, the package developer just feeds in his
>> project's particulars, and a template-driven engine puts the pieces together
>> and spits out a "sane" RPM and SRPM.
>
> The name is rather similar to the rpmbuild command. Hopefully this
> would not cause confusion...
>
> Regards,
>
> --
> Michel Salim
> http://hircus.jaiku.com/
>
It was named similar intentionally, but I can see your point. Good thing the
name is easily changed :)
Please contact me off-list for any further comments/suggestions/etc.
Thanks!
15 years, 9 months
Re: Call for developers: rpmbuilder
by Chris Evich
> Chris Evich wrote:
>> Hi,
>>
>> Hopefully this is the right mailing list :)
>>
>> Project rpmbuilder aims to provide a template-based approach to packaging. In
>> other words, it removes responsibility from developer to produce an RPM spec
>> file the "right" way. Instead, the package developer just feeds in his
>> project's particulars, and a template-driven engine puts the pieces together
>> and spits out a "sane" RPM and SRPM.
>>
>> https://fedorahosted.org/rpmbuilder
>
> Interesting. Fails to build here:
>
> gcc -D__USE_FIXED_PROTOTYPES__ -Wall -g -pthread -DORBIT2=1
> -I/home/behdad/.local/include/cairo -I/home/behdad/.local/include/pango-1.0
> -I/home/behdad/.local/include -I/usr/include/glib-2.0
> -I/usr/lib/glib-2.0/include -I/usr/include/libgnome-2.0
> -I/usr/include/libbonobo-2.0 -I/usr/include/orbit-2.0
> -I/usr/include/bonobo-activation-2.0 -I/usr/include/libgnomeui-2.0
> -I/usr/include/libbonoboui-2.0 -I/usr/include/libgnomecanvas-2.0
> -I/usr/include/gtk-2.0 -I/usr/include/gnome-vfs-2.0
> -I/usr/lib/gnome-vfs-2.0/include -I/usr/include/libart-2.0
> -I/usr/lib/gtk-2.0/include -I/usr/include/atk-1.0 -I/usr/include/freetype2
> -I/usr/include/gconf/2 -I/usr/include/libglade-2.0 -I/usr/include/libxml2
> -c -o template.o template.c
> In file included from template.c:32:
> macro.h:39: error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or ‘__attribute__’ before
> ‘macro_new_context’
> macro.h:42: error: expected ‘)’ before ‘mc’
> macro.h:47: error: expected ‘)’ before ‘mc’
> macro.h:52: error: expected ‘)’ before ‘mc’
> template.c: In function ‘template_expand’:
> template.c:41: error: ‘MacroContext’ undeclared (first use in this function)
> template.c:41: error: (Each undeclared identifier is reported only once
> template.c:41: error: for each function it appears in.)
> template.c:41: error: expected ‘;’ before ‘mc’
> template.c:49: error: ‘mc’ undeclared (first use in this function)
> template.c:49: warning: implicit declaration of function ‘macro_new_context’
> make: *** [template.o] Error 1
I think you're missing rpm-devel or some other rpm headers/libraries. Though
N.B. The current development version won't actually do anything for you. See
the project page for a link to a (very old but somewhat working) version.
Contact me off-list for any questions/proposals/info./etc.
15 years, 9 months
Package review trade
by Neil Horman
Hey all-
I've got two review requests outstanding (one of them has been
twisting in the wind waiting for a reviewer for about 6 months). I'd really
like to get both of these packages processed:
https://bugzilla.redhat.com/show_bug.cgi?id=442377
https://bugzilla.redhat.com/show_bug.cgi?id=461305
I'll trade reviews with anyone interested. Just let me know
Thanks!
Neil
--
/***************************************************
*Neil Horman
*Senior Software Engineer
*Red Hat, Inc.
*nhorman(a)redhat.com
*gpg keyid: 1024D / 0x92A74FA1
*http://pgp.mit.edu
***************************************************/
15 years, 9 months
RE: Proposed removal of packages with long-standing FTBFS failures
by Shawn Starr
See below.
> -----Original Message-----
> From: fedora-devel-list-bounces(a)redhat.com
> [mailto:fedora-devel-list-bounces@redhat.com]On Behalf Of Matt Domsch
> Sent: Friday, September 05, 2008 11:40 AM
> To: fedora-devel-list(a)redhat.com
> Subject: Proposed removal of packages with long-standing
> FTBFS failures
>
>
> The following 90 packages have had FTBFS (Fails to Build From Source)
> failures for several months, some as far back as February 2008.
>
> There are several "trivial" failures which could be addressed easily.
> 8 fail due to unpackaged files
> 6 fail due to patch fuzz
> 1 fails due to open() not passing a mode.
>
> http://fedoraproject.org/wiki/FTBFS describes the FTBFS process.
>
> As was proposed to FESCO, packages with unresolved FTBFS bugs
> immediately following the Alpha release will be removed from the
> distribution. Package owners may request that their package _not_ be
> removed provided they are actively working on resolving the FTBFS and
> have a plan to resolve the FTBFS before the Release Candidate
> release. FESCo has the final say of course, but these are the items
> on my candidate list. I'd prefer packages get fixed rather than
> removed. If you are the package owner, or are interested in the
> future of these packages, please investigate these build failures and
> fix them ASAP.
>
> astyle-1.21-6.fc8 [u'433971 ASSIGNED'] (build/make) addutko,mtasaka
Please don't remove astyle, KDE developers use this to keep coding styles in a certain format and it's documented on our wiki how to use astyle. If it doesn't build, I'll co-maintain it.
> lilypond-2.10.33-1.fc8 [u'434394 ASSIGNED'] (build/make) limb
Removing this will break any MIDI based apps, you sure that's good? Especially rosegarden and such which use lilypond for notation.
> pdsh-2.11-6.fc9 [u'440811 ASSIGNED'] (build/make) kg6fnk
Please do not remove PDSH this is needed for clusters especially HPC clusters.
Pdsh should build just fine, if not I'll co-maintain it.
/me worries what releng is doing...
15 years, 9 months
RE: Proposed removal of packages with long-standing FTBFS failures
by Shawn Starr
> -----Original Message-----
> From: fedora-devel-list-bounces(a)redhat.com
> [mailto:fedora-devel-list-bounces@redhat.com]On Behalf Of
> Jesse Keating
> Sent: Tuesday, September 09, 2008 11:47 AM
> To: fedora-devel-list(a)redhat.com
> Subject: RE: Proposed removal of packages with long-standing FTBFS
> failures
>
>
> On Tue, 2008-09-09 at 08:42 -0700, Shawn Starr wrote:
> > /me worries what releng is doing...
>
> releng is preventing a future where we have to rebuild a
> large swath of
> packages for some emergency or another, only to find that a good chunk
> of them fail to rebuild. This is a bad situation to be in.
>
> Often times, the only way to get somebody to work on these is to
> threaten to remove them from the distro. It brings out the people who
> actually care about the packages so that they can work on making them
> build again.
>
I guess that's a good thing seeing, It's gotten me to care about some of those now :-)
> --
> Jesse Keating
> Fedora -- Freedom² is a feature!
> identi.ca: http://identi.ca/jkeating
>
15 years, 9 months
RE: Proposed removal of packages with long-standing FTBFS failures
by Jon Ciesla
> See below.
>
>> -----Original Message-----
>> From: fedora-devel-list-bounces(a)redhat.com
>> [mailto:fedora-devel-list-bounces@redhat.com]On Behalf Of Matt Domsch
>> Sent: Friday, September 05, 2008 11:40 AM
>> To: fedora-devel-list(a)redhat.com
>> Subject: Proposed removal of packages with long-standing
>> FTBFS failures
>>
>>
>> The following 90 packages have had FTBFS (Fails to Build From Source)
>> failures for several months, some as far back as February 2008.
>>
>> There are several "trivial" failures which could be addressed easily.
>> 8 fail due to unpackaged files
>> 6 fail due to patch fuzz
>> 1 fails due to open() not passing a mode.
>>
>> http://fedoraproject.org/wiki/FTBFS describes the FTBFS process.
>>
>> As was proposed to FESCO, packages with unresolved FTBFS bugs
>> immediately following the Alpha release will be removed from the
>> distribution. Package owners may request that their package _not_ be
>> removed provided they are actively working on resolving the FTBFS and
>> have a plan to resolve the FTBFS before the Release Candidate
>> release. FESCo has the final say of course, but these are the items
>> on my candidate list. I'd prefer packages get fixed rather than
>> removed. If you are the package owner, or are interested in the
>> future of these packages, please investigate these build failures and
>> fix them ASAP.
>>
>> astyle-1.21-6.fc8 [u'433971 ASSIGNED'] (build/make) addutko,mtasaka
>
> Please don't remove astyle, KDE developers use this to keep coding styles
> in a certain format and it's documented on our wiki how to use astyle. If
> it doesn't build, I'll co-maintain it.
>
>> lilypond-2.10.33-1.fc8 [u'434394 ASSIGNED'] (build/make) limb
>
> Removing this will break any MIDI based apps, you sure that's good?
> Especially rosegarden and such which use lilypond for notation.
No worries, I fixed it.
>> pdsh-2.11-6.fc9 [u'440811 ASSIGNED'] (build/make) kg6fnk
>
> Please do not remove PDSH this is needed for clusters especially HPC
> clusters.
>
> Pdsh should build just fine, if not I'll co-maintain it.
>
> /me worries what releng is doing...
>
> --
> fedora-devel-list mailing list
> fedora-devel-list(a)redhat.com
> https://www.redhat.com/mailman/listinfo/fedora-devel-list
>
--
novus ordo absurdum
15 years, 9 months
To freeze, or not to freeze
by Jesse Keating
A few weeks back the releng team made a schedule adjustment, to make up
for lost rawhide time due to the intrusion. When we made that schedule
adjustment, we had assumed having a working rawhide within days of that
meeting, giving us a week or so worth of working rawhide to shake out
any pre-beta bugs we wanted to.
Unfortunately, while we were able to /attempt/ rawhide creation as
scheduled, a series of software bugs and bad personnel timing has
prevented those attempts from producing usable rawhide images until
basically today (and today's are pretty shaky from what I hear). This
is not so good, as without an installable rawhide, we don't get a good
idea as to how the installer is working, and we miss out on a lot of
'initial install' testing of software on people's systems. We get a lot
of "I upgraded from foo" type testing, which definitely has it's value,
but I feel we're missing a pretty key part of the rawhide experience.
The Beta freeze is set for Tomorrow. That means the content that would
show up in tomorrow's rawhide would also be the content we use as the
basis of Beta. Any changes after that would have to be ran through the
releng/qa teams to be approved.
Given the "fun" we had with Alpha, I really feel that it would be
prudent to spend a few more unfrozen days with a hopefully continually
working rawhide installer so that we can do some of that last minute
testing of what's wrong before we freeze, and hopefully have a shorter
and more productive freeze period. But this is just my opinion, and
thus I'm putting this out there for discussion.
Feature owners in particular, I'm interested in your opinions as to if
you need a few more days to see what shape your features are in before
we freeze. Ideally the week before a freeze would have been a slow down
period, where large changes were avoided and bugfixing was focused on so
that the Beta was useful. I feel like we didn't give you a chance to do
this and it'll still feel like crash landing planes on the carrier deck
when it come to features in Beta.
I'm interested in what the rest of you think as well, both package
owners and testers alike. If you think our schedule time would be
better spent fixing and verifying things pre-freeze and adding an extra
week to the schedule, or just freeze as things are, and potentially slip
a week during the freeze to make everything usable for the Beta (or the
third option, things are fine as they are, just freeze and release as
scheduled and stop being so paranoid).
What say you?
--
Jesse Keating
Fedora -- Freedom² is a feature!
identi.ca: http://identi.ca/jkeating
15 years, 9 months
Merge review question
by Jon Ciesla
If the owner of a former Core package is unresponsive to activity on a
Merge Review bug, despite being CCd, and the changes needed are minor, and
the reviewer is an uberpackager, is there any reason not to simply commit
the changes to cvs with comments and close the bug?
Thanks,
Jon
--
novus ordo absurdum
15 years, 9 months
Fedora 8 and 9 updates status
by Jesse Keating
As you well know, we have been working hard to get updates for 8 and 9
flowing again, complete with new package signing keys. Discussion has
been somewhat quiet on this front as we've all had our heads down and
have been working hard toward a solution, one that involves little to no
manual effort on behalf of our users.
Today we've reached a major milestone in this progress. We have done a
successful compose of all the existing and as of yesterday pending
updates for Fedora 8 and Fedora 9, all signed with our new keys. These
updates will soon hit mirrors in a new set of directory locations. What
we don't have quite yet is the updated fedora-release package in the old
updates location that will get you the new keys and the new repo
locations. The last mile testing of this update requires that new
updates be live on the mirrors.
Due to the size of the resigned updates, it may take a good while for
our sync process. This may delay getting the new fedora-release out
until tomorrow, but we'll be working hard on it.
While we're working on this update, we'll also be drafting a FAQ page to
explain to users what it is that we're doing, and hopefully answer some
of the questions that will come up. This document will be living
though, and as you encounter questions yourself, or questions via one of
our many avenues of support (email, IRC, forums, LUGS, etc..) please
help us in growing that document. Announcements regarding the location
of said document and how to help with content will be coming shortly.
We deeply appreciate the enormous magnitude of patience you the greater
community has shown us the Fedora project as we work though these
serious issues. It is a great testament to how wonderful it is to work
in and with the Fedora community.
--
Jesse Keating
Fedora -- Freedom² is a feature!
identi.ca: http://identi.ca/jkeating
_______________________________________________
Fedora-devel-announce mailing list
Fedora-devel-announce(a)redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-announce
15 years, 9 months