Re: Need instructions with packaging

2014-05-29 Thread quickbooks office
The comment is from 2007

Ralf Ertzinger 2007-11-28 06:44:41 EST

Apart from the IOS files, the sources contain two binary files
(mips64_microcode, ppc32_microcode) which are somehow incorporated into the
emulator.

I do not know what these files contain or where they come from and what license
they are under.



GNS3 took over development of dynamips. Are the binary files still
there? GNS3 does not provide the IOS images as far as I know.

On Sat, May 3, 2014 at 5:39 PM, Christopher Meng  wrote:
> On Sun, May 4, 2014 at 8:33 AM, Adrian Soliard
>  wrote:
>> Right, that's another dynamips. But, what is the other link I share
>> before? It's also dynamips.
>>
>> What that "CANTFIX" means? Can I get the packaging process of
>> dynamips? And how do I do it?
>
> That means this package has issues which CANNOT be fixed if upstream
> doesn't change.
>
> See comment 6:
>
> https://bugzilla.redhat.com/show_bug.cgi?id=246150#c6
> --
> devel mailing list
> devel@lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/devel
> Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: [ACTION REQUIRED] Retiring packages for Fedora 21

2014-05-29 Thread Jon Ciesla
On Thu, May 29, 2014 at 8:43 AM, Till Maas  wrote:

> Since the mass rebuild will start in a week (2014-06-06) it is a good
> time to start cleaning up Fedora. After the mass rebuild, packages that
> fail to build for two releases will be be added to this list. Since this
> is the first run after adapting the script to pkgdb2, there might be
> some errors here, please report them.
>
> 

Many, many errors.  For one, curl isn't orphaned.  For another, CUnit is
orphaned but has 3 comaintainters, not the huge number reported, unless I'm
misunderstanding.  Though on seconf look it looks like that's caused by
CUnit being required by curl.  So maybe the output needs restructuring.
And one of the CUnit comaintainers needs to take ownership.

-J


-- 
http://cecinestpasunefromage.wordpress.com/

in your fear, seek only peace
in your fear, seek only love

-d. bowie
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: [ACTION REQUIRED] Retiring packages for Fedora 21

2014-05-29 Thread Michael Schwendt
On Thu, 29 May 2014 08:50:47 -0500, Jon Ciesla wrote:

> On Thu, May 29, 2014 at 8:43 AM, Till Maas wrote:
> 
> > Since the mass rebuild will start in a week (2014-06-06) it is a good
> > time to start cleaning up Fedora. After the mass rebuild, packages that
> > fail to build for two releases will be be added to this list. Since this
> > is the first run after adapting the script to pkgdb2, there might be
> > some errors here, please report them.
> >
> > 
> 
> Many, many errors.  For one, curl isn't orphaned. 

The list only says that curl is affected because it depends on CUnit.

> For another, CUnit is
> orphaned but has 3 comaintainters, 

The list says "two".

> not the huge number reported, unless I'm
> misunderstanding.

Likely a misunderstanding. The list at the bottom tells which package
maintainers are affected by _any_ of the orphans, and in order to be
helpful, the list tells which soon to be retired package(s) each maintainer
is affected by.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: [ACTION REQUIRED] Retiring packages for Fedora 21

2014-05-29 Thread Troy Dawson
On 05/29/2014 08:43 AM, Till Maas wrote:
> Since the mass rebuild will start in a week (2014-06-06) it is a good
> time to start cleaning up Fedora. After the mass rebuild, packages that
> fail to build for two releases will be be added to this list. Since this
> is the first run after adapting the script to pkgdb2, there might be
> some errors here, please report them.
> 
> The following packages are orphaned and will be retired when Fedora
> (F21) is branched, unless someone adopts them. If you know for sure that
> the package should be retired, please do so now with a proper reason:
> https://fedoraproject.org/wiki/How_to_remove_a_package_at_end_of_life
> 
...
> openshift-origin-cartridge-abstract   orphan,
>   maxamillion   
> openshift-origin-cartridge-cron-1.4   orphan,
>   maxamillion, tdawson  
> openshift-origin-cartridge-diy-0.1orphan,
>   maxamillion, tdawson  
...

These three packages need to go away, they have been replaced.  Please
retire them with a clear conscious.

openshift-origin-cartridge-cron-1.4 -> openshift-origin-cartridge-cron
openshift-origin-cartridge-diy-0.1 -> openshift-origin-cartridge-diy
openshift-origin-cartridge-abstract -> No longer needed.

