systemd dependencies

[Vít Ondruch]

Hi,

Recently I have noticed that systemd package dependency is creeping into
some packages where it is not necessary. subversion [1] or rsync [2] are
good examples. Please consider moving daemon parts into independent
subpackages. When I install rsync/subversion, I am typically interested
just in client side.

Just to be clear, systemd-libs is in minimal build root already, so I am
not complaining about systemd-libs package, but about systemd package.


Thanks,


Vít



[1] https://bugzilla.redhat.com/show_bug.cgi?id=1133786
[2] https://bugzilla.redhat.com/show_bug.cgi?id=1123813
-- 
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: OCaml 4.02.0+rc1 rebuild (was: Re: Contacting the Ocaml maintainers)

[Richard W.M. Jones]

On Mon, Aug 25, 2014 at 01:22:04PM -0600, Jerry James wrote:
> On Sun, Aug 24, 2014 at 9:28 AM, Richard W.M. Jones  wrote:
> > This is complete now.  There were four or five packages which didn't
> > rebuild which I'll look at after the UK public holiday.
> 
> Your rebuild script did coq, flocq, and why3, but not gappalib-coq,
> frama-c, or why.  There are ordering dependencies here, too.

I don't have any control over the build ordering.

The script should build them in BuildRequires order automatically.
However in this case I have blocked frama-c and gappalib-coq because
they didn't build in the previous round, see:

http://git.annexia.org/?p=goals.git;a=blob;f=fedora_ocaml_rebuild.ml;h=c708223078ddba42b6bd854e3d297f1b0f2ebe8b;hb=HEAD#l25

The script also blocks any dependencies recursively.

If they build now, I can unblock them and their dependencies and rerun
the script.

> Also, the ocaml-tplib build is failing because this invocation:
> 
> ocamlbuild -cflag -g -lflag -g -ocamlc ocp-ocamlc.opt -ocamlopt
> ocp-ocamlopt.opt -classic-display -no-links -build-dir _build
> -use-ocamlfind src/tplib.mllib src/numeric.cmi src/semiring.cmi
> src/vector.cmi src/halfspace.cmi src/hypergraph.cmi src/tplib_core.cmi
> src/tplib_abstract.cmi src/numeric_plugins/zarith_plugin.cmxs
> src/bindings/tplib_double_callback.obj.o
> src/bindings/tplib_rational_callback.obj.o src/compute_ext_rays.native
> src/compute_ext_rays_polar.native src/compute_halfspaces.native
> src/compute_tangent_hypergraph.native
> src/compute_minimal_external_representations.native
> src/compute_tropical_complex.native
> 
> prompts ocamlbuild to issue this command:
> 
> ocamlfind ocp-ocamlopt.opt unix.cmxa -I /usr/lib64/ocaml/ocamlbuild
> /usr/lib64/ocaml/ocamlbuild/ocamlbuildlib.cmxa -g -linkpkg
> myocamlbuild.ml /usr/lib64/ocaml/ocamlbuild/ocamlbuild.cmx -o
> myocamlbuild
> 
> but ocamlfind doesn't know anything about an ocp-ocamlopt.opt command:
> 
> Usage: ocamlfind query[-help | other options]  ...
>or: ocamlfind ocamlc   [-help | other options]  ...
>or: ocamlfind ocamlcp  [-help | other options]  ...
>or: ocamlfind ocamlmklib   [-help | other options]  ...
>or: ocamlfind ocamlmktop   [-help | other options]  ...
>or: ocamlfind ocamlopt [-help | other options]  ...
>or: ocamlfind ocamloptp[-help | other options]  ...
>or: ocamlfind ocamldep [-help | other options]  ...
>or: ocamlfind ocamlbrowser [-help | other options]
>or: ocamlfind ocamldoc [-help | other options]  ...
>or: ocamlfind install  [-help | other options]   
> ...
>or: ocamlfind remove   [-help | other options] 
>or: ocamlfind printconf[-help] [variable]
>or: ocamlfind list
>or: ocamlfind pkg/cmd arg ...
> Select toolchain with:
>   ocamlfind -toolchain  
> Abbreviations:
>   e.g. ocamlfind opt instead of ocamlfind ocamlopt
> Command exited with code 2.
> 
> If I build for Fedora 21 instead, that same ocambuild invocation
> results in this command being issued:
> 
> ocamlfind ocamlopt unix.cmxa -I /usr/lib64/ocaml/ocamlbuild
> /usr/lib64/ocaml/ocamlbuild/ocamlbuildlib.cmxa -g -linkpkg
> myocamlbuild.ml /usr/lib64/ocaml/ocamlbuild/ocamlbuild.cmx -o
> myocamlbuild
> 
> which works.  Apparently the meaning of the -ocamlopt option to
> ocamlbuild has changed.  Do you have any suggestions on how to deal
> with the situation?

I'm not very familiar with ocamlbuild.  In fact I didn't and still
don't agree with it on principle.  Guess we need to ask upstream to
fix this.

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: Multiple different licenses for tag in a appdata file

[Richard Hughes]

On 25 August 2014 20:09, Erik Schilling  wrote:
> I am being on rawhide here. Is there anything I am doing wrong?

Rawhide might not be new enough; have you got libappstream-glib >=
0.2.5 installed?

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: systemd dependencies

[Michal Sekletar]

On Tue, Aug 26, 2014 at 09:32:26AM +0200, Vít Ondruch wrote:
> Hi,

Hi Vít,

> 
> Recently I have noticed that systemd package dependency is creeping into
> some packages where it is not necessary. subversion [1] or rsync [2] are
> good examples. Please consider moving daemon parts into independent
> subpackages. When I install rsync/subversion, I am typically interested
> just in client side.

At some point in time (F16 IIRC) we had systemd-units package which contained
/etc/rpm/macros.systemd file. Packagers which followed our guidelines used for
example %{unitdir} macro in %files. Hence they added systemd-units to
BuildRequires.

These days systemd-units no longer exists, macro file moved to systemd rpm and
systemd-units is a provided by systemd rpm. Therefore systemd proper creeping
into buildroots.

> 
> Just to be clear, systemd-libs is in minimal build root already, so I am
> not complaining about systemd-libs package, but about systemd package.
> 
> 
> Thanks,
> 
> 
> Vít

Michal
> 
> 
> 
> [1] https://bugzilla.redhat.com/show_bug.cgi?id=1133786
> [2] https://bugzilla.redhat.com/show_bug.cgi?id=1123813
> -- 
> 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: Circular dependencies in RPM

[Petr Pisar]

On 2014-08-24, Nico Kadel-Garcia  wrote:
> Installation scripting is not the only source of the problem. Perl
> modules have been prone to this.
>
> * Perl module  A requires perl module B.
> * Perl module B requires perl module C.
> * One small script or macro in module C requires one small script from
> module A. It may not even be a critical component of C, and may be
> easily segregated, but suddenly there is a circular dependency.
>
There is no algorithmic difference between Perl packages and any other
packages.

Specifically to Perl, we employ %perl_bootstrap macro which guards the
`not even a critical' dependency which allows us to break the dependency
cycle.

Perl SIG exhibits weekly rebuilds
 which
allow us to watch that all Perl packages are buildable.

> The vortex enters when the author of module B updates to a new
> dependency or build dependency that is not in the current version of
> C, and C introduces a new dependency on A but it's based on an older
> version of A, that has since discarded that macro due to a code
> cleanup. Hilarity ensues.
>
If you need to do such an upgrade, provided you've already deployed the
%perl_bootstrap condition, you just define perl_bootstrap temporarily in
one of the upgraded packages, and after upgrading the connected
component, you remove the macro definition and rebuild the package
again.

> The underlying point is that it's sometimes very helpful to split
> upstream packages to smaller, individual components, precisely to
> segregate these dependencies. It's especially useful with Perl
> modules.

Definitely. Once packageres realize that Perl modules can move beetween
RPM packages freely, once they realize that specifying all direct
dependencies without relying on transitive dependencies is the best
practice and a must for healthy distribution, then splitting packages is
obvious solution.

Although splitting cannot solve all issues, especially if the splitted
modules are really interdependend. Then there is no point in the split.
However that's a upstream issue.

-- Petr

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

ICU upgraded to 53.1 with soname bump

[David Tardon]

Hi all,

ICU has been upgraded to 53.1 in Rawhide. This includes a soname bump,
as usual. I will start rebuilding dependencies when the build gets into
the buildroot.

D.
-- 
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: ca-certificates 2014.2.1 will remove several still valid CA certificates with weak keys

[Vít Ondruch]

Hi Kay,

This update has potential to break RubyGems with error:


$ gem fetch power_assert
ERROR:  Could not find a valid gem 'power_assert' (>= 0), here is why:
  Unable to download data from https://rubygems.org/ -
SSL_connect returned=1 errno=0 state=SSLv3 read server certificate B:
certificate verify failed
(https://s3.amazonaws.com/production.s3.rubygems.org/latest_specs.4.8.gz)


Upstream RubyGems ships the certificates, but on your request, I removed
the bundled certificates [1]. Now, 3 months later are RubyGems broken in
F21+ due to this update. Luckily, I have never backported this commit to
F20, so this particular update is not harmful for stable Fedora release,
but what am I supposed to do with F21+?

I don't feel like contacting Amazon. You claim that nothing should break
and Mozilla contacted everybody, so why not Amazon? Are they so negligible?

Should I follow your advises or follow upstream? Sorry, but this puzzles
me ...



Vít



[1]
http://pkgs.fedoraproject.org/cgit/ruby.git/commit/?id=efdf386e3192775d84b69006d3bc12d5532455d2




Dne 18.8.2014 23:48, Kai Engert napsal(a):
> Hello,
>
> this is a heads-up for an update to the ca-certificates package that
> I've just submitted for updates-testing for Fedora 19 and 20.
>
> The upstream Mozilla CA list maintainers have decided to start removing
> CA certificates that use a weak 1024-bit key. Although those
> certificates are still valid, Mozilla has worked with the CAs, and they
> did agree that it's OK to remove them.
>
> However, there are end-entity and intermediate-CA certificates which
> have been issued by the removed CAs, which are still valid, and they
> might still be used by some - despite the CAs having attempted to reach
> out to all their customers and getting them to reconfigure their
> systems.
>
> This means, when installing the updated ca-certificates package version
> 2014.2.1, some SSL/TLS connections might suddenly fail, because the
> related CA certificate is no longer trusted.
>
> If you experience such situations, the right approach is to contact the
> owner of the certificate (or the server), and ask them to get a
> replacement certificate, or to install a replacement certificate on
> their SSL/TLS server.
>
> Additional details can be found in the update description, which I'll
> paste at the end of this message.
>
> (I have disabled karma-automation for this update, in case there's a
> need for a longer testing period. Note that this updated set of CA
> certificates is currently planned to be part of Firefox 32, which will
> get released around SEP 02.)
>
> Regards
> Kai
>
>
> Update description:
> ===
> This is an update to the latest released set of CA certificates
> according to the Mozilla CA Policy. It's the same set that has been
> released in NSS versions 3.16.4 and 3.17.
>
> It's noteworthy that several CA certificates with a weak key size of
> 1024-bits have been removed, prior to their expiration. (It is expected
> that additional CA certificates with weak 1024-bit keys will be removed
> in future releases.)
>
> The removed CA certificates have been used to issue end-entity and
> intermediate-CA certificates which are still valid. Those certificates
> are likely to be rejected when using this upated ca-certificates
> package. The owners of affected certificates should contact their CA and
> ask for replacement certificates. In some scenarios it might be
> sufficient to install an alternative intermediate CA certificate (e.g.
> on a TLS server), allowing an alternative trust chain to another root CA
> certificate to be found.
>
> More information about the affected CA certificates and other recent
> modifications can be found in the NSS release notes for version 3.16.3
> at
> https://developer.mozilla.org/en-US/docs/Mozilla/Projects/NSS/NSS_3.16.3_release_notes
>  with amendments to the changes as explained in the NSS release notes for 
> version 3.16.4 
> https://developer.mozilla.org/en-US/docs/Mozilla/Projects/NSS/NSS_3.16.4_release_notes
>
>

-- 
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: Circular dependencies in RPM

[Petr Pisar]

On 2014-08-25, Miroslav Suchý  wrote:
> Or we can wait for F21, which will have weak dependencies in RPM. And
> I anticipate that weak dependencies will break a lot of circles.
>
Does Fedora have guidelines what should and what should not be a weak
dependency?

My experience with Perl packages is that "declaring dependency because it's
recommended but the package works without it" is quite seldom. The
majority of build cycles are either build-time dependencies for tests or
hard run-time dependencies (the Perl module exits with an exception
without the dependency in some code paths.)

In my opinion, it would be much more appreciated if Fedora had
a mechanism to express "I want support for PDF" on the installed system
and then package manager would use this boolean to install or skip
affected dependencies. (This is the case of "some code paths" from
previous paragraph.)

-- Petr

-- 
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: systemd dependencies

[Vít Ondruch]

Dne 26.8.2014 11:06, Michal Sekletar napsal(a):
> On Tue, Aug 26, 2014 at 09:32:26AM +0200, Vít Ondruch wrote:
>> Hi,
> Hi Vít,
>
>> Recently I have noticed that systemd package dependency is creeping into
>> some packages where it is not necessary. subversion [1] or rsync [2] are
>> good examples. Please consider moving daemon parts into independent
>> subpackages. When I install rsync/subversion, I am typically interested
>> just in client side.
> At some point in time (F16 IIRC) we had systemd-units package which contained
> /etc/rpm/macros.systemd file. Packagers which followed our guidelines used for
> example %{unitdir} macro in %files. Hence they added systemd-units to
> BuildRequires.
>
> These days systemd-units no longer exists, macro file moved to systemd rpm and
> systemd-units is a provided by systemd rpm.

Thank you for insightful explanation.

Nevertheless, if you are using some macro, it is just build time
dependency. I believe that the issue might be due to %{unitdir} folder
ownership. And I see two solutions:

1) Packages which ships unit files should consider to put them into sub
package called either -daemon or -server. And this applies especially to
packages such as man (forgot to mention this one previously), rsync or
subversion. I don't typically use their server features or con jobs or
whatever.

2) sytemd should consider to provide -filesystem package, which would
limit the dependency to single small package (but this might be return
to the -units subpackage days? Not sure).

Their combination might be the best solution.

Vít
-- 
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: systemd dependencies

[Michal Sekletar]

On Tue, Aug 26, 2014 at 12:59:23PM +0200, Vít Ondruch wrote:
> Dne 26.8.2014 11:06, Michal Sekletar napsal(a):
> > On Tue, Aug 26, 2014 at 09:32:26AM +0200, Vít Ondruch wrote:
> >> Hi,
> > Hi Vít,
> >
> >> Recently I have noticed that systemd package dependency is creeping into
> >> some packages where it is not necessary. subversion [1] or rsync [2] are
> >> good examples. Please consider moving daemon parts into independent
> >> subpackages. When I install rsync/subversion, I am typically interested
> >> just in client side.
> > At some point in time (F16 IIRC) we had systemd-units package which 
> > contained
> > /etc/rpm/macros.systemd file. Packagers which followed our guidelines used 
> > for
> > example %{unitdir} macro in %files. Hence they added systemd-units to
> > BuildRequires.
> >
> > These days systemd-units no longer exists, macro file moved to systemd rpm 
> > and
> > systemd-units is a provided by systemd rpm.
> 
> Thank you for insightful explanation.
> 
> Nevertheless, if you are using some macro, it is just build time
> dependency. I believe that the issue might be due to %{unitdir} folder
> ownership. And I see two solutions:

Yes it is build time dependency only.

> 
> 1) Packages which ships unit files should consider to put them into sub
> package called either -daemon or -server. And this applies especially to
> packages such as man (forgot to mention this one previously), rsync or
> subversion. I don't typically use their server features or con jobs or
> whatever.

I think we can't make this a general rule. There are packages which has to ship
unit files in a main package and I'd argue that we have quite a lot of those. 
Note
that it is rather gut feeling not a fact I researched or measured in any
way. In any case having *recomendation* in guidelines doesn't hurt, thus such
split should be left at the curtesy of the individual maintainers.

But then again, I am not against such change in packages where it makes
sense.

> 
> 2) sytemd should consider to provide -filesystem package, which would
> limit the dependency to single small package (but this might be return
> to the -units subpackage days? Not sure).

That may improve a situation, but we have to commit to not going down the same
road in the future as we did with systemd-units. However I don't have all the
context why systemd-units was merged into systemd back then.

> 
> Their combination might be the best solution.
> 
> Vít

Michal
> -- 
> 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: systemd dependencies

[Lennart Poettering]

On Tue, 26.08.14 09:32, Vít Ondruch (vondr...@redhat.com) wrote:

> Hi,
> 
> Recently I have noticed that systemd package dependency is creeping into
> some packages where it is not necessary. subversion [1] or rsync [2] are
> good examples. Please consider moving daemon parts into independent
> subpackages. When I install rsync/subversion, I am typically interested
> just in client side.
> 
> Just to be clear, systemd-libs is in minimal build root already, so I am
> not complaining about systemd-libs package, but about systemd package.

What's the rationale here? I mean, we have so many dependencies, if you
want to minimize them, you have a lng way to go...

Lennart

-- 
Lennart Poettering, Red Hat
-- 
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: systemd dependencies

[Lennart Poettering]

On Tue, 26.08.14 11:06, Michal Sekletar (msekl...@redhat.com) wrote:

> > Recently I have noticed that systemd package dependency is creeping into
> > some packages where it is not necessary. subversion [1] or rsync [2] are
> > good examples. Please consider moving daemon parts into independent
> > subpackages. When I install rsync/subversion, I am typically interested
> > just in client side.
> 
> At some point in time (F16 IIRC) we had systemd-units package which contained
> /etc/rpm/macros.systemd file. Packagers which followed our guidelines used for
> example %{unitdir} macro in %files. Hence they added systemd-units to
> BuildRequires.
> 
> These days systemd-units no longer exists, macro file moved to systemd rpm and
> systemd-units is a provided by systemd rpm. Therefore systemd proper creeping
> into buildroots.

Yeah, we removed the systemd-units package a while after systemd was the
only init system we supported on Fedora...

Lennart

-- 
Lennart Poettering, Red Hat
-- 
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: systemd dependencies

[Lennart Poettering]

On Tue, 26.08.14 12:59, Vít Ondruch (vondr...@redhat.com) wrote:

> 2) sytemd should consider to provide -filesystem package, which would
> limit the dependency to single small package (but this might be return
> to the -units subpackage days? Not sure).

Why? 

I am really against splitting things up into a million of subpackages,
unless you have a ver good reason for a split.

Lennart

-- 
Lennart Poettering, Red Hat
-- 
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: systemd dependencies

[Vít Ondruch]

Dne 26.8.2014 13:49, Lennart Poettering napsal(a):
> On Tue, 26.08.14 09:32, Vít Ondruch (vondr...@redhat.com) wrote:
>
>> Hi,
>>
>> Recently I have noticed that systemd package dependency is creeping into
>> some packages where it is not necessary. subversion [1] or rsync [2] are
>> good examples. Please consider moving daemon parts into independent
>> subpackages. When I install rsync/subversion, I am typically interested
>> just in client side.
>>
>> Just to be clear, systemd-libs is in minimal build root already, so I am
>> not complaining about systemd-libs package, but about systemd package.
> What's the rationale here? I mean, we have so many dependencies, if you
> want to minimize them, you have a lng way to go...

Someone has to start somewhere. It is annoying to install several
packages, when you expect that only one should be installed. And by
coincidence, I met several of systemd dependencies during short period
of time.

Vít
-- 
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: systemd dependencies

[Vít Ondruch]

Dne 26.8.2014 13:51, Lennart Poettering napsal(a):
> On Tue, 26.08.14 12:59, Vít Ondruch (vondr...@redhat.com) wrote:
>
>> 2) sytemd should consider to provide -filesystem package, which would
>> limit the dependency to single small package (but this might be return
>> to the -units subpackage days? Not sure).
> Why? 
>
> I am really against splitting things up into a million of subpackages,
> unless you have a ver good reason for a split.
>
> Lennart
>

I am against installing million packages when I expect one. If I saw
systemd-filesystem installed, then I would think that something needs to
be placed into the systemd folder structure, but it was not worth of
splitting into the separate package, e.g. small unit file. But when I
see systemd and 5 other packages installed when I want to install
subversion, that looks fishy to me.


Vít
-- 
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: systemd dependencies

[Lennart Poettering]

On Tue, 26.08.14 14:18, Vít Ondruch (vondr...@redhat.com) wrote:

> >> Recently I have noticed that systemd package dependency is creeping into
> >> some packages where it is not necessary. subversion [1] or rsync [2] are
> >> good examples. Please consider moving daemon parts into independent
> >> subpackages. When I install rsync/subversion, I am typically interested
> >> just in client side.
> >>
> >> Just to be clear, systemd-libs is in minimal build root already, so I am
> >> not complaining about systemd-libs package, but about systemd package.
> > What's the rationale here? I mean, we have so many dependencies, if you
> > want to minimize them, you have a lng way to go...
> 
> Someone has to start somewhere. It is annoying to install several
> packages, when you expect that only one should be installed. And by
> coincidence, I met several of systemd dependencies during short period
> of time.

What I am not getting: what's the point? I mean, systemd is not exactly
an optional package in Fedora.

You are asking people to split their packages in two, but what's the
real reason for that? If the systemd package isn't optional anyway, why
is this the dep you start with and asking people to complicate things
for?

Lennart

-- 
Lennart Poettering, Red Hat
-- 
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: systemd dependencies

[Lennart Poettering]

On Tue, 26.08.14 14:22, Vít Ondruch (vondr...@redhat.com) wrote:

> > I am really against splitting things up into a million of subpackages,
> > unless you have a ver good reason for a split.
> 
> I am against installing million packages when I expect one. If I saw
> systemd-filesystem installed, then I would think that something needs to
> be placed into the systemd folder structure, but it was not worth of
> splitting into the separate package, e.g. small unit file. But when I
> see systemd and 5 other packages installed when I want to install
> subversion, that looks fishy to me.

The init system of Fedora is systemd. What did you expect?

Lennart

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

rawhide report: 20140826 changes

[Fedora Rawhide Report]

Broken deps for i386
--
[APLpy]
APLpy-0.9.8-5.fc21.noarch requires pywcs
[PyKDE]
PyKDE-3.16.6-14.fc20.i686 requires sip-api(10) >= 0:10.0
[PyQuante]
PyQuante-libint-1.6.4-11.fc22.1.i686 requires libint(x86-32) = 
0:1.1.6-2.fc21
[audtty]
audtty-0.1.12-9.fc20.i686 requires libaudclient.so.2
[authhub]
authhub-0.1.2-3.fc19.i686 requires libjson.so.0
[aws]
aws-devel-3.1.0-6.fc21.i686 requires libgrypt-devel
[cduce]
cduce-0.6.0-6.fc22.i686 requires ocaml(String) = 
0:d3baab1cf7edc2fec1fa9c9217140d10
cduce-0.6.0-6.fc22.i686 requires ocaml(Pervasives) = 
0:4329e57fde14cc94b02a739d2595516b
cduce-0.6.0-6.fc22.i686 requires ocaml(Location) = 
0:0beb1f904f757422c85ea51aae076559
cduce-0.6.0-6.fc22.i686 requires ocaml(Lazy) = 
0:65801e9cdbd8c4e82df1f02f97116721
cduce-0.6.0-6.fc22.i686 requires ocaml(Format) = 
0:a9de4c8c622e30d6eb221ce41563dbf4
cduce-0.6.0-6.fc22.i686 requires ocaml(Filename) = 
0:3b889637b7a18c39de7a0d0f5d10432e
cduce-0.6.0-6.fc22.i686 requires ocaml(Array) = 
0:9125e0607c9ad02018c9eb4672142241
[compat-gcc-34]
compat-gcc-34-c++-3.4.6-29.fc19.i686 requires libstdc++ < 0:4.9.0
[condor]
condor-plumage-8.1.4-7.a1a7df5.fc22.i686 requires libmongoclient.so
[cp2k]
cp2k-2.5.1-8.fc22.i686 requires libint(x86-32) = 0:1.1.6-2.fc21
cp2k-mpich-2.5.1-8.fc22.i686 requires libint(x86-32) = 0:1.1.6-2.fc21
cp2k-openmpi-2.5.1-8.fc22.i686 requires libint(x86-32) = 0:1.1.6-2.fc21
[csound]
csound-java-5.19.01-1.fc20.i686 requires libgcj_bc.so.1
csound-java-5.19.01-1.fc20.i686 requires java-gcj-compat
csound-java-5.19.01-1.fc20.i686 requires java-gcj-compat
csound-java-5.19.01-1.fc20.i686 requires java-1.5.0-gcj
csound-tk-5.19.01-1.fc20.i686 requires libtk8.5.so
csound-tk-5.19.01-1.fc20.i686 requires libtcl8.5.so
[deltacloud-core]
deltacloud-core-rackspace-1.1.3-1.fc20.noarch requires 
rubygem(cloudservers)
deltacloud-core-rackspace-1.1.3-1.fc20.noarch requires 
rubygem(cloudfiles)
[docker-registry]
docker-registry-0.7.3-1.fc22.noarch requires docker-io
[dragonegg]
dragonegg-3.4-0.3.rc0.fc21.i686 requires gcc = 0:4.8.2-14.fc21
[edelib]
edelib-2.1-5.fc22.i686 requires libedelib.so
edelib-devel-2.1-5.fc22.i686 requires libedelib.so
[eucalyptus]
eucalyptus-common-java-3.3.0-0.5.20130408git32052445.fc20.i686 requires 
hibernate3-jbosscache >= 0:3.6.10-7
[fatrat]
1:fatrat-1.2.0-0.21.beta2.fc22.i686 requires libtorrent-rasterbar.so.7
[flashrom]
flashrom-0.9.6.1-5.svn1705.fc20.i686 requires libftdi.so.1
[flush]
flush-0.9.12-10.fc22.i686 requires libtorrent-rasterbar.so.7
[freesteam]
freesteam-ascend-2.1-6.20140724svn753.fc22.i686 requires libascend.so.1
[gcc-python-plugin]
gcc-python2-debug-plugin-0.12-18.fc21.i686 requires gcc = 
0:4.8.2-14.fc21
gcc-python2-plugin-0.12-18.fc21.i686 requires gcc = 0:4.8.2-14.fc21
gcc-python3-debug-plugin-0.12-18.fc21.i686 requires 
libpython3.3dm.so.1.0
gcc-python3-debug-plugin-0.12-18.fc21.i686 requires gcc = 
0:4.8.2-14.fc21
gcc-python3-plugin-0.12-18.fc21.i686 requires libpython3.3m.so.1.0
gcc-python3-plugin-0.12-18.fc21.i686 requires gcc = 0:4.8.2-14.fc21
[gedit-valencia]
gedit-valencia-0.4.0-1.20131223git94442bf.fc21.i686 requires 
libvala-0.24.so.0
[gnome-python2-desktop]
gnome-python2-metacity-2.32.0-18.fc21.i686 requires 
libmetacity-private.so.0
[gnome-shell-extension-pomodoro]
gnome-shell-extension-pomodoro-0.10.0-4.fc21.i686 requires 
libupower-glib.so.2
[gofer]
ruby-gofer-0.77.1-2.fc21.noarch requires rubygem(qpid) >= 0:0.16.0
[ice]
ice-php-3.5.1-4.fc21.i686 requires php(zend-abi) = 0:20121212-32
ice-php-3.5.1-4.fc21.i686 requires php(api) = 0:20121113-32
[iwhd]
iwhd-1.6-11.fc22.i686 requires libmongoclient.so
[lcg-util]
lcg-util-1.16.0-3.fc21.i686 requires libgfal.so.1
lcg-util-libs-1.16.0-3.fc21.i686 requires libgfal.so.1
lcg-util-python-1.16.0-3.fc21.i686 requires libgfal.so.1
[leiningen]
leiningen-1.7.1-7.fc20.noarch requires maven-ant-tasks
leiningen-1.7.1-7.fc20.noarch requires classworlds
[libghemical]
libghemical-2.99.1-24.fc20.i686 requires libf77blas.so.3
libghemical-2.99.1-24.fc20.i686 requires libatlas.so.3
[libguestfs]
1:ocaml-libguestfs-1.27.30-1.fc22.i686 requires ocaml(Pervasives) = 
0:4329e57fde14cc94b02a739d2595516b
[libopensync-plugin-irmc]
1:libopensync-plugin-irmc-0.22-7.fc20.i686 requires libopenobex.so.1
[librasterlite2]
librasterlite2-1.0.0-1.rc0.fc22.i686 requires libgeotiff.so.1.2
librasterlite2-tools-1.0.0-1.rc0.fc22.i686 requires libgeotiff.so.1.2
[libreatlas]
libreatlas-1.0.0a-8.fc22.i686 requires libgeotiff.so.1.2
[libvirt]
   

Re: systemd dependencies

[Vít Ondruch]

Dne 26.8.2014 14:23, Lennart Poettering napsal(a):
> On Tue, 26.08.14 14:18, Vít Ondruch (vondr...@redhat.com) wrote:
>
 Recently I have noticed that systemd package dependency is creeping into
 some packages where it is not necessary. subversion [1] or rsync [2] are
 good examples. Please consider moving daemon parts into independent
 subpackages. When I install rsync/subversion, I am typically interested
 just in client side.

 Just to be clear, systemd-libs is in minimal build root already, so I am
 not complaining about systemd-libs package, but about systemd package.
>>> What's the rationale here? I mean, we have so many dependencies, if you
>>> want to minimize them, you have a lng way to go...
>> Someone has to start somewhere. It is annoying to install several
>> packages, when you expect that only one should be installed. And by
>> coincidence, I met several of systemd dependencies during short period
>> of time.
> What I am not getting: what's the point? I mean, systemd is not exactly
> an optional package in Fedora.
>
> You are asking people to split their packages in two, but what's the
> real reason for that? If the systemd package isn't optional anyway, why
> is this the dep you start with and asking people to complicate things
> for?
>
> Lennart
>

Isn't it optional? I am using mock and can build probably every ruby
package without *systemd* package installed into the build root (I am
not speaking about *systemd-libs*). But once I install one of man,
subversion or rsync packages, systemd is suddenly pulled in, why? Why it
should be?

You can try session like this yourself:


$ mock -r fedora-rawhide-i386 --init
INFO: mock.py version 1.1.41 starting...
Start: init plugins
INFO: selinux enabled
Finish: init plugins
Start: run
Start: lock buildroot
Start: clean chroot
INFO: chroot (/var/lib/mock/fedora-rawhide-i386) unlocked and deleted
Finish: clean chroot
Finish: lock buildroot
Start: chroot init
Start: lock buildroot
Mock Version: 1.1.41
INFO: Mock Version: 1.1.41
INFO: calling preinit hooks
INFO: enabled root cache
Start: unpacking root cache
Finish: unpacking root cache
INFO: enabled yum cache
Start: cleaning yum metadata
Finish: cleaning yum metadata
INFO: enabled ccache
Start: device setup
Finish: device setup
Start: yum update
Finish: yum update
Finish: lock buildroot
Finish: chroot init
INFO: Installed packages:
Finish: run

$ mock -r fedora-rawhide-i386 shell
INFO: mock.py version 1.1.41 starting...
Start: init plugins
INFO: selinux enabled
Finish: init plugins
Start: run
Start: lock buildroot
Start: device setup
Finish: device setup
Start: shell

[root@unused-4-226 /]# svn --help
bash: svn: command not found

[root@unused-4-226 /]# # Ah, no subversion

[root@unused-4-226 /]# logout
Finish: shell
Finish: lock buildroot

$ mock -r fedora-rawhide-i386 --install subversion
INFO: mock.py version 1.1.41 starting...
Start: init plugins
INFO: selinux enabled
Finish: init plugins
Start: run
Mock Version: 1.1.41
INFO: Mock Version: 1.1.41
Start: lock buildroot
INFO: installing package(s): subversion
INFO:

 Package  Arch   Version
RepositorySize

Installing:
 subversion   i686   1.8.10-2.fc22  
fedora   1.2 M
Installing for dependencies:
 acl  i686   2.2.52-7.fc22  
fedora76 k
 apr  i686   1.5.1-3.fc22   
fedora   118 k
 apr-util i686   1.5.3-3.fc22   
fedora98 k
 cryptsetup-libs  i686   1.6.6-1.fc22   
fedora   188 k
 dbus i686   1:1.8.6-3.fc22 
fedora   332 k
 dbus-libsi686   1:1.8.6-3.fc22 
fedora   169 k
 device-mapperi686   1.02.88-2.fc22 
fedora   221 k
 device-mapper-libs   i686   1.02.88-2.fc22 
fedora   276 k
 fipschecki686   1.4.1-7.fc22   
fedora25 k
 fipscheck-libi686   1.4.1-7.fc22   
fedora15 k
 kmod i686   18-3.fc22  
fedora   112 k
 kmod-libsi686   18-3.fc22  
fedora62 k
 libseccomp   i686   2.1.1-5.fc22   
fedora44 k
 libserf  i686   1.3.7-2.fc22   
fedora58 k
 python   i686   2.7.8-6.fc22   
fedora91 k
 qrencode-libsi686   3.4.2-4.fc22   
fedora56 k
 subversion-libs  i686   1.8.10-2.fc22  
fedora   1.1 M
 systemd  i686   216-2.fc22 
fedora   4.9 M

Transaction Summary
=

Re: systemd dependencies

[Vít Ondruch]

Dne 26.8.2014 14:55, Vít Ondruch napsal(a):
> Dne 26.8.2014 14:23, Lennart Poettering napsal(a):
>> On Tue, 26.08.14 14:18, Vít Ondruch (vondr...@redhat.com) wrote:
>>
> Recently I have noticed that systemd package dependency is creeping into
> some packages where it is not necessary. subversion [1] or rsync [2] are
> good examples. Please consider moving daemon parts into independent
> subpackages. When I install rsync/subversion, I am typically interested
> just in client side.
>
> Just to be clear, systemd-libs is in minimal build root already, so I am
> not complaining about systemd-libs package, but about systemd package.
 What's the rationale here? I mean, we have so many dependencies, if you
 want to minimize them, you have a lng way to go...
>>> Someone has to start somewhere. It is annoying to install several
>>> packages, when you expect that only one should be installed. And by
>>> coincidence, I met several of systemd dependencies during short period
>>> of time.
>> What I am not getting: what's the point? I mean, systemd is not exactly
>> an optional package in Fedora.
>>
>> You are asking people to split their packages in two, but what's the
>> real reason for that? If the systemd package isn't optional anyway, why
>> is this the dep you start with and asking people to complicate things
>> for?
>>
>> Lennart
>>
> Isn't it optional? I am using mock and can build probably every ruby
> package without *systemd* package installed into the build root (I am
> not speaking about *systemd-libs*). But once I install one of man,
> subversion or rsync packages, systemd is suddenly pulled in, why? Why it
> should be?
>
> You can try session like this yourself:
>
>
> $ mock -r fedora-rawhide-i386 --init
> INFO: mock.py version 1.1.41 starting...
> Start: init plugins
> INFO: selinux enabled
> Finish: init plugins
> Start: run
> Start: lock buildroot
> Start: clean chroot
> INFO: chroot (/var/lib/mock/fedora-rawhide-i386) unlocked and deleted
> Finish: clean chroot
> Finish: lock buildroot
> Start: chroot init
> Start: lock buildroot
> Mock Version: 1.1.41
> INFO: Mock Version: 1.1.41
> INFO: calling preinit hooks
> INFO: enabled root cache
> Start: unpacking root cache
> Finish: unpacking root cache
> INFO: enabled yum cache
> Start: cleaning yum metadata
> Finish: cleaning yum metadata
> INFO: enabled ccache
> Start: device setup
> Finish: device setup
> Start: yum update
> Finish: yum update
> Finish: lock buildroot
> Finish: chroot init
> INFO: Installed packages:
> Finish: run
>
> $ mock -r fedora-rawhide-i386 shell
> INFO: mock.py version 1.1.41 starting...
> Start: init plugins
> INFO: selinux enabled
> Finish: init plugins
> Start: run
> Start: lock buildroot
> Start: device setup
> Finish: device setup
> Start: shell
>
> [root@unused-4-226 /]# svn --help
> bash: svn: command not found
>
> [root@unused-4-226 /]# # Ah, no subversion
>
> [root@unused-4-226 /]# logout
> Finish: shell
> Finish: lock buildroot
>
> $ mock -r fedora-rawhide-i386 --install subversion
> INFO: mock.py version 1.1.41 starting...
> Start: init plugins
> INFO: selinux enabled
> Finish: init plugins
> Start: run
> Mock Version: 1.1.41
> INFO: Mock Version: 1.1.41
> Start: lock buildroot
> INFO: installing package(s): subversion
> INFO:
> 
>  Package  Arch   Version
> RepositorySize
> 
> Installing:
>  subversion   i686   1.8.10-2.fc22  
> fedora   1.2 M
> Installing for dependencies:
>  acl  i686   2.2.52-7.fc22  
> fedora76 k
>  apr  i686   1.5.1-3.fc22   
> fedora   118 k
>  apr-util i686   1.5.3-3.fc22   
> fedora98 k
>  cryptsetup-libs  i686   1.6.6-1.fc22   
> fedora   188 k
>  dbus i686   1:1.8.6-3.fc22 
> fedora   332 k
>  dbus-libsi686   1:1.8.6-3.fc22 
> fedora   169 k
>  device-mapperi686   1.02.88-2.fc22 
> fedora   221 k
>  device-mapper-libs   i686   1.02.88-2.fc22 
> fedora   276 k
>  fipschecki686   1.4.1-7.fc22   
> fedora25 k
>  fipscheck-libi686   1.4.1-7.fc22   
> fedora15 k
>  kmod i686   18-3.fc22  
> fedora   112 k
>  kmod-libsi686   18-3.fc22  
> fedora62 k
>  libseccomp   i686   2.1.1-5.fc22   
> fedora44 k
>  libserf  i686   1.3.7-2.fc22   
> fedora58 k
>  python   i686   2.7.8-6.fc22   
> fedora91 k
>  qrencode-libsi686   3.4.

Re: systemd dependencies

[Jan Zelený]

On 26. 8. 2014 at 14:55:34, Vít Ondruch wrote:
> Dne 26.8.2014 14:23, Lennart Poettering napsal(a):
> > On Tue, 26.08.14 14:18, Vít Ondruch (vondr...@redhat.com) wrote:
>  Recently I have noticed that systemd package dependency is creeping
>  into
>  some packages where it is not necessary. subversion [1] or rsync [2]
>  are
>  good examples. Please consider moving daemon parts into 
independent
>  subpackages. When I install rsync/subversion, I am typically interested
>  just in client side.
>  
>  Just to be clear, systemd-libs is in minimal build root already, so I
>  am
>  not complaining about systemd-libs package, but about systemd 
package.
> >>> 
> >>> What's the rationale here? I mean, we have so many dependencies, if you
> >>> want to minimize them, you have a lng way to go...
> >> 
> >> Someone has to start somewhere. It is annoying to install several
> >> packages, when you expect that only one should be installed. And by
> >> coincidence, I met several of systemd dependencies during short period
> >> of time.
> > 
> > What I am not getting: what's the point? I mean, systemd is not exactly
> > an optional package in Fedora.
> > 
> > You are asking people to split their packages in two, but what's the
> > real reason for that? If the systemd package isn't optional anyway, why
> > is this the dep you start with and asking people to complicate things
> > for?
> > 
> > Lennart
> 
> Isn't it optional? I am using mock and can build probably every ruby
> package without *systemd* package installed into the build root (I am
> not speaking about *systemd-libs*). But once I install one of man,
> subversion or rsync packages, systemd is suddenly pulled in, why? Why it
> should be?

I have to agree with Vít here. Unnecessary dependencies are not something 
anyone should be advocating, whatever the reason might be.

By the same logic you offer, systemd dependencies can be removed from all of 
the mentioned packages, as it's safe to assume systemd is core part of the 
system and will therefore be installed.

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

F-21 Branched report: 20140826 changes

[Fedora Branched Report]

Compose started at Tue Aug 26 07:15:03 UTC 2014

Broken deps for armhfp
--
[APLpy]
APLpy-0.9.8-5.fc21.noarch requires pywcs
[PyKDE]
PyKDE-3.16.6-14.fc20.armv7hl requires sip-api(10) >= 0:10.0
[PyQuante]
PyQuante-libint-1.6.4-11.fc21.1.armv7hl requires libint(armv7hl-32) = 
0:1.1.6-2.fc21
[audtty]
audtty-0.1.12-9.fc20.armv7hl requires libaudclient.so.2
[authhub]
authhub-0.1.2-3.fc19.armv7hl requires libjson.so.0
[cp2k]
cp2k-2.5.1-8.fc21.armv7hl requires libint(armv7hl-32) = 0:1.1.6-2.fc21
cp2k-mpich-2.5.1-8.fc21.armv7hl requires libint(armv7hl-32) = 
0:1.1.6-2.fc21
cp2k-openmpi-2.5.1-8.fc21.armv7hl requires libint(armv7hl-32) = 
0:1.1.6-2.fc21
[csound]
csound-java-5.19.01-1.fc20.armv7hl requires libgcj_bc.so.1
csound-java-5.19.01-1.fc20.armv7hl requires java-gcj-compat
csound-java-5.19.01-1.fc20.armv7hl requires java-gcj-compat
csound-java-5.19.01-1.fc20.armv7hl requires java-1.5.0-gcj
csound-tk-5.19.01-1.fc20.armv7hl requires libtk8.5.so
csound-tk-5.19.01-1.fc20.armv7hl requires libtcl8.5.so
[deltacloud-core]
deltacloud-core-rackspace-1.1.3-1.fc20.noarch requires 
rubygem(cloudservers)
deltacloud-core-rackspace-1.1.3-1.fc20.noarch requires 
rubygem(cloudfiles)
[docker-registry]
docker-registry-0.7.3-1.fc21.noarch requires docker-io
[dragonegg]
dragonegg-3.4-0.3.rc0.fc21.armv7hl requires gcc = 0:4.8.2-14.fc21
[edelib]
edelib-2.1-5.fc21.armv7hl requires libedelib.so
edelib-devel-2.1-5.fc21.armv7hl requires libedelib.so
[eucalyptus]
eucalyptus-common-java-3.3.0-0.5.20130408git32052445.fc20.armv7hl 
requires hibernate3-jbosscache >= 0:3.6.10-7
[fatrat]
1:fatrat-1.2.0-0.21.beta2.fc21.armv7hl requires 
libtorrent-rasterbar.so.7
[flashrom]
flashrom-0.9.6.1-5.svn1705.fc20.armv7hl requires libftdi.so.1
[flush]
flush-0.9.12-10.fc21.armv7hl requires libtorrent-rasterbar.so.7
[freesteam]
freesteam-ascend-2.1-6.20140724svn753.fc21.armv7hl requires 
libascend.so.1
[gcc-python-plugin]
gcc-python2-debug-plugin-0.12-18.fc21.armv7hl requires gcc = 
0:4.8.2-14.fc21
gcc-python2-plugin-0.12-18.fc21.armv7hl requires gcc = 0:4.8.2-14.fc21
gcc-python3-debug-plugin-0.12-18.fc21.armv7hl requires 
libpython3.3dm.so.1.0
gcc-python3-debug-plugin-0.12-18.fc21.armv7hl requires gcc = 
0:4.8.2-14.fc21
gcc-python3-plugin-0.12-18.fc21.armv7hl requires libpython3.3m.so.1.0
gcc-python3-plugin-0.12-18.fc21.armv7hl requires gcc = 0:4.8.2-14.fc21
[gedit-valencia]
gedit-valencia-0.4.0-1.20131223git94442bf.fc21.armv7hl requires 
libvala-0.24.so.0
[ghc-hint]
ghc-hint-devel-0.4.2.0-2.fc21.armv7hl requires 
ghc-devel(ghc-7.6.3-9662c0f342b2d5c9e1cd2b6330e697bc)
[gnome-python2-desktop]
gnome-python2-metacity-2.32.0-18.fc21.armv7hl requires 
libmetacity-private.so.0
[gnome-shell-extension-pomodoro]
gnome-shell-extension-pomodoro-0.10.0-4.fc21.armv7hl requires 
libupower-glib.so.2
[gofer]
ruby-gofer-0.77.1-2.fc21.noarch requires rubygem(qpid) >= 0:0.16.0
[hibernate-search]
hibernate-search-4.5.1-4.fc21.noarch requires mvn(org.apache.avro:avro)
[ice]
ice-php-3.5.1-4.fc21.armv7hl requires php(zend-abi) = 0:20121212-32
ice-php-3.5.1-4.fc21.armv7hl requires php(api) = 0:20121113-32
[leiningen]
leiningen-1.7.1-7.fc20.noarch requires maven-ant-tasks
leiningen-1.7.1-7.fc20.noarch requires classworlds
[leksah]
ghc-leksah-devel-0.12.1.3-15.fc21.armv7hl requires 
ghc-devel(ghc-7.6.3-9662c0f342b2d5c9e1cd2b6330e697bc)
[leksah-server]
ghc-leksah-server-devel-0.12.1.2-15.fc21.armv7hl requires 
ghc-devel(ghc-7.6.3-9662c0f342b2d5c9e1cd2b6330e697bc)
[libghemical]
libghemical-2.99.1-24.fc20.armv7hl requires libf77blas.so.3
libghemical-2.99.1-24.fc20.armv7hl requires libatlas.so.3
[libopensync-plugin-irmc]
1:libopensync-plugin-irmc-0.22-7.fc20.armv7hl requires libopenobex.so.1
[libvirt]
libvirt-lock-sanlock-1.2.7-2.fc21.armv7hl requires sanlock >= 0:2.4
libvirt-lock-sanlock-1.2.7-2.fc21.armv7hl requires 
libsanlock_client.so.1
[lirc]
lirc-0.9.1a-2.fc21.armv7hl requires libiguanaIR.so.0(IGUANAIR_0)
lirc-0.9.1a-2.fc21.armv7hl requires libiguanaIR.so.0
[ltsp]
ltsp-client-5.4.5-8.fc21.armv7hl requires fuse-unionfs
ltsp-server-5.4.5-8.fc21.armv7hl requires cdialog
[meshmagick]
meshmagick-0.6.0-20.svn2898.fc21.armv7hl requires libOgreMain.so.1.8.1
meshmagick-libs-0.6.0-20.svn2898.fc21.armv7hl requires 
libOgreMain.so.1.8.1
[monodevelop-vala]
monodevelop-vala-2.8.8.1-6.fc21.armv7hl requires vala < 0:0.25.0
[mpqc]
mpqc-2.3.1-26.fc21.armv7hl requires libint(armv7hl-32) = 0:1.1.6-2.fc21
[netdisco]
netdisco-1.1-7.fc21.noarch requires perl(SNMP::Info::Layer2::Bay)
[openstack-nova]
 

Re: Agenda for Env-and-Stacks WG meeting (2014-08-26)

[Marcela Mašláňová]

#fedora-meeting: Env and Stacks (2014-08-26)



Meeting started by mmaslano at 13:00:13 UTC. The full logs are available
at
http://meetbot.fedoraproject.org/fedora-meeting/2014-08-26/env-and-stacks.2014-08-26-13.00.log.html
.



Meeting summary
---
* follow up from we learnt on Flock  (mmaslano, 13:01:55)
  * ACTION: hhorak will send a proposal for every WG to send a short
summary time to time to other WGs directly, so we all stay tuned
(hhorak, 13:10:25)
  * ACTION: mmaslano will continue in writiing status of env and stacks
WG  (mmaslano, 13:11:38)

* EPEL/epic proposal  (mmaslano, 13:11:51)
  * LINK:

https://lists.fedoraproject.org/pipermail/epel-devel/2014-March/009320.html
(juhp_, 13:36:27)
  * ACTION: juhp_ will chat with smooge about epel/epic proposal and
what should Env and Stack WG do about it  (mmaslano, 14:02:06)

Meeting ended at 14:16:36 UTC.




Action Items

* hhorak will send a proposal for every WG to send a short summary time
  to time to other WGs directly, so we all stay tuned
* mmaslano will continue in writiing status of env and stacks WG
* juhp_ will chat with smooge about epel/epic proposal and what should
  Env and Stack WG do about it




Action Items, by person
---
* hhorak
  * hhorak will send a proposal for every WG to send a short summary
time to time to other WGs directly, so we all stay tuned
* juhp
  * juhp_ will chat with smooge about epel/epic proposal and what should
Env and Stack WG do about it
* juhp_
  * juhp_ will chat with smooge about epel/epic proposal and what should
Env and Stack WG do about it
* mmaslano
  * mmaslano will continue in writiing status of env and stacks WG
* **UNASSIGNED**
  * (none)




People Present (lines said)
---
* juhp_ (57)
* mmaslano (38)
* hhorak (30)
* langdon (11)
* bkabrda (6)
* zodbot (5)
* vpavlin (4)
* pingou (4)
* sicampbell (1)
* bkabrda1 (1)
* pkovar (1)
* samkottler (0)
* tjanez (0)
* juhp (0)




Generated by `MeetBot`_ 0.1.4

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

Self introduction: Valentin Gologuzov

[Valentin Gologuzov]

Hi everybody,

My name is Valentin Gologuzov. I've recently joined Copr project at Red 
Hat.
Prior I've been using Linux for a long time, but it was primarily 
debian, so the RH/Fedora ecosystem quite new for me. I have 3 year 
experience of backend development in Python, mainly aimed for service 
high availability and performance.


Here is my first package for Fedora: 
https://bugzilla.redhat.com/show_bug.cgi?id=1131616 , it provides python 
interface to the Copr service.


--
Best regards,
Gologuzov Valentin.
--
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: systemd dependencies

[DJ Delorie]

> What's the rationale here? I mean, we have so many dependencies, if
> you want to minimize them, you have a lng way to go...

When I bootstrapped Fedora for ARM way back when, I had to deal with
these dependencies.  A lot.  Finding a minimal set of RPMs to
cross-compile to get a bootable core was very difficult because of
dependencies, and managing the path up to koji was a nightmare.  Even
after that, there were some packages that couldn't be built *at all*
because of circuilar dependencies or dependencies on them.

So, to all of you who say "oh well" to dependencies... I hate you.

Seriously.  Not only have you made my personal job miserable for a
while, but you demonstrate the worst traits of engineering.  If
there's a problem, you don't hide it or just "let it be because we're
used to it."  You *fix* it.  And you make sure it *stays* fixed.  Take
some pride in your work!  Do the best you can!  If you're only willing
to do mediocre work and let problems exist because you can't be
bothered to fix them, then Fedora will at best be a mediocre product.
-- 
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: systemd dependencies

[DJ Delorie]

> If I saw systemd-filesystem installed, then I would think that
> something needs to be placed into the systemd folder structure,

Perhaps the bug is this: that you need to install a whole other RPM
just to make a directory exist so you can put a file in it.

Why can't the RPM providing the file just make the directory and not
have a dependency at all?
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Proposal for every WG to send a short summary *to other WGs directly*

[Honza Horak]

Hi working groups members,

since we have learned on Flock that new Fedora working groups do not 
communicate with each other much (or enough), I'd like to propose the 
following:


Every working group will time to time (e.g. weekly) send short summary 
about what they did / were talking about directly to mailing lists of 
other working groups + to devel@fp.o. Really only a short summary with 
links where one can find details.


I tried to collect such info from the meeting logs and mailing lists for 
the last few weeks for Env and Stacks WG:

https://lists.fedoraproject.org/pipermail/env-and-stacks/2014-August/000487.html

I found many notes are really worth spreading beyond groups' borders, 
but it takes too much time for one person to collect all the 
information. Thus, proposing to "do a summary once per group and share 
with other groups".


Another benefit would be that Matt would have better content for his 5tiftw.

I don't think we need to sync about date or frequency, just remembering 
to send a direct mail if anything interesting is done/discussed should 
work fine.


List of proposed MLs to send this summary to:
ser...@lists.fedoraproject.org
desk...@lists.fedoraproject.org
cl...@lists.fedoraproject.org
env-and-sta...@lists.fedoraproject.org
devel@lists.fedoraproject.org

Comments, ideas or better solutions are welcome as usually, but I might 
be offline until Sunday, so do not expect any answers from me in that 
time :)


Cheers,
Honza
--
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: Proposal for every WG to send a short summary *to other WGs directly*

[Josh Boyer]

On Tue, Aug 26, 2014 at 10:46 AM, Honza Horak  wrote:
> Hi working groups members,
>
> since we have learned on Flock that new Fedora working groups do not
> communicate with each other much (or enough), I'd like to propose the
> following:
>
> Every working group will time to time (e.g. weekly) send short summary about
> what they did / were talking about directly to mailing lists of other
> working groups + to devel@fp.o. Really only a short summary with links where
> one can find details.
>
> I tried to collect such info from the meeting logs and mailing lists for the
> last few weeks for Env and Stacks WG:
> https://lists.fedoraproject.org/pipermail/env-and-stacks/2014-August/000487.html
>
> I found many notes are really worth spreading beyond groups' borders, but it
> takes too much time for one person to collect all the information. Thus,
> proposing to "do a summary once per group and share with other groups".
>
> Another benefit would be that Matt would have better content for his 5tiftw.
>
> I don't think we need to sync about date or frequency, just remembering to
> send a direct mail if anything interesting is done/discussed should work
> fine.
>
> List of proposed MLs to send this summary to:
> ser...@lists.fedoraproject.org
> desk...@lists.fedoraproject.org
> cl...@lists.fedoraproject.org
> env-and-sta...@lists.fedoraproject.org
> devel@lists.fedoraproject.org
>
> Comments, ideas or better solutions are welcome as usually, but I might be
> offline until Sunday, so do not expect any answers from me in that time :)

I don't have any major objections to this, but I will note that
reports stopped being sent to FESCo because at some point they were
kind of redundant.  "Still working on thing X" every week isn't really
something that needs to be sent.  So I would avoid a weekly deadline
and maybe just post minutes/summaries of the meetings the groups have
when there is actually something to communicate.

josh
-- 
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: systemd dependencies

[Josh Boyer]

On Tue, Aug 26, 2014 at 10:44 AM, DJ Delorie  wrote:
>
>> What's the rationale here? I mean, we have so many dependencies, if
>> you want to minimize them, you have a lng way to go...
>
> When I bootstrapped Fedora for ARM way back when, I had to deal with
> these dependencies.  A lot.  Finding a minimal set of RPMs to
> cross-compile to get a bootable core was very difficult because of
> dependencies, and managing the path up to koji was a nightmare.  Even
> after that, there were some packages that couldn't be built *at all*
> because of circuilar dependencies or dependencies on them.
>
> So, to all of you who say "oh well" to dependencies... I hate you.
>
> Seriously.  Not only have you made my personal job miserable for a
> while, but you demonstrate the worst traits of engineering.  If
> there's a problem, you don't hide it or just "let it be because we're
> used to it."  You *fix* it.  And you make sure it *stays* fixed.  Take
> some pride in your work!  Do the best you can!  If you're only willing
> to do mediocre work and let problems exist because you can't be
> bothered to fix them, then Fedora will at best be a mediocre product.

Your message is likely to be lost because your tone is basically an
attack.  It's pretty unwarranted as well.  People don't add
dependencies just for the hell of it.  They grow over time like any
software bloat, and usually make sense at the time they're added.

FWIW, I agree the dependency issues can be a problem.  I just wish you
wouldn't have resorted to being so negative.

josh
-- 
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: ca-certificates 2014.2.1 will remove several still valid CA certificates with weak keys

[Eric H. Christensen]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On Tue, Aug 26, 2014 at 12:36:47PM +0200, Vít Ondruch wrote:
> $ gem fetch power_assert
> ERROR:  Could not find a valid gem 'power_assert' (>= 0), here is why:
>   Unable to download data from https://rubygems.org/ -
> SSL_connect returned=1 errno=0 state=SSLv3 read server certificate B:
> certificate verify failed
> (https://s3.amazonaws.com/production.s3.rubygems.org/latest_specs.4.8.gz)
> 
> 
> Upstream RubyGems ships the certificates, but on your request, I removed
> the bundled certificates [1]. Now, 3 months later are RubyGems broken in
> F21+ due to this update. Luckily, I have never backported this commit to
> F20, so this particular update is not harmful for stable Fedora release,
> but what am I supposed to do with F21+?
> 
> I don't feel like contacting Amazon. You claim that nothing should break
> and Mozilla contacted everybody, so why not Amazon? Are they so negligible?
> 
> Should I follow your advises or follow upstream? Sorry, but this puzzles
> me ...


Hmmm, according to SSLLabs[0] rubygems.org is using a 2048-bit certificate and 
chains all the way up to the CA with 2048-bit certificate.  The 
s3.amazonaws.com URL also uses a 2048-bit cert and chains up to the CA with 
2048-bit certs as well.  If the "fix" to the CA trust file only removed CAs 
with weak (<2048-bit) certificates it would appear that the breakage you see 
wouldn't be affected by this.

Out of curisity, did certificate verification get turned on in the F21 version?

- -- Eric

- --
Eric "Sparks" Christensen
Fedora Project

spa...@fedoraproject.org - spa...@redhat.com
097C 82C3 52DF C64A 50C2  E3A3 8076 ABDE 024B B3D1
- --
-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQGcBAEBCgAGBQJT/KEGAAoJEB/kgVGp2CYv0UoL/2xSiic1najZuVsrCNMkmbkm
cH/7v/r9NAFFm0+yqjyl7Z1yweOb/VFIKTqBp2WuxEP2JFrclc/8MwG7vGymjDra
7wPxj+vF3vebHDWKW5MU6QFIE7LdumYTRqty5sSX/BfoFZIf1ZNI2zLPd5HglS+e
A+KjfSHjRChUIdobD/hDqxdJc36h3w1rUMzqx/lywpNxWsL56JpxqjT139O8C9xA
qIIdnjZJUtE2xK78rnRFjWgRZkUj2M2rjJfTpYwwcofsVkyNeh1nlTcmXnLyOyw3
zNoy8CpmfMFAOiVq6JZTl3gL77k76AjdnJ3Q+tT1uxZTx0lSxZz44iSB9s50ZLDb
rR7lG08Je3kuk6S5afIeoo8PtFlQpxBVam1pBMiLjMXjCQP4VB2YldG2PBBuWIoz
dyvDXjlSGJwDHjJRjw1tmN5VijqDjDIrAhDsm0ddzl2b9ZlfdqF5QHF50vA56lbG
iCVd4QtM/eUGrx5nkn0sprhll2XIZZ+2jXNnRZEkTQ==
=5t+O
-END 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

Re: Proposal for every WG to send a short summary *to other WGs directly*

[Miloslav Trmač]

- Original Message -
> I don't have any major objections to this, but I will note that
> reports stopped being sent to FESCo because at some point they were
> kind of redundant.  "Still working on thing X" every week isn't really
> something that needs to be sent.  So I would avoid a weekly deadline
> and maybe just post minutes/summaries of the meetings the groups have
> when there is actually something to communicate.

It seems to me that what we technically need, and what would solve this problem 
as well, is to have the meeting minutes be actually useful.  As great as 
meetbot is, it takes effort to use it to produce really good meeting minutes, 
and the default output has a lot of output that makes everyone’s eyes glaze 
over.

Ultimately the solution to both the reports and meetbot is the same—human 
editing—but I guess that a good summary for other WGs would be more or less 
equivalent to good meeting minutes (assuming that the obviously internal-only 
“implementation status” topics would be easy to recognize and skip)
Mirek
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

[perl-YAML/el5] Fix a couple of bugs

[Paul Howarth]

commit a687d86815f182ffaea9ea7c70f3d1d6d3aace33
Author: Paul Howarth 
Date:   Tue Aug 26 16:02:00 2014 +0100

Fix a couple of bugs

- Fix YAML::Dumper minimum example does not work (#567620, CPAN RT#19838)
- Fix handling of large input data (CPAN RT#90593)
- Drop %defattr, redundant since rpm 4.4
- Don't need to remove empty directories from the buildroot

 .gitignore  |2 +-
 YAML-0.66-rt19838.patch |   39 +++
 YAML-0.66-rt90593.patch |   47 +++
 perl-YAML.spec  |   20 
 4 files changed, 103 insertions(+), 5 deletions(-)
---
diff --git a/.gitignore b/.gitignore
index 293d018..2bd9484 100644
--- a/.gitignore
+++ b/.gitignore
@@ -1 +1 @@
-YAML-0.62.tar.gz
+/YAML-[0-9.]*.tar.gz
diff --git a/YAML-0.66-rt19838.patch b/YAML-0.66-rt19838.patch
new file mode 100644
index 000..17b8996
--- /dev/null
+++ b/YAML-0.66-rt19838.patch
@@ -0,0 +1,39 @@
+diff --git a/lib/YAML/Dumper.pm b/lib/YAML/Dumper.pm
+index c917f2a..6ad63a4 100644
+--- a/lib/YAML/Dumper.pm
 b/lib/YAML/Dumper.pm
+@@ -142,6 +142,7 @@ sub _prewalk {
+ }
+ 
+ # Handle YAML Blessed things
++require YAML;
+ if (defined YAML->global_object()->{blessed_map}{$node_id}) {
+ $value = YAML->global_object()->{blessed_map}{$node_id};
+ $self->transferred->{$node_id} = $value;
+diff --git a/t/dump-synopsis.t b/t/dump-synopsis.t
+new file mode 100644
+index 000..d65c49a
+--- /dev/null
 b/t/dump-synopsis.t
+@@ -0,0 +1,21 @@
++use strict;
++use warnings;
++
++use Test::More tests => 1;
++
++my $success = 0;
++my $err;
++{
++local $@;
++eval {
++require YAML::Dumper;
++my $hash   = {};
++my $dumper = YAML::Dumper->new();
++my $string = $dumper->dump($hash);
++$success = 1;
++};
++$err = $@;
++}
++is( $success, 1, "Basic YAML::Dumper usage worked as expected" )
++  or diag( explain($err) );
++
diff --git a/YAML-0.66-rt90593.patch b/YAML-0.66-rt90593.patch
new file mode 100644
index 000..e1a7fe9
--- /dev/null
+++ b/YAML-0.66-rt90593.patch
@@ -0,0 +1,47 @@
+--- lib/YAML/Loader.pm
 lib/YAML/Loader.pm
+@@ -507,10 +507,27 @@ sub _parse_inline_seq {
+ return $node;
+ }
+ 
++# Work around /regexp/ bug in perl < 5.10
++sub _parse_inline_double_quoted_perl_bug_work_around {
++my $self = shift;
++my @list;
++local $_ = $self->{inline};
++s{^"}{} or croak YAML_PARSE_ERR_BAD_DOUBLE();
++push @list, $1
++while s{^((?:\\.|[^\"\\]+){1,1000})}{};
++s/\\"/"/g for @list;
++s{^"}{} or croak YAML_PARSE_ERR_BAD_DOUBLE();
++$self->{inline} = $_;
++return join("",@list);
++}
++
+ # Parse the inline double quoted string.
+ sub _parse_inline_double_quoted {
+ my $self = shift;
+ my $node;
++# https://rt.cpan.org/Public/Bug/Display.html?id=18195
++return $self->_parse_inline_double_quoted_perl_bug_work_around()
++if length($self->{inline}) > 10_000;
+ if ($self->inline =~ /^"((?:\\"|[^"])*)"\s*(.*)$/) {
+ $node = $1;
+ $self->inline($2);
+--- t/rt-90593.t
 t/rt-90593.t
+@@ -0,0 +1,14 @@
++# https://rt.cpan.org/Public/Bug/Display.html?id=90593
++use Test::More tests => 2;
++
++use YAML;
++use constant LENGTH => 100;
++
++$SIG{__WARN__} = sub { die @_ };
++
++my $yaml = 'x: "' . ('x' x LENGTH) . '"' . "\n";
++
++my $hash = Load $yaml;
++
++is ref($hash), 'HASH', 'Loaded a hash';
++is length($hash->{x}), LENGTH, 'Long scalar loaded';
diff --git a/perl-YAML.spec b/perl-YAML.spec
index ffc9c26..6bac979 100644
--- a/perl-YAML.spec
+++ b/perl-YAML.spec
@@ -1,11 +1,13 @@
 Name:   perl-YAML
 Version:0.66
-Release:2%{?dist}
+Release:3%{?dist}
 Summary:YAML Ain't Markup Language (tm)
 License:GPL+ or Artistic
 Group:  Development/Libraries
 URL:http://search.cpan.org/dist/YAML/
 Source0:http://www.cpan.org/authors/id/I/IN/INGY/YAML-%{version}.tar.gz
+Patch0: YAML-0.66-rt19838.patch
+Patch1: YAML-0.66-rt90593.patch
 BuildRoot:  %{_tmppath}/%{name}-%{version}-%{release}-root-%(%{__id_u} -n)
 BuildArch:  noarch
 BuildRequires:  perl(ExtUtils::MakeMaker)
@@ -23,6 +25,12 @@ specification.
 %prep
 %setup -q -n YAML-%{version}
 
+# Fix YAML::Dumper minimum example does not work (#567620, CPAN RT#19838)
+%patch0 -p1
+
+# Fix handling of large input data (CPAN RT#18195, CPAN RT#90593)
+%patch1
+
 %build
 %{__perl} Makefile.PL INSTALLDIRS=vendor < /dev/null
 make %{?_smp_mflags}
@@ -39,7 +47,6 @@ rm -f $RPM_BUILD_ROOT%{perl_vendorlib}/Test/YAML* \
 $RPM_BUILD_ROOT%{_mandir}/man3/Test::YAML*.3*
 
 find $RPM_BUILD_ROOT -type f -name .packlist -exec rm -f {} \;
-find $RPM_BUILD_ROOT -depth -type d -exec rmdir {} 2>/dev/null \;
 
 %{_fixperms} $RPM_BUILD_ROOT/*
 
@@ -50,7 +57,6 @@ make test
 rm -rf $RPM_BUILD_ROOT
 
 %files
-%defattr(-,root,root,-)
 %doc Changes COM

Re: systemd dependencies

[Rich Mattes]

On Tue, Aug 26, 2014 at 10:46 AM, DJ Delorie  wrote:

>
> > If I saw systemd-filesystem installed, then I would think that
> > something needs to be placed into the systemd folder structure,
>
> Perhaps the bug is this: that you need to install a whole other RPM
> just to make a directory exist so you can put a file in it.
>
> Why can't the RPM providing the file just make the directory and not
> have a dependency at all?
>

As long your package doesn't need the package providing the directory for
normal functionality, there's no reason not to have your package own that
directory[1].  Packages that provide unit files, but are otherwise useful
in the absence of systemd would probably fall into this category.

Rich

[1]
https://fedoraproject.org/wiki/Packaging:Guidelines#The_directory_is_owned_by_a_package_which_is_not_required_for_your_package_to_function
-- 
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: Proposal for every WG to send a short summary *to other WGs directly*

[Ben Cotton]

Isn't this what the meetingminutes mailing list is for? I'd argue that
a better solution is to have regular (not weekly) coordination
meetings where representatives of the WGs can talk about what's going
on and coordinate cross-WG issues.

-- 
Ben Cotton
-- 
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: OCaml 4.02.0+rc1 rebuild (was: Re: Contacting the Ocaml maintainers)

[Jerry James]

On Tue, Aug 26, 2014 at 2:02 AM, Richard W.M. Jones  wrote:
> The script should build them in BuildRequires order automatically.
> However in this case I have blocked frama-c and gappalib-coq because
> they didn't build in the previous round, see:
>
> http://git.annexia.org/?p=goals.git;a=blob;f=fedora_ocaml_rebuild.ml;h=c708223078ddba42b6bd854e3d297f1b0f2ebe8b;hb=HEAD#l25
>
> The script also blocks any dependencies recursively.
>
> If they build now, I can unblock them and their dependencies and rerun
> the script.

I've already rebuilt them, so no need to rerun the script.  And, yes,
they built successfully this time around.

> I'm not very familiar with ocamlbuild.  In fact I didn't and still
> don't agree with it on principle.  Guess we need to ask upstream to
> fix this.

Just for clarification: "we == you" or "we == me"? :-)  Thanks,
-- 
Jerry James
http://www.jamezone.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: systemd dependencies

[Till Maas]

On Tue, Aug 26, 2014 at 12:59:23PM +0200, Vít Ondruch wrote:

> 2) sytemd should consider to provide -filesystem package, which would
> limit the dependency to single small package (but this might be return
> to the -units subpackage days? Not sure).

The directories can probably just be added to the filesystem package.
Opening a bugzilla ticket usually helps here.

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: systemd dependencies

[Chris Adams]

Once upon a time, DJ Delorie  said:
> Perhaps the bug is this: that you need to install a whole other RPM
> just to make a directory exist so you can put a file in it.
> 
> Why can't the RPM providing the file just make the directory and not
> have a dependency at all?

It used to work (more or less) that way.  The problem is when a
directory is supposed to have specific ownership/permission settings,
only the package that actually owns the directory has that configured.
It doesn't make sense to try to put that info in every package (should
the rsync RPM know the permissions of /usr/lib/systemd/system?).

-- 
Chris Adams 
-- 
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: Proposal for every WG to send a short summary *to other WGs directly*

[Kevin Fenzi]

On Tue, 26 Aug 2014 16:46:40 +0200
Honza Horak  wrote:

...snip...

I'm not against each group doing a summary, but as noted by Josh,
sometimes the summaries are very repetitive ( ...still working on
implemeting roles... etc)

> List of proposed MLs to send this summary to:
> ser...@lists.fedoraproject.org
> desk...@lists.fedoraproject.org
> cl...@lists.fedoraproject.org
> env-and-sta...@lists.fedoraproject.org
> devel@lists.fedoraproject.org

This is turning into my new pet peeve. ;) 

Cross posting to bunches of lists is not a good idea, IMHO. 

* It means the person posting the summary has to be subscribed to every
  single list they are sending to. 
* It means if anyone hits reply to all they have to be subscribed to
  every single list or deal with rejections/bounces/moderation. 

I think the best thing would be to mail just one list: devel. 

Failing that, I think the best way we can do cross posting right now is
for people to send seperate copies of an email to each list they want
to post to, follow discussion on all those lists, and then do another
sum up post if there's important feedback from only one list. 

> Comments, ideas or better solutions are welcome as usually, but I
> might be offline until Sunday, so do not expect any answers from me
> in that time :)

Fair enough. 

kevin




signature.asc
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

F21 Alpha Change Freeze

[Dennis Gilmore]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hi all,

As the Fedora 21 schedule[1] states the Alpha change freeze is upon
us and we have a confidence in delivering RC composes. As we are now at
the change freeze bodhi will be enabled for f21 tomorrow morning US
Time. It means all builds will now need an update created and as we are
at Alpha freeze only accepted exceptions[2] will be allowed in. 


we are at the pre beta stage of release, so the Pre-beta[3] stage of the
updates policy applies

Regards

Dennis

[1] http://fedorapeople.org/groups/schedule/f-21/f-21-devel-tasks.html
[2] http://fedoraproject.org/wiki/QA:SOP_freeze_exception_bug_process
[3] http://fedoraproject.org/wiki/Updates_Policy#Pre_Beta
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQIcBAEBAgAGBQJT/Kv6AAoJEH7ltONmPFDRV+YP/1qqQPUqqiC1S5q6Qrj+Uh/E
WZuj1wdEpttYi5tQ0oWn9mcjUL9ZZrb8oqeIxunDM175TRYLKKJ4+wL65gOCH7l/
t4zJjmfCyogWxMLRghw5XK+udgUum7fcs78Cuc/8kG1SYwDLFHwprCIUED7eo9eB
oIT9m/hqrp1ZgGfVcDGARIcN9k8yzQUYucvgSrPCyZGEdaXmnGLP/JOz21pInbKO
jCX+Fy9eveIv/DidxTXRUtIQLt/zH1AKUZ/c81TSm0tp6YoEYfOXfs4IMDm7TYL0
lObHJyaYDpFuEzWcyTvCs5AYjLfLYzwwFZ8GS6iRXdBwfaAPTBduTOIId2zZq4Zd
vVYXfiACTEa0GrElT5CJ6ip3wz1h3rwaL4lbvpkYOmOO4FDGIX9K1nMOqYBfqffD
O/n3EiAoZNJDICgdnJ655LM9ZdVdFnn1tmPbO8wB8ldcmrW4ANK0yWEQz/7EYqn5
PD4NXLdez5CJEH4klkPwGOwVl6JuvgiSqHcnLx/r+CdzOEUjx1usgWPIpf65ZJ18
+KnQHbJgQ27t3IDCQzCNWlq2d2xAy0l4QbYOGnAHSlUvfPW+DfBsxITTiwBvc54L
WoLpg+slhe9nvOhlsMEJ13LC9ooREytevUjXcoQCB9kXFcgdP03rlEpWe+2wBPx7
L7yebc6vHouKWxQrs/n5
=XD30
-END PGP SIGNATURE-
___
devel-announce mailing list
devel-annou...@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel-announce
-- 
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: Self introduction: Valentin Gologuzov

[Yohan Graterol]

Hi Valentin,

Welcome to Fedora, I met Copr in FLOCK 2014 and for me is a great project.

Regards!


Enviado con MailTrack



On Tue, Aug 26, 2014 at 9:27 AM, Valentin Gologuzov 
wrote:

> Hi everybody,
>
> My name is Valentin Gologuzov. I've recently joined Copr project at Red
> Hat.
> Prior I've been using Linux for a long time, but it was primarily debian,
> so the RH/Fedora ecosystem quite new for me. I have 3 year experience of
> backend development in Python, mainly aimed for service high availability
> and performance.
>
> Here is my first package for Fedora: https://bugzilla.redhat.com/
> show_bug.cgi?id=1131616 , it provides python interface to the Copr
> service.
>
> --
> Best regards,
> Gologuzov Valentin.
> --
> 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: systemd dependencies

[Lennart Poettering]

On Tue, 26.08.14 14:55, Vít Ondruch (vondr...@redhat.com) wrote:

>  Just to be clear, systemd-libs is in minimal build root already, so I am
>  not complaining about systemd-libs package, but about systemd package.
> >>> What's the rationale here? I mean, we have so many dependencies, if you
> >>> want to minimize them, you have a lng way to go...
> >> Someone has to start somewhere. It is annoying to install several
> >> packages, when you expect that only one should be installed. And by
> >> coincidence, I met several of systemd dependencies during short period
> >> of time.
> > What I am not getting: what's the point? I mean, systemd is not exactly
> > an optional package in Fedora.
> >
> > You are asking people to split their packages in two, but what's the
> > real reason for that? If the systemd package isn't optional anyway, why
> > is this the dep you start with and asking people to complicate things
> > for?
> 
> Isn't it optional? I am using mock and can build probably every ruby
> package without *systemd* package installed into the build root (I am
> not speaking about *systemd-libs*). But once I install one of man,
> subversion or rsync packages, systemd is suddenly pulled in, why? Why it
> should be?

I am not doubting that one can minimize things, and that currently
systemd ends up being into the build-root quite often. I am just
wondering what the big deal is.

I mean, if it is really the goal of Fedora to minimize deps, and split
everything up like Debian is doing it (where for example every single
library .so must be a .deb of its own), then that's OK, but so far
that's not how Fedora has been doing things. And I am pretty sure if you
want to change that, that you then should go through FESCO first...

Honestly, I kinda like the pragmatism on Fedora, so far, that there's
no need to split up packages into a myriad of mini packges. And I
think that texlive packaging is an absolute disaster, where things are
split up to the maximum possible (> 20% of the packages I have on my
machine now are texlive packages, just because i use latex beamer from
time to time...)

Of course, this kind of pragmatism makes bootstrapping fedora on some
new arch harder, but then again, it conceptually is much easer to grok
for admins what packages do what if there are fewer...

Lennart

-- 
Lennart Poettering, Red Hat
-- 
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: Multiple different licenses for tag in a appdata file

[Erik Schilling]

On 26/08/14 10:42, Richard Hughes wrote:
> On 25 August 2014 20:09, Erik Schilling  wrote:
>> I am being on rawhide here. Is there anything I am doing wrong?
> 
> Rawhide might not be new enough; have you got libappstream-glib >=
> 0.2.5 installed?

No. My Docker rawhide has 0.1.6. So I guess I have to ship the file as
it is for now and add the validator command as soon it is working in the
versions.

Regards,
Erik
-- 
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: systemd dependencies

[Stephen John Smoogen]

On 26 August 2014 10:43, Lennart Poettering  wrote:

> On Tue, 26.08.14 14:55, Vít Ondruch (vondr...@redhat.com) wrote:
>
> >  Just to be clear, systemd-libs is in minimal build root already, so
> I am
> >  not complaining about systemd-libs package, but about systemd
> package.
> > >>> What's the rationale here? I mean, we have so many dependencies, if
> you
> > >>> want to minimize them, you have a lng way to go...
> > >> Someone has to start somewhere. It is annoying to install several
> > >> packages, when you expect that only one should be installed. And by
> > >> coincidence, I met several of systemd dependencies during short period
> > >> of time.
> > > What I am not getting: what's the point? I mean, systemd is not exactly
> > > an optional package in Fedora.
> > >
> > > You are asking people to split their packages in two, but what's the
> > > real reason for that? If the systemd package isn't optional anyway, why
> > > is this the dep you start with and asking people to complicate things
> > > for?
> >
> > Isn't it optional? I am using mock and can build probably every ruby
> > package without *systemd* package installed into the build root (I am
> > not speaking about *systemd-libs*). But once I install one of man,
> > subversion or rsync packages, systemd is suddenly pulled in, why? Why it
> > should be?
>
> I am not doubting that one can minimize things, and that currently
> systemd ends up being into the build-root quite often. I am just
> wondering what the big deal is.
>

So after looking at several different container images kickstarts I notice
they all seem to remove systemd as it is provided by the base systemd of
the system. I don't know if that is the correct method or not, but seems to
be the common practice. So if various services end up relying on systemd
and would be removed in making an image.. what is the proper method?


-- 
Stephen J Smoogen.
-- 
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: Re: systemd dependencies

[José Matos]

On Tuesday 26 August 2014 18:43:22 Lennart Poettering wrote:
> Honestly, I kinda like the pragmatism on Fedora, so far, that there's
> no need to split up packages into a myriad of mini packges. And I
> think that texlive packaging is an absolute disaster, where things are
> split up to the maximum possible (> 20% of the packages I have on my
> machine now are texlive packages, just because i use latex beamer from
> time to time...)

This is an argument that I have seen repetitively in this list.

In my point of view the texlive split is similar to the perl-* or python-* 
packages.

In this case texlive is a meta-package (distribution) that has most of the 
(la)tex packages that can be shipped in Fedora.

To propose just a few texlive packages is similar to to have a few 
meta-packages called perl-extras or python-extras, with python-full, or 
perl-network. If this scheme does not make sense to python, or perl, or any 
other language why does it makes sense to apply it to latex packages?

-- 
José Abílio

-- 
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: systemd dependencies

[Lennart Poettering]

On Tue, 26.08.14 10:44, DJ Delorie (d...@redhat.com) wrote:

> 
> > What's the rationale here? I mean, we have so many dependencies, if
> > you want to minimize them, you have a lng way to go...
> 
> When I bootstrapped Fedora for ARM way back when, I had to deal with
> these dependencies.  A lot.  Finding a minimal set of RPMs to

Well, Fedora is not a distribution that cares about whether it is easily
bootstrappable. It never was a goal to be one. If you want to make it
one, then that's fine, but that'd be something to make an official goal
first, by going through FESCO... 

If you want a distro that is bootstrappable, the way that Gentoo is, or
that Debian tries to be then that's OK. I personally don't think it is
worth the effort though, as we don't have to bootstrap new archs every
other week... 

> cross-compile to get a bootable core was very difficult because of
> dependencies, and managing the path up to koji was a nightmare.  Even
> after that, there were some packages that couldn't be built *at all*
> because of circuilar dependencies or dependencies on them.

Cyclic dependencies are something that so far was accepted in
Fedora. If you want to get rid of that, then make it a Fedora goal...

For many packages getting rid of the cyclic deps would mean having to
build things twice, but I am not sure this is really worth the work...

> So, to all of you who say "oh well" to dependencies... I hate you.
>
> Seriously.  Not only have you made my personal job miserable for a
> while, but you demonstrate the worst traits of engineering.  If
> there's a problem, you don't hide it or just "let it be because we're
> used to it."  You *fix* it.  And you make sure it *stays* fixed.  Take
> some pride in your work!  Do the best you can!  If you're only willing
> to do mediocre work and let problems exist because you can't be
> bothered to fix them, then Fedora will at best be a mediocre product.

You know, some cyclic des might be easy to resolve, but a big chunk
really isn't. And our core OS stuff is full of it. I think you
underestiate the complexity of this. 

Lennart

-- 
Lennart Poettering, Red Hat
-- 
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: systemd dependencies

[Orion Poplawski]

On 08/26/2014 04:59 AM, Vít Ondruch wrote:

Dne 26.8.2014 11:06, Michal Sekletar napsal(a):

On Tue, Aug 26, 2014 at 09:32:26AM +0200, Vít Ondruch wrote:

Hi,

Hi Vít,


Recently I have noticed that systemd package dependency is creeping into
some packages where it is not necessary. subversion [1] or rsync [2] are
good examples. Please consider moving daemon parts into independent
subpackages. When I install rsync/subversion, I am typically interested
just in client side.

At some point in time (F16 IIRC) we had systemd-units package which contained
/etc/rpm/macros.systemd file. Packagers which followed our guidelines used for
example %{unitdir} macro in %files. Hence they added systemd-units to
BuildRequires.

These days systemd-units no longer exists, macro file moved to systemd rpm and
systemd-units is a provided by systemd rpm.


Thank you for insightful explanation.

Nevertheless, if you are using some macro, it is just build time
dependency. I believe that the issue might be due to %{unitdir} folder
ownership. And I see two solutions:

1) Packages which ships unit files should consider to put them into sub
package called either -daemon or -server. And this applies especially to
packages such as man (forgot to mention this one previously), rsync or
subversion. I don't typically use their server features or con jobs or
whatever.


Looks like rsync now has a -daemon sub-package, as you requested, and which I 
think is a good thing.


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

Wish it went with a -server name, as that seems much more common, especially 
for admin configurable services.  Really wish we had more standardized names.


[root@vmrawhide ~]# yum list \*-server | wc -l
137
[root@vmrawhide ~]# yum list \*-daemon | wc -l
30


--
Orion Poplawski
Technical Manager 303-415-9701 x222
NWRA, Boulder/CoRA Office FAX: 303-415-9702
3380 Mitchell Lane   or...@nwra.com
Boulder, CO 80301   http://www.nwra.com


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

Re: systemd dependencies

[Orion Poplawski]

On 08/26/2014 04:59 AM, Vít Ondruch wrote:


2) sytemd should consider to provide -filesystem package, which would
limit the dependency to single small package (but this might be return
to the -units subpackage days? Not sure).


It's not (just) filesystem ownership, it's scriptlet processing:

https://fedoraproject.org/wiki/Packaging:ScriptletSnippets#Macroized_scriptlets_.28Fedora_18.2B.29

so you need systemctl

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

Re: systemd dependencies

[Chris Adams]

Once upon a time, Stephen John Smoogen  said:
> So after looking at several different container images kickstarts I notice
> they all seem to remove systemd as it is provided by the base systemd of
> the system. I don't know if that is the correct method or not, but seems to
> be the common practice. So if various services end up relying on systemd
> and would be removed in making an image.. what is the proper method?

Yeah, saying a spreading systemd dependency is okay because "Fedora uses
systemd" is just IMHO a lazy excuse.  There are deployments like
containers that _don't_ use systemd, and don't want to pull it in.

There is no excuse for something like rsync depending on systemd.  The
majority of rsync usage for most system admins and such (deployment,
backups, etc.) does not use the rsync-as-a-service setup, but is run
over SSH (usually with keys).  I use rsync on the desktop all the time,
and I certainly don't run it is a service there.  The only time I've run
the rsync service was when I ran a public Fedora mirror server.  The
rsync-as-a-service either should be split into a separate subpackage, or
a common package like filesystem should provide the requisite
directories.

Looking at the rsync packaging, it includes the standard (macro provided
I believe) postinstall/preuninstall/postuninstall scripts that also call
systemctl, so in this case, the dep is not just on the directory.  So,
the practical solution is to split rsync into two packages, with an
rsync-service subpackage that has all the systemd integration.

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

[perl-Digest] Perl 5.20 rebuild

[Jitka Plesnikova]

commit 00c58f048eb35548ea1086b2cfc7b3744fc622f0
Author: Jitka Plesnikova 
Date:   Tue Aug 26 19:38:32 2014 +0200

Perl 5.20 rebuild

 perl-Digest.spec |5 -
 1 files changed, 4 insertions(+), 1 deletions(-)
---
diff --git a/perl-Digest.spec b/perl-Digest.spec
index bc59bec..633b2d2 100644
--- a/perl-Digest.spec
+++ b/perl-Digest.spec
@@ -1,6 +1,6 @@
 Name:   perl-Digest
 Version:1.17
-Release:292%{?dist}
+Release:293%{?dist}
 Summary:Modules that calculate message digests
 License:GPL+ or Artistic
 Group:  Development/Libraries
@@ -47,6 +47,9 @@ make test
 %{_mandir}/man3/*
 
 %changelog
+* Tue Aug 26 2014 Jitka Plesnikova  - 1.17-293
+- Perl 5.20 rebuild
+
 * Sat Jun 07 2014 Fedora Release Engineering  
- 1.17-292
 - Rebuilt for https://fedoraproject.org/wiki/Fedora_21_Mass_Rebuild
 
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-de...@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel

Re: systemd dependencies

[Josh Boyer]

On Tue, Aug 26, 2014 at 1:38 PM, Chris Adams  wrote:
> Once upon a time, Stephen John Smoogen  said:
>> So after looking at several different container images kickstarts I notice
>> they all seem to remove systemd as it is provided by the base systemd of
>> the system. I don't know if that is the correct method or not, but seems to
>> be the common practice. So if various services end up relying on systemd
>> and would be removed in making an image.. what is the proper method?
>
> Yeah, saying a spreading systemd dependency is okay because "Fedora uses
> systemd" is just IMHO a lazy excuse.  There are deployments like
> containers that _don't_ use systemd, and don't want to pull it in.

Yeah, that's a fair point.

> There is no excuse for something like rsync depending on systemd.  The
> majority of rsync usage for most system admins and such (deployment,
> backups, etc.) does not use the rsync-as-a-service setup, but is run
> over SSH (usually with keys).  I use rsync on the desktop all the time,
> and I certainly don't run it is a service there.  The only time I've run
> the rsync service was when I ran a public Fedora mirror server.  The
> rsync-as-a-service either should be split into a separate subpackage, or
> a common package like filesystem should provide the requisite
> directories.
>
> Looking at the rsync packaging, it includes the standard (macro provided
> I believe) postinstall/preuninstall/postuninstall scripts that also call
> systemctl, so in this case, the dep is not just on the directory.  So,
> the practical solution is to split rsync into two packages, with an
> rsync-service subpackage that has all the systemd integration.

Would you be willing to craft a patch and send it to the rsync
maintainer to do that?

josh
-- 
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: systemd dependencies

[Chris Adams]

Once upon a time, Josh Boyer  said:
> Would you be willing to craft a patch and send it to the rsync
> maintainer to do that?

I believe (later in this thread) someone said that has already been
done, as "rsync-daemon".
-- 
Chris Adams 
-- 
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: systemd dependencies

[Josh Boyer]

On Tue, Aug 26, 2014 at 1:56 PM, Chris Adams  wrote:
> Once upon a time, Josh Boyer  said:
>> Would you be willing to craft a patch and send it to the rsync
>> maintainer to do that?
>
> I believe (later in this thread) someone said that has already been
> done, as "rsync-daemon".

Excellent.  Missed that.  Thank you.

josh
-- 
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: systemd dependencies

[Peter Robinson]

>> > What's the rationale here? I mean, we have so many dependencies, if
>> > you want to minimize them, you have a lng way to go...
>>
>> When I bootstrapped Fedora for ARM way back when, I had to deal with
>> these dependencies.  A lot.  Finding a minimal set of RPMs to
>
> Well, Fedora is not a distribution that cares about whether it is easily
> bootstrappable. It never was a goal to be one. If you want to make it
> one, then that's fine, but that'd be something to make an official goal
> first, by going through FESCO...
>
> If you want a distro that is bootstrappable, the way that Gentoo is, or
> that Debian tries to be then that's OK. I personally don't think it is
> worth the effort though, as we don't have to bootstrap new archs every
> other week...

I believe that's something that the Base working group is actually
actively trying to achieve, Phil or one of the members might be able
to comment further on their exact plans for this.

>> cross-compile to get a bootable core was very difficult because of
>> dependencies, and managing the path up to koji was a nightmare.  Even
>> after that, there were some packages that couldn't be built *at all*
>> because of circuilar dependencies or dependencies on them.
>
> Cyclic dependencies are something that so far was accepted in
> Fedora. If you want to get rid of that, then make it a Fedora goal...
>
> For many packages getting rid of the cyclic deps would mean having to
> build things twice, but I am not sure this is really worth the work...

Well if you can set a boostrap flag in the distro, run a set of
builds, unset the flag, bump and rebuild it's really not that much
work,

>> So, to all of you who say "oh well" to dependencies... I hate you.
>>
>> Seriously.  Not only have you made my personal job miserable for a
>> while, but you demonstrate the worst traits of engineering.  If
>> there's a problem, you don't hide it or just "let it be because we're
>> used to it."  You *fix* it.  And you make sure it *stays* fixed.  Take
>> some pride in your work!  Do the best you can!  If you're only willing
>> to do mediocre work and let problems exist because you can't be
>> bothered to fix them, then Fedora will at best be a mediocre product.
>
> You know, some cyclic des might be easy to resolve, but a big chunk
> really isn't. And our core OS stuff is full of it. I think you
> underestiate the complexity of this.

There's actually been some analysis done of this and people are
actively working to reduce them.

Peter
-- 
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: OCaml 4.02.0+rc1 rebuild (was: Re: Contacting the Ocaml maintainers)

[Richard W.M. Jones]

On Tue, Aug 26, 2014 at 09:12:34AM -0600, Jerry James wrote:
> On Tue, Aug 26, 2014 at 2:02 AM, Richard W.M. Jones  wrote:
> > The script should build them in BuildRequires order automatically.
> > However in this case I have blocked frama-c and gappalib-coq because
> > they didn't build in the previous round, see:
> >
> > http://git.annexia.org/?p=goals.git;a=blob;f=fedora_ocaml_rebuild.ml;h=c708223078ddba42b6bd854e3d297f1b0f2ebe8b;hb=HEAD#l25
> >
> > The script also blocks any dependencies recursively.
> >
> > If they build now, I can unblock them and their dependencies and rerun
> > the script.
> 
> I've already rebuilt them, so no need to rerun the script.  And, yes,
> they built successfully this time around.
> 
> > I'm not very familiar with ocamlbuild.  In fact I didn't and still
> > don't agree with it on principle.  Guess we need to ask upstream to
> > fix this.
> 
> Just for clarification: "we == you" or "we == me"? :-)  Thanks,

Go for it if you have time.  If not then I'll ask in a few days.

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: systemd dependencies

[Yaakov Selkowitz]

On 2014-08-26 11:55, Lennart Poettering wrote:

Well, Fedora is not a distribution that cares about whether it is easily
bootstrappable. It never was a goal to be one. If you want to make it
one, then that's fine, but that'd be something to make an official goal
first, by going through FESCO...

If you want a distro that is bootstrappable, the way that Gentoo is, or
that Debian tries to be then that's OK. I personally don't think it is
worth the effort though, as we don't have to bootstrap new archs every
other week...


Both aarch64 and ppc64le were introduced in a relatively short amount of 
time.  As someone who helped bootstrap a new platform (and a relatively 
obscure one at that) last year, the last thing we need to do is make 
this process harder than necessary.


--
Yaakov Selkowitz
Associate Software Engineer, ARM
Red Hat, Inc.
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Mongo client in Rawhide

[Pete Zaitcev]

Guys, does anyone know what's up with this (in mock_output.log):

...
Start: build setup for iwhd-1.6-12.fc22.src.rpm
ERROR: 
Exception(/var/tmp/koji/tasks/6322/7456322/local/work/cli-build/1409089719.76847.osWulSbq/iwhd-1.6-12.fc22.src.rpm)
 Config(f22-build-2326357-414230) 0 minutes 1 seconds
INFO: Results and/or logs in: /var/lib/mock/f22-build-2326357-414230/result
ERROR: Command failed: 
 # ['/usr/bin/yum-builddep', '--installroot', 
'/var/lib/mock/f22-build-2326357-414230/root/', 
'/var/lib/mock/f22-build-2326357-414230/root///builddir/build/SRPMS/iwhd-1.6-12.fc22.src.rpm',
 '--setopt=tsflags=nocontexts']
Getting requirements for iwhd-1.6-12.fc22.src
 --> autoconf-2.69-15.fc21.noarch
 --> automake-1.14.1-4.fc21.noarch
 --> bison-3.0.2-3.fc22.x86_64
 --> boost-devel-1.55.0-4.fc22.x86_64
 --> boost-filesystem-1.55.0-4.fc22.x86_64
 --> flex-2.5.37-8.fc22.x86_64
 --> gc-devel-7.4.2-2.fc22.x86_64
 --> hail-devel-0.8-0.16.gf9c5b967.fc22.x86_64
 --> help2man-1.46.1-1.fc22.noarch
 --> jansson-devel-2.6-4.fc21.x86_64
 --> libcurl-devel-7.37.1-3.fc22.x86_64
 --> libmicrohttpd-devel-0.9.34-4.fc22.x86_64
 --> liboauth-devel-1.0.3-3.fc22.x86_64
 --> libuuid-devel-2.25-4.fc22.x86_64
 --> libxml2-devel-2.9.1-5.fc22.x86_64
 --> mongodb-server-2.6.3-2.fc22.x86_64
 --> systemd-216-2.fc22.x86_64
Error: No Package found for mongodb-devel

I didn't see any changes in Mongo announced for F22, am I missing
something?

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

Schedule for Wednesday's FESCo Meeting (2014-08-27)

[Kevin Fenzi]

Following is the list of topics that will be discussed in the FESCo
meeting Wednesday at 17:00UTC in #fedora-meeting on irc.freenode.net.

To convert UTC to your local time, take a look at
  http://fedoraproject.org/wiki/UTCHowto

or run:
  date -d '2014-08-27 17:00 UTC'

Links to all tickets below can be found at: 
https://fedorahosted.org/fesco/report/9

= Followups =

#topic #1178 Fedora 21 scheduling strategy
.fesco 1178
https://fedorahosted.org/fesco/ticket/1178

#topic #1322 F21 Changes - Progress on Changes Freeze
.fesco 1322
https://fedorahosted.org/fesco/ticket/1322

#topic #1332 retire orphan packags after 4 weeks instead of once per release
.fesco 1332
https://fedorahosted.org/fesco/ticket/1332

= New business =

#topic #1336 - 32 bit ppc support
.fesco 1336
https://fedorahosted.org/fesco/ticket/1336

= Open Floor = 

For more complete details, please visit each individual ticket.  The
report of the agenda items can be found at
https://fedorahosted.org/fesco/report/9

If you would like to add something to this agenda, you can reply to
this e-mail, file a new ticket at https://fedorahosted.org/fesco,
e-mail me directly, or bring it up at the end of the meeting, during
the open floor topic. Note that added topics may be deferred until
the following meeting. 


signature.asc
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

[perl-Sys-Mmap] Perl 5.20 rebuild

[Jitka Plesnikova]

commit 2cda3bfbbe923f237b5219e3ffc4aa16d8823c51
Author: Jitka Plesnikova 
Date:   Wed Aug 27 00:06:22 2014 +0200

Perl 5.20 rebuild

 perl-Sys-Mmap.spec |5 -
 1 files changed, 4 insertions(+), 1 deletions(-)
---
diff --git a/perl-Sys-Mmap.spec b/perl-Sys-Mmap.spec
index 654aae2..bb1caab 100644
--- a/perl-Sys-Mmap.spec
+++ b/perl-Sys-Mmap.spec
@@ -1,6 +1,6 @@
 Name:   perl-Sys-Mmap
 Version:0.14
-Release:15%{?dist}
+Release:16%{?dist}
 Summary:Use mmap to map in a file as a Perl variable
 License:GPL+ or Artistic
 Group:  Development/Libraries
@@ -43,6 +43,9 @@ make test
 %{_mandir}/man3/*
 
 %changelog
+* Tue Aug 26 2014 Jitka Plesnikova  - 0.14-16
+- Perl 5.20 rebuild
+
 * Sun Aug 17 2014 Fedora Release Engineering  
- 0.14-15
 - Rebuilt for https://fedoraproject.org/wiki/Fedora_21_22_Mass_Rebuild
 
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-de...@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel

Re: systemd dependencies

[Zbigniew Jędrzejewski-Szmek]

On Tue, Aug 26, 2014 at 10:16:46AM -0500, Chris Adams wrote:
> Once upon a time, DJ Delorie  said:
> > Perhaps the bug is this: that you need to install a whole other RPM
> > just to make a directory exist so you can put a file in it.
> > 
> > Why can't the RPM providing the file just make the directory and not
> > have a dependency at all?
> 
> It used to work (more or less) that way.  The problem is when a
> directory is supposed to have specific ownership/permission settings,
> only the package that actually owns the directory has that configured.
> It doesn't make sense to try to put that info in every package (should
> the rsync RPM know the permissions of /usr/lib/systemd/system?).
/usr/lib/systemd/system does not require any special mode. We actually
now warn about files with anything but rw-rw-r-- mode. This is very
unlikely to change.

The reason for dependency on systemd is different: if a package carries
a systemd unit, it should usually be enabled according to presets. It
should also be cleaned up when the package is removed. This requires
a dependency on systemd which carries the preset settings and utilities
to do this.

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

Re: Mongo client in Rawhide

[Sérgio Basto]

On Ter, 2014-08-26 at 15:57 -0600, Pete Zaitcev wrote: 
> Guys, does anyone know what's up with this (in mock_output.log):
> 
> ...
> Start: build setup for iwhd-1.6-12.fc22.src.rpm
> ERROR: 
> Exception(/var/tmp/koji/tasks/6322/7456322/local/work/cli-build/1409089719.76847.osWulSbq/iwhd-1.6-12.fc22.src.rpm)
>  Config(f22-build-2326357-414230) 0 minutes 1 seconds
> INFO: Results and/or logs in: /var/lib/mock/f22-build-2326357-414230/result
> ERROR: Command failed: 
>  # ['/usr/bin/yum-builddep', '--installroot', 
> '/var/lib/mock/f22-build-2326357-414230/root/', 
> '/var/lib/mock/f22-build-2326357-414230/root///builddir/build/SRPMS/iwhd-1.6-12.fc22.src.rpm',
>  '--setopt=tsflags=nocontexts']
> Getting requirements for iwhd-1.6-12.fc22.src
>  --> autoconf-2.69-15.fc21.noarch
>  --> automake-1.14.1-4.fc21.noarch
>  --> bison-3.0.2-3.fc22.x86_64
>  --> boost-devel-1.55.0-4.fc22.x86_64
>  --> boost-filesystem-1.55.0-4.fc22.x86_64
>  --> flex-2.5.37-8.fc22.x86_64
>  --> gc-devel-7.4.2-2.fc22.x86_64
>  --> hail-devel-0.8-0.16.gf9c5b967.fc22.x86_64
>  --> help2man-1.46.1-1.fc22.noarch
>  --> jansson-devel-2.6-4.fc21.x86_64
>  --> libcurl-devel-7.37.1-3.fc22.x86_64
>  --> libmicrohttpd-devel-0.9.34-4.fc22.x86_64
>  --> liboauth-devel-1.0.3-3.fc22.x86_64
>  --> libuuid-devel-2.25-4.fc22.x86_64
>  --> libxml2-devel-2.9.1-5.fc22.x86_64
>  --> mongodb-server-2.6.3-2.fc22.x86_64
>  --> systemd-216-2.fc22.x86_64
> Error: No Package found for mongodb-devel
> 
> I didn't see any changes in Mongo announced for F22, am I missing
> something?

[1] mongodb-2.6.3-1.fc22 doesn't exist  so I guess mass rebuild bring
mongodb-2.6.3-2 to rawhide , and build doesn't have mongodb-devel [2]
and build before was for mongodb-2.4 ...


[1] http://koji.fedoraproject.org/koji/packageinfo?packageID=10883

[2] http://koji.fedoraproject.org/koji/buildinfo?buildID=562176


-- 
Sérgio M. B.

-- 
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: Mongo client in Rawhide

[Peter Robinson]

On Tue, Aug 26, 2014 at 11:41 PM, Sérgio Basto  wrote:
> On Ter, 2014-08-26 at 15:57 -0600, Pete Zaitcev wrote:
>> Guys, does anyone know what's up with this (in mock_output.log):
>>
>> ...
>> Start: build setup for iwhd-1.6-12.fc22.src.rpm
>> ERROR: 
>> Exception(/var/tmp/koji/tasks/6322/7456322/local/work/cli-build/1409089719.76847.osWulSbq/iwhd-1.6-12.fc22.src.rpm)
>>  Config(f22-build-2326357-414230) 0 minutes 1 seconds
>> INFO: Results and/or logs in: /var/lib/mock/f22-build-2326357-414230/result
>> ERROR: Command failed:
>>  # ['/usr/bin/yum-builddep', '--installroot', 
>> '/var/lib/mock/f22-build-2326357-414230/root/', 
>> '/var/lib/mock/f22-build-2326357-414230/root///builddir/build/SRPMS/iwhd-1.6-12.fc22.src.rpm',
>>  '--setopt=tsflags=nocontexts']
>> Getting requirements for iwhd-1.6-12.fc22.src
>>  --> autoconf-2.69-15.fc21.noarch
>>  --> automake-1.14.1-4.fc21.noarch
>>  --> bison-3.0.2-3.fc22.x86_64
>>  --> boost-devel-1.55.0-4.fc22.x86_64
>>  --> boost-filesystem-1.55.0-4.fc22.x86_64
>>  --> flex-2.5.37-8.fc22.x86_64
>>  --> gc-devel-7.4.2-2.fc22.x86_64
>>  --> hail-devel-0.8-0.16.gf9c5b967.fc22.x86_64
>>  --> help2man-1.46.1-1.fc22.noarch
>>  --> jansson-devel-2.6-4.fc21.x86_64
>>  --> libcurl-devel-7.37.1-3.fc22.x86_64
>>  --> libmicrohttpd-devel-0.9.34-4.fc22.x86_64
>>  --> liboauth-devel-1.0.3-3.fc22.x86_64
>>  --> libuuid-devel-2.25-4.fc22.x86_64
>>  --> libxml2-devel-2.9.1-5.fc22.x86_64
>>  --> mongodb-server-2.6.3-2.fc22.x86_64
>>  --> systemd-216-2.fc22.x86_64
>> Error: No Package found for mongodb-devel
>>
>> I didn't see any changes in Mongo announced for F22, am I missing
>> something?
>
> [1] mongodb-2.6.3-1.fc22 doesn't exist  so I guess mass rebuild bring
> mongodb-2.6.3-2 to rawhide , and build doesn't have mongodb-devel [2]
> and build before was for mongodb-2.4 ...

I suspect the maintainer pushed 2.6.3 and didn't build it or deal with
any of the collateral and when the mass rebuild came through it built
it. I've added Jan to the cc: so he's aware of the issue.

Peter
-- 
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: systemd dependencies

[Zbigniew Jędrzejewski-Szmek]

On Tue, Aug 26, 2014 at 07:15:46PM +0100, Peter Robinson wrote:
> >> > What's the rationale here? I mean, we have so many dependencies, if
> >> > you want to minimize them, you have a lng way to go...
> >>
> >> When I bootstrapped Fedora for ARM way back when, I had to deal with
> >> these dependencies.  A lot.  Finding a minimal set of RPMs to
> >
> > Well, Fedora is not a distribution that cares about whether it is easily
> > bootstrappable. It never was a goal to be one. If you want to make it
> > one, then that's fine, but that'd be something to make an official goal
> > first, by going through FESCO...
> >
> > If you want a distro that is bootstrappable, the way that Gentoo is, or
> > that Debian tries to be then that's OK. I personally don't think it is
> > worth the effort though, as we don't have to bootstrap new archs every
> > other week...
> 
> I believe that's something that the Base working group is actually
> actively trying to achieve, Phil or one of the members might be able
> to comment further on their exact plans for this.

I think splitting out a subpackage (let's call it systemd-filesystem
for now) to reduce the dependencies would be useful. But it would have
to be done properly, in a way that behaviour is preserved,
i.e. that macros provided by /usr/lib/rpm/macros.d/macros.systemd
continue to do something sensible. Currently the dependency ensures
that when the system is bootstrapped, those packages are installed
after systemd. The macros would have to be modified to give an identical
result if systemd is installed later.

Looking at the list, those macros call udevadm, journalctl,
systemd-tmpfiles, systemd-sysusers, systemd-sysctl, systemd-binfmt. If
systemd was not installed the calls to systemctl stop/daemon-reload/try-restart
and udevadm control should become noops. Calls to systemd-binfmt, 
systemd-sysctl,
systemd-tmpfiles --create can be noops too,
with the understanding that the functionality will not be available
until systemd is installed and those services (systemd-tmpfiles.service,
systemd-binfmt.service, systemd-sysctl.service) are started.
Calls to systemctl preset/disable and udevadm hwdb --update,
systemd-sysusers, journalctl --update-catalog would have to tweaked so
that they run without systemd. They already either do that or support
that functionality with some switches, so it would be possible to
tweak the macros to do that. If systemd was installed later, it
would pick up the updated configuration from the filesystem.

I'm rejecting the idea of reimplementing the functionality. I think it
only makes sense is possible with existing binaries.

With this assumption, it seems feasible to split out
"systemd-filesystem", but it would have to contain systemctl,
journalctl, udevadm, and systemd-sysusers binaries. It's hard to say
exactly what dependencies would be shared with the main package, but
probably almost all of the libraries, including cryptographic and
compression and selinux... So I think that the savings would be
modest. Probably the most important: dbus, pam, seccomp, audit.

Also, this would not help the problem with arch bootstrapping, since
everything would still be built from one source package.

I'm not sure if people would still find that useful.

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

[Test-Announce] 2014-08-27 @ 16:00 UTC ** F21 Blocker Review

[Mike Ruckman]

# F21 Blocker Review meeting
# Date: 2014-08-27
# Time: 16:00 UTC (12:00 EDT, 09:00 PDT)
# Location: #fedora-blocker-review on irc.freenode.net

Greetings testers! It's time again tomorrow for another blocker review meeting!
Currently there are 4 proposed blockers, but more can certainly be reported
before the meeting.

If you want to take a look at the accepted blockers, the full list can be found
here: https://qa.fedoraproject.org/blockerbugs/milestone/21/alpha/buglist

We'll be evaluating these bugs to see if they violate the Alpha
Release Criteria and warrant the blocking of a release if they're not
fixed. Information on the release criteria for F21 can be found on the
wiki [0]. Product specific plans are still being solidified, but that
should be sorted quickly.

For more information about the Blocker and Freeze exception process,
check out these links:
  - https://fedoraproject.org/wiki/QA:SOP_blocker_bug_process
  - https://fedoraproject.org/wiki/QA:SOP_freeze_exception_bug_process

And for those of you who are curious how a Blocker Review Meeting
works - or how it's supposed to go - check out the SOP on the wiki:
  - https://fedoraproject.org/wiki/QA:SOP_Blocker_Bug_Meeting

See you tomorrow!

[0] https://fedoraproject.org/wiki/Fedora_Release_Criteria

-- 
// Mike 
--
Fedora QA
freenode: roshi
http://roshi.fedorapeople.org
___
test-announce mailing list
test-annou...@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/test-announce
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: systemd dependencies

[Tomasz Torcz]

On Wed, Aug 27, 2014 at 12:38:20AM +0200, Zbigniew Jędrzejewski-Szmek wrote:
> The reason for dependency on systemd is different: if a package carries
> a systemd unit, it should usually be enabled according to presets. It
> should also be cleaned up when the package is removed. This requires
> a dependency on systemd which carries the preset settings and utilities
> to do this.

  Maybe better place for presets would be fedora-release-* package?

-- 
Tomasz Torcz"Funeral in the morning, IDE hacking
xmpp: zdzich...@chrome.plin the afternoon and evening." - Alan Cox

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