Re: dist-git project update
On Fri, Jun 11, 2010 at 11:57 PM, Jesse Keating jkeat...@redhat.com wrote: The current url is pkgs.stg.fedoraproject.org/package and that works with git:// and ssh://. Any chance of making that work with http:// and https:// (for pushes) too? -- Iain. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
rawhide report: 20100612 changes
Compose started at Sat Jun 12 08:15:06 UTC 2010 Broken deps for i386 -- 1:anjuta-2.30.0.0-2.fc14.i686 requires libgladeui-1.so.9 blender-2.49b-6.fc13.i686 requires libgettextlib-0.17.so blenderplayer-2.49b-6.fc13.i686 requires libgettextlib-0.17.so cpanspec-1.78-5.fc14.noarch requires perl(IO::Uncompress::Bunzip2) dates-0.4.11-3.fc14.i686 requires libedataserver-1.2.so.11 deskbar-applet-2.30.0-1.1.fc14.i686 requires libedataserver-1.2.so.12 edje-0.9.93.063-1.fc14.i686 requires libecore-ver-svn-05.so.0 edje-0.9.93.063-1.fc14.i686 requires libembryo-ver-svn-05.so.0 edje-0.9.93.063-1.fc14.i686 requires libeina-ver-svn-05.so.0 edje-0.9.93.063-1.fc14.i686 requires libecore_evas-ver-svn-05.so.0 edje-0.9.93.063-1.fc14.i686 requires libecore_file-ver-svn-05.so.0 edje-0.9.93.063-1.fc14.i686 requires libecore_job-ver-svn-05.so.0 edje-0.9.93.063-1.fc14.i686 requires libecore_imf_evas-ver-svn-05.so.0 edje-0.9.93.063-1.fc14.i686 requires libevas-ver-svn-05.so.0 edje-0.9.93.063-1.fc14.i686 requires libecore_imf-ver-svn-05.so.0 edje-devel-0.9.93.063-1.fc14.i686 requires pkgconfig(ecore-job) efreet-0.5.0.063-1.fc14.i686 requires libeina-ver-svn-05.so.0 efreet-0.5.0.063-1.fc14.i686 requires libecore_file-ver-svn-05.so.0 efreet-0.5.0.063-1.fc14.i686 requires libecore-ver-svn-05.so.0 enlightenment-0.16.999.063-2.fc14.i686 requires libecore-ver-svn-05.so.0 enlightenment-0.16.999.063-2.fc14.i686 requires libedbus-ver-svn-05.so.0 enlightenment-0.16.999.063-2.fc14.i686 requires libeina-ver-svn-05.so.0 enlightenment-0.16.999.063-2.fc14.i686 requires libecore_evas-ver-svn-05.so.0 enlightenment-0.16.999.063-2.fc14.i686 requires libecore_con-ver-svn-05.so.0 enlightenment-0.16.999.063-2.fc14.i686 requires libehal-ver-svn-05.so.0 enlightenment-0.16.999.063-2.fc14.i686 requires libecore_file-ver-svn-05.so.0 enlightenment-0.16.999.063-2.fc14.i686 requires libecore_job-ver-svn-05.so.0 enlightenment-0.16.999.063-2.fc14.i686 requires libecore_input-ver-svn-05.so.0 enlightenment-0.16.999.063-2.fc14.i686 requires libecore_ipc-ver-svn-05.so.0 enlightenment-0.16.999.063-2.fc14.i686 requires libecore_x-ver-svn-05.so.0 enlightenment-0.16.999.063-2.fc14.i686 requires libecore_imf_evas-ver-svn-05.so.0 enlightenment-0.16.999.063-2.fc14.i686 requires libecore_txt-ver-svn-05.so.0 enlightenment-0.16.999.063-2.fc14.i686 requires libevas-ver-svn-05.so.0 enlightenment-0.16.999.063-2.fc14.i686 requires libecore_imf-ver-svn-05.so.0 enlightenment-devel-0.16.999.063-2.fc14.i686 requires pkgconfig(ecore-job) esperanza-0.4.0-6.fc13.i686 requires libxmmsclient++.so.3 esperanza-0.4.0-6.fc13.i686 requires libxmmsclient.so.5 evolution-couchdb-0.4.91-2.fc14.i686 requires libcamel-1.2.so.16 evolution-couchdb-0.4.91-2.fc14.i686 requires libcamel-provider-1.2.so.16 gambas-runtime-1.0.19-12.fc13.i686 requires libgettextlib-0.17.so gkrellxmms2-0.7.0-6.20090811git.fc13.i686 requires libxmmsclient.so.5 gnome-python2-brasero-2.30.0-5.fc14.i686 requires libbrasero-media.so.0 gnome-python2-brasero-2.30.0-5.fc14.i686 requires libbrasero-burn.so.0 gnome-python2-evolution-2.30.0-5.fc14.i686 requires libedataserver-1.2.so.12 gxmms2-0.7.0-6.20090811git.fc13.i686 requires libxmmsclient.so.5 highlight-3.0-0.1.fc14.i686 requires perl(MT::Plugin) highlight-3.0-0.1.fc14.i686 requires perl(MT::WeblogPublisher) highlight-3.0-0.1.fc14.i686 requires perl(MT::Entry) highlight-3.0-0.1.fc14.i686 requires perl(MT) highlight-3.0-0.1.fc14.i686 requires perl(MT::Template::Context) kobby-1.0-0.3.b4.fc13.i686 requires libinfinity-0.3.so.0 kobby-1.0-0.3.b4.fc13.i686 requires libinftext-0.3.so.0 kphotoalbum-4.1.1-5.fc13.i686 requires libmarblewidget.so.4 kphotoalbum-4.1.1-5.fc13.i686 requires libexiv2.so.6 libqinfinity-1.0-0.2.b4.fc13.i686 requires libinfinity-0.3.so.0 libqinfinity-1.0-0.2.b4.fc13.i686 requires libinftext-0.3.so.0 merkaartor-0.15.3-1.fc13.i686 requires libexiv2.so.6 perl-Sys-Virt-TCK-0.1.0-6.fc13.noarch requires perl(IO::Uncompress::Bunzip2) plexus-containers-component-annotations-javadoc-1.0-0.1.a34.7.fc12.noarch requires jakarta-commons-logging-javadoc qtgpsc-0.2.3-6.fc12.i686 requires libgps.so.18 rubygem-right_aws-1.10.0-3.fc14.noarch requires rubygem(right-http_connection) = 0:1.2.4 sound-juicer-2.28.2-2.fc14.i686 requires libbrasero-media.so.0 syncevolution-1.0beta3-2.fc14.i686 requires libedataserver-1.2.so.12 tasks-0.16-3.fc14.i686 requires libedataserver-1.2.so.12
Hey Presto!
You don't seem to be working all that good! I'm sure I'm not the only one seeing this. In particular: Transaction Summary Install 1 Package(s) Upgrade 85 Package(s) Total download size: 207 M Is this ok [y/N]: y Downloading Packages: Setting up and reading Presto delta metadata updates/prestodelta | 17 kB 00:00 Processing delta metadata Download delta size: 2.1 M (1/10): ModemManager-0.3-9.git20100409.fc12_0.3-13.git20 | 126 kB 00:00 (2/10): NetworkManager-0.8.0-6.git20100408.fc12_0.8.1-0. | 510 kB 00:00 (3/10): NetworkManager-glib-0.8.0-6.git20100408.fc12_0.8 | 106 kB 00:00 (4/10): NetworkManager-gnome-0.8.0-6.git20100408.fc12_0. | 301 kB 00:00 (5/10): NetworkManager-pptp-0.7.997-3.git20100120.fc12_0 | 47 kB 00:00 (6/10): NetworkManager-vpnc-0.7.996-4.git20090921.fc12_0 | 56 kB 00:00 (7/10): gstreamer-plugins-bad-free-0.10.18-1.fc12_0.10.1 | 339 kB 00:00 (8/10): gstreamer-plugins-good-0.10.22-1.fc12_0.10.23-1. | 427 kB 00:00 (9/10): libmtp-1.0.2-1.fc12_1.0.3-2.fc12.x86_64.drpm | 33 kB 00:00 (10/10): wpa_supplicant-0.6.8-8.fc12_0.6.8-9.fc12.x86_64 | 191 kB 00:00 Finishing rebuild of rpms, from deltarpms delta rebuild | 4.5 MB 00:03 Presto reduced the update size by 54% (from 4.5 M to 2.1 M). Package(s) data still to download: 202 M ...which includes the most recent openoffice.org update - a prime candidate for drpm goodness. Am I missing something obvious? -- Christopher Brown -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Hey Presto!
On Sat, Jun 12, 2010 at 5:24 PM, Christopher Brown snecklif...@gmail.com wrote: You don't seem to be working all that good! I'm sure I'm not the only one seeing this. In particular: Transaction Summary Install 1 Package(s) Upgrade 85 Package(s) Total download size: 207 M Is this ok [y/N]: y Downloading Packages: Setting up and reading Presto delta metadata updates/prestodelta | 17 kB 00:00 Processing delta metadata Download delta size: 2.1 M (1/10): ModemManager-0.3-9.git20100409.fc12_0.3-13.git20 | 126 kB 00:00 (2/10): NetworkManager-0.8.0-6.git20100408.fc12_0.8.1-0. | 510 kB 00:00 (3/10): NetworkManager-glib-0.8.0-6.git20100408.fc12_0.8 | 106 kB 00:00 (4/10): NetworkManager-gnome-0.8.0-6.git20100408.fc12_0. | 301 kB 00:00 (5/10): NetworkManager-pptp-0.7.997-3.git20100120.fc12_0 | 47 kB 00:00 (6/10): NetworkManager-vpnc-0.7.996-4.git20090921.fc12_0 | 56 kB 00:00 (7/10): gstreamer-plugins-bad-free-0.10.18-1.fc12_0.10.1 | 339 kB 00:00 (8/10): gstreamer-plugins-good-0.10.22-1.fc12_0.10.23-1. | 427 kB 00:00 (9/10): libmtp-1.0.2-1.fc12_1.0.3-2.fc12.x86_64.drpm | 33 kB 00:00 (10/10): wpa_supplicant-0.6.8-8.fc12_0.6.8-9.fc12.x86_64 | 191 kB 00:00 Finishing rebuild of rpms, from deltarpms delta rebuild | 4.5 MB 00:03 Presto reduced the update size by 54% (from 4.5 M to 2.1 M). Package(s) data still to download: 202 M ...which includes the most recent openoffice.org update - a prime candidate for drpm goodness. Am I missing something obvious? We don't generate deltas for packages with a size of = 100MB which kind of makes it useless for this case but it seems that delta generation is to expensive to do for such large packages on the re-eng boxes. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Hey Presto!
On Sat, Jun 12, 2010 at 05:27:32PM +0200, drago01 wrote: We don't generate deltas for packages with a size of = 100MB which kind of makes it useless for this case but it seems that delta generation is to expensive to do for such large packages on the re-eng boxes. It's because the program that generates the delta RPMs reads the whole RPMs into memory, according to: http://lwn.net/Articles/329484/ Anyone know if there's a genuine reason why it does it, or if it's just a Simple Matter Of Programming to fix it? (And can point us to the actual bit of code that could be fixed ...) Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones virt-p2v converts physical machines to virtual machines. Boot with a live CD or over the network (PXE) and turn machines into Xen guests. http://et.redhat.com/~rjones/virt-p2v -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Hey Presto!
On Sat, Jun 12, 2010 at 16:35, Richard W.M. Jones rjo...@redhat.com wrote: On Sat, Jun 12, 2010 at 05:27:32PM +0200, drago01 wrote: We don't generate deltas for packages with a size of = 100MB which kind of makes it useless for this case but it seems that delta generation is to expensive to do for such large packages on the re-eng boxes. It's because the program that generates the delta RPMs reads the whole RPMs into memory, according to: http://lwn.net/Articles/329484/ Anyone know if there's a genuine reason why it does it, or if it's just a Simple Matter Of Programming to fix it? (And can point us to the actual bit of code that could be fixed ...) There was in fact a request for volunteers about a month ago: http://lists.fedoraproject.org/pipermail/devel/2010-May/136090.html -- There are 10 kinds of people in the world: Those who understand binary and those who don't... -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Hey Presto!
On Sat, 2010-06-12 at 16:24 +0100, Christopher Brown wrote: You don't seem to be working all that good! I'm sure I'm not the only one seeing this. In particular: Transaction Summary Install 1 Package(s) Upgrade 85 Package(s) Total download size: 207 M Is this ok [y/N]: y Downloading Packages: Setting up and reading Presto delta metadata updates/prestodelta | 17 kB 00:00 Processing delta metadata Download delta size: 2.1 M (1/10): ModemManager-0.3-9.git20100409.fc12_0.3-13.git20 | 126 kB 00:00 (2/10): NetworkManager-0.8.0-6.git20100408.fc12_0.8.1-0. | 510 kB 00:00 (3/10): NetworkManager-glib-0.8.0-6.git20100408.fc12_0.8 | 106 kB 00:00 (4/10): NetworkManager-gnome-0.8.0-6.git20100408.fc12_0. | 301 kB 00:00 (5/10): NetworkManager-pptp-0.7.997-3.git20100120.fc12_0 | 47 kB 00:00 (6/10): NetworkManager-vpnc-0.7.996-4.git20090921.fc12_0 | 56 kB 00:00 (7/10): gstreamer-plugins-bad-free-0.10.18-1.fc12_0.10.1 | 339 kB 00:00 (8/10): gstreamer-plugins-good-0.10.22-1.fc12_0.10.23-1. | 427 kB 00:00 (9/10): libmtp-1.0.2-1.fc12_1.0.3-2.fc12.x86_64.drpm | 33 kB 00:00 (10/10): wpa_supplicant-0.6.8-8.fc12_0.6.8-9.fc12.x86_64 | 191 kB 00:00 Finishing rebuild of rpms, from deltarpms delta rebuild | 4.5 MB 00:03 Presto reduced the update size by 54% (from 4.5 M to 2.1 M). Package(s) data still to download: 202 M ...which includes the most recent openoffice.org update - a prime candidate for drpm goodness. Am I missing something obvious? Old deltarpms are being deleted after each push. This means that the openoffice.org deltarpms were only available for a day or two before being deleted. Yes, this is a bug. https://bugzilla.redhat.com/show_bug.cgi?id=598584 Jonathan signature.asc Description: This is a digitally signed message part -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Hey Presto!
On Sat, 2010-06-12 at 16:35 +0100, Richard W.M. Jones wrote: On Sat, Jun 12, 2010 at 05:27:32PM +0200, drago01 wrote: We don't generate deltas for packages with a size of = 100MB which kind of makes it useless for this case but it seems that delta generation is to expensive to do for such large packages on the re-eng boxes. It's because the program that generates the delta RPMs reads the whole RPMs into memory, according to: http://lwn.net/Articles/329484/ Anyone know if there's a genuine reason why it does it, or if it's just a Simple Matter Of Programming to fix it? (And can point us to the actual bit of code that could be fixed ...) For the record, openoffice.org-core comes under the size limit for deltarpm generation (which I think is closer to 200MB, but I may be wrong), which means we normally *do* get openoffice.org-core deltarpms. In my other email, I explained why we don't have them right now. As for the reason why, deltarpm currently compares *all* of the uncompressed old rpm against *all* of the uncompressed new rpm. This gives you the best possible delta at the expense of memory usage. I would like to allow deltarpm to split both old and new rpms into block and delta each block separately, but it would involve some very creative reworking on how deltarpm uses pseudo-files for all of it's work (see cfile.[ch] for the pseudo-file structure). I don't know if that's clear enough, feel free to ask if it's not. Jonathan signature.asc Description: This is a digitally signed message part -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: dist-git project update
Am 11.06.2010 23:57, schrieb Jesse Keating: ssh://. One advantage to using fedpkg clone is that if you like the current directory layout where each release is a subdir, you can do 'fedpkg clone --branches' and you'll get that layout. You can also do fedpkg clone -b branch and get a checkout of the specific branch It's seems, that this feature is not implemented in the current fedora-packager package. when I try to make a fedpkg cloone --branches I will get only a message which describe the function for this command without any visible result. Best Regards: Jochen Schmitt -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