I'd followed the procedure for Renaming/Replacing Existing Packages [1]
but I guess your script is just being extra cautious.

Troy Dawson

-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: [ACTION REQUIRED] Retiring packages for Fedora 21

2014-05-29 Thread Jon Ciesla
On Thu, May 29, 2014 at 9:27 AM, Michael Schwendt 
wrote:

> On Thu, 29 May 2014 08:50:47 -0500, Jon Ciesla wrote:
>
> > On Thu, May 29, 2014 at 8:43 AM, Till Maas wrote:
> >
> > > Since the mass rebuild will start in a week (2014-06-06) it is a good
> > > time to start cleaning up Fedora. After the mass rebuild, packages that
> > > fail to build for two releases will be be added to this list. Since
> this
> > > is the first run after adapting the script to pkgdb2, there might be
> > > some errors here, please report them.
> > >
> > > 
> >
> > Many, many errors.  For one, curl isn't orphaned.
>
> The list only says that curl is affected because it depends on CUnit.
>
> > For another, CUnit is
> > orphaned but has 3 comaintainters,
>
> The list says "two".
>
> > not the huge number reported, unless I'm
> > misunderstanding.
>
> Likely a misunderstanding. The list at the bottom tells which package
> maintainers are affected by _any_ of the orphans, and in order to be
> helpful, the list tells which soon to be retired package(s) each maintainer
> is affected by.
>

I thought so.  If someone doesn't step up soon I'll take CUnit.

-J


> --
> devel mailing list
> devel@lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/devel
> Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct




-- 
http://cecinestpasunefromage.wordpress.com/

in your fear, seek only peace
in your fear, seek only love

-d. bowie
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: [ACTION REQUIRED] Retiring packages for Fedora 21

2014-05-29 Thread Paul Howarth

On 29/05/14 15:31, Jon Ciesla wrote:




On Thu, May 29, 2014 at 9:27 AM, Michael Schwendt mailto:mschwe...@gmail.com>> wrote:

On Thu, 29 May 2014 08:50:47 -0500, Jon Ciesla wrote:

 > On Thu, May 29, 2014 at 8:43 AM, Till Maas wrote:
 >
 > > Since the mass rebuild will start in a week (2014-06-06) it is
a good
 > > time to start cleaning up Fedora. After the mass rebuild,
packages that
 > > fail to build for two releases will be be added to this list.
Since this
 > > is the first run after adapting the script to pkgdb2, there
might be
 > > some errors here, please report them.
 > >
 > > 
 >
 > Many, many errors.  For one, curl isn't orphaned.

The list only says that curl is affected because it depends on CUnit.

 > For another, CUnit is
 > orphaned but has 3 comaintainters,

The list says "two".

 > not the huge number reported, unless I'm
 > misunderstanding.

Likely a misunderstanding. The list at the bottom tells which package
maintainers are affected by _any_ of the orphans, and in order to be
helpful, the list tells which soon to be retired package(s) each
maintainer
is affected by.


I thought so.  If someone doesn't step up soon I'll take CUnit.


If you do, it'd be nice if you'd also branch and build it for EPEL-7 
(pretty please).


Paul.

--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: [ACTION REQUIRED] Retiring packages for Fedora 21

2014-05-29 Thread Jon Ciesla
On Thu, May 29, 2014 at 9:42 AM, Paul Howarth  wrote:

> On 29/05/14 15:31, Jon Ciesla wrote:
>
>>
>>
>>
>> On Thu, May 29, 2014 at 9:27 AM, Michael Schwendt > > wrote:
>>
>> On Thu, 29 May 2014 08:50:47 -0500, Jon Ciesla wrote:
>>
>>  > On Thu, May 29, 2014 at 8:43 AM, Till Maas wrote:
>>  >
>>  > > Since the mass rebuild will start in a week (2014-06-06) it is
>> a good
>>  > > time to start cleaning up Fedora. After the mass rebuild,
>> packages that
>>  > > fail to build for two releases will be be added to this list.
>> Since this
>>  > > is the first run after adapting the script to pkgdb2, there
>> might be
>>  > > some errors here, please report them.
>>  > >
>>  > > 
>>  >
>>  > Many, many errors.  For one, curl isn't orphaned.
>>
>> The list only says that curl is affected because it depends on CUnit.
>>
>>  > For another, CUnit is
>>  > orphaned but has 3 comaintainters,
>>
>> The list says "two".
>>
>>  > not the huge number reported, unless I'm
>>  > misunderstanding.
>>
>> Likely a misunderstanding. The list at the bottom tells which package
>> maintainers are affected by _any_ of the orphans, and in order to be
>> helpful, the list tells which soon to be retired package(s) each
>> maintainer
>> is affected by.
>>
>>
>> I thought so.  If someone doesn't step up soon I'll take CUnit.
>>
>
> If you do, it'd be nice if you'd also branch and build it for EPEL-7
> (pretty please).
>
> Taken, branched, and building.

