Re: Source file audit - 2013-11-17

2013-11-23 Thread Till Maas
On Thu, Nov 21, 2013 at 08:41:21PM +0200, Ville Skyttä wrote:
> On Thu, Nov 21, 2013 at 4:53 PM, Björn Persson
>  wrote:
> > Ville Skyttä wrote:
> >>spectool is not a source verification tool nor a certificate
> >>validation one, and I'm not going to help people get the misconception
> >>that it might be something like that.
> >
> > So how do you think the verification should be done?
> 
> Um, source verification needs to be done... by verifying the sources?
> Diligence how deep maintainers want to go and their competence levels
> vary, but there's really no way around it. Standard procedures for
> checking the authenticity of sources should include GPG/signature
> checking (if available), checksum checking (if available, hopefully
> signed), and cross checking with other consumers (e.g. other distros,
> if available). And authenticity checking is not verifying the sources
> nor enough -- upstreams make mistakes too, and packagers should really
> know what they're shipping, read and understand diffs between releases
> etc etc.

How many packagers do this?

> > If an upstream project doesn't PGP-sign the tarballs but does make them
> > available over HTTPS, then the TLS connection is the only thing that
> > ensures that the tarball you receive is the one that the developers
> > published.
> 
> No, it doesn't, at all. For example the server may have had all its
> content compromised and serve all that over an HTTPS connection that
> passes whatever validity and authenticity checks one might want to
> throw at it.

Even if you read the diff, it might not help, because an important fix
for a vulnerability might be missing. So there is no 100% security.
However using HTTPS URLs with sane software should allow to trust that
the TLS connection was properly verified. With the change you risk also
persons who are e.g. upstream and Fedora maintainers using HTTPS URLs to
fetch their published tarball. There is no need for them to use other
out-of-band validation techniques to verify that the tarball they
downloaded is the same they uploaded unless they have reasonable doubt
about their system.

However, if you do not want to use HTTPS to verify the transfered
contents then just use plain HTTP. Using HTTPS but not verifying the
server's certificate makes things only worse as long as no secret
contents are transmitted.

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

Broken dependencies: perl-Language-Expr

2013-11-23 Thread buildsys


perl-Language-Expr has broken dependencies in the F-20 tree:
On x86_64:
perl-Language-Expr-0.19-4.fc19.noarch requires 
perl(:MODULE_COMPAT_5.16.2)
On i386:
perl-Language-Expr-0.19-4.fc19.noarch requires 
perl(:MODULE_COMPAT_5.16.2)
On armhfp:
perl-Language-Expr-0.19-4.fc19.noarch requires 
perl(:MODULE_COMPAT_5.16.2)
Please resolve this as soon as possible.


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

F-20 Branched report: 20131123 changes

2013-11-23 Thread Fedora Branched Report
Compose started at Sat Nov 23 09:15:02 UTC 2013

