Re: Non-responsive maintainer: huwang?

2019-11-15 Thread Fernando Nasser 
On 2019-11-14 5:03 a.m., Fabio Valentini wrote:
> Hi everybody,

Hi Fabio,

All the maven-*-plugin packages were related to the mvn command we used
to maintain in Fedora to build Maven-based software.
It was a modified maven that would use RPMs to provide the dependent
artifacts.  We initially called it 'mvnjpp' to distinguish from an
unaltered 'mvn' command.

I am not sure if anyone is maintaining maven if Fedora now.  If there is
someone then they should inherit everything with maven-*-plugin name. 
If not, well, lets retire all of these.

As for guava, it would be important to determine which other of our
packages depend on it.  It was probably with Hui for being used by maven
or some of its plugins, but we should make sure there aren't any other
users of that package.  Woul'd you be able to compute that list?

Cheers,
Fernando


>
> Following the policy for non-responsive package maintainers [0], I'm
> asking here if anybody knows how to contact huwang. Hui, if you're
> still interested in maintaining your packages, please respond.
>
> Some of their packages are broken on fedora 31+ due to retired Java
> dependencies, and others are getting out of date (see the linked Bug
> List in [1]), which is starting to impact some Stewardship SIG
> packages as well.
>
> Other packages (such as maven-changelog-plugin, maven-ejb-plugin,
> maven-project-info-reports-plugin) were already broken and
> unmaintained for so long they were already cleaned up in the F30FTBFS
> removal and retired for f31+, without getting any attention from the
> maintainer.
>
> - Looking at src.fedoraproject.org, there's next to no activity in the
> past year.
>
> https://src.fedoraproject.org/user/huwang
>
> - Bodhi doesn't even know huwang exists:
>
> https://bodhi.fedoraproject.org/users/huwang
>
> - all BugZ assigned to them are still "NEW" or were closed by either
> FTBFS cleanup or fedora EOL since 2017 ...
>
> Thanks,
> Fabio
>
> [0]: 
> https://docs.fedoraproject.org/en-US/fesco/Policy_for_nonresponsive_package_maintainers/
> [1]: https://bugzilla.redhat.com/show_bug.cgi?id=1772380
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: 
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Un-orphaned NodeJS packages upgrades in rawhide

2019-04-29 Thread Fernando Nasser 
On 2019-04-29 10:31 a.m., Tom Hughes wrote:
> On 29/04/2019 15:21, Jan Staněk wrote:
>
>> Only other option I can think of is going the Rust route (packages only
>> in rawhide, anything depending on them must be a module), which I'm not
>> a fan of.
>
> Module don't work for Node.js though.
>
> They work for rust and go because of static linking, so different
> packages can pull in the library versions (from parallel available
> modules) at build time and then those libraries are statically
> linked into the resulting program.
>
> Node.js is totally different though - there the node modules are
> needed at run time by the installed packages not just at build time
> so you would need parallel installability not just availability.


Right.  For major versions the only way is to resort to the good olde
versioned packages.

nodejs-xxx  for the latest
and nodejs-xxxN  for the legacy one needed

In the case of node I wonder if all packages should not be versioned
with the major version anyway.

Besides that, we'd have to relax dependencies with '^' around.  But to
do that we'd need to have some basic tests for the modules we meddle
with the dependencies.

Fernando

>
> Tom
>
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: RPM spec style

2018-05-11 Thread Fernando Nasser 

On 2018-05-11 10:33 AM, Merlin Mathesius wrote:

Greetings.

I'd like a quick opinion on spec file style...

Nearly all specs I've seen dealing with subpackages group all the
%package/%description stanzas near the beginning, and put all the %files
stanzas near the the end. (Example 1 below)

However, are there any reasons, stylistic or otherwise, that the %files
stanzas shouldn't be grouped with their corresponding
%package/%description stanzas? (Example 2 below) Especially when there
are a large number of subpackages...


If you think of it, the usual order of spec file sections reflects the 
timing where they are used.


So you have the tags at the top, which are used to set things up, then 
preparation, building, installation and the list of files which is used 
firstly to verify if what was produced matches what you expect.


Granted, scriptlets like %pre %post etc. are grouped together so a 
general vision of hooks is given.


You could say the same about packages and their Descriptions being 
together.  It gives a whole vision of what this SRPM will produce.




Regards,
Fernando





Thanks.

Regards,

Merlin



___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: question about Obsoletes/Provides

2018-03-08 Thread Fernando Nasser 

On 2018-03-08 5:58 AM, Daniel P. Berrangé wrote:

On Thu, Mar 08, 2018 at 11:23:45AM +0100, Jos de Kloe wrote:

I have a question about an open review request on the eccodes package,
see: https://bugzilla.redhat.com/show_bug.cgi?id=1508950

Eccodes will replace grib_api for which downstream will stop support at
the end of this year.
Therefore the first draft spec file had Obsoletes/Provides entries to
make clear that eccodes will replace it.

Then I received a comment that this was maybe not correct, since the
replacement package may not be compatible enough so I disabled these
keywords.

Main differences are:
* grib_api provides a fortran77 library, which is absent in eccodes
* library and pkg-config files changed name

on the other hand, they both provide a fully compatible api version of
the c and fortran90 library.

On top of that, they both provide a collection of tools in /usr/bin with
identical names which gives a conflict in ownership if both packages
would be present at the same time.

looking at
https://fedoraproject.org/wiki/Packaging:Guidelines#Renaming.2FReplacing_Existing_Packages
is this a case where only an Obsoletes should be used?

Yes, IMHO this is a case where just using 'Obsoletes' on its own to get
the upgrade installed is reasonable. Any downstream RPM that depends on
the original package may well need adapting due to changed library name,
so claiming 'Provides' is not appropriate.


Regards,
Daniel



Just adding a reminder:  make sure your Obsoletes is versioned.


Regards,

Fernando
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: BSD 2-Clause license

2018-02-21 Thread Fernando Nasser 

On 2018-02-19 11:33 AM, Daniel P. Berrangé wrote:

On Mon, Feb 19, 2018 at 11:22:56AM -0500, Fernando Nasser wrote:

Hi,


Would it be possible to add:

BSD 2-clause

to our table of valid licenses?

Which table are you referring to ?

The main list of licenses in the following page already includes it

   https://fedoraproject.org/wiki/Licensing:Main

in the table entry  "BSD License (two clause)"


Yes, thanks.  Someone else also pointed that out to me.