-J


> Paul.
>
> --
> devel mailing list
> devel@lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/devel
> Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct




-- 
http://cecinestpasunefromage.wordpress.com/

in your fear, seek only peace
in your fear, seek only love

-d. bowie
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

CUnit pkgdb bug? / Re: [ACTION REQUIRED] Retiring packages for Fedora 21

2014-05-29 Thread Michael Schwendt
On Thu, 29 May 2014 09:31:52 -0500, Jon Ciesla wrote:

> If someone doesn't step up soon I'll take CUnit.

I visited pkgdb to try taking CUnit, but I can't. Pkgdb presents an empty
"Branch" field and doesn't let me continue. I'll look into reporting that
as a bug first.

:-(
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: CUnit pkgdb bug? / Re: [ACTION REQUIRED] Retiring packages for Fedora 21

2014-05-29 Thread Jon Ciesla
On Thu, May 29, 2014 at 9:57 AM, Michael Schwendt 
wrote:

> On Thu, 29 May 2014 09:31:52 -0500, Jon Ciesla wrote:
>
> > If someone doesn't step up soon I'll take CUnit.
>
> I visited pkgdb to try taking CUnit, but I can't. Pkgdb presents an empty
> "Branch" field and doesn't let me continue. I'll look into reporting that
> as a bug first.
>
> :-(
>

Odd, I took it with no issues.  If you'd like it we can transfer after the
bug is worked out.

-J


> --
> devel mailing list
> devel@lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/devel
> Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct




-- 
http://cecinestpasunefromage.wordpress.com/

in your fear, seek only peace
in your fear, seek only love

-d. bowie
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: CUnit pkgdb bug? / Re: [ACTION REQUIRED] Retiring packages for Fedora 21

2014-05-29 Thread Michael Schwendt
On Thu, 29 May 2014 09:59:00 -0500, Jon Ciesla wrote:

> > I visited pkgdb to try taking CUnit, but I can't. Pkgdb presents an empty
> > "Branch" field and doesn't let me continue. I'll look into reporting that
> > as a bug first.
> >
> > :-(
> >
> 
> Odd, I took it with no issues.  If you'd like it we can transfer after the
> bug is worked out.

Filed #17 in pkgdb2 tracker. Probably just a race-condition because you
took it shortly after I had loaded the pkgdb page to take it.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: update of ipython in rawhide

2014-05-29 Thread Kalev Lember
On 05/23/2014 11:01 PM, Thomas Spura wrote:
> Dear maintainers of dependent packages of ipython,
> 
> I will update python-ipython in rawhide next week on Friday to version 2.1.0.
> This will be shortly before the mass rebuilt on 6/6 [2].

Any chance you could push this now?

The ipython that's currently in rawhide is in a broken state after the
Python 3.4 update and blocking rebuilds for other packages that use ipython.

Thanks,
Kalev

-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: [ACTION REQUIRED] Retiring packages for Fedora 21

2014-05-29 Thread Till Maas
On Thu, May 29, 2014 at 08:50:47AM -0500, Jon Ciesla wrote:

> CUnit being required by curl.  So maybe the output needs restructuring.
> And one of the CUnit comaintainers needs to take ownership.

Do you have a suggestion about how to restructure? It seems to me that
the limits of plaintext emails are reached with all the information that
is include there, but I am interested in new ideas. :-)

Regards
Till
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: [ACTION REQUIRED] Retiring packages for Fedora 21

2014-05-29 Thread Jon Ciesla
On Thu, May 29, 2014 at 11:09 AM, Till Maas  wrote:

> On Thu, May 29, 2014 at 08:50:47AM -0500, Jon Ciesla wrote:
>
> > CUnit being required by curl.  So maybe the output needs restructuring.
> > And one of the CUnit comaintainers needs to take ownership.
>
> Do you have a suggestion about how to restructure? It seems to me that
> the limits of plaintext emails are reached with all the information that
> is include there, but I am interested in new ideas. :-)
>

No, I was just compla^H^H^H^H^H^Hmaking an observation. :)

