On Mon, Jan 23, 2017 at 6:17 PM, Theodore Papadopoulo
wrote:
> Then if there is a agreement, I'll need some advice on how to proceed
> next...
That depends on whether you're already a member of the packagers group.
If you are, go here:
https://fedoraproject.org/wiki/New_package_process_for_existi
On 01/23/2017 04:51 PM, Alexander Ploumistos wrote:
> It might feel like I'm splitting hairs, but please bear with me.
No, no it's me that have not understood your previous request. I had not
realized how much the guidelines might have changed these last years,
and I learnt a lot (even though I mi
It might feel like I'm splitting hairs, but please bear with me.
Modify your changelog heading to one of the following formats
* Sun Jan 22 2017 Theodore Papadopoulo - 4.3.1-1
* Sun Jan 22 2017 Theodore Papadopoulo - 4.3.1-1
( http://fedoraproject.org/wiki/Packaging:Guidelines#Changelogs )
and
On 01/22/2017 08:11 PM, Alexander Ploumistos wrote:
> Almost there, still some light reading ahead:
> http://fedoraproject.org/wiki/Packaging:Guidelines#Changelogs
>
> You need to amend your changelog entry heading to match one of the
> styles mentioned there, the most common being
>
> * Sun Jan
Almost there, still some light reading ahead:
http://fedoraproject.org/wiki/Packaging:Guidelines#Changelogs
You need to amend your changelog entry heading to match one of the
styles mentioned there, the most common being
* Sun Jan 22 2017 Theodore.Papadopoulo - 4.3.1-1
As Michael Schwendt point
OK. Thank's for the quick reply. Here is the updated spec.
On 01/22/2017 04:01 PM, Alexander Ploumistos wrote:
> On Sun, Jan 22, 2017 at 4:31 PM, Theodore Papadopoulo
> wrote:
>> OK, I hope I have taken into acount of all suggestions except one (I
>> found nothing on %licence in %files).
>
> "I
On Sun, Jan 22, 2017 at 4:31 PM, Theodore Papadopoulo
wrote:
> OK, I hope I have taken into acount of all suggestions except one (I
> found nothing on %licence in %files).
"If the source package includes the text of the license(s) in its own
file, then that file, containing the text of the licens
OK, I hope I have taken into acount of all suggestions except one (I
found nothing on %licence in %files). For now I have made the
4.3.1+patch version as the git repo, while it indeed solves the place
where are installed libraries, does not put correct values in
itpp-config and itpp.pc. Beside the
On Fri, Jan 20, 2017 at 12:15:14PM +0200, Alexander Ploumistos wrote:
> On Fri, Jan 20, 2017 at 11:02 AM, Theodore Papadopoulo
> wrote:
> > On 01/20/2017 07:50 AM, Zbigniew Jędrzejewski-Szmek wrote:
> [snip]
> >> Without looking at the repo, it sounds like packaging a git snapshot would
> >> be ea
On Fri, 20 Jan 2017 15:04:56 +0700, Dmitrij S. Kryzhevich wrote:
> Anyway lib_64_ must be handled in another way.
The two new Perl based subst expressions added to %install also are
specific to lib64 build targets and won't be correct where %_libdir expands
to /usr/lib.
> Group: System
On Fri, Jan 20, 2017 at 11:02 AM, Theodore Papadopoulo
wrote:
> On 01/20/2017 07:50 AM, Zbigniew Jędrzejewski-Szmek wrote:
[snip]
>> Without looking at the repo, it sounds like packaging a git snapshot would
>> be easier and better.
>
> Is this allowed ??? I know that in many cases this is discour
On 01/20/2017 07:50 AM, Zbigniew Jędrzejewski-Szmek wrote:
> On Fri, Jan 20, 2017 at 02:32:22AM +0100, Kevin Kofler wrote:
>> Theodore Papadopoulo wrote:
>>> The only problem is that libraries got installed (as usual with cmake) in
>>> /usr/lib and not in /usr/lib64,
>>
>> Only if the CMakeLists.tx
Hi, my two pence.
BuildRoot: %{_tmppath}/%{name}-%{version}-%{release}-root-%(%{__id_u} -n)
Not required.
%cmake -DBLA_VENDOR=ATLAS -DCMAKE_BUILD_TYPE=Release -DCMAKE_INSTALL_PREFIX=/usr
make %{?_smp_mflags}
May be you want to do:
mkdir -p %{_target_platform}
pushd %{_target_platform
On Fri, Jan 20, 2017 at 02:32:22AM +0100, Kevin Kofler wrote:
> Theodore Papadopoulo wrote:
> > The only problem is that libraries got installed (as usual with cmake) in
> > /usr/lib and not in /usr/lib64,
>
> Only if the CMakeLists.txt is broken. It should use LIB_INSTALL_DIR and/or
> LIB_SUFFIX
Theodore Papadopoulo wrote:
> The only problem is that libraries got installed (as usual with cmake) in
> /usr/lib and not in /usr/lib64,
Only if the CMakeLists.txt is broken. It should use LIB_INSTALL_DIR and/or
LIB_SUFFIX. In this case, it was fixed back in 2014 (!):
https://sourceforge.net/p/i
On 01/19/2017 01:38 AM, Michael Schwendt wrote:
>> Provided I get some guidance (or readings, account settings, ...), I
>> ciuld maintain or co-maintain the package if necessary.
> [...]
> https://fedoraproject.org/wiki/Packaging:LicensingGuidelines#License_Text
>
>
>> %{_bindir}/%{name}-config
>
Thank's a lot for the review.
I will analyze all your comments and produce an updated spec file.
I need some time to understand the references you sent.
Thank's again.
Theo.
On 01/19/2017 01:38 AM, Michael Schwendt wrote:
>> Provided I get some guidance (or readings, account sett
> Provided I get some guidance (or readings, account settings, ...), I
> ciuld maintain or co-maintain the package if necessary.
> Release:0%{?dist}
First release of a package usually starts with 1 not 0:
https://fedoraproject.org/wiki/Packaging:Versioning#Release_Tag
> %package devel
>
On 01/18/2017 07:01 PM, Jon Ciesla wrote:
>
> It will need to be re-reviewed, since it's been retired more than two weeks.
Of course...
Theo.
signature.asc
Description: OpenPGP digital signature
___
devel mailing list -- devel@lists.fedorap
On Wed, Jan 18, 2017 at 11:53 AM, Theodore Papadopoulo <
theodore.papadopo...@inria.fr> wrote:
> Hi,
>
> I'd like to unretire itpp(which was retired on 2011-07-25 due to
> constant C++ build problems). It seems that those problems have been
> solved and that as of (at least) itpp-4.3.1, it
20 matches
Mail list logo