Broken deps for armhfp
--
[avro]
avro-mapred-1.7.5-1.fc20.noarch requires hadoop-mapreduce
avro-mapred-1.7.5-1.fc20.noarch requires hadoop-client
[blueman]
blueman-1.23-7.fc20.armv7hl requires obex-data-server >= 0:0.4.3
blueman-1.23-7.fc20.armv7hl requires gvfs-obexftp
[cloud-init]
cloud-init-0.7.2-7.fc20.noarch requires dmidecode
[cobbler]
cobbler-2.4.0-2.fc20.noarch requires syslinux
[condor-wallaby]
condor-wallaby-client-5.0.3-5.fc20.noarch requires python-qpid-qmf >= 
0:0.9.1073306
[fence-agents]
fence-agents-common-4.0.4-3.fc20.armv7hl requires pexpect
[fts]
fts-server-3.1.1-1.fc20.armv7hl requires libactivemq-cpp.so.14
[glpi]
glpi-0.84.3-1.fc20.noarch requires php-ZendFramework2-Version
glpi-0.84.3-1.fc20.noarch requires php-ZendFramework2-Stdlib
glpi-0.84.3-1.fc20.noarch requires php-ZendFramework2-ServiceManager
glpi-0.84.3-1.fc20.noarch requires php-ZendFramework2-Loader
glpi-0.84.3-1.fc20.noarch requires php-ZendFramework2-I18n
glpi-0.84.3-1.fc20.noarch requires php-ZendFramework2-Cache-apc
glpi-0.84.3-1.fc20.noarch requires php-ZendFramework2-Cache
[gnome-do-plugins]
gnome-do-plugins-thunderbird-0.8.4-14.fc20.armv7hl requires thunderbird
[gofer]
ruby-gofer-0.75-4.fc20.noarch requires rubygem(qpid) >= 0:0.16.0
[gtkd]
gtkd-geany-tags-2.0.0-29.20120815git9ae9181.fc18.noarch requires gtkd = 
0:2.0.0-29.20120815git9ae9181.fc18
[ipython]
python-ipython-console-0.13.2-2.fc20.noarch requires pexpect
python3-ipython-console-0.13.2-2.fc20.noarch requires python3-pexpect
[kawa]
1:kawa-1.11-5.fc19.armv7hl requires servlet25
[koji]
koji-vm-1.8.0-2.fc20.noarch requires python-virtinst
[kyua-cli]
kyua-cli-0.5-3.fc19.armv7hl requires liblutok.so.0
kyua-cli-tests-0.5-3.fc19.armv7hl requires liblutok.so.0
[mozilla-firetray]
mozilla-firetray-thunderbird-0.3.6-0.5.143svn.fc18.1.armv7hl requires 
thunderbird >= 0:11
[msp430-libc]
msp430-libc-20120224-2.fc19.noarch requires msp430-gcc >= 0:4.6.3
[nifti2dicom]
nifti2dicom-0.4.6-3.fc20.armv7hl requires libvtksys.so.5.10
nifti2dicom-0.4.6-3.fc20.armv7hl requires libvtkWidgets.so.5.10
nifti2dicom-0.4.6-3.fc20.armv7hl requires libvtkVolumeRendering.so.5.10
nifti2dicom-0.4.6-3.fc20.armv7hl requires libvtkViews.so.5.10
nifti2dicom-0.4.6-3.fc20.armv7hl requires libvtkTextAnalysis.so.5.10
nifti2dicom-0.4.6-3.fc20.armv7hl requires libvtkRendering.so.5.10
nifti2dicom-0.4.6-3.fc20.armv7hl requires libvtkParallel.so.5.10
nifti2dicom-0.4.6-3.fc20.armv7hl requires libvtkInfovis.so.5.10
nifti2dicom-0.4.6-3.fc20.armv7hl requires libvtkImaging.so.5.10
nifti2dicom-0.4.6-3.fc20.armv7hl requires libvtkIO.so.5.10
nifti2dicom-0.4.6-3.fc20.armv7hl requires libvtkHybrid.so.5.10
nifti2dicom-0.4.6-3.fc20.armv7hl requires libvtkGraphics.so.5.10
nifti2dicom-0.4.6-3.fc20.armv7hl requires libvtkGeovis.so.5.10
nifti2dicom-0.4.6-3.fc20.armv7hl requires libvtkGenericFiltering.so.5.10
nifti2dicom-0.4.6-3.fc20.armv7hl requires libvtkFiltering.so.5.10
nifti2dicom-0.4.6-3.fc20.armv7hl requires libvtkCommon.so.5.10
nifti2dicom-0.4.6-3.fc20.armv7hl requires libvtkCharts.so.5.10
nifti2dicom-0.4.6-3.fc20.armv7hl requires libQVTK.so.5.10
[nocpulse-common]
nocpulse-common-2.2.7-2.fc20.noarch requires perl(RHN::DBI)
[openbox]
gdm-control-3.5.2-2.fc20.armv7hl requires gnome-panel
gnome-panel-control-3.5.2-2.fc20.armv7hl requires gnome-panel
[openlmi-providers]
openlmi-0.4.0-1.fc20.noarch requires openlmi-power
[openpts]
openpts-0.2.6-7.fc20.armv7hl requires tboot
[perl-Language-Expr]
perl-Language-Expr-0.19-4.fc19.noarch requires 
perl(:MODULE_COMPAT_5.16.2)
[pure]
pure-doc-0.57-4.fc20.noarch requires pure = 0:0.57-4.fc20
[python-requests-oauthlib]
python-requests-oauthlib-0.4.0-2.fc20.noarch requires python-oauthlib
[python-tag]
python-tag-2013.1-1.fc20.armv7hl requires libboost_python.so.1.53.0
[qpid-cpp]
qpid-cpp-server-ha-0.24-6.fc20.armv7hl requires qpid-qmf(armv7hl-32)
qpid-tools-0.24-6.fc20.noarch requires python-qpid-qmf
[rootplot]
rootplot-2.2.1-7.fc19.noarch requires root-python
[ruby-spqr]
ruby-spqr-0.3.6-7.fc20.noarch requires ruby-qpid-qmf
[rubygem-audited-activerecord]
rubygem-audited-activerecord-3.0.0-3.fc19.noarch requires 
rubygem(activerecord) < 0:4
[scilab]
scilab-doc-5.4.1-4.fc20.noarch requires scilab = 0:5.4.1-4.fc20
scilab-tests-5.4.1-4.fc20.noarch requires scilab = 0:5.4.1-4.fc20
[sigul]
sigul-0.100-3.fc20.noarch requires pexpect
[spacewalk-admin]
spacewalk-admin-2.0.1-2.fc20.noarch requir

Broken dependencies: perl-Language-Expr

2013-11-23 Thread buildsys


perl-Language-Expr has broken dependencies in the rawhide tree:
On x86_64:
perl-Language-Expr-0.19-4.fc19.noarch requires 
perl(:MODULE_COMPAT_5.16.2)
On i386:
perl-Language-Expr-0.19-4.fc19.noarch requires 
perl(:MODULE_COMPAT_5.16.2)
On armhfp:
perl-Language-Expr-0.19-4.fc19.noarch requires 
perl(:MODULE_COMPAT_5.16.2)
Please resolve this as soon as possible.


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

rawhide report: 20131123 changes

2013-11-23 Thread Fedora Rawhide Report
Compose started at Sat Nov 23 08:15:02 UTC 2013

Broken deps for i386
--
[OpenEXR_CTL]
OpenEXR_CTL-1.0.1-16.fc20.i686 requires libImath.so.6
OpenEXR_CTL-1.0.1-16.fc20.i686 requires libIlmThread.so.6
OpenEXR_CTL-1.0.1-16.fc20.i686 requires libIlmImf.so.7
OpenEXR_CTL-1.0.1-16.fc20.i686 requires libIexMath.so.6
OpenEXR_CTL-1.0.1-16.fc20.i686 requires libIex.so.6
OpenEXR_CTL-1.0.1-16.fc20.i686 requires libHalf.so.6
OpenEXR_CTL-libs-1.0.1-16.fc20.i686 requires libIlmThread.so.6
OpenEXR_CTL-libs-1.0.1-16.fc20.i686 requires libIlmImf.so.7
OpenEXR_CTL-libs-1.0.1-16.fc20.i686 requires libIex.so.6
[R-RScaLAPACK]
R-RScaLAPACK-0.6.1-13.fc20.i686 requires libatlas.so.3
[blueman]
blueman-1.23-7.fc20.i686 requires obex-data-server >= 0:0.4.3
blueman-1.23-7.fc20.i686 requires gvfs-obexftp
[converseen]
converseen-0.6.2-2.fc20.i686 requires libMagick++-6.Q16.so.1
[derelict]
derelict-tcod-3-20.20130626gite70c293.fc20.i686 requires tcod
derelict-tcod-devel-3-20.20130626gite70c293.fc20.i686 requires tcod
[dragonegg]
dragonegg-3.3-11.fc21.i686 requires gcc = 0:4.8.2-1.fc21
[drawtiming]
drawtiming-0.7.1-11.fc20.i686 requires libMagick++-6.Q16.so.1
[evolution-rss]
1:evolution-rss-0.3.94-2.fc21.i686 requires libcamel-1.2.so.46
[fatrat]
1:fatrat-1.2.0-0.14.beta2.fc20.i686 requires liblog4cpp.so.4
[firstaidkit]
firstaidkit-plugin-openscap-0.3.2-7.fc20.noarch requires 
openscap-content >= 0:0.7.2
[freefem++]
freefem++-3.19-3.1.fc18.i686 requires libf77blas.so.3
freefem++-3.19-3.1.fc18.i686 requires libcblas.so.3
freefem++-3.19-3.1.fc18.i686 requires libatlas.so.3
freefem++-glx-3.19-3.1.fc18.i686 requires libf77blas.so.3
freefem++-glx-3.19-3.1.fc18.i686 requires libcblas.so.3
freefem++-glx-3.19-3.1.fc18.i686 requires libatlas.so.3
freefem++-mpi-3.19-3.1.fc18.i686 requires libf77blas.so.3
freefem++-mpi-3.19-3.1.fc18.i686 requires libcblas.so.3
freefem++-mpi-3.19-3.1.fc18.i686 requires libatlas.so.3
[ghc-happstack-server]
ghc-happstack-server-7.1.0-1.fc21.i686 requires 
libHSthreads-0.5.0.2-ghc7.6.3.so
ghc-happstack-server-7.1.0-1.fc21.i686 requires 
ghc(threads-0.5.0.2-e4dbb933a3190a4bd85aab395a8b346f)
ghc-happstack-server-devel-7.1.0-1.fc21.i686 requires 
ghc-devel(threads-0.5.0.2-e4dbb933a3190a4bd85aab395a8b346f)
[gtkd]
gtkd-2.0.0-29.20120815git9ae9181.fc18.i686 requires libphobos-ldc.so.60
[httpdtap]
httpdtap-0.2-2.fc21.noarch requires kernel-debuginfo
httpdtap-0.2-2.fc21.noarch requires httpd-debuginfo
httpdtap-0.2-2.fc21.noarch requires apr-util-debuginfo
httpdtap-0.2-2.fc21.noarch requires apr-debuginfo
[initial-setup]
initial-setup-0.3.11-1.fc21.noarch requires anaconda-tui >= 0:21.7
initial-setup-gui-0.3.11-1.fc21.noarch requires anaconda-gui >= 0:21.7
[kawa]
1:kawa-1.11-5.fc19.i686 requires servlet25
[koji]
koji-vm-1.8.0-2.fc20.noarch requires python-virtinst
[kscreen]
1:kscreen-1.0.2.1-1.fc21.i686 requires libkscreen(x86-32) = 1:1.0.2.1
[kyua-cli]
kyua-cli-0.5-3.fc19.i686 requires liblutok.so.0
kyua-cli-tests-0.5-3.fc19.i686 requires liblutok.so.0
[libghemical]
libghemical-2.99.1-24.fc20.i686 requires libf77blas.so.3
libghemical-2.99.1-24.fc20.i686 requires libatlas.so.3
[libopensync-plugin-irmc]
1:libopensync-plugin-irmc-0.22-7.fc20.i686 requires libopenobex.so.1
[libreoffice]
1:libreoffice-core-4.1.3.2-4.fc21.i686 requires libcmis-0.3.so.3
[maven-doxia]
maven-doxia-module-itext-1.4-4.fc21.noarch requires 
mvn(com.lowagie:itext:2.1.7)
[mpqc]
mpqc-2.3.1-23.fc20.i686 requires libf77blas.so.3
mpqc-2.3.1-23.fc20.i686 requires libatlas.so.3
[netdisco]
netdisco-1.1-6.fc20.noarch requires perl(SNMP::Info::Layer2::Bay)
[nifti2dicom]
nifti2dicom-0.4.6-3.fc20.i686 requires libvtksys.so.5.10
nifti2dicom-0.4.6-3.fc20.i686 requires libvtkWidgets.so.5.10
nifti2dicom-0.4.6-3.fc20.i686 requires libvtkVolumeRendering.so.5.10
nifti2dicom-0.4.6-3.fc20.i686 requires libvtkViews.so.5.10
nifti2dicom-0.4.6-3.fc20.i686 requires libvtkTextAnalysis.so.5.10
nifti2dicom-0.4.6-3.fc20.i686 requires libvtkRendering.so.5.10
nifti2dicom-0.4.6-3.fc20.i686 requires libvtkParallel.so.5.10
nifti2dicom-0.4.6-3.fc20.i686 requires libvtkInfovis.so.5.10
nifti2dicom-0.4.6-3.fc20.i686 requires libvtkImaging.so.5.10
nifti2dicom-0.4.6-3.fc20.i686 requires libvtkIO.so.5.10
nifti2dicom-0.4.6-3.fc20.i686 requires libvtkHybrid.so.5.10
nifti2dicom-0.4.6-3.fc20.i686 requires libvtkGraphics.so.5.10
nifti2dicom-0.4.6-3.fc20.i686 requires libvtkGeovis.so.5.10
nifti2dicom-0.4.6-3.fc20.i686 requires libvtkG