But I'll think about it.

-J


> Regards
> Till
> --
> devel mailing list
> devel@lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/devel
> Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct




-- 
http://cecinestpasunefromage.wordpress.com/

in your fear, seek only peace
in your fear, seek only love

-d. bowie
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Build lua libraries also for compat-lua?

2014-05-29 Thread Tomasz Torcz
On Tue, May 13, 2014 at 11:17:39AM +0200, Jan Kaluža wrote:
> Hi,
> 
> I'm playing with an idea of building lua libraries against compat-lua to
> allow luajit working with them. My initial motivation for this is that there
> are projects which don't work with Lua-5.2 and developers for various
> reasons don't want to port it to lua-5.2 yet (for example Prosody package).
> 
> I'm OK with creating bugs and patches against some basic lua modules
> (basically the ones I need myself for Prosody :) ), but at first I wanted to
> ask Lua people here what do they think about it?

  Hi,

  Was there any progress with this?  I'd love to see working Prosody package in 
F20.

-- 
Tomasz Torcz   72->|   80->|
xmpp: zdzich...@chrome.pl  72->|   80->|

-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: [ACTION REQUIRED] Retiring packages for Fedora 21

2014-05-29 Thread Richard W.M. Jones
On Thu, May 29, 2014 at 03:43:49PM +0200, Till Maas wrote:
> xorg-x11-drv-cirrus   orphan, airlied, ajax, alexl, 
>   caillon, caolanm, glisse, 
>   hadess, johnp, 
>   mbarnes, rhughes, rstrode, ssp, whot, 
>   xiphmont  

I think this one came up last time we went through this exercise.

The Cirrus Logic CLGD 5446 card is the default one emulated by qemu
(and Xen I think).  It has a number of problems, not least low maximum
resolution, but it's simple and well understood.

Isn't this driver therefore required by this emulated card?  Or does
another driver do the job?

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
Fedora Windows cross-compiler. Compile Windows programs, test, and
build Windows installers. Over 100 libraries supported.
http://fedoraproject.org/wiki/MinGW
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: [ACTION REQUIRED] Retiring packages for Fedora 21

2014-05-29 Thread Dominik 'Rathann' Mierzejewski
Hi Jochen,

On Thursday, 29 May 2014 at 15:43, Till Maas wrote:
> Since the mass rebuild will start in a week (2014-06-06) it is a good
> time to start cleaning up Fedora. After the mass rebuild, packages that
> fail to build for two releases will be be added to this list. Since this
> is the first run after adapting the script to pkgdb2, there might be
> some errors here, please report them.
> 
> The following packages are orphaned and will be retired when Fedora
> (F21) is branched, unless someone adopts them. If you know for sure that
> the package should be retired, please do so now with a proper reason:
> https://fedoraproject.org/wiki/How_to_remove_a_package_at_end_of_life
> 
> According to https://fedoraproject.org/wiki/Schedule branching will
> occur not earlier than 2015-07-08. The packages will be retired shortly 
> before.
> 
>   Package(co)maintainers
> ===
[...]
> cleanfeed orphan 
[...]
> inn   orphan,
>   npajkovs, ovasik, s4504kr 

I noticed inn is orphaned and will be retired if nobody steps up.
I see that you've been taking care of it for quite some time now,
would you like to take over inn officially?

Also, cleanfeed needs a new maintainer, too.

I haven't run a local INN instance for quite a few years now,
but I did it in the past and would take over if absolutely necessery,
if only to ensure it doesn't disappear from Fedora.

Regards,
Dominik
-- 
Fedora http://fedoraproject.org/wiki/User:Rathann
RPMFusion http://rpmfusion.org | MPlayer http://mplayerhq.hu
"Faith manages."
-- Delenn to Lennier in Babylon 5:"Confessions and Lamentations"
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: selinux issue with containers

2014-05-29 Thread Daniel J Walsh

On 05/28/2014 05:26 PM, Zbigniew Jędrzejewski-Szmek wrote:
> On Wed, May 28, 2014 at 01:52:23PM -0400, Daniel J Walsh wrote:
>> On 05/28/2014 01:40 PM, Richard W.M. Jones wrote:
>>> On Wed, May 28, 2014 at 06:32:04PM +0200, Zbigniew Jędrzejewski-Szmek wrote:
 On Wed, May 28, 2014 at 10:41:45AM -0400, Daniel J Walsh wrote:
> Yum -y update your entire computer and yum reinstall
> selinux-policy-targeted  Should fix the problem.
 Nope. No effect afaict. Any pointers how to debug this?
>>> Does it list any AVCs if you run this command shortly after the
>>> failure?
> No. I only have some unrelated SERVICE_START/SERVICE_STOP messages from 
> systemd-tmpfiles.
>
>>> # ausearch -ts recent -m avc
> 
>
>> rpm -q selinux-policy-targeted
> selinux-policy-targeted-3.13.1-55.fc21.noarch
>
> I now tried with a new rawhide VM and I get identical
> results.
>
>> This looks like the old bug we had with a bad selinux policy update.
> Yes.
>
> Zbyszek

-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

fedoras default cflags & clang

2014-05-29 Thread Tim St Clair
I've been seeing this bug crop up in many circles: 
https://bugzilla.redhat.com/show_bug.cgi?id=1099282

Many folks like to use clang as their primary compiler for various reasons, is 
there anyone who knows a workaround or fix?   

-- 
Cheers,
Tim
Freedom, Features, Friends, First -> Fedora
https://fedoraproject.org/wiki/SIGs/bigdata
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: fedoras default cflags & clang

2014-05-29 Thread Richard W.M. Jones
On Thu, May 29, 2014 at 04:28:18PM -0400, Tim St Clair wrote:
> I've been seeing this bug crop up in many circles: 
> https://bugzilla.redhat.com/show_bug.cgi?id=1099282
>
> Many folks like to use clang as their primary compiler for various
> reasons, is there anyone who knows a workaround or fix?

If you're building RPMs locally, you can drop your own definition of
__global_cflags into '~/.rpmmacros':

%__global_cflags-O2 -g ..etc..

If you are building a package that uses an autoconf-generated
configure script, then simply setting CFLAGS before running configure
should be enough, eg:

  CFLAGS="$(
rpm --eval '%{__global_cflags}' |
  sed 's/-fstack-protector-strong//'
  )" \
  ./configure

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
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
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Packaging: bin subfolder

2014-05-29 Thread Sandro Mani

Hi,

I'm working on packaging Salome (The Open Source Integration Platform 
for Numerical Simulation) [1], and the cmake scripts there install tons 
of binaries and python scripts to the /usr/bin/salome folder. Is this 
acceptable?


Thanks,
Sandro


[1] http://www.salome-platform.org/
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Packaging: bin subfolder

2014-05-29 Thread Paulo César Pereira de Andrade
2014-05-29 18:27 GMT-03:00 Sandro Mani :
> Hi,

  Hi,

> I'm working on packaging Salome (The Open Source Integration Platform for
> Numerical Simulation) [1], and the cmake scripts there install tons of

  I packaged and maintained it packaged in Mandriva for a few years.
If I recall correctly, it is (kind of) salome "solution" to avoid name clashes.

> binaries and python scripts to the /usr/bin/salome folder. Is this
> acceptable?

  I believe a symbolic link should be acceptable. Actually creating a subdir
would probably have a lot of opposition, but it should be possible to
reconfigure salome to use %_libexecdir/salome or %_libdir/salome

> Thanks,
> Sandro
>
>
> [1] http://www.salome-platform.org/

Paulo
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Packaging: bin subfolder

2014-05-29 Thread Sandro Mani



binaries and python scripts to the /usr/bin/salome folder. Is this
acceptable?

   I believe a symbolic link should be acceptable. Actually creating a subdir
would probably have a lot of opposition, but it should be possible to
reconfigure salome to use %_libexecdir/salome or %_libdir/salome
Yeah reconfiguring is not an issue, and if the symlink solution is 
accepted I'd be happy. I'd just prefer not to break the install 
hierarchy too much so that various documentation and stuff on the net 
also applies to Fedora as far as possible.



Thanks,
Sandro

--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: [ACTION REQUIRED] Retiring packages for Fedora 21

2014-05-29 Thread Eduardo Mayorga Téllez

Hi,

I'll take ownership of python-ZConfig as I already maintain a few Python 
packages and I'm interested in keeping python-ZODB in the distribution.


