Re: critpath approval process seems rather broken
On 04/10/2011 07:39 PM, Bruno Wolff III wrote: > On Sun, Apr 10, 2011 at 18:19:26 -0700, > Christopher Aillon wrote: >> >> I just realized today for the first time that our nightlies are based on >> stable, not testing. I think that's something we need to address. It's >> probably still useful to have nightlies based on stable, but I think >> it's rather vital to have images created with the updates in the queue. > > The nightlies are intended to be made from stable, so that they are more > likely to work and near releases (including test ones) corrsepond to > the upcoming release. I definitely agree that the nightlies need to be made from stable sources. OTOH, the process for testing anything that is part of the installation process (anaconda, lorax, mdadm ...) seems to be more of a PITA than it really needs to be (someone has to build the .iso manually and push it to fedorapeople in order to share it). >> So, yes, -testing is the default for f15 installs, but the problem is >> you have to get 15 installed first, at which point you can't test the >> live image/installer part of the critical path, since you are now in an >> installed environment, not a live image/installer. > > There may need to be special instructions for testing things that get included > in the initramfs to get them tested. Another option would be to make it easier to build and host images build from testing for updates that affect the installation process. I'll have to think about realistic ways that would be possible unless someone else has an idea. Until then, instructions would help or someone is going to have to build and push the testing image by hand. Tim signature.asc Description: OpenPGP digital signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: critpath approval process seems rather broken
On 04/10/2011 06:39 PM, Bruno Wolff III wrote: > On Sun, Apr 10, 2011 at 18:19:26 -0700, >Christopher Aillon wrote: >> >> I just realized today for the first time that our nightlies are based on >> stable, not testing. I think that's something we need to address. It's >> probably still useful to have nightlies based on stable, but I think >> it's rather vital to have images created with the updates in the queue. > > The nightlies are intended to be made from stable Yes, and I already agreed that it's good that we have them. But not having a set of nightlies based on testing is a problem, and I think we really really need to fix that. I see no reason we need to pick one or the other, let's do both! -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: critpath approval process seems rather broken
On 04/11/2011 12:13 AM, Tim Flink wrote: > On 04/10/2011 07:39 PM, Bruno Wolff III wrote: >> On Sun, Apr 10, 2011 at 18:19:26 -0700, >>Christopher Aillon wrote: >>> >>> I just realized today for the first time that our nightlies are based on >>> stable, not testing. I think that's something we need to address. It's >>> probably still useful to have nightlies based on stable, but I think >>> it's rather vital to have images created with the updates in the queue. >> >> The nightlies are intended to be made from stable, so that they are more >> likely to work and near releases (including test ones) corrsepond to >> the upcoming release. > > I definitely agree that the nightlies need to be made from stable sources. And I did too. I also agree that we need to get nightlies made with testing. I don't think this is an either-or situation. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: critpath approval process seems rather broken
On 04/09/2011 05:31 AM, drago01 wrote: > On Sat, Apr 9, 2011 at 12:57 PM, Tomasz Torcz wrote: >> On Sat, Apr 09, 2011 at 05:32:04AM +0200, Kevin Kofler wrote: >>> Will Woods wrote: In fact, there's plenty of approvers available, but you're not engaging with them. They might not know how to test libtiff, or what needs testing, so other stuff gets tested first. >>> >>> The fact is, this is a SECURITY UPDATE and as such it should go out even >>> without testing. It's not acceptable to sit on security updates for weeks. >> >> No, security updates are not _that_ special. For example, there's >> an avahi update in pipeline. It has broken dependencies. Pushing this >> would broke some systems. I'm talking about: >> https://admin.fedoraproject.org/updates/avahi-0.6.27-6.fc14 > > Packages with broken dependencies should just be unpushable (autoqa > was supposed to fix this but not sure what happend to it ...) > > We really should do an automated dep check before pushing updates (and > reject those with broken deps). Actually, we are running automated dependency checks on builds. Comments should be re-enabled in bodhi soon (in the next couple of days unless something changes) but as Adam said, everything is just a warning for now - no automation is preventing the push of updates with broken dependencies. I may be biased, but I know that I'm looking forward to the new depcheck and upgradepath goodness :) Tim signature.asc Description: OpenPGP digital signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: critpath approval process seems rather broken
On 04/11/2011 01:21 AM, Christopher Aillon wrote: > On 04/11/2011 12:13 AM, Tim Flink wrote: >> On 04/10/2011 07:39 PM, Bruno Wolff III wrote: >>> On Sun, Apr 10, 2011 at 18:19:26 -0700, >>>Christopher Aillon wrote: I just realized today for the first time that our nightlies are based on stable, not testing. I think that's something we need to address. It's probably still useful to have nightlies based on stable, but I think it's rather vital to have images created with the updates in the queue. >>> >>> The nightlies are intended to be made from stable, so that they are more >>> likely to work and near releases (including test ones) corrsepond to >>> the upcoming release. >> >> I definitely agree that the nightlies need to be made from stable >> sources. > > And I did too. I also agree that we need to get nightlies made with > testing. I don't think this is an either-or situation. Good point, I didn't mean to imply that it had to be one or the other; just that testing-based nightlies alone aren't enough. My next questions would be: - Is this needed often enough to justify building another nightly? -> Or would it be more effort than it's worth to build testing based nightlies on a less regular basis? - If so, what would need to be done in order to propose this and hopefully see it happen? Tim signature.asc Description: OpenPGP digital signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: dependencies on mod_perl-devel in rawhide
On 11/04/11 07:30, David Tardon wrote: > In current rawhide, > > repoquery --whatrequires mod_perl-devel > > returns > > mod_perl-devel-0:2.0.5-1.fc16.i686 > mod_perl-devel-0:2.0.5-1.fc16.x86_64 > BackupPC-0:3.1.0-17.fc15.x86_64 > MySQL-zrm-0:2.2.0-2.fc15.noarch > Perlbal-0:1.78-1.fc15.noarch > Sprog-0:0.14-20.fc15.noarch > TeXmacs-0:1.0.7.10-1.fc16.x86_64 > ack-0:1.92-3.fc15.noarch > amanda-0:3.2.2-1.fc16.x86_64 > amanda-client-0:3.2.2-1.fc16.x86_64 > amanda-server-0:3.2.2-1.fc16.x86_64 > amavisd-new-0:2.6.4-3.fc15.noarch > amavisd-new-snmp-0:2.6.4-3.fc15.noarch > amsn-plugins-0:0.98.4-1.fc15.x86_64 > amtterm-0:1.2-4.fc15.x86_64 > arp-scan-0:1.7-5.fc15.x86_64 > asciio-0:1.02.71-8.fc15.noarch > backup-manager-0:0.7.10-2.fc15.noarch > bfast-0:0.6.4e-2.fc15.x86_64 > blazeblogger-0:1.2.0-1.fc16.noarch > bucardo-0:4.4.0-3.fc15.noarch > bugzilla-0:4.0-1.fc16.noarch > bugzilla-contrib-0:4.0-1.fc16.noarch > bwa-0:0.5.9-1.fc16.x86_64 > centerim-1:4.22.10-1.fc15.x86_64 > check_postgres-0:2.16.0-1.fc16.noarch > checkgmail-0:1.13-8.20091022svn.fc15.noarch > clamtk-0:4.31-2.fc15.noarch > clang-analyzer-0:2.9-0.1.rc2.fc16.x86_64 > clive-0:2.3.0.2-1.fc16.noarch > clusterssh-0:3.28-3.fc15.noarch > collectd-web-0:4.10.3-1.fc16.x86_64 > condor-0:7.5.5-2.fc15.x86_64 > cpan-upload-0:2.2-8.fc15.noarch > cpanspec-0:1.78-7.fc15.noarch > cpm-0:0.23-0.3.beta.fc12.x86_64 > crossfire-maps-0:1.11.0-4.fc15.noarch > crypto-utils-0:2.4.1-27.x86_64 > cvsweb-0:3.0.6-10.fc15.noarch > dayplanner-0:0.10-3.fc15.noarch > dnsenum-0:1.2-5.fc15.noarch > dpkg-0:1.15.5.6-7.fc15.x86_64 > dpkg-devel-0:1.15.5.6-7.fc15.noarch > drbd-utils-0:8.3.9-1.fc16.x86_64 > drraw-0:2.2-0.7.b2.fc15.noarch > dselect-0:1.15.5.6-7.fc15.x86_64 > eg-0:0.97-6.fc15.noarch > fence-agents-0:3.1.3-1.fc16.x86_64 > fldigi-0:3.21.7-1.fc16.x86_64 > freeradius-utils-0:2.1.10-5.fc16.x86_64 > frozen-bubble-0:2.2.0-7.fc15.x86_64 > geda-utils-1:1.6.2-1.fc16.x86_64 > git-0:1.7.4.2-1.fc16.x86_64 > git-arch-0:1.7.4.2-1.fc16.noarch > git-bugzilla-0:0-0.5.20091211git.fc15.noarch > git-cpan-patch-0:0.4.6-3.fc15.noarch > git-cvs-0:1.7.4.2-1.fc16.noarch > git-email-0:1.7.4.2-1.fc16.noarch > git-svn-0:1.7.4.2-1.fc16.noarch > gitolite-0:2.0-1.fc16.noarch > gitweb-0:1.7.4.2-1.fc16.noarch > gitweb-caching-0:1.6.5.2-9.b1ab8b5.fc15.noarch > glib2-devel-0:2.28.5-2.fc15.i686 > glib2-devel-0:2.28.5-2.fc15.x86_64 > glibmm24-devel-0:2.28.0-1.fc16.i686 > glibmm24-devel-0:2.28.0-1.fc16.x86_64 > globus-gram-job-manager-setup-sge-0:2.5-2.fc15.noarch > globus-gss-assist-progs-0:5.9-3.fc15.x86_64 > gmusicbrowser-0:1.1.7-1.fc16.noarch > google-perftools-0:1.7-2.fc16.i686 > google-perftools-0:1.7-2.fc16.x86_64 > gpsdrive-0:2.11-3.fc16.x86_64 > gridengine-0:6.2u5-7.fc15.i686 > gridengine-0:6.2u5-7.fc15.x86_64 > groff-perl-0:1.21-2.fc15.x86_64 > gscan2pdf-0:0.9.32-1.fc16.noarch > hct-0:0.7.60-4.fc15.noarch > hivex-0:1.2.4-7.fc15.i686 > hivex-0:1.2.4-7.fc15.x86_64 > honeyd-0:1.5c-13.fc15.x86_64 > html2wiki-0:0.68-6.fc15.noarch > hyperestraier-perl-0:1.4.13-7.fc15.x86_64 > i3-0:3.e-6.bf2.fc15.x86_64 > ikiwiki-0:3.20110321-1.fc16.noarch > imapsync-0:1.404-3.fc16.noarch > imvirt-0:0.9.0-2.fc15.x86_64 > inkscape-0:0.48.1-4.fc16.x86_64 > inn-0:2.5.2-5.fc15.x86_64 > innotop-0:1.6.0-7.fc15.noarch > kcbench-data-2.6.35-0:0.1-7.1.noarch > kdesdk-0:4.6.2-1.fc16.x86_64 > kfilefactory-0:0.1.1-2.fc15.noarch > krazy2-0:2.90-10.20100926svn.fc15.i686 > krazy2-0:2.90-10.20100926svn.fc15.x86_64 > ksplice-0:0.9.9-2.fc15.x86_64 > lagan-0:2.0-7.fc15.x86_64 > latexmk-0:4.23-1.fc16.noarch > libguestfs-tools-1:1.9.18-2.fc16.x86_64 > liboping-0:1.5.1-2.fc15.i686 > liboping-0:1.5.1-2.fc15.x86_64 > libpurple-perl-0:2.7.11-2.fc16.x86_64 > llvm-devel-0:2.9-0.1.rc2.fc16.i686 > llvm-devel-0:2.9-0.1.rc2.fc16.x86_64 > logcheck-0:1.3.13-6.fc15.noarch > m2vmp2cut-0:0.79-6.fc15.x86_64 > maatkit-0:7332-1.fc16.noarch > mediawiki-nomath-0:1.16.2-56.fc16.x86_64 > mhonarc-0:2.6.18-3.fc16.noarch > mimedefang-0:2.71-2.fc15.x86_64 > mm-common-0:0.9.5-1.fc16.noarch > mod_perl-0:2.0.5-1.fc16.x86_64 > mod_perlite-0:0.10-4.fc15.x86_64 > mogilefsd-0:2.36-2.fc15.noarch > mogstored-0:2.36-2.fc15.noarch > mojomojo-0:1.04-1.fc16.noarch > mon-0:1.2.0-7.fc15.x86_64 > moreutils-0:0.40-2.fc15.x86_64 > mr-0:1.02-1.fc16.noarch > munin-0:1.4.5-8.fc15.noarch > munin-common-0:1.4.5-8.fc15.noarch > munin-node-0:1.4.5-8.fc15.noarch > mysql-mmm-0:2.2.1-3.fc15.noarch > mysql-mmm-agent-0:2.2.1-3.fc15.noarch > mysql-mmm-monitor-0:2.2.1-3.fc15.noarch > mysql-mmm-tools-0:2.2.1-3.fc15.noarch > mysql-test-0:5.5.10-2.fc16.x86_64 > mysqltuner-0:1.2.0-1.fc15.noarch > mythtv-backend-0:0.24-7.fc15.x86_64 > mythvideo-0:0.24-7.fc15.x86_64 > mythweather-0:0.24-7.fc15.x86_64 > nagios-plugins-check-updates-0:1.4.11-2.fc15.x86_64 > ncid-0:0.81-1.fc16.x86_64 > net-snmp-perl-1:5.6.1-7.fc16.x86_64 > netcdf-perl-0:1.2.4-7.fc16.x86_64 > nginx-0:0.8.53-6.fc15.x86_64 > nopaste-1:0.28-1.fc16.noarch > nufw-utils-0:2.4.3-4.fc16.x86_64 > nuxwdog-0:1.0.1-2.fc15.i686 > nuxwdog-0:1.0.1-2.fc15.x86_64 > ocsin
rawhide report: 20110411 changes
Compose started at Mon Apr 11 08:15:02 UTC 2011 Broken deps for x86_64 -- GMT-4.5.6-1.fc15.i686 requires libnetcdf.so.6 GMT-4.5.6-1.fc15.x86_64 requires libnetcdf.so.6()(64bit) HippoDraw-python-1.21.1-14.fc15.x86_64 requires libboost_python.so.1.46.0()(64bit) QuantLib-test-1.0.1-6.fc15.x86_64 requires libboost_unit_test_framework.so.1.46.0()(64bit) bzrtools-2.3.1-2.fc15.x86_64 requires bzr < 0:2.4 callweaver-javascript-1.2.1-8.fc16.x86_64 requires libjs.so.1()(64bit) castor-0.9.5-6.fc15.1.x86_64 requires oro couchdb-1.0.2-2.fc16.x86_64 requires libjs.so.1()(64bit) cpm-0.23-0.3.beta.fc12.x86_64 requires libdotconf-1.0.so.0()(64bit) db4o-7.4-2.fc13.x86_64 requires mono(Mono.GetOptions) = 0:2.0.0.0 dbmail-3.0.0-0.3.rc1.fc15.x86_64 requires libevent-1.4.so.2()(64bit) dbmail-auth-ldap-3.0.0-0.3.rc1.fc15.x86_64 requires libevent-1.4.so.2()(64bit) dh-make-0.55-3.fc15.noarch requires debhelper django-dpaste-0.2.4-3.fc16.noarch requires django-mptt easystroke-0.5.3-4.fc15.x86_64 requires libboost_serialization-mt.so.1.46.0()(64bit) ekiga-3.3.0-6.fc15.x86_64 requires libboost_signals-mt.so.1.46.0()(64bit) elinks-0.12-0.24.pre5.fc15.x86_64 requires libjs.so.1()(64bit) emerillon-0.1.2-14.fc15.x86_64 requires libchamplain-gtk-0.8.so.1()(64bit) emerillon-0.1.2-14.fc15.x86_64 requires libchamplain-0.8.so.1()(64bit) erlang-js-0.5.0-2.fc16.x86_64 requires libjs.so.1()(64bit) esperanza-0.4.0-9.20100601git.fc15.x86_64 requires libboost_signals-mt.so.1.46.0()(64bit) fawkes-plugin-player-0.4.2-3.fc16.x86_64 requires libboost_signals-mt.so.1.46.0()(64bit) fawkes-plugin-player-0.4.2-3.fc16.x86_64 requires libboost_thread-mt.so.1.46.0()(64bit) 1:fife-0.3.2-1.fc15.i686 requires libboost_regex.so.1.44.0 1:fife-0.3.2-1.fc15.i686 requires libboost_system.so.1.44.0 1:fife-0.3.2-1.fc15.i686 requires libboost_filesystem.so.1.44.0 1:fife-0.3.2-1.fc15.x86_64 requires libboost_regex.so.1.44.0()(64bit) 1:fife-0.3.2-1.fc15.x86_64 requires libboost_system.so.1.44.0()(64bit) 1:fife-0.3.2-1.fc15.x86_64 requires libboost_filesystem.so.1.44.0()(64bit) file-browser-applet-0.6.6-1.fc15.x86_64 requires libpanel-applet-2.so.0()(64bit) flush-0.9.10-2.fc16.x86_64 requires libboost_signals-mt.so.1.46.0()(64bit) flush-0.9.10-2.fc16.x86_64 requires libboost_filesystem-mt.so.1.46.0()(64bit) flush-0.9.10-2.fc16.x86_64 requires libboost_system-mt.so.1.46.0()(64bit) flush-0.9.10-2.fc16.x86_64 requires libboost_thread-mt.so.1.46.0()(64bit) fuse-encfs-1.7.2-3.fc15.i686 requires libboost_filesystem-mt.so.1.46.0 fuse-encfs-1.7.2-3.fc15.i686 requires libboost_system-mt.so.1.46.0 fuse-encfs-1.7.2-3.fc15.i686 requires libboost_serialization-mt.so.1.46.0 fuse-encfs-1.7.2-3.fc15.x86_64 requires libboost_serialization-mt.so.1.46.0()(64bit) fuse-encfs-1.7.2-3.fc15.x86_64 requires libboost_filesystem-mt.so.1.46.0()(64bit) fuse-encfs-1.7.2-3.fc15.x86_64 requires libboost_system-mt.so.1.46.0()(64bit) fusecompress-2.6-9.20100223git754bc0de.fc15.x86_64 requires libboost_serialization-mt.so.1.46.0()(64bit) fusecompress-2.6-9.20100223git754bc0de.fc15.x86_64 requires libboost_program_options-mt.so.1.46.0()(64bit) fusecompress-2.6-9.20100223git754bc0de.fc15.x86_64 requires libboost_system-mt.so.1.46.0()(64bit) fusecompress-2.6-9.20100223git754bc0de.fc15.x86_64 requires libboost_filesystem-mt.so.1.46.0()(64bit) fusecompress-2.6-9.20100223git754bc0de.fc15.x86_64 requires libboost_iostreams-mt.so.1.46.0()(64bit) gcstar-1.6.1-3.fc15.noarch requires perl(Gtk2::ScrolledWindow) gcstar-1.6.1-3.fc15.noarch requires perl(Gtk2::MessageDialog) gcstar-1.6.1-3.fc15.noarch requires perl(Gtk2::Dialog) gcstar-1.6.1-3.fc15.noarch requires perl(Gtk2::Toolbar) gcstar-1.6.1-3.fc15.noarch requires perl(Gtk2::TreeView) gcstar-1.6.1-3.fc15.noarch requires perl(Gtk2::MenuBar) gcstar-1.6.1-3.fc15.noarch requires perl(Gtk2::VBox) gcstar-1.6.1-3.fc15.noarch requires perl(Gtk2::Window) gdcm-2.0.17-1.fc16.i686 requires libmysqlclient.so.16 gdcm-2.0.17-1.fc16.x86_64 requires libmysqlclient.so.16()(64bit) gdcm-devel-2.0.17-1.fc16.i686 requires libmysqlclient.so.16 gdcm-devel-2.0.17-1.fc16.x86_64 requires libmysqlclient.so.16()(64bit) gedit-valencia-0.3.0-4.fc14.x86_64 requires libvala-0.10.so.0()(64bit) ghc-hamlet-0.6.1.2-3.fc16.i686 requires ghc(blaze-builder-0.2.1.4) = 0:092e1b6ac860af61a26470d20bb2e432 ghc-hamlet-0.6.1.2-3.fc16.i686 requires libHSblaze-builder-0.2.1.4-ghc7.0.2.so ghc-hamlet-0.6.1.2-3.fc16.x86_64 requires libHSblaze-builder-0.2.1.
Re: dependencies on mod_perl-devel in rawhide
On Mon, Apr 11, 2011 at 11:00:07AM +0200, Marcela Mašláňová wrote: > On 04/11/2011 10:42 AM, Paul Howarth wrote: > Fixed in mod_perl-2.0.5-3.fc16 > Thanks! D. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Vala 0.12 is out -- thoughts on updating the F-14 package?
Hello all, Now that Vala 0.12 is out, Renich has inquired whether we can update the F-14 package. I wouldn't push an update unless all packages that require Valencia can be built against 0.12 without a major update -- F-14, after all, is a stable release -- so if possible, would the package maintainers let me know if this is currently possible? Affected packages are: anjuta-1:2.32.1.1-1.fc14.src awn-extras-applets-0:0.4.0-24.fc14.1.src dconf-0:0.5.1-1.fc14.src deja-dup-0:16.1.1-1.fc14.src emerillon-0:0.1.2-7.fc14.src ethos-0:0.2.2-7.fc14.src folks-0:0.1.16-1.fc14.1.src gedit-vala-0:0.10.2-1.fc14.1.src gedit-valencia-0:0.3.0-4.fc14.src gpx-viewer-0:0.2.0-3.fc14.src gstreamer-rtsp-0:0.10.5-2.fc14.src gupnp-vala-0:0.6.12-1.fc14.src latexila-0:2.0.5-1.fc14.src rygel-0:0.8.3-1.fc14.src shotwell-0:0.8.1-2.fc14.src telepathy-glib-0:0.11.16-1.fc14.src tracker-0:0.8.17-1.fc14.src valide-0:0.7.0-7.20100923bzr557.fc14.src xnoise-0:0.1.12-3.fc14.src Thanks, -- Michel Alexandre Salim µblog: http://identi.ca/hircus http://twitter.com/hircus GPG key ID: 78884778 () ascii ribbon campaign - against html e-mail /\ www.asciiribbon.org - against proprietary attachments -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Vala 0.12 is out -- thoughts on updating the F-14 package?
On 04/11/2011 04:02 PM, Michel Alexandre Salim wrote: > Hello all, > > Now that Vala 0.12 is out, Renich has inquired whether we can update the > F-14 package. > > I wouldn't push an update unless all packages that require Valencia can > be built against 0.12 without a major update -- F-14, after all, is a > stable release -- so if possible, would the package maintainers let me > know if this is currently possible? Why is this update a benefit for Fedora 14? Does it break any compatibility? Have you done any testing with the affected packages? Rahul -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Vala 0.12 is out -- thoughts on updating the F-14 package?
On Mon, Apr 11, 2011 at 11:36 AM, Rahul Sundaram wrote: > On 04/11/2011 04:02 PM, Michel Alexandre Salim wrote: >> Hello all, >> >> Now that Vala 0.12 is out, Renich has inquired whether we can update the >> F-14 package. >> >> I wouldn't push an update unless all packages that require Valencia can >> be built against 0.12 without a major update -- F-14, after all, is a >> stable release -- so if possible, would the package maintainers let me >> know if this is currently possible? > > Why is this update a benefit for Fedora 14? Does it break any > compatibility? Have you done any testing with the affected packages? With the question of "would the package maintainers let me know if this is currently possible?" my guess would be no, but then it was a question. I think the shipping version of shotwell will have issues if it needs to be recompiled but its worth noting that as vala only generates C code which is then run native that apps shouldn't be affected. That said I don't have the time to go through and test my list of vala packages at the moment. Peter -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
[Bug 695295] New: perl-Mozilla-CA-20110409 is available
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug. Summary: perl-Mozilla-CA-20110409 is available https://bugzilla.redhat.com/show_bug.cgi?id=695295 Summary: perl-Mozilla-CA-20110409 is available Product: Fedora Version: rawhide Platform: Unspecified OS/Version: Unspecified Status: NEW Keywords: FutureFeature, Triaged Severity: unspecified Priority: unspecified Component: perl-Mozilla-CA AssignedTo: ppi...@redhat.com ReportedBy: upstream-release-monitor...@fedoraproject.org QAContact: extras...@fedoraproject.org CC: fedora-perl-devel-l...@redhat.com, mmasl...@redhat.com, ppi...@redhat.com, psab...@redhat.com Classification: Fedora Story Points: --- Latest upstream release: 20110409 Current version in Fedora Rawhide: 20110301 URL: http://search.cpan.org/dist/Mozilla-CA/ Please consult the package updates policy before you issue an update to a stable branch: https://fedoraproject.org/wiki/Updates_Policy More information about the service that created this bug can be found at: https://fedoraproject.org/wiki/Upstream_release_monitoring -- Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug. -- 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
[Bug 695294] New: perl-Math-MatrixReal-2.08 is available
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug. Summary: perl-Math-MatrixReal-2.08 is available https://bugzilla.redhat.com/show_bug.cgi?id=695294 Summary: perl-Math-MatrixReal-2.08 is available Product: Fedora Version: rawhide Platform: Unspecified OS/Version: Unspecified Status: NEW Keywords: FutureFeature, Triaged Severity: unspecified Priority: unspecified Component: perl-Math-MatrixReal AssignedTo: mmasl...@redhat.com ReportedBy: upstream-release-monitor...@fedoraproject.org QAContact: extras...@fedoraproject.org CC: fedora-perl-devel-l...@redhat.com, pertu...@free.fr, mmasl...@redhat.com Classification: Fedora Story Points: --- Latest upstream release: 2.08 Current version in Fedora Rawhide: 2.05 URL: http://search.cpan.org/dist/Math-MatrixReal/ Please consult the package updates policy before you issue an update to a stable branch: https://fedoraproject.org/wiki/Updates_Policy More information about the service that created this bug can be found at: https://fedoraproject.org/wiki/Upstream_release_monitoring -- Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug. -- 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
Re: Vala 0.12 is out -- thoughts on updating the F-14 package?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 04/11/2011 12:54 PM, Peter Robinson wrote: > On Mon, Apr 11, 2011 at 11:36 AM, Rahul Sundaram wrote: >> On 04/11/2011 04:02 PM, Michel Alexandre Salim wrote: >>> Hello all, >>> >>> Now that Vala 0.12 is out, Renich has inquired whether we can update the >>> F-14 package. >>> >>> I wouldn't push an update unless all packages that require Valencia can >>> be built against 0.12 without a major update -- F-14, after all, is a >>> stable release -- so if possible, would the package maintainers let me >>> know if this is currently possible? >> >> Why is this update a benefit for Fedora 14? Does it break any >> compatibility? Have you done any testing with the affected packages? > > With the question of "would the package maintainers let me know if > this is currently possible?" my guess would be no, but then it was a > question. > As Peter said; as for shotwell and xnoise, there are updates that actually require a newer Vala that can be pushed to F-14 if Vala is updated, and Renich asked because, likewise, a synapse update requires the new Vala. Most shotwell ABRT bugs seem to be not due to shotwell itself, but due to a dependent library; and another of my package, gedit-vala, would need to be updated to a snapshot to support Vala 0.12. So personally, I can go either way on this, but would like to hear if other maintainers prefer to go ahead or not. Thanks, - -- Michel Alexandre Salim Fedora Project Contributor: http://fedoraproject.org/ Email: sali...@fedoraproject.org | GPG key ID: 78884778 Jabber: hir...@jabber.ccc.de | IRC: hir...@irc.freenode.net () ascii ribbon campaign - against html e-mail /\ www.asciiribbon.org - against proprietary attachments -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/ iEYEARECAAYFAk2i41MACgkQNd069XiIR3jVNwCeKrlnP2OgUdv7TWP6ten4g/AJ mi8AniomPooI0V23AdQdIPkCJx4tBdCt =akMP -END PGP SIGNATURE- -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: critpath approval process seems rather broken
Dne 10.4.2011 23:07, Adam Williamson napsal(a): > (What I'd like to be able to do in this kind of case is have Bodhi > explain, hey, this package is critpath because $THIS_OTHER_PACKAGE > depends on it, and if $THIS_OTHER_PACKAGE is working okay, then this > package has fulfilled its critpath responsibilities, go ahead and +1 > it). I think that this is really too simplistic system (especially given that our dependencies are broken, because we are missing Suggests/Recommends … Ceterum autem censeo, Carthaginem esse delendam). Let me show you one more example. I have posted some updates to mobile-broadband-provider-info. These are just data files for NetworkManager, they need frequent updates, and the biggest disaster which can happen in case of their brokenness (which is quite low, anyway, these are XML files validated during the build) is that somebody won't be able to connect to the Internet via mobile phone. However, because it is a dependency for NetworkManager, it is in the critical path. And, so although I asked on #fedora-qa for testing already twice, https://admin.fedoraproject.org/updates/mobile-broadband-provider-info-1.20110218-1.fc13 has been in updates-testing since 2011-02-19 01:03:39. Best, Matěj -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: critpath approval process seems rather broken
On Mon, Apr 11, 2011 at 01:43:14PM +0200, Matej Cepl wrote: > I have posted some updates to mobile-broadband-provider-info. These are > just data files for NetworkManager, they need frequent updates, and the > biggest disaster which can happen in case of their brokenness (which is > quite low, anyway, these are XML files validated during the build) is > that somebody won't be able to connect to the Internet via mobile phone. So people with cellphone as only internet connectivity option will be unable unable to download fixed packages? -- Tomasz Torcz "Never underestimate the bandwidth of a station xmpp: zdzich...@chrome.plwagon filled with backup tapes." -- Jim Gray -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: critpath approval process seems rather broken
On Mon, Apr 11, 2011 at 00:18:24 -0700, Christopher Aillon wrote: > > But not having a set of nightlies based on testing is a problem, and I > think we really really need to fix that. I see no reason we need to > pick one or the other, let's do both! That's probably an issue for infrasctructure. If doing the extra builds isn't a probelm from their point of veiw, then it could probably be done. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
AutoQA vs Bodhi – round 2
As you probably noticed not so long ago we announced [1] that AutoQA [2] would be sending comments to Bodhi [3] and inform package maintainers about the results of important test cases (depcheck and ugpradepath). We enabled the functionality and disabled it again very soon due to a number of problems that were discovered. Good news – we’re going for round two! In the first run we discovered some bugs in our test code, but we also found a number of packages that were incorrectly tagged as pending updates even though they had been in the stable repository for a long time already. The former problem should be solved by AutoQA 0.4.6 [4] (and 0.4.5 [5]) which we are releasing today. The latter problem was fixed on Bodhi side by Luke Macken (huge thanks for quick response). Hopefully now the package maintainers won’t receive any alerts about already pushed package updates, only about the newly proposed ones. AutoQA Bodhi comments should be re-enabled today. As mentioned before we will quickly disable them if something goes wrong, fix the problem, then re-enable them again. If you don’t receive any AutoQA results for your package, don’t be surprised. However if you receive results but they seem to be wrong, please tell us so that we can investigate: autoqa-devel [6] or #fedora-qa [7]. Thanks! [1] http://kparal.wordpress.com/2011/03/21/autoqa-will-be-providing-comments-for-fedora-updates-really-soon/ [2] https://fedoraproject.org/wiki/AutoQA [3] https://admin.fedoraproject.org/updates/ [4] https://fedorahosted.org/autoqa/milestone/0.4.6 [5] https://fedorahosted.org/autoqa/milestone/0.4.5 [6] https://fedorahosted.org/mailman/listinfo/autoqa-devel [7] http://webchat.freenode.net/?channels=fedora-qa -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: critpath approval process seems rather broken
On Sun, 2011-04-10 at 18:19 -0700, Christopher Aillon wrote: > I just realized today for the first time that our nightlies are based on > stable, not testing. I think that's something we need to address. It's > probably still useful to have nightlies based on stable, but I think > it's rather vital to have images created with the updates in the queue. It would be nice to have both, but we didn't previously have the resources; we may do now they're being done by Bodhi. But we always intentionally picked the 'stable' case as we felt it was the more useful of the two, given we could only have one. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: critpath approval process seems rather broken
On Sun, 2011-04-10 at 23:21 -0400, Doug Ledford wrote: > > I had a closer look at the raid setup on my f15-box and as the raid was > > up as expected and poking at the raid with mdadm didn't turn up any > > issues, I've given it positive karma which has made it "Critpath > > approved". > > Thanks for that. I hope you read my other emails to Adam about the > testing of mdadm. My point of those being that there is more to mdadm > than *just* bringing the raid arrays up (although that is, of course, > the biggest thing). The fact that monitoring is down on the previous > version but ok on the current version is a big deal. Monitoring is > almost as important in the real world as it is the difference between an > array going degraded and you knowing or you doing nothing until it > finally dies altogether. Well, we are still talking about a *pre-release* here, remember. No-one's supposed to trust any data (or drives) they care about to a pre-release. A failure in RAID monitoring would not break any Beta release criteria, though we would have probably accepted it as NTH if it had been proposed. (It also doesn't break any Final release criteria at present; we could consider changing that, but we might not). You don't need to worry about Final as the update will get pushed as soon as the Beta freeze is lifted, but if future issues arise, please do propose a bug as NTH or Blocker if you think it should be fixed before release. Since this is an issue in monitoring and not array activation, it can be fixed satisfactorily with an update, yes? The fixed mdadm will be available as an update immediately after install (if the user leaves updates-testing checked) or once the freeze is lifted (if the user disables that repo). -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: critpath approval process seems rather broken
On Mon, 2011-04-11 at 13:43 +0200, Matej Cepl wrote: > Dne 10.4.2011 23:07, Adam Williamson napsal(a): > > (What I'd like to be able to do in this kind of case is have Bodhi > > explain, hey, this package is critpath because $THIS_OTHER_PACKAGE > > depends on it, and if $THIS_OTHER_PACKAGE is working okay, then this > > package has fulfilled its critpath responsibilities, go ahead and +1 > > it). > > I think that this is really too simplistic system (especially given that > our dependencies are broken, because we are missing Suggests/Recommends > … Ceterum autem censeo, Carthaginem esse delendam). Let me show you one > more example. There's nothing much we could do about that within the context of the critpath process. As you note, this is really more about limitations of package dependencies. > I have posted some updates to mobile-broadband-provider-info. These are > just data files for NetworkManager, they need frequent updates, and the > biggest disaster which can happen in case of their brokenness (which is > quite low, anyway, these are XML files validated during the build) is > that somebody won't be able to connect to the Internet via mobile phone. O rly? Are you *sure*? Sure it's not at all possible there could be a bug somewhere in NM which causes it to crash because it misparses an odd character in one of the files, for instance? "It's just a configuration / data file, it can't possibly break anything!" is one of those assertions that bitter experience tends to prove incorrect on occasion :) -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Vala 0.12 is out -- thoughts on updating the F-14 package?
On Mon, Apr 11, 2011 at 5:54 AM, Peter Robinson wrote: > On Mon, Apr 11, 2011 at 11:36 AM, Rahul Sundaram wrote: >> >> Why is this update a benefit for Fedora 14? Does it break any >> compatibility? Have you done any testing with the affected packages? > > With the question of "would the package maintainers let me know if > this is currently possible?" my guess would be no, but then it was a > question. > > I think the shipping version of shotwell will have issues if it needs > to be recompiled but its worth noting that as vala only generates C > code which is then run native that apps shouldn't be affected. That > said I don't have the time to go through and test my list of vala > packages at the moment. I'm out of town right now, and won't get a chance to do any testing before tomorrow night, but based on my past experiences with folks + vala, I would lean against updating vala in our stable releases. Later, /B -- Brian Pepple https://fedoraproject.org/wiki/User:Bpepple gpg --keyserver pgp.mit.edu --recv-keys 810CC15E BD5E 6F9E 8688 E668 8F5B CBDE 326A E936 810C C15E -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
[perl-Test-WWW-Mechanize] Add Test-WWW-Mechanize-1.30-svn.r712.diff (Fix FTBS on f13/f14/f15). Add Test-WWW-Mechanize-1.30-Tes
commit 520c9060015390df5712c702113212a2b8ffce58
Author: Ralf Corsépius
Date: Mon Apr 11 17:44:33 2011 +0200
Add Test-WWW-Mechanize-1.30-svn.r712.diff (Fix FTBS on f13/f14/f15).
Add Test-WWW-Mechanize-1.30-Test-LongString.diff (Fix FTBS on f16).
Spec file cleanup.
Test-WWW-Mechanize-1.30-Test-LongString.diff | 48 +++
Test-WWW-Mechanize-1.30-svn-trunk-r712.diff | 63 ++
perl-Test-WWW-Mechanize.spec | 26 +++
3 files changed, 127 insertions(+), 10 deletions(-)
---
diff --git a/Test-WWW-Mechanize-1.30-Test-LongString.diff
b/Test-WWW-Mechanize-1.30-Test-LongString.diff
new file mode 100644
index 000..105d4d6
--- /dev/null
+++ b/Test-WWW-Mechanize-1.30-Test-LongString.diff
@@ -0,0 +1,48 @@
+diff -u -x .svn trunk/t/back_ok.t trunk.hacked/t/back_ok.t
+--- trunk/t/back_ok.t 2011-04-11 17:09:03.414516193 +0200
trunk.hacked/t/back_ok.t 2011-04-11 17:17:53.538464020 +0200
+@@ -54,7 +54,7 @@
+ test_out( 'not ok 1 - Try to get bad URL' );
+ test_fail( +3 );
+ test_diag( '500' );
+-test_diag( q{Can't connect to wango.nonexistent.xx-only-testing:80 (Bad
hostname 'wango.nonexistent.xx-only-testing')} );
++test_diag( q{Can't connect to wango.nonexistent.xx-only-testing:80 (Bad
hostname)} );
+ my $ok = $mech->get_ok( $badurl, 'Try to get bad URL' );
+ test_test( 'Fails to get nonexistent URI and reports failure' );
+
+diff -u -x .svn trunk/t/content_lacks.t trunk.hacked/t/content_lacks.t
+--- trunk/t/content_lacks.t2011-04-11 17:09:03.413516183 +0200
trunk.hacked/t/content_lacks.t 2011-04-11 17:17:53.538464020 +0200
+@@ -35,7 +35,7 @@
+ test_fail(+4);
+ test_diag(q(searched: "\x{0a}\x{0a}Test
Page"...) );
+ test_diag(q( and found: "Test Page") );
+-test_diag(q( at position: 33) );
++test_diag(q( at position: 33 (line 3 column 16)) );
+ $mech->content_lacks( 'Test Page', q{Shouldn't say it's a test page} );
+ test_test( 'Handles not finding it' );
+
+diff -u -x .svn trunk/t/get_ok.t trunk.hacked/t/get_ok.t
+--- trunk/t/get_ok.t 2011-04-11 17:09:03.414516193 +0200
trunk.hacked/t/get_ok.t2011-04-11 17:17:53.538464020 +0200
+@@ -55,7 +55,7 @@
+ test_out( 'not ok 1 - Try to get bad URL' );
+ test_fail( +3 );
+ test_diag( '500' );
+-test_diag( q{Can't connect to wango.nonexistent.xx-only-testing:80 (Bad
hostname 'wango.nonexistent.xx-only-testing')} );
++test_diag( q{Can't connect to wango.nonexistent.xx-only-testing:80 (Bad
hostname)} );
+ my $ok = $mech->get_ok( $badurl, 'Try to get bad URL' );
+ test_test( 'Fails to get nonexistent URI and reports failure' );
+
+diff -u -x .svn trunk/t/head_ok.t trunk.hacked/t/head_ok.t
+--- trunk/t/head_ok.t 2011-04-11 17:09:03.414516193 +0200
trunk.hacked/t/head_ok.t 2011-04-11 17:17:53.538464020 +0200
+@@ -52,7 +52,7 @@
+ test_out( 'not ok 1 - Try to HEAD bad URL' );
+ test_fail( +3 );
+ test_diag( '500' );
+-test_diag( qq{Can't connect to $NONEXISTENT:80 (Bad hostname
'$NONEXISTENT')} );
++test_diag( qq{Can't connect to $NONEXISTENT:80 (Bad hostname)} );
+ my $ok = $mech->head_ok( $badurl, 'Try to HEAD bad URL' );
+ test_test( 'Fails to HEAD nonexistent URI and reports failure' );
+
diff --git a/Test-WWW-Mechanize-1.30-svn-trunk-r712.diff
b/Test-WWW-Mechanize-1.30-svn-trunk-r712.diff
new file mode 100644
index 000..e933da0
--- /dev/null
+++ b/Test-WWW-Mechanize-1.30-svn-trunk-r712.diff
@@ -0,0 +1,63 @@
+--- Test-WWW-Mechanize-1.30.orig/t/head_ok.t 2008-12-22 22:28:21.0
+0100
trunk/t/head_ok.t 2011-04-11 17:09:03.414516193 +0200
+@@ -2,21 +2,12 @@
+
+ use strict;
+ use warnings;
+-use Test::More;
++use Test::More tests => 11;
+ use Test::Builder::Tester;
+
+-use constant NONEXISTENT => 'http://blahblablah.xx-nonexistent.';
+-BEGIN {
+-if ( gethostbyname( NONEXISTENT ) ) {
+-plan skip_all => 'Found an A record for the non-existent domain';
+-}
+-}
+-
+-BEGIN {
+-plan tests => 11;
+-use_ok( 'Test::WWW::Mechanize' );
+-}
++my $NONEXISTENT = 'blahblablah.xx-nonexistent.foo';
+
++require_ok( 'Test::WWW::Mechanize' );
+
+ use lib 't';
+ use TestServer;
+@@ -25,7 +16,7 @@
+ my $pid = $server->background;
+ my $server_root = $server->root;
+
+-my $mech=Test::WWW::Mechanize->new( autocheck => 0 );
++my $mech = Test::WWW::Mechanize->new( autocheck => 0 );
+ isa_ok($mech,'Test::WWW::Mechanize');
+
+ GOOD_HEAD: { # Stop giggling, you!
+@@ -46,15 +37,22 @@
+ test_test('HEAD existing URI and reports success - default desc');
+ }
+
+-BAD_HEAD: {
+-my $badurl = 'http://wango.nonexistent.xx-only-testing/';
++# Bad HEAD test. Relies on getting an error finding a non-existent domain.
++# Some ISPs "helpfully" provide resolution for non-existent domains,
++# and thus this test fails by succeeding. We check for this annoying
++# behavior and skip this subtest if we get it.
++SKIP: {
++skip "Found
Re: bodhi auto-obsoleting disabled?
On Sat, 9 Apr 2011 10:27:05 +0200 Michael Schwendt wrote: > Caution, everyone! > > It seems that bodhi no longer obsoletes update tickets when submitting > newer ones. Currently, there are several competing test-updates, where > a ticket exists for an old and a new release. But only the older > release is found in the repo actually due to a bug in bodhi (either > regression or still unfixed, but it has been reported long ago). E.g. > libchamplain and libinfinity. Auto obsoletes haven't been disabled... it looks like the old libchamplain had a stable request already on it, then the new one was submitted. Bodhi won't obsolete a update that has a pending request on it. ;( This sort of thing is more likely to happen in freezes. ;( kevin signature.asc Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: bodhi auto-obsoleting disabled?
On Mon, 11 Apr 2011 10:53:24 -0600, Kevin wrote: > On Sat, 9 Apr 2011 10:27:05 +0200 > Michael Schwendt wrote: > > > Caution, everyone! > > > > It seems that bodhi no longer obsoletes update tickets when submitting > > newer ones. Currently, there are several competing test-updates, where > > a ticket exists for an old and a new release. But only the older > > release is found in the repo actually due to a bug in bodhi (either > > regression or still unfixed, but it has been reported long ago). E.g. > > libchamplain and libinfinity. > > Auto obsoletes haven't been disabled... it looks like the old > libchamplain had a stable request already on it, No, you're misreading things: https://admin.fedoraproject.org/updates/libchamplain-0.9.1-1.fc15 * bodhi - 2011-04-03 15:34:42 This update has been submitted for testing by pbrobinson. * bodhi - 2011-04-09 12:44:46 This update has been submitted for stable by pbrobinson. https://admin.fedoraproject.org/updates/libchamplain-0.10.0-1.fc15 * bodhi - 2011-04-05 15:18:39 This update has been submitted for testing by tbzatek. * bodhi - 2011-04-11 09:18:46 This update has been submitted for stable by tbzatek. > then the new one was > submitted. Bodhi won't obsolete a update that has a pending request on > it. ;( > > This sort of thing is more likely to happen in freezes. ;( Bad, bad, bad. No response to my comments inside those bodhi tickets. Meanwhile, both packages have been requested to be pushed to stable, but one of them has never been in updates-testing. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: critpath approval process seems rather broken
Adam Williamson wrote: > O rly? Are you *sure*? Sure it's not at all possible there could be a > bug somewhere in NM which causes it to crash because it misparses an odd > character in one of the files, for instance? "It's just a > configuration / data file, it can't possibly break anything!" is one of > those assertions that bitter experience tends to prove incorrect on > occasion :) But is that minute risk worth withholding the useful bugfix update for 2+ MONTHS, because of completely unrealistic testing requirements which just won't be fulfilled out there in the real world for a n-1 release? Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: bodhi auto-obsoleting disabled?
And here's the analysis for libinfinity: https://admin.fedoraproject.org/updates/libinfinity-0.5.0-1.fc15 * bodhi - 2011-04-05 13:10:32 This update has been submitted for testing by tbzatek. https://admin.fedoraproject.org/updates/libinfinity-0.5.0-2.fc15 * bodhi - 2011-04-05 13:51:07 This update has been submitted for testing by tbzatek. No auto-obsoleting. And only 0.5.0-1.fc15 (the old one with broken deps) has ever appeared in the updates-testing repo. For the newer one, * bodhi - 2011-04-05 20:20:21 This update has been pushed to testing isn't true, because it still isn't found in updates-testing. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Broken dependencies with Fedora 15 + updates-testing - 2011-04-11
The following packages in the repository suffer from broken dependencies: == The results in this summary consider Test Updates! == package: perl-EV-devel-4.03-3.fc15.i686 from fedora-15-development-i386 unresolved deps: perl-EV(x86-32) = 0:4.03-3.fc15 package: perl-EV-devel-4.03-3.fc15.x86_64 from fedora-15-development-x86_64 unresolved deps: perl-EV(x86-64) = 0:4.03-3.fc15 -- 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
Re: Non-responsive maintainer - Chris Ricker
On Sat, 09 Apr 2011 11:14:54 -0700 Christopher Aillon wrote: > On 11/15/2010 08:57 AM, Kevin Fenzi wrote: > > On Mon, 15 Nov 2010 05:16:43 -0500 (EST) > > Jaroslav Skarvada wrote: > > > >> Please could any FESCo member approve the takeover of rrdtool > >> (according to nonresponsive package maintainers policy)? Or should > >> I open ticket for this? > > > > I'll approve it and orphan rrdtool. > > Five months later and Chris Ricker (kaboom) is still MIA. Yeah. ;( I sure hope he's ok. > I'd like to propose we orphan all his packages. > https://admin.fedoraproject.org/pkgdb/users/packages/kaboom as > nothing's really changed since the nonresponsive maintainer process > was invoked on him. > > I'll take gnuchess and xboard. Sounds reasonable. I sent him another email with no reply as well. Toshio is going to orphan his packages later today... kevin signature.asc Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
A "whatuses" command for yum?
A humble, basic question for you experts... Given a library, such as jansson (C JSON lib), how does one automatically list all packages in the F14 repo which require jansson? Must be able to find packages which are not installed on the current system. Thanks, Jeff -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: A "whatuses" command for yum?
Jeff Garzik wrote: > A humble, basic question for you experts... > > Given a library, such as jansson (C JSON lib), how does one > automatically list all packages in the F14 repo which require jansson? > > Must be able to find packages which are not installed on the current system. > > Thanks, > > Jeff > > > > repoquery --whatrequires , which could be a name of an RPM, or a solib name, like libfoo.so.0. repoquery is in yum-utils. -J -- in your fear, seek only peace in your fear, seek only love -d. bowie -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: A "whatuses" command for yum?
Le lundi 11 avril 2011 à 14:55 -0400, Jeff Garzik a écrit : > A humble, basic question for you experts... > > Given a library, such as jansson (C JSON lib), how does one > automatically list all packages in the F14 repo which require jansson? > > Must be able to find packages which are not installed on the current system. Hi, through repoquery? $ repoquery --whatrequires jansson -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: critpath approval process seems rather broken
On Sat, 09 Apr 2011 13:07:21 +0200 Kevin Kofler wrote: > While I welcome those changes, I don't understand why we need to make > the update rules to be enforced by Bodhi more and more complicated > (and in fact, too complicated for Bodhi to implement correctly, there > are already several corner cases in which the implementation in Bodhi > differs from what FESCo requested) when we could just ask maintainers > for a bit of common sense and do without any software enforcement. > > As you're seeing from all those proposals being floated for various > special cases, there are many factors to consider in the tradeoff > between getting important fixes out quickly and getting changes > tested. I think there's a lot to gain from being flexible. No > hardcoded policy will do the right thing in all cases. This thread is > just one of the many cases where it goes wrong. > > Homo sapiens sapiens has an organ called the "brain", which is very > effective at making decisions. We have many of those available, one > per maintainer. Why not use this processing power for decision making? To some extent I agree with you. ;) We went though several models over the years... - Anything goes, up to the maintainer. This gave us major updates in stable releases, things that weren't tested very well or widely, lots of smaller updates for minor things leading to churn, etc. - Anything goes, up to the maintainer, but verify/put some framework on it. Sadly, there's no way to verify/sanity check all updates from a rel-eng point of view. The flow is far too vast, so the only way we can really test/check things is... - Some rules/structure, enforced by the tool and verified/checked by anyone out there who cares to do so. I agree that the complexity is anoying and hard to get right, but not sure we could go to less rules without hitting cases we really would like to check for. Things like bodhi 2.0 and autoqa will help too... when they finally arrive. ;) The current situation is not ideal, but we are trying... kevin signature.asc Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: critpath approval process seems rather broken
On Sun, 10 Apr 2011 15:41:25 +0900 TASAKA Mamoru wrote: > Tomasz Torcz wrote, at 04/09/2011 07:57 PM +9:00: > > On Sat, Apr 09, 2011 at 05:32:04AM +0200, Kevin Kofler wrote: > >> Will Woods wrote: > >>> In fact, there's plenty of approvers available, but you're not > >>> engaging with them. They might not know how to test libtiff, or > >>> what needs testing, so other stuff gets tested first. > >> > >> The fact is, this is a SECURITY UPDATE and as such it should go > >> out even without testing. It's not acceptable to sit on security > >> updates for weeks. > > > >No, security updates are not _that_ special. For example, > > there's an avahi update in pipeline. It has broken dependencies. > > Pushing this would broke some systems. I'm talking about: > > https://admin.fedoraproject.org/updates/avahi-0.6.27-6.fc14 > > > > So as a result we are just leaving this security issue unresolved > more than one month? Okay, it is all very well that we try to explain > why the new updates request is not yet pushed, however then people > would ask, "so why can't Fedora try to fix such issue like broken > dependency ASAP? Short of man power? Is Fedora just making light > of security issues?" > > Who is responsible for this issue? I would say (in order): - The person who submitted the update. - Any co-maintainers the package has that could fix it and push a new update. - Any provenpackagers who are interested in the package and can go fix it and push a fixed update. - FESCo or rel-eng if no one else steps up and someone notifies those bodies of the problem, so someone there can fix it. kevin signature.asc Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: A "whatuses" command for yum?
On Mon, 11 Apr 2011 13:59:11 -0500, Jon wrote: > Jeff Garzik wrote: > > A humble, basic question for you experts... > > > > Given a library, such as jansson (C JSON lib), how does one > > automatically list all packages in the F14 repo which require jansson? > > > > Must be able to find packages which are not installed on the current system. > > > > Thanks, > > > > Jeff > > > > > > > > > repoquery --whatrequires , which could be a name of an RPM, or a > solib name, like libfoo.so.0. > > repoquery is in yum-utils. Note that --alldeps option is the default for some time, so if you really want to be "a name of an RPM", you need to add --exactdeps -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: critpath approval process seems rather broken
Kevin Fenzi wrote: > - Anything goes, up to the maintainer. > > This gave us major updates in stable releases, That's a feature. :-) > things that weren't tested very well or widely, Yet they worked… > lots of smaller updates for minor things leading to churn, etc. Very few updates were genuinely useless. Even a minor bugfix is a bugfix and should get pushed. Fighting "churn" as a "problem" only leads to sitting on fixes instead of getting them out to our users as soon as possible. Churn is a feature! Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
[Test-Announce] Announcing 389 Directory Server version 1.2.8.1 Testing
The 389 Project team is pleased to announce the release of 389-ds-base-1.2.8.1. This release has fixes for bugs found in 1.2.8 testing and bugs from earlier releases. Installation yum install --enablerepo=updates-testing 389-ds # or for EPEL yum install --enablerepo=epel-testing 389-ds setup-ds-admin.pl Upgrade yum upgrade --enablerepo=updates-testing 389-ds-base idm-console-framework 389-admin 389-ds-console 389-admin-console # or for EPEL yum upgrade --enablerepo=epel-testing 389-ds-base idm-console-framework 389-admin 389-ds-console 389-admin-console setup-ds-admin.pl -u How to Give Feedback The best way to provide feedback is via the Fedora Update system. Each update is broken down by package and platform. For example, if you are using Fedora 13, and you have successfully installed or upgraded all of the packages, and the console and etc. works, then go to the links below for Fedora 13 and provide feedback. * EL-5 - https://admin.fedoraproject.org/updates/389-ds-base-1.2.8.1-1.el5 * Fedora 13 - https://admin.fedoraproject.org/updates/389-ds-base-1.2.8.1-1.fc13 * Fedora 14 - https://admin.fedoraproject.org/updates/389-ds-base-1.2.8.1-1.fc14 * Fedora 15 - https://admin.fedoraproject.org/updates/389-ds-base-1.2.8.1-1.fc15 scroll down to the bottom of the page, and click on the Add a comment >> link * select one of the Works for me or Does not work radio buttons, add text, and click on the Add Comment button If you are using a build on another platform, just send us an email to 389-us...@lists.fedoraproject.org Reporting Bugs If you find a bug, or would like to see a new feature, you can enter it here - https://bugzilla.redhat.com/enter_bug.cgi?product=389 More Information * Release Notes - http://port389.org/wiki/Release_Notes * Install_Guide - http://port389.org/wiki/Install_Guide * Download - http://port389.org/wiki/Download ___ 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
Re: critpath approval process seems rather broken
On Monday 11 April 2011 13:58:21 Tomasz Torcz wrote: > So people with cellphone as only internet connectivity option will > be unable unable to download fixed packages? Nope. They just have to enter their connection settings manually. Instructions were provided by their ISP, probably along with some crappy Windows software. Besides, there are numerous other offline places to find that information (flyers, recent cell phones, etc.). It's really no big deal. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
[Test-Announce] Fedora 15 Beta Go/No-Go Meeting Wednesday, April 13, 2011 @ 21:00 UTC
Join us on irc.freenode.net #fedora-meeting for this important meeting. Wednesday, April 13, 2011 @ 21:00 UTC (17:00 EDT/14:00 PDT) "Before each public release Development, QA, and Release Engineering meet to determine if the release criteria are met for a particular release. This meeting is called the: Go/No-Go Meeting." "Verifying that the Release criteria are met is the responsibility of the QA Team." For more details about this meeting see: https://fedoraproject.org/wiki/Go_No_Go_Meeting In the meantime keep an eye on the Fedora 15 Beta Blocker list and help us get the testing matrix completed by testing. https://fedoraproject.org/wiki/Current_Release_Blockers (One approved blocker left, currently in VERIFIED - woohoo!) http://fedoraproject.org/wiki/Category:Fedora_15_Beta_RC_Test_Results ___ 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
Re: Non-responsive maintainer - Chris Ricker
On Mon, Apr 11, 2011 at 11:53:41AM -0600, Kevin Fenzi wrote: > On Sat, 09 Apr 2011 11:14:54 -0700 > Christopher Aillon wrote: > > I'd like to propose we orphan all his packages. > > https://admin.fedoraproject.org/pkgdb/users/packages/kaboom as > > nothing's really changed since the nonresponsive maintainer process > > was invoked on him. > > > > I'll take gnuchess and xboard. > > Sounds reasonable. I sent him another email with no reply as well. > > Toshio is going to orphan his packages later today... > Orphaned. Feel free to take. -Toshio pgpJtUSxr911p.pgp Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: dependencies on mod_perl-devel in rawhide
On Mon, 11 Apr 2011 11:00:07 +0200, Marcela wrote: > > mod_perl-devel erroneously provides perl(warnings), which means that > > anything containing a perl script with "use warnings;" in it is liable > > to pull it in. Should be easily fixable - I'll get on it. > > > > Paul. > Fixed in mod_perl-2.0.5-3.fc16 Not the only one: perl-CPAN -> 'perl(base)' -> libgtk-java-devel libgtk-java-devel also provides tons of 'perl(...)' stuff. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: A "whatuses" command for yum?
On 04/11/2011 10:15 PM, Michael Schwendt wrote: > On Mon, 11 Apr 2011 13:59:11 -0500, Jon wrote: >> repoquery --whatrequires , which could be a name of an RPM, or a >> solib name, like libfoo.so.0. > > Note that --alldeps option is the default for some time, so if you > really want to be "a name of an RPM", you need to add --exactdeps I think that's somewhat misleadingly put, there's no need to use --exactdeps if one wants to give "a name of an RPM" as an argument. For the example above, --exactdeps is only needed if one wants to get the list of things that depend on the exact string (so dependencies to things might provide are not checked), but I believe those use cases are not as usual as the default --alldeps ones. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Orphaning gpointing-device-settings
Hi I'm not using this package anymore so I'd like to orphan it; bugs and all other data at: https://admin.fedoraproject.org/pkgdb/acls/bugs/gpointing-device-settings Regards G. -- Gianluca Sforna http://morefedora.blogspot.com http://identi.ca/giallu - http://twitter.com/giallu -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: A "whatuses" command for yum?
On Tue, 12 Apr 2011 00:36:02 +0300, Ville wrote: > On 04/11/2011 10:15 PM, Michael Schwendt wrote: > > On Mon, 11 Apr 2011 13:59:11 -0500, Jon wrote: > >> repoquery --whatrequires , which could be a name of an RPM, or a > >> solib name, like libfoo.so.0. > > > > Note that --alldeps option is the default for some time, so if you > > really want to be "a name of an RPM", you need to add --exactdeps > > I think that's somewhat misleadingly put, there's no need to use > --exactdeps if one wants to give "a name of an RPM" as an argument. For > the example above, --exactdeps is only needed if one wants to get the > list of things that depend on the exact string (so dependencies to > things might provide are not checked), but I believe those use > cases are not as usual as the default --alldeps ones. Okay, that's a much longer explanation of what I've had in mind. And I agree, the --alldeps query is needed more often and is appropriate as a default. In either case, the repoquery user ought to be aware of the two options and what they do. Especially when trying to understand the difference between automatic dependencies and explicit dependencies on package names. Or when planning to rename a subpackage or to move a file from one subpackage to another. Without understanding the default --whatrequires query, there is the risk of misinterpreting its result. Example: $ repoquery --whatrequires libmad|grep -v libmad|wc -l 33 Oh, so many packages depend on libmad. However, the packages don't care about the "libmad" package name (but just the shared library name in it): $ repoquery --exactdeps --whatrequires libmad|grep -v libmad $ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
RE: A "whatuses" command for yum?
-Original Message- Sent: Tuesday, April 12, 2011 4:56 AM Subject: A "whatuses" command for yum? A humble, basic question for you experts... Given a library, such as jansson (C JSON lib), how does one automatically list all packages in the F14 repo which require jansson? Must be able to find packages which are not installed on the current system. Thanks, Jeff Correct me if I'm wrong, but wouldn't "yum info jansson" give you this? Regards Chris Jones -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
gnuchess license changed from GPLv2+ to GPLv3+
gnuchess v5.08 is now licensed under the GPLv3+. Already built in rawhide. Will push builds to F15,F14,F13 later this week. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Firefox releases, going forward
Given that Mozilla is dramatically changing the development of Firefox and making releases much more frequent - i.e. Firefox 5 due in July, 6 later in the year, are Firefox updates going to change in Fedora? Are we still going to stick with the major version series at the time of Fedora release, or are we thinking about a more rolling release system? I'm assuming this will ultimately depend on the changes Firefox pushes and their effects on system libraries, but just curious. -c -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: bodhi auto-obsoleting disabled?
On Mon, 11 Apr 2011 19:28:44 +0200 Michael Schwendt wrote: > On Mon, 11 Apr 2011 10:53:24 -0600, Kevin wrote: > > > On Sat, 9 Apr 2011 10:27:05 +0200 > > Michael Schwendt wrote: > > > > > Caution, everyone! > > > > > > It seems that bodhi no longer obsoletes update tickets when > > > submitting newer ones. Currently, there are several competing > > > test-updates, where a ticket exists for an old and a new release. > > > But only the older release is found in the repo actually due to a > > > bug in bodhi (either regression or still unfixed, but it has been > > > reported long ago). E.g. libchamplain and libinfinity. > > > > Auto obsoletes haven't been disabled... it looks like the old > > libchamplain had a stable request already on it, > > No, you're misreading things: > > https://admin.fedoraproject.org/updates/libchamplain-0.9.1-1.fc15 > * bodhi - 2011-04-03 15:34:42 > This update has been submitted for testing by pbrobinson. > * bodhi - 2011-04-09 12:44:46 > This update has been submitted for stable by pbrobinson. > > > https://admin.fedoraproject.org/updates/libchamplain-0.10.0-1.fc15 > * bodhi - 2011-04-05 15:18:39 > This update has been submitted for testing by tbzatek. > * bodhi - 2011-04-11 09:18:46 > This update has been submitted for stable by tbzatek. So I am. Odd. ;( > Bad, bad, bad. No response to my comments inside those bodhi tickets. > Meanwhile, both packages have been requested to be pushed to stable, > but one of them has never been in updates-testing. Yeah, I am going to mail them both, but perhaps we should revoke both requests until they sort it out. ;( kevin signature.asc Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