I was looking for a more specific abbreviation, as there is a variety of 
BSD licenses with different acceptance status.


(moved discussion to the Fedora legal list).


Regards,
Fernando




Regards,
Daniel


___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

BSD 2-Clause license

2018-02-19 Thread Fernando Nasser 

Hi,


Would it be possible to add:

BSD 2-clause

to our table of valid licenses?


It is already in https://spdx.org/licenses/

BSD 2-Clause "Simplified" License 
 	|BSD-2-Clause|


and is OSI-approved.

For reference: https://spdx.org/licenses/BSD-2-Clause.html#licenseText


Thanks in advance!


P.S.: It is used by something called 'fluentd'.

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Package Question

2018-01-08 Thread Fernando Nasser 

On 2018-01-08 3:07 PM, Nico Kadel-Garcia wrote:

On Mon, Jan 8, 2018 at 2:32 PM, Fernando Nasser <fnas...@redhat.com> wrote:

On 2018-01-08 12:21 PM, Steve Dickson wrote:

Hello,

Is it a problem for a package to pull from two different
upstream tar balls? Basically have

Source0: http://server.com/package1/package1.tar
Source1: http://server.com/package2/package2.tar

It happens all the time. Subversion used to do this a lot, when the
requirement for the "swig" library was more recent than what was in
Fedora. It also happens quite a lot for RHEL and EPEL packages, where
the necessary versions of various libraries may conflict with the
stable, standard library used by other tools.


Hum... not sure if this was good form.  An important security fix may 
fail to be applied to this "hidden" library for one thing.


This is supposed to be handled by having a versioned package for the 
alternative library version that could then be used by this package (as 
opposed as the default Fedora version of it).


This has similar problems as using the Maven shadow plugin in Fedora 
Java builds (which is AFAIK also discouraged).


--Fernando



___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org


___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Package Question

2018-01-08 Thread Fernando Nasser 

On 2018-01-08 12:21 PM, Steve Dickson wrote:

Hello,

Is it a problem for a package to pull from two different
upstream tar balls? Basically have

Source0: http://server.com/package1/package1.tar
Source1: http://server.com/package2/package2.tar


Important questions:

1) Are the lifecycles the same?

2) Can one be built independently of the other?

3) Are the licenses the same?  Is the IP owner the same?


I am just wondering if these cannot be split into two packages, built 
one after the other.



Maybe it is necessary to look into the specifics of the case, instead of 
trying to reason over a generic case.


What are you trying to package exactly?


Regards,
Fernando




Then I would, by hand, untar Source1 into Source0 directory.

Before do the work I want to make sure I'm not
breaking violating any package rules. I did look
around and didn't see anything addressing this.

If this is kosher, are there any examples of other
packages doing this...

tia,

steved.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org


___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: common location of spec files in upstream sources

2017-10-26 Thread Fernando Nasser 

On 2017-10-26 5:39 PM, William Moreno wrote:


2017-10-26 15:02 GMT-06:00 Mátyás Selmeci >:


Hi,

For upstream projects that provide spec files in their
repositories, do y'all tend to see a common location for the spec
files? Like dist/.spec or rpm/.spec, etc. My
organization is trying to standardize on a location for the
software we maintain, and it would be better to use something that
many in the open source community also use.


Helllo I have not seem many upstream projects shiping rpm files in 
theirs sources, but I have seem  many with a /debian directory with 
all the debian packaging stuff and some others with a /PKGBUILD dwith 
file used for the  Arch Linux´s AUR, since rpm is not only for Fedora 
I think /rpm should be a good place to ship the rpm file.


Or

rpm/SPECS

to match where rpmbuild would look for it

--Fernando






___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org



___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: RFC: retiring yum

2017-09-01 Thread Fernando Nasser 

On 2017-09-01 2:52 PM, Matthew Miller wrote:

On Fri, Sep 01, 2017 at 02:38:59PM -0400, Fernando Nasser wrote:

1) Can we use existing repositories created with yum createrepo with dnf?

Yes.


2) Are "groups" supported?  (E.g.: yum instalgroup xxx)

Yes.

Thanks Matthew.  I guess it will be just access to information via cli 
and api as people have brought up.



Cheers,

Fernando
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: RFC: retiring yum

2017-09-01 Thread Fernando Nasser 

On 2017-09-01 1:01 PM, Igor Gnatenko wrote:

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

So I think F28/F29 would be best time for retiring YUM. Right now DNF
should be already stable and provide same capabilities (or documented
that something will not be supported).

Hopefully infrastructure / rel-eng folks will finally add support for
rich dependencies[0] which would mean that yum will not work in Fedora
anyway, so..

Do you still have some critical missing functionality in DNF? And let
us know reasons why would you like to keep YUM available (hopefully
there are no)!


I should have paid more attention to this, but I still traumatized and 
avoid looking at anything related to yum.


1) Can we use existing repositories created with yum createrepo with dnf?


2) Are "groups" supported?  (E.g.: yum instalgroup xxx)

Thanks,
Fernando


P.S. I didn't wrote any Change Proposal yet, want to get feedback first

[0] https://fedoraproject.org/wiki/Changes/Packaging_Rust_applications_
and_libraries
- -- 
- -Igor Gnatenko

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: BTRFS dropped by RedHat

2017-08-04 Thread Fernando Nasser 

On 2017-08-04 11:12 AM, Przemek Klosowski wrote:


The release notes for RHEL 7.4 announce that RedHat gave up on btrfs:



Is it only RHEL?

What are other distros doing?


https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/7.4_Release_Notes/chap-Red_Hat_Enterprise_Linux-7.4_Release_Notes-Deprecated_Functionality.html

Btrfs has been deprecated

The Btrfs file system has been in Technology Preview state since
the initial release of Red Hat Enterprise Linux 6. Red Hat will
not be moving Btrfs to a fully supported feature and it will be
removed in a future major release of Red Hat Enterprise Linux.
The Btrfs file system did receive numerous updates from the
upstream in Red Hat Enterprise Linux 7.4 and will remain available
in the Red Hat Enterprise Linux 7 series. However, this is the
last planned update to this feature.

I think RH roadmap is to use XFS over LVM.

This is a pity---BTRFS features looked attractive:

- integrated RAID that ties low level (block/stripe) issues with 
high-level objects (files); I thought this is important because with 
brfs filesystem integrity features filesystem-level trouble could be 
tied to low level issues like silent failures on one raid element. 
This is important and unique: I had seen failures of large volumes 
both on proprietary RAID hardware and in software RAID, due to silent 
corruption of one element of the array, that propagated to other 
healthy elements.


- snapshotting/rollbacks that enable recovery system update failures 
and other nice functionality


- scalable support for really large file systems (reasonable fsck 
times, etc)


Are people who care about mass storage issues aware of RedHat's plans 
and are OK with the situation? Are there any other options apart from 
what RedHat is planning?




___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org



___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Unversioned Obsoletes (was Re: Mass issue: /usr/bin/env dependency)

2017-03-31 Thread Fernando Nasser 

On 2017-03-31 4:04 PM, Michael Schwendt wrote:

On Fri, 31 Mar 2017 15:16:22 -0400, Fernando Nasser wrote:


A few issues I remember caused by unversioned Obsoletes (before they
were banished to Hell) were:

- Not being able, ever again, to provide the thing being obsoleted.  And
believe me, things change ;-)

- The Obsoletes affects other channels as well, not only the content of
the channel that contains the package that contains the Obsoletes is
affected.\
If the obsoleted name is needed by something in some other package even
being at a higher version it cannot be installed.

So for a decade or more (I list track, I am here for almost 2 decades),
the Obsoletes always comes with a '=' or a '<='.

RPM itself also blocks a package from being installed, if *any* other
installed packages obsoletes that package name. If non-versioned, you're
doomed and would need to get rid of the Obsoletes tag first.

An overly simplified test-case where the package containing the Obsoletes
tag is replaced directly via rpm -Uvh is not sufficient.


One has to resort to triggers, and even that does not work in all cases.

Wretched thing, unversioned Obsoletes.

Fernando



___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org


___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Unversioned Obsoletes (was Re: Mass issue: /usr/bin/env dependency)

2017-03-31 Thread Fernando Nasser 
A few issues I remember caused by unversioned Obsoletes (before they 
were banished to Hell) were:


- Not being able, ever again, to provide the thing being obsoleted.  And 
believe me, things change ;-)


- The Obsoletes affects other channels as well, not only the content of 
the channel that contains the package that contains the Obsoletes is 
affected.\
If the obsoleted name is needed by something in some other package even 
being at a higher version it cannot be installed.


So for a decade or more (I list track, I am here for almost 2 decades), 
the Obsoletes always comes with a '=' or a '<='.


Regards,
Fernando


On 2017-03-31 3:08 PM, Igor Gnatenko wrote:

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On Fri, 2017-03-31 at 19:41 +0100, Tomasz Kłoczko wrote:

On 31 March 2017 at 17:57, Michael Schwendt 
wrote:


No, it's based on common experience several packagers have made
over a
period of several years. You seem to have missed that period. Non-
versioned
Obsoletes have caused problems before.


OK. Could you please show me example? Best if it will be documented
for
example in bugzilla.
I'm almost sure that it is kind of mistake or results
misinterpretation.

It is yet another possibility tat it may be result of using yum/dnf
which
are working not exactly the same as rpm.

[..]


What will happen if in 2.0 will be "Obsolete: A-static < 2.0-1"
and just
"Obsolete: A-static" when new 3.0 will arrive?

What will happen on upgrade from 1.0 to 2.0 if A-static-1.0 was
installed
before? Of course A-static will be uninstalled.

What will happen on upgrade from 1.0 to 3.0? Because A-3.0 no
longer
carries Obsolete rule -> A and A-static will be upgraded
together.

No. The exact behaviour is implementation dependent. As long as the
Obsoletes tag is seen by the dependency resolver when examining
installed
packages and available packages, the obsolete package is not taken
into
consideration when resolving dependencies. Its EVR is irrelevant
then.
It will not become an update or upgrade. It is obsolete.

Below you added a wall of text once again. Your passion for this
topic
is admirable, but it won't lead to anything, if you refuse to be
much more
short and concise.


I have no idea about what kind scenario you are talking about so I
made my
tests.
As I wrote engineering is about testing so here is my test case:
Four spec files and two scripts.
First one has:

rm -f ~/rpmbuild/RPMS/x86_64/test*
rpmbuild -ba --quiet test-1.0.spec test-2.0.spec test-3.0.spec
sudo rpm -Uvh ~/rpmbuild/RPMS/x86_64/test*1.0*
rpm -qa | grep ^test
sudo rpm -Uvh ~/rpmbuild/RPMS/x86_64/test*2.0*
rpm -qa | grep ^test
sudo rpm -Uvh ~/rpmbuild/RPMS/x86_64/test*3.0*
rpm -qa | grep ^test

Here is my result:

$ sh ./test.sh
rpm: no packages given for erase
Preparing...  ###
##
[100%]
Updating / installing...
1:test-1.0-
1   # [
33%]
2:test-devel-1.0-
1 # [
67%]
3:test-static-1.0-
1#
[100%]
test-1.0-1.x86_64
test-devel-1.0-1.x86_64
test-static-1.0-1.x86_64
Preparing...  ###
##
[100%]
Updating / installing...
1:test-2.0-
1   # [
20%]
2:test-devel-2.0-
1 # [
40%]
Cleaning up / removing...
3:test-static-1.0-
1# [
60%]
4:test-devel-1.0-
1 # [
80%]
5:test-1.0-
1   #
[100%]
test-2.0-1.x86_64
test-devel-2.0-1.x86_64
Preparing...  ###
##
[100%]
Updating / installing...
1:test-3.0-
1   # [
20%]
2:test-devel-3.0-
1 # [
40%]
3:test-static-3.0-
1# [
60%]
Cleaning up / removing...
4:test-devel-2.0-
1 # [
80%]
5:test-2.0-
1   #
[100%]
test-devel-3.0-1.x86_64
test-static-3.0-1.x86_64
test-3.0-1.x86_64

And second test on with test-2.0-ver.spec which has changed:

--- test-2.0.spec 2017-03-31 18:55:05.986642900 +0100
+++ test-2.0-ver.spec 2017-03-31 18:55:52.877882709 +0100
@@ -3,7 +3,7 @@
  Version: 2.0
  Release: 1
  License: Test
-Obsoletes: test-static
+Obsoletes: test-static < 2.0-1

  %description
  Test package.

Result:

$ sh ./test-ver.sh
Preparing...  ###
##
[100%]
Updating / installing...
1:test-1.0-
1   # [
33%]
2:test-devel-1.0-
1

Re: Rotation logs - use or not to use

2017-03-16 Thread Fernando Nasser 

On 2017-03-16 2:04 PM, Samuel Rakitničan wrote:

Cheers all,

I'm trying to do something with a patch in MariaDB, but I need to know
current situation about rotation logs.

*What's the problem:*
Upstream ship rotation log, we drop it out.
This started sometimes between F15 and F16. Mostly because (for what I
read) Fedora didn't like rotation logs, there were issues in them, they
were often broken and so on.

I though logrotate is mandatory?
https://fedoraproject.org/wiki/Packaging:Guidelines#Log_Files


Otherwise inevitably the dist will fill and your server will fail or at 
least you'll lose log entries.

Depending on how the disk is partitioned even prevent using the system.

In addition to rotating the logs it is necessary to set up the log 
cleaning as well.


We used to do this for all servers.

Fernando


___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org


___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: drop obsolete static uid/gid allocations

2017-01-17 Thread Fernando Nasser 

On 2017-01-16 2:03 PM, Richard W.M. Jones wrote:

On Sun, Jan 15, 2017 at 12:13:16AM +, Zbigniew Jędrzejewski-Szmek wrote:

== The following are completely unused?
console, wnn, haldaemon, vcsa, realtime, nocpulse, desktop, jonas,
pvm, xfs


"jonas" is (was?) the userid/group for the OW2 Consortioum Java EE 
Application Server, JOnAS.




I'm going to guess that wnn is related to the Japanese input method of
the same name.  (canna, also a Japanese input method, has its own
static uid & gid registered too).  Both packages run daemons in the
background.

I'm also going to guess that vcsa is something to do with the
/dev/vcs* virtual console devices, although if that's the case then
the group is no longer used.

Rich.


___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: drop obsolete static uid/gid allocations

2017-01-15 Thread Fernando Nasser 

On 2017-01-15 12:54 PM, Zbigniew Jędrzejewski-Szmek wrote:

On Sun, Jan 15, 2017 at 08:13:42AM +0100, Pavel Raiskup wrote:

On Sunday, January 15, 2017 12:30:51 AM CET Nico Kadel-Garcia wrote:

On Sat, Jan 14, 2017 at 7:20 PM, Zbigniew Jędrzejewski-Szmek
 wrote:

On Sun, Jan 15, 2017 at 01:17:52AM +0100, Reindl Harald wrote:


Am 15.01.2017 um 01:13 schrieb Zbigniew Jędrzejewski-Szmek:

== No need for static allocation, afaict
games, man, slocate, squid, named, postgres, mysql, nscd,
rpcuser, rpc, rpm, ntp, mailman, gdm, utempter, apache, smmsp,
tomcat, frontpage, nut, beagleindex, avahi, tcpdmp, privoxy, radvd,
imap, majordomo, polkituser, screen, clamav, saned, mock, ricci, luci

this idea is horrible wenn you maintain many machines over many
years because the 27/27 for mysqld and 48/48 for apache as example
ensures that you can clone/move data between every redhat based
distribution of the last 15 years and you wnat to go that capability
to be gone

How do you "clone/move data"? Normally tar/rsync/scp will use the user
or group name, not the number.

Except when it doesn't. The mysql use on one system may not *exist* at
the time of running rsync or tar, and it certainly does not work wekk
across mounted disk images or NFSv3 and most NFSv4 mounts.

Let's not change static, stable content that there isn't a compelling
reason to change.

Agreed; at least for the databases, please don't drop postgres and mysql,
thank you.


Please keep apache and tomcat as well (same for jboss, which fortunately 
is not in the list).


Thanks!

Fernando




The pattern to take into account might be that "external storage is often
used to store data" of the service.  Without central arbiter (which users
are often a bit to setup for e.g. for "only" database server) it is
non-trivial to keep UIDs/GIDs synced across VM deployments.

Ack.

Zbyszek
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org


___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: rpm: %patch needs --fuzz

2016-05-04 Thread Fernando Nasser 

On 2016-05-04 9:25 AM, Josh Boyer wrote:

On Wed, May 4, 2016 at 9:22 AM, Neal Becker  wrote:

In an rpm .spec I need a patch with more fuzz

%patch macro

doesn't seem to accept --fuzz=xxx

What's a good solution?

Clean the patch up so it applies without fuzz.  That is always the
best solution.

The alternative is to literally call patch(1) in the spec and pass it
whatever flags you need.

Or you could try and push Tom Lane's patch, if not already merged:

https://www.redhat.com/archives/rhl-devel-list/2008-July/msg01655.html


josh
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org


--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: Self-Reintroduction: DJ Delorie

2016-01-28 Thread Fernando Nasser 

DJ is being modest, this is a small sample of his contributions.


On 2016-01-28 2:42 PM, DJ Delorie wrote:

I've been around for a while, but as I'm taking on a new role inside
Red Hat, I'll be showing up in different places here and upstream, so
I figured I'd refresh everyone's memory as well as announce the change :-)

For those who don't know me, I'm the creator of the DJGPP project, a
senior engineer at Red Hat for the last 17 years, and a
maintainer/contributor for many upstream projects, including gcc,
binutils, newlib, and gdb.  I was also active in the Fedora ARM
bootstrap project, and wrote the initial (stage 1-3) bootstrap scripts
for it.  I also do electronics, woodworking, and metalworking as
hobbies, so I tend to show up in lots of forums...

In my new role at Red Hat I'll be focusing more on glibc work, so
expect to see me poking my nose around there too now :-)

DJ Delorie
work: d...@redhat.com
personal: d...@delorie.com
fedoraproject: djdelorie
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: Summary/Minutes from today's FESCo Meeting (2015-10-07)

2015-10-09 Thread Fernando Nasser 

On 2015-10-09 10:02 AM, Ralf Corsepius wrote:

On 10/09/2015 03:51 PM, Matthew Miller wrote:

On Fri, Oct 09, 2015 at 01:50:27PM +0100, Richard W.M. Jones wrote:
This opens the door to all kinds of duplication, waste of disk 
space, waste

of RAM, symbol conflicts and unfixed security issues!

I agree - the new wording does appear to give in to poor programming
practices.


Do you have suggestions for improvements?

Do I have to pronouce the obivious? FESCO to revert their faulty 
decision.



+1
--
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: Your Outstanding Requests on closed bugs

2015-03-30 Thread Fernando Nasser 

On 2015-03-30 9:55 AM, Paul Wouters wrote:

On Mon, 30 Mar 2015, Michael Cronenworth wrote:


On 03/30/2015 08:39 AM, Paul Wouters wrote:


There are currently no flags set at all.


Check the flags on the attachment itself (your second link).


Ohh. there is shows up. How odd. Thanks. Now at least I know how
to get rid of it, although I think it should clear out all requests
for closed bugs.

+1


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: [fedora-java] Headless JRE in Fedora

2013-10-24 Thread Fernando Nasser 
Also, will this change be ackported into the Java packages of RHEL_5 and RHEL-6?

Our products use only one spec file, we'll have to add lots of %if osversion 
in our spec files (and we have 300+ of them).


- Original Message -
 From: Stanislav Ochotnicky sochotni...@redhat.com
 To: Jiri Vanek jva...@redhat.com, devel@lists.fedoraproject.org
 Cc: java-de...@lists.fedoraproject.org
 Sent: Thursday, October 24, 2013 5:08:01 AM
 Subject: Re: [fedora-java] Headless JRE in Fedora
 
 Quoting Jiri Vanek (2013-10-21 18:45:46)
  Hi all!
  
  With
  https://admin.fedoraproject.org/updates/java-1.7.0-openjdk-1.7.0.60-2.4.3.0.fc20
  beeing stable,
  would like to make this more visible:
  
  The jdk in Fedora, being inspired in Debian, now supports headless
  version. During the life of F20
  (as in f21 all expected packages should be correctly headless)i
  would like to recommend all java
  packages maintainers, who do not need audio, or X or whatever (this
  is still on QA on our side)
  to swap theirs dependence to java-headless.
  Alos, maintainers, please do not forget, that when you update your
  package, also packages you are
  depending on must become just hedless dependent. Anyway - all
  libraries should be jut java-headless :)
  
  I would like to suggest especially wildFly and tomcat to try to
  migrate asap, as this change was
  designed for them :)
 
 They can't. Several reasons:
 
 * Packaging guidelines clearly state BR/R: java
 * Maven packages have automatically generated requires on java
 (or
   java-devel)
 
 To *really* make use of java-headless few things need to happen:
 * guidelines have to be updated
 * java-packages have to be changed to R: java-headless by default
 * Maven packages are rebuilt
 * packages not built with maven are migrated manually
 * leaf applications make sure they have R: java
 
  Btw - the update above is now somehow stuck - it not in testing,
  nor in updates. Maybe the relengs
  can help.
 
 If you need to get in touch with rel-engs file a ticket[1], don't CC
 their ML or
 it's going to get lost
 
 [1] https://fedorahosted.org/rel-eng/
 
 --
 Stanislav Ochotnicky sochotni...@redhat.com
 Software Engineer - Developer Experience
 
 PGP: 7B087241
 Red Hat Inc.   http://cz.redhat.com
 
 --
 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: Non-responsive maintainer: Anthony Green

2013-08-07 Thread Fernando Nasser 
I will probably meet him personally tomorrow if he is not traveling or on 
vacations.
He is definitively still around, so I will point him to your e-mail.

--Fernando

- Original Message -
 From: Miroslav Lichvar mlich...@redhat.com
 To: devel@lists.fedoraproject.org
 Cc: gr...@redhat.com
 Sent: Wednesday, August 7, 2013 11:19:36 AM
 Subject: Non-responsive maintainer: Anthony Green
 
 I'm having troubles contacting Anthony Green (username green). I'd
 like to comaintain the autogen package. There is a number of bugs
 which should be addressed [1], but my request for commit access is
 unanswered. I didn't get any reply on email or IRC. The last commit
 he
 made in the autogen package is from Nov 25 2011. Has anyone heard
 from
 him recently?
 
 It has not been three weeks since my first attempt to contact him (as
 per the policy) yet, but I noticed there are other unanswered acl
 requests in the libffi and ws-commons-utils packages, so I thought
 others may be waiting for his response too.
 
 [1] https://admin.fedoraproject.org/pkgdb/acls/bugs/autogen
 
 --
 Miroslav Lichvar
 --
 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: Software Management call for RFEs

2013-05-28 Thread Fernando Nasser 
This is basically the major impediment to the uninstall of a product that 
consists of several packages.  Some of these packages may be, at time of 
uninstall, also required by other packages, so the and no other package 
requires them part is essential.

--Fernando

- Original Message -
 From: Ales Kozumplik akozu...@redhat.com
 To: Development discussions related to Fedora 
 devel@lists.fedoraproject.org
 Sent: Tuesday, May 28, 2013 9:27:23 AM
 Subject: Re: Software Management call for RFEs
 
 On 05/28/2013 01:14 PM, Miroslav Suchý wrote:
 dnf autoremove
  should tell me that packages bar and bra were installed as
  dependencies for package, which is no more present on disk (and no
  other
  package requires them) and can be removed.
 
 There's an RFE for this already:
 
 https://bugzilla.redhat.com/show_bug.cgi?id=963345
 
 Ales
 --
 devel mailing list
 devel@lists.fedoraproject.org
 https://admin.fedoraproject.org/mailman/listinfo/devel
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Proposed F19 Feature: Apache OpenOffice

2013-02-01 Thread Fernando Nasser 
What about dependency conflicts?

Which one will determine the version of the dependencies?
I think it will have to be the current existing OO right?

So the new one, if added, must build and run with any shared
dependency at the original one levels.

Makes sense?

--Fernando

- Original Message -
 From: Matej Cepl mc...@redhat.com
 To: devel@lists.fedoraproject.org
 Sent: Friday, February 1, 2013 8:38:59 AM
 Subject: Re: Proposed F19 Feature: Apache OpenOffice
 
 On 2013-01-31, 22:07 GMT, Chris Adams wrote:
  I'm not saying having both is a bad thing, but I would like to
  think
  that there's some thought given to does Fedora gain from having
  both,
  since there is a cost involved.
 
 We don’t (unfortunately?) have policy to stop somebody from packaging
 whatever they want (if it satisfies Fedora packaging policy).
 
 Matěj
 
 --
 devel mailing list
 devel@lists.fedoraproject.org
 https://admin.fedoraproject.org/mailman/listinfo/devel
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: What would it take to make Software Collections work in Fedora?

2012-12-13 Thread Fernando Nasser 
What is the difficult on adding a file to yum.repo.d ?

It is designed for that.  Each initial page for an aditional repo would
have instructions on how to activate it and provide a repo file to copy from.



- Original Message -
 From: Richard W.M. Jones rjo...@redhat.com
 To: Development discussions related to Fedora 
 devel@lists.fedoraproject.org
 Sent: Tuesday, December 11, 2012 4:42:39 PM
 Subject: Re: What would it take to make Software Collections work in Fedora?
 
 On Tue, Dec 11, 2012 at 03:18:42PM -0500, Fernando Nasser wrote:
   From: Richard W.M. Jones rjo...@redhat.com
   So let's say the user has to add the OCaml repo themselves.
That's
   difficult for the user because lots of tools like yum search no
   longer work well.
   
  
  Really?  If I add several yum repos in my tum.repo.d  the yum
  subcommands
  operate over all those repos, son't they?  I am surprised by this
  statement.
 
 Obviously I mean that yum search and many other commands don't work
 until and unless the user knows (how?) what repo to add.  That means
 that you have to add the external repos for the user, or advertise
 them, which are incompatible as I explained.
 
  Did I overlook anything here?
 
 Lots.
 
 Rich.
 
 --
 Richard Jones, Virtualization Group, Red Hat
 http://people.redhat.com/~rjones
 virt-p2v converts physical machines to virtual machines.  Boot with a
 live CD or over the network (PXE) and turn machines into Xen guests.
 http://et.redhat.com/~rjones/virt-p2v
 --
 devel mailing list
 devel@lists.fedoraproject.org
 https://admin.fedoraproject.org/mailman/listinfo/devel
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: For Fedora vs. In Fedora [Was: What would it take to make Software Collections work in Fedora?]

2012-12-13 Thread Fernando Nasser 
Good.  Then we should use this model more frequently.

And in these third party repos, Software Collections could be used
by them to avoid conflicts with base, allow installations of multiple of 
their versions etc.

So, SC _for_ Fedora as opposed as _in_ Fedora.

--Fernando

- Original Message -
 From: Emmanuel Seyman emman...@seyman.fr
 To: devel@lists.fedoraproject.org
 Sent: Tuesday, December 11, 2012 6:23:36 PM
 Subject: Re: For Fedora vs. In Fedora  [Was: What would it take to make   
 Software Collections work in Fedora?]
 
 * Fernando Nasser [11/12/2012 23:05] :
 
  As we have EPEL _for_ RHEL we can have things _for_ Fedora as
  opposed
  to _in_ Fedora.  It is how several VARs do with their software
  _for_
  RHEL in the Red Hat world.
 
 We already have third party repositories for Fedora.
 
 Emmanuel
 --
 devel mailing list
 devel@lists.fedoraproject.org
 https://admin.fedoraproject.org/mailman/listinfo/devel
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: What would it take to make Software Collections work in Fedora?

2012-12-11 Thread Fernando Nasser 
see in line

- Original Message -
 From: Richard W.M. Jones rjo...@redhat.com
 To: Development discussions related to Fedora 
 devel@lists.fedoraproject.org
 Sent: Tuesday, December 11, 2012 2:33:13 PM
 Subject: Re: What would it take to make Software Collections work in Fedora?
 
 On Tue, Dec 11, 2012 at 01:02:41PM -0500, Jon Masters wrote:
  I'd love LSB to matter more. But I didn't raise that can of worms
  intentionally :) To drill down to a single point though, as I said
  above, I don't want the distro to ship every piece of software I
  might
  use. Today, there is too much of a focus on doing it that way where
  I
  think there would be more value (to those who use third party
  software
  or who are pondering downstream consumers of Fedora also) in having
  a
  smaller core and treating everything that comes on top equally.
 
 What I'm confused about is how this would work in terms of Fedora
 policy (not in terms of the software).
 
 Let's say that we decided that OCaml was non-core.  It would be in a
 collection, and there'd be an OCaml repo, OCaml maintainer team,
 OCaml
 packaging policy and so on.
 
 Should Fedora add this repo automatically to make it easier to pull
 in
 packages?  If it does that, then OCaml is really part of Fedora as
 far
 as I can see, pretty much the same as now but a bit more awkward.
 

I don't think we can legally add it.  It must be added by the user
so those OCaml people go to jail, not us ;-)


 So let's say the user has to add the OCaml repo themselves.  That's
 difficult for the user because lots of tools like yum search no
 longer work well.
 

Really?  If I add several yum repos in my tum.repo.d  the yum subcommands
operate over all those repos, son't they?  I am surprised by this statement.


 What happens if the OCaml team goes rogue and starts adding
 non-free
 packages? 

Their repo, their problem.

 Could Fedora be accused of contributory infringement for
 even pointing to the location of this repo?  Again, if Fedora accepts
 detailed oversight over what goes into these external repos, then
 AFAICS they might as well just be in Fedora in the first place.
 

We should not even host their repo.  Anything that does not undergo 
Fedora's strict review process must be kept segregated IMHO.
disclaimer: IANAL

 What happens if a core program needs an OCaml program to build?  Or
 needs to Require on one?  Or (in Debian terms) could be enhanced by
 one?  I guess this means that everything in Fedora New Core would
 need to be written in C and perhaps Python, and can only depend on a
 handful of features, and that's rather limiting for everyone.
 

There is no problem here.  Whatever we need in core we need to add in 
there and build in there in our own ways and it becomes part of the
core and it is installed in the FHS proper places as usual.  We'll 
have to maintain these pieces (or convince some of the OCaml guys 
to do it under our rules in core).  The OCaml collection
(or collections!!!) will have theor own copy in /opt and out of
our ways.

Did I overlook anything here?



 Rich.
 
 --
 Richard Jones, Virtualization Group, Red Hat
 http://people.redhat.com/~rjones
 virt-p2v converts physical machines to virtual machines.  Boot with a
 live CD or over the network (PXE) and turn machines into Xen guests.
 http://et.redhat.com/~rjones/virt-p2v
 --
 devel mailing list
 devel@lists.fedoraproject.org
 https://admin.fedoraproject.org/mailman/listinfo/devel
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

For Fedora vs. In Fedora [Was: What would it take to make Software Collections work in Fedora?]

2012-12-11 Thread Fernando Nasser 
Hi all,

As we have EPEL _for_ RHEL we can have things _for_ Fedora as opposed
to _in_ Fedora.  It is how several VARs do with their software _for_
RHEL in the Red Hat world.

Some years ago JPackage.org had a yum repo with JBoss AS (community 
version) that was tailored to be installed in Fedora.  Just add the
(sample provided) repo file in your yu,repo.d and yum insyall it.
It worked very well and it was adjusted not to interfere with the few
java packages that were in Fedora Core (those days).

It is a bit more difficult to avoid trampling the core Java packages 
these days, that is where the Software Collections can help, have
these things _for_ Fedora install without interfering with the base 
stuff that is _in_ Fedora (and perhaps even with some other _for_
Fedora things).

What I am trying to say (besides a pitch for add-on Fedora repos _elsewhere_),
is that Software Collections is for things _for_ Fedora not for 
things _in_ Fedora.

Just my 2c.

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

Re: What would it take to make Software Collections work in Fedora?

2012-12-06 Thread Fernando Nasser 
And _maintain_ them, with all security fixes.

The problem with duplication is above all one of scalability of
maintenance.

- Original Message -
 From: Aleksandar Kurtakov akurt...@redhat.com
 To: Development discussions related to Fedora 
 devel@lists.fedoraproject.org
 Sent: Thursday, December 6, 2012 11:14:01 AM
 Subject: Re: What would it take to make Software Collections work in Fedora?
 
 - Original Message -
  From: Mark Bidewell mbide...@gmail.com
  To: Development discussions related to Fedora
  devel@lists.fedoraproject.org
  Sent: Thursday, December 6, 2012 5:50:03 PM
  Subject: Re: What would it take to make Software Collections work
  in Fedora?
  
  
  On Thu, Dec 6, 2012 at 10:06 AM, Adam Williamson 
  awill...@redhat.com  wrote:
  
  
  
  
  
  On Thu, 2012-12-06 at 15:30 +0100, Nicolas Mailhot wrote:
   IMHO use of software collections is a symptom of a badly run
   organisation
   not devoting enough cycles to maintain the software it uses, and
   hoping
   (as in wishful thinking) no problem will go critical before the
   product
   they built on top of those collections is end-of-lifed
   
   I completely fail to see how entities with that problem will
   manage
   to
   maintain the package number explosion creating software
   collections
   will
   induce.
  
  On the one hand, I agree completely - I think the 'share all
  dependencies dynamically' model that Linux distros have
  traditionally
  embraced is the right one, and that we're a strong vector for
  spreading
  the gospel when it comes to that model, and it'd be a shame to
  compromise that.
  
  On the other hand, we've been proselytizing the Java heretics for
  over a
  decade now, and the Ruby ones for a while, and neither shows any
  signs
  of conversion or just plain going away, so we may have to call it
  an
  ecumenical matter and deal with their models somehow. Sucky as it
  may
  be. I don't know, I'm a bit conflicted.
  
  --
  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
  
  I used to use Fedora as my primary OS (Now I use a Mac). The major
  issue which drove me away and which I believe SC would help to
  solve
  is that with the current dependency model is that it becomes I want
  a new version of Libreoffice so now I have to upgrade my entire
  system from the Kernel on up (and by upgrade I mean clean install)
  to avoid issues. SC would help decouple system and userland apps
  which would do wonders for usability.
 
 So are you saying that you will do the scl enabled builds of
 libraries needed by LibreOffice ?
 
 
 Alexander Kurtakov
 Red Hat Eclipse team
 
  
  
  --
  Mark Bidewell
  http://www.linkedin.com/in/markbidewell
  
  --
  devel mailing list
  devel@lists.fedoraproject.org
  https://admin.fedoraproject.org/mailman/listinfo/devel
 --
 devel mailing list
 devel@lists.fedoraproject.org
 https://admin.fedoraproject.org/mailman/listinfo/devel
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: What would it take to make Software Collections work in Fedora?

2012-12-06 Thread Fernando Nasser 
Note that two versions of a product that is already being maintained anyway
could be a candidate, but of course this is something _for_ the OS, not
part of it  (RHEL, not Fedora in the exemple I have in mind).



- Original Message -
 From: Fernando Nasser fnas...@redhat.com
 To: Development discussions related to Fedora 
 devel@lists.fedoraproject.org
 Sent: Thursday, December 6, 2012 11:44:27 AM
 Subject: Re: What would it take to make Software Collections work in Fedora?
 
 And _maintain_ them, with all security fixes.
 
 The problem with duplication is above all one of scalability of
 maintenance.
 
 - Original Message -
  From: Aleksandar Kurtakov akurt...@redhat.com
  To: Development discussions related to Fedora
  devel@lists.fedoraproject.org
  Sent: Thursday, December 6, 2012 11:14:01 AM
  Subject: Re: What would it take to make Software Collections work
  in Fedora?
  
  - Original Message -
   From: Mark Bidewell mbide...@gmail.com
   To: Development discussions related to Fedora
   devel@lists.fedoraproject.org
   Sent: Thursday, December 6, 2012 5:50:03 PM
   Subject: Re: What would it take to make Software Collections work
   in Fedora?
   
   
   On Thu, Dec 6, 2012 at 10:06 AM, Adam Williamson 
   awill...@redhat.com  wrote:
   
   
   
   
   
   On Thu, 2012-12-06 at 15:30 +0100, Nicolas Mailhot wrote:
IMHO use of software collections is a symptom of a badly run
organisation
not devoting enough cycles to maintain the software it uses,
and
hoping
(as in wishful thinking) no problem will go critical before the
product
they built on top of those collections is end-of-lifed

I completely fail to see how entities with that problem will
manage
to
maintain the package number explosion creating software
collections
will
induce.
   
   On the one hand, I agree completely - I think the 'share all
   dependencies dynamically' model that Linux distros have
   traditionally
   embraced is the right one, and that we're a strong vector for
   spreading
   the gospel when it comes to that model, and it'd be a shame to
   compromise that.
   
   On the other hand, we've been proselytizing the Java heretics for
   over a
   decade now, and the Ruby ones for a while, and neither shows any
   signs
   of conversion or just plain going away, so we may have to call it
   an
   ecumenical matter and deal with their models somehow. Sucky as it
   may
   be. I don't know, I'm a bit conflicted.
   
   --
   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
   
   I used to use Fedora as my primary OS (Now I use a Mac). The
   major
   issue which drove me away and which I believe SC would help to
   solve
   is that with the current dependency model is that it becomes I
   want
   a new version of Libreoffice so now I have to upgrade my entire
   system from the Kernel on up (and by upgrade I mean clean
   install)
   to avoid issues. SC would help decouple system and userland apps
   which would do wonders for usability.
  
  So are you saying that you will do the scl enabled builds of
  libraries needed by LibreOffice ?
  
  
  Alexander Kurtakov
  Red Hat Eclipse team
  
   
   
   --
   Mark Bidewell
   http://www.linkedin.com/in/markbidewell
   
   --
   devel mailing list
   devel@lists.fedoraproject.org
   https://admin.fedoraproject.org/mailman/listinfo/devel
  --
  devel mailing list
  devel@lists.fedoraproject.org
  https://admin.fedoraproject.org/mailman/listinfo/devel
 --
 devel mailing list
 devel@lists.fedoraproject.org
 https://admin.fedoraproject.org/mailman/listinfo/devel
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Yum Package Remove Order

2012-12-03 Thread Fernando Nasser 
Besides a call to /sbin/chkconfig perhaps I see no reason for anything 
to be done in %post, %preun etc.  in a setup like the on you describe.

These scripts are supposed to be used for very simple and very unlikely 
commands like adding a user or a service to boot, they should not install
or remove files (directly) of any kind, there are other sections that 
have the appropriate mechanisms to do that and detect problems at rpmbuild
time instead of when you are installing/uninstalling.

Regards,
Fernando

- Original Message -
 From: Mark Bidewell mbide...@gmail.com
 To: Development discussions related to Fedora 
 devel@lists.fedoraproject.org
 Sent: Saturday, December 1, 2012 8:46:52 PM
 Subject: Re: Yum Package Remove Order
 
 
 
 
 
 
 
 On Fri, Nov 30, 2012 at 10:54 PM, Adam Williamson 
 awill...@redhat.com  wrote:
 
 
 
 On Fri, 2012-11-30 at 17:24 +0100, Nicolas Mailhot wrote:
  Le Ven 30 novembre 2012 15:11, Mark Bidewell a écrit :
   I have been working on packaging software into RPMs for my
   company. These
   RPMs create directories in %post into which dependent RPMs
   install
   components.
  
  You need to create those directories in %install and have your
  package own
  them in %files, and have dependant rpms depend on your package then
  everything will work fine
 
 Or for bonus points, the app itself ought to create the directories
 in
 the first place, if they're associated with the app. Packages should
 only create directories for stuff that's added as part of the
 package,
 not part of the software per se - say, you're including a convenience
 script which is not upstream, or moving the icons around, or
 something.
 --
 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
 Here is the setup we have.
 1) An RPM which creates a raw JBoss install
 2) An RPM which sets up a specialized server config (based on the
 default config from 1) with common configuration
 3) RPMs containing WARs (and configuration).
 
 
 The reason we encounter the CentOS 5 bug is that the when the RPM in
 2 uninstalls, it removes the server config and with it the WARs from
 3. Is there a better way?
 
 
 Thanks
 
 
 --
 Mark Bidewell
 http://www.linkedin.com/in/markbidewell
 
 --
 devel mailing list
 devel@lists.fedoraproject.org
 https://admin.fedoraproject.org/mailman/listinfo/devel
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: replacing folders with symlinks leads to rpm cpio rename errors

2012-09-24 Thread Fernando Nasser 
triggers could be used too  (to rm -fr the directory installed by old versions 
of the package)

Another *be careful* warning for this one too.

- Original Message -
From: Panu Matilainen pmati...@laiskiainen.org
To: devel@lists.fedoraproject.org
Sent: Friday, September 21, 2012 4:17:27 AM
Subject: Re: replacing folders with symlinks leads to rpm cpio rename errors

On 09/21/2012 10:27 AM, Ralf Corsepius wrote:
 On 09/21/2012 09:22 AM, Julian Sikorski wrote:
 W dniu 21.09.2012 08:53, Julian Sikorski pisze:
 Hi list,

 one of the updates I am preparing is supposed to replace some of the
 folders with symlinks. Unfortunately, this leads to rpm cpio: rename
 errors upon an update attempt. Is there a standard way of dealing
 with this?

 Regards,
 Julian

 It seems to have gone through upon the second attempt. Odd.

 Was the directory empty before installing the rpm replacing the
 directory with a symlink?

 I could be wrong, but IIRC, current rpm is only able to handle
 dir-symlink replacers when dirs are empty.

A directory (empty or not) can't be automatically replaced by anything 
else (symlink or otherwise) in the existing rpm versions. If absolutely 
necessary, it can be accomplished by doing the necessary renames and 
symlinks in %pretrans -p lua scriptlet, but that should be only seen 
as the last resort as its not exactly a safe operation.

- Panu -

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

Re: replacing folders with symlinks leads to rpm cpio rename errors

2012-09-24 Thread Fernando Nasser 
It worked because the first (broken) installation at least removed the 
old version with the real directory.

Then on the second time the old version was no longer there, so no 
real directory and then the symlink could be installed.

But this means a manual process:  install once, remove, install again
which is probably not pratical for distribution on RHN.

--Fernando

- Original Message -
From: Julian Sikorski beleg...@gmail.com
To: Development discussions related to Fedora devel@lists.fedoraproject.org
Sent: Friday, September 21, 2012 3:22:12 AM
Subject: Re: replacing folders with symlinks leads to rpm cpio rename errors

W dniu 21.09.2012 08:53, Julian Sikorski pisze:
 Hi list,
 
 one of the updates I am preparing is supposed to replace some of the
 folders with symlinks. Unfortunately, this leads to rpm cpio: rename
 errors upon an update attempt. Is there a standard way of dealing with this?
 
 Regards,
 Julian
 
It seems to have gone through upon the second attempt. Odd.

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

Re: Xerces 3.0.1 is now built - retire Xerces 2.8?

2010-02-05 Thread Fernando Nasser 
Jonathan Robie wrote:
 I have built Xerces 3.0.1 for Rawhide.  Xerces 3.0.1. was released in 
 February, 2009.

 I think it should replace Xerces 2.8, which was released in August, 
 2007. Do any packages require Xerces 2.8? Is there anyone who can not 
 build against the new 3.0.1 packages?

 Jonathan

Can you please call it xerces-j3 please?

It is a really sensitive piece, and we have to install a very specific 
one for the AppServer (jbossas) or regressions are seen in the 
compliance tests.

If you call it xerces-j3 we can install the xerces-j2 in parallel.

P.S.: A bit of history: the '2' in xerces-j2 was added in 2004 so we 
could keep  xerces-j  (1.3.1).  Similar reasons.

--Fernando

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