Eduardo
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: update of ipython in rawhide

2014-05-29 Thread Thomas Spura
2014-05-29 18:04 GMT+02:00 Kalev Lember :
> On 05/23/2014 11:01 PM, Thomas Spura wrote:
>> Dear maintainers of dependent packages of ipython,
>>
>> I will update python-ipython in rawhide next week on Friday to version 2.1.0.
>> This will be shortly before the mass rebuilt on 6/6 [2].
>
> Any chance you could push this now?
>
> The ipython that's currently in rawhide is in a broken state after the
> Python 3.4 update and blocking rebuilds for other packages that use ipython.

It looks like that is some kind of race condition, when building with
python 3.4, so for now the python3 tests are disabled... :(

The built can be found at:
http://koji.fedoraproject.org/koji/taskinfo?taskID=6909927

Please let me know, if there are any other problems with the new ipython.

Thanks,
Tom
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Correct way to unpush an update?

2014-05-29 Thread Richard Shaw
Ok, so I don't get bit again by bodhi letting me do something I shouldn't...

Do I just unpush the update but NOT delete it?

I have a newpackge update and one of the three packages has a problem so
obviously I don't want to push it to stable. Once I get the email that's
it's been successfully unpushed, so I just create a new update with the two
packages that are fine and a new build of the problem package?

Thanks,
Richard
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Correct way to unpush an update?

2014-05-29 Thread Jon
On Thu, May 29, 2014 at 8:35 PM, Richard Shaw  wrote:
> Ok, so I don't get bit again by bodhi letting me do something I shouldn't...
>
> Do I just unpush the update but NOT delete it?
>
> I have a newpackge update and one of the three packages has a problem so
> obviously I don't want to push it to stable. Once I get the email that's
> it's been successfully unpushed, so I just create a new update with the two
> packages that are fine and a new build of the problem package?
>
> Thanks,
> Richard
>

maybe just untag from whatever tag it's sitting in right now.

-- 

-Jon
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Correct way to unpush an update?

2014-05-29 Thread T.C. Hollingsworth
On Thu, May 29, 2014 at 5:35 PM, Richard Shaw  wrote:
> Ok, so I don't get bit again by bodhi letting me do something I shouldn't...
>
> Do I just unpush the update but NOT delete it?
>
> I have a newpackge update and one of the three packages has a problem so
> obviously I don't want to push it to stable. Once I get the email that's
> it's been successfully unpushed, so I just create a new update with the two
> packages that are fine and a new build of the problem package?

You can just edit the bodhi update and replace the broken build with
the fixed one.  Then bodhi will unpush the bad one and push the good
one at the same time in the next compose, and the other two packages
won't be affected at all.

-T.C.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: F21 System Wide Change: Web Assets

2014-05-29 Thread T.C. Hollingsworth
On Fri, May 16, 2014 at 3:39 AM, Vít Ondruch  wrote:
> Is it true actually? Last time I was checking the Ruby packages contained
> different/modified version of upstream JS files.

AFAICT they're both fine.

rubygem-uglifier includes the main uglify-js via git submodules:
https://github.com/lautis/uglifier/tree/master/vendor

And rubygem-coffee-script-source is just a browser build of
coffee-script.  The main coffee-script package will be providing such
a build soon.

I'll file bugs with concrete patches when everything's ready.

-T.C.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Packaging: bin subfolder

2014-05-29 Thread Toshio Kuratomi
On Thu, May 29, 2014 at 11:56:02PM +0200, Sandro Mani wrote:
> 
> >>binaries and python scripts to the /usr/bin/salome folder. Is this
> >>acceptable?
> >   I believe a symbolic link should be acceptable. Actually creating a subdir
> >would probably have a lot of opposition, but it should be possible to
> >reconfigure salome to use %_libexecdir/salome or %_libdir/salome
> Yeah reconfiguring is not an issue, and if the symlink solution is
> accepted I'd be happy. I'd just prefer not to break the install
> hierarchy too much so that various documentation and stuff on the net
> also applies to Fedora as far as possible.
> 
  Probably %{_libdir}/salome/REAL_FILES  and
%{_bindir}/SYMLINKS_TO_REAL_FILES.  If there is a concern that salome's
files will conflict with other things in %{_bindir} the symlinks probably
need to have a prefix like salome-SYMLINK.

-Toshio


pgpjAguzoXqEg.pgp
Description: PGP signature
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct