me-tv orphaned
Dear list, I just asked Zarko Pintar (grof) if he still maintains me-tv (application to watch dvb-t tv). He tells me that he is not. Could someone pick it up, please? Thanks! Stefan Grosse http://koji.fedoraproject.org/koji/packageinfo?packageID=8486 From: Zarko Pintar zarko.pin...@... To: Stefan Grossestefan.gro...@... Sorry, but no, I am not! And I do not know who care about this package now regards, Zarko On Wed, May 26, 2010 at 11:46 PM, Stefan Grosse stefan.gro...@... wrote: Hi Zarko, are you still maintaining me-tv on Fedora? There have been several updates (current is 1.2.4 but in Fedora latest is 1.1.6) of that program. Would you mind to start a new build? -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: me-tv orphaned
2010/5/27 Stefan Grosse singularit...@gmx.net: Dear list, I just asked Zarko Pintar (grof) if he still maintains me-tv (application to watch dvb-t tv). He tells me that he is not. Could someone pick it up, please? Thanks! Stefan Grosse http://koji.fedoraproject.org/koji/packageinfo?packageID=8486 From: Zarko Pintar zarko.pin...@... To: Stefan Grossestefan.gro...@... Sorry, but no, I am not! And I do not know who care about this package now regards, Zarko On Wed, May 26, 2010 at 11:46 PM, Stefan Grosse stefan.gro...@... wrote: Hi Zarko, are you still maintaining me-tv on Fedora? There have been several updates (current is 1.2.4 but in Fedora latest is 1.1.6) of that program. Would you mind to start a new build? -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel You should ask his to orphan it on pkgdb, then others can take this package and make an update. https://admin.fedoraproject.org/pkgdb/acls/name/me-tv Regards, Chen Lei -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: systemd (Was Re: tmpfs for strategic directories)
drago01 wrote: Well spawing your logic further means we should avoid compiled programs at all, what if I want configure $app by editing its source code? Oh wait it is written in C ... If it goes down to want to edit scripts for configuration reasons (which isn't sane anyway) compared to a faster an cleaner boot process I'd opt for the later. Seriously source code is NOT and never was intended to be a configuration system period. It's a great advantage to have non-compiled programs on the system which can be edited: - Debugging packaged python programs - Customizing user interfaces - Understanding logic and parameters That's speaking as a developer and someone who does some sysadmin work. The overhead of a simple scripting language like Lua, awk, Python or Perl is minimal compared to the fork cost. You won't notice the difference between a Lua startup script and a C one. Jeremy -- http://jeremysanders.net/ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: systemd (Was Re: tmpfs for strategic directories)
Bill Nottingham wrote: Jeremy Sanders (jer...@jeremysanders.net) said: Something like Lua would be very good. The overheads over C would be minimal, and it would have the advantage of being editable. I've had to edit an init script to get something working properly many times. If you're going to want them to be editable to pass the lowest-common-denominator test of whatever admins might be editing them, I think bash is probably the only reasonable choice. Perhaps, though C is completely non editable to many sysadmins and lacks easy to use builtin routines helpful in scripting (maps, lists, tuples, string manipulation). At least a simple Lua script should be comprehensible to the average sysadmin in case they need to debug or trace something, even if they never write anything. Jeremy -- http://jeremysanders.net/ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: systemd (Was Re: tmpfs for strategic directories)
drago01 wrote: I beg to differ. I've had to create or modify initscripts quite often, either as a sysadmin or a packager. Again the sysadmin case just implies that something *else* is broken. Well if changing over to C does only get rid of this disease it would be enough of a gain. It would force broken apps to be fixed, and let admins edit *configuration* files and not source code. What rubbish. For instance, we customised an early Fedora to work on a diskless NFS rooted system, mainly by mucking around with init scripts. Being able to easily edit these files made this project work and work quickly. Trying to get upstream to special case our particular setup wouldn't have happened. You're suggesting hammering shut the insides of linux to stop people playing around and reducing freedom - sounds like you want Fedora to be like the products of other large propitiatory systems. There is a clear case for having an open and completely configurable system. It's not going to cost 1 sec of bootup either. Jeremy -- http://jeremysanders.net/ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: systemd (Was Re: tmpfs for strategic directories)
On 05/26/2010 02:54 PM, Seth Vidal wrote: On Wed, 26 May 2010, Simo Sorce wrote: While you don't edit them *all* the time, it is something that is done regularly, and it is something most admins can do with ease. Turn them in a C program and you left admins out in the cold, most of them. I would be very, very wary of accepting a C init script. An unmanageable system is a useless system. +20 million. I couldn't agree more. They need to be scripts, considering how seldom they actually run it makes even less sense to chase down optimization in them by making them compiled. -sv We mainly speek about rc.sysinit, which most of you don't touch, because it would be overwritten the next initscripts update anyway. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: systemd (Was Re: tmpfs for strategic directories)
On 05/26/2010 06:07 PM, Adam Williamson wrote: On Wed, 2010-05-26 at 12:42 +0200, drago01 wrote: On Wed, May 26, 2010 at 5:02 AM, Casey Dahlincdah...@redhat.com wrote: On Tue, May 25, 2010 at 05:45:07PM +0200, Lennart Poettering wrote: On Tue, 25.05.10 10:21, Casey Dahlin (cdah...@redhat.com) wrote: [...] 3) Cutting down on the forking by replacing some of the shell scripts... cool 3a) With C code... really? This does make a lot of sense to me, initscripts being scripts is a major slowdown factor by itself. It is not like you want to edit the scripts all the time, so there is no reason for them being scripts. I beg to differ. I've had to create or modify initscripts quite often, either as a sysadmin or a packager. If this is now going to require C coding skills, I'm not going to be able to do it. I don't think it's safe to assume that everyone who needs to write or modify an initscript is going to know C. What about people who write apps that need initscripts in some other language? unless you want rc.sysinit changes, you would have no problem with systemd to modify the system to your needs -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Orphaning most of my packages
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hello, as there is no more use for most of my packages at work anymore I don't find the time to adequately take care of them. Please show your love by adopting one or the other: php-channel-phing -- Adds phing channel to PEAR php-channel-phpdb -- Adds phpdb channel to PEAR php-channel-symfony -- Adds symfony project channel to PEAR php-pear-creole -- A database abstraction layer for PHP5 php-pear-pake -- PHP5 project builder system php-pear-phing -- A project build system based on Apache Ant php-pear-propel_generator -- An ORM framework for PHP5 - generator component php-pear-propel_runtime -- An ORM framework for PHP5 - runtime component Thank you Alex - -- Alexander Kahl GNU/Linux Software Developer -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.14 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/ iEYEARECAAYFAkv+OKkACgkQVTRddCFHw13DiQCg1Aopna/2lsU7p/+jLyk3B5FH tQoAoNrQy/3heb4n7NheRXBU28Vl64Wv =Amay -END PGP SIGNATURE- -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: fc12 in F13
On 05/27/2010 04:23 PM, Frank Murphy wrote: They seem to play well together. If it's not broken, no need to fix it. You might want to run package-clean --dupes yum list extras and yum check to verify if things are ok. Rahul -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Privilege escalation policy and desktop_admin_r
I have a question about how our privilege escalation policy interacts with the desktop_admin_r group. Is a member user of desktop_admin_r considered an unprivileged user? Tim. */ 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: systemd (Was Re: tmpfs for strategic directories)
On Thu, May 27, 2010 at 10:10:35AM +0200, Harald Hoyer wrote: We mainly speek about rc.sysinit, which most of you don't touch, because it would be overwritten the next initscripts update anyway. I would never touch it with a permanent change, but I definitely make debugging changes to it often enough. That's not down to it being a shell script though; it's because it's a crufty mess. -- 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: Orphaning email2trac
On Mon, May 17, 2010 at 5:31 PM, Jesse Keating jkeat...@redhat.com wrote: This was a failed experiment with fedora hosted, and I no longer need to manage this package. If anybody wants it, it's now an orphan in pkgdb. I've taken over for now, since I submitted a few patches for it upstream in the past few weeks. Regards, -- McGill University IT Security Konstantin Kay Ryabitsev Montréal, Québec -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: gcc 4.4 vs. 4.5 (was: Re: rawhide report: 20100526 changes)
On Wed, May 26, 2010 at 11:53 PM, Kevin Kofler kevin.kof...@chello.at wrote: Rawhide Report wrote: gcc-4.4.4-5.fc14 * Tue May 25 2010 Jakub Jelinek ja...@redhat.com 4.4.4-5 - update from gcc-4_4-branch Can we get 4.5 for F14? +1. Would be nice to test LLVM's new dragonegg compiler back-end once 4.5 lands in Rawhide. -- Michel Alexandre Salim Fedora Project Contributor: http://fedoraproject.org/ Email: sali...@fedoraproject.org | GPG key ID: 78884778 Jabber: hir...@jabber.ccc.de | IRC: hir...@irc.freenode.net () ascii ribbon campaign - against html e-mail /\ www.asciiribbon.org - against proprietary attachments -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
rawhide report: 20100527 changes
Compose started at Thu May 27 08:15:04 UTC 2010 Broken deps for i386 -- almanah-0.7.3-1.fc14.i686 requires libedataserver-1.2.so.12 1:anjuta-2.30.0.0-2.fc14.i686 requires libgladeui-1.so.9 dates-0.4.11-3.fc14.i686 requires libedataserver-1.2.so.11 deskbar-applet-2.30.0-1.1.fc14.i686 requires libedataserver-1.2.so.12 empathy-2.31.1-1.fc14.i686 requires libedataserver-1.2.so.12 giggle-0.5-1.fc14.i686 requires libedataserver-1.2.so.12 gnome-launch-box-0.4-17.fc14.i686 requires libedataserver-1.2.so.12 gnome-panel-2.30.0-2.fc14.i686 requires libedataserver-1.2.so.12 gnome-phone-manager-0.65-5.fc12.i686 requires libedataserver-1.2.so.11 gnome-phone-manager-telepathy-0.65-5.fc12.i686 requires libedataserver-1.2.so.11 gnome-python2-evolution-2.30.0-5.fc14.i686 requires libedataserver-1.2.so.12 kdebase-workspace-python-applet-4.4.80-2.fc14.i686 requires PyKDE4 = 0:4.4.80 kobby-1.0-0.3.b4.fc13.i686 requires libinfinity-0.3.so.0 kobby-1.0-0.3.b4.fc13.i686 requires libinftext-0.3.so.0 libqinfinity-1.0-0.2.b4.fc13.i686 requires libinfinity-0.3.so.0 libqinfinity-1.0-0.2.b4.fc13.i686 requires libinftext-0.3.so.0 plexus-containers-component-annotations-javadoc-1.0-0.1.a34.7.fc12.noarch requires jakarta-commons-logging-javadoc qtgpsc-0.2.3-6.fc12.i686 requires libgps.so.18 rubygem-right_aws-1.10.0-3.fc14.noarch requires rubygem(right-http_connection) = 0:1.2.4 syncevolution-1.0beta3-2.fc14.i686 requires libedataserver-1.2.so.12 tasks-0.16-3.fc14.i686 requires libedataserver-1.2.so.12 tracker-evolution-plugin-0.8.5-1.fc14.i686 requires libcamel-provider-1.2.so.15 tracker-evolution-plugin-0.8.5-1.fc14.i686 requires libcamel-1.2.so.15 tracker-evolution-plugin-0.8.5-1.fc14.i686 requires libedataserver-1.2.so.12 vfrnav-0.4-1.fc13.i686 requires libgps.so.18 vifir-0.4-2.fc14.i686 requires libgps.so.18 viking-0.9.91-3.fc13.i686 requires libgps.so.18 Broken deps for x86_64 -- almanah-0.7.3-1.fc14.x86_64 requires libedataserver-1.2.so.12()(64bit) 1:anjuta-2.30.0.0-2.fc14.i686 requires libgladeui-1.so.9 1:anjuta-2.30.0.0-2.fc14.x86_64 requires libgladeui-1.so.9()(64bit) dates-0.4.11-3.fc14.x86_64 requires libedataserver-1.2.so.11()(64bit) deskbar-applet-2.30.0-1.1.fc14.x86_64 requires libedataserver-1.2.so.12()(64bit) empathy-2.31.1-1.fc14.x86_64 requires libedataserver-1.2.so.12()(64bit) giggle-0.5-1.fc14.i686 requires libedataserver-1.2.so.12 giggle-0.5-1.fc14.x86_64 requires libedataserver-1.2.so.12()(64bit) gnome-launch-box-0.4-17.fc14.x86_64 requires libedataserver-1.2.so.12()(64bit) gnome-panel-2.30.0-2.fc14.x86_64 requires libedataserver-1.2.so.12()(64bit) gnome-phone-manager-0.65-5.fc12.x86_64 requires libedataserver-1.2.so.11()(64bit) gnome-phone-manager-telepathy-0.65-5.fc12.x86_64 requires libedataserver-1.2.so.11()(64bit) gnome-python2-evolution-2.30.0-5.fc14.x86_64 requires libedataserver-1.2.so.12()(64bit) kdebase-workspace-python-applet-4.4.80-2.fc14.x86_64 requires PyKDE4 = 0:4.4.80 kobby-1.0-0.3.b4.fc13.x86_64 requires libinfinity-0.3.so.0()(64bit) kobby-1.0-0.3.b4.fc13.x86_64 requires libinftext-0.3.so.0()(64bit) libqinfinity-1.0-0.2.b4.fc13.i686 requires libinfinity-0.3.so.0 libqinfinity-1.0-0.2.b4.fc13.i686 requires libinftext-0.3.so.0 libqinfinity-1.0-0.2.b4.fc13.x86_64 requires libinfinity-0.3.so.0()(64bit) libqinfinity-1.0-0.2.b4.fc13.x86_64 requires libinftext-0.3.so.0()(64bit) plexus-containers-component-annotations-javadoc-1.0-0.1.a34.7.fc12.noarch requires jakarta-commons-logging-javadoc qtgpsc-0.2.3-6.fc12.x86_64 requires libgps.so.18()(64bit) rubygem-right_aws-1.10.0-3.fc14.noarch requires rubygem(right-http_connection) = 0:1.2.4 syncevolution-1.0beta3-2.fc14.i686 requires libedataserver-1.2.so.12 syncevolution-1.0beta3-2.fc14.x86_64 requires libedataserver-1.2.so.12()(64bit) tasks-0.16-3.fc14.x86_64 requires libedataserver-1.2.so.12()(64bit) tracker-evolution-plugin-0.8.5-1.fc14.x86_64 requires libcamel-provider-1.2.so.15()(64bit) tracker-evolution-plugin-0.8.5-1.fc14.x86_64 requires libedataserver-1.2.so.12()(64bit) tracker-evolution-plugin-0.8.5-1.fc14.x86_64 requires libcamel-1.2.so.15()(64bit) vfrnav-0.4-1.fc13.x86_64 requires libgps.so.18()(64bit) vifir-0.4-2.fc14.x86_64 requires libgps.so.18()(64bit) viking-0.9.91-3.fc13.x86_64 requires libgps.so.18()(64bit) New package apache-commons-beanutils Java utility methods for accessing and modifying the properties of arbitrary JavaBeans New
Re: Orphaning most of my packages
I will try to sort it out this evening. On Thu, May 27, 2010 at 14:46, Remi Collet colletr...@free.fr wrote: Le 27/05/2010 12:40, Christof Damian a écrit : I will take: - php-channel-symfony Great. Can you please ask for EL-6 for it ? (and ask for build) See https://bugzilla.redhat.com/show_bug.cgi?id=592528 regards. Remi. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: systemd (Was Re: tmpfs for strategic directories)
Chris Adams wrote: No, it isn't. It makes the process much more opaque to system administrators and makes it harder to make quick fixes and simple local changes. Editing the code is the wrong way to make simple local changes. If there isn't a measurable and significant speed improvement, it is definately a waste of time to replace working scripts. According to the explanations given elsewhere in the thread, the idea is to have much of the stuff done directly inside the init system instead of softcoding (cf. http://en.wikipedia.org/wiki/Softcoding, http://thedailywtf.com/Articles/Soft_Coding.aspx) it as scripts. Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: systemd (Was Re: tmpfs for strategic directories)
On Thu, May 27, 2010 at 03:14:54PM +0200, Kevin Kofler wrote: That's not down to it being a shell script though; it's because it's a crufty mess. … which is exactly why it should be handled inside the init system instead of being that mess of a shell script. :-) Maybe. That cruft is all there for a reason, and it'll take a lot of work to disentangle the good reasons from the ones that should be left behind. Putting it all in an opaque binary seems _less_ conducive to that rather than more. -- 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 (Was Re: tmpfs for strategic directories)
On Thu, May 27, 2010 at 9:56 AM, Jeremy Sanders jer...@jeremysanders.net wrote: drago01 wrote: [..] You're suggesting hammering shut the insides of linux to stop people playing around and reducing freedom - sounds like you want Fedora to be like the products of other large propitiatory systems. What? You can edit it anytime it is OPEN SOURCE ( you have the freedom to do whatever the OSS license used allows you *including* editing). Configuration is not supposed to be done by editing code. The whole C vs. bash aside, even editing bash scripts which are part of the system for _configuration_ reasons is *wrong*. Separating source code and configuration is just well designed software not non free software. Anyway I am done with this discussion. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Privilege escalation policy and desktop_admin_r
On Thu, 2010-05-27 at 12:01 +0100, Tim Waugh wrote: I have a question about how our privilege escalation policy interacts with the desktop_admin_r group. Is a member user of desktop_admin_r considered an unprivileged user? No, he or she is considered privileged. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Remove 1507 Package(s) ?
On 26 May 2010 14:06, Seth Vidal skvi...@fedoraproject.org wrote: On Wed, 26 May 2010, Tomasz Torcz wrote: On Wed, May 26, 2010 at 10:58:29AM +0100, Frank Murphy wrote: ... nss-softokn-freebl-3.12.6-1.2.fc11.x86_64 my version is currently at: nss-softokn-freebl-3.12.4-19.fc12.i686 on a fully updated F13 box. That's look like a problem betwee F11 and F12: % rpmdev-vercmp nss-softokn-freebl-3.12.6-1.2.fc11.x86_64 nss-softokn-freebl-3.12.4-19.fc12.i686 0:nss-softokn-freebl-3.12.6-1.2.fc11.x86_64 is newer .6 .4 you're absolutely right. Try doing a yum downgrade to the nss-softokn-freebl in f13. And then file a bug on it. I've just seen exactly the same thing with a system going from F12 to F13 with preupgrade. BZ filed here: https://bugzilla.redhat.com/show_bug.cgi?id=596840 As Seth suggested, this resolved the issue for me: yum downgrade nss-softokn-freebl nss-softokn I wonder if it should be added to the common problems wiki page. J. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: fc12 in F13
On Thu, 2010-05-27 at 08:26 -0700, Adam Williamson wrote: In the cases where you have an fc12 package and there is no fc13 package, though, that's not necessarily any kind of problem, it just means the package wasn't rebuilt for F13, or if it was, the rebuild failed. The rebuild failing would be something we'd want to fix over time, but if the fc12 package works, there's no intrinsic problem here for a user to worry about. There are two cases to distinguish. Packages with the fc12 dist tag that are also in F13, such as zlib-1.2.3-23.fc12 (https://koji.fedoraproject.org/koji/buildinfo?buildID=124463), are fine. Packages that are not in F13, such as gdevilspie, will appear in package-cleanup --orphans output and should be considered unsupported if one chooses to leave them installed. -- Matt -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Privilege escalation policy and desktop_admin_r
On Thu, 2010-05-27 at 08:23 -0700, Adam Williamson wrote: The relevant bit here is the last sentence, which was intended to cover the whole desktop_admin_r stuff. Let me know if it's factually off. Seeing as desktop_admin_r is actually part of the default spin, can we add some text which explicitly exempts users in that group from the privilege escalation policy? In other words, can we say something along the lines of it's fine for the default spin to ship policykit files allowing desktop_admin_r users to do stuff without passwords being required? Tim. */ 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: How this bug can come out of its dead-end? Any suggestions?!
The device can be automatically mounted. It can be checked by its label that is the original label released with the distro. I think that should exists a relation between packages and the repositories on a cached manner. If the repository is on a umounted device (USB, CD/DVD-ROM) and is not possible to find it on a online repository or does not exist a active Internet connection, should be prompted to the user to put / plug the device and a additional thread is on background checking if the device is mounted by label. A timeout should be used on check thread to does not put the PackageKit to sleep forever waiting the path to be mounted. Should exists a functionality to collect data from the repositories on media, giving the user the chance to put each DVD/CD on a scanning process that is stored on the yum / PackageKit database. Should exists a configuration option to try to search first on offline repositories giving the user the chance to try use the media before try to download packages from Internet. I think that with this the PackageKit is not the responsible to mount the media. Only ideas. Thank you. Best regards. On Mon, May 10, 2010 at 5:08 AM, Andrew Haley a...@redhat.com wrote: On 05/09/2010 02:28 PM, Frank Murphy wrote: On 09/05/10 13:34, Hedayat Vatankhah wrote: If you have not see this at all, I've seen this frequently. Fedora sucks in this area for many years. I've seen it, so whatever arguments you bring; I KNOW that this bug IS very important and should be fixed. Currently there are various threads, about what Fedora is targeted at, those questions as yet rmein without a proper answr. Excuse me, I'm looking for a solution, not for wiping the problem statement. The solution for a new user to Linux, give hime Ubuntu-LTS. When he knows some more, give him Fedora. This is a bad argument IMO. Many users are advanced in some areas, but not others. The whole idea that Fedora is a distro for advanced users therefore it should be hard to use is absurd. The ability to install packages from a DVD just as easily as from the repos would be useful to a great many. Andrew. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel -- ___ Allann J. O. Silva I received the fundamentals of my education in school, but that was not enough. My real education, the superstructure, the details, the true architecture, I got out of the public library. For an impoverished child whose family could not afford to buy books, the library was the open door to wonder and achievement, and I can never be sufficiently grateful that I had the wit to charge through that door and make the most of it. (from I. Asimov, 1994) -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: NVR email I just sent
On Thu, May 27, 2010 at 11:28:08AM -0700, John Reiser wrote: greater for f12: x86info (davej ) f12 = 1:x86info-1.25-1.45.fc12.src f13 = 1:x86info-1.25-1.44.fc13.src These are actually the same, (I did two commits in f12, and combined both when I updated f13). is it worth rebuilding just to get it off the list ? Yes. It seems kinda pointless to push an update when nothing changes at all. The _name_ changes, and that is important because the name has semantic meaning. ok, rebuilt, and update pushed out. thanks, Dave -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: banshee-1 hang during playing video overnight
On 27 May 2010 02:56, Luming Yu luming...@gmail.com wrote: On Wed, May 26, 2010 at 2:45 PM, Luming Yu luming...@gmail.com wrote: On Wed, May 26, 2010 at 11:48 AM, Rakesh Pandit rakesh.pan...@gmail.com wrote: On 26 May 2010 08:16, Luming Yu wrote: Hi there, I happen to see a banshee-1 hang after it was accidentally left repeatedly playing two videos (big-buck-bunny.ogv and kittens.ogv) overnight. Any insight and suggestions to the hang will be very appreciated. Please report it on bugzilla (if not already done) with all information and follow up with maintainer. https://bugzilla.redhat.com/show_bug.cgi?id=595997 Hmmm no responses ? Anyone knows what's going on from the back trace? Please let me know what you need to proceed further.. if nobody cares about it, please suggest me an alternative to banshee-1.. Please have patience, you only posted a day ago! Not every one reads the list everyday. (Especially if they are particularly fond of staying sane...) Please post follow ups in the bugzilla ticket as you were advised to above. -- Mat Booth -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Remove 1507 Package(s) ?
On Thu, 2010-05-27 at 17:27 +0100, Jonathan Underwood wrote: On 27 May 2010 16:43, Jonathan Underwood jonathan.underw...@gmail.com wrote: I've just seen exactly the same thing with a system going from F12 to F13 with preupgrade. BZ filed here: https://bugzilla.redhat.com/show_bug.cgi?id=596840 As Seth suggested, this resolved the issue for me: yum downgrade nss-softokn-freebl nss-softokn I wonder if it should be added to the common problems wiki page. Ugh. Actually I see this problem with a lot of packages where the F-12 nvr is greater than the F-13 version: While it's not good packaging, most of the time these bad versions don't cause any problems. If you want to get rid of them easily though, feel free to install the yum from rawhide and run distro-sync. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Board and FESCo Election results
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 The Fedora elections for the Fedora Project Board and the Fedora Engineering Steering Committee (FESCo) have concluded, and the results follow: The Board is electing 3 seats this cycle. A total of 229 ballots were cast, meaning a candidate could accumulate up to 1374 votes (229 * 6). The results for the Fedora Board election are as follows: name | # votes - --+- Tom Callaway (spot) |1001 Máirín Duffy (mizmo) | 978 Rex Dieter (rdieter) | 772 - --+- Stephen Smoogen (smooge) | 559 John McDonough (jjmcd) | 437 Larry Cafiero (lcafiero) | 430 Therefore, Tom Callaway, Máirín Duffy, and Rex Dieter are elected to the Board for a full two-release term. * * * FESCo is electing 5 seats this cycle. A total of 180 ballots were cast, meaning a candidate could accumulate up to 1260 votes (180 * 7). The results for the FESCo election are as follows: name | # votes - --+- Bill Nottingham (notting)| 937 Kevin Fenzi (kevin) | 749 Matthias Clasen (mclasen)| 681 Kyle McMartin (kyle) | 545 Steven M. Parrish (tuxbrewr) | 516 - --+- Bruno Wolff III (bruno) | 492 Justin M. Forbes (jforbes) | 460 Therefore, Bill Nottingham, Kevin Fenzi, Matthias Clasen, Kyle McMartin, and Steven M. Parrish are elected to FESCo for a full two-release term. * * * Congratulations to the winning candidates, and thank you to each of the nominees for running, and our volunteers and team members for their assistance. - -- Paul W. Frieldshttp://paul.frields.org/ gpg fingerprint: 3DA6 A0AC 6D58 FEC4 0233 5906 ACDB C937 BD11 3717 http://redhat.com/ - - - - http://pfrields.fedorapeople.org/ Where open source multiplies: http://opensource.com -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.14 (GNU/Linux) iD8DBQFL/nuQrNvJN70RNxcRAnU4AKDxQ2osyntcQGmh8BNZ+l+9bWsBwACgtUnQ 5jCCWRWT9tMiuyolChtzJLg= =xI7D -END PGP SIGNATURE- ___ devel-announce mailing list devel-announce@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel-announce