Re: Packaging changes for libev in Rawhide

2013-11-23 Thread Simo Sorce
On Tue, 2013-11-19 at 15:30 +0800, Mathieu Bridon wrote:
> Hi,
> 
> I would like to finally fix this bug in Fedora:
>   https://bugzilla.redhat.com/show_bug.cgi?id=985610
> 
> Basically, our libev package diverges from upstream in two ways:
> 
>   1. we install the header files in /usr/include/libev/ whereas upstream
>  installs them in /usr/include/
>   2. we ship a pkgconfig file, which upstream does not want
> 
> I'm not happy with these Fedora-specific changes, and upstream is
> completely uninterested in them.
> 
> It's confusing users who don't find the headers where they expect them,
> as demonstrated by this bug report.
> 
> Worst of all, it's causing changes in software consuming libev, which
> have often had to be modified for the Fedora-specific change in libev.
> Those changes were sometimes made in the respective upstreams, but most
> often in additional Fedora-specific changes.
> 
> I've been talking to upstream libev, and they really don't want the
> changes we made. They'd be much happier if we were packaging libev the
> way Debian is, as that's how they intended libev to be used.
> 
> So I'd like to follow upstream libev wishes, and stop confusing
> everybody with our Fedora-only changes.
> 
> My plan is to do the following in Rawhide (the future Fedora 21) :
> 
>   * Move the headers back to /usr/include, as upstream intended
>   * Put the event.h header into a libev-libevent-devel subpackage, and
> make it Conflicts: libevent-devel (this is what Debian did)
>   * Drop our pkgconfig file.
> 
> Here is the list of packages I could find with a build requirement on
> libev:
> 
>   $ repoquery --enablerepo=\*source --archlist=src --whatrequires 
> 'pkgconfig(libev)' libev-devel
>   awesome-0:3.5.1-8.fc20.src
>   i3-0:4.6-1.fc20.src
>   i3lock-0:2.5-2.fc20.src
>   libverto-0:0.2.5-3.fc20.src
>   ocaml-lwt-0:2.4.2-3.fc20.src
>   picviz-0:0.6-12.fc20.src
>   rubygem-passenger-0:4.0.18-2.fc20.src
>   rubygem-passenger-0:4.0.18-4.fc20.src
>   spectrum-0:1.4.8-11.fc20.src
>   stud-0:0.3-4.20120814git.fc20.src
>   weighttp-0:0.3-5.fc20.src
> 
> I'll fix weighttp, as it is my package, but I can't do much about the
> other ones.
> 
> I'm adding a breakdown of how these packages use libev and what needs to
> be done for them at the end of this email.
> 
> Does anybody have any comment, or objection?
> 
> Cheers,
> 
> 
> -- 
> Mathieu
> 
> 
> 
> awesome
> ---
> 
> Our package has some downstream patches to require our Fedora-only
> pkgconfig file for libev.
> 
> Making it build-require libev-devel instead and dropping this downstream
> patch should be enough.
> 
> i3
> --
> 
> Nothing should need to be done here.
> 
> Upstream checks for libev with pkg-config, but it ignores errors. And
> once I move the libev headers in /usr/include, then they'll be found
> anyway.
> 
> i3lock
> --
> 
> The spec file calls pkgconfig to find the libev headers.
> 
> This should just be removed, and the package should build just fine, as
> intended by upstream.
> 
> libverto
> 
> 
> Upstream itself requires the pkgconfig file for libev.
> 
> That's just a terrible idea, as it means libverto won't build on e.g
> Debian, or with the upstream libev.
> 
> libverto should be fixed upstream here IMHO.

Libverto builds against both libevent and libev being a event loop
abstraction library, if you make libev and libevent conflict libeverto
cannot be built anymore.

It makes not sense to make libev and libevent conflict, even if just in
development headers.

If upstream can;t see it then the distribution has to deal with it,
which is what has been done with the changes you noted.

Big -1 to revert those changes and breaking libverto in the process for
no good reason whatsoever.

CCed Nathaniel which is libverto's author.

Simo.

-- 
Simo Sorce * Red Hat, Inc * New York

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

Re: Packaging changes for libev in Rawhide

2013-11-23 Thread Matthew Garrett
On Sat, Nov 23, 2013 at 01:47:49PM -0500, Simo Sorce wrote:
> On Tue, 2013-11-19 at 15:30 +0800, Mathieu Bridon wrote:
> > Upstream itself requires the pkgconfig file for libev.
> > 
> > That's just a terrible idea, as it means libverto won't build on e.g
> > Debian, or with the upstream libev.
> > 
> > libverto should be fixed upstream here IMHO.
> 
> Libverto builds against both libevent and libev being a event loop
> abstraction library, if you make libev and libevent conflict libeverto
> cannot be built anymore.

But it requires patches to libev that aren't upstream in order to build? 
One alternative would be to package the libev headers twice, one in the 
upstream location and once in the Fedora-specific location. The latter 
package could then include the pkgconfig file.

This is still a bad solution. If libverto needs to link against both 
then libverto upstream should really work with libev and libevent 
upstream to find a solution that'll work for all distributions, rather 
than being limited to Fedora hacks.

-- 
Matthew Garrett | mj...@srcf.ucam.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

Unable to push to el5 branch

2013-11-23 Thread John Morris
Hi,

Attempt to update the el5 branch of the bcfg2 package results in an error:

  Counting objects: 1, done.
  Writing objects: 100% (1/1), 318 bytes | 0 bytes/s, done.
  Total 1 (delta 0), reused 0 (delta 0)
  remote: W refs/heads/el5 bcfg2 zultron DENIED by
  refs/heads/el[0-9]
  remote: error: hook declined to update refs/heads/el5
  To ssh://zult...@pkgs.fedoraproject.org/bcfg2
   ! [remote rejected] HEAD -> el5 (hook declined)
  error: failed to push some refs to
  'ssh://zult...@pkgs.fedoraproject.org/bcfg2'

I am a maintainer of the branch:

  https://admin.fedoraproject.org/pkgdb/acls/name/bcfg2#EL-5

And just moments before successfully pushed to the el6 branch:

  Counting objects: 1, done.
  Writing objects: 100% (1/1), 311 bytes | 0 bytes/s, done.
  Total 1 (delta 0), reused 0 (delta 0)
  remote: Emitting a message to the fedmsg bus.
  To ssh://zult...@pkgs.fedoraproject.org/bcfg2
 fe0e7e2..2d567d9  HEAD -> el6

What am I missing here?

John

-- 
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: Unable to push to el5 branch

2013-11-23 Thread Kevin Fenzi
On Sat, 23 Nov 2013 15:45:47 -0600
John Morris  wrote:

> Hi,
> 
> Attempt to update the el5 branch of the bcfg2 package results in an
> error:

...snip...

> What am I missing here?

You do not have the "commit" acl for that branch. 

You will need to login and request it and the owner 'fab' will need to
approve it. 

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

Re: Packaging changes for libev in Rawhide

2013-11-23 Thread Orcan Ogetbil
On Tue, Nov 19, 2013 at 7:36 AM, Michael Schwendt  wrote:
> On Tue, 19 Nov 2013 15:30:46 +0800, Mathieu Bridon wrote:
>>   * Move the headers back to /usr/include, as upstream intended
>>   * Put the event.h header into a libev-libevent-devel subpackage, and
>> make it Conflicts: libevent-devel (this is what Debian did)
>
> Seems plausible.
>
> Personally, I don't mind explicitly conflicting -devel packages,
> especially not if they are unlikely to be present in the same buildroot
> (and libev's event.h is a libevent compatibility header).

Can we have an event.h file that conditionally (or maybe even
unconditionally) #includes the appropriate header file from either
package? Both packages can then use the same event.h file without
conflicts.

Best,
Orcan
-- 
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: [pkgdb2] call for testers, bug reports and RFE

2013-11-23 Thread Dennis Gilmore
By using github you are also eliminating the possibility of some people to 
contribute to your project. I personally won't create an account on github. 
Just because I believe that open projects should be hosted on open platforms. 
I'd rather us work out a way to have an open patch submission and review 
process. 

There is pros and cons of each.

Dennis

Pierre-Yves Chibon  wrote:
>On Fri, Nov 22, 2013 at 02:34:28PM +0100, Kevin Kofler wrote:
>> Miro Hrončok wrote:
>> > The reason is simple. Fedorahosted lacks features, is unplesant and
>need
>> > byrocracy even to create a repository.
>> 
>> Creating a repository is actually the only time "bureaucracy" is
>required. 
>> Giving write permissions just works over FAS. (There's a FAS group
>for every 
>> repository that is created, the developer only needs to request group
>
>> membership through FAS and you can approve it, all self-service in
>FAS.) 
>> Clones, commits, pushes etc. are plain git (or SVN or whatever you
>chose! 
>> Fedorahosted is much more flexible than GitHub there) just as on
>GitHub or 
>> anywhere else. A Trac site is automatically created along with the 
>> repository if requested (you're expected to say in the repository
>request 
>> whether you want Trac or not, normally you should always say "yes"),
>it has 
>> bug trackers which work with FAS accounts (and Trac's issue tracker
>is no 
>> worse than GitHub's, they're actually very similar), a repository
>browser, 
>> and a wiki that you can edit (no "bureaucracy"). You also get a
>directory 
>> for file releases below https://fedorahosted.org/releases/ that
>accepts SCP 
>> uploads.
>> 
>> I really don't see what is missing there, apart from missing
>automation for 
>> the one-time creation process.
>
>You're forgeting, patch/code reviews, possibility to close or refer to
>a ticket
>from the git commit, the possibility to easily follow a project and be
>informed
>of its changes (yes, I know, you can create mailing list and have all
>the
>commits and action from the trac be sent to said list, I already do
>this for
>fedocal) and probably some more feature I'm forgetting.
>
>Anyway, did you see the link in the footer? The one that says 'pkgdb'?
>
>Pierre
>-- 
>devel mailing list
>devel@lists.fedoraproject.org
>https://admin.fedoraproject.org/mailman/listinfo/devel
>Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct