Re: Source file audit - 2013-11-17
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
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
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
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
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
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
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
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
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
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
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