Re: Build control-center in mock fail

[Björn Persson]

Nico Kadel-Garcia wrote:
> On Sat, May 25, 2013 at 1:14 PM, Kevin Fenzi  wrote:
> > I'm sure we could ask the FPC to add this to guidelines.
> > I've filed such a ticket, please feel free to add comments:
> >
> > https://fedorahosted.org/fpc/ticket/295
> 
> It's reasonable, but is missing an important feature. "All source
> materials for the RPM must also be contained in the new SRPM,
> preferably as source material." This creates a preference for source
> rather than .jar, .war, or .gem files, but I think that's really
> desirable.

The requirement to build from source is already explicit:

https://fedoraproject.org/wiki/Packaging:Guidelines#No_inclusion_of_pre-built_binaries_or_libraries

Björn Persson


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

Re: Build control-center in mock fail

[Nico Kadel-Garcia]

On Sat, May 25, 2013 at 1:14 PM, Kevin Fenzi  wrote:
> On Sat, 25 May 2013 11:15:22 -0400
> Nico Kadel-Garcia  wrote:
>
>> [ Sorry for the late reply, I've been at a family funeral this week. ]
>
> :(
>
>> That's very specific to the Fedora build environment. Difficult to
>> replicate in the field without a huge local build structure! And
>> enforced by a specific build environment is nowhere near the same
>> thing as "mandated by published policy" to help SRPM builders know how
>> they should plan their work.
>
> ...snip...
>
> I'm sure we could ask the FPC to add this to guidelines.
> I've filed such a ticket, please feel free to add comments:
>
> https://fedorahosted.org/fpc/ticket/295
>
> kevin

It's reasonable, but is missing an important feature. "All source
materials for the RPM must also be contained in the new SRPM,
preferably as source material." This creates a preference for source
rather than .jar, .war, or .gem files, but I think that's really
desirable.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Package EVR problems in Fedora 2013-05-25

[buildsys]

Broken upgrade path report for tags f19 -> f20:
R-RUnit:
f19 > f20 (R-RUnit-0.4.26-7.fc19 R-RUnit-0.4.26-6.fc20)

R-Rcompression:
f19 > f20 (R-Rcompression-0.93.2-8.fc19 R-Rcompression-0.93.2-7.fc20)

R-zoo:
f19 > f20 (R-zoo-1.7.9-1.fc19 R-zoo-1.7.6-5.fc20)

bind10:
f19 > f20 (bind10-1.0.0-2.fc19 bind10-1.0.0-1.fc19)

converseen:
f19 > f20 (converseen-0.6-1.fc19 converseen-0.5.3-2.fc20)

drupal7-backup_migrate:
f19 > f20 (drupal7-backup_migrate-2.5-1.fc19 
drupal7-backup_migrate-2.4-3.fc19)

drupal7-ctools:
f19 > f20 (drupal7-ctools-1.3-1.fc19 drupal7-ctools-1.2-2.fc19)

emacs-identica-mode:
f19 > f20 (emacs-identica-mode-1.2.1-5.fc19 
emacs-identica-mode-1.2.1-4.fc19)

erlang-eleveldb:
f19 > f20 (erlang-eleveldb-1.3.0-2.fc19 erlang-eleveldb-1.3.0-1.fc19)

etoys:
f19 > f20 (etoys-5.0.2408-5.fc19 etoys-5.0.2408-4.fc19)

facter:
f19 > f20 (facter-1.6.18-3.fc19 facter-1.6.18-2.fc20)

firefox:
f19 > f20 (firefox-21.0-3.fc19 firefox-20.0-5.fc20)

gdesklets:
f19 > f20 (gdesklets-0.36.3-11.fc19 gdesklets-0.36.3-10.fc20)

gimp-normalmap:
f19 > f20 (gimp-normalmap-1.2.3-4.fc19 gimp-normalmap-1.2.3-3.fc19)

gluegen2:
f19 > f20 (gluegen2-2.0-0.8.rc11.fc19 gluegen2-2.0-0.7.rc11.fc19)

gnome-desktop3:
f19 > f20 (gnome-desktop3-3.8.2-2.fc19 gnome-desktop3-3.8.2-1.fc20)

gnome-initial-setup:
f19 > f20 (gnome-initial-setup-0.10-3.fc19 gnome-initial-setup-0.9-2.fc20)

gobby:
f19 > f20 (gobby-0.4.12-11.fc19 gobby-0.4.12-10.fc19)

ibus-hangul:
f19 > f20 (ibus-hangul-1.4.2-4.fc19 ibus-hangul-1.4.2-3.fc20)

icedtea-web:
f19 > f20 (icedtea-web-1.4-0.fc19 icedtea-web-1.3.1-5.fc19)

jogl2:
f19 > f20 (jogl2-2.0-0.8.rc11.fc19 jogl2-2.0-0.7.rc11.fc19)

keepalived:
f19 > f20 (keepalived-1.2.7-5.fc19 keepalived-1.2.7-4.fc19)

kscreen:
f19 > f20 (1:kscreen-0.0.92-1.fc19 1:kscreen-0.0.81-1.fc20)

libXext:
f19 > f20 (libXext-1.3.1-4.fc19 libXext-1.3.1-3.20130524gitdfe6e1f3b.fc20)

libgsf:
f19 > f20 (libgsf-1.14.26-4.fc19 libgsf-1.14.26-2.fc20)

lightdm:
f19 > f20 (lightdm-1.6.0-8.fc19 lightdm-1.6.0-4.fc20)

mate-session-manager:
f19 > f20 (mate-session-manager-1.6.0-3.fc19 
mate-session-manager-1.6.0-2.fc20)

nesc:
f19 > f20 (nesc-1.3.4-4.fc19 nesc-1.3.4-3.fc19)

ninja-ide:
f19 > f20 (ninja-ide-2.2-1.fc19 ninja-ide-2.1.1-5.fc19)

olpc-os-builder:
f19 > f20 (olpc-os-builder-6.0.0-1.fc19 olpc-os-builder-5.0.1-2.fc19)

openstack-packstack:
f19 > f20 (openstack-packstack-2013.1.1-0.3.dev527.fc19 
openstack-packstack-2012.2.2-0.9.dev406.fc19)

openstack-swift:
f19 > f20 (openstack-swift-1.8.0-2.fc19 openstack-swift-1.8.0-1.fc20)

perl-Locale-Maketext-Gettext:
f19 > f20 (perl-Locale-Maketext-Gettext-1.27-12.fc19 
perl-Locale-Maketext-Gettext-1.27-10.fc19)

pygobject3:
f19 > f20 (pygobject3-3.8.1-2.fc19 pygobject3-3.8.1-1.fc20)

pynag:
f19 > f20 (pynag-0.4.9-1.fc19 pynag-0.4.8-2.fc19)

rygel:
f19 > f20 (rygel-0.18.2-1.fc19 rygel-0.18.1-1.fc20)

satyr:
f19 > f20 (satyr-0.3-2.fc19 satyr-0.3-1.fc20)

seamonkey:
f19 > f20 (seamonkey-2.17.1-1.fc19 seamonkey-2.17-1.fc20)

squeak-vm:
f19 > f20 (squeak-vm-4.10.2.2614-7.fc19 squeak-vm-4.10.2.2614-6.fc19)

tboot:
f19 > f20 (1:tboot-1.7.3-3.fc19 1:tboot-1.7.3-2.fc19)

uwsgi:
f19 > f20 (uwsgi-1.9.8-0.fc19 uwsgi-1.2.6-10.fc20)

xulrunner:
f19 > f20 (xulrunner-21.0-4.fc19 xulrunner-20.0-4.fc20)

---
Broken paths by builder:
asrob:
drupal7-backup_migrate:
f19 > f20 (drupal7-backup_migrate-2.5-1.fc19 
drupal7-backup_migrate-2.4-3.fc19)
drupal7-ctools:
f19 > f20 (drupal7-ctools-1.3-1.fc19 drupal7-ctools-1.2-2.fc19)

atkac:
bind10:
f19 > f20 (bind10-1.0.0-2.fc19 bind10-1.0.0-1.fc19)

buc:
seamonkey:
f19 > f20 (seamonkey-2.17.1-1.fc19 seamonkey-2.17-1.fc20)

caolanm:
libgsf:
f19 > f20 (libgsf-1.14.26-4.fc19 libgsf-1.14.26-2.fc20)

comzeradd:
ninja-ide:
f19 > f20 (ninja-ide-2.2-1.fc19 ninja-ide-2.1.1-5.fc19)

davidcl:
gluegen2:
f19 > f20 (gluegen2-2.0-0.8.rc11.fc19 gluegen2-2.0-0.7.rc11.fc19)
jogl2:
f19 > f20 (jogl2-2.0-0.8.rc11.fc19 jogl2-2.0-0.7.rc11.fc19)

derekh:
openstack-packstack:
f19 > f20 (openstack-packstack-2013.1.1-0.3.dev527.fc19 
openstack-packstack-2012.2.2-0.9.dev406.fc19)
openstack-swift:
f19 > f20 (openstack-swift-1.8.0-2.fc19 openstack-swift-1.8.0-1.fc20)

dsd:
etoys:
f19 > f20 (etoys-5.0.2408-5.fc19 etoys-5.0.2408-4.fc19)
olpc-os-builder:
f19 > f20 (olpc-os-builder-6.0.0-1.fc19 olpc-os-builder-5.0.1-2.fc19)
squeak-vm:
f19 > f20 (squeak-vm-4.10.2.2614-7.fc19 squeak-vm-4.10.2.2614-6.fc19)

dvratil:
kscreen:
f19 > f20 (1:kscreen-0.0.92-1.fc19 1:kscreen-0.0.81-1.fc20)

gwei3:
tboot:
f19 > f20 (1:tboot-1.7.3-3.fc19 1:tboot-1.7.3-2.fc19)

jvanek:
icedtea-web:
f19 > f20 (icedtea-web-1.4-0.fc19 icedtea-web-1.3.1-5.fc19)

kad:
   

Re: Build control-center in mock fail

[Kevin Fenzi]

On Sat, 25 May 2013 11:15:22 -0400
Nico Kadel-Garcia  wrote:

> [ Sorry for the late reply, I've been at a family funeral this week. ]

:( 

> That's very specific to the Fedora build environment. Difficult to
> replicate in the field without a huge local build structure! And
> enforced by a specific build environment is nowhere near the same
> thing as "mandated by published policy" to help SRPM builders know how
> they should plan their work.

...snip...

I'm sure we could ask the FPC to add this to guidelines.
I've filed such a ticket, please feel free to add comments: 

https://fedorahosted.org/fpc/ticket/295

kevin


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

Re: Software Management call for RFEs

[Kevin Fenzi]

On Sat, 25 May 2013 01:42:44 +0300
Oron Peled  wrote:

> I think you missed the whole point of Debian's multi-arch -- instead
> of special handling for "sister" architectures (e.g: x86/x86_64), or
> proving there aren't (e.g: aarch64/armv7) -- it creates a symmetric
> world.
> 
> The *huge* benefit of multi-arch is to people that *cross-compile*.

...snip...

>  * This means cross-toolchains becomes first class citizens.

I understand that some people cross compile, and that's nice, but I'm
not convinced it's important enough a use case to rearrange lots of
things with all the pain involved. 

Since I've not actually used debian in years, I'll bow out of this
discussion now. ;) 

kevin


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

Re: Software Management call for RFEs

[Ralf Corsepius]

On 05/24/2013 09:26 AM, Michael Scherer wrote:

Le vendredi 24 mai 2013 à 07:08 +0200, Ralf Corsepius a écrit :

On 05/23/2013 06:05 PM, Simone Caronni wrote:

On 23 May 2013 17:38, James Antill mailto:ja...@fedoraproject.org>> wrote:

 On Thu, 2013-05-23 at 13:52 +0200, Simone Caronni wrote:
  > mv /etc/nagios/nagios.cfg /etc/nagios/nagios.cfg.mine
  > yum reinstall nagios --onlyfile /etc/nagios/nagios.cfg

   How is this functionally different from "yum reinstall nagios" ?
   Yes, yum/rpm will currently replace files with identical copies but
 functionally the extra copies are "just wasting reinstall time".


By doing "yum reinstall nagios" I don't have the the default config
files (i.e. nagios.cfg.rpmnew is not created). This happens only on
upgrades.


yum remove 
yum install 

should do what you want (backups of modified config files).


But that's unfortunately not always convenient if you need to remove
dependent packages for "yum remove" ?
I guess yum-shell may help in that case ?


c.f. what I wrote in 
http://lists.fedoraproject.org/pipermail/devel/2013-May/183321.html


This works in most cases (I haven't seen it fails in any real world 
case, it's imaginable it fails in some stateful packages).


Ralf

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

Re: Build control-center in mock fail

[Colin Walters]

On Sat, 2013-05-25 at 11:15 -0400, Nico Kadel-Garcia wrote:

[The build hosts do not have outside network access]

> That's very specific to the Fedora build environment. Difficult to
> replicate in the field without a huge local build structure! 

If you do it using firewalls, yes, quite annoying.  But not if you use
Linux container features; linux-user-chroot allows using some of them
in a (relatively) safe way as non-root:

$ whoami
walters
$ ping -c 1 google.com
PING google.com (173.194.43.2) 56(84) bytes of data.
64 bytes from lga15s34-in-f2.1e100.net (173.194.43.2): icmp_seq=1 ttl=54 
time=39.9 ms

--- google.com ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 106ms
rtt min/avg/max/mdev = 39.956/39.956/39.956/0.000 ms
$ linux-user-chroot --unshare-net / ping -c 1 google.com
ping: unknown host google.com
$ 

This is how the gnome-ostree build system builds completely as
non-root *and* denies network access during the build process.


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

Re: Build control-center in mock fail

[Nico Kadel-Garcia]

On Thu, May 16, 2013 at 11:38 PM, Adam Williamson  wrote:
> On Thu, 2013-05-16 at 22:48 -0400, Nico Kadel-Garcia wrote:
>> On Thu, May 9, 2013 at 12:12 AM, Rahul Sundaram  wrote:
>> > Hi
>> >
>> >
>> > On Thu, May 9, 2013 at 12:04 AM, Adam Williamson wrote:
>> >>
>> >>
>> >>
>> >> Yes, I know that, thanks. I didn't ask for a lecture, but whether this
>> >> was actually written down in the guidelines somewhere.
>> >
>> >
>> > It is not written down as policy and since the tools themselves enforce
>> > this, I don't think it has been needed
>> >
>> > Rahul
>>
>> Which tool enforces this? Unless the toolkit for the build
>> environments is completely isolated from the Internet and uses only
>> disk access or local VLAN for it's access to source file repositories,
>> this can be very difficult to enforce.
>
> It is, as mentioned elsewhere in the thread. The build hosts do not have
> outside network access.

[ Sorry for the late reply, I've been at a family funeral this week. ]

That's very specific to the Fedora build environment. Difficult to
replicate in the field without a huge local build structure! And
enforced by a specific build environment is nowhere near the same
thing as "mandated by published policy" to help SRPM builders know how
they should plan their work.

>> But I continue to
>> run across Java based SRPM's that use "maven" and wind up with broken
>> URL's or insufficiently specific URL's that just grab the latest
>> modules from their relevant upstream repo.
>
> In Fedora's build system the source tarballs aren't ever 'automagically'
> pulled from the URL specified in the spec file, so it can be utterly and
> complete incorrect without any obvious consequences. Though by policy,
> it's supposed to be valid and correct.

Completely agreed, but irrelevant to the "maven" problem I just
described. I've caught perl package builders doing it, too. The
"%build" part of their software, or tools like "maven", automatically
pull in dependencies from arbitrary external locations without ever
listing the source bundles in the .spec files. Good package mantainers
normally deal with this by using the "maven-jpp" command, which
correctly refuses to pull down uninstalled dependencies. But new RPM
builders have little guidance to avoid this pitfall.

>> It would make my life easier to have a stated policy I can point
>> packagers to in the wide world. Please?
>
> Fedora's policies only apply to packages that are part of Fedora in any
> case, so I'm not sure why you think people who are packaging outside of
> the Fedora repositories would pay attention to a Fedora policy, and we
> can't really set policies for anyone else...:)

Well, no. But they're good policies, and it would help me to have them
be explicit so I can point to them as reference guidelines, rather
than relying on the koji build system to enforce an entirely unstated
policy.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Software Management call for RFEs

[Simone Caronni]

On 24 May 2013 22:02, Przemek Klosowski  wrote:

> On 05/23/2013 07:52 AM, Simone Caronni wrote:
>
>  I fiddle around with a new Nagios installation, then something stops
>> working. I'm pretty sure it is some modifications in
>> /etc/nagios/nagios.cfg but I cannot track it down.
>> As an example I could do:
>>
>> mv /etc/nagios/nagios.cfg /etc/nagios/nagios.cfg.mine
>> yum reinstall nagios --onlyfile /etc/nagios/nagios.cfg
>>
>
> What's the advantage over just yum reinstall nagios, given that modified
> config files are preserved? A known baseline is a huge advantage of RPM,
> and allowing retail installation seems to go against that.
>

Well, that's true; I was thinking of a more obscure case that happened to
me with some config files and manipulated files under /usr/share but that's
really a corner case. If I just save the file I get the same behaviour.
Forget it.

Regards,
--Simone

-- 
You cannot discover new oceans unless you have the courage to lose sight of
the shore (R. W. Emerson).

http://xkcd.com/229/
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Software Management call for RFEs

[Nico Kadel-Garcia]

On Thu, May 23, 2013 at 4:53 AM, Stijn Hoop  wrote:
> Hi,
>
> I would like better integration with domain-specific package managers.
> By which I mean npm (for node.js), gem (for ruby), pip (for python),
> cpan (for perl), pecl/pear (for PHP), CRAN (for R), CTAN (for TeX), and
> many more I'm sure.

You left out "maven". And first off, those are not "yum" behaviors,
they're "rpm" or "rpmbuild" behaviors. .

Second, the second you start letting yum and RPM grab modules
automatically from any of those third party repositories, you are in
dependency and compatibility hell. To take an example, look at the
perl-HTML-Mason package. It's been evolving reasonably quickly and
bopping back and forth between distinct authors with distinct styles,
so the dependency lists keep changing and updating to very recent
versions of other modules. As you bring in more Perl dependencies,
automatically, via local cpan builds, you lose track of which RPM you
built and installed in what fashion and can wind up with dependencies
based on the latest builds from CPAN that *break* your existing
codebase, or even wind up upgrading your version of perl. (Been there
with "cpan build", done that, had one hell of a time cleaning up the
mess!)

I've done a lot of work with CPAN -> RPM building, and it's painful
(That's why I keep updated versions of "cpan2rpm" and "cpanspec" up at
https://github.com/nkadel/)

> By integrating RPM with these package managers, I feel it would be
> possible to provide a consistent view of the system, as well as a
> consistent management interface for sysadmins as opposed to application
> developers. The latter I might expect to continue to use the domain
> specific package managers, simply because they add value to domain
> experts -- but for the common usecase "install this app on the server"
> it would be nice to use RPM only.

It's possible to have some tools to help with such building, but
that's a package creation issue, not a package management issue. The
same issues exist

> Another advantage that I see is that it saves Fedora packager manpower
> -- if the "translation" is good enough, it should be possible to work
> with upstream packages and simply automate the fedora rpm process as
> much as possible. Current examples are R2spec and the TeXLive package
> scripts.

TexLive is well defined. CPAN, rubygems, Maven, php/pear, etc.? Not so
much. Rubygems is particularly scary because the gems *do not publish
compilable source* for any well defined build environment, they rely
extensively on pre-built modules. Maven has the same "I publish
binaries, not buildable source code" problem.  CPAN is a nightmare:
the stylistic differences among the developers make consistent RPm
building a very, very manual process: TexLive is so well organized as
a monolithic, buildable source environment that it works well, I'll
admit, but but not the others.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Software Management call for RFEs

[Nico Kadel-Garcia]

On Thu, May 23, 2013 at 9:52 AM,   wrote:
>> From: Rahul Sundaram 
>> What I would like to see is
>> solid git integration. Git has become the standard distributed vcs
>> and github and google code etc have stopped hosting tarballs and/or
>> discouraging it and GNOME is planning to do that as well.  If Source
>> URL could point directly to a git url with a hash or git tag, we
>> would benefit.
>
> Amen to that!  I roll my own rpms daily from locally developed sources where
> we have no policy of pushing tarballs.  From everything I've ever been able
> to figure out, it's necessary for me to make temporary tarballs just to feed
> rpmbuild.  It always seems such a huge waste of time, especially for very
> large packages.

Nahh, you can work around this. Manipulate %setup" to build a local
compilation directory, but not unload tarballs, and then in the
"%build" step do a git pull froom your git repo. And add
"BuildRequires: /usr/bin/git".

But this  means that your SRPM's will not have the available build
materials, and will require an outside web access to download source
code. This is *tremendous* source control problem.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Software Management call for RFEs

[Nico Kadel-Garcia]

On Wed, May 22, 2013 at 11:55 AM, Michael Ekstrand  wrote:
> Performance improvement: improve scaling to 5K+ installed packages.

* Amen. This is particularly compounded by poor caching default
behavior, so that a few yum commands in a row each wind up reaching
out to downloading metadata again, and again, and again.

I think this can be addressed by moving the metadata updates to a
different function, and calling it *separately* only as needed. The
Debian "apt" tool does this quite effectively.

* Script parseable output without extraneous labeling.

The output of "yum list is cluttered with unnecessary headers, and
whitespace handling that winds up trimming package names or inserting
extraneous new lines. I'd fiind it invaluable if "yum list --tsv" gave
a tab separated variables list of:

 nameversion   release  arch   reponame

And leave *OFF* the  "Installed Packages" and "Available Packages"
entries for such tab separated variable output. I loathe having to
sort those out for scriptable operations.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

rawhide report: 20130525 changes

[Fedora Rawhide Report]

Compose started at Sat May 25 08:15:03 UTC 2013

Broken deps for x86_64
--
[bochs]
bochs-2.6.1-1.fc20.x86_64 requires vgabios
[dragonegg]
dragonegg-3.1-19.fc19.x86_64 requires gcc = 0:4.7.2-9.fc19
[ekiga]
ekiga-4.0.1-1.fc19.x86_64 requires libedata-book-1.2.so.17()(64bit)
[evolution-ews]
evolution-ews-3.9.1-1.fc20.i686 requires libicalvcal.so.0
evolution-ews-3.9.1-1.fc20.i686 requires libicalss.so.0
evolution-ews-3.9.1-1.fc20.i686 requires libical.so.0
evolution-ews-3.9.1-1.fc20.x86_64 requires libicalvcal.so.0()(64bit)
evolution-ews-3.9.1-1.fc20.x86_64 requires libicalss.so.0()(64bit)
evolution-ews-3.9.1-1.fc20.x86_64 requires libical.so.0()(64bit)
[evolution-mapi]
evolution-mapi-3.9.1-1.fc20.i686 requires libicalvcal.so.0
evolution-mapi-3.9.1-1.fc20.i686 requires libicalss.so.0
evolution-mapi-3.9.1-1.fc20.i686 requires libical.so.0
evolution-mapi-3.9.1-1.fc20.x86_64 requires libicalvcal.so.0()(64bit)
evolution-mapi-3.9.1-1.fc20.x86_64 requires libicalss.so.0()(64bit)
evolution-mapi-3.9.1-1.fc20.x86_64 requires libical.so.0()(64bit)
[gcc-python-plugin]
gcc-python2-debug-plugin-0.12-4.fc20.x86_64 requires gcc = 
0:4.8.0-6.fc20
gcc-python2-plugin-0.12-4.fc20.x86_64 requires gcc = 0:4.8.0-6.fc20
gcc-python3-debug-plugin-0.12-4.fc20.x86_64 requires gcc = 
0:4.8.0-6.fc20
gcc-python3-plugin-0.12-4.fc20.x86_64 requires gcc = 0:4.8.0-6.fc20
[gnome-shell]
gnome-shell-3.9.1-2.fc20.x86_64 requires libicalvcal.so.0()(64bit)
gnome-shell-3.9.1-2.fc20.x86_64 requires libicalss.so.0()(64bit)
gnome-shell-3.9.1-2.fc20.x86_64 requires libical.so.0()(64bit)
[gooddata-cl]
gooddata-cl-1.2.56-2.fc19.noarch requires gdata-java
[kawa]
1:kawa-1.11-5.fc19.x86_64 requires servlet25
[koji]
koji-vm-1.8.0-1.fc20.noarch requires python-virtinst
[lancet]
lancet-1.0.1-6.fc19.noarch requires ant-nodeps >= 0:1.7.1
[libopensync-plugin-evolution2]
1:libopensync-plugin-evolution2-0.22-33.fc20.x86_64 requires 
libicalvcal.so.0()(64bit)
1:libopensync-plugin-evolution2-0.22-33.fc20.x86_64 requires 
libicalss.so.0()(64bit)
1:libopensync-plugin-evolution2-0.22-33.fc20.x86_64 requires 
libical.so.0()(64bit)
[lua-logging]
lua-logging-1.3.0-1.fc20.noarch requires lua = 0:5.2
[lua-rex]
lua-rex-2.7.2-1.fc20.x86_64 requires lua = 0:5.2
[luadoc]
luadoc-3.0.1-8.fc20.noarch requires lua = 0:5.2
[lutok]
lutok-devel-0.2-4.fc19.i686 requires lua-devel < 0:5.2
lutok-devel-0.2-4.fc19.x86_64 requires lua-devel < 0:5.2
[ooo2gd]
ooo2gd-3.0.0-6.fc19.x86_64 requires gdata-java
[openbox]
gdm-control-3.5.0-11.20121001git782b28.fc19.x86_64 requires gnome-panel
gnome-panel-control-3.5.0-11.20121001git782b28.fc19.x86_64 requires 
gnome-panel
[ovirt-engine]
ovirt-engine-notification-service-3.1.0-1.fc19.noarch requires 
classpathx-mail
[ovirt-guest-agent]
ovirt-guest-agent-gdm-plugin-1.0.6-6.fc19.x86_64 requires 
libgdmsimplegreeter.so.1()(64bit)
[perl-Bio-ASN1-EntrezGene]
perl-Bio-ASN1-EntrezGene-1.091-17.fc19.noarch requires 
perl(Bio::Index::AbstractSeq)
[perl-Bio-SamTools]
perl-Bio-SamTools-1.35-2.fc19.x86_64 requires 
perl(Bio::SeqFeature::Lite)
perl-Bio-SamTools-1.35-2.fc19.x86_64 requires perl(Bio::PrimarySeq)
[python-TraitsBackendQt]
python-TraitsBackendQt-3.5.0-5.fc19.noarch requires python-TraitsGUI
[python-flask-admin]
python-flask-admin-1.0.5-3.fc20.noarch requires python-wtf-peewee
[qpid-cpp]
qpid-cpp-server-xml-0.20-6.fc20.x86_64 requires libxqilla.so.5()(64bit)
[scala]
scala-2.9.2-2.fc19.noarch requires osgi(org.scala-ide.scala.library)
[spacewalk-web]
spacewalk-dobby-1.9.22-2.fc19.noarch requires perl(Spacewalk::Setup)
[zarafa]
libmapi-7.0.13-1.fc19.i686 requires libicalss.so.0
libmapi-7.0.13-1.fc19.i686 requires libical.so.0
libmapi-7.0.13-1.fc19.x86_64 requires libicalss.so.0()(64bit)
libmapi-7.0.13-1.fc19.x86_64 requires libical.so.0()(64bit)
php-mapi-7.0.13-1.fc19.x86_64 requires php(zend-abi) = 0:20100525-x86-64
php-mapi-7.0.13-1.fc19.x86_64 requires php(api) = 0:20100412-x86-64
zarafa-ical-7.0.13-1.fc19.x86_64 requires libicalss.so.0()(64bit)
zarafa-ical-7.0.13-1.fc19.x86_64 requires libical.so.0()(64bit)



Broken deps for i386
--
[bochs]
bochs-2.6.1-1.fc20.i686 requires vgabios
[dragonegg]
dragonegg-3.1-19.fc19.i686 requires gcc = 0:4.7.2-9.fc19
[ekiga]
ekiga-4.0.1-1.fc19.i686 requires libedata-book-1.2.so.17
[evolution-ews]
evolution-ews-3.9.1-1.fc20.i686 requires libicalvcal.so.0
evolution-ews-3.9.1-1.fc20.i686 requires libicalss.so.0
evolution-ews-3.9.1-1.fc

Re: Software Management call for RFEs

[Michael Scherer]

Le vendredi 24 mai 2013 à 07:08 +0200, Ralf Corsepius a écrit :
> On 05/23/2013 06:05 PM, Simone Caronni wrote:
> > On 23 May 2013 17:38, James Antill  > > wrote:
> >
> > On Thu, 2013-05-23 at 13:52 +0200, Simone Caronni wrote:
> >  > mv /etc/nagios/nagios.cfg /etc/nagios/nagios.cfg.mine
> >  > yum reinstall nagios --onlyfile /etc/nagios/nagios.cfg
> >
> >   How is this functionally different from "yum reinstall nagios" ?
> >   Yes, yum/rpm will currently replace files with identical copies but
> > functionally the extra copies are "just wasting reinstall time".
> >
> >
> > By doing "yum reinstall nagios" I don't have the the default config
> > files (i.e. nagios.cfg.rpmnew is not created). This happens only on
> > upgrades.
> 
> yum remove 
> yum install 
> 
> should do what you want (backups of modified config files).

But that's unfortunately not always convenient if you need to remove
dependent packages for "yum remove" ?
I guess yum-shell may help in that case ?

-- 
Michael Scherer

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

Re: Arduino firmware permissible to include?

[Peter Robinson]

On Sat, May 25, 2013 at 8:59 AM, Paolo Bonzini  wrote:
> Il 23/05/2013 15:25, Peter Oliver ha scritto:
>> Arduino is an electronics prototyping board, and also a GNU
>> GPL2-licenced IDE for writing and uploading code to such boards.  Fedora
>> has packages for the IDE.
>>
>> Recent versions of the IDE include WiFi firmware for Arduino
>> (http://arduino.cc/en/Main/ArduinoWiFiShield).  The Arduino "source"
>> bundles include the binary firmware.  Source code for the firmware is
>> also included, but there are no build scripts, and the firmware is not
>> built when the IDE itself is built.
>>
>> Is it permissible to include this firmware in the Fedora packages?  My
>> impression is that it's not firmware in the sense described at
>> https://fedoraproject.org/wiki/Licensing:Main#Binary_Firmware, because
>> it's not firmware for hardware on which Fedora runs.  Rather, I believe
>> that it is content
>> (https://fedoraproject.org/wiki/Packaging:Guidelines#Code_Vs_Content).
>>
>> Without access to the build scripts (which the GNU GPL2specifically says
>> must be included), do we even have a licence to redistribute the firmware?
>
> The firmware is merely aggregated to the IDE, so the GNU GPLv2 doesn't
> matter here.
>
> The firmware license is definitely not free.  I don't know if you can
> get an exception because it doesn't run on the CPU.  The safest bet is
> to ask FESCo.


Definitely one for Fedora legal. Probably the easiest way to do this,
but not the only way, is to file a package review request and have it
block FE-LEGAL.

The minimum requirement with firmwares is that it needs to be freely
distributable but I suspect we do need an exception on top of that.

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

Re: Arduino firmware permissible to include?

[Dan Horák]

On Sat, 25 May 2013 09:59:00 +0200
Paolo Bonzini  wrote:

> Il 23/05/2013 15:25, Peter Oliver ha scritto:
> > Arduino is an electronics prototyping board, and also a GNU
> > GPL2-licenced IDE for writing and uploading code to such boards.
> > Fedora has packages for the IDE.
> > 
> > Recent versions of the IDE include WiFi firmware for Arduino
> > (http://arduino.cc/en/Main/ArduinoWiFiShield).  The Arduino "source"
> > bundles include the binary firmware.  Source code for the firmware
> > is also included, but there are no build scripts, and the firmware
> > is not built when the IDE itself is built.
> > 
> > Is it permissible to include this firmware in the Fedora packages?
> > My impression is that it's not firmware in the sense described at
> > https://fedoraproject.org/wiki/Licensing:Main#Binary_Firmware,
> > because it's not firmware for hardware on which Fedora runs.
> > Rather, I believe that it is content
> > (https://fedoraproject.org/wiki/Packaging:Guidelines#Code_Vs_Content).
> > 
> > Without access to the build scripts (which the GNU GPL2specifically
> > says must be included), do we even have a licence to redistribute
> > the firmware?
> 
> The firmware is merely aggregated to the IDE, so the GNU GPLv2 doesn't
> matter here.
> 
> The firmware license is definitely not free.  I don't know if you can
> get an exception because it doesn't run on the CPU.  The safest bet is
> to ask FESCo.

better ask the Fedora legal list I think as this is more a legal
question than technical


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

Re: Arduino firmware permissible to include?

[Paolo Bonzini]

Il 23/05/2013 15:25, Peter Oliver ha scritto:
> Arduino is an electronics prototyping board, and also a GNU
> GPL2-licenced IDE for writing and uploading code to such boards.  Fedora
> has packages for the IDE.
> 
> Recent versions of the IDE include WiFi firmware for Arduino
> (http://arduino.cc/en/Main/ArduinoWiFiShield).  The Arduino "source"
> bundles include the binary firmware.  Source code for the firmware is
> also included, but there are no build scripts, and the firmware is not
> built when the IDE itself is built.
> 
> Is it permissible to include this firmware in the Fedora packages?  My
> impression is that it's not firmware in the sense described at
> https://fedoraproject.org/wiki/Licensing:Main#Binary_Firmware, because
> it's not firmware for hardware on which Fedora runs.  Rather, I believe
> that it is content
> (https://fedoraproject.org/wiki/Packaging:Guidelines#Code_Vs_Content).
> 
> Without access to the build scripts (which the GNU GPL2specifically says
> must be included), do we even have a licence to redistribute the firmware?

The firmware is merely aggregated to the IDE, so the GNU GPLv2 doesn't
matter here.

The firmware license is definitely not free.  I don't know if you can
get an exception because it doesn't run on the CPU.  The safest bet is
to ask FESCo.

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