[Bug 626765] The latest F14 ocaml-lablgtk has lower NVR than F13
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=626765 --- Comment #2 from Adam Tkac at...@redhat.com 2010-08-24 07:50:25 EDT --- Thanks for info. Are you going to fix this issue and release update for F14, please, or should I do it myself? -- 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. ___ ocaml-devel mailing list ocaml-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/ocaml-devel
[Bug 589261] amending values of log_to_syslog = true; log_file = /dev/null in config causes nothing, values get reverted
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=589261 Fedora Update System upda...@fedoraproject.org changed: What|Removed |Added Fixed In Version|mldonkey-3.0.3-1.fc12 |mldonkey-3.0.3-1.fc14 -- 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. ___ ocaml-devel mailing list ocaml-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/ocaml-devel
[Bug 616128] .desktop menu entry has wrong/missing categories
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=616128 --- Comment #11 from Fedora Update System upda...@fedoraproject.org 2010-08-24 21:21:57 EDT --- mldonkey-3.0.3-1.fc14 has been pushed to the Fedora 14 stable repository. If problems still persist, please make note of it in this bug report. -- 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. ___ ocaml-devel mailing list ocaml-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/ocaml-devel
New fedpkg build coming to an update repo near you!
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
I just submitted updates for el5 and f1{2,3,4} as well as a build for
rawhide (f15) of a new fedpkg build. Here is a summary from the rpm:
- - Error check the update call. #625679
- - Use the correct remote when listing revs
- - Add the bash completion file
- - re-fix dist defines.
- - Short cut the failure on repeated builds
- - Allow passing srpms to the build command
- - clone: set repo's push.default to tracking
- - pull the username from fedora_cert to pass to bodhi
- - Catch double ^c's from build. RHBZ #620465
- - Fix up chain building
- - Add missing process call for non-pipe no tty.
In addition I've fixed chain building (#624419) and applied a patch to
read bodhi user names from your fedora cert (#625326).
https://admin.fedoraproject.org/updates/fedora-packager-0.5.1.3-1.fc14
https://admin.fedoraproject.org/updates/fedora-packager-0.5.1.3-1.fc13
https://admin.fedoraproject.org/updates/fedora-packager-0.5.1.3-1.fc12
https://admin.fedoraproject.org/updates/fedora-packager-0.5.1.3-1.el5
Those are the bodhi links. Testing + karma would be appreciated!
- --
Jesse Keating
Fedora -- Freedom² is a feature!
identi.ca: http://identi.ca/jkeating
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAkxzak0ACgkQ4v2HLvE71NWpBQCffRSj4FNetaaRZcAia/AcAE7b
g60AniWFioOGfqZjwAwclie3Zx6YPOkP
=lwp2
-END PGP SIGNATURE-
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
[Test-Announce] Bugzappers meeting slot 2010-08-24
Hi, folks. There's a meeting slot tomorrow at the usual time, 2010-08-24 15:00 UTC. There's nothing new on the agenda page - https://fedoraproject.org/wiki/BugZappers:meeting-agenda-list - and I can't think of any particularly pressing topics, so we may not need to have a meeting. I'll be around in the morning, though, just in case. If anyone would like to discuss something specific, please do reply to this email and we'll run the meeting as usual. Thanks! -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org http://www.happyassassin.net ___ 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: [ACTION REQUIRED, v2] orphaned packages in F-14
Hi, On 08/20/2010 10:25 PM, Bill Nottingham wrote: The attached list shows currently orphaned packages in F-14. If they are not claimed by the end of next week, they will be blocked, potentially breaking dependencies (and causing more things to be blocked...) If you already co-maintain the package, please step up and take it. (If you don't, it may be assigned to you anyway.) Otherwise, volunteers would be appreciated for those packages that other things require. Bill I've taken dom4j and requested c-maintainership for libsigc++, as these both are deps for packages I own. Regards, Hans Orphan JSDoc Orphan bzr-gtk comaintained by: shahms Orphan cdf Orphan classworlds comaintained by: dbhole Orphan crun Orphan django-authopenid Orphan dom4j comaintained by: dbhole Orphan drgeo Orphan drgeo-doc Orphan drpython Orphan dtdparser comaintained by: dbhole Orphan fet comaintained by: fab Orphan fish comaintained by: oliver Orphan gg2 Orphan gnome-vfsmm26 Orphan gnomecatalog Orphan gperiodic Orphan hsqldb comaintained by: fnasser Orphan impressive Orphan isorelax Orphan jlex Orphan jrefactory Orphan jzlib Orphan kasablanca comaintained by: tuxbrewr rdieter Orphan kflickr Orphan ldapjdk Orphan libgnomecanvasmm26 Orphan libgnomemm26 Orphan libgnomeuimm26 Orphan libmspack Orphan libpanelappletmm Orphan libsigc++ Orphan lucene Orphan mapbender Orphan mapserver comaintained by: devrim oliver Orphan mediawiki-HNP Orphan mediawiki-StubManager Orphan minirpc Orphan nettle Orphan nodm Orphan objectweb-anttask Orphan ogdi Orphan pAgenda Orphan papercut Orphan pastebin Orphan php-channel-phpdb Orphan php-pear-Phlickr Orphan php-pear-creole Orphan php-pear-pake Orphan php-pear-propel_generator Orphan php-pear-propel_runtime Orphan pitivi Orphan plexus-ant-factory Orphan plexus-appserver Orphan plexus-bsh-factory Orphan plexus-compiler Orphan plexus-runtime-builder Orphan plexus-xmlrpc comaintained by: fnasser Orphan poker-engine Orphan poker-eval Orphan poker-network Orphan poker2d Orphan poker3d Orphan poker3d-data Orphan pycairo Orphan pyfacebook Orphan pyorbit Orphan pypoker-eval Orphan python-numarray Orphan python-urllib2_kerberos Orphan python-zc-lockfile comaintained by: cheeselee Orphan python-zdaemon comaintained by: cheeselee Orphan python-zope-event comaintained by: cheeselee Orphan python-zope-testing comaintained by: cheeselee Orphan qosmic Orphan relaxngDatatype comaintained by: dbhole Orphan ruby-activerecord Orphan spambayes Orphan stardict-dic-en comaintained by: kaio Orphan stardict-dic-ja comaintained by: kaio Orphan stardict-dic-ru comaintained by: kaio Orphan stardict-dic-zh_CN comaintained by: kaio Orphan stardict-dic-zh_TW comaintained by: kaio Orphan taipeifonts comaintained by: kaio Orphan tanukiwrapper comaintained by: devrim Orphan tinyows Orphan tomcat6 comaintained by: dwalluck akurtakov dknox Orphan tpb Orphan tremfusion Orphan twitux Orphan vgabios Orphan windowlab Orphan ws-jaxme comaintained by: dbhole Orphan x2vnc Orphan xenwatch Orphan xjavadoc Orphan xmldb-api comaintained by: dbhole Orphan xmlrpc comaintained by: devrim Orphan xom comaintained by: dbhole Orphan xpp2 comaintained by: dbhole Orphan xpp3 comaintained by: dbhole Orphan xwnc List of deps left behind by orphan removal: Orphan: classworlds intellij-idea requires classworlds = 1.1-4.fc12 maven-doxia requires classworlds = 1.1-4.fc12 maven-doxia-sitetools requires classworlds = 1.1-4.fc12 maven-surefire requires classworlds = 1.1-4.fc12 maven-wagon requires classworlds = 1.1-4.fc12 maven2 requires classworlds = 1.1-4.fc12 mercury requires classworlds = 1.1-4.fc12 modello requires classworlds = 1.1-4.fc12 plexus-ant-factory requires classworlds = 1.1-4.fc12 plexus-appserver requires classworlds = 1.1-4.fc12 plexus-archiver requires classworlds = 1.1-4.fc12 plexus-bsh-factory requires classworlds = 1.1-4.fc12 plexus-compiler requires classworlds = 1.1-4.fc12 plexus-container-default requires classworlds = 1.1-4.fc12 plexus-i18n requires classworlds = 1.1-4.fc12 plexus-resources requires classworlds = 1.1-4.fc12 plexus-velocity requires classworlds = 1.1-4.fc12 plexus-xmlrpc requires classworlds = 1.1-4.fc12 Orphan: dom4j bolzplatz2006 requires dom4j = 1.6.1-5.fc12 eclipse-checkstyle requires dom4j = 1.6.1-5.fc12 freemarker requires dom4j = 1.6.1-5.fc12 itext requires dom4j = 1.6.1-5.fc12 itext-rups requires dom4j = 1.6.1-5.fc12 jaxen requires dom4j = 1.6.1-5.fc12 json-lib requires dom4j = 1.6.1-5.fc12 logback requires dom4j = 1.6.1-5.fc12
Re: systemd and changes
On Mon, 23 Aug 2010 16:17:21 -0400, Matthew wrote: Was there a conversation other than this FESCO meeting? http://meetbot.fedoraproject.org/fedora-meeting/2010-06-15/fesco.2010-06-15-19.35.log.html#l-446 There, I see this discussion: 20:51:41 mezcalero so, i would like to keep the options open, but i'd like to see the testing for the case systemd as default [...] I'm not sure if you actually read this before or participated directly in the discussion, but [...] mezcalero is Lennart himself. Or more precisely, one of his user names. [Doesn't make it impossible for somebody else to enter IRC with that name (and perhaps register that one even if not occupied already), but well, that's beyond the scope of this reply.] -- Fedora release 14 (Laughlin) - Linux 2.6.35.2-9.fc14.x86_64 loadavg: 0.38 0.29 0.28 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: systemd acceptance, packaging guidelines (was Re: systemd and changes)
On 08/23/2010 11:06 PM, Bill Nottingham wrote: (intentionally breaking thread) Toshio Kuratomi (a.bad...@gmail.com) said: Maybe I should start a new thread since this isn't really a bug, but it is a blocker -- we need to get some packaging guidelines out for systemd. I think that the last message on the subject was this one: http://lists.fedoraproject.org/pipermail/devel/2010-July/139483.html Could I get a reply as to whether that looks right? - At the moment, /bin/systemctl is in systemd-units. (I think this is a bug. Filed.) - As long as we're still shipping upstart, the sysv scripts would still need included, and would still need to be set up with chkconfig the same way. As noted in the post, I'm not sure if the outlined procedure correctly implements level 1. I believe it does. We should probably also have the scriptlets for implementing level 3 for the things basic to the system that require that. My reading of your mail is different - the case we want to handle is case #2 (installation of something that starts by default - dbus, NM, etc.) As I understand it, they would be the same, with the addition of: %post if [ 0$1 -eq ]; then /bin/systemctl enablefoo.service fi with foo.service having the appropriate [Install] stanza that says where it should start up. As with SysV scripts, we generally do not start services by default, so this is rare. Case #3 that you mentioned is something I don't think we have in Fedora - we never start services on package installation. This, however, is just packaging guidelines. From readng the thread, there are many things that I think people would like covered with systemd before they would feel comfortable with it. So, I'm going to attempt to quantify what would need to be tested and verified. This document focuses on backwards compatibility. THIS IS GOING TO BE VERY VERBOSE. Comments, changes, etc. welcome. BOOTUP - System boots successfully to GUI, when configured. - System boots successfully to text mode, when configured. - System properly handles being passed [1-5], 'single', 'S', 's', '-s', booting to the appropriate 'runlevel' (0 and 6 can still work, but they're sort of pointless anyway) When booted in this manner, '5' will bring up a GUI, and '3' will not. SINGLE USER MODE - Exiting single user mode properly returns to the default state. - single-user mode output is correctly displayed on the console. File /etc/inittab should keep working at the same level it is now. Jeff -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora Notifications System.
On Friday, August 20, 2010 10:46:43 pm Mahmoud Abdul Jawad wrote: Hi all,, Hi! before two weeks, a discussion started in ambassadors mailing-list about a work around to deliver the important notifications to the fedora desktop (whatever the desktop is). after some discussion, we started with some guide lines putted them on the wiki: https://fedoraproject.org/wiki/Fedora_notifications_system Reading this - I'm not sure all Fedora notifications should go through system notification system. Why? I understand it for urgent/priority notification like Close your desktop, nuclear war out there (or just a security update combined with some steps how to fix it). But I hope it should work for a lot of things like Fedora elections etc. - this should for example go to your calendar, some tips how to use Fedora (just a RSS feed like Plasma widget?) etc. Jaroslav Continuing, I created an early prototype i want people to check gives feedbacks about it. you can reach it through gitweb: http://fedorapeople.org/gitweb?p=megenius/public_git/fns.git;a=summary or, you can grab your own clone from the git repo: git://fedorapeople.org/megenius/fns.git keep in mind that last_check file should be writeable by the world, you should change its value to an earlier date, so you can see some notifications. -- Jaroslav Řezník jrez...@redhat.com Software Engineer - Base Operating Systems Brno Office: +420 532 294 275 Mobile: +420 602 797 774 Red Hat, Inc. http://cz.redhat.com/ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: yum appmarket
On Saturday, August 21, 2010 02:25:08 am Jeff Spaleta wrote: On Fri, Aug 20, 2010 at 10:52 AM, Adam Williamson awill...@redhat.com wrote: That would likely be a bad idea. Mandriva did something similar a few years back, before I left, and it was pretty unpopular and often confusing for users. I lost count of the number of times I explained how to change the default filter back to 'all packages'... Perhaps...there's a reason to have two complete different UIs instead of having a UI be configured for either/or. Give me the equivalent of a Newark Electronics snailmail parts catalogue as a developer/contributor. And give end-users something that makes sense for them to find applications...and make them very obviously different things. +1 -jef -- Jaroslav Řezník jrez...@redhat.com Software Engineer - Base Operating Systems Brno Office: +420 532 294 275 Mobile: +420 602 797 774 Red Hat, Inc. http://cz.redhat.com/ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: drop default MTA for Fedora 15
my desktop runs on software mirror raid below an lvm. not for performance but for data recovery reasons. mdmonitor does mail notification. will this be fixed? how about logwatch, it is really useful to have to get an overview what happened on the system in a neat summary. also handy for desktops but just not recognized and presented in an end user compatible way. just my opinion. kind regards, Rudolf Kastl -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: drop default MTA for Fedora 15
On Tue, Aug 24, 2010 at 9:36 AM, Rudolf Kastl che...@gmail.com wrote: my desktop runs on software mirror raid below an lvm. not for performance but for data recovery reasons. mdmonitor does mail notification. will this be fixed? how about logwatch, it is really useful to have to get an overview what happened on the system in a neat summary. also handy for desktops but just not recognized and presented in an end user compatible way. just my opinion. Neither of those need to run a MTA locally to work, you just need to point them to a mail server, even then they need to be configured to send the mail to something other than root anyway. Removing the default MTA won't change these out of the box and if you still want to run a local MTA its as simple as selecting it during install. I use all of the above on dozens of servers and none of them run a mail server locally. Peter -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: systemd acceptance, packaging guidelines (was Re: systemd and changes)
2010/8/24 Miroslav Lichvar mlich...@redhat.com: On Mon, Aug 23, 2010 at 11:06:32PM -0400, Bill Nottingham wrote: SERVICE HANDLING - Running 'chkconfig foo (null)|on|off' on a service managed by systemd will return the correct code/perform an appropriate action. Also, if chkconfig --add called systemctl enable when the sysv script is enabled, most of the current scriptlets probably wouldn't need any changes. The status of systemd and sysv services would be required to stay in sync though. keeping compatibility to chkconfig is in my opinion a key requirement to really find acceptance as a replacement. kind regards, Rudolf Kastl -- Miroslav Lichvar -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: New fedpkg build coming to an update repo near you!
Thanks, but I have following problem: $ fedpkg co -B xterm Cloning into bare repository /home/yarda/git-fedora/xterm/fedpkg.git... remote: Counting objects: 657, done. remote: Compressing objects: 100% (333/333), done. remote: Total 657 (delta 274), reused 657 (delta 274) Receiving objects: 100% (657/657), 81.09 KiB | 81 KiB/s, done. Resolving deltas: 100% (274/274), done. Traceback (most recent call last): File /usr/bin/fedpkg, line 1086, in module args.command(args) File /usr/bin/fedpkg, line 425, in clone pyfedpkg.clone_with_dirs(args.module[0], args.user) File /usr/lib/python2.6/site-packages/pyfedpkg/__init__.py, line 413, in clone_with_dirs clone(module, user, top_path, bare_dir=repo_path) File /usr/lib/python2.6/site-packages/pyfedpkg/__init__.py, line 385, in clone repo = git.Repo(module) The fedpkg-0.5.1.2-2.fc13 is working fine: $ fedpkg co -B xterm Cloning into bare repository /home/yarda/git-fedora/NetworkManager/xterm/fedpkg.git... remote: Counting objects: 657, done. remote: Compressing objects: 100% (333/333), done. remote: Total 657 (delta 274), reused 657 (delta 274) Receiving objects: 100% (657/657), 81.09 KiB | 85 KiB/s, done. Resolving deltas: 100% (274/274), done. Bug? Or my wrong setup/use case? Thanks Jaroslav -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: WebKit(s) SIG
On Friday, August 06, 2010 04:45:39 pm Jaroslav Reznik wrote: Just an update: we hava our own WebKit SIG mailing list [1]. Feel free to subscribe. [1] https://admin.fedoraproject.org/mailman/listinfo/webkit Thanks Jaroslav -- Jaroslav Řezník jrez...@redhat.com Software Engineer - Base Operating Systems Brno Office: +420 532 294 275 Mobile: +420 602 797 774 Red Hat, Inc. http://cz.redhat.com/ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
rawhide report: 20100824 changes
Compose started at Tue Aug 24 08:15:26 UTC 2010 Broken deps for x86_64 -- OpenSceneGraph-libs-2.8.3-2.fc14.i686 requires libpoppler.so.6 OpenSceneGraph-libs-2.8.3-2.fc14.x86_64 requires libpoppler.so.6()(64bit) PragmARC-20060427-6.fc13.i686 requires libgnarl-4.4.so PragmARC-20060427-6.fc13.i686 requires libgnat-4.4.so PragmARC-20060427-6.fc13.x86_64 requires libgnarl-4.4.so()(64bit) PragmARC-20060427-6.fc13.x86_64 requires libgnat-4.4.so()(64bit) RackTables-0.18.3-1.fc15.noarch requires /usr/local/bin/php RackTables-0.18.3-1.fc15.noarch requires perl(File::FnMatch) RackTables-0.18.3-1.fc15.noarch requires perl(Net::Telnet::Cisco) antlr3-python-3.1.2-7.fc14.noarch requires python(abi) = 0:2.6 cairo-java-1.0.5-12.fc12.i686 requires libgcj.so.10 cairo-java-1.0.5-12.fc12.x86_64 requires libgcj.so.10()(64bit) cinepaint-0.22.1-17.fc14.x86_64 requires liboyranos.so.0.1.9()(64bit) cinepaint-libs-0.22.1-17.fc14.i686 requires liboyranos.so.0.1.9 cinepaint-libs-0.22.1-17.fc14.x86_64 requires liboyranos.so.0.1.9()(64bit) cyphesis-0.5.21-2.fc13.x86_64 requires libpython2.6.so.1.0()(64bit) dpm-python3-1.7.4.7-3.fc14.x86_64 requires python(abi) = 0:3.1 dpm-python3-1.7.4.7-3.fc14.x86_64 requires libpython3.1.so.1.0()(64bit) emerillon-0.1.2-7.fc14.x86_64 requires librest-0.6.so.0()(64bit) evolution-couchdb-0.4.92-1.fc14.x86_64 requires libedata-book-1.2.so.2()(64bit) evolution-couchdb-0.4.92-1.fc14.x86_64 requires libcamel-1.2.so.17()(64bit) evolution-couchdb-0.4.92-1.fc14.x86_64 requires libgtkhtml-editor.so.0()(64bit) evolution-couchdb-0.4.92-1.fc14.x86_64 requires libebook-1.2.so.9()(64bit) evolution-couchdb-0.4.92-1.fc14.x86_64 requires libcamel-provider-1.2.so.17()(64bit) evolution-sharp-0.21.1-7.fc14.x86_64 requires libebook-1.2.so.9()(64bit) evolution-sharp-0.21.1-7.fc14.x86_64 requires libecal-1.2.so.7()(64bit) fmt-ptrn-java-1.3.20-5.fc13.i686 requires libgcj.so.10 fmt-ptrn-java-1.3.20-5.fc13.x86_64 requires libgcj.so.10()(64bit) frysk-0.4-26.fc14.x86_64 requires libgcj.so.10()(64bit) frysk-devel-0.4-26.fc14.i386 requires libgcj.so.10 frysk-devel-0.4-26.fc14.x86_64 requires libgcj.so.10()(64bit) frysk-gnome-0.4-26.fc14.x86_64 requires libgcj.so.10()(64bit) gedit-vala-0.6.1-1.fc13.x86_64 requires libvala.so.0()(64bit) gloobus-preview-0.4.1-6.fc14.x86_64 requires libpoppler.so.6()(64bit) 3:gnome-commander-1.2.8.7-1.fc14.x86_64 requires libpoppler.so.6()(64bit) gpx-viewer-0.1.2-2.fc14.x86_64 requires libchamplain-gtk-0.4.so.0()(64bit) gpx-viewer-0.1.2-2.fc14.x86_64 requires libchamplain-0.4.so.0()(64bit) inkscape-0.48-0.4.20100505bzr.fc14.x86_64 requires libpoppler.so.6()(64bit) inkscape-view-0.48-0.4.20100505bzr.fc14.x86_64 requires libpoppler.so.6()(64bit) intellij-idea-9.0.1.94.399-11.fc14.x86_64 requires jna-examples lfc-python3-1.7.4.7-3.fc14.x86_64 requires libpython3.1.so.1.0()(64bit) lfc-python3-1.7.4.7-3.fc14.x86_64 requires python(abi) = 0:3.1 libextractor-plugins-pdf-0.6.1-1402.fc14.x86_64 requires libpoppler.so.6()(64bit) libgconf-java-2.12.4-14.fc12.i686 requires libgcj.so.10 libgconf-java-2.12.4-14.fc12.x86_64 requires libgcj.so.10()(64bit) libglade-java-2.12.5-12.fc12.i686 requires libgcj.so.10 libglade-java-2.12.5-12.fc12.x86_64 requires libgcj.so.10()(64bit) libgnome-java-2.12.4-12.fc12.i686 requires libgcj.so.10 libgnome-java-2.12.4-12.fc12.x86_64 requires libgcj.so.10()(64bit) libgtk-java-2.8.7-13.fc13.i686 requires libgcj.so.10 libgtk-java-2.8.7-13.fc13.x86_64 requires libgcj.so.10()(64bit) libopenvrml-0.18.6-1.fc14.i686 requires libboost_filesystem-mt.so.1.41.0 libopenvrml-0.18.6-1.fc14.i686 requires libboost_thread-mt.so.1.41.0 libopenvrml-0.18.6-1.fc14.x86_64 requires libboost_thread-mt.so.1.41.0()(64bit) libopenvrml-0.18.6-1.fc14.x86_64 requires libboost_filesystem-mt.so.1.41.0()(64bit) libopenvrml-gl-0.18.6-1.fc14.i686 requires libboost_filesystem-mt.so.1.41.0 libopenvrml-gl-0.18.6-1.fc14.i686 requires libboost_thread-mt.so.1.41.0 libopenvrml-gl-0.18.6-1.fc14.x86_64 requires libboost_thread-mt.so.1.41.0()(64bit) libopenvrml-gl-0.18.6-1.fc14.x86_64 requires libboost_filesystem-mt.so.1.41.0()(64bit) libselinux-python3-2.0.96-3.fc14.x86_64 requires python(abi) = 0:3.1 libsemanage-python3-2.0.45-5.fc14.x86_64 requires libpython3.1.so.1.0()(64bit) libsemanage-python3-2.0.45-5.fc14.x86_64 requires python(abi) = 0:3.1 libvte-java-0.12.1-15.fc12.i686 requires libgcj.so.10 libvte-java-0.12.1-15.fc12.x86_64 requires
Re: drop default MTA for Fedora 15
On 08/23/2010 08:15 PM, Jon Masters wrote: On Sun, 2010-08-22 at 20:10 +0200, drago01 wrote: On Sun, Aug 22, 2010 at 7:45 PM, Rex Dieter rdie...@math.unl.edu wrote: pbrobin...@gmail.com wrote: I know its been discussed in the past but there's been reasons not to drop a default MTA but now that cronie (the last actual dependency) has support for logging to system logs is there any reason to include an MTA by default for F-14? A bit late to consider for F-14 imo (I'd argue something like should in place and testable by or near feature freeze), F-15 is doable. Test what? That no MTA is present? I'd say we should stop arguing forever and just do it. What's the benefit of having no default MTA at all? Is it that Desktop users don't care about MTAs being installed? what about those of us who care more about server installations than Desktop? Even the web page proposing its deletion acknowledges that The presence of a Mail Transfer Agent (MTA) like sendmail has long been the de facto standard. Indeed it has: the ability to send mail from a program has been an entitlement for as long as UNIX has been around. In comparison with this, the benefit is very feeble: One less required package in the critical path, and we clear the way for removing the MTA from the default install. Andrew. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: drop default MTA for Fedora 15
On Tue, Aug 24, 2010 at 12:43 PM, Andrew Haley a...@redhat.com wrote: On 08/23/2010 08:15 PM, Jon Masters wrote: On Sun, 2010-08-22 at 20:10 +0200, drago01 wrote: On Sun, Aug 22, 2010 at 7:45 PM, Rex Dieter rdie...@math.unl.edu wrote: pbrobin...@gmail.com wrote: I know its been discussed in the past but there's been reasons not to drop a default MTA but now that cronie (the last actual dependency) has support for logging to system logs is there any reason to include an MTA by default for F-14? A bit late to consider for F-14 imo (I'd argue something like should in place and testable by or near feature freeze), F-15 is doable. Test what? That no MTA is present? I'd say we should stop arguing forever and just do it. What's the benefit of having no default MTA at all? Is it that Desktop users don't care about MTAs being installed? what about those of us who care more about server installations than Desktop? Even the web page proposing its deletion acknowledges that The presence of a Mail Transfer Agent (MTA) like sendmail has long been the de facto standard. Indeed it has: the ability to send mail from a program has been an entitlement for as long as UNIX has been around. In comparison with this, the benefit is very feeble: One less required package in the critical path, and we clear the way for removing the MTA from the default install. Removing it doesn't stop applications in unix from sending mail! Peter -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: drop default MTA for Fedora 15
On 08/24/2010 12:47 PM, pbrobin...@gmail.com wrote: On Tue, Aug 24, 2010 at 12:43 PM, Andrew Haley a...@redhat.com wrote: On 08/23/2010 08:15 PM, Jon Masters wrote: On Sun, 2010-08-22 at 20:10 +0200, drago01 wrote: On Sun, Aug 22, 2010 at 7:45 PM, Rex Dieter rdie...@math.unl.edu wrote: pbrobin...@gmail.com wrote: I know its been discussed in the past but there's been reasons not to drop a default MTA but now that cronie (the last actual dependency) has support for logging to system logs is there any reason to include an MTA by default for F-14? A bit late to consider for F-14 imo (I'd argue something like should in place and testable by or near feature freeze), F-15 is doable. Test what? That no MTA is present? I'd say we should stop arguing forever and just do it. What's the benefit of having no default MTA at all? Is it that Desktop users don't care about MTAs being installed? what about those of us who care more about server installations than Desktop? Even the web page proposing its deletion acknowledges that The presence of a Mail Transfer Agent (MTA) like sendmail has long been the de facto standard. Indeed it has: the ability to send mail from a program has been an entitlement for as long as UNIX has been around. In comparison with this, the benefit is very feeble: One less required package in the critical path, and we clear the way for removing the MTA from the default install. Removing it doesn't stop applications in unix from sending mail! Yes, it does, unless you happen to have configured your machine to be able to send mail externally. And also, you can't guarantee that every user ID on a machine corresponds to an email address that is globally reachable. I suspect that, in general, they aren't. Andrew. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Wrong packages in F14/rawhide composes
Hello, it seems there are some issues with recent mass rebuilds for perl 5.12.0 in F14/rawhide. Some packages were rebuilt against new perl and then were built again. However koji exposes only the older build. This is list of affected packages which I discovered during work on FES ticket https://fedorahosted.org/fedora-engineering-services/ticket/35: nagios, perl-DBD-SQLite, perl-HTTP-DAV, perl-Net-STOMP-Client, perl-PAR and perl-PAR-Packer. For example when I visit koji via https://kojiweb.fedoraproject.org/koji web interface and search for example for nagios package, then I can see there is nagios-3.2.1-5.fc14 package with dist-f14 tag. However when I run $ koji latest-pkg dist-f14 nagios I get: Build Tag Built by nagios-3.2.1-4.fc14 dist-f14 mmaslano This is really odd, what would be the best way to fix this issue? Rebuild of affected packages? Regards, Adam -- Adam Tkac, Red Hat, Inc. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: systemd acceptance, packaging guidelines (was Re: systemd and changes)
On Mon, 2010-08-23 at 23:06 -0400, Bill Nottingham wrote: Hey Bill, this is a very good initial list, this should make it very easy for QA to whip up a test plan for systemd. Some comments below. BOOTUP - System boots successfully to GUI, when configured. - System boots successfully to text mode, when configured. - System properly handles being passed [1-5], 'single', 'S', 's', '-s', booting to the appropriate 'runlevel' (0 and 6 can still work, but they're sort of pointless anyway) When booted in this manner, '5' will bring up a GUI, and '3' will not. You mean 'being passed on the kernel cmdline', I assume ? Do we consider interactive boot essential (I think not) ? Should mention something about forced fsck, maybe. What about selinux relabeling ? SINGLE USER MODE - Exiting single user mode properly returns to the default state. - single-user mode output is correctly displayed on the console. PLYMOUTH - plymouth is shown on startup. - plymouth is quit correctly. - plymouth is shown on shutdown. - 'esc' to show details still functions in plymouth. - an equivalent to /var/log/boot.log still exists, and is populated (can be normal syslog) - plymouth transition from grub - boot - X is seamless for KMS cards, similar to Fedora 13. Note that this is currently broken (somewhere in X, not systemd's fault at all). RUNTIME TOOLS - telinit [0123456] does the proper thing. - the 'runlevel' command displays correct output if we are in a target that is aliased to a runlevel. - 'halt' shuts down, but does not poweroff. -- 'halt' supports -p, to power off. - 'poweroff' shuts down, and powers off. - 'reboot' shuts down and reboots. - 'halt', 'poweroff', 'reboot' all support '-f', to force the action. - 'halt', 'poweroff', 'reboot' all properly log to utmp, wtmp, and the audit layer. - 'shutdown' shall support the following arguments in a compatible manner: 'r', 'h', 'H', 'P', 'c', 'k', time. - 'telinit' does not error when passed '[Qq]' (to reload its configuration) and '[Uu]' to re-exec itself. It can optionally make systemd do a similar action, if valid. - init shall support a mechanism to re-exec itself to not cause dirty inodes on shutdown; initscripts will use this method on shutdown. - the kbdrequest job currently in systemd will be disabled for final release. - 'ctrl-alt-delete' will reboot the system. Should include chkconfig here, probably ? PREFDM - prefdm starts a configured display manager correctly. - prefdm starts a installed display manager correctly without additional configuration. CONSOLEKIT - ConsoleKit properly logs system start, stop, and restart. - The ConsoleKit shutdown/reboot/halt methods work as expected. SERIAL CONSOLES - Booting with a primary serial console (via console=) automatically sets up a getty on the console, and sets up securetty to allow for root login. - (optional) Booting with secondary serial consoles does the same. NON-SERIAL CONSOLES - By default, 6 gettys will be started in text mode, on tty1-6. 5 gettys will be started in GUI mode, on tty2-6. - getty and X will not be started on the same tty. - (optional) The number of ttys started can be configurable. ERROR HANDLING - SELinux automatic relabelling will still function. - fsck will still function. - Dropping to an emergency shell in the case where either of these fails shall still function. SELINUX - No AVCs from the init system in normal use. - No AVCs when executing any of the cases specified here - systemd shall still function if booted with selinux=0. PACKAGING - Guidelines for packaging systemd units shall be formalized. - The behavior when both systemd units and SysV services are present on the system shall be defined. This includes defined behavior when a service appears to be 'enabled' for SysV links while 'disabled' for systemd (and vice-versa). - The syntax of systemd units shall be frozen for the release (all future releases? Some set number of releases?) Can you clarify this a bit ? I assume what we want is that future systemd releases remain backwards compatible with systemd units of today. SERVICE HANDLING - Running 'chkconfig foo (null)|on|off' on a service managed by systemd will return the correct code/perform an appropriate action. - Running 'service foo start|stop|...' on a service managed by systemd will perform the appropriate action (via systemctl), and return similar errors. - Running '/etc/init.d/foo start|stop|...' will not break the systemd environment, while still performing the action specified, and shall return similar errors. GENERAL SANITY - Booting a system shall achieve a similar result as booting in upstart: -- The same set of services will be started. I don't think this is a requirement on systemd, really. If we make changes to the default system configuration to not include a service in F14 that was included in F13, that is not a
Re: Wrong packages in F14/rawhide composes
On 24/08/10 13:45, Adam Tkac wrote:
Hello,
it seems there are some issues with recent mass rebuilds for perl
5.12.0 in F14/rawhide.
Some packages were rebuilt against new perl and then were built again.
However koji exposes only the older build.
This is list of affected packages which I discovered during work on
FES ticket https://fedorahosted.org/fedora-engineering-services/ticket/35:
nagios, perl-DBD-SQLite, perl-HTTP-DAV, perl-Net-STOMP-Client,
perl-PAR and perl-PAR-Packer.
For example when I visit koji via https://kojiweb.fedoraproject.org/koji
web interface and search for example for nagios package, then I can
see there is nagios-3.2.1-5.fc14 package with dist-f14 tag. However
when I run $ koji latest-pkg dist-f14 nagios I get:
Build Tag Built by
nagios-3.2.1-4.fc14 dist-f14 mmaslano
This is really odd, what would be the best way to fix this issue?
Rebuild of affected packages?
Yes, because the newer builds have probably been built against the
older perl.
Paul.
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Git question
Hello, How I merge the latests changes from the remotes/origin/f13/master on to my f13/user/steved/pnfs-13 remote branch? Also, the kernel that is currently being built from my pnfs-13 branch fails to install with the following error: FATAL: Could not load /lib/modules/2.6.34.5-43.pnfs_all_2.6.35_2010_08_19.fc13.x86_64-pnfs/modules.dep: No such file or directory The extra -pnfs on the 2.6.34.5-43... directory name is the problem. It probably has something to do with how I changed the buildid: --- a/kernel.spec +++ b/kernel.spec @@ -23,7 +23,7 @@ Summary: The Linux kernel # # (Uncomment the '#' and both spaces below to set the buildid.) # -# % define buildid .local +%define buildid .pnfs_all_2.6.35_2010_08_19 ### Any insight on this would definitely be appreciated... tia, steved. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Wrong packages in F14/rawhide composes
On Tue, Aug 24, 2010 at 01:54:25PM +0100, Paul Howarth wrote:
On 24/08/10 13:45, Adam Tkac wrote:
Hello,
it seems there are some issues with recent mass rebuilds for perl
5.12.0 in F14/rawhide.
Some packages were rebuilt against new perl and then were built again.
However koji exposes only the older build.
This is list of affected packages which I discovered during work on
FES ticket https://fedorahosted.org/fedora-engineering-services/ticket/35:
nagios, perl-DBD-SQLite, perl-HTTP-DAV, perl-Net-STOMP-Client,
perl-PAR and perl-PAR-Packer.
For example when I visit koji via https://kojiweb.fedoraproject.org/koji
web interface and search for example for nagios package, then I can
see there is nagios-3.2.1-5.fc14 package with dist-f14 tag. However
when I run $ koji latest-pkg dist-f14 nagios I get:
Build Tag Built by
nagios-3.2.1-4.fc14 dist-f14 mmaslano
This is really odd, what would be the best way to fix this issue?
Rebuild of affected packages?
Yes, because the newer builds have probably been built against the
older perl.
Right you are, thanks for the pointing out the root cause. I will
rebuild discussed packages.
Regards, Adam
--
Adam Tkac, Red Hat, Inc.
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Git question
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 08/24/2010 08:55 AM, Steve Dickson wrote: Hello, How I merge the latests changes from the remotes/origin/f13/master on to my f13/user/steved/pnfs-13 remote branch? The easiest way would be to switch to the pnfs-13 branch and then do: git rebase origin/f13/master This will apply any patches atop the branch point of your branch, then attempt to apply your branch's patches atop those (stopping if there are merge conflicts that need to be resolved) - -- Stephen Gallagher RHCE 804006346421761 Delivering value year after year. Red Hat ranks #1 in value among software vendors. http://www.redhat.com/promo/vendor/ -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/ iEYEARECAAYFAkxzxhIACgkQeiVVYja6o6PDxgCcCDEsLaBVMYZ22ttrEld2erEv BaMAn2sofQZ8JeRLixt/5BwDx66ZLIz/ =R6JC -END PGP SIGNATURE- -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Git question
Am 24.08.10 14:55, schrieb Steve Dickson: How I merge the latests changes from the remotes/origin/f13/master on to my f13/user/steved/pnfs-13 remote branch? I think git cherry-pick is the command whar you want to use. With git cherry-pck you can apply the changes of a commit from an other branch on to of the current branch where you are. Best Regards: Jochen Schmitt -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Git question
On Tue, Aug 24, 2010 at 4:21 PM, Jochen Schmitt joc...@herr-schmitt.de wrote: Am 24.08.10 14:55, schrieb Steve Dickson: How I merge the latests changes from the remotes/origin/f13/master on to my f13/user/steved/pnfs-13 remote branch? I think git cherry-pick is the command whar you want to use. cherry-pick is useful when you take patches from one _custom_ branch to another. I case of master branch the rebase is more convenient, I think. -- With Best Regards, Andy Shevchenko -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Git question
On 08/24/2010 09:16 AM, Stephen Gallagher wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 08/24/2010 08:55 AM, Steve Dickson wrote: Hello, How I merge the latests changes from the remotes/origin/f13/master on to my f13/user/steved/pnfs-13 remote branch? The easiest way would be to switch to the pnfs-13 branch and then do: git rebase origin/f13/master This will apply any patches atop the branch point of your branch, then attempt to apply your branch's patches atop those (stopping if there are merge conflicts that need to be resolved) Very good... thank you!! steved. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Git question
On 08/24/2010 09:27 AM, Andy Shevchenko wrote: On Tue, Aug 24, 2010 at 4:21 PM, Jochen Schmitt joc...@herr-schmitt.de wrote: Am 24.08.10 14:55, schrieb Steve Dickson: How I merge the latests changes from the remotes/origin/f13/master on to my f13/user/steved/pnfs-13 remote branch? I think git cherry-pick is the command whar you want to use. cherry-pick is useful when you take patches from one _custom_ branch to another. I case of master branch the rebase is more convenient, I think. I do know and have used git cherry-pick before but in this particular case I agree with Andy that git rebase was the way to go... Thanks for the replies!! steved. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
[perl-DBD-SQLite] Fix testsuite to run with the latest sqlite (bugs.debian.org/591111).
commit acf6c396c24366416725a0b0d1dc32c98b80a94b
Author: Adam Tkac at...@redhat.com
Date: Tue Aug 24 15:35:41 2010 +0200
Fix testsuite to run with the latest sqlite (bugs.debian.org/59).
Signed-off-by: Adam Tkac at...@redhat.com
...-clean-temporary-files-in-child-processes.patch | 49
perl-DBD-SQLite.spec |7 ++-
2 files changed, 55 insertions(+), 1 deletions(-)
---
diff --git a/0001-Don-t-clean-temporary-files-in-child-processes.patch
b/0001-Don-t-clean-temporary-files-in-child-processes.patch
new file mode 100644
index 000..6ef1d4b
--- /dev/null
+++ b/0001-Don-t-clean-temporary-files-in-child-processes.patch
@@ -0,0 +1,49 @@
+From 89c8a661e61bbf0fb1d1e5050262390649e13f2a Mon Sep 17 00:00:00 2001
+From: Niko Tyni nt...@debian.org
+Date: Mon, 23 Aug 2010 08:15:15 +0300
+Subject: [PATCH] Don't clean temporary files in child processes
+
+As of SQLite 3.7.0, write locks try to stat() the database
+file and fail with a 'Disk I/O error' if it is missing. This
+breaks those tests that fork child processes (namely 08_busy.t
+and t/28_schemachange.t) because the child process removes
+the database file in the END block.
+
+The fix is to disable the clean() function for child processes.
+
+See http://bugs.debian.org/59
+---
+ t/lib/Test.pm |3 +++
+ 1 files changed, 3 insertions(+), 0 deletions(-)
+
+diff --git a/t/lib/Test.pm b/t/lib/Test.pm
+index 80e50ce..8d1be25 100644
+--- a/t/lib/Test.pm
b/t/lib/Test.pm
+@@ -7,6 +7,7 @@ use Exporter ();
+ use File::Spec ();
+ use Test::More ();
+
++my $parent;
+ use vars qw{$VERSION @ISA @EXPORT @CALL_FUNCS};
+ BEGIN {
+ $VERSION = '1.29';
+@@ -15,6 +16,7 @@ BEGIN {
+
+ # Allow tests to load modules bundled in /inc
+ unshift @INC, 'inc';
++ $parent = $$;
+ }
+
+ # Always load the DBI module
+@@ -22,6 +24,7 @@ use DBI ();
+
+ # Delete temporary files
+ sub clean {
++ return if $$ != $parent;
+ unlink( 'foo' );
+ unlink( 'foo-journal' );
+ }
+--
+1.7.1
+
diff --git a/perl-DBD-SQLite.spec b/perl-DBD-SQLite.spec
index 7c61aad..8f10c0f 100644
--- a/perl-DBD-SQLite.spec
+++ b/perl-DBD-SQLite.spec
@@ -1,6 +1,6 @@
Name: perl-DBD-SQLite
Version:1.29
-Release:3%{?dist}
+Release:4%{?dist}
Summary:SQLite DBI Driver
Group: Development/Libraries
@@ -8,6 +8,7 @@ License:GPL+ or Artistic
URL:http://search.cpan.org/dist/DBD-SQLite/
Source0:
http://search.cpan.org/CPAN/authors/id/A/AD/ADAMK/DBD-SQLite-%{version}.tar.gz
patch0: perl-DBD-SQLite-bz543982.patch
+Patch1: 0001-Don-t-clean-temporary-files-in-child-processes.patch
BuildRoot: %{_tmppath}/%{name}-%{version}-%{release}-root-%(%{__id_u} -n)
# if sqlite = 3.1.3 then
@@ -35,6 +36,7 @@ libraries.
%prep
%setup -q -n DBD-SQLite-%{version}
%patch0 -p1
+%patch1 -p1
%build
CFLAGS=$RPM_OPT_FLAGS %{__perl} Makefile.PL INSTALLDIRS=vendor
@@ -67,6 +69,9 @@ rm -rf $RPM_BUILD_ROOT
%changelog
+* Tue Aug 24 2010 Adam Tkac atkac redhat com - 1.29-4
+- fix testsuite to run with the latest sqlite (bugs.debian.org/59)
+
* Tue Aug 24 2010 Adam Tkac atkac redhat com - 1.29-3
- rebuild
--
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
Packages on which Thunderbird functionality depends!
For the past week or so I have been battling with a problem that I had thought (after some chasing around) was a Thunderbird upstream problem. The issue was that selecting Edit-Preferences- General and allowing selection of a xxx.wav file to play for incoming mail did not work. It turned out that in fact the reason was there were two required packages (pulseaudio-esound-compat and esound-libs) that were needed for Thunderbird to function with sound and play these sounds. Whilst it would be highly desirable for upstream to move from the now obsolete esd sound system to pulse, in the meantime we are stuck with thunderbird as it is. However it took quite a lot of searching to find the two packages necessary (which are not installed by default), and I wonder if it would be possible to make those two packages a dependency for thunderbird so that others don't hit the same bug. Certainly an inexperienced Fedora user would most likely not be able to resolve this for a standard installed set of packages! The upstream bug where this was sorted out is at: https://bugzilla.mozilla.org/show_bug.cgi?id=589732 It seems that for some other distributions the necessary packages are there by default. Any views on this? Could it be done for f14? -- mike c -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Packages on which Thunderbird functionality depends!
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 08/24/2010 09:37 AM, mike cloaked wrote: For the past week or so I have been battling with a problem that I had thought (after some chasing around) was a Thunderbird upstream problem. The issue was that selecting Edit-Preferences- General and allowing selection of a xxx.wav file to play for incoming mail did not work. It turned out that in fact the reason was there were two required packages (pulseaudio-esound-compat and esound-libs) that were needed for Thunderbird to function with sound and play these sounds. Whilst it would be highly desirable for upstream to move from the now obsolete esd sound system to pulse, in the meantime we are stuck with thunderbird as it is. However it took quite a lot of searching to find the two packages necessary (which are not installed by default), and I wonder if it would be possible to make those two packages a dependency for thunderbird so that others don't hit the same bug. Certainly an inexperienced Fedora user would most likely not be able to resolve this for a standard installed set of packages! The upstream bug where this was sorted out is at: https://bugzilla.mozilla.org/show_bug.cgi?id=589732 It seems that for some other distributions the necessary packages are there by default. Any views on this? Could it be done for f14? I'm not a Thunderbird maintainer, so I don't know how feasible this is, but perhaps we could create a subpackage like 'thunderbird-sound-support' that has the appropriate dependencies on it. Then at least someone doing a yum search on thunderbird would notice that and assume they probably wanted it (if they're hitting the same issue). It would then be up to the individual spins whether they want this in their default package set or not. - -- Stephen Gallagher RHCE 804006346421761 Delivering value year after year. Red Hat ranks #1 in value among software vendors. http://www.redhat.com/promo/vendor/ -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/ iEYEARECAAYFAkxzzDMACgkQeiVVYja6o6MykACggWnppFPYlZp6ul0fy8Fz0a4t u98AoKhFK+f2PVDvtYkCPY1sl4qIA/7k =cpl/ -END PGP SIGNATURE- -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
[Bug 626765] The latest F14 ocaml-lablgtk has lower NVR than F13
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=626765 --- Comment #4 from Fedora Update System upda...@fedoraproject.org 2010-08-24 09:41:19 EDT --- ocaml-lablgtk-2.14.0-6.fc14 has been submitted as an update for Fedora 14. http://admin.fedoraproject.org/updates/ocaml-lablgtk-2.14.0-6.fc14 -- 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. ___ ocaml-devel mailing list ocaml-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/ocaml-devel
git rebase OK on Fedora git branches?
Is it OK to use 'git rebase -i' to compress my mistakes together into a single working Fedora git commit? (Provided I don't push things in between or otherwise try to rewrite public history) I'm a bit confused by whether 'fedpkg commit', 'fedpkg build', 'fedpkg push' etc are doing magic that will be broken by this. Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones virt-p2v converts physical machines to virtual machines. Boot with a live CD or over the network (PXE) and turn machines into Xen guests. http://et.redhat.com/~rjones/virt-p2v -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: systemd acceptance, packaging guidelines (was Re: systemd and changes)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 08/24/2010 08:45 AM, Matthias Clasen wrote: On Mon, 2010-08-23 at 23:06 -0400, Bill Nottingham wrote: Hey Bill, this is a very good initial list, this should make it very easy for QA to whip up a test plan for systemd. Some comments below. BOOTUP - System boots successfully to GUI, when configured. - System boots successfully to text mode, when configured. - System properly handles being passed [1-5], 'single', 'S', 's', '-s', booting to the appropriate 'runlevel' (0 and 6 can still work, but they're sort of pointless anyway) When booted in this manner, '5' will bring up a GUI, and '3' will not. You mean 'being passed on the kernel cmdline', I assume ? Do we consider interactive boot essential (I think not) ? Should mention something about forced fsck, maybe. What about selinux relabeling ? SINGLE USER MODE - Exiting single user mode properly returns to the default state. - single-user mode output is correctly displayed on the console. PLYMOUTH - plymouth is shown on startup. - plymouth is quit correctly. - plymouth is shown on shutdown. - 'esc' to show details still functions in plymouth. - an equivalent to /var/log/boot.log still exists, and is populated (can be normal syslog) - plymouth transition from grub - boot - X is seamless for KMS cards, similar to Fedora 13. Note that this is currently broken (somewhere in X, not systemd's fault at all). RUNTIME TOOLS - telinit [0123456] does the proper thing. - the 'runlevel' command displays correct output if we are in a target that is aliased to a runlevel. - 'halt' shuts down, but does not poweroff. -- 'halt' supports -p, to power off. - 'poweroff' shuts down, and powers off. - 'reboot' shuts down and reboots. - 'halt', 'poweroff', 'reboot' all support '-f', to force the action. - 'halt', 'poweroff', 'reboot' all properly log to utmp, wtmp, and the audit layer. - 'shutdown' shall support the following arguments in a compatible manner: 'r', 'h', 'H', 'P', 'c', 'k', time. - 'telinit' does not error when passed '[Qq]' (to reload its configuration) and '[Uu]' to re-exec itself. It can optionally make systemd do a similar action, if valid. - init shall support a mechanism to re-exec itself to not cause dirty inodes on shutdown; initscripts will use this method on shutdown. - the kbdrequest job currently in systemd will be disabled for final release. - 'ctrl-alt-delete' will reboot the system. Should include chkconfig here, probably ? PREFDM - prefdm starts a configured display manager correctly. - prefdm starts a installed display manager correctly without additional configuration. CONSOLEKIT - ConsoleKit properly logs system start, stop, and restart. - The ConsoleKit shutdown/reboot/halt methods work as expected. SERIAL CONSOLES - Booting with a primary serial console (via console=) automatically sets up a getty on the console, and sets up securetty to allow for root login. - (optional) Booting with secondary serial consoles does the same. NON-SERIAL CONSOLES - By default, 6 gettys will be started in text mode, on tty1-6. 5 gettys will be started in GUI mode, on tty2-6. - getty and X will not be started on the same tty. - (optional) The number of ttys started can be configurable. ERROR HANDLING - SELinux automatic relabelling will still function. - fsck will still function. - Dropping to an emergency shell in the case where either of these fails shall still function. SELINUX - No AVCs from the init system in normal use. - No AVCs when executing any of the cases specified here - systemd shall still function if booted with selinux=0. PACKAGING - Guidelines for packaging systemd units shall be formalized. - The behavior when both systemd units and SysV services are present on the system shall be defined. This includes defined behavior when a service appears to be 'enabled' for SysV links while 'disabled' for systemd (and vice-versa). - The syntax of systemd units shall be frozen for the release (all future releases? Some set number of releases?) Can you clarify this a bit ? I assume what we want is that future systemd releases remain backwards compatible with systemd units of today. SERVICE HANDLING - Running 'chkconfig foo (null)|on|off' on a service managed by systemd will return the correct code/perform an appropriate action. - Running 'service foo start|stop|...' on a service managed by systemd will perform the appropriate action (via systemctl), and return similar errors. - Running '/etc/init.d/foo start|stop|...' will not break the systemd environment, while still performing the action specified, and shall return similar errors. GENERAL SANITY - Booting a system shall achieve a similar result as booting in upstart: -- The same set of services will be started. I don't think this is a requirement on systemd, really. If we make
[Bug 626765] The latest F14 ocaml-lablgtk has lower NVR than F13
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=626765 Fedora Update System upda...@fedoraproject.org changed: What|Removed |Added Status|ASSIGNED|MODIFIED -- 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. ___ ocaml-devel mailing list ocaml-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/ocaml-devel
Re: drop default MTA for Fedora 15
Once upon a time, pbrobin...@gmail.com pbrobin...@gmail.com said:
Neither of those need to run a MTA locally to work, you just need to
point them to a mail server, even then they need to be configured to
send the mail to something other than root anyway.
They can't be configured that way; they don't implement SMTP. It is a
de-facto standard for Unix programs to send mail by piping the message
to either /bin/mail or /usr/{sbin,lib}/sendmail. That has the advantage
of queueing for later delivery (what if I'm off-line when mdmonitor
detects a failure?) and such.
Having to implement SMTP in every program and then configure every
program for SMTP server settings (including possible AUTH and SSL/TLS
parameters) is a really bad idea.
I'm still of the opinion that there should be _something_ at the
de-facto standard location of /usr/sbin/sendmail that can queue messages
for later delivery. I don't care whether it is actually sendmail or
not. Preferably, it should be something that can be easily configured
to smarthost and use SMTP AUTH. I would use sendmail for that, but
that's just me (I understand many don't want sendmail and I have no
problem with that).
What do we gain by not having any MTA installed (other than a little bit
of disk space)? I understand that a little bit of disk space can add
up quick, but a local queueing MTA is a pretty standard part of a Unix
system.
--
Chris Adams cmad...@hiwaay.net
Systems and Network Administrator - HiWAAY Internet Services
I don't speak for anybody but myself - that's enough trouble.
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: git rebase OK on Fedora git branches?
On Tue, 2010-08-24 at 14:43 +0100, Richard W.M. Jones wrote: Is it OK to use 'git rebase -i' to compress my mistakes together into a single working Fedora git commit? (Provided I don't push things in between or otherwise try to rewrite public history) Yes. I'm a bit confused by whether 'fedpkg commit', 'fedpkg build', 'fedpkg push' etc are doing magic that will be broken by this. Not really. - ajax signature.asc Description: This is a digitally signed message part -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: drop default MTA for Fedora 15
Chris Adams wrote: What do we gain by not having any MTA installed (other than a little bit of disk space)? I understand that a little bit of disk space can add up quick, but a local queueing MTA is a pretty standard part of a Unix system. Why are you complaining? If your package needs an MTA - put in a Requires! Why do we need packages installed just because? -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: systemd acceptance, packaging guidelines (was Re: systemd and changes)
On Tue, 2010-08-24 at 08:45 -0400, Matthias Clasen wrote: On Mon, 2010-08-23 at 23:06 -0400, Bill Nottingham wrote: BOOTUP - System boots successfully to GUI, when configured. - System boots successfully to text mode, when configured. - System properly handles being passed [1-5], 'single', 'S', 's', '-s', booting to the appropriate 'runlevel' (0 and 6 can still work, but they're sort of pointless anyway) When booted in this manner, '5' will bring up a GUI, and '3' will not. You mean 'being passed on the kernel cmdline', I assume ? Do we consider interactive boot essential (I think not) ? Should mention something about forced fsck, maybe. What about selinux relabeling ? I can't remember interactive boot ever working. PLYMOUTH - plymouth is shown on startup. - plymouth is quit correctly. - plymouth is shown on shutdown. - 'esc' to show details still functions in plymouth. - an equivalent to /var/log/boot.log still exists, and is populated (can be normal syslog) - plymouth transition from grub - boot - X is seamless for KMS cards, similar to Fedora 13. Note that this is currently broken (somewhere in X, not systemd's fault at all). Depends on the driver, but yeah. - ajax signature.asc Description: This is a digitally signed message part -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: drop default MTA for Fedora 15
On Tue, Aug 24, 2010 at 08:56:21AM -0500, Chris Adams wrote: I'm still of the opinion that there should be _something_ at the de-facto standard location of /usr/sbin/sendmail that can queue messages for later delivery. I don't care whether it is actually sendmail or not. Preferably, it should be something that can be easily configured to smarthost and use SMTP AUTH. I would use sendmail for that, but that's just me (I understand many don't want sendmail and I have no problem with that). +1 -- Matthew Miller mat...@mattdm.org Senior Systems Architect -- Instructional Research Computing Services Harvard School of Engineering Applied Sciences -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: systemd acceptance, packaging guidelines (was Re: systemd and changes)
On Tue, 2010-08-24 at 10:00 -0400, Adam Jackson wrote: On Tue, 2010-08-24 at 08:45 -0400, Matthias Clasen wrote: On Mon, 2010-08-23 at 23:06 -0400, Bill Nottingham wrote: BOOTUP - System boots successfully to GUI, when configured. - System boots successfully to text mode, when configured. - System properly handles being passed [1-5], 'single', 'S', 's', '-s', booting to the appropriate 'runlevel' (0 and 6 can still work, but they're sort of pointless anyway) When booted in this manner, '5' will bring up a GUI, and '3' will not. You mean 'being passed on the kernel cmdline', I assume ? Do we consider interactive boot essential (I think not) ? Should mention something about forced fsck, maybe. What about selinux relabeling ? I can't remember interactive boot ever working. It always worked for me - and it saved my arse a number of times when a service starting up would go haywire and hang the system. I know it worked in rhel4 and rhel5 - so circa: fedora 3 and fedora 6 at the very least. -sv -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: drop default MTA for Fedora 15
On 08/24/2010 02:58 PM, Michael Cronenworth wrote:
Chris Adams wrote:
What do we gain by not having any MTA installed (other than a little bit
of disk space)? I understand that a little bit of disk space can add
up quick, but a local queueing MTA is a pretty standard part of a Unix
system.
Why are you complaining? If your package needs an MTA - put in a Requires!
Not everything that runs on Fedora is a Fedora package: people run
their own programs, too. Some things, like the existence of /bin/ls
or being able to send mail by piping the message to either /bin/mail
or /usr/{sbin,lib}/sendmail are basic features of UNIX.
Andrew.
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: drop default MTA for Fedora 15
On Tue, Aug 24, 2010 at 08:58:50AM -0500, Michael Cronenworth wrote: Why are you complaining? If your package needs an MTA - put in a Requires! If we follow the general state of things: if a package might need something, toss it in as a requires!, this will totally defeat the purpose of the comps change, since it will get pulled in by something important at some point. Rsyslog, for example, can send output via e-mail. Having a very simple mail-queue-and-relay program as an alternative to sendmail seems like a better choice than just ditching it. -- Matthew Miller mat...@mattdm.org Senior Systems Architect -- Instructional Research Computing Services Harvard School of Engineering Applied Sciences -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Python 3.2a1 in rawhide
On Mon, Aug 23, 2010 at 7:16 PM, David Malcolm dmalc...@redhat.com wrote: A suggested fix (caveat: not tested): ensure that the python-lxml.spec has a BuildRequires: Cython = 0.12 and delete the .c file in the %prep, to ensure that Cython regenerates it during the build. Does this fix it? That worked, or at least it let me build. Cython isn't available for python3 apparently so you can't let the python3 build stage generate the .c files, you need to generate them during the python2 build stage and copy them over to the python3 build dir. One other issue I discovered was that I needed to suppress byte compiling during the install stage because it seemed that the python3 installer somehow was doing python2-style byte compilation. (Or maybe I'm just misunderstanding things) -- Jeff Ollie -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: systemd acceptance, packaging guidelines (was Re: systemd and changes)
On Tue, Aug 24, 2010 at 10:00:55AM -0400, Adam Jackson wrote: I can't remember interactive boot ever working. It does in RHEL 5. It will need to be working for RHEL 7. -- Matthew Miller mat...@mattdm.org Senior Systems Architect -- Instructional Research Computing Services Harvard School of Engineering Applied Sciences -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: drop default MTA for Fedora 15
Andrew Haley wrote:
Not everything that runs on Fedora is a Fedora package: people run
their own programs, too. Some things, like the existence of /bin/ls
or being able to send mail by piping the message to either /bin/mail
or/usr/{sbin,lib}/sendmail are basic features of UNIX.
No one is going to stop you from using an MTA.
I, for one, *never* use /bin/mail or /usr/bin/sendmail. I guess you
could call me a young whipper snapper though.
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: drop default MTA for Fedora 15
Once upon a time, Michael Cronenworth m...@cchtml.com said: Chris Adams wrote: What do we gain by not having any MTA installed (other than a little bit of disk space)? I understand that a little bit of disk space can add up quick, but a local queueing MTA is a pretty standard part of a Unix system. Why are you complaining? If your package needs an MTA - put in a Requires! It seems that this thread is trying to eliminate those requirements. The mdadm package doesn't currently require MTA (needed for monitoring). If the Requires was added, what would be the response (since the proposal is to remove any MTA from the default package set)? Why do we need packages installed just because? I guess I assumed that Fedora is still providing a Unix-like system. There are a number of things in the Base package set that are there just because this is still a Unix-like system, not because they are required by any other installed software. How many users use at or bc (well, I use dc all the time)? What about ed? Nothing directly depends on them (except for the LSB package, which also requires /usr/sbin/sendmail). -- Chris Adams cmad...@hiwaay.net Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: drop default MTA for Fedora 15
Matthew Miller wrote: If we follow the general state of things: if a package might need something, toss it in as a requires!, this will totally defeat the purpose of the comps change, since it will get pulled in by something important at some point. Rsyslog, for example, can send output via e-mail. That's *not* what I said. There are guidelines in place to prevent a Requires madness. This is a perfect opportunity for you to investigate Recommended for RPM. Having a very simple mail-queue-and-relay program as an alternative to sendmail seems like a better choice than just ditching it. I'll just yum remove that, too. Thanks for wasting 30 seconds of my life. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: drop default MTA for Fedora 15
On 24/08/10 15:13, Chris Adams wrote: Once upon a time, Michael Cronenworthm...@cchtml.com said: Chris Adams wrote: What do we gain by not having any MTA installed (other than a little bit of disk space)? I understand that a little bit of disk space can add up quick, but a local queueing MTA is a pretty standard part of a Unix system. Why are you complaining? If your package needs an MTA - put in a Requires! It seems that this thread is trying to eliminate those requirements. The mdadm package doesn't currently require MTA (needed for monitoring). If the Requires was added, what would be the response (since the proposal is to remove any MTA from the default package set)? Why do we need packages installed just because? I guess I assumed that Fedora is still providing a Unix-like system. There are a number of things in the Base package set that are there just because this is still a Unix-like system, not because they are required by any other installed software. How many users use at or bc (well, I use dc all the time)? I use at on a regular basis, to schedule large downloads and uploads when my ADSL bandwidth becomes unmetered after midnight. And I like getting the resulting email in the morning showing that all went well, or not as the case may be. Paul. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Packages on which Thunderbird functionality depends!
On Tue, Aug 24, 2010 at 2:42 PM, Stephen Gallagher sgall...@redhat.com wrote: I'm not a Thunderbird maintainer, so I don't know how feasible this is, but perhaps we could create a subpackage like 'thunderbird-sound-support' that has the appropriate dependencies on it. Then at least someone doing a yum search on thunderbird would notice that and assume they probably wanted it (if they're hitting the same issue). It would then be up to the individual spins whether they want this in their default package set or not. That sounds like a reasonable suggestion. -- mike c -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: drop default MTA for Fedora 15
On Tue, 2010-08-24 at 10:09 -0400, Matthew Miller wrote: On Tue, Aug 24, 2010 at 08:58:50AM -0500, Michael Cronenworth wrote: Why are you complaining? If your package needs an MTA - put in a Requires! If we follow the general state of things: if a package might need something, toss it in as a requires!, this will totally defeat the purpose of the comps change, since it will get pulled in by something important at some point. Rsyslog, for example, can send output via e-mail. Having a very simple mail-queue-and-relay program as an alternative to sendmail seems like a better choice than just ditching it. My previous objection was based on the precedent it sets. I don't want a Desktop distribution in Fedora. I want a server-usable distribution. Sure, it's just a dep and one can go install an MTA. But today it's killing the MTA, tomorrow it's removing something else that's useful on the server side of things. I want to see that trend stop and reverse. Jon. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: drop default MTA for Fedora 15
Paul Howarth wrote:
I use at on a regular basis, to schedule large downloads and uploads
when my ADSL bandwidth becomes unmetered after midnight.
And I like getting the resulting email in the morning showing that all
went well, or not as the case may be.
No one will prevent you from doing so. Nothing on your end will change.
I get it now - This is the old meets the new.
New: MTA? WTF?
Old: MTA! 3
It is asking a lot for Fedora to be a one size fits all distribution.
No one will be happy, so what can the compromise be?
1) Leave as is. Makes MTA-lovers rejoice. Other folks will continue to
yum remove.
2) Remove from comps. Makes Desktop users rejoice. Other folks will yum
install {sendmail,postfix,exim,$MTA}
3) Make Fedora installs separated into usage-based comps. Server,
Laptop, Netbook, and Handheld (read MeeGo).
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora Notifications System.
Jaroslav Reznik wrote: Reading this - I'm not sure all Fedora notifications should go through system notification system. Why? I understand it for urgent/priority notification like Close your desktop, nuclear war out there (or just a security update combined with some steps how to fix it). But I hope it should work for a lot of things like Fedora elections etc. - this should for example go to your calendar, some tips how to use Fedora (just a RSS feed like Plasma widget?) etc. That essentially already exists [0], so just point your existing widgets at that. I personally think that shoving things of this nature in users' faces is not the job of an operating system. [0] http://planet.fedoraproject.org/atom.xml -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: drop default MTA for Fedora 15
On Tue, 2010-08-24 at 10:19 -0400, Jon Masters wrote: My previous objection was based on the precedent it sets. I don't want a Desktop distribution in Fedora. I want a server-usable distribution. Sure, it's just a dep and one can go install an MTA. But today it's killing the MTA, tomorrow it's removing something else that's useful on the server side of things. I want to see that trend stop and reverse. How about you become involved in the 'Server' SIG [1] then, and help them produce a spin or install image that is suitable for your idea of a server, instead of shooting down changes on this mailing list. Blocking change is not going to make Fedora a better server... Matthias [1] http://fedoraproject.org/wiki/SIGs/Server -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: systemd and changes
On Mon, Aug 23, 2010 at 04:32:03PM -0400, Bill Nottingham wrote: So, I'm honestly asking: what are the odds that these few things are the only improvements that cause a disruptive change to user interaction? I don't think it's unreasonable to wonder if there are other changes which fit this category. My concern with this line of thinking is that you're asking us to quantify the unknown unknown, and define a time period of testing which is 'long enough' for us to catch all the unknown unknowns. This seems impractical, in as much as it doesn't give us any clear criteria to define success with. I guess what I'm getting at is that we need careful end-user release note documentation at the alpha testing stage showing what's known by the developers to have a new interface or semantics. Some of that is in the FAQ (How do I change a runlevel? Turns out, by isolating a target which defines that runlevel.) but some of it is not -- things like noauto now means auto should have been in there. And a FAQ format is not exactly what's needed. Writing this isn't necessarily Lennart's job. But someone needs to do it, and if it's there sooner rather than later, it'll be a better document and issues with design and intent can be addressed. -- Matthew Miller mat...@mattdm.org Senior Systems Architect -- Instructional Research Computing Services Harvard School of Engineering Applied Sciences -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: drop default MTA for Fedora 15
On Tue, 2010-08-24 at 10:36 -0400, Matthias Clasen wrote: On Tue, 2010-08-24 at 10:19 -0400, Jon Masters wrote: My previous objection was based on the precedent it sets. I don't want a Desktop distribution in Fedora. I want a server-usable distribution. Sure, it's just a dep and one can go install an MTA. But today it's killing the MTA, tomorrow it's removing something else that's useful on the server side of things. I want to see that trend stop and reverse. How about you become involved in the 'Server' SIG [1] then Happy to do so. I also happen to believe that Fedora should have certain server-useful characteristics out of the box (like Linux always has done). That's my opinion, I've made it known, and now I'm done. Jon. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: drop default MTA for Fedora 15
On Tue, Aug 24, 2010 at 08:56:21AM -0500, Chris Adams wrote:
They can't be configured that way; they don't implement SMTP. It is a
de-facto standard for Unix programs to send mail by piping the message
to either /bin/mail or /usr/{sbin,lib}/sendmail. That has the advantage
of queueing for later delivery (what if I'm off-line when mdmonitor
detects a failure?) and such.
The problem with delivering this to a user's mailbox via an MTA is that
in the typical case it doesn't result in the user noticing anything
until they've logged in as root and find out that the you have new
mail message actually means Your RAID is fucked and not just Here's
some random syslog spew that something you installed and forgot about
keeps generating. If the question is How do I ensure that important
system messages get delivered to someone who can do something about them
in a timely manner, a local MTA isn't a great answer.
There's certainly a set of people who want an MTA for this - in a server
environment it's obviously far more straightforward to get mailed on
failure, and that's something that you'll probably configure when
setting up the machine in the first place. But we're talking about the
default install case, and right now the situation is that anything that
pipes directly to sendmail is almost certainly never being read by the
user. Having an MTA installed doesn't solve the problem that we want to
solve, and so dropping an MTA from the default install means a reduction
in the quantity of privileged code running on the system without any
significant reduction in functionality.
The long term fix would arguably be to provide a stub /usr/sbin/sendmail
that ties into a more generic event reporting interface, which in turn
could be configured to send mail elsewhere but would default to popping
up some sort of desktop notification.
--
Matthew Garrett | mj...@srcf.ucam.org
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: drop default MTA for Fedora 15
Matthew Garrett wrote: The long term fix would arguably be to provide a stub /usr/sbin/sendmail that ties into a more generic event reporting interface, which in turn could be configured to send mail elsewhere but would default to popping up some sort of desktop notification. Already works that way. Sendmail/logwatch deliver e-mail and DeviceKit displays desktop notifications (without requiring an MTA). -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Git question
On Tue, 24 Aug 2010, Steve Dickson wrote: Also, the kernel that is currently being built from my pnfs-13 branch fails to install with the following error: FATAL: Could not load /lib/modules/2.6.34.5-43.pnfs_all_2.6.35_2010_08_19.fc13.x86_64-pnfs/modules.dep: No such file or directory The extra -pnfs on the 2.6.34.5-43... directory name is the problem. It probably has something to do with how I changed the buildid: I suspect it has nothing to do with the buildid (I use one and don't have the problem). I would check the kernel version file in the source (I don't know offhand what it is called) and see if -pnfs is added there. If it is add a patch to remove it. Michael Young -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: systemd and changes
On Mon, Aug 23, 2010 at 03:04:43PM -0700, Jesse Keating wrote: As to not keep moving the goal posts for Lennart, I believe that some group (perhaps FESCo) should come up with a set of do or die functionality for systemd, that can be tested for at the test day. That way the goals are clearly marked. If it passes, hurray! If it doesn't pass, then FESCo would be able to give Lennart a timeline to make them pass, or enact the rollback plan. Obviously this timeline should leave enough time at the end of it to enact the rollback plan without causing Beta to slip. Or FESCo could decide that systemd is worth slipping for and thus enact a slip until systemd can pass the do or die test set. Either way, clearly mark the goals, let Lennart shoot for them. FTR, this sounds perfect to me. I am not opposed to systemd a priori. -- Matthew Miller mat...@mattdm.org Senior Systems Architect -- Instructional Research Computing Services Harvard School of Engineering Applied Sciences -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: drop default MTA for Fedora 15
On Tue, Aug 24, 2010 at 03:43:36PM +0100, Matthew Garrett wrote: There's certainly a set of people who want an MTA for this - in a server environment it's obviously far more straightforward to get mailed on failure, and that's something that you'll probably configure when This isn't server-only -- it's also the case in an enterprise desktop environment. I don't think that's a real problem, because if those places aren't installing via kickstart already, they've got other issues. But I just wanted to point out that this isn't a pure server-vs-the-desktop issue. The long term fix would arguably be to provide a stub /usr/sbin/sendmail that ties into a more generic event reporting interface, which in turn could be configured to send mail elsewhere but would default to popping up some sort of desktop notification. +1. C'mon, prolific desktop code guys. :) -- Matthew Miller mat...@mattdm.org Senior Systems Architect -- Instructional Research Computing Services Harvard School of Engineering Applied Sciences -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: systemd acceptance, packaging guidelines (was Re: systemd and changes)
On Tue, Aug 24, 2010 at 10:18:27AM +0200, Tomasz Torcz wrote: File /etc/inittab should keep working at the same level it is now. Now it only selects default runlevel. How about: - If /etc/inittab exists and contains an initdefault line, the default target will be set accordingly. - any other non-comment, non-blank lines in /etc/inittab will be logged as warnings. This leaves a migration path (ditch the file completely) while maintaining some backwards compatibility. For a number of releases, the file can continue to exist with a warning in the comments and the release notes, and then eventually it can go away. -- Matthew Miller mat...@mattdm.org Senior Systems Architect -- Instructional Research Computing Services Harvard School of Engineering Applied Sciences -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: drop default MTA for Fedora 15
On 08/24/2010 03:37 PM, Jon Masters wrote: On Tue, 2010-08-24 at 10:36 -0400, Matthias Clasen wrote: On Tue, 2010-08-24 at 10:19 -0400, Jon Masters wrote: My previous objection was based on the precedent it sets. I don't want a Desktop distribution in Fedora. I want a server-usable distribution. Sure, it's just a dep and one can go install an MTA. But today it's killing the MTA, tomorrow it's removing something else that's useful on the server side of things. I want to see that trend stop and reverse. How about you become involved in the 'Server' SIG [1] then Happy to do so. I also happen to believe that Fedora should have certain server-useful characteristics out of the box (like Linux always has done). That's my opinion, I've made it known, and now I'm done. It's not just about the MTA. I think there's a much more fundamental question here, which is whether a default Fedora installation is intended to be a real UNIX-like system or just the dependencies for GNOME. Andrew. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Announcing the release of Fedora 14 Alpha!!
The Fedora 14 Laughlin Alpha release is available! This release offers a preview of some of the best free and open source technology currently under development. Catch a glimpse of the future: http://fedoraproject.org/get-prerelease == What is the Alpha release? == The Alpha release contains all the features of Fedora 14 in a form that anyone can help test. This testing, guided by the Fedora QA team, helps us target and identify bugs. When these bugs are fixed, we make a Beta release available. A Beta release is code-complete, and bears a very strong resemblance to the third and final release. The final release of Fedora 14 is due in November. We need your help to make Fedora 14 the best release yet, so please take a moment of your time to download and try out the Alpha and make sure the things that are important to you are working. If you find a bug, please report it -- every bug you uncover is a chance to improve the experience for millions of Fedora users worldwide. Together, we can make Fedora a rock-solid distribution. (Read down to the end of the announcement for more information on how to help.) Fedora 14 is named in honor of distinguished physicist Robert B. Laughlin, whose fields of research have included, among other things, the topic of emergence. Emergence is the process by which a group of individual components interact to produce a system that is more complex than the sum of its parts - a perfect description of an open source community. ==Features== This release of Fedora includes a variety of features both over and under the hood that show off the power and flexibility of the advancing state of free software. Examples include: * '''System and session management.''' Fedora 14 introduces '''systemd''', a smarter, more efficient way of starting up and managing the background daemons that services we all use every day - such as '''NetworkManager''' and '''PulseAudio''' - rely on. * '''Desktop virtualization'''. High-quality access to QEMU virtual machines moves a step closer with the introduction of '''Spice''', a complete open source solution for interaction with virtualized desktops. * '''Faster JPEG compression/decompression'''. The replacement of '''libjpeg''' with '''libjpeg-turbo''' brings speed improvements to a wide range of applications when handling images in JPEG format, including photo managers, video editors and PDF readers. * '''New and updated programming languages'''. Fedora 14 sees the introduction of '''D''', a systems programming language combining power and high performance with programmer productivity, as well as updates to '''Python''', '''Erlang''', and '''Perl'''. * '''Better tools for developers'''. Simpler, faster debugging with '''gdb''' indexing and new commands for finding and fixing memory leaks, as well as new versions of '''NetBeans''' and '''Eclipse'''. * '''The latest desktop environments'''. '''KDE 4.5''' introduces window tiling and better notification features, along with many stability improvements. '''Sugar 0.90''' features major usability improvements and support for 3G networks. * '''Improved netbook experience with MeeGo™'''. The '''MeeGo™ Netbook UX 1.0''' provides a user interface tailored specifically for netbooks, building on the foundations laid by '''Moblin''' in previous Fedora releases. * '''Fedora on the cloud'''. From Fedora 14 onward images for EC2 will be provided for each new release, allowing users of Amazon's on-demand cloud computing platform to use the latest Fedora. * '''IPMI server management made simple'''. New to Fedora 14 is '''ipmiutil''', an easy-to-use, fully-featured IPMI server management utility that allows a wide range of management functions to be performed with just a few commands. * '''Support for SCAP'''. Fedora 14 introduces an open source framework for the Security Content Automation Protocol (SCAP), allowing users to automatically scan their system to check whether it complies with a defined security configuration. * '''Perl 6 support with Rakudo'''. Fedora 14 comes with Rakudo Perl, an implementation of the Perl 6 specification based on the Parrot virtual machine, which enables developers to write new applications or port existing ones to Perl 6. * '''More powerful data analysis'''. Given that Fedora 14 is named after one of the giants of modern theoretical physics, it seems appropriate that Laughlin sees the introduction to Fedora of '''ROOT''', an obejct-oriented, open-source platform for data acquisition, simulation and data analysis developed by CERN. Support for the increasingly popular '''R''' statistical programming language is also broadened with a range of new addons. These and many other improvements provide a wide and solid base for future releases, further increasing the range of possibilities for developers and helping to maintain Fedora's position at the leading edge of free and open source technology. A more complete list and
Re: drop default MTA for Fedora 15
Andrew Haley wrote: I think there's a much more fundamental question here, which is whether a default Fedora installation is intended to be a real UNIX-like system or just the dependencies for GNOME. I was going to reply to Chris, but I'll reply here. What benefit do I, or anyone else, receive by shipping a 100% Unix-clone environment by default? With PCs evolving every 5-10 years, will Unix-like be necessary for much longer? Are we making a Fedora for people to use or for researchers to study? -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: systemd acceptance, packaging guidelines (was Re: systemd and changes)
On Tue, Aug 24, 2010 at 08:45:33AM -0400, Matthias Clasen wrote: GENERAL SANITY - Booting a system shall achieve a similar result as booting in upstart: -- The same set of services will be started. I don't think this is a requirement on systemd, really. If we make changes to the default system configuration to not include a service in F14 that was included in F13, that is not a systemd problem. So, I think what you really mean here is: systemd will start all services that are configured to be included in the default install (and dependencies), but no others. If we're still including upstart as a fallback option, I think it's reasonable to ask that making that selection doesn't significantly change what gets started -- *or*, that if it is expected to behave differently, all ways in which it will be different are clearly documented in the release notes. Cases where I think documenting differences is appropriate rather than requiring identical behavior would be: - services which take advantage of fancy new systemd features - services which take advantage of any upstartd features which systemd does not implement in a similar fashion (if such things exist). - services where the end-user has gone out of their way to configure upstart in a fancy non-default way. It'd be *nice* if the last case could automatically work too, but I'm not expecting magic. So instead, we need to be clear. - The basic syntax of systemd commands shall be frozen for future releases. - The syntax of systemd units shall be frozen for future releases. Again, the best we can ask for is backwards compatibility, I think. 'Frozen' is entirely too strong for a 2 month old project. In fact, I think we need some flexibility to change things which turn out to be sub-optimal once they're out in the real world. Freezing these decisions too soon is one of the strong arguments for waiting until F15. -- Matthew Miller mat...@mattdm.org Senior Systems Architect -- Instructional Research Computing Services Harvard School of Engineering Applied Sciences -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: drop default MTA for Fedora 15
On Tue, 2010-08-24 at 10:10 -0500, Michael Cronenworth wrote: Andrew Haley wrote: I think there's a much more fundamental question here, which is whether a default Fedora installation is intended to be a real UNIX-like system or just the dependencies for GNOME. I was going to reply to Chris, but I'll reply here. What benefit do I, or anyone else, receive by shipping a 100% Unix-clone environment by default? With PCs evolving every 5-10 years, will Unix-like be necessary for much longer? Are we making a Fedora for people to use or for researchers to study? I think it really depends on what you mean by 'people'. If you mean people == someone using a laptop/desktop. OR do you mean people == someone who admins a lot of servers and desktops for others. And that is the crux of the issue and has always been the crux of the issue. -sv -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: drop default MTA for Fedora 15
On Tue, Aug 24, 2010 at 09:46:26AM -0500, Michael Cronenworth wrote: Matthew Garrett wrote: The long term fix would arguably be to provide a stub /usr/sbin/sendmail that ties into a more generic event reporting interface, which in turn could be configured to send mail elsewhere but would default to popping up some sort of desktop notification. Already works that way. Sendmail/logwatch deliver e-mail and DeviceKit displays desktop notifications (without requiring an MTA). That's limited to disk and power notifications, isn't it? -- Matthew Garrett | mj...@srcf.ucam.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: drop default MTA for Fedora 15
On Tue, Aug 24, 2010 at 10:53:13AM -0400, Matthew Miller wrote: On Tue, Aug 24, 2010 at 03:43:36PM +0100, Matthew Garrett wrote: There's certainly a set of people who want an MTA for this - in a server environment it's obviously far more straightforward to get mailed on failure, and that's something that you'll probably configure when This isn't server-only -- it's also the case in an enterprise desktop environment. Sorry, yeah - wherever I say Server read it as Machine with a remote sysadmin. The long term fix would arguably be to provide a stub /usr/sbin/sendmail that ties into a more generic event reporting interface, which in turn could be configured to send mail elsewhere but would default to popping up some sort of desktop notification. +1. C'mon, prolific desktop code guys. :) I'll take a look at what would be involved. -- Matthew Garrett | mj...@srcf.ucam.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Python 3.2a1 in rawhide
On Tue, 2010-08-24 at 09:10 -0500, Jeffrey Ollie wrote: On Mon, Aug 23, 2010 at 7:16 PM, David Malcolm dmalc...@redhat.com wrote: A suggested fix (caveat: not tested): ensure that the python-lxml.spec has a BuildRequires: Cython = 0.12 and delete the .c file in the %prep, to ensure that Cython regenerates it during the build. Does this fix it? That worked, or at least it let me build. Cython isn't available for python3 apparently so you can't let the python3 build stage generate the .c files, you need to generate them during the python2 build stage and copy them over to the python3 build dir. As I understand it, the .c files that Cython generates are compilable against both Python 2 and Python 3: it adds the necessary preprocessor macros to do the right thing. (The shared libraries that are generated will be specific to a particular MAJOR.MINOR release of python, though). Cython itself is implemented in Python; it sounds from the above like it's written to work with just Python 2 at this stage (which I don't see as an issue; I think it's perfectly acceptable to require python 2 to run tools to build python 3 packages; as another example: we use systemtap's /usr/bin/dtrace during the build of python3, which is in fact a Python 2 script). One other issue I discovered was that I needed to suppress byte compiling during the install stage because it seemed that the python3 installer somehow was doing python2-style byte compilation. (Or maybe I'm just misunderstanding things) That sounds weird. Do you have a build log? Dave -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: systemd acceptance, packaging guidelines (was Re: systemd and changes)
On Mon, Aug 23, 2010 at 11:06:32PM -0400, Bill Nottingham wrote: RUNTIME TOOLS - telinit [0123456] does the proper thing. It currently doesn't, by the way. But there's been upstream fixes which aren't yet in rawhide, so I'll retest when that's available. - the 'runlevel' command displays correct output if we are in a target that is aliased to a runlevel. Correct meaning not just the highest-numbered synonymous runlevel, but the one which was selected? From one point of view, it tells you something that is correct now. From a practical point of view, I think what's actually important is: -- if you're in single user mode → it says 'S' -- if you're in non-GUI multiuser → it says '3' -- if you're in X mode→ it says '5' Because that's what people are testing for in scripts. It should also print the correct _previous_ runlevel. I note that the man page for Fedora 13's runlevel command (and RHEL 5's, for that matter) claims that init will set the environment variables RUNLEVEL and PREVLEVEL, but that doesn't seem to actually happen. The systemd man page for runlevel doesn't say that init will set those, but says that if they *are* set, that's where it will get its information. - 'shutdown' shall support the following arguments in a compatible manner: 'r', 'h', 'H', 'P', 'c', 'k', time. Including acting like the current shutdown command with times e.g. tomorrow morning. - 'telinit' does not error when passed '[Qq]' (to reload its configuration) and '[Uu]' to re-exec itself. It can optionally make systemd do a similar action, if valid. Since it already is documented as doing the similar actions, let's remove optionally from this statement. SERVICE HANDLING - Running 'chkconfig foo (null)|on|off' on a service managed by systemd will return the correct code/perform an appropriate action. - Running 'service foo start|stop|...' on a service managed by systemd will perform the appropriate action (via systemctl), and return similar errors. Please also include 'restart' and 'reload'. And if 'graceful' for httpd and any other services which support that kind of thing will no longer work, that needs to be documented in big bold letters. - Running '/etc/init.d/foo start|stop|...' will not break the systemd environment, while still performing the action specified, and shall return similar errors. Likewise, commands like apache's 'apachectl graceful' need to continue working, even if upstart does something special to start those services. (I don't know that they wouldn't; it just should go on the list.) I would like to see tab-completion for systemctl working before the final release. That's a request, though, not a demand. -- Matthew Miller mat...@mattdm.org Senior Systems Architect -- Instructional Research Computing Services Harvard School of Engineering Applied Sciences -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Broken dependencies: perl-Pugs-Compiler-Rule
perl-Pugs-Compiler-Rule has broken dependencies in the F-14 tree: On x86_64: perl-Pugs-Compiler-Rule-0.37-4.fc13.noarch requires perl(:MODULE_COMPAT_5.10.1) On i386: perl-Pugs-Compiler-Rule-0.37-4.fc13.noarch requires perl(:MODULE_COMPAT_5.10.1) Please resolve this as soon as possible. -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Re: drop default MTA for Fedora 15
Once upon a time, Michael Cronenworth m...@cchtml.com said: What benefit do I, or anyone else, receive by shipping a 100% Unix-clone environment by default? With PCs evolving every 5-10 years, will Unix-like be necessary for much longer? Are we making a Fedora for people to use or for researchers to study? So, according to you, Unix-like systems are only for researchers to study? How does PCs evolving every 5-10 years have any bearing on being Unix-like or not? -- Chris Adams cmad...@hiwaay.net Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: systemd acceptance, packaging guidelines (was Re: systemd and changes)
On Mon, Aug 23, 2010 at 11:06:32PM -0400, Bill Nottingham wrote: SERVICE HANDLING - Running 'chkconfig foo (null)|on|off' on a service managed by systemd will return the correct code/perform an appropriate action. - Running 'service foo start|stop|...' on a service managed by systemd will perform the appropriate action (via systemctl), and return similar errors. - Running '/etc/init.d/foo start|stop|...' will not break the systemd environment, while still performing the action specified, and shall return similar errors. - Running 'service foo status will' produce a concise human-understandable output and the apppropriate return code -- Matthew Miller mat...@mattdm.org Senior Systems Architect -- Instructional Research Computing Services Harvard School of Engineering Applied Sciences -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Bodhi updates
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Bodhi updates can have multiple packages associated with a single update as long as they are on different branches. Why this restriction? At least in the case of something like a security update, I would think that it would be beneficial to be able to push the update to all branches simultaneously. - -- Stephen Gallagher RHCE 804006346421761 Delivering value year after year. Red Hat ranks #1 in value among software vendors. http://www.redhat.com/promo/vendor/ -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/ iEYEARECAAYFAkxz8sEACgkQeiVVYja6o6OT2wCdEc0bSCkXTlpr9+EvKJc/YjFR dVAAoIL6qIHj0cs//+fXYXKECT3YlWev =S8C2 -END PGP SIGNATURE- -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora Notifications System.
2010/8/24 Garrett Holmstrom gho...@fedoraproject.org Jaroslav Reznik wrote: Reading this - I'm not sure all Fedora notifications should go through system notification system. Why? I understand it for urgent/priority notification like Close your desktop, nuclear war out there (or just a security update combined with some steps how to fix it). But I hope it should work for a lot of things like Fedora elections etc. - this should for example go to your calendar, some tips how to use Fedora (just a RSS feed like Plasma widget?) etc. That essentially already exists [0], so just point your existing widgets at that. I personally think that shoving things of this nature in users' faces is not the job of an operating system. [0] http://planet.fedoraproject.org/atom.xml -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel @Jaroslav: The idea is to have a way to communicate Fedora with the user and viceversa... If Fedora has another Important Bug like the Update One in Fedora 13 Hermes will tell the user inmediatly and it will say the user how to fix it. The idea is to have not only a notification system, but also a way to keep the user in touch with Fedora. I think that if there's already a plasma widget for a RSS Feed Parser (Or a screenlet in case of gnome) we can start working from there... I'll also would like to offer the user a search bar in hermes that uses fedora's database to give search results to the user, so when someone using fedora wants to know a HowTo instead of using Google, they'll have the option of Fedora answering them @Garret: Many things are not the job of an operating system already... The idea is to transform Fedora in more that just software... Let's transform it into a intelligent enviroment concerned about it's users and powered by it's community... -- -Manuel Escudero- Linux User #509052 @GWave: jmlev...@googlewave.com @Blogger: http://www.blogxenode.tk/ (Xenode Systems Blog) PGP/GnuPG: DAE3 82E9 D68E 7AE4 ED31 1F8F 4AF4 D00C 50E7 ABC6 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: systemd acceptance, packaging guidelines
On Mon, Aug 23, 2010 at 11:06:32PM -0400, Bill Nottingham wrote: PACKAGING - The syntax of systemd units shall be frozen for the release (all future releases? Some set number of releases?) ADMIN INTERFACE - The files and paths used by systemd shall be frozen for future releases. - The basic syntax of systemd commands shall be frozen for future releases. - The syntax of systemd units shall be frozen for future releases. Imho systemd is too young to already freeze that much stuff for more than a release. Regards Till pgp5907HFYFiC.pgp Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
systemd: targets which are runlevel-like
As I was thinking about Bug 626840, I noticed something. With the current runlevel system, it's easy to know what your options are. The systemd FAQ helpfully explains that systemctl isolate graphical.target is the replacement, and that systemctl list-units --type=target will show me the various possibilities. But it's very difficult to know which of these _might be a good idea_ to use as the target for systemctl isolate. I'm not sure what'll happen if I say systemctl isolate getty.target -- will I get a nice console-mode environment, or will I be stuck with only gettys running? I can generate pretty 'dot' output to find the answer to my question, but I don't think that's the general-case solution. :) (As another note: I suggest renaming isolate to switch-to, which I think captures the meaning better.) Maybe good documentation is the answer here, but it's definitely a quirk of the system. Is there some way in which complete working runlevel targets are distinguished from other ones which I am missing? Thanks! -- Matthew Miller mat...@mattdm.org Senior Systems Architect -- Instructional Research Computing Services Harvard School of Engineering Applied Sciences -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: drop default MTA for Fedora 15
Andrew Haley a...@redhat.com wrote:
On 08/24/2010 02:58 PM, Michael Cronenworth wrote:
Chris Adams wrote:
What do we gain by not having any MTA installed (other than a little bit
of disk space)? I understand that a little bit of disk space can add
up quick, but a local queueing MTA is a pretty standard part of a Unix
system.
Why are you complaining? If your package needs an MTA - put in a Requires!
Not everything that runs on Fedora is a Fedora package: people run
their own programs, too. Some things, like the existence of /bin/ls
or being able to send mail by piping the message to either /bin/mail
or /usr/{sbin,lib}/sendmail are basic features of UNIX.
Isn't that what the lsb packages are for? I you want a traditional base,
install the group for it.
--
Sent from my Android phone. Please excuse my brevity.
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: drop default MTA for Fedora 15
On Tue, Aug 24, 2010 at 03:43:36PM +0100, Matthew Garrett wrote: The problem with delivering this to a user's mailbox via an MTA is that in the typical case it doesn't result in the user noticing anything until they've logged in as root and find out that the you have new mail message actually means Your RAID is fucked and not just Here's In the typical case users do not use RAID. And how does this change with the new not MTA feauture? And in case a RAID is used, how is the user notified when the RAID is broken? Regards Till pgp7CrDISWMV2.pgp Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Packages on which Thunderbird functionality depends!
Stephen Gallagher (sgall...@redhat.com) said: I'm not a Thunderbird maintainer, so I don't know how feasible this is, but perhaps we could create a subpackage like 'thunderbird-sound-support' that has the appropriate dependencies on it. Then at least someone doing a yum search on thunderbird would notice that and assume they probably wanted it (if they're hitting the same issue). Just changing the package requires seems far simpler to me. Bill -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: drop default MTA for Fedora 15
On Tue, Aug 24, 2010 at 5:37 PM, Till Maas opensou...@till.name wrote: On Tue, Aug 24, 2010 at 03:43:36PM +0100, Matthew Garrett wrote: The problem with delivering this to a user's mailbox via an MTA is that in the typical case it doesn't result in the user noticing anything until they've logged in as root and find out that the you have new mail message actually means Your RAID is fucked and not just Here's In the typical case users do not use RAID. And how does this change with the new not MTA feauture? And in case a RAID is used, how is the user notified when the RAID is broken? How are they notified now? By default the local mta delivers everything to root because there's no way to know what user is going to exisit. How many people check the local root users mail. So for desktop it should be a notification to the screen, for a server it would need to be configured anyway for smart relay hosts and real users to send it to. So its currently broken as it standard. This change is not going to make that any better or worse. Peter -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: drop default MTA for Fedora 15
On Tue, Aug 24, 2010 at 3:19 PM, Jon Masters jonat...@jonmasters.org wrote: On Tue, 2010-08-24 at 10:09 -0400, Matthew Miller wrote: On Tue, Aug 24, 2010 at 08:58:50AM -0500, Michael Cronenworth wrote: Why are you complaining? If your package needs an MTA - put in a Requires! If we follow the general state of things: if a package might need something, toss it in as a requires!, this will totally defeat the purpose of the comps change, since it will get pulled in by something important at some point. Rsyslog, for example, can send output via e-mail. Having a very simple mail-queue-and-relay program as an alternative to sendmail seems like a better choice than just ditching it. My previous objection was based on the precedent it sets. I don't want a Desktop distribution in Fedora. I want a server-usable distribution. Sure, it's just a dep and one can go install an MTA. But today it's killing the MTA, tomorrow it's removing something else that's useful on the server side of things. I want to see that trend stop and reverse. Its NOT killing the MTA. In most cases you won't see any difference. Its removing the mandatory option in the comps. There are dozens of packages that depend on /usr/bin/sendmail and they will install a MTA as a dependency. Peter -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: drop default MTA for Fedora 15
On Tue, Aug 24, 2010 at 3:09 PM, Matthew Miller mat...@mattdm.org wrote: On Tue, Aug 24, 2010 at 08:58:50AM -0500, Michael Cronenworth wrote: Why are you complaining? If your package needs an MTA - put in a Requires! If we follow the general state of things: if a package might need something, toss it in as a requires!, this will totally defeat the purpose of the comps change, since it will get pulled in by something important at some point. Rsyslog, for example, can send output via e-mail. yes, but in the case that something needs it such as logwatch it will automatically install an MTA as part of the dependencies. So just because its not there by default doesn't mean that it won't necessarily be installed. It just means that for a minimal install or possibly a desktop spin if there's not a dependency on it it won't unnecessarily get installed. Peter -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: systemd and changes
On Mon, 2010-08-23 at 15:52 -0500, Mike McGrath wrote: It's just risk management. I think we'd be better off acknowledging there are unknown unknowns and try to mitigate them. One way we could have done that this time around was making it an optional feature (as Matt was mentioning in a previous email) for F14 and then decide in F15 if it was ready. Unfortunately that's not the path we seem to be on. We unwisely seemed to declare it ready before anyone even saw it then we ignored what we didn't know as if we knew there were going to be no problems. The sad thing is that's such an easy fix by making brand new features for core components like this opt in, even if it's just for a single release. Well, ironically enough, Lennart's last big revolution illustrates the problem with that. PulseAudio - previously PolypAudio, remember - was 'opt-in' for several releases; it was packaged in Fedora and many other major distributions, you could enable it just by installing it. It was used by approximately no-one. People just don't opt in to big bits of infrastructural change unless they have some very specific reason to do so; booting the system more or less works for most people, so why would they 'opt in' to a new init daemon? -- 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: systemd and changes
Adam Williamson wrote: On Mon, 2010-08-23 at 15:52 -0500, Mike McGrath wrote: It's just risk management. I think we'd be better off acknowledging there are unknown unknowns and try to mitigate them. One way we could have done that this time around was making it an optional feature (as Matt was mentioning in a previous email) for F14 and then decide in F15 if it was ready. Unfortunately that's not the path we seem to be on. We unwisely seemed to declare it ready before anyone even saw it then we ignored what we didn't know as if we knew there were going to be no problems. The sad thing is that's such an easy fix by making brand new features for core components like this opt in, even if it's just for a single release. Well, ironically enough, Lennart's last big revolution illustrates the problem with that. PulseAudio - previously PolypAudio, remember - was 'opt-in' for several releases; it was packaged in Fedora and many other major distributions, you could enable it just by installing it. It was used by approximately no-one. People just don't opt in to big bits of infrastructural change unless they have some very specific reason to do so; booting the system more or less works for most people, so why would they 'opt in' to a new init daemon? If it's worth the revolution, wouldn't people choose to opt in? If nobody ever opts in, perhaps it's not worth the revolution? Just a thought ;) -Eric -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Bodhi updates
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 8/24/10 9:45 AM, Bill Nottingham wrote: Stephen Gallagher (sgall...@redhat.com) said: Bodhi updates can have multiple packages associated with a single update as long as they are on different branches. Why this restriction? At least in the case of something like a security update, I would think that it would be beneficial to be able to push the update to all branches simultaneously. The push process is not atomic across branches... you can, for, example, as a releng member only push dist-f13-updates-testing. Bill Nor is testing / stability atomic / equal across the branches. While the f13 package may work fine, the f12 build may have severe problems. They need to be treated individually. - -- Jesse Keating Fedora -- Freedom² is a feature! identi.ca: http://identi.ca/jkeating -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkxz+0UACgkQ4v2HLvE71NUueQCfe6+5Z2RYYOlvXY5hcDCv308Y 1yIAoKY4CAZL639daI2Wg/8Y69SxehDy =c/z+ -END PGP SIGNATURE- -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F-14 Branched report: 20100824 changes
On Tue, Aug 24, 2010 at 04:42:17PM +, Branched Report wrote: 1:libguestfs-1.5.2-4.fc14.i686 requires /lib/libxtables.so.4 This seems to be a warning about an older version than what's currently in F14: http://koji.fedoraproject.org/koji/buildinfo?buildID=190165 https://admin.fedoraproject.org/updates/libguestfs-1.5.2-7.fc14 Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones virt-top is 'top' for virtual machines. Tiny program with many powerful monitoring features, net stats, disk stats, logging, etc. http://et.redhat.com/~rjones/virt-top -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: systemd and changes
On Tue, 24 Aug 2010, Eric Sandeen wrote: Adam Williamson wrote: On Mon, 2010-08-23 at 15:52 -0500, Mike McGrath wrote: It's just risk management. I think we'd be better off acknowledging there are unknown unknowns and try to mitigate them. One way we could have done that this time around was making it an optional feature (as Matt was mentioning in a previous email) for F14 and then decide in F15 if it was ready. Unfortunately that's not the path we seem to be on. We unwisely seemed to declare it ready before anyone even saw it then we ignored what we didn't know as if we knew there were going to be no problems. The sad thing is that's such an easy fix by making brand new features for core components like this opt in, even if it's just for a single release. Well, ironically enough, Lennart's last big revolution illustrates the problem with that. PulseAudio - previously PolypAudio, remember - was 'opt-in' for several releases; it was packaged in Fedora and many other major distributions, you could enable it just by installing it. It was used by approximately no-one. People just don't opt in to big bits of infrastructural change unless they have some very specific reason to do so; booting the system more or less works for most people, so why would they 'opt in' to a new init daemon? If it's worth the revolution, wouldn't people choose to opt in? If nobody ever opts in, perhaps it's not worth the revolution? Just a thought ;) People like you and me would opt-in. (well I would on some hosts) because we know what we're doing. Expert eyes get a look at it before it's forced onto our users, who are already leaving in leaps and bounds. -Mike -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: systemd acceptance, packaging guidelines (was Re: systemd and changes)
On Tue, 2010-08-24 at 11:15 -0400, Matthew Miller wrote: On Tue, Aug 24, 2010 at 08:45:33AM -0400, Matthias Clasen wrote: GENERAL SANITY - Booting a system shall achieve a similar result as booting in upstart: -- The same set of services will be started. I don't think this is a requirement on systemd, really. If we make changes to the default system configuration to not include a service in F14 that was included in F13, that is not a systemd problem. So, I think what you really mean here is: systemd will start all services that are configured to be included in the default install (and dependencies), but no others. If we're still including upstart as a fallback option, I think it's The intent is not to do so in the final release, AIUI. We're only keeping it around during pre-release, so that if we decide we need to fall back to upstart for final release, it's easy to do. As far as I know, the plan is to decide later (presumably after beta) which one we're going with, and dump the other. -- 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: systemd acceptance, packaging guidelines (was Re: systemd and changes)
On Tue, 24 Aug 2010, Adam Williamson wrote: On Tue, 2010-08-24 at 11:15 -0400, Matthew Miller wrote: On Tue, Aug 24, 2010 at 08:45:33AM -0400, Matthias Clasen wrote: GENERAL SANITY - Booting a system shall achieve a similar result as booting in upstart: -- The same set of services will be started. I don't think this is a requirement on systemd, really. If we make changes to the default system configuration to not include a service in F14 that was included in F13, that is not a systemd problem. So, I think what you really mean here is: systemd will start all services that are configured to be included in the default install (and dependencies), but no others. If we're still including upstart as a fallback option, I think it's The intent is not to do so in the final release, AIUI. We're only keeping it around during pre-release, so that if we decide we need to fall back to upstart for final release, it's easy to do. As far as I know, the plan is to decide later (presumably after beta) which one we're going with, and dump the other. So the alpha and beta will be tested in a configuration that the final release will not? -Mike -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: systemd and changes
On Tue, 2010-08-24 at 12:02 -0500, Eric Sandeen wrote: Well, ironically enough, Lennart's last big revolution illustrates the problem with that. PulseAudio - previously PolypAudio, remember - was 'opt-in' for several releases; it was packaged in Fedora and many other major distributions, you could enable it just by installing it. It was used by approximately no-one. People just don't opt in to big bits of infrastructural change unless they have some very specific reason to do so; booting the system more or less works for most people, so why would they 'opt in' to a new init daemon? If it's worth the revolution, wouldn't people choose to opt in? If nobody ever opts in, perhaps it's not worth the revolution? No, not really, for a couple of reasons. One, consider the sets of people involved. systemd opens up interesting possibilities for operating system creators (that's us) and possibly sysadmins. Neither of those groups is very large, and certainly both pale in comparison to the total number of people who will ultimately be *affected*, if only passively, by the change (which includes both the above groups, plus all other users). Even for operating system creators and sysadmins, there's factors to inhibit switching as long as it's just an optional alternative. We can't build anything into Fedora that relies on systemd unless it's the default, obviously. And sysadmins are generally fairly conservative beasts (that's the point some of them are whaling on here on this list) who prefer to change as little as possible about a working system. I'd say it's generally true that, if you get people using Foobar 1.0, then branch out and offer Foobar 1.x and Foobar 2.x where 1.x is just maintenance for 1.0 and 2.x has all the shiny new features but some adjustment shock, people will look at 2.x briefly, think 'ow, it's different!' and just carry on using 1.x. If you take away 1.x and only offer 2.x they will migrate to it, whine for a week about what's different, then quickly forget about it and start realizing the changes offer them something neat and useful. Not saying it's a foregone conclusion that that's how it'll go with systemd, but I think it's worth considering. -- 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: systemd and changes
On Tue, 2010-08-24 at 12:10 -0500, Mike McGrath wrote: People like you and me would opt-in. (well I would on some hosts) because we know what we're doing. Expert eyes get a look at it before it's forced onto our users, who are already leaving in leaps and bounds. Again, Pulse/PolypAudio seems to suggest that this is not the case. Why didn't expert eyes who knew what they were doing migrate to that before it become default? Or, alternatively, if the expert eyes which knew what they were doing did migrate, why didn't they catch the bugs that others encountered when it became default? -- 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: Bodhi updates
Stephen Gallagher (sgall...@redhat.com) said: Bodhi updates can have multiple packages associated with a single update as long as they are on different branches. Why this restriction? At least in the case of something like a security update, I would think that it would be beneficial to be able to push the update to all branches simultaneously. The push process is not atomic across branches... you can, for, example, as a releng member only push dist-f13-updates-testing. Bill -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
[Bug 626920] New: [abrt] crash in perl-Padre-0.32-2.fc12: wxStyledTextCtrl::SendMsg: Process /usr/bin/perl was killed by signal 11 (SIGSEGV)
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug. Summary: [abrt] crash in perl-Padre-0.32-2.fc12: wxStyledTextCtrl::SendMsg: Process /usr/bin/perl was killed by signal 11 (SIGSEGV) https://bugzilla.redhat.com/show_bug.cgi?id=626920 Summary: [abrt] crash in perl-Padre-0.32-2.fc12: wxStyledTextCtrl::SendMsg: Process /usr/bin/perl was killed by signal 11 (SIGSEGV) Product: Fedora Version: 12 Platform: i686 OS/Version: Linux Status: NEW Status Whiteboard: abrt_hash:5d7988fcae0c432f77545581c126f5d9ad6fd0fd Severity: medium Priority: low Component: perl-Padre AssignedTo: mmasl...@redhat.com ReportedBy: mact...@webdragon.net QAContact: extras...@fedoraproject.org CC: fedora-perl-devel-l...@redhat.com, mmasl...@redhat.com Classification: Fedora abrt 1.1.1 detected a crash. architecture: i686 Attached file: backtrace cmdline: /usr/bin/perl /usr/bin/padre comment: basically working with the new module creation tool, but had not yet edited any of the files. opened a few to inspect the contents and while closing them out to get back to the main module, padre crashed with the info supplied here. Hopefully this information is useful to the developers. component: perl-Padre crash_function: wxStyledTextCtrl::SendMsg executable: /usr/bin/perl global_uuid: 5d7988fcae0c432f77545581c126f5d9ad6fd0fd kernel: 2.6.32.19-163.fc12.i686.PAE package: perl-Padre-0.32-2.fc12 rating: 4 reason: Process /usr/bin/perl was killed by signal 11 (SIGSEGV) release: Fedora release 12 (Constantine) How to reproduce - 1. created a new Project in padre using New Perl Distrubution (Module::Starter) 2. opened a few windows on the various files created 3. clicked the close box in the _toolbar_ (not the tabs) several times in succession to close the various open windows -- 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: systemd acceptance, packaging guidelines (was Re: systemd and changes)
Matthew Miller (mat...@mattdm.org) said: How about: - If /etc/inittab exists and contains an initdefault line, the default target will be set accordingly. - any other non-comment, non-blank lines in /etc/inittab will be logged as warnings. This leaves a migration path (ditch the file completely) while maintaining some backwards compatibility. For a number of releases, the file can continue to exist with a warning in the comments and the release notes, and then eventually it can go away. As stated in the bug, this would lead to a situation where you could have both a initdefault line, and a default.target symlnk, that select different things. How would you arbitrate? Bill -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: systemd acceptance, packaging guidelines (was Re: systemd and changes)
On Mon, 2010-08-23 at 23:06 -0400, Bill Nottingham wrote: This, however, is just packaging guidelines. From readng the thread, there are many things that I think people would like covered with systemd before they would feel comfortable with it. So, I'm going to attempt to quantify what would need to be tested and verified. This document focuses on backwards compatibility. THIS IS GOING TO BE VERY VERBOSE. Comments, changes, etc. welcome. This looks great, and I'd definitely like to use it as the basis for the systemd test day. Once comments and so on are in, could you post a 'version 2.0'? Thanks! -- 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: Fedora Notifications System.
On Mon, Aug 23, 2010 at 11:19 PM, Jon Masters jonat...@jonmasters.orgwrote: On Mon, 2010-08-23 at 11:54 -0400, Genes MailLists wrote: Whatever we do please make it an option NOT to have any window splat on the screen anywhere - let it stay in the system tray and not interfere with my work. It gets worse. I frequently come back to a desktop on which my girlfriend is logged in, switch users, and there are a load of popup notifications on the suspended session. Or the other way around. At this point, I generally uninstall software (including update software - I have a nice and growing list of exclude entries in my yum config) that annoys me with popups that I can't permanently disable. Jon. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel that was one of the issues i wants opinions about i. in fact, i would like to create a small config application that allows the user to manage when to check when to announce the notifications. i would like to know your opinions about this application so i can create the one size fits all notifications system. -- Regards,, Mahmoud Abdul Jawad @meGenius -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Git question
On Tue, 24 Aug 2010, Steve Dickson wrote: On 08/24/2010 10:46 AM, M A Young wrote: On Tue, 24 Aug 2010, Steve Dickson wrote: Also, the kernel that is currently being built from my pnfs-13 branch fails to install with the following error: FATAL: Could not load /lib/modules/2.6.34.5-43.pnfs_all_2.6.35_2010_08_19.fc13.x86_64-pnfs/modules.dep: No such file or directory The extra -pnfs on the 2.6.34.5-43... directory name is the problem. It probably has something to do with how I changed the buildid: I suspect it has nothing to do with the buildid (I use one and don't have the problem). I would check the kernel version file in the source (I don't know offhand what it is called) and see if -pnfs is added there. If it is add a patch to remove it. Does anybody know the name of the file Michael is talking about? I was misremembering a bit. What may be adding that extra bit is any file in the base of the kernel tree of the form localversion* which get sucked in by the base level Makefile. Michael Young -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
