Re: Fedora Elections and Release Name Selection - Voting Information
by Paul W. Frields
On Sat, Jun 06, 2009 at 10:27:51AM -0400, Nigel Jones wrote:
> Fedora 12 Release Name Community Vote:
> -----------------------------------------------
> This community vote has been setup to choose the release name for
> Fedora 12.
>
> The choices for this vote were selected using community suggestions
> from http://fedoraproject.org/wiki/Name_suggestions_for_Fedora_12.
>
> The options for this vote are in alphabetical order:
>
> Chilon
> Constantine
> Orville
> Rugosa
> Umbria
>
> To vote, you must be a member of the ambassadors group in the Fedora
> Account System.
>
> Vote Here: https://admin.fedoraproject.org/voting/about/relnamef12
One small correction to the above: You must be a member of at least
one non-CLA group to vote for the release name. This information is
confirmed in the voting system itself:
https://admin.fedoraproject.org/voting/about/relnamef12
Refer to the previous email for information about all the elections,
or visit the voting application at:
https://admin.fedoraproject.org/voting/
Voting opens on June 7 and will end on June 22, as noted on the wiki
[[Elections]] page. Please take advantage of this opportunity, and
vote wisely. Most importantly, thank you for participating in Fedora!
--
Paul W. Frields http://paul.frields.org/
gpg fingerprint: 3DA6 A0AC 6D58 FEC4 0233 5906 ACDB C937 BD11 3717
http://redhat.com/ - - - - http://pfrields.fedorapeople.org/
irc.freenode.net: stickster @ #fedora-docs, #fedora-devel, #fredlug
_______________________________________________
Fedora-devel-announce mailing list
Fedora-devel-announce(a)redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-announce
14 years, 11 months
Proposal (and yes, I'm willing to do stuff!): Must Use More Macros
by Adam Williamson
Just wanted to run this by the group to make sure it's desired before I
start working on it...
I've been dipping my toes into packaging things for Fedora lately, and
one thing that feels a bit awkward is that the packaging guidelines are
full of boilerplate like:
"Use this when a desktop entry has a 'MimeType key.
%post
update-desktop-database &> /dev/null || :
%postun
update-desktop-database &> /dev/null || :"
"noarch packages
The following macros must be used at the top of the spec file to
determine the correct installation paths:
%{!?tcl_version: %global tcl_version %(echo 'puts $tcl_version' | tclsh)}
%{!?tcl_sitelib: %global tcl_sitelib %{_datadir}/tcl%{tcl_version}}"
"If you are installing anything into the global site_packages directory,
use the following trick. First, define python_sitelib at the top of your
specfile:
%{!?python_sitelib: %global python_sitelib %(%{__python} -c "from distutils.sysconfig import get_python_lib; print get_python_lib()")}"
Heck, there's an entire page full of these:
https://fedoraproject.org/wiki/Packaging/ScriptletSnippets
it seems to me that this is a bit of a silly approach - it encourages
cut and paste errors (or people cutting and pasting non-canonical blocks
from other people's spec files), it just looks bad in spec files, and if
any of those snippets happens to need to be changed a bit - say, the
syntax for updating the desktop database changes, or something - we'd
have to adjust them in seven zillion different spec files.
It seems to me it'd make sense to convert all these kinds of snippets
into macros. Am I right, or is there a reason against doing this?
If I'm right, I'm happy to work on this and contribute it as patches to
the relevant packages, or as a new package in itself, or something.
Where should such macros go? Should we have a separate package for them
which is brought in when you install the development environment package
set? Or should they be added to the appropriate -devel packages - e.g.,
Tcl snippets should be turned into a /etc/rpm/macros.tcl that's in the
tcl-devel package? Or a combination of the two?
Thanks!
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org
http://www.happyassassin.net
14 years, 11 months
Re: Action requested: check dist tags and conditionals
by Julian Sikorski
Bill Nottingham pisze:
> (If you've never used a construct like "%if 0%{?fedora}" in your spec
> file, you can disregard this message.)
>
> Many packages in Fedora use release-based conditionals such as:
>
> ...
> %if 0%{?rhel}
> %endif
>
> %if 0%{?fedora} < 10
> %endif
>
> %{?fedora:%global _with_xfce --with-xfce}
> ...
>
> I'd just like to remind people of the following:
>
> - If you're using open ended conditionals such as:
> %if 0%{?fedora} > 9
> make sure you keep in mind what will happen if %{fedora} isn't defined,
> such as in the case of a derivative distribution.
>
> - If you're building for EPEL from a unified Fedora spec file, and have
> separate %{fedora} and %{rhel} sections, make sure they do the right
> things for any potential new releases, not just %{rhel} = 4 or %{rhel} = 5.
>
> Thanks!
>
> Bill
>
> _______________________________________________
> Fedora-devel-announce mailing list
> Fedora-devel-announce(a)redhat.com
> https://www.redhat.com/mailman/listinfo/fedora-devel-announce
>
This is often used to tailor BuildRequires, I can't take responsibility
what a given release of a derivative distro does or doesn't include.
Julian
14 years, 11 months
package review questions
by jan.klepek
Hi,
I'm working on unofficial package review for redmine
( https://bugzilla.redhat.com/show_bug.cgi?id=499959 ).
Redmine is written in ruby and is using rubygem-actionwebservice, which
is shipped with redmine.
Rubygem-actionwebservice was abandoned by upstream like two years ago,
and same happened for fedora package. My question is if redmine package
should install it on system or it should be considered as blocker, until
upstream of redmine migrate to activeresource.
Second question is when redmine contains plugins which are separate
applications/libraries (coderay is used by redmine for example) this
applications/libraries should be shipped within this package or should
be shipped in it's own package (and package should be created when it
doesn't exists)? My thoughts are that it should be shipped separately,
so it could be used by more applications.
Thanks for help,
Jan Klepek
14 years, 11 months
Re: Maintainer Responsibilities
by Reindl Harald
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
I think it is simple BAD to close bugreports with "upstream"!
For me as "enduser" of fedora i have one bugzilla and i really like
to help with bugreports, try things if maintainer needs better explains
what happens.
But i have no time and no energy to register on the bugzilla of every
piece of software i have installed and i can not look at bugzilla
from rsync, kde, amarok..... the whole time.
Should the enduser try patches and svn-versions?
NO he is user and that was it
If someone maintains a package he can test this much better
and understands many things the normal user never can and want to konw
I know the maintainer can't too for all BUT he get's only bugs for packages
which he maintains, he konws (or should know) the software he maintains
and normally i think he/she have a watch at upstream-bugzilla and
knows MUCH more about the upstream project as the most users
So i think the maintainer should play as "relay", taking fedora-bugreports
and in many cases report them with much more knowing about the software
upstream.
If you want that the enduser report bugs upstream you get no repsonse
in many cases because the user will say "WTF i wanted to help and you
want to say me exactly how i have to help" and after this happens
trhee times he is frustrated and will never ever report bugs
As poweruser you could use many applications and find mny small bugs
in all of them - If you try to handle all of that stuff in the
upstream-project and have a fulltimejob and a family you would
egt a problem - reporting bugs on fedora-bz or lost your life
and deal with all upstream-projects you know
Forget it - I think this is maintainers work or you will lost
respnses time after time
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
iEYEARECAAYFAkooFkEACgkQhmBjz394AnlLzgCglDQ465W4reprEmCbmoiYgw48
X1MAoJj3mdTmlo+SCD+kC/myICY3V+SP
=b+9R
-----END PGP SIGNATURE-----
14 years, 11 months
Re: Maintainer Responsibilities
by Reindl Harald
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
> Message: 1
> Date: Thu, 04 Jun 2009 23:26:12 +0200
> From: Kevin Kofler <kevin.kofler(a)chello.at>
> Subject: Re: Maintainer Responsibilities
> To: fedora-devel-list(a)redhat.com
> Message-ID: <h09e5k$aj1$2(a)ger.gmane.org>
> Content-Type: text/plain; charset=us-ascii
> Your misunderstanding is there: it's US maintainers that are helping YOU
> reporters by fixing your bugs. If you think you don't need our help because
> you don't care about the bug anyway, we can just close it as
> INSUFFICIENT_DATA and stop there.
>
> Kevin Kofler
YOU missunderstand
You really believe a normal user ever registers at bugzilla for every piece of software he uses? The truth is the MOST
upstream-bugzillas are fu**ing ignored and/or arrogant and thats the reason why i gave up in the meantime because i have
better things to do as registering and be ignored or in the best cases i must discuss per private mail that some stupid
upstream-developer repopens a bug after understanding "oh yes this is really a bug"
PHP:
http://bugs.php.net/bug.php?id=42836
Bogus? Not a problem in php when it mixes per-host-configuration?
I'm php-developer and serveradmin for long enough to be sure that this IS a bug
OK PHP6 is pre-alpha but thats not the point - how will tey get away them
They do not need help? the do not got help upstream any longer
You can be sure if a @redhat.com-address or a known maintainer reports this
it would not be closed as "bogus".
For unknown users the developers have a reflex "close as soon as possible"
PHP:
http://bugs.php.net/bug.php?id=42077
Closed with "read why there in the archive" and at this time you could not comment a closed bug and you hace to mail
this crazy peopole until he understands this is a bug - sorry but if this would not be a showstopper for our whole
company if released this way i would se "leave me fuck in peace and do what you want"
Firefox:
I NEVER got any response from upstream bugzilla
https://bugzilla.mozilla.org/show_bug.cgi?id=495196
I do not like to search older ones but if i trie to report bugs there should be any response and i got never ever any
response from firefox-bugzilla
eaccelerator:
http://eaccelerator.net/ticket/307
WTF - New snapshot introduces a new problem, repoorted a year ago, a workaround is no solution and its not really funny
to get ignored in such way
ffmpeg-php
https://sourceforge.net/tracker/?func=detail&aid=2017954&group_id=122353&...
does not compile after ffmpeg-upgrade from livna, livna-bugtracker told i should make a bugreport against upstream and
they ignores it since nearly a year, some other reporters got "svn has fixes" but svn-version also not compiles
_____________________________
Only in the last 2 years i can search a lot of such frustrating things and only the time spent for registering in the
bugzillas should be used for drink some beer to make more sense and yes it is a BIG different if a nobody or a well
known maintainer from a distribution reports something upstream
So please leave me in peace with "report upstream" and take the love for the software and help from users that way they
are able and willing to give or you lose them in many cases with no response in rh-bugzilla AND do not get the bug
reported upstream
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
iEYEARECAAYFAkooi9AACgkQhmBjz394AnnT1QCglPGy7GBT8AfmAC/XIsXOKyQM
ayAAn2xp4iRoeRcJsEUcgBSdMMuZ28eN
=nhRF
-----END PGP SIGNATURE-----
14 years, 11 months
Re: Action requested: check dist tags and conditionals
by Kevin Kofler
Bill Nottingham wrote:
> %if 0%{?fedora} < 10
> %endif
While we are at it: Please make sure you always use 0%{?fedora},
not "%{?fedora}". The latter will do string comparisons and do the wrong
thing when comparing "9" with "10" or "11". We already had a broken
dependency in F9 updates because of that.
So DO NOT DO THIS:
%if "%{?fedora}" < "11" <-- THIS WILL NOT WORK FOR F9!
do this instead:
%if 0%{?fedora} < 11
Also DO NOT DO THIS:
%if "%{?fedora}" > "9" <-- THIS WILL NOT WORK FOR ABOUT 40 MORE YEARS (*)!
do this instead:
%if 0%{?fedora} > 9
(*) assuming Fedora still exists by then ;-) and it'll break again with
Fedora 100...
Of course, this issue will be less pressing with F9 going EOL, but it's good
to remind people of this. It'll also become an issue for %{?rhel} when
we'll reach RHEL 10, which will happen in more or less 8 years if RHEL
continues at its current pace.
Kevin Kofler
14 years, 11 months
Packager = Programmer?
by Frank Murphy
Does trying to become a packager.
Involve being currently a Developer,
as in Programming skills\certification,
whether Perl\Python\c++ etc.
Frank
--
msn: frankly3d skype: frankly3d
Mailing-List Reply to: Mailing-List
Still Learning, Unicode where possible
14 years, 11 months