Re: delta rpms - can we turn them off
On Mon, Jun 30, 2014 at 3:01 AM, Jon wrote: > On Sun, Jun 29, 2014 at 7:42 PM, Stephen John Smoogen > wrote: >> > [snip] >> >> Personally I would just say don't make delta-rpms for i386 and arm or just >> have deltarpm=1 on those architectures by default. > > Or all architectures even. > This should, in my opinion, be disabled by default. > The default-off setting should be self-documented in the config, so > that it could be easily found and toggled on/off. No the current state (save bandwidth by default for both clients and mirrors) is fine. If someone really wants to always download all of them he/she should opt out. -- 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: Mule Orphaned Package
How many patches needed for the latest mule? Are these[1] merged already? [1]---http://pkgs.fedoraproject.org/cgit/mule.git/tree/ -- 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: delta rpms - can we turn them off
On Sun, Jun 29, 2014 at 7:42 PM, Stephen John Smoogen wrote: > [snip] > > Personally I would just say don't make delta-rpms for i386 and arm or just > have deltarpm=1 on those architectures by default. Or all architectures even. This should, in my opinion, be disabled by default. The default-off setting should be self-documented in the config, so that it could be easily found and toggled on/off. This should please the masochists, or people with very slow internet. Meanwhile, we can bikeshed on how to optimise the feature. Eventually somebody will make the changes that cause DRPMs to suck slightly less. At that future time we can reevaluate if we rewards are worth the aggravations. -- -Jon -- 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: delta rpms - can we turn them off
On 29 June 2014 15:34, Kevin Fenzi wrote: > On Sun, 29 Jun 2014 14:20:44 -0700 > Jonathan Dieter wrote: > > > We can do this, but createrepo would need to store the checksum of 0 > > level compressed xz rpms in primary, which involve making createrepo > > decompress each rpm and then recompress at level 0. Not sure what > > the infra folks think about this. > > Do not like. :( > > Also, thinking about it, if any proposed changes need us to sign drpms > thats probably a non starter too. Since it would mean signing rpms, > starting push, generating the drpms and then stopping and signing all > of them too and then resuming. Also changes in mash and bodhi1. > Personally I would just say don't make delta-rpms for i386 and arm or just have deltarpm=1 on those architectures by default. -- Stephen J Smoogen. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Mule Orphaned Package
On Sun, Jun 29, 2014 at 10:59 AM, tspaul...@yahoo.com wrote: > Hi All, > > I'm a mule developer and fedora user. Recently, I noticed that the version > of mule packaged with fedora is not only very behind the current upstream > version but it is also orphaned. I'd like to take over maintaining the > packaging of mule on fedora if there are no objections. This was originally my package; it was packaged as part of the effort to get Eucalyptus into Fedora a few releases ago, and at the time I packaged something close to what upstream Eucalyptus code bundled as a dependency. Thankfully, Eucalyptus updated most of their dependencies in 4.0, so there should be nothing depending on the old version now. Andy > Thanks, > > Tim > > -- > devel mailing list > devel@lists.fedoraproject.org > https://admin.fedoraproject.org/mailman/listinfo/devel > Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
[Test-Announce] 2014-06-30 @ 15:00 UTC - Fedora QA Meeting
# Fedora Quality Assurance Meeting # Date: 2014-06-30 # Time: 15:00 UTC (https://fedoraproject.org/wiki/Infrastructure/UTCHowto) # Location: #fedora-meeting on irc.freenode.net Greetings testers! This is a reminder of the upcoming QA meeting. Please reply to this mail with any suggestions for additions to the agenda. The current proposed agenda is included below. If no topics beyond the standard "Previous meeting follow-up" and "Open Discussion" topics are present or proposed, the meeting will be cancelled. == Proposed Agenda Topics == 1. Fedora 21 Status Updates A. Blocker Status - Count and Any especially worrysome ones? B. roshi and/or pschindl report on Test Days - See Action Item from 2014-06-09 meeting notes C. Rawhide Testing Status 2. Taskotron Discussion A. Status Report B. bodhi2 integration discussion? 3. Alpha Release Related Items ?? 4. Open Floor Anyone with additional agenda items please respond to the mailing list this weekend. If you hit send after 0400 Monday they probably won't make the meeting and you'll have to raise them during Open Floor. Sincerely, Mike Ruckman signature.asc Description: PGP signature ___ test-announce mailing list test-annou...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/test-announce-- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: delta rpms - can we turn them off
On Sun, 29 Jun 2014 14:20:44 -0700 Jonathan Dieter wrote: > We can do this, but createrepo would need to store the checksum of 0 > level compressed xz rpms in primary, which involve making createrepo > decompress each rpm and then recompress at level 0. Not sure what > the infra folks think about this. Do not like. :( Also, thinking about it, if any proposed changes need us to sign drpms thats probably a non starter too. Since it would mean signing rpms, starting push, generating the drpms and then stopping and signing all of them too and then resuming. Also changes in mash and bodhi1. 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: Mule Orphaned Package
On Sun, Jun 29, 2014 at 10:59:22AM -0400, tspaul...@yahoo.com wrote: > Hi All, > > I'm a mule developer and fedora user. Recently, I noticed that the version > of mule packaged with fedora is not only very behind the current upstream > version but it is also orphaned. I'd like to take over maintaining the > packaging of mule on fedora if there are no objections. https://admin.fedoraproject.org/pkgdb/package/mule/ It looks like the package is currently orphaned, so you can take it over without asking anyone, once you become a packager. To become a packager you need to look at these pages: https://fedoraproject.org/wiki/Join_the_package_collection_maintainers https://fedoraproject.org/wiki/How_to_get_sponsored_into_the_packager_group Best of luck, Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming and virtualization blog: http://rwmj.wordpress.com virt-builder quickly builds VMs from scratch http://libguestfs.org/virt-builder.1.html -- 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: delta rpms - can we turn them off
On 06/29/2014 04:36 AM, Florian Weimer wrote: On 06/29/2014 12:32 PM, drago01 wrote: On Sun, Jun 29, 2014 at 1:55 AM, Jonathan Dieter wrote: 2. RPM would also need to support signatures across the uncompressed payload as well as the compressed payload. Well Florian said that only the header is actually signed not the payload. So this shouldn't be necessary. I missed that the information that the payload is XZ-compressed is likely signed (hard to tell because the current RPM format isn't documented). So we'd need a fake XZ implementation that produces an essentially uncompressed data stream (xz -0 still compresses). In the meantime, we could try to reduce the compression level to 0 unconditionally in applydeltarpm. We can do this, but createrepo would need to store the checksum of 0 level compressed xz rpms in primary, which involve making createrepo decompress each rpm and then recompress at level 0. Not sure what the infra folks think about this. I may run some tests over the next few weeks to see what implementing this would actually take. I am on a two-month vacation, so no promises on how quick I'll be. Jonathan -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Mule Orphaned Package
Hi All, I'm a mule developer and fedora user. Recently, I noticed that the version of mule packaged with fedora is not only very behind the current upstream version but it is also orphaned. I'd like to take over maintaining the packaging of mule on fedora if there are no objections. Thanks, Tim -- 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: delta rpms - can we turn them off
On 06/29/2014 12:32 PM, drago01 wrote: On Sun, Jun 29, 2014 at 1:55 AM, Jonathan Dieter wrote: 2. RPM would also need to support signatures across the uncompressed payload as well as the compressed payload. Well Florian said that only the header is actually signed not the payload. So this shouldn't be necessary. I missed that the information that the payload is XZ-compressed is likely signed (hard to tell because the current RPM format isn't documented). So we'd need a fake XZ implementation that produces an essentially uncompressed data stream (xz -0 still compresses). In the meantime, we could try to reduce the compression level to 0 unconditionally in applydeltarpm. -- Florian Weimer / Red Hat Product Security -- 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: delta rpms - can we turn them off
On 06/29/2014 12:34 PM, drago01 wrote: > Well they should (or have some other source of documentation) ... the > config file isn't really the right place for documentation, given > that it does not get updated once you have edited it once ... you will > miss new options / changed semantics that way. This is way you keep an eye an any *.rpmsave, *.rpmnew and merge the differences (with a proper tool, like "meld"). -- Roberto Ragusamail at robertoragusa.it -- 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: delta rpms - can we turn them off
drago01 gmail.com> writes: > Well they should (or have some other source of documentation) ... the > config file isn't really the right place for documentation, given > that it does not get updated once you have edited it once ... you will > miss new options / changed semantics that way. Yes, that makes sense. But the config file could at least have a commented line at the top referring to the corresponding man page or other separate documentation, if it exists. -- 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: delta rpms - can we turn them off
On Sun, Jun 29, 2014 at 12:09 PM, Andre Robatino wrote: > Rahul Sundaram gmail.com> writes: > >> All that being said, what is the criteria for getting a default >> configuration line put into yum.conf? >> I'd really like to get the deltarpm= line put in there. >> >> >> File a bug report in yum bug tracker or Red Hat bugzilla against yum as > the component. Do the same for dnf > > More generally, all existing options should have a commented line in the > config file. In fact, this should probably be true for all config files in > all packages. Not all packages have special man pages for their config > files, like yum and dnf do [...] Well they should (or have some other source of documentation) ... the config file isn't really the right place for documentation, given that it does not get updated once you have edited it once ... you will miss new options / changed semantics that way. -- 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: delta rpms - can we turn them off
On Sun, Jun 29, 2014 at 1:55 AM, Jonathan Dieter wrote: > 2. RPM would also need to support signatures across the uncompressed payload > as well as the compressed payload. Well Florian said that only the header is actually signed not the payload. So this shouldn't be necessary. > 3. Deltarpm would need to be patched to build non-compressed rpms when > rebuilding the deltarpms. > > As the maintainer of deltarpm, I can easily do (3), but there didn't seem to > be much buy-in for (1) and (2) the last time I suggested it (no references; > I can't seem to find the previous thread in the archives). > > Please note that this would severely reduce the need for CPU during the > deltarpm rebuild process, but at the expense of increasing IO as we're > writing an uncompressed RPM. Given how expensive xz compression is that should sitll be a win. On a fast system where the compression does not hurt so much you are likely have enough memory for I/O not to be much on an issue for moderately sized updates. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
rawhide report: 20140629 changes
Broken deps for i386 -- [APLpy] APLpy-0.9.8-5.fc21.noarch requires pywcs [IQmol] IQmol-2.2.0-9.fc21.i686 requires libQGLViewer.so.2.3.9 [PyKDE] PyKDE-3.16.6-14.fc20.i686 requires sip-api(10) >= 0:10.0 [PyQuante] PyQuante-libint-1.6.4-10.fc21.i686 requires libint(x86-32) = 0:1.1.6-1.fc21 [SkyX] SkyX-0.4-6.fc21.i686 requires libOgreMain.so.1.8.1 [audtty] audtty-0.1.12-9.fc20.i686 requires libaudclient.so.2 [aws] aws-devel-3.1.0-6.fc21.i686 requires libgrypt-devel [compat-gcc-34] compat-gcc-34-c++-3.4.6-29.fc19.i686 requires libstdc++ < 0:4.9.0 [csound] csound-java-5.19.01-1.fc20.i686 requires libgcj_bc.so.1 csound-java-5.19.01-1.fc20.i686 requires java-gcj-compat csound-java-5.19.01-1.fc20.i686 requires java-gcj-compat csound-java-5.19.01-1.fc20.i686 requires java-1.5.0-gcj csound-tk-5.19.01-1.fc20.i686 requires libtk8.5.so csound-tk-5.19.01-1.fc20.i686 requires libtcl8.5.so [deltacloud-core] deltacloud-core-rackspace-1.1.3-1.fc20.noarch requires rubygem(cloudfiles) [dragonegg] dragonegg-3.4-0.3.rc0.fc21.i686 requires gcc = 0:4.8.2-14.fc21 [dsqlite] dsqlite-1.1.1-1.fc20.i686 requires libphobos-ldc.so.63 [edelib] edelib-2.1-4.fc21.i686 requires libedelib.so edelib-devel-2.1-4.fc21.i686 requires libedelib.so [eucalyptus] eucalyptus-common-java-3.3.0-0.5.20130408git32052445.fc20.i686 requires hibernate3-jbosscache >= 0:3.6.10-7 [fedora-dockerfiles] fedora-dockerfiles-0-0.6.git122ef5d.fc21.noarch requires docker-io [flashrom] flashrom-0.9.6.1-5.svn1705.fc20.i686 requires libftdi.so.1 [gcc-python-plugin] gcc-python2-debug-plugin-0.12-18.fc21.i686 requires gcc = 0:4.8.2-14.fc21 gcc-python2-plugin-0.12-18.fc21.i686 requires gcc = 0:4.8.2-14.fc21 gcc-python3-debug-plugin-0.12-18.fc21.i686 requires libpython3.3dm.so.1.0 gcc-python3-debug-plugin-0.12-18.fc21.i686 requires gcc = 0:4.8.2-14.fc21 gcc-python3-plugin-0.12-18.fc21.i686 requires libpython3.3m.so.1.0 gcc-python3-plugin-0.12-18.fc21.i686 requires gcc = 0:4.8.2-14.fc21 [gitg] gitg-0.3.2-2.fc21.i686 requires libgit2.so.0 gitg-libs-0.3.2-2.fc21.i686 requires libgit2.so.0 [gnome-pie] gnome-pie-0.5.5-3.20130330git0a5aa2.fc20.i686 requires libbamf3.so.0 [gnome-python2-desktop] gnome-python2-metacity-2.32.0-18.fc21.i686 requires libmetacity-private.so.0 [gofer] ruby-gofer-0.77.1-2.fc21.noarch requires rubygem(qpid) >= 0:0.16.0 [golang-github-smarterclayton-go-systemd] golang-github-smarterclayton-go-systemd-devel-0-0.5.git5cb9e9e.fc21.noarch requires golang(github.com/guelfey/go.dbus) [grass] grass-6.4.3-5.fc21.i686 requires libtk8.5.so grass-6.4.3-5.fc21.i686 requires libtcl8.5.so [hfsutils] hfsutils-x11-3.2.6-24.fc20.i686 requires libtk8.5.so hfsutils-x11-3.2.6-24.fc20.i686 requires libtcl8.5.so [ibutils] ibutils-1.5.7-10.fc20.i686 requires libtcl8.5.so ibutils-libs-1.5.7-10.fc20.i686 requires libtcl8.5.so [ice] ice-php-3.5.1-4.fc21.i686 requires php(zend-abi) = 0:20121212-32 ice-php-3.5.1-4.fc21.i686 requires php(api) = 0:20121113-32 [leiningen] leiningen-1.7.1-7.fc20.noarch requires maven-ant-tasks leiningen-1.7.1-7.fc20.noarch requires classworlds [libghemical] libghemical-2.99.1-24.fc20.i686 requires libf77blas.so.3 libghemical-2.99.1-24.fc20.i686 requires libatlas.so.3 [libopensync-plugin-irmc] 1:libopensync-plugin-irmc-0.22-7.fc20.i686 requires libopenobex.so.1 [magic] magic-8.0.60-6.fc20.i686 requires libtk8.5.so magic-8.0.60-6.fc20.i686 requires libtcl8.5.so [mapserver] mapserver-java-6.2.1-7.fc21.i686 requires java-gcj-compat [meshmagick] meshmagick-0.6.0-20.svn2898.fc21.i686 requires libOgreMain.so.1.8.1 meshmagick-libs-0.6.0-20.svn2898.fc21.i686 requires libOgreMain.so.1.8.1 [mingw-tk] mingw32-tk-8.5.13-5.fc21.noarch requires mingw32(tcl85.dll) [mpqc] mpqc-2.3.1-23.fc20.i686 requires libf77blas.so.3 mpqc-2.3.1-23.fc20.i686 requires libatlas.so.3 [nautilus-actions] nautilus-actions-3.2.2-4.fc20.i686 requires libgtop-2.0.so.7 [netdisco] netdisco-1.1-7.fc21.noarch requires perl(SNMP::Info::Layer2::Bay) [nodejs-grunt-contrib-uglify] nodejs-grunt-contrib-uglify-0.4.0-4.fc21.noarch requires npm(maxmin) < 0:0.2 [openbox] gnome-panel-control-3.5.2-4.fc21.i686 requires gnome-panel [openvas-client] openvas-client-3.0.3-8.fc20.i686 requires libopenvas_omp.so.6 openvas-client-3.0.3-8.fc20.i686 requires libopenvas_nasl.so.6 openvas-client-3.0.3-8.fc20.i686 requires libopenvas_misc.so.6 openvas-client-3.0.3-8.fc20.i686 requires libopenvas_hg.so.6 openvas-client-3.0.3-8.fc20.i686 requires libopenvas_b
Re: delta rpms - can we turn them off
Rahul Sundaram gmail.com> writes: > All that being said, what is the criteria for getting a default > configuration line put into yum.conf? > I'd really like to get the deltarpm= line put in there. > > > File a bug report in yum bug tracker or Red Hat bugzilla against yum as the component. Do the same for dnf More generally, all existing options should have a commented line in the config file. In fact, this should probably be true for all config files in all packages. Not all packages have special man pages for their config files, like yum and dnf do, and life is easier if every config file is self-documenting. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
