Re: New package written in Python, without python-*

[Bohuslav Kabrda]

- Original Message -
> Hi everybody,
> 
> I have a question about the name of a new package and would like
> everyone's opinion on this issue, because in our wiki
> (http://fedoraproject.org/wiki/Features/PythonNamingDependingOnImplementation)
> practically forces whatever is written in Python to have name:
> python-% {name}, but I believe this is very bad for our users, if the
> package is a tool, not a python module the user would like to use this
> package:
> 
> # Yum install python-% {name}
> $ ./python-% {Name}-u xxx-p xxx-f file1.txt file2.txt
> 
> This is not the real purpose of the package, which aims to be a
> tool for use by our users.
> There are also packages in Fedora are tools that are written in
> Python and is not named python-% {name}, eg fpaste
> (https://apps.fedoraproject.org/packages/fpaste/sources/spec).
> I created this ticket and transmit it to everyone to view and opine:
> 
> https://bugzilla.redhat.com/show_bug.cgi?id=980318
> 
> Thank you.
> 
> Marcelo Barbosa
> Fedora Project Packager
> Fedora Project Ambassador
> fireman...@fedoraproject.org
> http://planet.fedoraproject.org

Hi,
there is a note in the naming guidelines regarding this [1]:

If a new package is considered an "addon" package that enhances or adds a new 
functionality to an existing Fedora package without being useful on its own, 
its name should reflect this fact.

Therefore if you don't consider your package to be an addon (in this case, 
addon would be a Python library), but an "application", you should name it 
without the "python-" prefix.
The way you chose to name your application seems perfectly fine to me.

-- 
Regards,
Bohuslav "Slavek" Kabrda.

[1] 
https://fedoraproject.org/wiki/Packaging:NamingGuidelines#Addon_Packages_.28General.29
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

New package written in Python, without python-*

[Marcelo Barbosa - Fedora Ambassador]

Hi everybody,

I have a question about the name of a new package and would like
everyone's opinion on this issue, because in our wiki
(http://fedoraproject.org/wiki/Features/PythonNamingDependingOnImplementation)
practically forces whatever is written in Python to have name:
python-% {name}, but I believe this is very bad for our users, if the
package is a tool, not a python module the user would like to use this
package:

# Yum install python-% {name}
$ ./python-% {Name}-u xxx-p xxx-f file1.txt file2.txt

This is not the real purpose of the package, which aims to be a
tool for use by our users.
There are also packages in Fedora are tools that are written in
Python and is not named python-% {name}, eg fpaste
(https://apps.fedoraproject.org/packages/fpaste/sources/spec).
I created this ticket and transmit it to everyone to view and opine:

https://bugzilla.redhat.com/show_bug.cgi?id=980318

Thank you.

Marcelo Barbosa
Fedora Project Packager
Fedora Project Ambassador
fireman...@fedoraproject.org
http://planet.fedoraproject.org
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: More unhelpful update descriptions

[Dan Mashal]

On Mon, Jul 1, 2013 at 2:52 PM, Pierre-Yves Luyten  wrote:
> Not sure if it makes any sense but maybe could we have something like
> "freeze tag changes until desc is better".
>
> I propose this because testers will not _really_ want to -1 karma, and
> as a maintainer it might be a bit hard, but with a good reminder like
> "not pushed to stable until desc is better" I would have made less
> mistakes
>
> yes not being reminded is not an excuse and such proposal would not save
> time, still I believe it could help more than hurt


There is already a perfect example of this.

https://admin.fedoraproject.org/updates/FEDORA-2013-11846/selinux-policy-3.12.1-57.fc19

Dan
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: More unhelpful update descriptions

[Pierre-Yves Luyten]

Le lundi 01 juillet 2013 à 14:01 -0500, Michael Catanzaro a écrit :
> On Mon, 2013-07-01 at 11:25 -0700, Adam Williamson wrote:
> > 
> > You appear to be missing the contention made by me and others that
> > the 
> > update description is not and should not be a simple repetition of
> > any 
> > other content. It is not the RPM changelog. It is not the git commit 
> > log. It is not the upstream changelog.
> And as far as the tooling is concerned... this is the matter of writing
> just one extra sentence, so even if we did have awesome technology to
> write the update description for you from the RPM changelog, and even if
> it was considered acceptable to present that to users, it's not like
> that would save a ton of time and effort.
> 

Not sure if it makes any sense but maybe could we have something like
"freeze tag changes until desc is better".

I propose this because testers will not _really_ want to -1 karma, and
as a maintainer it might be a bit hard, but with a good reminder like
"not pushed to stable until desc is better" I would have made less
mistakes

yes not being reminded is not an excuse and such proposal would not save
time, still I believe it could help more than hurt

Pierre-Yves


-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: libgd breakage

[Orion Poplawski]

On 06/29/2013 09:50 AM, Paulo César Pereira de Andrade wrote:

2013/6/28 Adam Williamson :


   Almost there, but still cannot generate chroot in mock.

DEBUG util.py:264:  Error: Package: gnuplot-4.6.2-2.fc20.x86_64 (build)
DEBUG util.py:264: Requires: libgd.so.2()(64bit)


gnuplot appears to be failing on some sort of texlive-related nonsense:

Execute script `gnuplot.lg'
/usr/bin/t4ht: line 2: -f/gnuplot: No such file or directory
/usr/bin/t4ht: line 3: -f/gnuplot: No such file or directory
/usr/bin/t4ht: line 4: -f/gnuplot: No such file or directory
--- error --- improper command line

and then it just appears to loop over the tex4ht usage message forever
and ever. I don't know if the error is in texlive-tex4ht-bin (which


   It fork bombs for me, and dies a bit later.


provides /usr/bin/t4ht and /usr/bin/tex4ht), or in how gnuplot is
calling it. (But I don't have time to figure out that crap, so I'm just
going to yum remove gnuplot...)


It is not parsing correctly arguments, and t4ht does not check
arguments:

$ cat /usr/bin/t4ht
#!/bin/sh
 $1 $2
 $1 $2
 $1 $2
 tex4ht $2
 t4ht $2  $3

on f18 at least, and other distros t4ht is a real binary:
$ t4ht --help

t4ht.c (2012-07-25-19:28 kpathsea)
t4ht --help
--- error ---

t4ht [-f]filename ...
   -b ignore -d -m -M for bitmaps
   -c...  choose named segment in env file
   -d...  directory for output files   (default:  current)
   -e...  location of tex4ht.env
   -i debugging info
   -g ignore errors in system calls
   -m...  chmod ... of new output files (reused bitmaps excluded)
   -p don't convert pictures   (default:  convert)
   -r replace bitmaps of all glyphs(default:  reuse old ones)
   -M...  chmod ... of all output files
   -Q quit, if tex4ht.c had problems
   -S...  permission for system calls: *-always, filter
   -X...  content for field %%3 in X scripts
   -  content for field %%2 in . scripts

Example:
t4ht name -d/WWW/temp/ -etex4ht-32.env -m644



but on rawhide:
$ t4ht --help
<< fork bombs -- do not try >>

Paulo



See https://bugzilla.redhat.com/show_bug.cgi?id=959696.  Renaming ht to t4ht 
was clearly the wrong thing to do.  I'm reverting it for now.


--
Orion Poplawski
Technical Manager 303-415-9701 x222
NWRA, Boulder/CoRA Office FAX: 303-415-9702
3380 Mitchell Lane   or...@nwra.com
Boulder, CO 80301   http://www.nwra.com
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: More unhelpful update descriptions

[Dan Mashal]

On Mon, Jul 1, 2013 at 2:41 PM, Björn Persson
 wrote:
> Perhaps you would like to write an RFC specifying the Source Code,
> Changelogs and Release Notes Publishing Protocol and submit it to the
> IETF, so that there will be a sane way to automatically find and parse
> those changelogs and release notes? Or do you expect Bodhi to magically
> find and understand upstream release notes in a gazillion random
> locations and an unbounded number of formats? Or what exactly do you
> want the "better tooling" to do?

I'm pretty sure there is a Bodhi 2.0 in the works, as noted by the
list of talks for Flock, hopefully this will take care of that.

Dan
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: More unhelpful update descriptions

[Björn Persson]

Richard W.M. Jones wrote:
> As I think I said pretty clearly, there are two streams of
> documentation: the detailed changelogs and the release notes (which
> summarise changes in a human-readable form for a whole release).
> 
> These should already exist, upstream.
> 
> No need for them to be duplicated, *if* we had better tooling.

Perhaps you would like to write an RFC specifying the Source Code,
Changelogs and Release Notes Publishing Protocol and submit it to the
IETF, so that there will be a sane way to automatically find and parse
those changelogs and release notes? Or do you expect Bodhi to magically
find and understand upstream release notes in a gazillion random
locations and an unbounded number of formats? Or what exactly do you
want the "better tooling" to do?

Björn Persson


signature.asc
Description: PGP signature
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: find-lang.sh search path

[Antonio Trande]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 07/01/2013 10:31 PM, Michael Schwendt wrote:
> On Mon, 01 Jul 2013 20:57:46 +0200, Antonio wrote:
> 
>> On Mon 01 Jul 2013 08:53:44 PM CEST, Michael Schwendt wrote:
>>> On Mon, 01 Jul 2013 20:36:25 +0200, Antonio wrote:
>>> 
 In qgifer package building (Bug#979702), I need to include
 language *.qm files from source software.
 
 Currently, 'cmake' command puts language files into
 /usr/share/locale directory but find-lang.sh doesn't locate
 them in $RPM_BUILD_ROOT. Why ?
>>> 
>>> The usage of %find_lang seems incorrect:
>>> 
 + /usr/lib/rpm/find-lang.sh 
 /home/sagitter/rpmbuild/BUILDROOT/qgifer-0.2.1-1.fc19.x86_64
 pl --with-qt No translations found for pl in 
 /home/sagitter/rpmbuild/BUILDROOT/qgifer-0.2.1-1.fc19.x86_64
>>> 
>>> There's a suspicious "pl" in there.
>>> 
>> 
>> "pl" is the file name without extension (pl.qm). In .spec file:
>> 
>> ... %find_lang pl --with-qt %find_lang ru --with-qt ...
>> 
>> Are they correct ?
> 
> No.
> 
> Multiple invocations of %find_lang is a consecutive fault after
> installing the locale files wrongly. You would run %find_lang once
> only and give it the common name of the files to search for. Most
> often that is the package %{name}:
> 
> https://fedoraproject.org/wiki/Packaging:Guidelines#Handling_Locale_Files

Indeed,
> 
but in this case locale files are not named %{name} and I
don't know why language files (pl.qm and ru.qm) are not found. :)
Also indicating just one file, I obtain ever same error.

> 
> In your review request, the original path is
> 
> %{_datadir}/%{name}/locale/*.qm
> 
> which looks more usual for Qt based projects.
> 
>> /usr/share/locale/pl.qm /usr/share/locale/ru.qm
> 
> This would conflict with any other project installing the files
> like that. There is no %name prefix in there at all. No reference
> to the qgifer name.
> 

Genuinely, forcing /usr/share/locale/ directory is just a my attempt
to find language files through  find-lang.sh .


- -- 
- 
Antonio Trande

mailto: sagit...@fedoraproject.org
Homepage: http://www.fedoraos.worpress.com
GPG Key: D400D6C4
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.13 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIcBAEBAgAGBQJR0fRgAAoJED2vIvfUANbEiS4P/2arDNlBxx7/TPqDFPu68oAX
Fa4Y372xI9fmRY1wrH/e4RC9rPiw1r7oNiqxR3K1C67G/xY4fb9xUsOQW4rk7GgR
PkVUUxFhLDiehcbuXyIp92nAy/ben3D3ksIcarmiJN2rqREp62PvzgTcfa2KWV7S
y/ZlYCUT8ZWxmj8P9jNafhUaOjo+1+tTJrEp0o+h2kYfM75++ES+im8U4aYhfLiv
01IOQIYK7EbYK8x5+sLQPkEYxEaikmpzLEcWIr9AnE8mksINje1yq1lwfEI2+WCL
7sV/SjL61GTNUxKw3NLWm/bg88TQIO/5KT4pcLeYRf5vv8GN9RAZSB7TjWBtu+K2
2orKZBHXHq+kNn7lT4rbik/F6pWV8cnA8v8CFJxm9nr1xPw8+mFAzpjmBk0ncVs9
1+lrwjVy7tECbietsnxmq1ZB0jLUnhTT1SmBsRDXICKEXrWT/5Uc0TpjGUvFA48L
l+0/dNwR8PSXm6vVg9QCClg8rSjFUluPJuT0Bqz0pu08FXgJfJu8F3+89tpwSeKK
KDjTbnaAqStaq3k6PgI75nRTgGZJt5m217iKmk6BSQNTGyQsNmWdsoP2LSjDDScs
OrFPOkNpNZw0nKUQNAyEQ7sRjMHfxyvf5RIvM0EiXFvDSJDXuPjQdpbrdqh1OpYL
s6Rgj/DoF2f9HsqgpYhT
=hatN
-END PGP SIGNATURE-
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: find-lang.sh search path

[Michael Schwendt]

On Mon, 01 Jul 2013 20:57:46 +0200, Antonio wrote:

> On Mon 01 Jul 2013 08:53:44 PM CEST, Michael Schwendt wrote:
> > On Mon, 01 Jul 2013 20:36:25 +0200, Antonio wrote:
> >
> >> In qgifer package building (Bug#979702), I need to include language
> >> *.qm files from source software.
> >>
> >> Currently, 'cmake' command puts language files into /usr/share/locale
> >> directory but find-lang.sh doesn't locate them in $RPM_BUILD_ROOT. Why ?
> >
> > The usage of %find_lang seems incorrect:
> >
> >> + /usr/lib/rpm/find-lang.sh
> >> /home/sagitter/rpmbuild/BUILDROOT/qgifer-0.2.1-1.fc19.x86_64 pl --with-qt
> >> No translations found for pl in
> >> /home/sagitter/rpmbuild/BUILDROOT/qgifer-0.2.1-1.fc19.x86_64
> >
> > There's a suspicious "pl" in there.
> >
> 
> "pl" is the file name without extension (pl.qm). In .spec file:
> 
> ...
> %find_lang pl --with-qt
> %find_lang ru --with-qt
> ...
> 
> Are they correct ?

No.

Multiple invocations of %find_lang is a consecutive fault after installing
the locale files wrongly. You would run %find_lang once only and give it
the common name of the files to search for. Most often that is the package
%{name}:

  https://fedoraproject.org/wiki/Packaging:Guidelines#Handling_Locale_Files

In your review request, the original path is

  %{_datadir}/%{name}/locale/*.qm

which looks more usual for Qt based projects.

> /usr/share/locale/pl.qm
> /usr/share/locale/ru.qm

This would conflict with any other project installing the files like
that. There is no %name prefix in there at all. No reference to the
qgifer name.

-- 
Fedora release 19 (Schrödinger’s Cat) - Linux 3.9.8-300.fc19.x86_64
loadavg: 0.08 0.06 0.05
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: More unhelpful update descriptions

[Richard W.M. Jones]

On Mon, Jul 01, 2013 at 11:25:51AM -0700, Adam Williamson wrote:
> On 2013-07-01 1:28, Richard W.M. Jones wrote:
> >Since this topic comes up every few months, and no one's pointed
> >out the obvious answer yet, I'll say it:
> >
> >* Instead of making up more rules, make the tooling better so
> >we don't have to repeat update descriptions in multiple places. *
> 
> You appear to be missing the contention made by me and others that
> the update description is not and should not be a simple repetition
> of any other content. It is not the RPM changelog. It is not the git
> commit log. It is not the upstream changelog.

As I think I said pretty clearly, there are two streams of
documentation: the detailed changelogs and the release notes (which
summarise changes in a human-readable form for a whole release).

These should already exist, upstream.

No need for them to be duplicated, *if* we had better tooling.

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
libguestfs lets you edit virtual machines.  Supports shell scripting,
bindings from many languages.  http://libguestfs.org
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: More unhelpful update descriptions

[Johannes Lips]

Richard W.M. Jones wrote:

Since this topic comes up every few months, and no one's pointed
out the obvious answer yet, I'll say it:

* Instead of making up more rules, make the tooling better so
we don't have to repeat update descriptions in multiple places. *
Wouldn't it make sense to perhaps apply different rules or policies for 
different types of packages? I mean we could focus on those applications 
a regular user sees, like all the Office, Internet and Multimedia apps.
And make the rules for libs and all that stuff, normally only devs are 
interested in, less strict.
So we always write update comments with the respective target audience, 
making them less technical for all the userspace applications and so on.
On the other hand, bodhi probably can't distinguish between those two 
types of packages, or?


Johanens


Rich.



--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: More unhelpful update descriptions

[Till Maas]

On Mon, Jul 01, 2013 at 02:01:29PM -0500, Michael Catanzaro wrote:

> And as far as the tooling is concerned... this is the matter of writing
> just one extra sentence, so even if we did have awesome technology to
> write the update description for you from the RPM changelog, and even if
> it was considered acceptable to present that to users, it's not like
> that would save a ton of time and effort.

According to Bodhi it would have saved more than 1 sentences for
Fedora 17.

> I absolutely think there should be at least some minimal level of
> quality to what we present to users in the default graphical update
> interface

You easily get a good minimal level of quality by just using the
available information in an update such as the type and mentioned bug
reports.

Regards
Till
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: [Owner-change] Fedora packages ownership change

[Pierre-Yves Chibon]

On Mon, 2013-07-01 at 20:48 +0200, Michael Schwendt wrote:
> On Mon,  1 Jul 2013 18:14:46 + (UTC), nobody fedoraproject org wrote:
> 
> > 9 packages were orphaned
> 
> > php-pecl-apc [devel] was orphaned by remi
> >  APC caches and optimizes PHP intermediate code
> >  https://admin.fedoraproject.org/pkgdb/acls/name/php-pecl-apc
> 
> Could the script be enhanced to distinguish between "orphaned" and
> "deprecated" (= retired)?
> 
> For orphans in pkgdb any packager can simply click the "Take ownership"
> button. For retired packages, the process is different, and there may be a
> good reason why a package has been retired/dropped/replaced/…

fedmsg announce them so we should be able to indeed.
So we'll have:
- orphaned
- unorphaned
- retired
- changed

Pierre
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: find-lang.sh search path

[Michael Schwendt]

On Mon, 01 Jul 2013 20:36:25 +0200, Antonio wrote:

> In qgifer package building (Bug#979702), I need to include language
> *.qm files from source software.
> 
> Currently, 'cmake' command puts language files into /usr/share/locale
> directory but find-lang.sh doesn't locate them in $RPM_BUILD_ROOT. Why ?

The usage of %find_lang seems incorrect:

> + /usr/lib/rpm/find-lang.sh
> /home/sagitter/rpmbuild/BUILDROOT/qgifer-0.2.1-1.fc19.x86_64 pl --with-qt
> No translations found for pl in
> /home/sagitter/rpmbuild/BUILDROOT/qgifer-0.2.1-1.fc19.x86_64

There's a suspicious "pl" in there.

-- 
Fedora release 19 (Schrödinger’s Cat) - Linux 3.9.8-300.fc19.x86_64
loadavg: 0.16 0.15 0.16
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: More unhelpful update descriptions

[Michael Catanzaro]

On Mon, 2013-07-01 at 11:25 -0700, Adam Williamson wrote:
> 
> You appear to be missing the contention made by me and others that
> the 
> update description is not and should not be a simple repetition of
> any 
> other content. It is not the RPM changelog. It is not the git commit 
> log. It is not the upstream changelog. 
And as far as the tooling is concerned... this is the matter of writing
just one extra sentence, so even if we did have awesome technology to
write the update description for you from the RPM changelog, and even if
it was considered acceptable to present that to users, it's not like
that would save a ton of time and effort.

I absolutely think there should be at least some minimal level of
quality to what we present to users in the default graphical update
interface


signature.asc
Description: This is a digitally signed message part
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: find-lang.sh search path

[Antonio]

On Mon 01 Jul 2013 08:53:44 PM CEST, Michael Schwendt wrote:
> On Mon, 01 Jul 2013 20:36:25 +0200, Antonio wrote:
>
>> In qgifer package building (Bug#979702), I need to include language
>> *.qm files from source software.
>>
>> Currently, 'cmake' command puts language files into /usr/share/locale
>> directory but find-lang.sh doesn't locate them in $RPM_BUILD_ROOT. Why ?
>
> The usage of %find_lang seems incorrect:
>
>> + /usr/lib/rpm/find-lang.sh
>> /home/sagitter/rpmbuild/BUILDROOT/qgifer-0.2.1-1.fc19.x86_64 pl --with-qt
>> No translations found for pl in
>> /home/sagitter/rpmbuild/BUILDROOT/qgifer-0.2.1-1.fc19.x86_64
>
> There's a suspicious "pl" in there.
>

"pl" is the file name without extension (pl.qm). In .spec file:

...
%find_lang pl --with-qt
%find_lang ru --with-qt
...

Are they correct ?


Antonio Trande

mailto: sagit...@fedoraproject.org
Homepage: http://www.fedoraos.worpress.com
GPG Key: D400D6C4
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: find-lang.sh search path

[Richard Shaw]

On Mon, Jul 1, 2013 at 1:36 PM, Antonio  wrote:

> In qgifer package building (Bug#979702), I need to include language
> *.qm files from source software.
>
> Currently, 'cmake' command puts language files into /usr/share/locale
> directory but find-lang.sh doesn't locate them in $RPM_BUILD_ROOT. Why ?
> - -- Installing:
>
> /home/sagitter/rpmbuild/BUILDROOT/qgifer-0.2.1-1.fc19.x86_64/usr/share/locale/pl.qm
> - -- Installing:
>
> /home/sagitter/rpmbuild/BUILDROOT/qgifer-0.2.1-1.fc19.x86_64/usr/share/locale/ru.qm
>

It doesn't look right to me, but I'm not a translation expert by any means.

The translations don't go directly in the locale dir but under named
directories for each language, try looking under /usr/share/locale on your
system.

In either case, it doesn't look like qm (QT translations) go in
/usr/share/locale, but rather in a per application location, i.e.:

/usr/share/qgifer/locale/pl.qm

Or something like that.

Richard
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: [Owner-change] Fedora packages ownership change

[Michael Schwendt]

On Mon,  1 Jul 2013 18:14:46 + (UTC), nobody fedoraproject org wrote:

> 9 packages were orphaned

> php-pecl-apc [devel] was orphaned by remi
>  APC caches and optimizes PHP intermediate code
>  https://admin.fedoraproject.org/pkgdb/acls/name/php-pecl-apc

Could the script be enhanced to distinguish between "orphaned" and
"deprecated" (= retired)?

For orphans in pkgdb any packager can simply click the "Take ownership"
button. For retired packages, the process is different, and there may be a
good reason why a package has been retired/dropped/replaced/…
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

find-lang.sh search path

[Antonio]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hi all.

In qgifer package building (Bug#979702), I need to include language
*.qm files from source software.

Currently, 'cmake' command puts language files into /usr/share/locale
directory but find-lang.sh doesn't locate them in $RPM_BUILD_ROOT. Why ?

...
Install the project...
/usr/bin/cmake -P cmake_install.cmake
- -- Install configuration: "Release"
- -- Installing:
/home/sagitter/rpmbuild/BUILDROOT/qgifer-0.2.1-1.fc19.x86_64/usr/bin/qgifer
- -- Installing:
/home/sagitter/rpmbuild/BUILDROOT/qgifer-0.2.1-1.fc19.x86_64/usr/share/qgifer/menu/qgifer
- -- Installing:
/home/sagitter/rpmbuild/BUILDROOT/qgifer-0.2.1-1.fc19.x86_64/usr/share/applications/qgifer.desktop
- -- Installing:
/home/sagitter/rpmbuild/BUILDROOT/qgifer-0.2.1-1.fc19.x86_64/usr/share/icons/hicolor/128x128/apps/qgifer.xpm
- -- Installing:
/home/sagitter/rpmbuild/BUILDROOT/qgifer-0.2.1-1.fc19.x86_64/usr/share/locale/pl.qm
- -- Installing:
/home/sagitter/rpmbuild/BUILDROOT/qgifer-0.2.1-1.fc19.x86_64/usr/share/locale/ru.qm
- -- Installing:
/home/sagitter/rpmbuild/BUILDROOT/qgifer-0.2.1-1.fc19.x86_64/usr/share/doc/qgifer-0.2.1/LICENSE
- -- Installing:
/home/sagitter/rpmbuild/BUILDROOT/qgifer-0.2.1-1.fc19.x86_64/usr/share/doc/qgifer-0.2.1/COPYRIGHT
- -- Installing:
/home/sagitter/rpmbuild/BUILDROOT/qgifer-0.2.1-1.fc19.x86_64/usr/share/doc/qgifer-0.2.1/ChangeLog
+ popd
~/rpmbuild/BUILD/qgifer-0.2.1-source
+ /usr/lib/rpm/find-lang.sh
/home/sagitter/rpmbuild/BUILDROOT/qgifer-0.2.1-1.fc19.x86_64 pl --with-qt
No translations found for pl in
/home/sagitter/rpmbuild/BUILDROOT/qgifer-0.2.1-1.fc19.x86_64
error: Bad exit status from /var/tmp/rpm-tmp.sbQ58D (%install)




- 
Antonio Trande

mailto: sagit...@fedoraproject.org
Homepage: http://www.fedoraos.worpress.com
GPG Key: D400D6C4
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.13 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIcBAEBAgAGBQJR0cwpAAoJED2vIvfUANbEwW8QANaxJshS3nn3zgymiinyRE6R
PKDxCkuv3o53GB+3ApVNtzyB93zW/5jmpni2aVySxwRzhp0jKIN4Ybh4m1gHtKgX
9qG8Ep2zTMR7awBgYAyHvQcplqliA7jp+VMCpN+jF6Lm63agqNt1yGm/4awK2AtM
oVXjwJvcNCC8/HerJ/w1iIGlrIgwIXS7RxR7rwF9JYY+Ypu2INQM/AEK9ukShirq
TYWFRNaAVQwu6mFZ1Yf9N9qIIOAwJ1RiFdvV4rnTCHwasRyxrNoA3kjw3GljBHfo
zcOFnGMd7hofHd+P/0udraY6rRJiUcgEZOXZuGFn5kJh2dUepjAzgeDkQVEpuhLd
iSjv9agoRtQ1wKQKE8xKjpNrDjVqVdAigPNCjDc08Ybdn7I8e5JaWAms3d1YEXdh
e6e6ujYueEJQtnhcDMgMnufGYanGbkTPDtCKd6YLBcCarpfZ07wG+bASCyRaa1t7
cQgjBa15whmMqhuPADh7uXY8YV4u8fSnhwMRvvBEie+XBcx3TWO/s+TRfDbvSnqL
BKpTiXvnO2dHVoDISzr88FW9XwYZx+n4nVPHDEXeLO593pMpgd34Se8jPvHX/NHL
6txXE6/scw5qBpYE/YRxrOztqw186QvRHGM212dk5DrrgKm4J8Eapa+8Bnk3X3SL
hmT/eKGAC6WRD155fW5G
=EkQC
-END PGP SIGNATURE-
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: More unhelpful update descriptions

[Adam Williamson]

On 2013-07-01 1:28, Richard W.M. Jones wrote:

Since this topic comes up every few months, and no one's pointed
out the obvious answer yet, I'll say it:

* Instead of making up more rules, make the tooling better so
we don't have to repeat update descriptions in multiple places. *


You appear to be missing the contention made by me and others that the 
update description is not and should not be a simple repetition of any 
other content. It is not the RPM changelog. It is not the git commit 
log. It is not the upstream changelog.


--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora
http://www.happyassassin.net
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

[Owner-change] Fedora packages ownership change

[nobody]

Change in ownership over the last 168 hours
===

9 packages were orphaned

mysql-connector-c++ [devel] was orphaned by remi
 MySQL database connector for C++
 https://admin.fedoraproject.org/pkgdb/acls/name/mysql-connector-c++
guiloader-c++ [devel,f17,f18,f19] was orphaned by fab
 C++ Binding to GuiLoader Library
 https://admin.fedoraproject.org/pkgdb/acls/name/guiloader-c++
php-pecl-apc [devel] was orphaned by remi
 APC caches and optimizes PHP intermediate code
 https://admin.fedoraproject.org/pkgdb/acls/name/php-pecl-apc
bsd-mailx [devel] was orphaned by pschiffe
 Simple mail user agent
 https://admin.fedoraproject.org/pkgdb/acls/name/bsd-mailx
python-github [devel,f19] was orphaned by bkabrda
 A Python library implementing the full Github API v3
 https://admin.fedoraproject.org/pkgdb/acls/name/python-github
guiloader [devel,f17,f18,f19] was orphaned by fab
 GuiXml Loader Library
 https://admin.fedoraproject.org/pkgdb/acls/name/guiloader
libgssglue [devel] was orphaned by steved
 Generic Security Services Application Programming Interface Library
 https://admin.fedoraproject.org/pkgdb/acls/name/libgssglue
mysql-workbench [devel] was orphaned by remi
 A MySQL visual database modeling, administration and querying tool
 https://admin.fedoraproject.org/pkgdb/acls/name/mysql-workbench
libgssapi [devel,f17,f18,f19] was orphaned by steved
 Generic Security Services Application Programming Interface Library
 https://admin.fedoraproject.org/pkgdb/acls/name/libgssapi

7 packages unorphaned
-
rohara  unorphaned : haproxy [EL-5]
skottlerunorphaned : rubygem-minitest [EL-6]
romaunorphaned : fmtools [devel]
cicku   unorphaned : elementary-icon-theme [f17]
mizdebskunorphaned : java-service-wrapper [f18]
cicku   unorphaned : gcin [f19]
skottlerunorphaned : cppunit [EL-5]

6 packages changed owner

limbgave to gwei3  : oat [EL-6]
limbgave to than   : apiextractor [EL-6]
limbgave to than   : python-pyside [EL-6]
limbgave to than   : shiboken [EL-6]
limbgave to than   : sparsehash [EL-6]
limbgave to than   : generatorrunner [EL-6]
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: [rawhide] kernel-install and grubby and ... what's going on?

[Matthew Miller]

On Mon, Jul 01, 2013 at 01:21:16PM -0400, Josh Boyer wrote:
> - kernel.spec now requires systemd >  kernel-install in it>

Which is fine, because it's not like we're gonna support older kernels or
running without systemd.

> - kernel.spec calls kernel-install instead of new-kernel-pkg (which is
> provided by grubby)
> - kernel-install in Fedora 19 and 20 is patched to call new-kernel-pkg
> under the covers for the bootloader config update portions
> - kernel-install calls dracut to create the initramfs (I think).
> - eventually grub2 will deal with the BootLoaderSpec stuff directly
> and kernel-install won't call new-kernel-pkg any longer.


So until that eventually, it looks like *something* needs to require
new-kernel-pkg so that doesn't get missed. It feels a little odd to put that
requires in the systemd package. Or should we just put the package in it in
@core?


-- 
Matthew Miller  ☁☁☁  Fedora Cloud Architect  ☁☁☁  
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: [rawhide] kernel-install and grubby and ... what's going on?

[Josh Boyer]

On Mon, Jul 1, 2013 at 12:00 PM, Matthew Miller
 wrote:
> It looks like the venerable calls to new-kernel-pkg (from grubby) have been
> replaced by kernel-install, which checks if /sbin/new-kernel-pkg exists and
> runs that if it does, and otherwise does this stuff
> http://www.freedesktop.org/wiki/Specifications/BootLoaderSpec/.
>
> I'm trying to update the cloud kickstart files for F20 (now that F19 is in
> the can, right?), and am trying to understand what the plan and migration
> path is here. I can't find a feature page for this.
>
> Right now, immediately, the result is no initramfs being created under
> appliace-creator. (We're hoping to move _away_ from appliance-creator for
> this release, but one step at a time.) I went ahead and added grubby to the
> kickstart package manifest, but I'm not sure if that's the right thing.
>
> How is this _supposed_ to be working?

You should probably ask Harald explicitly to be sure, but the current
state of affairs is:

- kernel.spec now requires systemd > 
- kernel.spec calls kernel-install instead of new-kernel-pkg (which is
provided by grubby)
- kernel-install in Fedora 19 and 20 is patched to call new-kernel-pkg
under the covers for the bootloader config update portions
- kernel-install calls dracut to create the initramfs (I think).
- eventually grub2 will deal with the BootLoaderSpec stuff directly
and kernel-install won't call new-kernel-pkg any longer.

I'm not exactly sure what the timeframe for that last item is, but
it's not in the immediate future.

josh
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: More unhelpful update descriptions

[Przemek Klosowski]

On 06/29/2013 05:12 PM, T.C. Hollingsworth wrote:


I do agree that the RPM changelog is completely useless in the case of
most of my packages, and if there is something interesting there it
would benefit from a slightly longer description in the update summary
rather than some magical automatic inclusion of the RPM changelog.


"changelogs should contain CVEs of backported security patches"

RPM changelog is the most accessible record on an installed system. Many 
environments require accountability for security patching---admins must 
be able to respond whether they are patched against specific exploits 
usually given by their CVE number. They can either show that 'we have 
version 5.5.13 which fixes this bug', or else that the fix was 
backported---and an RPM changelog listing security fixes by CVE numbers 
is a very convenient way of proving that.


It seems to be a widely used practice, but it is not a formal 
requirement. I opened a RFE for that to happen.

--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Packaging Go libraries for Fedora

[Lars Seipel]

On Mon, Jul 01, 2013 at 02:39:11PM +0100, Richard W.M. Jones wrote:
> Now as far as I can tell, we can just ignore the $GOPATH stuff, and
> instead drop files into the right places in %_libdir/golang.  It works
> in my single, limited experiment, but I've no idea if this is the
> Right Thing to do.

One issue with this approach is that $GOROOT (i.e. %_libdir/golang)
always takes precedence over $GOPATH. Users would be unable to use
another version of a library that is already installed through RPM.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Fedora Gooey Karma as GSOC project

[Till Maas]

Hi,

On Wed, Jun 05, 2013 at 06:48:55PM +0200, Branislav Blaskovic wrote:

> My proposal [1] is available on fedoraproject wiki page where you can find
> main features of this new tool.

> If you have any questions, please feel free to contact me here on mailing
> list, off-list or br...@freenode.org.
> 
> [1]
> https://fedoraproject.org/wiki/GSOC_2013/Student_Application_Blaskovic/Fedora_Gooey_Karma%284111%29

is this planned to be a replacement or an alternative to the command
line tool?

Regards
Till
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

[rawhide] kernel-install and grubby and ... what's going on?

[Matthew Miller]

It looks like the venerable calls to new-kernel-pkg (from grubby) have been
replaced by kernel-install, which checks if /sbin/new-kernel-pkg exists and
runs that if it does, and otherwise does this stuff
http://www.freedesktop.org/wiki/Specifications/BootLoaderSpec/.

I'm trying to update the cloud kickstart files for F20 (now that F19 is in
the can, right?), and am trying to understand what the plan and migration
path is here. I can't find a feature page for this.

Right now, immediately, the result is no initramfs being created under
appliace-creator. (We're hoping to move _away_ from appliance-creator for
this release, but one step at a time.) I went ahead and added grubby to the
kickstart package manifest, but I'm not sure if that's the right thing.

How is this _supposed_ to be working?



-- 
Matthew Miller  ☁☁☁  Fedora Cloud Architect  ☁☁☁  
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Packaging Go libraries for Fedora

[Richard W.M. Jones]

On Mon, Jul 01, 2013 at 04:14:10PM +0200, Florian Weimer wrote:
> On 07/01/2013 03:39 PM, Richard W.M. Jones wrote:
> >But for libraries that aren't bundled with the Go compiler, it looks
> >like the Go designers intended you to keep them in your home directory:
> >
> >http://golang.org/doc/code.html#Organization
> 
> It's also expected that you keep around source code and recompile
> from source each time something in the dependency tree changes.
> There's no ABI stability whatsoever because internal implementation
> details (struct sizes and offsets, say) bubble up due to inlining.

Also, it'll try to recompile stuff in the %_libdir/golang directory if
it thinks it's out of date.  And fail, obviously.  Joy.

https://bugzilla.redhat.com/show_bug.cgi?id=973842#c23

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming blog: http://rwmj.wordpress.com
Fedora now supports 80 OCaml packages (the OPEN alternative to F#)
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

APC is dead - Welcome APCU

[Remi Collet]

Hi,

php-pecl-apc have been retired from rawhide repository.

php-pecl-apcu is a dropin alternative for user cache and is also
available in F18, F19 and EPEL6 (testing).

It's time to switch and test.


Remi.

P.S. opcode cache is now provided by zend-opcache (php 5.5) or
php-pecl-zendopcache (php 5.3 / 5.4), the official PHP project opcode cache.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: F19 upgrade pulls in a lot of i686 packages

[Michael Schwendt]

On Sun, 30 Jun 2013 17:03:58 +0200, Heiko Adams wrote:

> But why doesn't prevent yum packages with arch != ($Basearch, noarch)
> from being pulled in by default?

Yum developers can answer that. Probably such a prevention technique is
not implemented, because it would require checks that might not be 100%
without user-intervention.

That's one reason why we're adding %_isa to package dependencies.
To make deps more strict and safer, but that doesn't help with Obsoletes
yet.

"noarch -> arch" means the installed package was for "no particular arch"
(= "any arch"). If that noarch package gets replaced, one way is to
install the replacement package for all archs it's available for, which is
as close to "any arch" as it can get for a multi-arch platform (and
packages, which might have been installed only because they are included
in some comps group).

Also remember, a dependency on just the "khrplatform-devel" package name
can be resolved with either the i686 or the x86_64 build. If you remove
khrplatform-devel.noarch from a pure x86_64 installation and replace it
with khrplatform-devel.x86_64, that might be okay for the x86_64 run-time,
but something has been taken away (since noarch is for more archs than
x86_64). Then, if you install i686 packages with a dependency on the
khrplatform-devel package name, Yum would need to guess that the x86_64
build of that package might be insufficient. Not pretty.

> It doesn't make sense to install i.e.
> x86_64 packages on an i686 System.

That's the reverse scenario from above. On that "i686 System", available
noarch packages are also for x86_64. When removing noarch packages and
replacing them with just a single arch build, you remove _something_
which you may need to add later. Unless the user configures the system
to tell that it will stay x86_64 only.

> So those packages should be ignored
> comletely by yum as long as the user doesn't instruct yum explicit to
> install them.

Again, if the package installer by default "takes away" something
(when replacing noarch packages), that might be missing later.

-- 
Fedora release 19 (Schrödinger’s Cat) - Linux 3.9.8-300.fc19.x86_64
loadavg: 0.00 0.01 0.07
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

[perl-threads] Specify all dependencies

[Petr Pisar]

commit 6fc59cad87e5bdbad64a60b82cfc2f7b2a4fef78
Author: Petr Písař 
Date:   Mon Jul 1 17:05:43 2013 +0200

Specify all dependencies

 perl-threads.spec |7 ++-
 1 files changed, 6 insertions(+), 1 deletions(-)
---
diff --git a/perl-threads.spec b/perl-threads.spec
index 1725150..b1c2105 100644
--- a/perl-threads.spec
+++ b/perl-threads.spec
@@ -1,6 +1,6 @@
 Name:   perl-threads
 Version:1.87
-Release:1%{?dist}
+Release:2%{?dist}
 Summary:Perl interpreter-based threads
 License:GPL+ or Artistic
 Group:  Development/Libraries
@@ -19,6 +19,8 @@ BuildRequires:  perl(XSLoader)
 # Tests only:
 BuildRequires:  perl(ExtUtils::testlib)
 BuildRequires:  perl(IO::File)
+BuildRequires:  perl(Hash::Util)
+BuildRequires:  perl(POSIX)
 BuildRequires:  perl(Test::More)
 Requires:   perl(:MODULE_COMPAT_%(eval "`perl -V:version`"; echo $version))
 Requires:   perl(Carp)
@@ -57,6 +59,9 @@ make test
 %{_mandir}/man3/*
 
 %changelog
+* Mon Jul 01 2013 Petr Pisar  - 1.87-2
+- Specify all dependencies
+
 * Thu May 30 2013 Petr Pisar  - 1.87-1
 - 1.87 bump
 
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-de...@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel

[perl-Test-Vars] Update dependencies

[Jitka Plesnikova]

commit ed8834dd81489416f76ffd3fe5d223c00fc5379d
Author: Jitka Plesnikova 
Date:   Mon Jul 1 17:05:35 2013 +0200

Update dependencies

 perl-Test-Vars.spec |   21 +++--
 1 files changed, 15 insertions(+), 6 deletions(-)
---
diff --git a/perl-Test-Vars.spec b/perl-Test-Vars.spec
index bfa7af6..74373dc 100644
--- a/perl-Test-Vars.spec
+++ b/perl-Test-Vars.spec
@@ -1,6 +1,6 @@
 Name:  perl-Test-Vars
 Version:   0.005
-Release:   1%{?dist}
+Release:   2%{?dist}
 Summary:   Detects unused variables
 License:   GPL+ or Artistic
 Group: Development/Libraries
@@ -13,25 +13,31 @@ BuildArch:  noarch
 BuildRequires: perl(Module::Build) >= 0.38
 BuildRequires: perl(CPAN::Meta)
 BuildRequires: perl(CPAN::Meta::Prereqs)
+BuildRequires: perl(File::Basename)
+BuildRequires: perl(File::Spec)
+BuildRequires: perl(strict)
+BuildRequires: perl(utf8)
+BuildRequires: perl(warnings)
 # ===
 # Module requirements
 # ===
 BuildRequires: perl >= 4:5.10.0
 BuildRequires: perl(B)
 BuildRequires: perl(constant)
+BuildRequires: perl(ExtUtils::Manifest)
 BuildRequires: perl(parent)
-BuildRequires: perl(Test::Builder)
+BuildRequires: perl(Symbol)
 BuildRequires: perl(Test::Builder::Module)
-BuildRequires: perl(Test::Builder::Tester)
 # ===
 # Test suite requirements
 # ===
-BuildRequires: perl(Test::More)
+BuildRequires: perl(Test::Builder::Tester)
+BuildRequires: perl(Test::More) >= 0.88
 # ===
 # Author/Release test requirements
 # ===
-BuildRequires: perl(Test::Pod::Coverage)
-BuildRequires: perl(Test::Pod)
+BuildRequires: perl(Test::Pod::Coverage) >= 1.04
+BuildRequires: perl(Test::Pod) >= 1.14
 BuildRequires: perl(Test::Synopsis)
 # ===
 # Runtime requirements
@@ -65,6 +71,9 @@ perl Build.PL installdirs=vendor
 %{_mandir}/man3/Test::Vars.3pm*
 
 %changelog
+* Mon Jul 01 2013 Jitka Plesnikova  - 0.005-2
+- Update dependencies
+
 * Fri May 31 2013 Paul Howarth  - 0.005-1
 - Update to 0.005
   - Use skip_all instead of planning 0 tests (#4)
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-de...@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel

Re: Architecture specific header files

[Vít Ondruch]

Dne 28.6.2013 15:04, Jakub Jelinek napsal(a):

On Fri, Jun 28, 2013 at 02:58:12PM +0200, Vít Ondruch wrote:

Dne 25.6.2013 15:41, Vít Ondruch napsal(a):

Is there some common practice, where to place architecture
specific header files? From output of the following command, I
can't see any such place.

gcc doesn't have such location, you'd want a different path
for gcc -m64, different for gcc -m32, different for gcc -mx32, 
The standard way is to add a wrapper header and include your arch specific
header based on compiler predefined macros.  Say something like:
# ifdef __i386__
#  include 
# elif defined(__ILP32__)
#  include 
# else
#  include 
# endif
or, if possible, avoid arch specific headers altogether.

Jakub


BTW it seems that Debian already does this, although in completely 
different scale: http://wiki.debian.org/Multiarch/TheCaseForMultiarch



Vít
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: More unhelpful update descriptions

[Dan Mashal]

On Mon, Jul 1, 2013 at 6:44 AM, Richard W.M. Jones  wrote:
> On Mon, Jul 01, 2013 at 10:45:10AM +0200, Emmanuel Seyman wrote:
>> * Richard W.M. Jones [01/07/2013 09:28] :
>> >
>> > * Instead of making up more rules, make the tooling better so
>> > we don't have to repeat update descriptions in multiple places. *
>>
>> Note that you have to describe your update a grand total of once.
>
> Wrong.  It's tiring to have to repeat this, so I'll just point to the
> last time this came up:
>
> https://lists.fedoraproject.org/pipermail/devel/2013-March/thread.html#179655
>
> Especially:
>
> https://lists.fedoraproject.org/pipermail/devel/2013-March/179783.html

+1
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Packaging Go libraries for Fedora

[Florian Weimer]

On 07/01/2013 03:39 PM, Richard W.M. Jones wrote:

But for libraries that aren't bundled with the Go compiler, it looks
like the Go designers intended you to keep them in your home directory:

http://golang.org/doc/code.html#Organization


It's also expected that you keep around source code and recompile from 
source each time something in the dependency tree changes.  There's no 
ABI stability whatsoever because internal implementation details (struct 
sizes and offsets, say) bubble up due to inlining.



This is of course not so great from a packaging/security/updates
point of view.


Right.


Thoughts on this? (especially from anyone who knows what they're
talking about, which is not necessarily me ...)


I wonder if something like common-lisp-controller is needed.


I have a small cgo library which I'd like to package for Fedora, so
this discussion is not entirely theoretical.


cgo is even more difficult because recompiling during installation is 
probably out of question. 8-(


--
Florian Weimer / Red Hat Product Security Team
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Fedora 19 status is ALIVE, GA on July 02, 2013

[Matthias Clasen]

On Sat, 2013-06-29 at 13:59 -0400, Matthew Miller wrote:
> On Sat, Jun 29, 2013 at 10:05:56AM -0600, Kevin Fenzi wrote:
> > > I like the idea of 19.1 pretty unofficially or untested, which fix
> > > some issues on mac installs. Which is basically someone run pungi
> > > with new boot installer stuff. 
> > We are currently pretty unsetup for any kind of point releases. 
> 
> I think this is an interesting longer-term idea to consider, especially once
> we have the idea of batching non-critical updates in place. That batch makes
> a pretty good starting place for point releases.


We already have a pretty decent tool for tracking what goes into the GA
release:
https://qa.fedoraproject.org/blockerbugs/milestone/19/final/buglist

I have been thinking recently that it is a pity to just turn this off
once the GA comes, and let updates flow in unchecked. The tool could
easily be used to control what goes into a batched, qa-ed f19.1 update.

-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: More unhelpful update descriptions

[Richard W.M. Jones]

On Mon, Jul 01, 2013 at 10:45:10AM +0200, Emmanuel Seyman wrote:
> * Richard W.M. Jones [01/07/2013 09:28] :
> >
> > * Instead of making up more rules, make the tooling better so
> > we don't have to repeat update descriptions in multiple places. *
> 
> Note that you have to describe your update a grand total of once.

Wrong.  It's tiring to have to repeat this, so I'll just point to the
last time this came up:

https://lists.fedoraproject.org/pipermail/devel/2013-March/thread.html#179655

Especially:

https://lists.fedoraproject.org/pipermail/devel/2013-March/179783.html

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
virt-top is 'top' for virtual machines.  Tiny program with many
powerful monitoring features, net stats, disk stats, logging, etc.
http://people.redhat.com/~rjones/virt-top
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Packaging Go libraries for Fedora

[Richard W.M. Jones]

(The same topic came up on this list about a month ago, with no
particular resolution).

Fedora 18+ now has a proper Go compiler, and if you get the
version in updates-testing, it's even a working Go compiler :-)

Go seems to have a "unique" approach to packaging libraries.  It looks
as if everything revolves around there being a Go compiler + lots of
bundled libraries that come with that Go compiler.  On Fedora this
gets installed into %_libdir/golang.

But for libraries that aren't bundled with the Go compiler, it looks
like the Go designers intended you to keep them in your home directory:

http://golang.org/doc/code.html#Organization

This is of course not so great from a packaging/security/updates
point of view.

Now as far as I can tell, we can just ignore the $GOPATH stuff, and
instead drop files into the right places in %_libdir/golang.  It works
in my single, limited experiment, but I've no idea if this is the
Right Thing to do.

I think we should leave the $GOPATH environment variable alone.  If
users want to install things in their home directory too, they can set
up $GOPATH and the directory structure themselves.

Thoughts on this? (especially from anyone who knows what they're
talking about, which is not necessarily me ...)

I have a small cgo library which I'd like to package for Fedora, so
this discussion is not entirely theoretical.

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming blog: http://rwmj.wordpress.com
Fedora now supports 80 OCaml packages (the OPEN alternative to F#)
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

rawhide report: 20130701 changes

[Fedora Rawhide Report]

Compose started at Mon Jul  1 08:15:03 UTC 2013

Broken deps for x86_64
--
[avgtime]
avgtime-0-0.6.git20130201.fc20.x86_64 requires 
libphobos-ldc.so.60()(64bit)
[contour]
contour-0.3-2.fc19.x86_64 requires libsolidcontrolifaces.so.4()(64bit)
contour-0.3-2.fc19.x86_64 requires libsolidcontrol.so.4()(64bit)
[derelict]
derelict-tcod-3-20.20130626gite70c293.fc20.i686 requires tcod
derelict-tcod-3-20.20130626gite70c293.fc20.x86_64 requires tcod
derelict-tcod-devel-3-20.20130626gite70c293.fc20.i686 requires tcod
derelict-tcod-devel-3-20.20130626gite70c293.fc20.x86_64 requires tcod
[ekiga]
ekiga-4.0.1-1.fc19.x86_64 requires libedata-book-1.2.so.17()(64bit)
[evolution-rss]
1:evolution-rss-0.3.93-3.fc20.x86_64 requires libeutil.so()(64bit)
1:evolution-rss-0.3.93-3.fc20.x86_64 requires libeshell.so()(64bit)
[fuse-emulator]
fuse-emulator-1.1.0-1.fc20.x86_64 requires libspectrum.so.9()(64bit)
[fuse-emulator-utils]
fuse-emulator-utils-1.1.0-1.fc20.x86_64 requires 
libspectrum.so.9()(64bit)
[gdb-heap]
gdb-heap-0.5-12.fc19.x86_64 requires glibc(x86-64) = 0:2.17
[gnome-commander]
3:gnome-commander-1.2.8.15-7.fc19.1.x86_64 requires 
libpoppler.so.34()(64bit)
[gnuplot]
gnuplot-4.6.2-2.fc20.x86_64 requires libgd.so.2()(64bit)
gnuplot-minimal-4.6.2-2.fc20.x86_64 requires libgd.so.2()(64bit)
[gooddata-cl]
gooddata-cl-1.2.56-2.fc19.noarch requires gdata-java
[gtkd]
gtkd-2.0.0-29.20120815git9ae9181.fc18.i686 requires libphobos-ldc.so.60
gtkd-2.0.0-29.20120815git9ae9181.fc18.x86_64 requires 
libphobos-ldc.so.60()(64bit)
[jboss-as]
jboss-as-7.1.1-19.fc20.noarch requires cxf-common >= 0:2.6.3
[kawa]
1:kawa-1.11-5.fc19.x86_64 requires servlet25
[koji]
koji-vm-1.8.0-1.fc20.noarch requires python-virtinst
[kyua-cli]
kyua-cli-0.5-3.fc19.x86_64 requires liblutok.so.0()(64bit)
kyua-cli-tests-0.5-3.fc19.x86_64 requires liblutok.so.0()(64bit)
[lancet]
lancet-1.0.1-6.fc19.noarch requires ant-nodeps >= 0:1.7.1
[openbox]
gdm-control-3.5.0-11.20121001git782b28.fc19.x86_64 requires gnome-panel
gnome-panel-control-3.5.0-11.20121001git782b28.fc19.x86_64 requires 
gnome-panel
[openlierox]
openlierox-0.59-0.11.beta10.fc20.x86_64 requires libgd.so.2()(64bit)
[ovirt-engine]
ovirt-engine-notification-service-3.1.0-1.fc19.noarch requires 
classpathx-mail
[ovirt-guest-agent]
ovirt-guest-agent-gdm-plugin-1.0.6-6.fc19.x86_64 requires 
libgdmsimplegreeter.so.1()(64bit)
[oyranos]
oyranos-libs-0.4.0-7.fc19.i686 requires libraw.so.5
oyranos-libs-0.4.0-7.fc19.x86_64 requires libraw.so.5()(64bit)
[perl-Bio-ASN1-EntrezGene]
perl-Bio-ASN1-EntrezGene-1.091-17.fc19.noarch requires 
perl(Bio::Index::AbstractSeq)
[perl-Bio-SamTools]
perl-Bio-SamTools-1.35-2.fc19.x86_64 requires 
perl(Bio::SeqFeature::Lite)
perl-Bio-SamTools-1.35-2.fc19.x86_64 requires perl(Bio::PrimarySeq)
[perl-PDL]
perl-PDL-2.4.10-6.fc19.x86_64 requires libgd.so.2()(64bit)
[python-TraitsBackendQt]
python-TraitsBackendQt-3.5.0-5.fc19.noarch requires python-TraitsGUI
[rubygem-openshift-origin-common]
rubygem-openshift-origin-common-1.8.10-1.fc20.noarch requires 
rubygem(safe_yaml)
[rubygem-openshift-origin-node]
rubygem-openshift-origin-node-1.9.15-1.fc20.noarch requires 
rubygem(safe_yaml)
rubygem-openshift-origin-node-1.9.15-1.fc20.noarch requires 
openshift-origin-node-proxy
[rubygem-qpid]
rubygem-qpid-0.16.0-14.fc20.x86_64 requires libqpidtypes.so.1()(64bit)
rubygem-qpid-0.16.0-14.fc20.x86_64 requires 
libqpidmessaging.so.3()(64bit)
rubygem-qpid-0.16.0-14.fc20.x86_64 requires libqpidcommon.so.5()(64bit)
rubygem-qpid-0.16.0-14.fc20.x86_64 requires libqpidclient.so.5()(64bit)
[sagemath]
sagemath-core-5.9-5.fc20.i686 requires libgd.so.2
sagemath-core-5.9-5.fc20.x86_64 requires libgd.so.2()(64bit)
[scala]
scala-2.9.2-2.fc19.noarch requires osgi(org.scala-ide.scala.library)
[spacewalk-web]
spacewalk-dobby-1.9.22-2.fc19.noarch requires perl(Spacewalk::Setup)
[spring]
spring-94.1-1.fc20.x86_64 requires libassimp.so.2()(64bit)
[sumwars]
sumwars-0.5.6-12.fc20.x86_64 requires libenet-1.3.7.so()(64bit)
[tango]
tango-2-12.20120821git7b92443.fc19.i686 requires libphobos-ldc.so.60
tango-2-12.20120821git7b92443.fc19.x86_64 requires 
libphobos-ldc.so.60()(64bit)
[vfrnav]
vfrnav-20130510-1.fc20.x86_64 requires libpolyclipping.so.8()(64bit)
vfrnav-utils-20130510-1.fc20.x86_64 requires 
libpolyclipping.so.8()(64bit)
[zarafa]
libmapi-7.0.13-1.fc19.i686 requires libicalss.so.0
libmapi-7.0.13-1.fc19.i686 requires libical.so.0
libmapi-7.0.13-1.fc19.x86_64 requires libicalss.so.0()(64bit)
libmapi-7.0.13-1.fc1

Re: Heads up: Upcoming python-pillow 2.2 breaks "import _imaging" -> should be python-pillow 2.1, not 2.2

[Sandro Mani]

Slight confusion on my part, the new version is python-pillow 2.1, not 2.2.

Sandro
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: How noarch FFI wrapper package can dependes on .so file

[T.C. Hollingsworth]

On Jul 1, 2013 2:43 AM, "Vít Ondruch"  wrote:
> Hi,
>
> I recently did review or rubygem-gssapi [1], which is FFI wrapper above
libgssapi_krb5.so.2.
>
> Now, we'd like to specify dependency directly on this library, but since
rubygem-gssapi is noarch, it seems there is no way how to specify this
dependency better then "Requires: krb5-libs", unless the rubygem-gssapi
would be arch dependent. Or is there any better way? Any suggestion?

I ended up doing the arch-dependent thing for python-webm (which wraps
libwebp with ctypes) because there didn't seem to be a better solution.

It hardcodes the .so file though, so it _really_ needed a soname-based
dependency; a simple "Requires: libwebp" wouldn't have been good enough.

I'd too would like to know if there's a better way... :-/

-T.C.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

How noarch FFI wrapper package can dependes on .so file

[Vít Ondruch]

Hi,

I recently did review or rubygem-gssapi [1], which is FFI wrapper above 
libgssapi_krb5.so.2.


Now, we'd like to specify dependency directly on this library, but since 
rubygem-gssapi is noarch, it seems there is no way how to specify this 
dependency better then "Requires: krb5-libs", unless the rubygem-gssapi 
would be arch dependent. Or is there any better way? Any suggestion?


Thanks

Vít



[1] https://bugzilla.redhat.com/show_bug.cgi?id=975339
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Compile-time shared library name mismatching base name (SDL)

[Petr Pisar]

Hello list,

I got an interresting report regarging SDL library file names
.

If you install SDL and SDL-devel, you will get these files:

root@fedora-20:~ # ls -o /usr/lib64/libSDL*
lrwxrwxrwx. 1 root 20 Jul  1 10:43 /usr/lib64/libSDL-1.2.so.0 -> 
libSDL-1.2.so.0.11.4
-rwxr-xr-x. 1 root 444176 Jun 19 12:58 /usr/lib64/libSDL-1.2.so.0.11.4
lrwxrwxrwx. 1 root 20 Jul  1 10:55 /usr/lib64/libSDL.so -> 
libSDL-1.2.so.0.11.4
root@fedora-20:~ # scanelf --soname /usr/lib64/libSDL*
 TYPE   SONAME FILE 
ET_DYN libSDL-1.2.so.0 /usr/lib64/libSDL-1.2.so.0 
ET_DYN libSDL-1.2.so.0 /usr/lib64/libSDL-1.2.so.0.11.4 
ET_DYN libSDL-1.2.so.0 /usr/lib64/libSDL.so 

You can see the symlink for compile-time linking is called libSDL.so
despite the SONAME is libsSDL-1.2.so.0, so the expected file name should
be libSDL-1.2.so.

And that's probably the reason why ldconfig gets confused and wants to
change libSDL-1.2.so.0 symlink from libSDL-1.2.so.0.11.4 to libSDL.so:

root@fedora-20:~ # ldconfig -v |grep SDL
ldconfig: Can't stat /libx32: No such file or directory
ldconfig: Path `/usr/lib' given more than once
ldconfig: Path `/usr/lib64' given more than once
ldconfig: Can't stat /usr/libx32: No such file or directory
libSDL-1.2.so.0 -> libSDL.so

If I remove the libSDL.so, then ldconfig leaves this silly idea and
returns to expected value (libSDL-1.2.so.0 -> libSDL-1.2.so.0.11.4).

Is this is a bug or a feature of ldconfig?

Is the installed libSDL.so symlink a mistage in the SDL-devel package?

Is renaming libSDL.so to libSDL-1.2.so wise? The libSDL.so is used in
upstream and other distributions.

Is adding the libSDL-1.2.so symlink (and preserving libSDL.so) for
backward compatibility wise?

-- Petr

-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: More unhelpful update descriptions

[Emmanuel Seyman]

* Richard W.M. Jones [01/07/2013 09:28] :
>
> * Instead of making up more rules, make the tooling better so
> we don't have to repeat update descriptions in multiple places. *

Note that you have to describe your update a grand total of once.

Emmanuel
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: More unhelpful update descriptions

[Richard W.M. Jones]

Since this topic comes up every few months, and no one's pointed
out the obvious answer yet, I'll say it:

* Instead of making up more rules, make the tooling better so
we don't have to repeat update descriptions in multiple places. *

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
virt-top is 'top' for virtual machines.  Tiny program with many
powerful monitoring features, net stats, disk stats, logging, etc.
http://people.redhat.com/~rjones/virt-top
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Heads-up: perl-BSD-Resource license change

[Petr Šabata]

All BSD::Resource users,

Please note that according to upstream, the license of this
package isn't actually 'same as Perl' (GPL+ or Artistic) but
rather 'LGPLv2 or Artistic 2.0'.

Regards,
Petr


pgpdG2G6JRAQh.pgp
Description: PGP signature
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

[Test-Announce] 2013-07-01 @ 15:00 UTC - Fedora QA Meeting

[Adam Williamson]

# Fedora Quality Assurance Meeting
# Date: 2013-07-01
# Time: 15:00 UTC
(https://fedoraproject.org/wiki/Infrastructure/UTCHowto)
# Location: #fedora-meeting on irc.freenode.net

Greetings testers!

It's meeting time again today/tomorrow! We finished up Fedora 19, and we 
haven't met for a while, so let's get together to look back on F19 and 
forward to F20.


This is a reminder of the upcoming QA meeting. Please add any topic
suggestions to the meeting wiki page:
https://fedoraproject.org/wiki/QA/Meetings/20130701
The current proposed agenda is included below.

== Proposed Agenda Topics ==
1. Fedora 19 retrospective and wrap-up
2. Fedora 20 planning
3. Taskbot
4. Test Days
5. Open floor
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora
http://www.happyassassin.net
___
test-announce mailing list
test-annou...@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/test-announce
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel