gmane.linux.redhat.fedora.devel

Re: Build control-center in mock fail

Nico Kadel-Garcia — 2013-05-26T01:36:49

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.

Package EVR problems in Fedora 2013-05-25

2013-05-25T22:05:19

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 >

Re: Build control-center in mock fail

Kevin Fenzi — 2013-05-25T17:14:20

On Sat, 25 May 2013 11:15:22 -0400
Nico Kadel-Garcia <nkadel< at >gmail.com> wrote:


:( 


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

Re: Software Management call for RFEs

Kevin Fenzi — 2013-05-25T17:07:23

On Sat, 25 May 2013 01:42:44 +0300
Oron Peled <oron< at >actcom.co.il> wrote:


...snip...


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

Re: Software Management call for RFEs

Ralf Corsepius — 2013-05-25T16:58:05

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

Re: Build control-center in mock fail

Colin Walters — 2013-05-25T15:51:56

[The build hosts do not have outside network access]


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.

Re: Build control-center in mock fail

Nico Kadel-Garcia — 2013-05-25T15:15:22

[ 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.


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.


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 guidel

Re: Software Management call for RFEs

Simone Caronni — 2013-05-25T14:52:57


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

Re: Software Management call for RFEs

Nico Kadel-Garcia — 2013-05-25T14:12:24

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 update

Re: Software Management call for RFEs

Nico Kadel-Garcia — 2013-05-25T14:04:45

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.

F-19 Branched report: 20130525 changes

Fedora Branched Report — 2013-05-25T13:47:59

Compose started at Sat May 25 09:15:02 UTC 2013

Broken deps for x86_64
----------------------------------------------------------
[bochs]
bochs-2.6.1-1.fc19.x86_64 requires vgabios
[deltacloud-core]
deltacloud-core-rhevm-1.1.3-1.fc19.noarch requires rubygem(rbovirt) >= 0:0.0.18
[dragonegg]
dragonegg-3.1-19.fc19.x86_64 requires gcc = 0:4.7.2-9.fc19
[fence-virt]
fence-virtd-libvirt-qmf-0.3.0-11.fc19.x86_64 requires libvirt-qmf
[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.fc19.noarch requires python-virtinst
[libkolab]
php-kolab-0.4.1-3.fc19.x86_64 requires php(zend-abi) = 0:20100525-x86-64
php-kolab-0.4.1-3.fc19.x86_64 requires php(api) = 0:20100412-x86-64
[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-not

Re: Software Management call for RFEs

Nico Kadel-Garcia — 2013-05-25T13:34:32

* 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:

             name    version   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.

rawhide report: 20130525 changes

Fedora Rawhide Report — 2013-05-25T13:14:42

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 re

Re: Software Management call for RFEs

Michael Scherer — 2013-05-24T07:26:00

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

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 ?

Re: Arduino firmware permissible to include?

Peter Robinson — 2013-05-25T08:36:20


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

Re: Arduino firmware permissible to include?

Dan Horák — 2013-05-25T08:05:54

On Sat, 25 May 2013 09:59:00 +0200
Paolo Bonzini <pbonzini< at >redhat.com> wrote:


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


Dan

Re: Arduino firmware permissible to include?

Paolo Bonzini — 2013-05-25T07:59:00

Il 23/05/2013 15:25, Peter Oliver ha scritto:

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

Re: Software Management call for RFEs

Adam Williamson — 2013-05-25T06:40:00

First google result for 'fedora comps' is:

https://fedoraproject.org/wiki/How_to_use_and_edit_comps.xml_for_package_groups

It has a 'how to edit comps' section which gives the repo URL.


Guess again. All packagers can commit to comps, I believe. But please,
please, try to avoid committing to it during release freezes without
checking in with notting/qa/releng, especially if your change adds
packages to release media. Or is completely broken, as has happened. ;)


Or you could not make assumptions :)

Re: Software Management call for RFEs

David Tardon — 2013-05-25T06:36:25

Hi,

On Fri, May 24, 2013 at 10:08:06AM -0700, Adam Williamson wrote:

Some things in favor of metapackages:

1. The packager has to know that such thing as comps exists. (I know
about it. I have even seen patches for it, so I know it is some sort of
XML. But I have no idea where to look for it. Is there a repo for it?
"fedpkg clone -B comps" was unsuccessful.) On the other side, the
packager already knows how to make a (sub-)package that depends on other
package(s).

2. A metapackage uses rpm syntax for specifying the dependencies. No
need to learn anything new.

3. A metapackage is under the packager's control. A comps group is not.
(I doubt packagers have commit access to to comps repo (if there is a
repo). That means creating a patch, opening a bug, waiting for reaction
(probably for days),... tadda yadda... Or I can create a subpackage and
be done in a minute.)

D.

Re: About volatile udev directory

Kay Sievers — 2013-05-25T00:48:48

It is not created by default. The one who needs it can create it.

Cheers,
Kay

Re: Software Management call for RFEs

Oron Peled — 2013-05-24T22:42:44

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*.

Example (without multi-arch -- like in Fedora today):
 * You cross compile libfoo (e.g: on x86 you compile for arm)

 * You can install the resulting libfoo rpm on the arm device

 * Now you want to cross-compile an application that use this
   library, so you need to install libfoo-devel on your workstation -- BUT!

 * The libfoo-devel you have is for arm (not installable on your x86)

 * Furthermore, even if you manage to install it, it will put the files
   in the wrong location (/usr/lib) and not where the cross-compiler
   will search them (e.g: /usr/arm-unknown-linux/.../lib)

 * So you have to extract the arm libraries from libfoo-devel and
   manually put them into the correct location.
   (btw: Debian embedded developers