Re: [Fedora-haskell-list] Taking ownership of haddock
- lakshminaras2...@gmail.com wrote: I intend to take ownership of haddock package. It is required for one other package (leksah, an IDE for Haskell) that I am planning to submit. Yes, I think that is fine. You will need to submit haddock for package review since it has been retired from Fedora for a while and then after approval - you can make SCM Change Request to take ownership of the retired package. Jens -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Does anybody know how to contact Chris Ricker?
Does anybody know how to contact Chris Ricker (kaboom AT oobleck.net)? https://bugzilla.redhat.com/show_bug.cgi?id=554334 https://bugzilla.redhat.com/show_bug.cgi?id=631825 and more Jaroslav -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
rawhide report: 20101101 changes
Compose started at Mon Nov 1 08:15:05 UTC 2010 Broken deps for x86_64 -- 1:anjuta-2.31.90.0-3.fc15.i686 requires libvala-0.10.so.0 1:anjuta-2.31.90.0-3.fc15.x86_64 requires libvala-0.10.so.0()(64bit) apcupsd-3.14.8-3.fc15.x86_64 requires libnetsnmp.so.20()(64bit) beagle-0.3.9-19.fc14.x86_64 requires libmono.so.0()(64bit) beagle-0.3.9-19.fc14.x86_64 requires libmono.so.0(VER_1)(64bit) cluster-glue-1.0.6-1.fc14.x86_64 requires libnetsnmp.so.20()(64bit) cluster-snmp-0.18.1-1.fc15.x86_64 requires libnetsnmp.so.20()(64bit) clutter-gst-devel-1.2.0-1.fc15.i686 requires pkgconfig(clutter-1.0) 0:1.3.0 clutter-gst-devel-1.2.0-1.fc15.x86_64 requires pkgconfig(clutter-1.0) 0:1.3.0 db4o-7.4-2.fc13.x86_64 requires mono(Mono.GetOptions) = 0:2.0.0.0 dh-make-0.55-2.fc15.noarch requires debhelper dmapd-0.0.25-5.fc15.i686 requires libdmapsharing.so.1 dmapd-0.0.25-5.fc15.x86_64 requires libdmapsharing.so.1()(64bit) dmapd-devel-0.0.25-5.fc15.i686 requires pkgconfig(libdmapsharing-1.9) dmapd-devel-0.0.25-5.fc15.x86_64 requires pkgconfig(libdmapsharing-1.9) eog-plugins-2.30.0-2.fc14.x86_64 requires libgdata.so.7()(64bit) freefem++-3.9-2.1.fc15.x86_64 requires libopen-rte.so.0()(64bit) freefem++-3.9-2.1.fc15.x86_64 requires libmpi.so.0()(64bit) freefem++-3.9-2.1.fc15.x86_64 requires libmpi_cxx.so.0()(64bit) freefem++-3.9-2.1.fc15.x86_64 requires libopen-pal.so.0()(64bit) freefem++-mpi-3.9-2.1.fc15.x86_64 requires libmpi.so.0()(64bit) freefem++-mpi-3.9-2.1.fc15.x86_64 requires libopen-rte.so.0()(64bit) freefem++-mpi-3.9-2.1.fc15.x86_64 requires libmpi_cxx.so.0()(64bit) freefem++-mpi-3.9-2.1.fc15.x86_64 requires libopen-pal.so.0()(64bit) 1:gedit-devel-2.91.0-4.fc15.i686 requires gtksourceview2-devel = 0:2.91 1:gedit-devel-2.91.0-4.fc15.x86_64 requires gtksourceview2-devel = 0:2.91 gedit-vala-0.10.2-2.fc15.i686 requires libvala-0.10.so.0 gedit-vala-0.10.2-2.fc15.x86_64 requires libvala-0.10.so.0()(64bit) 1:gnome-games-extra-2.31.91.1-1.fc15.x86_64 requires libclutter-gtk-0.10.so.0()(64bit) gnome-pilot-eds-2.32.0-1.fc14.x86_64 requires libcamel-1.2.so.19()(64bit) gnome-python2-brasero-2.32.0-1.fc14.x86_64 requires libbrasero-burn.so.1()(64bit) gnome-python2-brasero-2.32.0-1.fc14.x86_64 requires libbrasero-media.so.1()(64bit) gnome-python2-evince-2.32.0-1.fc14.x86_64 requires libevdocument.so.3()(64bit) gnome-python2-evince-2.32.0-1.fc14.x86_64 requires libevview.so.3()(64bit) gnome-python2-evolution-2.32.0-1.fc14.x86_64 requires libcamel-1.2.so.19()(64bit) gnome-python2-totem-2.32.0-1.fc14.x86_64 requires libgnome-media-profiles.so.0()(64bit) gnome-rdp-0.2.3-6.fc12.x86_64 requires mono(Mono.Data.SqliteClient) = 0:2.0.0.0 gpx-viewer-0.2.0-3.fc14.x86_64 requires libchamplain-0.6.so.0()(64bit) gpx-viewer-0.2.0-3.fc14.x86_64 requires libclutter-gtk-0.10.so.0()(64bit) gpx-viewer-0.2.0-3.fc14.x86_64 requires libchamplain-gtk-0.6.so.0()(64bit) hedgewars-server-0.9.13-3.fc15.x86_64 requires libHSdataenc-0.13.0.3-ghc6.12.3.so()(64bit) hornsey-1.5.2-0.3.fc15.x86_64 requires libclutter-gtk-0.10.so.0()(64bit) hugin-2010.0.0-5.fc15.x86_64 requires libpano13.so.1()(64bit) hugin-base-2010.0.0-5.fc15.i686 requires libpano13.so.1 hugin-base-2010.0.0-5.fc15.x86_64 requires libpano13.so.1()(64bit) ifstat-1.1-12.fc13.x86_64 requires libnetsnmp.so.20()(64bit) log4net-1.2.10-13.fc13.x86_64 requires mono(System) = 0:1.0.5000.0 log4net-1.2.10-13.fc13.x86_64 requires mono(System.Data) = 0:1.0.5000.0 log4net-1.2.10-13.fc13.x86_64 requires mono(mscorlib) = 0:1.0.5000.0 log4net-1.2.10-13.fc13.x86_64 requires mono(System.Xml) = 0:1.0.5000.0 log4net-1.2.10-13.fc13.x86_64 requires mono(System.Web) = 0:1.0.5000.0 moblin-panel-status-0.1.21-6.fc14.x86_64 requires libsocialweb-client.so.1()(64bit) moblin-panel-status-0.1.21-6.fc14.x86_64 requires libchamplain-0.6.so.0()(64bit) moblin-panel-status-0.1.21-6.fc14.x86_64 requires libclutter-gtk-0.10.so.0()(64bit) mono-ndoc-1.3.1-8.fc13.x86_64 requires mono(System.Drawing) = 0:1.0.5000.0 mono-ndoc-1.3.1-8.fc13.x86_64 requires mono(System.Windows.Forms) = 0:1.0.5000.0 mono-ndoc-1.3.1-8.fc13.x86_64 requires mono(System) = 0:1.0.5000.0 mono-ndoc-1.3.1-8.fc13.x86_64 requires mono(mscorlib) = 0:1.0.5000.0 mono-ndoc-1.3.1-8.fc13.x86_64 requires mono(System.Xml) = 0:1.0.5000.0 nagios-plugins-snmp-disk-proc-1.2-6.fc13.x86_64 requires libnetsnmp.so.20()(64bit) 1:nant-0.85-34.fc13.x86_64 requires mono(ICSharpCode.SharpZipLib) = 0:0.84.0.0
Re: Polyinstantiated /tmp
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 10/31/2010 03:07 PM, Matt McCutchen wrote: On Wed, 2010-10-20 at 08:13 -0400, Daniel J Walsh wrote: I have been trying to get system processes to stop using /tmp for years. http://danwalsh.livejournal.com/11467.html As some one who lives with polyinstatiated namespace /tmp, The only problem I know of now is handing of kerberos tickets. Whenever a system process (root) needs to communicate with a user via /tmp. namespace /tmp breaks it. sssd can not create kerberos tickets in my /tmp and gssd can not find my kerberos tickets in /tmp. I believe the solution to both is to move the tickets to be managed by sssd and leave /tmp to users. BTW, X has solved this problem a couple of years ago by using virtual namespace for its sockets. In the abstract namespace, don't you have the same problem where if the real X server dies for any reason, other users can create a socket at the same path and mess with your applications? Yes although there, you can only create sockets. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/ iEYEARECAAYFAkzOtIAACgkQrlYvE4MpobPXgQCdH+Z26zudSVlF/SqhuXLdFJcE NHsAoNGkABKeaSxJ67kXjnuYM5tG1Nkr =qB2z -END PGP SIGNATURE- -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: rawhide report: 20101019 changes
On Tue, Oct 19, 2010 at 04:05:19PM +0100, Matthew Garrett wrote: On Tue, Oct 19, 2010 at 04:59:29PM +0200, Michal Hlavinka wrote: another benefit (not yet mentioned) is for filesystem encryption. I have / and /home encrypted and /usr not encrypted (for better performance of my laptop) I'm kind of curious about this. What's on / that benefits from being encrypted? Logfiles, some stuff in /etc? There is also /root and if you do not have /var on a separate partition, there might be application data on /var or temporary files in /var/tmp or /tmp. Regards Till pgpn9958UfRbk.pgp Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: -frecord-gcc-switches as default CFLAG?
On 10/30/2010 06:01 AM, Richard W.M. Jones wrote: On Sat, Oct 30, 2010 at 02:24:02AM -0400, Jon Stanley wrote: I noticed on my Fedora 13 box that in the RPM macro %__global_cflags that -frecord-gcc-switches is missing, which is a nifty compiler feature that will record the flags passed to gcc in a section in the object file, thus aiding in the how in the world was this compiled? problem. An example: [jstan...@hawtness ~]$ gcc -O2 -frecord-gcc-switches -g -o hello hello.c [jstan...@hawtness ~]$ readelf -p .GCC.command.line hello String dump of section '.GCC.command.line': [ 0] hello.c [ 8] -mtune=generic [17] -g [1a] -O2 [1e] -frecord-gcc-switches What do folks think about adding this as a default? Any reason not to (other than possibly a few bytes extra in the object files)? +1 I think would also catch those cases where some gcc flag is found to break code generation. You reasonably see which binaries were affected. I agree. Unless there is a notable performance cost in this, I say we should go for it. ~spot -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: -frecord-gcc-switches as default CFLAG?
On Mon, Nov 1, 2010 at 9:04 AM, Tom spot Callaway tcall...@redhat.com wrote: On 10/30/2010 06:01 AM, Richard W.M. Jones wrote: On Sat, Oct 30, 2010 at 02:24:02AM -0400, Jon Stanley wrote: I noticed on my Fedora 13 box that in the RPM macro %__global_cflags that -frecord-gcc-switches is missing, which is a nifty compiler feature that will record the flags passed to gcc in a section in the object file, thus aiding in the how in the world was this compiled? problem. An example: [jstan...@hawtness ~]$ gcc -O2 -frecord-gcc-switches -g -o hello hello.c [jstan...@hawtness ~]$ readelf -p .GCC.command.line hello String dump of section '.GCC.command.line': [ 0] hello.c [ 8] -mtune=generic [ 17] -g [ 1a] -O2 [ 1e] -frecord-gcc-switches What do folks think about adding this as a default? Any reason not to (other than possibly a few bytes extra in the object files)? +1 I think would also catch those cases where some gcc flag is found to break code generation. You reasonably see which binaries were affected. I agree. Unless there is a notable performance cost in this, I say we should go for it. How do you envision this working with debuginfo? Does this section get stripped out from normal install and collected into the -debuginfo subpackage, or does debuginfo need to be taught to leave this section intact in the actual installed binary? josh -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: -frecord-gcc-switches as default CFLAG?
On Mon, Nov 01, 2010 at 09:04:12AM -0400, Tom spot Callaway wrote: On 10/30/2010 06:01 AM, Richard W.M. Jones wrote: On Sat, Oct 30, 2010 at 02:24:02AM -0400, Jon Stanley wrote: I noticed on my Fedora 13 box that in the RPM macro %__global_cflags that -frecord-gcc-switches is missing, which is a nifty compiler feature that will record the flags passed to gcc in a section in the object file, thus aiding in the how in the world was this compiled? problem. An example: [jstan...@hawtness ~]$ gcc -O2 -frecord-gcc-switches -g -o hello hello.c [jstan...@hawtness ~]$ readelf -p .GCC.command.line hello String dump of section '.GCC.command.line': [ 0] hello.c [ 8] -mtune=generic [17] -g [1a] -O2 [1e] -frecord-gcc-switches What do folks think about adding this as a default? Any reason not to (other than possibly a few bytes extra in the object files)? +1 I think would also catch those cases where some gcc flag is found to break code generation. You reasonably see which binaries were affected. I agree. Unless there is a notable performance cost in this, I say we should go for it. -frecord-gcc-switches is unfortunately pretty much useless, see http://gcc.gnu.org/PR32998. Please don't add it, we want something actually usable, not this option. Jakub -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: RemoveSETUID feature (Was: Summary/Minutes from today's FESCo meeting (2010-10-26) NEW TIME!)
On 29/10/10 04:15, Jason L Tibbitts III wrote: JN == Joe Nallj...@nall.com writes: JN On Oct 28, 2010, at 5:08 PM, Richard W.M. Jones wrote: More to the point, I can easily see the setuid bit easily on a binary. How do I tell if these strange/hidden capabilities are present on a binary? 'ls' doesn't mention anything. JN getcap Interesting. That's in the libcap package, which is sort of oddly named because it includes executables. And of course it's multilib, but the binaries are arch-specific which I believe is a multilib conflict. Probably needs the executables split out into a libcap-tools packages. I notice that rpm supports that %caps() directive in the %files list to specify capabilities. I don't recall seeing that before; how long ago did rpm grow support for it? It looks like it came in around rpm 4.7, so all supported Fedora releases have it. However, I'm certain it's not in RHEL4 and I'm pretty sure it's not in RHEL5 either, so at least the EPEL folks will need to make a note of it. I've just come across another issue with this. I use the tmpfs plugin with mock usually, and it appears that tmpfs doesn't support the necessary file capabilities, as I get these errors when setting up the buildroot: DEBUG util.py:267: Error unpacking rpm package iputils-20101006-2.fc15.x86_64 DEBUG util.py:267: error: unpacking of archive failed on file /bin/ping: cpio: cap_set_file failed - Operation not supported DEBUG util.py:267: Error unpacking rpm package policycoreutils-2.0.83-32.fc15.x86_64 DEBUG util.py:267: error: unpacking of archive failed on file /usr/sbin/seunshare: cpio: cap_set_file failed - Operation not supported If I disable the tmpfs plugin, so mock uses the ext3 filesystem I have on /var/lib/mock, the build succeeds. So at least I have a workaround but I'd like to have tmpfs working as it *really* improves performance. Paul. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Polyinstantiated /tmp
On Sun, 2010-10-31 at 15:07 -0400, Matt McCutchen wrote: On Wed, 2010-10-20 at 08:13 -0400, Daniel J Walsh wrote: I have been trying to get system processes to stop using /tmp for years. http://danwalsh.livejournal.com/11467.html As some one who lives with polyinstatiated namespace /tmp, The only problem I know of now is handing of kerberos tickets. Whenever a system process (root) needs to communicate with a user via /tmp. namespace /tmp breaks it. sssd can not create kerberos tickets in my /tmp and gssd can not find my kerberos tickets in /tmp. I believe the solution to both is to move the tickets to be managed by sssd and leave /tmp to users. BTW, X has solved this problem a couple of years ago by using virtual namespace for its sockets. In the abstract namespace, don't you have the same problem where if the real X server dies for any reason, other users can create a socket at the same path and mess with your applications? There are multiple problems ... the one that using the abstract socket namespace solves is that you can have a per. user /tmp and still communicate between users. Much like if you have a per. user /tmp but /tmp/global was shared among all users, and kerberos/X/whatever all used that (IMNSHO much better than using the abstract namespace ... but meh). -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Package review template
Hi everyone, I just put my package review template on my wiki space at : https://fedoraproject.org/wiki/User:Jfsaucier/Review_Template My template is simply a collection based on other's already existing template. What I did is I tried to put missing checks and sort them in an order that should go well when doing a review. My goal here is to try to produce a good review template to publicize and help people doing package review. If you can help growing my review template checklist or think of something to improve it, that would be really helpful. Also, if you spot any errors or have any comment, I will be happy to receive them. I plan to put up some scripts to automate part of the review process as soon as I have the time to finish them. Thank you! -- Jean-Francois Saucier (djf_jeff) GPG key : 0xA9E6E953 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Package review template
On 11/01/2010 03:32 PM, Jean-Francois Saucier wrote: Hi everyone, I just put my package review template on my wiki space at : https://fedoraproject.org/wiki/User:Jfsaucier/Review_Template I created something similar specifically for Java reviews with Java SIG members improving it bit by bit: https://fedoraproject.org/wiki/Java_review_template My template is simply a collection based on other's already existing template. What I did is I tried to put missing checks and sort them in an order that should go well when doing a review. From the looks of it, I'd say we used the same base :-) My goal here is to try to produce a good review template to publicize and help people doing package review. If you can help growing my review template checklist or think of something to improve it, that would be really helpful. Also, if you spot any errors or have any comment, I will be happy to receive them. I'd like to see links to packaging guidelines for each point (or at least for non-obvious ones). It's helpful for the both parties to know why they have to fix things. I plan to put up some scripts to automate part of the review process as soon as I have the time to finish them. That would be great. -- Stanislav Ochotnicky sochotni...@redhat.com Associate Software Engineer - Base Operating Systems Brno PGP: 71A1677C Red Hat Inc. http://cz.redhat.com signature.asc Description: OpenPGP digital signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: RemoveSETUID feature (Was: Summary/Minutes from today's FESCo meeting (2010-10-26) NEW TIME!)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 11/01/2010 09:44 AM, Paul Howarth wrote: On 29/10/10 04:15, Jason L Tibbitts III wrote: JN == Joe Nallj...@nall.com writes: JN On Oct 28, 2010, at 5:08 PM, Richard W.M. Jones wrote: More to the point, I can easily see the setuid bit easily on a binary. How do I tell if these strange/hidden capabilities are present on a binary? 'ls' doesn't mention anything. JN getcap Interesting. That's in the libcap package, which is sort of oddly named because it includes executables. And of course it's multilib, but the binaries are arch-specific which I believe is a multilib conflict. Probably needs the executables split out into a libcap-tools packages. I notice that rpm supports that %caps() directive in the %files list to specify capabilities. I don't recall seeing that before; how long ago did rpm grow support for it? It looks like it came in around rpm 4.7, so all supported Fedora releases have it. However, I'm certain it's not in RHEL4 and I'm pretty sure it's not in RHEL5 either, so at least the EPEL folks will need to make a note of it. I've just come across another issue with this. I use the tmpfs plugin with mock usually, and it appears that tmpfs doesn't support the necessary file capabilities, as I get these errors when setting up the buildroot: DEBUG util.py:267: Error unpacking rpm package iputils-20101006-2.fc15.x86_64 DEBUG util.py:267: error: unpacking of archive failed on file /bin/ping: cpio: cap_set_file failed - Operation not supported DEBUG util.py:267: Error unpacking rpm package policycoreutils-2.0.83-32.fc15.x86_64 DEBUG util.py:267: error: unpacking of archive failed on file /usr/sbin/seunshare: cpio: cap_set_file failed - Operation not supported If I disable the tmpfs plugin, so mock uses the ext3 filesystem I have on /var/lib/mock, the build succeeds. So at least I have a workaround but I'd like to have tmpfs working as it *really* improves performance. Paul. Paul is this because NOSUID is set on tmpfs? -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/ iEYEARECAAYFAkzO1ukACgkQrlYvE4MpobNTRgCgvpFXeGWful7wY1np4buMLBrc 1zEAoNIBDFDHQ9t8qoqljX9pRlACOUFS =27qj -END PGP SIGNATURE- -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: The new Update Acceptance Criteria are broken
On Sun, 31 Oct 2010 10:16:41 -0400 Clyde E. Kunkel clydekunkel7...@cox.net wrote: On 10/31/2010 03:18 AM, Michael Schwendt wrote: Okay, feedback time. Lately, there have been several attempts at urging proventesters (and not just testers in general) to give positive karma for aging critpath updates. It also has been decided by someone (or maybe even a comittee) to spam proventesters daily with [old_testing_critpath] messages for all three dist releases, with no day to unsubscribe from that (other than leaving proventesters group, which is what at least one person has threatened with, or filtering those messages). Yeah, I am not sure at all how usefull those emails are. There are a variety of ways to see what things need testing, sending emails to proventesters a bunch isn't likely to be a very nice one. Dunno about other testers (and there aren't many yet), but I have abandoned F-12 long ago due to lack of time when F-13 became the one to use on a daily basis. And some time before F-14 Beta, my desktop has been switched to boot F-14 by default. That's the only opportunity to evaluate F-14 early and possibly find issues prior to its release. On the contrary, most of Fedora's users will wait for the final release, and many users will wait even longer. It's highly likely that bugzilla can confirm that. I've got a f12 vm that I can run command line testing easily and some limited gui testing (vnc). F-14 is the the only way forward, and don't like to spend time on F-13 and older anymore. That also applies to packagers I maintain or monitor. I simply don't see the user base [target group] anymore. It's really hard to tell I'm afraid, but I understand your feeling there. I also would love some simple per-package test plans. My thought was that our testing could start out with a very low bar, and go from there. ie, Does it install. Does it run and display a window, etc. If there was a test plan page for better testing that would be great. If there was a way to test a specific bug that would also be great. (several updates have included test cases in their bug that were great to test and confirm it was fixed). Anyhow, I agree we should look at adjusting the f12 setup (although its only got 1 month left), as well as look at dropping the emails to proventesters with old testing stuff. Thanks for the constructive feedback Clyde and Michael. Specific plans for changing things for the better welcome. kevin signature.asc Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Package review template
I plan to put up some scripts to automate part of the review process as soon as I have the time to finish them. Great idea. I hacked a little script some time ago. It may be a little outdated now, non optimally designed, but maybe something could be reused in your project: http://jskarvad.fedorapeople.org/pmreview Jaroslav -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Package review template
On Mon, 2010-11-01 at 15:58 +0100, Stanislav Ochotnicky wrote: I plan to put up some scripts to automate part of the review process as soon as I have the time to finish them. Some time ago I put this together: http://project.pingoured.fr/reviewHelper/ The idea here is of course not to do the review but to help at doing it by automating what can be. This version covers I think most of R's packaging features. Pierre -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: The new Update Acceptance Criteria are broken (was: Re: Heads Up - New Firefox update)
On Mon, 2010-11-01 at 02:18 +0100, Miloslav Trmač wrote: Kevin, could you *please* not word things like that? There's just no need for it. I already wrote this to -test a couple of days ago: http://lists.fedoraproject.org/pipermail/test/2010-October/095135.html and we're discussing it there. I think the thread demonstrates things tend to go much more constructively if you avoid throwing words like 'blatant' and 'failure' and 'needlessly' around. Did we not fail our users? Was there a real need to fail them? (As a non-native speaker, I won't judge the relative merits of blatant vs. sucks.) I didn't say that what Kevin said was *wrong*, I said it wasn't the best way to word it. We designed a policy, put it into effect, now we're observing how well it works and we can modify its implementation on the fly. It doesn't need to be done in an adversarial spirit. Given that _this exact scenario_ was repeatedly brought up since the very start of the update acceptance criteria proposals, I think some frustration is quite justified. This situation is not really a surprise, and Fedora did not have to unnecessarily expose users to a vulnerability in order to relearn this lesson. On the other hand, other scenarios were also brought up, which have not come to pass - for instance, the same thing happening to Fedora 13 or Fedora 14. If we had simply accepted the predictions of doom and not implemented the policy at all, we would be without its benefits for the development of F13 and F14. In addition to being constructive about remedying the situation, shouldn't we try to be more constructive about _not introducing such situations_ in the first place? Mirek Saying 'oh dear, this might not work, we'd better not try' is rarely a good approach, IMHO. It's better to try things, with the proviso that you accept when they aren't working and withdraw or modify them. -- 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: The new Update Acceptance Criteria are broken (was: Re: Heads Up - New Firefox update)
On Mon, 2010-11-01 at 03:54 +0100, Kevin Kofler wrote: There's exactly one constructive thing to do, it's repealing this set of policies (Critical Path and Update Acceptance Criteria) in its entirety. An update should go stable when the maintainer says so, karma should be purely informational feedback for the maintainer. I disagree. The evidence you cite does not support this conclusion. We implemented the policies for three releases. There are significant problems with one release. This does not justify the conclusion that the policies should be entirely repealed. -- 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: The new Update Acceptance Criteria are broken (was: Re: Heads Up - New Firefox update)
On Mon, Nov 1, 2010 at 5:08 PM, Adam Williamson awill...@redhat.com wrote: Saying 'oh dear, this might not work, we'd better not try' is rarely a good approach, IMHO. It's better to try things, with the proviso that you accept when they aren't working and withdraw or modify them. I would agree with this, if the let's try them and see what happens approach to a process makes it a point to set up a set of specific conditions before putting a new process in place which latch a withdraw of the process. Hey we are going to try this.. and if this or this other things happens..then we are going to stop doing this and put our heads together and have a little re-think about modifying the process -jef -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: The new Update Acceptance Criteria are broken (was: Re: Heads Up - New Firefox update)
Adam Williamson píše v Po 01. 11. 2010 v 10:08 -0700: We designed a policy, put it into effect, now we're observing how well it works and we can modify its implementation on the fly. It doesn't need to be done in an adversarial spirit. Given that _this exact scenario_ was repeatedly brought up since the very start of the update acceptance criteria proposals, I think some frustration is quite justified. This situation is not really a surprise, and Fedora did not have to unnecessarily expose users to a vulnerability in order to relearn this lesson. On the other hand, other scenarios were also brought up, which have not come to pass - for instance, the same thing happening to Fedora 13 or Fedora 14. If we had simply accepted the predictions of doom and not implemented the policy at all, we would be without its benefits for the development of F13 and F14. A problem with this line of argument is that the benefits are not quite apparent to me. In addition to being constructive about remedying the situation, shouldn't we try to be more constructive about _not introducing such situations_ in the first place? Saying 'oh dear, this might not work, we'd better not try' is rarely a good approach, IMHO. That is a cost-benefit comparison. New does not imply improved. It's better to try things, with the proviso that you accept when they aren't working and withdraw or modify them. It's even better not to dismiss known problems with the policy, and to make sure the policy can handle them properly from the start. This was not a surprise, this was an unforced error. Mirek -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: The new Update Acceptance Criteria are broken (was: Re: Heads Up - New Firefox update)
On Mon, 2010-11-01 at 18:29 +0100, Miloslav Trmač wrote: On the other hand, other scenarios were also brought up, which have not come to pass - for instance, the same thing happening to Fedora 13 or Fedora 14. If we had simply accepted the predictions of doom and not implemented the policy at all, we would be without its benefits for the development of F13 and F14. A problem with this line of argument is that the benefits are not quite apparent to me. The policies prevented us from shipping a number of completely broken updates, which is exactly what they were intended to do. I don't have a command handy to do a search for rejected proposed critpath updates for F14, but if you figure it out, you can see the precise results of the policy there. In addition to being constructive about remedying the situation, shouldn't we try to be more constructive about _not introducing such situations_ in the first place? Saying 'oh dear, this might not work, we'd better not try' is rarely a good approach, IMHO. That is a cost-benefit comparison. New does not imply improved. We had an extensive discussion about the benefits of testing important updates at the time the policy went into effect. I don't think it's really necessary to re-hash the entire thing. For the record, I did not say nor do I believe that new inevitably implies improved. It's better to try things, with the proviso that you accept when they aren't working and withdraw or modify them. It's even better not to dismiss known problems with the policy, and to make sure the policy can handle them properly from the start. This was not a surprise, this was an unforced error. Sorry, but characterizing it as a 'known problem' is misleading. It's easy to forecast failure, and you'll likely always be correct in *some* cases if you forecast enough failures. Only if you precisely forecast only the failures that actually happen, and do not forecast any failures that don't happen, can your forecast be considered truly reliable. If this had truly been a 'known problem' then those who predicted it would also have correctly chosen *not* to predict failure in the case of Fedora 13 and Fedora 14. The fact is that they did predict a failure which has not, in fact, come to pass (neither F13 nor F14 have long queues of old critpath updates). -- 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
[Bug 648598] New: perl-Term-ProgressBar is missing a dependency on perl-TermReadKey
Please do not reply directly to this email. All additional
comments should be made in the comments box of this bug.
Summary: perl-Term-ProgressBar is missing a dependency on perl-TermReadKey
https://bugzilla.redhat.com/show_bug.cgi?id=648598
Summary: perl-Term-ProgressBar is missing a dependency on
perl-TermReadKey
Product: Fedora
Version: rawhide
Platform: Unspecified
OS/Version: Unspecified
Status: NEW
Severity: medium
Priority: low
Component: perl-Term-ProgressBar
AssignedTo: cw...@alumni.drew.edu
ReportedBy: mbo...@redhat.com
QAContact: extras...@fedoraproject.org
CC: cw...@alumni.drew.edu,
fedora-perl-devel-l...@redhat.com
Classification: Fedora
Target Release: ---
Description of problem:
While perl-Term-ProgressBar can function without Term::ReadKey, it cannot
detect the width of a window, making the progress bar less than entirely
useful. The spec file is relying on automatic dependencies, but doesn't pick up
Term::ReadKey because the source doesn't 'use' it:
eval {
require Term::ReadKey;
}; if ($@) {
warn Guessing terminal width due to problem with Term::ReadKey\n;
return 50;
}
perl-TermReadKey was previously in limbo, but now seems to be included.
perl-Term-ProgressBar should depend on it, as the experience without it is
poor.
I've filed this against rawhide, but it applies equally to F13 and F14.
perl-TermReadKey is now available in all 3 places. I've attached a spec file
patch.
Version-Release number of selected component (if applicable):
perl-Term-ProgressBar-2.09-8
--
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: The new Update Acceptance Criteria are broken (was: Re: Heads Up - New Firefox update)
Adam Williamson píše v Po 01. 11. 2010 v 10:39 -0700: On Mon, 2010-11-01 at 18:29 +0100, Miloslav Trmač wrote: It's better to try things, with the proviso that you accept when they aren't working and withdraw or modify them. It's even better not to dismiss known problems with the policy, and to make sure the policy can handle them properly from the start. This was not a surprise, this was an unforced error. Sorry, but characterizing it as a 'known problem' is misleading. It's easy to forecast failure, and you'll likely always be correct in *some* cases if you forecast enough failures. Only if you precisely forecast only the failures that actually happen, and do not forecast any failures that don't happen, can your forecast be considered truly reliable. The accuracy of prediction, and especially accuracy of the timing, is not at all relevant. In fact, it is _preciselly_ the unknown nature of risks that requires thinking about them in advance. People don't wear helmets because they know when something will hit their head, but because they don't know when, or even if, it will. Mirek -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: The new Update Acceptance Criteria are broken (was: Re: Heads Up - New Firefox update)
On Mon, 2010-11-01 at 18:51 +0100, Miloslav Trmač wrote: Sorry, but characterizing it as a 'known problem' is misleading. It's easy to forecast failure, and you'll likely always be correct in *some* cases if you forecast enough failures. Only if you precisely forecast only the failures that actually happen, and do not forecast any failures that don't happen, can your forecast be considered truly reliable. The accuracy of prediction, and especially accuracy of the timing, is not at all relevant. In fact, it is _preciselly_ the unknown nature of risks that requires thinking about them in advance. Which rather contradicts your description of it as a 'known problem', yes? People don't wear helmets because they know when something will hit their head, but because they don't know when, or even if, it will. Mirek That's not really a relevant analogy. You can't 'wear a helmet' in this case. There's no way we could have implemented the policy and 'worn a helmet' by allowing updates to happen without the conditions of the policy being fulfilled; that would effectively negate the policy. If you want to continue with the analogy, what you seem to be saying is that we should never have implemented the policy in the first place, which is not analogous to wearing a helmet; it's analogous to never leaving the house just in case something hits you on the head. -- 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: The new Update Acceptance Criteria are broken (was: Re: Heads Up - New Firefox update)
Adam Williamson píše v Po 01. 11. 2010 v 10:55 -0700: On Mon, 2010-11-01 at 18:51 +0100, Miloslav Trmač wrote: Sorry, but characterizing it as a 'known problem' is misleading. It's easy to forecast failure, and you'll likely always be correct in *some* cases if you forecast enough failures. Only if you precisely forecast only the failures that actually happen, and do not forecast any failures that don't happen, can your forecast be considered truly reliable. The accuracy of prediction, and especially accuracy of the timing, is not at all relevant. In fact, it is _preciselly_ the unknown nature of risks that requires thinking about them in advance. Which rather contradicts your description of it as a 'known problem', yes? No; the existence of the problem was known, only the timing and precise extent was not. If you want to continue with the analogy, what you seem to be saying is that we should never have implemented the policy in the first place, That is one option; another would be adding a I'm the maintainer and I really mean it checkbox for security updates (with FESCo/Fedora QA/somebody else reviewing the cases retrospectively, if they feel like it); yeat another is not enforcing the policy on security updates at all, as I seem to remember was proposed (or even implemented?) at one time. Mirek -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: The new Update Acceptance Criteria are broken (was: Re: Heads Up - New Firefox update)
Adam Williamson wrote: On the other hand, other scenarios were also brought up, which have not come to pass - for instance, the same thing happening to Fedora 13 or Fedora 14. Nonsense. We just do not have enough evidence yet to show such things happening for F13 and F14. They CAN, and IMHO WILL, happen, e.g.: * Will a critical security fix for Konqueror get karma as quickly as the one for Firefox did? (This is especially relevant considering that some people want to put the whole KDE workspace into critpath. But even non-critpath updates need karma to get pushed.) * Would that Firefox update have gotten karma that quickly without the nagmail to the devel ML? Do you think the approach of sending nagmail scales? And at least for F14 development, there have been other, less critical failures, which I've already pointed out in the respective threads. If we had simply accepted the predictions of doom and not implemented the policy at all, we would be without its benefits for the development of F13 and F14. What benefits? I see only problems, in fact the very ones I've warned about right from the beginning. Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: The new Update Acceptance Criteria are broken (was: Re: Heads Up - New Firefox update)
Adam Williamson wrote: The policies prevented us from shipping a number of completely broken updates, which is exactly what they were intended to do. I don't have a command handy to do a search for rejected proposed critpath updates for F14, but if you figure it out, you can see the precise results of the policy there. They also let several completely broken updates through and then delayed the FIXES for those updates, exactly as I had been warning about all the time. For example, my firstboot update which was required to make the Xfce spin work again (there was an additional problem with the LXDE spin, but that one was present both before and after that update, and could only be noticed after that update was pushed) got delayed. The fact is that they did predict a failure which has not, in fact, come to pass (neither F13 nor F14 have long queues of old critpath updates). Even ONE old critpath update is a failure. Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: -frecord-gcc-switches as default CFLAG?
On Mon, Nov 1, 2010 at 9:12 AM, Jakub Jelinek ja...@redhat.com wrote: -frecord-gcc-switches is unfortunately pretty much useless, see http://gcc.gnu.org/PR32998. Please don't add it, we want something actually usable, not this option. Isn't it more useful in this state than not having the data at all? It seems that the bug that you refer to is about appending things to DW_AT_producer at this point, which is also useful, but I'm not convinced about that use of DW_AT_producer either, but that's another thread. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: The new Update Acceptance Criteria are broken (was: Re: Heads Up - New Firefox update)
On Mon, 01 Nov 2010 19:26:43 +0100 Kevin Kofler kevin.kof...@chello.at wrote: They also let several completely broken updates through and then delayed the FIXES for those updates, exactly as I had been warning about all the time. Cite(s)? For example, my firstboot update which was required to make the Xfce spin work again (there was an additional problem with the LXDE spin, but that one was present both before and after that update, and could only be noticed after that update was pushed) got delayed. If You mean: https://admin.fedoraproject.org/updates/firstboot-1.113-4.fc14 it didn't break the Xfce spin. Xfce spin is using gdm still, which means metacity is pulled in, which means firstboot was fine. So, this case seems to me like a poor example for your position. kevin signature.asc Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: RemoveSETUID feature (Was: Summary/Minutes from today's FESCo meeting (2010-10-26) NEW TIME!)
On Mon, 01 Nov 2010 11:04:09 -0400 Daniel J Walsh dwa...@redhat.com wrote: On 11/01/2010 09:44 AM, Paul Howarth wrote: On 29/10/10 04:15, Jason L Tibbitts III wrote: JN == Joe Nallj...@nall.com writes: JN On Oct 28, 2010, at 5:08 PM, Richard W.M. Jones wrote: More to the point, I can easily see the setuid bit easily on a binary. How do I tell if these strange/hidden capabilities are present on a binary? 'ls' doesn't mention anything. JN getcap Interesting. That's in the libcap package, which is sort of oddly named because it includes executables. And of course it's multilib, but the binaries are arch-specific which I believe is a multilib conflict. Probably needs the executables split out into a libcap-tools packages. I notice that rpm supports that %caps() directive in the %files list to specify capabilities. I don't recall seeing that before; how long ago did rpm grow support for it? It looks like it came in around rpm 4.7, so all supported Fedora releases have it. However, I'm certain it's not in RHEL4 and I'm pretty sure it's not in RHEL5 either, so at least the EPEL folks will need to make a note of it. I've just come across another issue with this. I use the tmpfs plugin with mock usually, and it appears that tmpfs doesn't support the necessary file capabilities, as I get these errors when setting up the buildroot: DEBUG util.py:267: Error unpacking rpm package iputils-20101006-2.fc15.x86_64 DEBUG util.py:267: error: unpacking of archive failed on file /bin/ping: cpio: cap_set_file failed - Operation not supported DEBUG util.py:267: Error unpacking rpm package policycoreutils-2.0.83-32.fc15.x86_64 DEBUG util.py:267: error: unpacking of archive failed on file /usr/sbin/seunshare: cpio: cap_set_file failed - Operation not supported If I disable the tmpfs plugin, so mock uses the ext3 filesystem I have on /var/lib/mock, the build succeeds. So at least I have a workaround but I'd like to have tmpfs working as it *really* improves performance. Paul. Paul is this because NOSUID is set on tmpfs? The tmpfs is set up by mock and I can't see anywhere in the mock code that it sets nosuid. I can't tell from outside mock what options it's using as it also uses a namespace. If I just run mount from within a package build I don't get any output. Any suggestions? Paul. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Package review template
On 11/1/2010 9:32, Jean-Francois Saucier wrote:
I just put my package review template on my wiki space at :
https://fedoraproject.org/wiki/User:Jfsaucier/Review_Template
[ ] SourceX is a working URL.
[ ] SourceX / PatchY prefixed with %{name}.
[ ] Final provides and requires are sane (rpm -q --provides and rpm -q
--requires).
[ ] %check is present and all tests pass.
[ ] Latest version is packaged.
Where do these come from? I understand why they're useful and all, but
I'm not sure what guidelines recommend them.
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
[Bug 647783] perl-Mail-Box shouldn't force spamassassin to be installed
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug. https://bugzilla.redhat.com/show_bug.cgi?id=647783 Tom spot Callaway tcall...@redhat.com changed: What|Removed |Added CC||ke...@tummy.com, ||n...@fedoraproject.org, ||wtogami+fed...@gmail.com Component|perl-Mail-Box |spamassassin AssignedTo|tcall...@redhat.com |wtogami+fed...@gmail.com --- Comment #1 from Tom spot Callaway tcall...@redhat.com 2010-11-01 16:02:10 EDT --- I'm not inclined to hack up perl-Mail-Box to remove the dependency here. I'd much rather see spamassassin-perl split off. Reassigning to spamassassin. Note: if the perl components do go into a spamassassin-perl subpackage, this package would not need to be rebuilt, as it depends on perl(Mail::SpamAssassin) -- 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: RemoveSETUID feature (Was: Summary/Minutes from today's FESCo meeting (2010-10-26) NEW TIME!)
On Mon, Nov 01, 2010 at 07:19:15PM +, Paul Howarth wrote: Any suggestions? We've encountered some funny things about tmpfs before: It doesn't support O_DIRECT at all, for example, necessitating workarounds in libguestfs/qemu. Just speculating, but maybe it doesn't support extended attributes, or has only partial support for them? Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming blog: http://rwmj.wordpress.com Fedora now supports 80 OCaml packages (the OPEN alternative to F#) http://cocan.org/getting_started_with_ocaml_on_red_hat_and_fedora -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: RemoveSETUID feature
Yeah, it looks like the capabilities thing has broken my buildsystem: Error unpacking rpm package iputils-20101006-2.fc15.x86_64 error: unpacking of archive failed on file /bin/ping: cpio: cap_set_file failed - Operation not supported Error unpacking rpm package policycoreutils-2.0.83-32.fc15.x86_64 error: unpacking of archive failed on file /usr/sbin/seunshare: cpio: cap_set_file failed - Operation not supported I don't use the mock tmpfs plugin; I just have a big tmpfs mounted on /mock that everything is built in. grep mock /proc/mounts tmpfs /mock tmpfs rw,rootcontext=unconfined_u:object_r:default_t:s0,seclabel,relatime,size=10485760k,nr_inodes=1048576,mode=2775,gid=219 0 0 I'm thinking that tmpfs simply doesn't support capabilities, which would be... unfortunate. - J -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: The new Update Acceptance Criteria are broken (was: Re: Heads Up - New Firefox update)
mån 2010-11-01 klockan 10:09 -0700 skrev Adam Williamson: I disagree. The evidence you cite does not support this conclusion. We implemented the policies for three releases. There are significant problems with one release. This does not justify the conclusion that the policies should be entirely repealed. I don't mind the process in general, but have some points where it can improve Very often the same update is submitted for several releases, and it's kind of pointless to require full karma in all releases (to require some in each release is ok). If one release has got full karma then it's reasonable to require less karma on other releases receiving the same update. The risk for non-obvious regression for some release only is fairly low, more likely there is very obvious release specific regressions like dependency failures when another package have been split/merged etc and related fuckups. We also need some obvious ways where users in general can subscribe to testing updates of stuff that they care about, to expand the userbase that performs testing of updates. Generally running a system with updates-testing always enabled is scary and not many want to take that leap. But I think that if we could give users the ability to subscribe to testing packages X,Y,Z of their choics and getting update testing notifications for those packages only from updates-testing would speed things up considerably. In addition the package management update request process could do with some serious makeover to streamline the process and reduce risk for error, but that's topic for another thread. Regards Henrik -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Detecting systems booting with GRUB2 in anaconda
Hi, I was asked about problem with installing Fedora 13 on a machine that is dual booting Windows 7 and another distro using GRUB2. There is nothing about GRUB2 in Installation Guide http://docs.fedoraproject.org/en-US/Fedora/13/html/Installation_Guide/s1-x86-bootloader.html To add, remove, or change the detected operating system settings, use the options provided. It is not clear is anaconda capable to detect properly such distro that uses GRUB2 and add it as additional system to Fedora GRUB menu list? Here is e-mail that I received about this problem: And Fedora has made my ubuntu installation unreachable (remember I'm a novice). I expected GRUB2 like behavior - list the available OSes. Instead I have Fedora and Other, with other pointing to Windows 7. You can try to add Ubuntu to this grub.conf Unfortunately, it looks like I was nailed pretty good on this one. Though a novice, I know that fdisk -l and blockid give me a lot of info. So I know the Ubuntu device (/dev/sda5), but Fedora complains when trying to mount it (Error mounting: wrong fs type, bad option, bad superblock on /dev/sda5). Booting from a Ubuntu LiveCD is the same. fschk -f /dev/sda5 - no joy. And trying to repair the superblock by hand with e2fsck, dumpe2fs and friends has not helped. I think I'm too ignorant of the file system to correct the problems that the installer created. Perhaps you could ask the Fedora team to add a test case: Install Fedora on a machine that is dual booting Windows 7 and another distro using GRUB2. The results might be alarming considering I did not receive one warning for the operation. Alexey Kurov nuc...@fedoraproject.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Summary/Minutes from today's FESCo meeting (2010-10-26) NEW TIME!
fre 2010-10-29 klockan 08:32 -0400 skrev James Antill: I don't think you need to display them, just display something that says this is more than it seems ... like ACLs. Something as simple as -rwcr-xr-x. instead of -rwsr-xr-x. for setuid. I.e. kind of like what ls --color does? Regards Henrik -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: The new Update Acceptance Criteria are broken (was: Re: Heads Up - New Firefox update)
On Mon, 2010-11-01 at 22:54 +0100, Henrik Nordström wrote: mån 2010-11-01 klockan 10:09 -0700 skrev Adam Williamson: I disagree. The evidence you cite does not support this conclusion. We implemented the policies for three releases. There are significant problems with one release. This does not justify the conclusion that the policies should be entirely repealed. I don't mind the process in general, but have some points where it can improve Very often the same update is submitted for several releases, and it's kind of pointless to require full karma in all releases (to require some in each release is ok). If one release has got full karma then it's reasonable to require less karma on other releases receiving the same update. The risk for non-obvious regression for some release only is fairly low, more likely there is very obvious release specific regressions like dependency failures when another package have been split/merged etc and related fuckups. This is a reasonable modification of the idea that an update should only require karma for one release (which would be nice if it were true but unfortunately isn't). In practice, though, there isn't much wiggle room for requiring 'less' karma. Non-critpath updates already require only one +1 to go through without the waiting time requirement. Critpath updates only require +1 from a proventester and +1 from any other tester (proven or not). I think I'd probably support the proposal that if a critpath update exists in identical form for multiple releases, and it has passed full critpath karma requirements for one release, it should require only +1 from any tester on the other releases to go out. We also need some obvious ways where users in general can subscribe to testing updates of stuff that they care about, to expand the userbase that performs testing of updates. Generally running a system with updates-testing always enabled is scary and not many want to take that leap. But I think that if we could give users the ability to subscribe to testing packages X,Y,Z of their choics and getting update testing notifications for those packages only from updates-testing would speed things up considerably. That's also a nice idea (though it's somewhat complex given that updates are *actually* pushed out as sets, and a given update may be affected by another given update even if they don't have an explicit relationship through dependencies). -- 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: Detecting systems booting with GRUB2 in anaconda
On Mon, Nov 1, 2010 at 10:00 PM, alekc...@googlemail.com wrote: There is nothing about GRUB2 in Installation Guide I'm not sure why there would be an expectation that their would be. Fedora doesn't use Grub2. There are many possible bootloaders that could be on a system. Do we mention any of them by name anywhere? We do have this just above the snippet you quote: You may have a boot loader installed on your system already. An operating system may install its own preferred boot loader, or you may have installed a third-party boot loader.If your boot loader does not recognize Linux partitions, you may not be able to boot Fedora How do we make it any clearer than that? -jef -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: The new Update Acceptance Criteria are broken (was: Re: Heads Up - New Firefox update)
mån 2010-11-01 klockan 15:12 -0700 skrev Adam Williamson: This is a reasonable modification of the idea that an update should only require karma for one release (which would be nice if it were true but unfortunately isn't). In practice, though, there isn't much wiggle room for requiring 'less' karma. Non-critpath updates already require only one +1 to go through without the waiting time requirement. Critpath updates only require +1 from a proventester and +1 from any other tester (proven or not). Right. I was mostly thinking about the autokarma I think. Not normally doing pushes until after the waiting period. I think I'd probably support the proposal that if a critpath update exists in identical form for multiple releases, and it has passed full critpath karma requirements for one release, it should require only +1 from any tester on the other releases to go out. Yes. From the same reasoning explained before. If it's provenly tested in one release then chances are very high it works in the other releases as well unless it doesn't work at all. Regards Henrik -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Detecting systems booting with GRUB2 in anaconda
What can expect user that have system booting with GRUB2 and installing Fedora? It is natural to expect that after Fedora installation will be bootable both systems Fedora and other distro. But if GRUB2 can not be detected there should be some kind of warning about that. This is the reason why it may be described in Installation Guide. Fedora 14 Installation Guide have some mention about GRUB2 but it is still not clear is anaconda capable to detect it. http://docs.fedoraproject.org/en-US/Fedora/14/html/Installation_Guide/s1-x86-bootloader.html Jeff Spaleta wrote: On Mon, Nov 1, 2010 at 10:00 PM, alekc...@googlemail.com wrote: There is nothing about GRUB2 in Installation Guide I'm not sure why there would be an expectation that their would be. Fedora doesn't use Grub2. There are many possible bootloaders that could be on a system. Do we mention any of them by name anywhere? We do have this just above the snippet you quote: You may have a boot loader installed on your system already. An operating system may install its own preferred boot loader, or you may have installed a third-party boot loader.If your boot loader does not recognize Linux partitions, you may not be able to boot Fedora How do we make it any clearer than that? -jef -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Detecting systems booting with GRUB2 in anaconda
On Mon, Nov 1, 2010 at 10:32 PM, alekc...@googlemail.com wrote: Fedora 14 Installation Guide have some mention about GRUB2 but it is still not clear is anaconda capable to detect it. http://docs.fedoraproject.org/en-US/Fedora/14/html/Installation_Guide/s1-x86-bootloader.html There is one reference to GRUB 2 to help clarify that Fedora does not use it. There's no suggestion anywhere that it or any other alternative bootloader is detectable or supported. Also there is this: If you have other operating systems already installed, Fedora attempts to automatically detect and configure GRUB to boot them. You may manually configure any additional operating systems if GRUB does not detect them. There is an attempt made but there's no effort to list which operating system that can be successfully detected. No specific operating system is named as being known to be detectable. -jef -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Getting users to test updates
[changing topic to split this out to it's own thread] mån 2010-11-01 klockan 15:12 -0700 skrev Adam Williamson: We also need some obvious ways where users in general can subscribe to testing updates of stuff that they care about, to expand the userbase that performs testing of updates. Generally running a system with updates-testing always enabled is scary and not many want to take that leap. But I think that if we could give users the ability to subscribe to testing packages X,Y,Z of their choics and getting update testing notifications for those packages only from updates-testing would speed things up considerably. That's also a nice idea (though it's somewhat complex given that updates are *actually* pushed out as sets, and a given update may be affected by another given update even if they don't have an explicit relationship through dependencies). Not sure it's bad to expose that complexity to the package maintainers. We do allow users to selectively update their systems. But yes, it may be good to inform users when there is updates in any dependencies even if not strictly required by version in the dependency. Regards Henrik -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
coming libnotify bump
I am planning to push libnotify 0.7.0 into rawhide by the end of this week; this is going to be a little painful, since there are some api changes that will require minor adjustment of all users. And there's quite a few of them (see below). I will hopefully be able to handle most of the GNOME dependencies, for the rest I need to ask for some help. Scratch builds of libnotify 0.7.0 rpms can be found here: http://mclasen.fedorapeople.org/libnotify/ Here is an overview of the api changes: notify_notification_new_with_status_icon is gone notify_notification_attach_to_status_icon is gone notify_notification_attach_to_widget is gone notify_notification_set_geometry_hints is gone notify_notification_newhas lost its widget argument A typical patch will look like this one: https://bugzilla.gnome.org/review?bug=632327attachment=172525 For some background on these changes, see http://live.gnome.org/GnomeShell/Design/Guidelines/MessageTray/Compatibility Possibly affected packages: NetworkManager-gnome-1:0.8.1-9.git20100831.fc15.x86_64 abrt-gui-0:1.1.13-2.fc15.x86_64 audacious-plugins-0:2.4.0-6.fc15.x86_64 awn-extras-applets-0:0.4.0-25.fc15.x86_64 balsa-0:2.4.7-2.fc14.x86_64 bognor-regis-0:0.6.11-1.fc15.x86_64 claws-mail-plugins-notification-0:3.7.6-7.fc15.x86_64 compiz-fusion-extras-0:0.8.6-1.fc14.x86_64 deja-dup-0:15.3-2.fc14.x86_64 eekboard-0:0.0.5-3.fc15.x86_64 ekiga-0:3.2.7-4.fc14.x86_64 empathy-0:2.91.0-4.fc15.x86_64 epiphany-1:2.31.5-2.fc15.x86_64 evolution-0:2.91.1-1.fc15.x86_64 evolution-pst-0:2.91.1-1.fc15.x86_64 exo-0:0.3.107-4.fc15.x86_64 florence-0:0.4.6-2.fc14.x86_64 gmpc-0:0.20.0-1.fc15.x86_64 gnome-applet-alarm-clock-0:0.3.1-2.fc15.x86_64 gnome-applet-globalmenu-0:0.7.8-1.fc13.x86_64 gnome-applet-sensors-0:2.2.7-3.fc15.x86_64 gnome-applets-1:2.32.0-2.fc15.x86_64 gnome-bluetooth-1:2.90.0-9.fc15.x86_64 gnome-color-manager-0:2.91.1-4.fc15.x86_64 gnome-disk-utility-0:2.32.0-1.fc15.x86_64 gnome-gmail-notifier-0:0.10.1-1.fc14.x86_64 gnome-packagekit-0:2.91.1-1.fc15.x86_64 gnome-packagekit-extra-0:2.91.1-1.fc15.x86_64 gnome-power-manager-0:2.91.1-1.fc15.x86_64 gnome-screensaver-0:2.30.2-5.fc15.x86_64 gnome-session-0:2.91.0-3.fc15.x86_64 gnome-settings-daemon-0:2.91.0-3.fc15.x86_64 gnome-user-share-0:2.30.1-3.fc15.x86_64 gshutdown-0:0.2-6.fc12.x86_64 gsql-0:0.2.1-4.fc12.x86_64 gwget-0:1.0.4-4.fc14.x86_64 gyachi-plugin-libnotify-0:1.2.10-3.fc14.x86_64 hornsey-0:1.5.2-0.3.fc15.x86_64 imsettings-0:0.108.1-2.fc15.x86_64 ircp-tray-0:0.7.4-1.fc14.x86_64 java-gnome-0:4.0.16-3.fc14.x86_64 krb5-auth-dialog-0:0.16-2.fc15.x86_64 libnotify-0:0.6.0-1.fc15.x86_64 libnotify-devel-0:0.6.0-1.fc15.x86_64 libnotifymm-0:0.6.1-8.fc14.x86_64 liferea-1:1.6.5-1.fc15.x86_64 lxmusic-0:0.4.4-1.fc14.x86_64 mail-notification-0:5.4-25.fc15.x86_64 meego-panel-datetime-0:0.3.2-2.fc15.x86_64 meego-panel-devices-0:0.2.4-4.fc15.x86_64 midori-0:0.2.8-2.fc15.x86_64 midori-0:0.2.9-1.fc15.x86_64 minbar-0:0.2.1-8.fc12.x86_64 nall-0:1.0-3.fc14.x86_64 network-manager-netbook-0:1.7.1-0.1.fc14.x86_64 nntpgrab-gui-0:0.6.90-3.fc15.x86_64 notify-python-0:0.1.1-15.fc15.x86_64 orage-0:4.7.5.16-2.fc15.x86_64 osmo-0:0.2.10-2.fc15.x86_64 padevchooser-0:0.9.4-0.11.svn20070925.fc13.x86_64 parole-0:0.2.0.2-4.fc15.x86_64 pcmanx-gtk2-0:0.3.9-6.20100618svn.fc14.x86_64 perl-Gtk2-Notify-0:0.05-8.fc14.x86_64 pidgin-gfire-0:0.9.2-2.fc15.x86_64 pidgin-libnotify-0:0.14-4.fc14.x86_64 pino-0:0.2.11-1.fc14.x86_64 qbittorrent-1:2.5.0-0.1.beta2.fc15.x86_64 rhythmbox-0:0.13.0-6.fc15.x86_64 rhythmbox-0:0.13.2-1.fc15.x86_64 rhythmbox-lirc-0:0.13.0-6.fc15.x86_64 rhythmbox-lirc-0:0.13.2-1.fc15.x86_64 seahorse-0:2.91.1-1.fc15.x86_64 seahorse-plugins-0:2.30.1-4.fc15.x86_64 setroubleshoot-0:3.0.1-1.fc15.x86_64 setroubleshoot-0:3.0.2-1.fc15.x86_64 setroubleshoot-server-0:3.0.1-1.fc15.x86_64 setroubleshoot-server-0:3.0.2-1.fc15.x86_64 sunbird-0:1.0-0.31.b2pre.fc15.x86_64 sunbird-0:1.0-0.32.b2pre.fc15.x86_64 synce-trayicon-0:0.15-1.fc14.x86_64 syncevolution-1:1.1-1.fc15.x86_64 systemd-gtk-0:11-1.fc15.x86_64 thunderbird-0:3.1.6-1.fc15.x86_64 torium-0:0.4.2-9.fc15.x86_64 transmission-gtk-0:2.11-1.fc15.x86_64 uget-0:1.6.1-1.fc15.x86_64 vino-0:2.32.0-1.fc15.x86_64 xchat-gnome-0:0.26.1-14.fc15.x86_64 xfce4-power-manager-0:0.8.5-1.fc13.x86_64 xfce4-sensors-plugin-0:1.0.0-1.fc14.x86_64 xfce4-settings-0:4.6.5-1.fc14.x86_64 xfce4-volumed-0:0.1.8-1.fc13.x86_64 xneur-0:0.10.0-5.fc15.x86_64 xnoise-plugins-core-0:0.1.6-2.fc14.x86_64 xulrunner-0:2.0-0.2b6.fc15.x86_64 zenity-0:2.32.0-1.fc15.x86_64 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
