Re: twinkle: Intent to retire
On Tue, Mar 12, 2013 at 08:36:57AM +0100, Jan Kratochvil wrote: On Tue, 12 Mar 2013 02:03:16 +0100, Jared K. Smith wrote: On Mon, Mar 11, 2013 at 7:02 PM, Richard W.M. Jones rjo...@redhat.com wrote: Has Fedora *ever* had a functional soft-phone? I ask this because I have tried many, and none of them *ever* worked [...] I've successfully used Twinkle for the last three or four years, Using SIP since 2005 as mostly the only phone and Twinkle was always the only one that worked, despite I tried many. I never wanted to use Twinkle due to its ugly GUI but Twinkle just always worked. I have switched from twinkle to linphone about one year ago, the reason were the crash on twinkle. linphone just works in my experience. Of course I have used ekiga in the past but it wasn't too happy with Cicso hardware. If we loose twinkle we will still have those two, Daniel -- Daniel Veillard | Open Source and Standards, Red Hat veill...@redhat.com | libxml Gnome XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | virtualization library http://libvirt.org/ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [Call to Arms] Fedora 19 Test Days starts this week
On Ter, 2013-03-12 at 17:16 -0400, Martin Holec wrote: Hi Fedora users, developers and friends! today Fedora 19 was branched from Rawhide. That means testing season begins now and will continue till Fedora 19 Final Release, which may be (or may not be) on 2013-06-25. Please, fasten your seatbelts, fire up your virtual or baremetal machines and enjoy this crash testing ride with us. Remember: https://is0.4sqi.net/userpix/D1Y3XKHJVN4GIMRW.jpg Before Alpha will (or won't) be ready on 2013-04-16, we have prepared some Test Days[0] for you. Starting this Thursday with KDE 4.10 [1] with one major innovation. You are invited to try how new KDE 4.10 [2] stuff not only using Fedora 19 Live test images, but also from updates-testing repository on your current Fedora stable installation, including both Fedora 18 and Fedora 17 releases. For first time, you can test new version of whole KDE platform before it rolls up and in as an stable update for your Fedora! [0] https://fedoraproject.org/wiki/QA/Fedora_19_test_days [1] https://fedoraproject.org/wiki/Test_Day:2013-03-14_KDE_4.10 [2] http://www.kde.org/announcements/4.10/ Well, you may already know about and use Bodhi[3] with karma voting process. But Test Day provides an opportunity to actually talk to developers before KDE 4.10 reaches stable updates and interactively report, explore, debug and fix your issues (or at least find workarounds for the time being). Together we can make this update less painful for everyday Fedora KDE users. [3] https://admin.fedoraproject.org/updates/ Join IRC #fedora-test-day on FreeNode and ask QA or developers for help, if you get into trouble. We can try to find workarounds and help you with debugging. Please report all bugs under appropriate component preferably at upstream bugzilla https://bugs.kde.org/ regarding common KDE 4.10 issues or Red Hat bugzilla http://bugzilla.redhat.com/ if you have problems with Fedora distribution integration. You can also report other Fedora bugs not related to this Test Day. Feel free to ask on IRC, if you don't know against which component or on what bugzilla you should fill the report. See you in Bugzilla! Best Regards, Martin Holec Desktop QE, Red Hat Brno Freenode nick: Martix Your self-appointed Fedora 19 Test Day Wrangler. where are mock configures ? [1] and boot images for fedup ? [2] and [3] [1] mock -r fedora-19-x86_64 ERROR: Could not find required config file: /etc/mock/fedora-19-x86_64.cfg [2] Could not parse metalink https://mirrors.fedoraproject.org/metalink?repo=fedora-install-19arch=x86_64 error was No repomd file Error: can't get boot images. [3] with --instrepo http://ftp.fi.muni.cz/pub/linux/fedora/linux/development/19/x86_64/ also Error: can't get boot images. The 'cmdline-instrepo' repo was rejected by yum as invalid. -- Sérgio M. B. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fwd: MariaDB replacing MySQL
On 14. 3. 2013 at 16:44:58, Norvald H. Ryeng wrote: On Wed, 13 Mar 2013 18:08:55 +0100, Honza Horak hho...@redhat.com wrote: On 03/13/2013 09:27 AM, Norvald H. Ryeng wrote: On Tue, 12 Mar 2013 18:25:02 +0100, Honza Horak hho...@redhat.com wrote: On 03/12/2013 01:14 PM, Norvald H. Ryeng wrote: On Mon, 11 Mar 2013 19:58:03 +0100, Kevin Kofler kevin.kof...@chello.at wrote: Honza Horak wrote: This doesn't solve all the issues -- if package like akonadi-mysql says Requires: mysql-server, then Oracle MySQL either wouldn't satisfy that requirement or (in case it includes Provides: mysql-server) RPM choosing behavior would be ambiguous. And it should not satisfy it. We now changed the Requires in akonadi-mysql to mariadb-server to be sure of what we get. This dependency is a problem. It makes it impossible to install MySQL-server on a KDE system since mariadb-server and MySQL-server conflict. I don't think conflict is actually the main problem -- the inability of RPM to un-ambigously choose one of the two packages that provide the same symbol *is* the real problem. If we solved that one, MySQL-server could provide right symbol and KDE system would be happy. I fully agree that enforcing the default is the main problem. It makes the whole ting very difficult. I've spent some time deep in yum and it seems to be better than I thought now. First, the magic about choosing one provider from more alternatives is not so dark any more (it was worse few years before) -- it's actually documented at [1] now. However, in scenarios I tested with packages similar to mysql/MySQL/mariadb it turned out, that we never reach the point where we have to choose one of more alternate providers. The reason is that yum chooses right package before going down to [1] (I tracked the code and it never came to the part _compare_providers). Can we get a comment on this from someone with more knowledge of arcane yum/RPM magic? We need this to be a stable solution, not only luck. CCing James and Zdenek, as they are *the guys* when it comes to yum depsolver magic. Jan I've tested that on sample packages in one repo, that basically looked like this: mysql-5.5.30 #last version of the package and also package currently installed mariadb-5.5.29: Provides: mysql = 5.5.29 Obsoletes: mysql 5.6 MySQL-5.6.10: Provides: mysql = 5.6.10 # doesn't obsolete mysql The following table shows what actions (cols) yum chose in different scenarios -- i.e packages installed (rows): installed | # yum install mysql | # yum update | # yum shell (*) | -- --- | mariadb (**)| --- | MySQL | mysql | mariadb | mariadb | MySQL | MySQL | mariadb | MySQL| MySQL | mariadb | --- | mariadb | MySQL | (*) yum shell is needed in order to install MySQL while removing current implementation if any (mysql or mariadb) in one transaction. (**) The reason why mariadb is chosen is most probably this notice printed by yum: Package mysql is obsoleted by mariadb, trying to install mariadb-5.5.29-2.fc18.x86_64 instead We haven't had time to check everything, but we've done some initial testing and it looks promising. What we have found, is that MySQL server needs the accompanying mysql and mysqladmin tools to pass all tests. There is added functionality that isn't in MariaDB. I suggest mariadb-server depends on mariadb and mariadb-common, and that mysql-community-server depends on mysql-community and mysql-community-common. They can both provide the same mysql-server and mysql symbols (i see no need for the mysql-common virtual provide). That seems to work in our tests. This means it works as we'd wish even if we let MySQL packages to provide mysql symbols. I'll test the real packages after weekend, since I'm going to be off until Sunday. Have a nice weekend! Regards, Norvald H. Ryeng -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: ImageMagick update in rawhide to 6.8.3-9 version, so-name change, split libs sub package
13.03.2013 20:24, Remi Collet wrote: Le 13/03/2013 17:16, Remi Collet a écrit : php-pecl-imagick As you're the owner of this one, if you prefer to update it, see http://svn.php.net/viewvc?view=revisionrevision=329769 Thanks for pointing. Remi. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [Fedora QA] #348: Store Bugzilla Email Association in Database
#348: Store Bugzilla Email Association in Database ---+--- Reporter: tflink| Owner: mkrizek Type: enhancement | Status: closed Priority: major | Milestone: Fedora 19 Component: Blocker bug tracker page |Version: Resolution: fixed | Keywords: Blocked By:| Blocking: 347 ---+--- Changes (by mkrizek): * status: new = closed * resolution: = fixed Comment: Fixed in [http://git.fedorahosted.org/cgit/blockerbugs.git/commit/?h=developid=4ffd2dd5700cab8c676ce794720f1e9a5edeb485 4ffd2dd5700cab8c676ce794720f1e9a5edeb485] -- Ticket URL: https://fedorahosted.org/fedora-qa/ticket/348#comment:3 Fedora QA http://fedorahosted.org/fedora-qa Fedora Quality Assurance ___ qa-devel mailing list qa-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/qa-devel
Re: [Fedora QA] #349: Implement Bugzilla Email Verification
#349: Implement Bugzilla Email Verification ---+--- Reporter: tflink| Owner: mkrizek Type: enhancement | Status: closed Priority: major | Milestone: Fedora 19 Component: Blocker bug tracker page |Version: Resolution: fixed | Keywords: Blocked By:| Blocking: 347 ---+--- Changes (by mkrizek): * status: new = closed * resolution: = fixed Comment: Fixed in [http://git.fedorahosted.org/cgit/blockerbugs.git/commit/?h=developid=4ffd2dd5700cab8c676ce794720f1e9a5edeb485 4ffd2dd5700cab8c676ce794720f1e9a5edeb485] -- Ticket URL: https://fedorahosted.org/fedora-qa/ticket/349#comment:2 Fedora QA http://fedorahosted.org/fedora-qa Fedora Quality Assurance ___ qa-devel mailing list qa-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/qa-devel
Re: ImageMagick update in rawhide to 6.8.3-9 version, so-name change, split libs sub package
14.03.2013 20:04, Orion Poplawski пишет: On 03/14/2013 09:34 AM, Orion Poplawski wrote: Okay, looks like upstream cmake has a patch, I'll get it into rawhide ASAP. Scratch that, it was a hack for Arch Linux's hacked version of ImageMagick sonames that doesn't work for Fedora. Will need to work on a fix... Could you do that? I think then I should wait until that happened before IM landed to rawhide, is not? -- With best wishes, Pavel Alexeev (aka Pahan-Hubbitus). For fast contact with me use jabber: hubbi...@jabber.ru -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Should MariaDB touch my.cnf in %post?
Le mardi 12 mars 2013 à 12:27 +0100, Bjorn Munch a écrit : On 08/03 12.56, Michael Scherer wrote: Le mardi 05 mars 2013 à 11:34 +0100, Bjorn Munch a écrit : The package we have ready as an upgrade of the existing one removes some no longer needed patches, adds a few new patches, updates the spec file of course, and also adds an rpmlintrc file. It has of course been tested on a Rawhide installation. What do you mean by adding a rpmlintrc file ? Sorry for late reply, I was away. yeah, no problem We have run rpmlint on the package and it reported a number of problems. Many have been fixed, but this file lists a couple of problems to be ignored. Either they're not actually errors (e.g. a few zero length files) or they should be fixed upstream. We do not really use rpmlintrc like this, as rpmlint config is just a python script, and I think this would be too dangerous to have it executed automatically ( even if that's not really different from spec for that matter ). -- Michael Scherer -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Heads-up: liboauth 1.0.1 in Rawhide
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Dear all, I've just updated liboauth to the latest 1.0.1 release in Rawhide. The soname is now liboauth.so.0.8.5 (previously liboauth.so.0.8.4), and dependent apps should not need a rebuild, but maintainers of the affected components should probably double-check to be sure. (Especially for Evolution and GNOME Documents, as ever since I enabled two-factor authentication, synchronization with Google servers have been a bit problematic anyway). There's a scratch build for Fedora 18 here: http://koji.fedoraproject.org/koji/taskinfo?taskID=5125265 Note that upstream now considers all use of oauth_http functions to be deprecated: http://liboauth.sourceforge.net/ Best regards, - -- Michel Alexandre Salim Fedora Project Contributor: http://fedoraproject.org/ Email: sali...@fedoraproject.org | GPG key ID: A36A937A Jabber: hir...@jabber.ccc.de | IRC: hir...@irc.freenode.net () ascii ribbon campaign - against html e-mail /\ www.asciiribbon.org - against proprietary attachments -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.13 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJRQuvHAAoJEEr1VKujapN6aDAH/1xTrlYG3l7IT4ANgnwWDg+h zcZyqdk/3IQnFrSBTPjQLOZ97DUVG82JW5LqqnlpNX7qs/3+XZAyk6IACVsW6Mzj Yw3miGHDBpBp17ktrfeIFINpUwT2gErR+8X8ozNhgcGoTtkxxMlFvUWSIZJIPuTo Gz7HvpiqvFUfpvoU1GDyFUyrWHqgJdOn4pgzSzmbomd+yzgmpEHsdIAqBCuOHSxW YuSY36TRlGeo6ptfBAXOdNEvHqD51MyuNJ+4rz+3j6e3ejpynIV1YohHRdPqZw7O 81eCLe/gISgRa27zi4TtQsmYrX9RakfGHGY4BPqpEECCK0DR6XHF/8F2sBV9HBk= =/AXl -END PGP SIGNATURE- -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
dnf installs cron.hourly
I don't think users would expect that install of dnf would without asking (or control) automatically run dnf-makecache. At least, this should be controllable via /etc/sysconfig. Further, I think it's not consistent with Fedora practice to enable this on default by installing the package. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Should MariaDB touch my.cnf in %post?
On 13/03 15.05, Michael Scherer wrote: We have run rpmlint on the package and it reported a number of problems. Many have been fixed, but this file lists a couple of problems to be ignored. Either they're not actually errors (e.g. a few zero length files) or they should be fixed upstream. We do not really use rpmlintrc like this, as rpmlint config is just a python script, and I think this would be too dangerous to have it executed automatically ( even if that's not really different from spec for that matter ). This is not used automatically, it's been used when running rpmlint manually and is included for documentation purposes (and for anoyne else who might want to run rpmlint manually). - Bjorn Munch PS There's something odd with the timing of this email: it dropped into my inbox less that two hours ago and all the Received lines in the header are also from this morning, but the message itself is dated the 13th at 15:05. Is there some strange delay in the mail server? -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: dnf installs cron.hourly
On Fri, Mar 15, 2013 at 07:16:27AM -0400, Neal Becker wrote: I don't think users would expect that install of dnf would without asking (or control) automatically run dnf-makecache. Heh. That's one of the things I love about DNF. No longer having to wait a long time for repo downloads when runing 'dnf' because the cron job has already cached it, is great. I wish yum would do this by default too! At least, this should be controllable via /etc/sysconfig. Further, I think it's not consistent with Fedora practice to enable this on default by installing the package. Adding ability to turn it off via /etc/sysconfig seems reasonable, but having it on by default makes the out of the box experiance so much better. Daniel -- |: http://berrange.com -o-http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :| -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: dnf installs cron.hourly
On Fri, 15 Mar 2013 11:33:24 + Daniel P. Berrange berra...@redhat.com wrote: On Fri, Mar 15, 2013 at 07:16:27AM -0400, Neal Becker wrote: I don't think users would expect that install of dnf would without asking (or control) automatically run dnf-makecache. Heh. That's one of the things I love about DNF. No longer having to wait a long time for repo downloads when runing 'dnf' because the cron job has already cached it, is great. I wish yum would do this by default too! RFE? -- Regards, Frank http//www.frankly3d.com -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Is there a reason we do not turn on the file system hardlink/symlink protection in Rawhide?
On Thu, Mar 14, 2013 at 8:48 PM, Chris Adams cmad...@hiwaay.net wrote: Once upon a time, Josh Boyer jwbo...@gmail.com said: My patch put it in /usr/lib/sysctl.d, just coming from systemd itself. We could possibly throw that file into initscripts if systemd doesn't want to make that change (though I think Lennart would have the same objection). The rest of the standard sysctl settings are in the file /usr/lib/sysctl.d/00-system.conf, which comes from initscripts. I see no reason to create another file, just to add a couple more defaults. Oh, sure. Totally fine with me too. josh -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: dnf installs cron.hourly
On Fri, Mar 15, 2013 at 11:40:59AM +, Frank Murphy wrote: On Fri, 15 Mar 2013 11:33:24 + Daniel P. Berrange berra...@redhat.com wrote: On Fri, Mar 15, 2013 at 07:16:27AM -0400, Neal Becker wrote: I don't think users would expect that install of dnf would without asking (or control) automatically run dnf-makecache. Heh. That's one of the things I love about DNF. No longer having to wait a long time for repo downloads when runing 'dnf' because the cron job has already cached it, is great. I wish yum would do this by default too! RFE? File one if you like - I don't use yum anymore, preferring DNF because its dep solver is soo much faster. Regards, Daniel -- |: http://berrange.com -o-http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :| -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: dnf installs cron.hourly
Daniel P. Berrange wrote: On Fri, Mar 15, 2013 at 11:40:59AM +, Frank Murphy wrote: On Fri, 15 Mar 2013 11:33:24 + Daniel P. Berrange berra...@redhat.com wrote: On Fri, Mar 15, 2013 at 07:16:27AM -0400, Neal Becker wrote: I don't think users would expect that install of dnf would without asking (or control) automatically run dnf-makecache. Heh. That's one of the things I love about DNF. No longer having to wait a long time for repo downloads when runing 'dnf' because the cron job has already cached it, is great. I wish yum would do this by default too! RFE? File one if you like - I don't use yum anymore, preferring DNF because its dep solver is soo much faster. Regards, Daniel You might prefer this, but I think it's against Fedora policy. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: dnf installs cron.hourly
On 15/03/13 11:33, Daniel P. Berrange wrote: On Fri, Mar 15, 2013 at 07:16:27AM -0400, Neal Becker wrote: I don't think users would expect that install of dnf would without asking (or control) automatically run dnf-makecache. Heh. That's one of the things I love about DNF. No longer having to wait a long time for repo downloads when runing 'dnf' because the cron job has already cached it, is great. I wish yum would do this by default too! Well yum does in F18 at least for anybody running PackageKit as it will do the downloads in the background by default. This is of course intensely annoying to anybody with time of day based bandwidth restrictions/charges, especially since it is not well advertised or easy to turn off. A bug complaining about this has now been ignored for nearly two months: https://bugzilla.redhat.com/show_bug.cgi?id=890070 Note that the settings change is per-user, so if you have multiple desktop users you need to make sure that they all disable downloads... Tom -- Tom Hughes (t...@compton.nu) http://compton.nu/ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
[HEADS UP] initramfs - dracut - systemd
In case you were not bitten by Schrödinger's Cat in Grub or got around her, you might run in dracut/systemd problems in the initramfs. You will have to update to at least systemd-198-6.fc19 and dracut-026-48.git20130315.fc19 for a working initramfs. # koji download-build --arch=$(arch) systemd-198-6.fc19 # koji download-build --arch=$(arch) dracut-026-48.git20130315.fc19 # rpm -Fvh systemd*.rpm dracut*.rpm # dracut -f --kver=not_booting_kernel_version Sorry for the inconvenience! -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
[perl-Digest-MD4/f19] Update to 1.8
Summary of changes: 33d0c86... Update to 1.8 (*) (*) 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-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Re: Is there a reason we do not turn on the file system hardlink/symlink protection in Rawhide?
On Fri, Mar 15, 2013 at 7:42 AM, Josh Boyer jwbo...@gmail.com wrote: On Thu, Mar 14, 2013 at 8:48 PM, Chris Adams cmad...@hiwaay.net wrote: Once upon a time, Josh Boyer jwbo...@gmail.com said: My patch put it in /usr/lib/sysctl.d, just coming from systemd itself. We could possibly throw that file into initscripts if systemd doesn't want to make that change (though I think Lennart would have the same objection). The rest of the standard sysctl settings are in the file /usr/lib/sysctl.d/00-system.conf, which comes from initscripts. I see no reason to create another file, just to add a couple more defaults. Oh, sure. Totally fine with me too. https://bugzilla.redhat.com/show_bug.cgi?id=922030 josh -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Self Introduction
Greetings, I'm a software developer from Fort Wayne, Indiana. I work for a company called ScreenCheck North America and have been building RPMs for our in-house software as well as various open source projects not foung in EPEL or other trusted repos. I created our internal Yum repos about a year ago and have become quite fond of RedHat based distros, even so much as to move my personal machines from Arch Linux to Fedora. My goal is to maintain our open source RPMs as a Fedora Package Maintainer so that we can share our work with the community. I figured I would start with a tough one first, this is actually a package that I don't use at work but have installed on most of my personal machines and servers. I figured this would help me get a feel for the package review process. https://bugzilla.redhat.com/show_bug.cgi?id=922060 If anyone from the Erlang SIG could give me feedback that would be extra helpful as I'm fairly new to Erlang. All feedback is appreciated. Thanks, Travis Paul t...@vispaul.me -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Unhelpful update descriptions
On 03/14/2013 05:02 PM, Rahul Sundaram wrote: On 03/14/2013 04:33 PM, Przemek Klosowski wrote: I didn't realize that my method was 'relying on the kindness of strangers' for including the relevant CVE data in the changelog, but it often gives a quick, direct answer for the specific system you're on. If this was accidental rather than a policy, it'd make sense to codify and preserve the practice of including such security patch status in RPM changelogs, particularly when they are backported but in general case as well. When patches are backported, typically the changelog would cover the reason for doing so but not necessarily when a new update fixes a bunch of issues and security issue happens to be one of them. In some cases, there is no CVE id assigned for the problem either but if you want to request that packaging guidelines recommend this in the general case, file it at https://fedorahosted.org/fpc/ OK, let's see whether others like it too: https://fedorahosted.org/fpc/ticket/267 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: dnf installs cron.hourly
On Fri, 15 Mar 2013 11:33:24 + Daniel P. Berrange berra...@redhat.com wrote: On Fri, Mar 15, 2013 at 07:16:27AM -0400, Neal Becker wrote: I don't think users would expect that install of dnf would without asking (or control) automatically run dnf-makecache. Heh. That's one of the things I love about DNF. No longer having to wait a long time for repo downloads when runing 'dnf' because the cron job has already cached it, is great. I wish yum would do this by default too! There's a yum-cron package. It did just that for years. that's where dnf got the idea. -sv -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Is there a reason we do not turn on the file system hardlink/symlink protection in Rawhide?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 03/15/2013 09:04 AM, Josh Boyer wrote: On Fri, Mar 15, 2013 at 7:42 AM, Josh Boyer jwbo...@gmail.com wrote: On Thu, Mar 14, 2013 at 8:48 PM, Chris Adams cmad...@hiwaay.net wrote: Once upon a time, Josh Boyer jwbo...@gmail.com said: My patch put it in /usr/lib/sysctl.d, just coming from systemd itself. We could possibly throw that file into initscripts if systemd doesn't want to make that change (though I think Lennart would have the same objection). The rest of the standard sysctl settings are in the file /usr/lib/sysctl.d/00-system.conf, which comes from initscripts. I see no reason to create another file, just to add a couple more defaults. Oh, sure. Totally fine with me too. https://bugzilla.redhat.com/show_bug.cgi?id=922030 josh I guess we could open a feature page for this for F20, or do we want to pull it into F19. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.13 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlFDKOMACgkQrlYvE4MpobOUAQCgwWTKB5d+sB7n+n+vf9mYJ90I Do4AmgOxvV4R3UR3qAemRaU9uGIEN24H =wFhV -END PGP SIGNATURE- -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Is there a reason we do not turn on the file system hardlink/symlink protection in Rawhide?
On Fri, Mar 15, 2013 at 9:57 AM, Daniel J Walsh dwa...@redhat.com wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 03/15/2013 09:04 AM, Josh Boyer wrote: On Fri, Mar 15, 2013 at 7:42 AM, Josh Boyer jwbo...@gmail.com wrote: On Thu, Mar 14, 2013 at 8:48 PM, Chris Adams cmad...@hiwaay.net wrote: Once upon a time, Josh Boyer jwbo...@gmail.com said: My patch put it in /usr/lib/sysctl.d, just coming from systemd itself. We could possibly throw that file into initscripts if systemd doesn't want to make that change (though I think Lennart would have the same objection). The rest of the standard sysctl settings are in the file /usr/lib/sysctl.d/00-system.conf, which comes from initscripts. I see no reason to create another file, just to add a couple more defaults. Oh, sure. Totally fine with me too. https://bugzilla.redhat.com/show_bug.cgi?id=922030 josh I guess we could open a feature page for this for F20, or do we want to pull it into F19. I don't think this needs a feature page. I'd like to see it in F19. There's a case to be made for enabling it on the other releases too, but F19 is a good target to start with. josh -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Is there a reason we do not turn on the file system hardlink/symlink protection in Rawhide?
Once upon a time, Josh Boyer jwbo...@gmail.com said: I don't think this needs a feature page. I'd like to see it in F19. There's a case to be made for enabling it on the other releases too, but F19 is a good target to start with. I agree that it doesn't really need a feature page, but IMHO it should be in the release notes (this is something that could break existing programs). It _shouldn't_ be an issue, but I don't think it is a good idea to enable this on released versions. If it is going to be changed for F19, the change should land ASAP so any potential issues can be found during testing. -- Chris Adams cmad...@hiwaay.net Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: dnf installs cron.hourly
On 03/15/2013 09:55 AM, seth vidal wrote There's a yum-cron package. It did just that for years. that's where dnf got the idea. Yep but defaults matter Rahul -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: dnf installs cron.hourly
On 03/15/2013 07:53 AM, Neal Becker wrote: You might prefer this, but I think it's against Fedora policy. Why do you think that? Can you point me to such a policy? Rahul -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Heads-up: liboauth 1.0.1 in Rawhide
On Fri, 15 Mar 2013 16:37:11 +0700 Michel Alexandre Salim sali...@fedoraproject.org wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Dear all, I've just updated liboauth to the latest 1.0.1 release in Rawhide. The soname is now liboauth.so.0.8.5 (previously liboauth.so.0.8.4), and dependent apps should not need a rebuild, but maintainers of the affected components should probably double-check to be sure. (Especially for Evolution and GNOME Documents, as ever since I enabled two-factor authentication, synchronization with Google servers have been a bit problematic anyway). There's a scratch build for Fedora 18 here: http://koji.fedoraproject.org/koji/taskinfo?taskID=5125265 Note that upstream now considers all use of oauth_http functions to be deprecated: http://liboauth.sourceforge.net/ Best regards, Do you intend to land this in f19 branched as well? Or just f20/rawhide? kevin signature.asc Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: dnf installs cron.hourly
On Fri, Mar 15, 2013 at 09:55:57AM -0400, seth vidal wrote: On Fri, 15 Mar 2013 11:33:24 + Daniel P. Berrange berra...@redhat.com wrote: On Fri, Mar 15, 2013 at 07:16:27AM -0400, Neal Becker wrote: I don't think users would expect that install of dnf would without asking (or control) automatically run dnf-makecache. Heh. That's one of the things I love about DNF. No longer having to wait a long time for repo downloads when runing 'dnf' because the cron job has already cached it, is great. I wish yum would do this by default too! There's a yum-cron package. It did just that for years. Users shouldn't have to go searching out that kind of thing in a separate package IMHO, it could just be part of stock yum install. If it needs to be optional a config param would suffice, rather than the big hammer of installing/uninstalling extra RPM to enable/ disable a feature. Daniel -- |: http://berrange.com -o-http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :| -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Is there a reason we do not turn on the file system hardlink/symlink protection in Rawhide?
On 03/15/2013 10:52 AM, Chris Adams wrote: I agree that it doesn't really need a feature page, but IMHO it should be in the release notes (this is something that could break existing programs). Here you go https://fedoraproject.org/wiki/Documentation_Security_Beat Rahul -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: dnf installs cron.hourly
On Fri, 15 Mar 2013 15:11:28 + Daniel P. Berrange berra...@redhat.com wrote: On Fri, Mar 15, 2013 at 09:55:57AM -0400, seth vidal wrote: On Fri, 15 Mar 2013 11:33:24 + Daniel P. Berrange berra...@redhat.com wrote: On Fri, Mar 15, 2013 at 07:16:27AM -0400, Neal Becker wrote: I don't think users would expect that install of dnf would without asking (or control) automatically run dnf-makecache. Heh. That's one of the things I love about DNF. No longer having to wait a long time for repo downloads when runing 'dnf' because the cron job has already cached it, is great. I wish yum would do this by default too! There's a yum-cron package. It did just that for years. Users shouldn't have to go searching out that kind of thing in a separate package IMHO, it could just be part of stock yum install. If it needs to be optional a config param would suffice, rather than the big hammer of installing/uninstalling extra RPM to enable/ disable a feature. Go back far enough and it was enabled by default. It was removed from yum when yum was taken in for rhel b/c, iirc, interaction with rhn and then wanting yum-updatesd. I may be misinterpreting your tone in these emails but you sure seem to be somewhat angry about this... I have no idea why, though. this is my last comment on this thread. I'm glad you like the feature in dnf. I'm sure the dnf devels are happy about it too. -sv -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fwd: MariaDB replacing MySQL
On Wed, 2013-03-13 at 18:08 +0100, Honza Horak wrote: I've spent some time deep in yum and it seems to be better than I thought now. First, the magic about choosing one provider from more alternatives is not so dark any more (it was worse few years before) -- it's actually documented at [1] now. It's documented what the current version of yum does, and it's documented mostly for information purposes ... if you want to install XYZ and that is provided by FOO and BAR then installing either is correct (even if it's not what you want). However, in scenarios I tested with packages similar to mysql/MySQL/mariadb it turned out, that we never reach the point where we have to choose one of more alternate providers. The reason is that yum chooses right package before going down to [1] (I tracked the code and it never came to the part _compare_providers). Not sure what operation you tested this with, but you probably missed something. When installing a virtual provide, the usual code path would be: yum install 'mysql(x86-64)' = YumBase.install() = YumBase.bestPacakgesFromList() = YumBase._bestPackageFromList() = Depsolve._compare_providers() I've tested that on sample packages in one repo, that basically looked like this: mysql-5.5.30 #last version of the package and also package currently installed mariadb-5.5.29: Provides: mysql = 5.5.29 Obsoletes: mysql 5.6 MySQL-5.6.10: Provides: mysql = 5.6.10 # doesn't obsolete mysql Note that we have two major red flags here: 1. We are mixing a _package name_ mysql with a provide mysql, and another package name that is different only by capitalization MySQL. 2. We have multiple providers of mysql and an obsolete of mysql (which, again, is based on package name not provides). ...now there are certain parts of yum that will see FOO as a package name before it looks for provides, and thus. will never pick the other random packages that also provide FOO, the relevant ones are that is yum install and yum upgrade both operate this way. The following table shows what actions (cols) yum chose in different scenarios -- i.e packages installed (rows): installed | # yum install mysql | # yum update | # yum shell (*) | -- --- | mariadb (**)| --- | MySQL | mysql | mariadb | mariadb | MySQL | MySQL | mariadb | MySQL| MySQL | mariadb | --- | mariadb | MySQL | (*) yum shell is needed in order to install MySQL while removing current implementation if any (mysql or mariadb) in one transaction. It's not obvious what you are doing in yum shell, but rawhide/F19 yum also has the swap command (Eg. yum swap MySQL mariadb). But given the results I wouldn't be shocked if this was the one that represented what a requires would do. (**) The reason why mariadb is chosen is most probably this notice printed by yum: Package mysql is obsoleted by mariadb, trying to install mariadb-5.5.29-2.fc18.x86_64 instead Yes, basically you are hitting: cmd line FOO = package name FOO package name FOO = obsoleted by BAR ...which doesn't hit compare providers, because there are no providers to compare. But if the old package goes away then this won't be the same, or if the user does yum install /usr/bin/mysql (which both the new packages provide and isn't a package name). Also when a package XYZ requires FOO, then we don't first lookup a package with the name FOO. Instead we just do a general provides lookup, so that could/would act differently to the above table. Given that mariadb and MySQL are forks, and will have similar deps. and be on the same arches etc. ... I'd expect compare providers to come down to two things: 1. If all the providers give an = version for the provide, we'll choose the highest provided version (this is not true in el6 atm. ... if this is going to happen there). Given the above packaging data, 5.6.x 5.5.x ... thus. MySQL would be preferred. 2. Shortest name (so MySQL will win). This means it works as we'd wish even if we let MySQL packages to provide mysql symbols. I'll test the real packages after weekend, since I'm going to be off until Sunday. So, to sum up the above, I've started to believe that we will be able to add Provides: mysql also to MySQL packages, while mariadb would be correctly preferred by default. I'd bet against this. [1] http://yum.baseurl.org/wiki/CompareProviders -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
GCC produced wrong code in gvfs-1.14.2-3.fc18.x86_64
I happened to run across a problem with current gvfsd-sftp in x86_64
Fedora 18 that is apparently due to bad code generated by GCC.
The function
void
g_vfs_read_channel_send_seek_offset (GVfsReadChannel *read_channel,
goffset offset)
{
GVfsDaemonSocketProtocolReply reply;
GVfsChannel *channel;
channel = G_VFS_CHANNEL (read_channel);
reply.type = g_htonl (G_VFS_DAEMON_SOCKET_PROTOCOL_REPLY_SEEK_POS);
reply.seq_nr = g_htonl (g_vfs_channel_get_current_seq_nr (channel));
reply.arg1 = g_htonl (offset 0x);
reply.arg2 = g_htonl (offset 32);
g_vfs_channel_send_reply (channel, reply, NULL, 0);
}
in /usr/src/debug/gvfs-1.14.2/daemon/gvfsreadchannel.c shall split the
signed 64 bit goffset offset into reply.arg1 and reply.arg2. What
happens though is that reply.arg2 erroneously contains the same
(byte-swapped, due to g_htonl) low-order 32 bits as reply.arg1. The
generated code is
0x00421c90 +0: push %rbp
0x00421c91 +1: mov %rsi,%rbp
0x00421c94 +4: push %rbx
0x00421c95 +5: mov %rdi,%rbx
0x00421c98 +8: sub $0x18,%rsp
0x00421c9c +12: callq 0x415cf0 g_vfs_channel_get_type
0x00421ca1 +17: mov %rbx,%rdi
0x00421ca4 +20: mov %rax,%rsi
0x00421ca7 +23: callq 0x4093b0 g_type_check_instance_cast@plt
0x00421cac +28: mov %rax,%rdi
0x00421caf +31: mov %rax,%rbx
0x00421cb2 +34: movl $0x200,(%rsp)
0x00421cb9 +41: callq 0x416ab0 g_vfs_channel_get_current_seq_nr
0x00421cbe +46: mov %ebp,%esi
0x00421cc0 +48: mov $0x20,%ecx
0x00421cc5 +53: bswap %eax
0x00421cc7 +55: sar %cl,%esi
^^
0x00421cc9 +57: mov %eax,0x4(%rsp)
0x00421ccd +61: mov %ebp,%eax
0x00421ccf +63: bswap %esi
0x00421cd1 +65: bswap %eax
0x00421cd3 +67: mov %rbx,%rdi
0x00421cd6 +70: mov %esi,0xc(%rsp)
0x00421cda +74: xor %ecx,%ecx
0x00421cdc +76: mov %rsp,%rsi
0x00421cdf +79: xor %edx,%edx
0x00421ce1 +81: mov %eax,0x8(%rsp)
0x00421ce5 +85: callq 0x416210 g_vfs_channel_send_reply
0x00421cea +90: add $0x18,%rsp
0x00421cee +94: pop %rbx
0x00421cef +95: pop %rbp
0x00421cf0 +96: retq
where sar %cl,%esi with %ecx=$0x20 is a nop, as the processor masks the
upper three bits of the [%cl] count operand [AMD64 Architecture
Programmer’s Manual Volume 3: General Purpose and System Instructions].
Is this a known problem with (Fedora 18's) GCC?
Stephan
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: dnf installs cron.hourly
Am 15.03.2013 12:33, schrieb Daniel P. Berrange: On Fri, Mar 15, 2013 at 07:16:27AM -0400, Neal Becker wrote: I don't think users would expect that install of dnf would without asking (or control) automatically run dnf-makecache. Heh. That's one of the things I love about DNF. No longer having to wait a long time for repo downloads when runing 'dnf' because the cron job has already cached it, is great. I wish yum would do this by default too! as someone said install yum-cron but it is a stupid DEFAULT to do so i saw this mechanism download hundrets of megabytes by wrong chekcsums due mirror upgrades and downloading the metadata from EACH known mirror all night long have fun if you have limited traffic and to pay for! signature.asc Description: OpenPGP digital signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: dnf installs cron.hourly
Am 15.03.2013 16:11, schrieb Daniel P. Berrange: On Fri, Mar 15, 2013 at 07:16:27AM -0400, Neal Becker wrote: I don't think users would expect that install of dnf would without asking (or control) automatically run dnf-makecache. Heh. That's one of the things I love about DNF. No longer having to wait a long time for repo downloads when runing 'dnf' because the cron job has already cached it, is great. I wish yum would do this by default too! There's a yum-cron package. It did just that for years. Users shouldn't have to go searching out that kind of thing in a separate package IMHO, it could just be part of stock yum install. If it needs to be optional a config param would suffice, rather than the big hammer of installing/uninstalling extra RPM to enable/ disable a feature. and hwat let you come to the conclusion that if you have it to enable in a config makes anything different? have it enabled as DEFAULT is plain stupid did you ever see checksu mismatch from YUM? i saw this once download the metadata from ALL known mirrors resultig in some hundret MB traffic over night in background thanks god that i have a) a fast line b) no traffic limit if you pay for traffic over limits such features can ruin you signature.asc Description: OpenPGP digital signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: dnf installs cron.hourly
On Fri, Mar 15, 2013 at 4:11 PM, Daniel P. Berrange berra...@redhat.com wrote: Users shouldn't have to go searching out that kind of thing in a separate package IMHO, it could just be part of stock yum install. If it needs to be optional a config param would suffice, rather than the big hammer of installing/uninstalling extra RPM to enable/ disable a feature. Yeah, we don't generally do configuration by package installation/uninstallation. Mirek -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: dnf installs cron.hourly
On Fri, Mar 15, 2013 at 10:30 AM, Miloslav Trmač m...@volny.cz wrote: On Fri, Mar 15, 2013 at 4:11 PM, Daniel P. Berrange berra...@redhat.com wrote: Users shouldn't have to go searching out that kind of thing in a separate package IMHO, it could just be part of stock yum install. If it needs to be optional a config param would suffice, rather than the big hammer of installing/uninstalling extra RPM to enable/ disable a feature. Yeah, we don't generally do configuration by package installation/uninstallation. More to the point, https://fedoraproject.org/wiki/Starting_services_by_default -J Mirek -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel -- http://cecinestpasunefromage.wordpress.com/ in your fear, seek only peace in your fear, seek only love -d. bowie -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: dnf installs cron.hourly
On Fri, Mar 15, 2013 at 10:45:03AM -0500, Jon Ciesla wrote: On Fri, Mar 15, 2013 at 10:30 AM, Miloslav Trmač m...@volny.cz wrote: On Fri, Mar 15, 2013 at 4:11 PM, Daniel P. Berrange berra...@redhat.com wrote: Users shouldn't have to go searching out that kind of thing in a separate package IMHO, it could just be part of stock yum install. If it needs to be optional a config param would suffice, rather than the big hammer of installing/uninstalling extra RPM to enable/ disable a feature. Yeah, we don't generally do configuration by package installation/uninstallation. More to the point, https://fedoraproject.org/wiki/Starting_services_by_default That's about starting system services by default though, so isn't directly relevant to the question of whether cron jobs are allowed to be enabled by default. Do we have any package docs about cron job enablement ? I couldn't find any in my search attempts. Daniel -- |: http://berrange.com -o-http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :| -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: dnf installs cron.hourly
On Fri, Mar 15, 2013 at 10:48 AM, Daniel P. Berrange berra...@redhat.comwrote: On Fri, Mar 15, 2013 at 10:45:03AM -0500, Jon Ciesla wrote: On Fri, Mar 15, 2013 at 10:30 AM, Miloslav Trmač m...@volny.cz wrote: On Fri, Mar 15, 2013 at 4:11 PM, Daniel P. Berrange berra...@redhat.com wrote: Users shouldn't have to go searching out that kind of thing in a separate package IMHO, it could just be part of stock yum install. If it needs to be optional a config param would suffice, rather than the big hammer of installing/uninstalling extra RPM to enable/ disable a feature. Yeah, we don't generally do configuration by package installation/uninstallation. More to the point, https://fedoraproject.org/wiki/Starting_services_by_default That's about starting system services by default though, so isn't directly relevant to the question of whether cron jobs are allowed to be enabled by default. Do we have any package docs about cron job enablement ? I couldn't find any in my search attempts. I guess I always took that to include cron jobs, but you're right, it doesn't explicitly say so. Maybe this needs clarification. -J Daniel -- |: http://berrange.com -o-http://www.flickr.com/photos/dberrange/:| |: http://libvirt.org -o- http://virt-manager.org:| |: http://autobuild.org -o- http://search.cpan.org/~danberr/:| |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc:| -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel -- http://cecinestpasunefromage.wordpress.com/ in your fear, seek only peace in your fear, seek only love -d. bowie -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: dnf installs cron.hourly
- Original Message - From: Daniel P. Berrange berra...@redhat.com To: Development discussions related to Fedora devel@lists.fedoraproject.org Sent: Friday, March 15, 2013 11:48:41 AM Subject: Re: dnf installs cron.hourly On Fri, Mar 15, 2013 at 10:45:03AM -0500, Jon Ciesla wrote: On Fri, Mar 15, 2013 at 10:30 AM, Miloslav Trmač m...@volny.cz wrote: On Fri, Mar 15, 2013 at 4:11 PM, Daniel P. Berrange berra...@redhat.com wrote: Users shouldn't have to go searching out that kind of thing in a separate package IMHO, it could just be part of stock yum install. If it needs to be optional a config param would suffice, rather than the big hammer of installing/uninstalling extra RPM to enable/ disable a feature. Yeah, we don't generally do configuration by package installation/uninstallation. More to the point, https://fedoraproject.org/wiki/Starting_services_by_default That's about starting system services by default though, so isn't directly relevant to the question of whether cron jobs are allowed to be enabled by default. Do we have any package docs about cron job enablement ? I couldn't find any in my search attempts. Daniel The list of files sitting in my /etc/cron.*/ directories would certainly indicate that even if there is such a rule it is being ignored. Not that I necessarily have a problem with that given the jobs that are there (mlocate, cups, logrotate, man-db are all examples I don't remember setting up myself). Steve -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: GCC produced wrong code in gvfs-1.14.2-3.fc18.x86_64
On 03/15/2013 04:23 PM, Stephan Bergmann wrote:
I happened to run across a problem with current gvfsd-sftp in x86_64
Fedora 18 that is apparently due to bad code generated by GCC.
The function
void
g_vfs_read_channel_send_seek_offset (GVfsReadChannel *read_channel,
goffset offset)
{
GVfsDaemonSocketProtocolReply reply;
GVfsChannel *channel;
channel = G_VFS_CHANNEL (read_channel);
reply.type = g_htonl (G_VFS_DAEMON_SOCKET_PROTOCOL_REPLY_SEEK_POS);
reply.seq_nr = g_htonl (g_vfs_channel_get_current_seq_nr (channel));
reply.arg1 = g_htonl (offset 0x);
reply.arg2 = g_htonl (offset 32);
g_vfs_channel_send_reply (channel, reply, NULL, 0);
}
in /usr/src/debug/gvfs-1.14.2/daemon/gvfsreadchannel.c shall split the
signed 64 bit goffset offset into reply.arg1 and reply.arg2. What
happens though is that reply.arg2 erroneously contains the same
(byte-swapped, due to g_htonl) low-order 32 bits as reply.arg1. The
generated code is
[...]
Is this a known problem with (Fedora 18's) GCC?
Grr, sorry for the noise; appears to be rather a bug in
glib2-devel-2.34.2-2.fc18.x86_64, where /usr/include/glib-2.0/glib/gtypes.h
#define GUINT32_SWAP_LE_BE(val) ((guint32) __builtin_bswap32 ((gint32) val))
misses parentheses around val, so the above
reply.arg2 = g_htonl (offset 32);
ultimately expands to
reply.arg2 = guint32) __builtin_bswap32 ((gint32) offset 32;
(and building gvfs with -Werror would have nicely given it away,
warning: right shift count = width of type [enabled by default]).
Stephan
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: dnf installs cron.hourly
On Fri, 15 Mar 2013 11:58:33 -0400 (EDT) Steve Gordon sgor...@redhat.com wrote: - Original Message - From: Daniel P. Berrange berra...@redhat.com To: Development discussions related to Fedora devel@lists.fedoraproject.org Sent: Friday, March 15, 2013 11:48:41 AM Subject: Re: dnf installs cron.hourly On Fri, Mar 15, 2013 at 10:45:03AM -0500, Jon Ciesla wrote: On Fri, Mar 15, 2013 at 10:30 AM, Miloslav Trmač m...@volny.cz wrote: On Fri, Mar 15, 2013 at 4:11 PM, Daniel P. Berrange berra...@redhat.com wrote: Users shouldn't have to go searching out that kind of thing in a separate package IMHO, it could just be part of stock yum install. If it needs to be optional a config param would suffice, rather than the big hammer of installing/uninstalling extra RPM to enable/ disable a feature. Yeah, we don't generally do configuration by package installation/uninstallation. More to the point, https://fedoraproject.org/wiki/Starting_services_by_default That's about starting system services by default though, so isn't directly relevant to the question of whether cron jobs are allowed to be enabled by default. Do we have any package docs about cron job enablement ? I couldn't find any in my search attempts. Daniel The list of files sitting in my /etc/cron.*/ directories would certainly indicate that even if there is such a rule it is being ignored. Not that I necessarily have a problem with that given the jobs that are there (mlocate, cups, logrotate, man-db are all examples I don't remember setting up myself). To be fair - none of those call out to the network. they all act on things locally. -sv -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: dnf installs cron.hourly
- Original Message - From: seth vidal skvi...@fedoraproject.org To: Development discussions related to Fedora devel@lists.fedoraproject.org Cc: sgor...@redhat.com Sent: Friday, March 15, 2013 12:07:00 PM Subject: Re: dnf installs cron.hourly On Fri, 15 Mar 2013 11:58:33 -0400 (EDT) Steve Gordon sgor...@redhat.com wrote: - Original Message - From: Daniel P. Berrange berra...@redhat.com To: Development discussions related to Fedora devel@lists.fedoraproject.org Sent: Friday, March 15, 2013 11:48:41 AM Subject: Re: dnf installs cron.hourly On Fri, Mar 15, 2013 at 10:45:03AM -0500, Jon Ciesla wrote: On Fri, Mar 15, 2013 at 10:30 AM, Miloslav Trmač m...@volny.cz wrote: On Fri, Mar 15, 2013 at 4:11 PM, Daniel P. Berrange berra...@redhat.com wrote: Users shouldn't have to go searching out that kind of thing in a separate package IMHO, it could just be part of stock yum install. If it needs to be optional a config param would suffice, rather than the big hammer of installing/uninstalling extra RPM to enable/ disable a feature. Yeah, we don't generally do configuration by package installation/uninstallation. More to the point, https://fedoraproject.org/wiki/Starting_services_by_default That's about starting system services by default though, so isn't directly relevant to the question of whether cron jobs are allowed to be enabled by default. Do we have any package docs about cron job enablement ? I couldn't find any in my search attempts. Daniel The list of files sitting in my /etc/cron.*/ directories would certainly indicate that even if there is such a rule it is being ignored. Not that I necessarily have a problem with that given the jobs that are there (mlocate, cups, logrotate, man-db are all examples I don't remember setting up myself). To be fair - none of those call out to the network. they all act on things locally. Right, but the packaging guidelines don't seem to mention whether you should enable cron jobs in packages by default (or not) at all - let alone provide enough detail to specify what types of jobs it's appropriate for. I'd agree with Jon's comment that there is probably some clarification required in the guidelines here. Steve -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
using fedup to upgrade to f19
Hi, where are mock configures ? [1] and boot images for fedup ? [2] and [3] [1] mock -r fedora-19-x86_64 ERROR: Could not find required config file: /etc/mock/fedora-19-x86_64.cfg [2] Could not parse metalink https://mirrors.fedoraproject.org/metalink?repo=fedora-install-19arch=x86_64 error was No repomd file Error: can't get boot images. [3] with --instrepo http://ftp.fi.muni.cz/pub/linux/fedora/linux/development/19/x86_64/ also Error: can't get boot images. The 'cmdline-instrepo' repo was rejected by yum as invalid. Thanks, -- Sérgio M. B. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: dnf installs cron.hourly
On Fri, Mar 15, 2013 at 10:55:57AM -0500, Jon Ciesla wrote: On Fri, Mar 15, 2013 at 10:48 AM, Daniel P. Berrange berra...@redhat.comwrote: On Fri, Mar 15, 2013 at 10:45:03AM -0500, Jon Ciesla wrote: On Fri, Mar 15, 2013 at 10:30 AM, Miloslav Trmač m...@volny.cz wrote: On Fri, Mar 15, 2013 at 4:11 PM, Daniel P. Berrange berra...@redhat.com wrote: Users shouldn't have to go searching out that kind of thing in a separate package IMHO, it could just be part of stock yum install. If it needs to be optional a config param would suffice, rather than the big hammer of installing/uninstalling extra RPM to enable/ disable a feature. Yeah, we don't generally do configuration by package installation/uninstallation. More to the point, https://fedoraproject.org/wiki/Starting_services_by_default That's about starting system services by default though, so isn't directly relevant to the question of whether cron jobs are allowed to be enabled by default. Do we have any package docs about cron job enablement ? I couldn't find any in my search attempts. I guess I always took that to include cron jobs, but you're right, it doesn't explicitly say so. Maybe this needs clarification. Yep, I think it would be worth explicitly documenting requirements around cron jobs in the packaging guidelines, if we want to have any rules in this area. Daniel -- |: http://berrange.com -o-http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :| -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: dnf installs cron.hourly
On Fri, Mar 15, 2013 at 12:07:00PM -0400, seth vidal wrote: On Fri, 15 Mar 2013 11:58:33 -0400 (EDT) Steve Gordon sgor...@redhat.com wrote: - Original Message - From: Daniel P. Berrange berra...@redhat.com To: Development discussions related to Fedora devel@lists.fedoraproject.org Sent: Friday, March 15, 2013 11:48:41 AM Subject: Re: dnf installs cron.hourly On Fri, Mar 15, 2013 at 10:45:03AM -0500, Jon Ciesla wrote: On Fri, Mar 15, 2013 at 10:30 AM, Miloslav Trmač m...@volny.cz wrote: On Fri, Mar 15, 2013 at 4:11 PM, Daniel P. Berrange berra...@redhat.com wrote: Users shouldn't have to go searching out that kind of thing in a separate package IMHO, it could just be part of stock yum install. If it needs to be optional a config param would suffice, rather than the big hammer of installing/uninstalling extra RPM to enable/ disable a feature. Yeah, we don't generally do configuration by package installation/uninstallation. More to the point, https://fedoraproject.org/wiki/Starting_services_by_default That's about starting system services by default though, so isn't directly relevant to the question of whether cron jobs are allowed to be enabled by default. Do we have any package docs about cron job enablement ? I couldn't find any in my search attempts. Daniel The list of files sitting in my /etc/cron.*/ directories would certainly indicate that even if there is such a rule it is being ignored. Not that I necessarily have a problem with that given the jobs that are there (mlocate, cups, logrotate, man-db are all examples I don't remember setting up myself). To be fair - none of those call out to the network. they all act on things locally. Hmm, but the system service guidelines don't say anything about forbiding use of networking, only that things should not listen on network sockets out of the box. Either way, I think this needs to be clarified in the guidelines. Daniel -- |: http://berrange.com -o-http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :| -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: using fedup to upgrade to f19
On Fri, 15 Mar 2013 16:18:47 + Sérgio Basto ser...@serjux.com wrote: Hi, where are mock configures ? [1] and boot images for fedup ? [2] and [3] [1] mock -r fedora-19-x86_64 ERROR: Could not find required config file: /etc/mock/fedora-19-x86_64.cfg Please file a bug on mock. They need to push out a version with f19 configs: https://bugzilla.redhat.com/enter_bug.cgi?product=Fedoraversion=rawhidecomponent=mock [2] Could not parse metalink https://mirrors.fedoraproject.org/metalink?repo=fedora-install-19arch=x86_64 error was No repomd file Error: can't get boot images. The install repo that fedup uses isn't setup yet in f19. It needs to point to update images that are not yet created. [3] with --instrepo http://ftp.fi.muni.cz/pub/linux/fedora/linux/development/19/x86_64/ also Error: can't get boot images. The 'cmdline-instrepo' repo was rejected by yum as invalid. Because it lacks the needed updates.img. I would advise using yum to upgrade to f19 at this time. kevin signature.asc Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: dnf installs cron.hourly
On Fri, Mar 15, 2013 at 5:26 PM, Daniel P. Berrange berra...@redhat.com wrote: On Fri, Mar 15, 2013 at 12:07:00PM -0400, seth vidal wrote: To be fair - none of those call out to the network. they all act on things locally. Hmm, but the system service guidelines don't say anything about forbiding use of networking, only that things should not listen on network sockets out of the box. Either way, I think this needs to be clarified in the guidelines. The guidelines will never be able to definitely answer every question. I think the basic balance (listening on the network by default is forbidden, enabling services on package installation by default is not required) is correct, and there is a genuine gray zone in between. Perhaps what we need in there is just a list of concerns to be aware of when making the decision (e.g. security/attack surface, metered internet connections, performance impact on the rest of the system). Mirek -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Packages requires /sbin/service.
After usr move packages should not install files to /sbin. Unfortunately there is a lot of packages requiring /sbin/service, which was recently moved to /usr/sbin/, and these packages were uninstallable. As a workaround I have put Provides: /sbin/service in the initscript spec, but I think that we should do a proper fix. So if your package is in following list, please change your Reguires to /usr/sbin/service. Thanks Lukas acpid-sysvinit amanda-client amanda-server amavisd-new amavisd-new-snmp autofs awstats bird-sysvinit bird6-sysvinit bitlbee bluez-compat boa cacti Canna cfengine conmux crossfire-selinux cyphesis cyrus-sasl dahdi-tools dhcp_probe dkim-milter ebtables exim exim-clamav fail2ban glpi greylistd groonga-munin-plugins groonga-server-gqtp groonga-server-http horde hplip ibmasm iputils-sysvinit isdn4k-utils i8kutils keepalived koji-builder koji-vm mailman mimedefang mogilefsd mogstored moodle munin-node nessus-server node nrpe oidentd openslp-server opensm-sysv openswan orbited pathfinderd pcsc-lite-openct phpMemcachedAdmin preload prelude-correlator quagga-sysvinit ratbox-services rinetd roundup rtpproxy setroubleshoot-server sip-redirect sks smstools spamassassin spampd spawn-fcgi squid-sysvinit srptools-sysv sysklogd tftp-server ttywatch ulogd varnish vblade vsftpd-sysvinit wine-desktop xorg-x11-xfs xtide yum-cron zarafa-dagent zarafa-gateway zarafa-ical zarafa-indexer zarafa-monitor zarafa-server zarafa-spooler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Packages requires /sbin/service.
On Fri, 15 Mar 2013 17:38:53 +0100
Lukáš Nykrýn lnyk...@redhat.com wrote:
After usr move packages should not install files to /sbin.
Unfortunately there is a lot of packages requiring /sbin/service,
which was recently moved to /usr/sbin/, and these packages were
uninstallable. As a workaround I have put Provides: /sbin/service in
the initscript spec, but I think that we should do a proper fix.
So if your package is in following list, please change your Reguires
to /usr/sbin/service.
To clarify, this affects only f19 and f20, right?
So,
%if 0%{?rhel} 6 || 0%{?fedora} 18
Requires: /usr/sbin/service
%else
Requires: /sbin/service
%endif
should work as a portable means of doing this?
Thanks
Lukas
kevin
signature.asc
Description: PGP signature
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Packages requires /sbin/service.
Pá 15. březen 2013, 17:47:05 CET, Kevin Fenzi napsal:
On Fri, 15 Mar 2013 17:38:53 +0100
Lukáš Nykrýn lnyk...@redhat.com wrote:
After usr move packages should not install files to /sbin.
Unfortunately there is a lot of packages requiring /sbin/service,
which was recently moved to /usr/sbin/, and these packages were
uninstallable. As a workaround I have put Provides: /sbin/service in
the initscript spec, but I think that we should do a proper fix.
So if your package is in following list, please change your Reguires
to /usr/sbin/service.
To clarify, this affects only f19 and f20, right?
So,
%if 0%{?rhel} 6 || 0%{?fedora} 18
Requires: /usr/sbin/service
%else
Requires: /sbin/service
%endif
should work as a portable means of doing this?
Thanks
Lukas
kevin
Yes this is related to F19 and F20. But my personal opinion is, that
packages should use systemctl now anyway.
Lukas
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: dnf installs cron.hourly
Rahul Sundaram wrote: On 03/15/2013 07:53 AM, Neal Becker wrote: You might prefer this, but I think it's against Fedora policy. Why do you think that? Can you point me to such a policy? Rahul https://fedoraproject.org/wiki/Starting_services_by_default -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Packages requires /sbin/service.
On 03/15/2013 05:38 PM, Lukáš Nykrýn wrote: After usr move packages should not install files to /sbin. Unfortunately there is a lot of packages requiring /sbin/service, which was recently moved to /usr/sbin/, and these packages were uninstallable. As a workaround I have put Provides: /sbin/service in the initscript spec, but I think that we should do a proper fix. So if your package is in following list, please change your Reguires to /usr/sbin/service. I am very much opposed to this change. You need to keep files which are expected to be in /bin or /sbin under these paths. Ralf -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: GCC produced wrong code in gvfs-1.14.2-3.fc18.x86_64
On 03/15/2013 05:06 PM, Stephan Bergmann wrote: Grr, sorry for the noise; appears to be rather a bug in glib2-devel-2.34.2-2.fc18.x86_64 See https://bugzilla.gnome.org/show_bug.cgi?id=695925 GUINT32/64_SWAP_LE_BE macros do not enclose val argument in parentheses. Stephan -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: using fedup to upgrade to f19
On Fri, Mar 15, 2013 at 9:36 AM, Kevin Fenzi ke...@scrye.com wrote: On Fri, 15 Mar 2013 16:18:47 + Sérgio Basto ser...@serjux.com wrote: Hi, where are mock configures ? [1] and boot images for fedup ? [2] and [3] [1] mock -r fedora-19-x86_64 ERROR: Could not find required config file: /etc/mock/fedora-19-x86_64.cfg Please file a bug on mock. They need to push out a version with f19 configs: https://bugzilla.redhat.com/enter_bug.cgi?product=Fedoraversion=rawhidecomponent=mock [2] Could not parse metalink https://mirrors.fedoraproject.org/metalink?repo=fedora-install-19arch=x86_64 error was No repomd file Error: can't get boot images. The install repo that fedup uses isn't setup yet in f19. It needs to point to update images that are not yet created. [3] with --instrepo http://ftp.fi.muni.cz/pub/linux/fedora/linux/development/19/x86_64/ also Error: can't get boot images. The 'cmdline-instrepo' repo was rejected by yum as invalid. Because it lacks the needed updates.img. I would advise using yum to upgrade to f19 at this time. kevin -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel You think if it breaks systems using yum (not yum's fault) you will have better luck with fedup? Dan -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: GCC produced wrong code in gvfs-1.14.2-3.fc18.x86_64
On Fri, Mar 15, 2013 at 10:24 AM, Stephan Bergmann sberg...@redhat.com wrote: On 03/15/2013 05:06 PM, Stephan Bergmann wrote: Grr, sorry for the noise; appears to be rather a bug in glib2-devel-2.34.2-2.fc18.x86_64 See https://bugzilla.gnome.org/show_bug.cgi?id=695925 GUINT32/64_SWAP_LE_BE macros do not enclose val argument in parentheses. Stephan -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Yes this is a glib2 issue. glib2 changes in 19 caused a lot of packages to change behavior/code. After we rushed to fix compilation issues we are now noticing the code behaving differently than it used to across distros. It sucks but such is life. Dan -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Is there a reason we do not turn on the file system hardlink/symlink protection in Rawhide?
On Mar 15, 2013 10:13 AM, Rahul Sundaram methe...@gmail.com wrote: On 03/15/2013 10:52 AM, Chris Adams wrote: I agree that it doesn't really need a feature page, but IMHO it should be in the release notes (this is something that could break existing programs). Here you go https://fedoraproject.org/wiki/Documentation_Security_Beat Rahul -- That is an excellent explanation, thanks Rahul! --Pete -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Packages requires /sbin/service.
On Fri, Mar 15, 2013 at 10:18 AM, Ralf Corsepius rc040...@freenet.de wrote: On 03/15/2013 05:38 PM, Lukáš Nykrýn wrote: After usr move packages should not install files to /sbin. Unfortunately there is a lot of packages requiring /sbin/service, which was recently moved to /usr/sbin/, and these packages were uninstallable. As a workaround I have put Provides: /sbin/service in the initscript spec, but I think that we should do a proper fix. So if your package is in following list, please change your Reguires to /usr/sbin/service. I am very much opposed to this change. You need to keep files which are expected to be in /bin or /sbin under these paths. Ralf -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Me too. Even with the switch to systemd I still use the service command, and plan to keep it that way. Dan -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [HEADS UP] initramfs - dracut - systemd
On 15/03/13 05:07 AM, Harald Hoyer wrote: In case you were not bitten by Schrödinger's Cat in Grub or got around her, you Thinking about it, by strict Law of Narrative Causality, I expect precisely half of the Rawhide/F19 testers would have got bitten by Schrödinger's Cat ;) -- 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: Packages requires /sbin/service.
On 03/15/2013 06:53 PM, Dan Mashal wrote: On Fri, Mar 15, 2013 at 10:18 AM, Ralf Corsepius rc040...@freenet.de wrote: I am very much opposed to this change. You need to keep files which are expected to be in /bin or /sbin under these paths. /sbin is a symlink to /usr/sbin, so calling /sbin/service still works. Me too. Even with the switch to systemd I still use the service command, and plan to keep it that way. Nobody's removing the command. Michal -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Packages requires /sbin/service.
On Fri, Mar 15, 2013 at 10:56 AM, Michal Schmidt mschm...@redhat.com wrote: On 03/15/2013 06:53 PM, Dan Mashal wrote: On Fri, Mar 15, 2013 at 10:18 AM, Ralf Corsepius rc040...@freenet.de wrote: I am very much opposed to this change. You need to keep files which are expected to be in /bin or /sbin under these paths. /sbin is a symlink to /usr/sbin, so calling /sbin/service still works. Me too. Even with the switch to systemd I still use the service command, and plan to keep it that way. Nobody's removing the command. Michal -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Looks like you guys added provides(service) and fixed the problem. Dan -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Packages requires /sbin/service.
On 03/15/2013 07:00 PM, Dan Mashal wrote: Looks like you guys added provides(service) and fixed the problem. Yes, Lukáš added it. He even mentioned it in the email that started this thread. Still it would be nice to drop legacy provide name after packages stop Requiring it. Michal -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Packages requires /sbin/service.
On Fri, Mar 15, 2013 at 5:52 PM, Lukáš Nykrýn lnyk...@redhat.com wrote:
Pá 15. březen 2013, 17:47:05 CET, Kevin Fenzi napsal:
On Fri, 15 Mar 2013 17:38:53 +0100
Lukáš Nykrýn lnyk...@redhat.com wrote:
After usr move packages should not install files to /sbin.
Unfortunately there is a lot of packages requiring /sbin/service,
which was recently moved to /usr/sbin/, and these packages were
uninstallable. As a workaround I have put Provides: /sbin/service in
the initscript spec, but I think that we should do a proper fix.
So if your package is in following list, please change your Reguires
to /usr/sbin/service.
To clarify, this affects only f19 and f20, right?
So,
%if 0%{?rhel} 6 || 0%{?fedora} 18
Requires: /usr/sbin/service
%else
Requires: /sbin/service
%endif
should work as a portable means of doing this?
Thanks
Lukas
Yes this is related to F19 and F20. But my personal opinion is, that
packages should use systemctl now anyway.
Yes - if you are going to touch the spec file, migrating to native
systemctl makes much more sense.
With the existing /sbin - /usr/sbin symlinks and the Provides:
/sbin/service, replacing /sbin/service references by /usr/sbin/service
references isn't solving any user-visible problem AFAICS.
Mirek
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Packages requires /sbin/service.
On Fri, Mar 15, 2013 at 11:04 AM, Michal Schmidt mschm...@redhat.com wrote: On 03/15/2013 07:00 PM, Dan Mashal wrote: Looks like you guys added provides(service) and fixed the problem. Yes, Lukáš added it. He even mentioned it in the email that started this thread. Still it would be nice to drop legacy provide name after packages stop Requiring it. Michal -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Well I was reading an IRC discussion on devel. I'm like a horse with blinders. This used to work and doesn't anymore. Which leads me to my next point: What does it hurt to have the command there? In fact you should just rename systemctl service and make it understand service commands. It's annoying over all. Dan -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: dnf installs cron.hourly
On 15/03/13 04:16 AM, Neal Becker wrote: I don't think users would expect that install of dnf would without asking (or control) automatically run dnf-makecache. At least, this should be controllable via /etc/sysconfig. Further, I think it's not consistent with Fedora practice to enable this on default by installing the package. Why not using systemd Calender Time? https://fedoraproject.org/wiki/Features/SystemdCalendarTimers -- Luya Tshimbalanga Graphic Web Designer E: l...@fedoraproject.org W: http://www.coolest-storm.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: dnf installs cron.hourly
On Fri, Mar 15, 2013 at 7:13 PM, Luya Tshimbalanga l...@fedoraproject.org wrote: On 15/03/13 04:16 AM, Neal Becker wrote: I don't think users would expect that install of dnf would without asking (or control) automatically run dnf-makecache. At least, this should be controllable via /etc/sysconfig. Further, I think it's not consistent with Fedora practice to enable this on default by installing the package. Why not using systemd Calender Time? https://fedoraproject.org/wiki/Features/SystemdCalendarTimers 1) Changing the mechanism would not resolve any of the questions discussed here. 2) http://lists.fedoraproject.org/pipermail/devel/2013-February/178220.html: * AGREED: Feature is approved. No packages should convert to using this feature yet. (7, 0, 0) (nirik, 20:26:31) Mirek -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Packages requires /sbin/service.
On 03/15/2013 07:07 PM, Dan Mashal wrote: Well I was reading an IRC discussion on devel. I'm like a horse with blinders. This used to work and doesn't anymore. I cannot be sure, but I think you're referring here to the breakage caused by initscripts-9.45-1 due to the missing Provides: /sbin/service, but that has been added in 9.45-2. Which leads me to my next point: What does it hurt to have the command there? I was not suggesting removing the command, but merely the RPM Provides eventually. Michal -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Packages requires /sbin/service.
On Fri, Mar 15, 2013 at 11:15 AM, Michal Schmidt mschm...@redhat.com wrote: On 03/15/2013 07:07 PM, Dan Mashal wrote: Well I was reading an IRC discussion on devel. I'm like a horse with blinders. This used to work and doesn't anymore. I cannot be sure, but I think you're referring here to the breakage caused by initscripts-9.45-1 due to the missing Provides: /sbin/service, but that has been added in 9.45-2. Which leads me to my next point: What does it hurt to have the command there? I was not suggesting removing the command, but merely the RPM Provides eventually. Michal -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Thanks for clarification. Dan -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: dnf installs cron.hourly
On Fri, Mar 15, 2013 at 07:14:39PM +0100, Miloslav Trmač wrote: 1) Changing the mechanism would not resolve any of the questions discussed here. Systemd is a bit cleaner to admin, and turning the service off wouldn't make an oddity show up in rpm -qaV like moving a cron job aside would. 2) http://lists.fedoraproject.org/pipermail/devel/2013-February/178220.html: * AGREED: Feature is approved. No packages should convert to using this feature yet. (7, 0, 0) (nirik, 20:26:31) Not sure if that applies in this case. It'd be dnf using a systemd feature, not systemd using a dnf feature. --CJD pgpVo2MZBpUXU.pgp Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: dnf installs cron.hourly
Daniel P. Berrange wrote: On Fri, Mar 15, 2013 at 12:07:00PM -0400, seth vidal wrote: On Fri, 15 Mar 2013 11:58:33 -0400 (EDT) Steve Gordon sgor...@redhat.com wrote: - Original Message - From: Daniel P. Berrange berra...@redhat.com To: Development discussions related to Fedora devel@lists.fedoraproject.org Sent: Friday, March 15, 2013 11:48:41 AM Subject: Re: dnf installs cron.hourly On Fri, Mar 15, 2013 at 10:45:03AM -0500, Jon Ciesla wrote: On Fri, Mar 15, 2013 at 10:30 AM, Miloslav Trmač m...@volny.cz wrote: On Fri, Mar 15, 2013 at 4:11 PM, Daniel P. Berrange berra...@redhat.com wrote: Users shouldn't have to go searching out that kind of thing in a separate package IMHO, it could just be part of stock yum install. If it needs to be optional a config param would suffice, rather than the big hammer of installing/uninstalling extra RPM to enable/ disable a feature. Yeah, we don't generally do configuration by package installation/uninstallation. More to the point, https://fedoraproject.org/wiki/Starting_services_by_default That's about starting system services by default though, so isn't directly relevant to the question of whether cron jobs are allowed to be enabled by default. Do we have any package docs about cron job enablement ? I couldn't find any in my search attempts. Daniel The list of files sitting in my /etc/cron.*/ directories would certainly indicate that even if there is such a rule it is being ignored. Not that I necessarily have a problem with that given the jobs that are there (mlocate, cups, logrotate, man-db are all examples I don't remember setting up myself). To be fair - none of those call out to the network. they all act on things locally. Hmm, but the system service guidelines don't say anything about forbiding use of networking, only that things should not listen on network sockets out of the box. Either way, I think this needs to be clarified in the guidelines. Daniel That's why in my OP I said I thought it violated Fedora Practice (or common expectations) (not necessarily the letter of the law). There are certainly some in our populations who do not expect that just cause they yum install X, that suddenly it's using their network without warning. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: dnf installs cron.hourly
On Fri, Mar 15, 2013 at 02:29:19PM -0400, Casey Dahlin wrote: On Fri, Mar 15, 2013 at 07:14:39PM +0100, Miloslav Trmač wrote: 1) Changing the mechanism would not resolve any of the questions discussed here. Systemd is a bit cleaner to admin, and turning the service off wouldn't make an oddity show up in rpm -qaV like moving a cron job aside would. Also, turning periodic job ON during installation would be the matter of preset, like with normal services. Not the matter of packager's mood. There was a decision of not _migrating_ cronjobs to timer units yet. But I think we should ban _introducing_ new cronjobs. Instead, new periodic jobs should be introduced as timer units. -- Tomasz .. oo o. oo o. .o .o o. o. oo o. .. Torcz.. .o .o .o .o oo oo .o .. .. oo oo o.o.o. .o .. o. o. o. o. o. o. oo .. .. o. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: dnf installs cron.hourly
On 15/03/13 08:30 AM, Miloslav Trmač wrote: On Fri, Mar 15, 2013 at 4:11 PM, Daniel P. Berrange berra...@redhat.com wrote: Users shouldn't have to go searching out that kind of thing in a separate package IMHO, it could just be part of stock yum install. If it needs to be optional a config param would suffice, rather than the big hammer of installing/uninstalling extra RPM to enable/ disable a feature. Yeah, we don't generally do configuration by package installation/uninstallation. In this case it seems perfectly logical. The thing in question is a cron script. You want it, install it. You don't want it, don't install it. How would this be implemented with a config parameter in a way which wouldn't be more messy? I mean, wouldn't you have to implement something absurd like a bit of code in yum to read the config value and fiddle with the presence of the cron script? Ew. -- 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: dnf installs cron.hourly
On 15/03/13 11:51 AM, Adam Williamson wrote: On 15/03/13 08:30 AM, Miloslav Trmač wrote: On Fri, Mar 15, 2013 at 4:11 PM, Daniel P. Berrange berra...@redhat.com wrote: Users shouldn't have to go searching out that kind of thing in a separate package IMHO, it could just be part of stock yum install. If it needs to be optional a config param would suffice, rather than the big hammer of installing/uninstalling extra RPM to enable/ disable a feature. Yeah, we don't generally do configuration by package installation/uninstallation. In this case it seems perfectly logical. The thing in question is a cron script. You want it, install it. You don't want it, don't install it. How would this be implemented with a config parameter in a way which wouldn't be more messy? I mean, wouldn't you have to implement something absurd like a bit of code in yum to read the config value and fiddle with the presence of the cron script? Ew. OK, now I think about it, of course the script just checks the config value and exits if it's 'disabled'. Still more Stuff than just a package with the script in it, to my mind, but eh. -- 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: dnf installs cron.hourly
On Fri, Mar 15, 2013 at 07:44:58PM +0100, Tomasz Torcz wrote: There was a decision of not _migrating_ cronjobs to timer units yet. But I think we should ban _introducing_ new cronjobs. Instead, new periodic jobs should be introduced as timer units. That's assuming all cron jobs should become systemd timer units (Lennart himself has stated systemd timer units don't fully replace cron). --CJD pgpbtQ5fOwcrS.pgp Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: using fedup to upgrade to f19
On 15/03/13 10:25 AM, Dan Mashal wrote: I would advise using yum to upgrade to f19 at this time. kevin -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel You think if it breaks systems using yum (not yum's fault) you will have better luck with fedup? What? Kevin said fedup isn't working, and recommended using yum. I can't see how your reply relates to what he wrote. -- 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: Packages requires /sbin/service.
On 15/03/13 11:07 AM, Dan Mashal wrote: On Fri, Mar 15, 2013 at 11:04 AM, Michal Schmidt mschm...@redhat.com wrote: On 03/15/2013 07:00 PM, Dan Mashal wrote: Looks like you guys added provides(service) and fixed the problem. Yes, Lukáš added it. He even mentioned it in the email that started this thread. Still it would be nice to drop legacy provide name after packages stop Requiring it. Michal -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Well I was reading an IRC discussion on devel. I'm like a horse with blinders. This used to work and doesn't anymore. Which leads me to my next point: What does it hurt to have the command there? In fact you should just rename systemctl service and make it understand service commands. It's annoying over all. Yes, well, the 'horse with blinkers' thing is kind of annoying sometimes. This has nothing to do with the thread. If you want to propose stuff like that, please do it in a separate thread, but it's really not very likely to happen. This thread was a very simple request for a simple spec change which has now gotten derailed into yet another systemd bikeshed. Sigh. -- 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: Packages requires /sbin/service.
On 03/15/2013 10:38 AM, Lukáš Nykrýn wrote: After usr move packages should not install files to /sbin. Unfortunately there is a lot of packages requiring /sbin/service, which was recently moved to /usr/sbin/, and these packages were uninstallable. As a workaround I have put Provides: /sbin/service in the initscript spec, but I think that we should do a proper fix. So if your package is in following list, please change your Reguires to /usr/sbin/service. Thanks Lukas fail2ban Finally moved this to systemd for F19+ -- Orion Poplawski Technical Manager 303-415-9701 x222 NWRA, Boulder Office FAX: 303-415-9702 3380 Mitchell Lane or...@nwra.com Boulder, CO 80301 http://www.nwra.com -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: using fedup to upgrade to f19
On Fri, Mar 15, 2013 at 10:36 AM, Kevin Fenzi ke...@scrye.com wrote: Please file a bug on mock. They need to push out a version with f19 configs: Thanks for pointing in the right direction. I've filed https://bugzilla.redhat.com/922268 - Ken -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: dnf installs cron.hourly
Steve Gordon wrote: - Original Message - From: seth vidal skvi...@fedoraproject.org To: Development discussions related to Fedora devel@lists.fedoraproject.org Cc: sgor...@redhat.com Sent: Friday, March 15, 2013 12:07:00 PM Subject: Re: dnf installs cron.hourly On Fri, 15 Mar 2013 11:58:33 -0400 (EDT) Steve Gordon sgor...@redhat.com wrote: - Original Message - From: Daniel P. Berrange berra...@redhat.com To: Development discussions related to Fedora devel@lists.fedoraproject.org Sent: Friday, March 15, 2013 11:48:41 AM Subject: Re: dnf installs cron.hourly On Fri, Mar 15, 2013 at 10:45:03AM -0500, Jon Ciesla wrote: On Fri, Mar 15, 2013 at 10:30 AM, Miloslav Trmač m...@volny.cz wrote: On Fri, Mar 15, 2013 at 4:11 PM, Daniel P. Berrange berra...@redhat.com wrote: Users shouldn't have to go searching out that kind of thing in a separate package IMHO, it could just be part of stock yum install. If it needs to be optional a config param would suffice, rather than the big hammer of installing/uninstalling extra RPM to enable/ disable a feature. Yeah, we don't generally do configuration by package installation/uninstallation. More to the point, https://fedoraproject.org/wiki/Starting_services_by_default That's about starting system services by default though, so isn't directly relevant to the question of whether cron jobs are allowed to be enabled by default. Do we have any package docs about cron job enablement ? I couldn't find any in my search attempts. Daniel The list of files sitting in my /etc/cron.*/ directories would certainly indicate that even if there is such a rule it is being ignored. Not that I necessarily have a problem with that given the jobs that are there (mlocate, cups, logrotate, man-db are all examples I don't remember setting up myself). To be fair - none of those call out to the network. they all act on things locally. Right, but the packaging guidelines don't seem to mention whether you should enable cron jobs in packages by default (or not) at all - let alone provide enough detail to specify what types of jobs it's appropriate for. I'd agree with Jon's comment that there is probably some clarification required in the guidelines here. Steve Almost makes me wonder if a system like that on my android is needed, where it tells me when I install that the app may use services that cost me money. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: using fedup to upgrade to f19
On Sex, 2013-03-15 at 12:19 -0700, Adam Williamson wrote: On 15/03/13 10:25 AM, Dan Mashal wrote: I would advise using yum to upgrade to f19 at this time. kevin -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel You think if it breaks systems using yum (not yum's fault) you will have better luck with fedup? What? Kevin said fedup isn't working, and recommended using yum. When I can expect have an updates.img ? composing is failing to generate images ? How I generate an update image ? I can't see how your reply relates to what he wrote. I think that was a question, and replying to the question of Dan Mashal, fedup will never work without the image . Best regards, -- Sérgio M. B. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: using fedup to upgrade to f19
On 15/03/13 04:56 PM, Sérgio Basto wrote: When I can expect have an updates.img ? composing is failing to generate images ? Possibly tomorrow, but it depends on the state of dracut and lorax. -- 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
Package EVR problems in Fedora 2013-03-16
Broken upgrade path report for tags f19 - f20: cumin: f19 f20 (cumin-0.1.5739-1.fc19 cumin-0.1.5522-5.fc19) cups: f19 f20 (1:cups-1.6.1-26.fc19 1:cups-1.6.1-25.fc19) cups-filters: f19 f20 (cups-filters-1.0.30-3.fc19 cups-filters-1.0.30-2.fc20) fedora-arm-installer: f19 f20 (fedora-arm-installer-1.0.3-7.fc19 fedora-arm-installer-1.0.2-6.fc19) hunspell: f19 f20 (hunspell-1.3.2-10.fc19 hunspell-1.3.2-9.fc19) kid3: f19 f20 (kid3-2.3-1.fc19 kid3-2.2.1-3.fc19) libgsf: f19 f20 (libgsf-1.14.26-2.fc19 libgsf-1.14.26-1.fc19) libguestfs: f19 f20 (1:libguestfs-1.21.20-1.fc19 1:libguestfs-1.21.19-1.fc19) plymouth: f19 f20 (plymouth-0.8.8-7.fc19 plymouth-0.8.8-6.fc19) policycoreutils: f19 f20 (policycoreutils-2.1.14-22.fc19 policycoreutils-2.1.14-19.fc19) rubygem-foreigner: f19 f20 (rubygem-foreigner-1.4.0-2.fc19 rubygem-foreigner-1.4.0-1.fc20) rubygem-transaction-simple: f19 f20 (rubygem-transaction-simple-1.4.0.2-6.fc19 rubygem-transaction-simple-1.4.0.2-5.fc19) selinux-policy: f19 f20 (selinux-policy-3.12.1-21.fc19 selinux-policy-3.12.1-20.fc19) setools: f19 f20 (setools-3.3.7-35.fc19 setools-3.3.7-34.fc19) texlive: f19 f20 (2:texlive-2012-18.20130310_r29324.fc19 2:texlive-2012-17.20130310_r29324.fc19) vdr: f19 f20 (vdr-1.7.40-1.fc19 vdr-1.7.39-2.fc19) vdr-epgsearch: f19 f20 (vdr-epgsearch-1.0.1-0.8.beta3.fc19 vdr-epgsearch-1.0.1-0.7.beta3.fc19) vdr-femon: f19 f20 (vdr-femon-1.7.19-1.fc19 vdr-femon-1.7.18-2.fc19) vdr-osdteletext: f19 f20 (vdr-osdteletext-0.9.4-1.fc19 vdr-osdteletext-0.9.3-8.fc19) vdr-remote: f19 f20 (vdr-remote-0.5.0-5.fc19 vdr-remote-0.5.0-4.fc19) vdr-screenshot: f19 f20 (vdr-screenshot-0.0.15-4.fc19 vdr-screenshot-0.0.15-3.fc19) vdr-skinenigmang: f19 f20 (vdr-skinenigmang-0.1.2-15.fc19 vdr-skinenigmang-0.1.2-14.fc19) vdr-skinsoppalusikka: f19 f20 (vdr-skinsoppalusikka-1.7.8-5.fc19 vdr-skinsoppalusikka-1.7.8-4.fc19) vdr-streamdev: f19 f20 (vdr-streamdev-0.6.1-0.3.git10db11ac.fc19 vdr-streamdev-0.6.1-0.2.git10db11ac.fc19) vdr-sudoku: f19 f20 (vdr-sudoku-0.3.5-20.fc19 vdr-sudoku-0.3.5-19.fc19) vdr-ttxtsubs: f19 f20 (vdr-ttxtsubs-0.3.0-1.fc19 vdr-ttxtsubs-0.2.4-16.20120718git.fc19) vdr-tvonscreen: f19 f20 (vdr-tvonscreen-1.0.141-25.fc19 vdr-tvonscreen-1.0.141-24.fc19) vdr-vnsiserver3: f19 f20 (vdr-vnsiserver3-0.9.0-5.fc19 vdr-vnsiserver3-0.9.0-4.fc19) --- Broken paths by builder: airlied: plymouth: f19 f20 (plymouth-0.8.8-7.fc19 plymouth-0.8.8-6.fc19) caolanm: hunspell: f19 f20 (hunspell-1.3.2-10.fc19 hunspell-1.3.2-9.fc19) libgsf: f19 f20 (libgsf-1.14.26-2.fc19 libgsf-1.14.26-1.fc19) corsepiu: texlive: f19 f20 (2:texlive-2012-18.20130310_r29324.fc19 2:texlive-2012-17.20130310_r29324.fc19) dwalsh: policycoreutils: f19 f20 (policycoreutils-2.1.14-22.fc19 policycoreutils-2.1.14-19.fc19) setools: f19 f20 (setools-3.3.7-35.fc19 setools-3.3.7-34.fc19) fossjon: fedora-arm-installer: f19 f20 (fedora-arm-installer-1.0.3-7.fc19 fedora-arm-installer-1.0.2-6.fc19) jpopelka: cups: f19 f20 (1:cups-1.6.1-26.fc19 1:cups-1.6.1-25.fc19) cups-filters: f19 f20 (cups-filters-1.0.30-3.fc19 cups-filters-1.0.30-2.fc20) mcpierce: rubygem-foreigner: f19 f20 (rubygem-foreigner-1.4.0-2.fc19 rubygem-foreigner-1.4.0-1.fc20) mgrepl: selinux-policy: f19 f20 (selinux-policy-3.12.1-21.fc19 selinux-policy-3.12.1-20.fc19) msuchy: rubygem-transaction-simple: f19 f20 (rubygem-transaction-simple-1.4.0.2-6.fc19 rubygem-transaction-simple-1.4.0.2-5.fc19) rjones: libguestfs: f19 f20 (1:libguestfs-1.21.20-1.fc19 1:libguestfs-1.21.19-1.fc19) scop: kid3: f19 f20 (kid3-2.3-1.fc19 kid3-2.2.1-3.fc19) vdr: f19 f20 (vdr-1.7.40-1.fc19 vdr-1.7.39-2.fc19) vdr-epgsearch: f19 f20 (vdr-epgsearch-1.0.1-0.8.beta3.fc19 vdr-epgsearch-1.0.1-0.7.beta3.fc19) vdr-femon: f19 f20 (vdr-femon-1.7.19-1.fc19 vdr-femon-1.7.18-2.fc19) vdr-osdteletext: f19 f20 (vdr-osdteletext-0.9.4-1.fc19 vdr-osdteletext-0.9.3-8.fc19) vdr-remote: f19 f20 (vdr-remote-0.5.0-5.fc19 vdr-remote-0.5.0-4.fc19) vdr-screenshot: f19 f20 (vdr-screenshot-0.0.15-4.fc19 vdr-screenshot-0.0.15-3.fc19) vdr-skinenigmang: f19 f20 (vdr-skinenigmang-0.1.2-15.fc19 vdr-skinenigmang-0.1.2-14.fc19) vdr-skinsoppalusikka: f19 f20 (vdr-skinsoppalusikka-1.7.8-5.fc19 vdr-skinsoppalusikka-1.7.8-4.fc19) vdr-streamdev: f19 f20 (vdr-streamdev-0.6.1-0.3.git10db11ac.fc19 vdr-streamdev-0.6.1-0.2.git10db11ac.fc19) vdr-sudoku: f19 f20 (vdr-sudoku-0.3.5-20.fc19 vdr-sudoku-0.3.5-19.fc19) vdr-ttxtsubs: f19 f20 (vdr-ttxtsubs-0.3.0-1.fc19 vdr-ttxtsubs-0.2.4-16.20120718git.fc19) vdr-tvonscreen:
Re: dnf installs cron.hourly
On 03/15/2013 07:51 PM, Adam Williamson wrote: In this case it seems perfectly logical. The thing in question is a cron script. May-be I am missing something, but the issue is not cron-jobs in general, it is unwanted, non-user-intended/initiated network access. Ralf -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
File Archive-Extract-0.68.tar.gz uploaded to lookaside cache by ppisar
A file has been added to the lookaside cache for perl-Archive-Extract: 8316c72e5df9808364157875bd48d887 Archive-Extract-0.68.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-Archive-Extract] 0.68 bump
commit 8b7bf42f1af5e6d598a285dbd63622502f3865ad
Author: Petr Písař ppi...@redhat.com
Date: Fri Mar 15 11:13:49 2013 +0100
0.68 bump
.gitignore|1 +
.rpmlint |2 ++
perl-Archive-Extract.spec |7 ++-
sources |2 +-
4 files changed, 10 insertions(+), 2 deletions(-)
---
diff --git a/.gitignore b/.gitignore
index 2bd1b2c..993aded 100644
--- a/.gitignore
+++ b/.gitignore
@@ -1,2 +1,3 @@
Archive-Extract-0.26.tar.gz
/Archive-Extract-0.66.tar.gz
+/Archive-Extract-0.68.tar.gz
diff --git a/.rpmlint b/.rpmlint
new file mode 100644
index 000..94391ed
--- /dev/null
+++ b/.rpmlint
@@ -0,0 +1,2 @@
+from Config import *
+addFilter(spelling-error .* (gz|lzma|tbz|txz|xz));
diff --git a/perl-Archive-Extract.spec b/perl-Archive-Extract.spec
index a8a6280..b8ddce1 100644
--- a/perl-Archive-Extract.spec
+++ b/perl-Archive-Extract.spec
@@ -1,5 +1,7 @@
Name: perl-Archive-Extract
-Version:0.66
+# Epoch to compete with core module from perl.spec
+Epoch: 1
+Version:0.68
Release:1%{?dist}
Summary:Generic archive extracting mechanism
License:GPL+ or Artistic
@@ -74,5 +76,8 @@ make test
%{_mandir}/man3/*
%changelog
+* Fri Mar 15 2013 Petr Pisar ppi...@redhat.com - 1:0.68-1
+- 0.68 bump
+
* Mon Feb 11 2013 Petr Pisar ppi...@redhat.com 0.66-1
- Specfile autogenerated by cpanspec 1.78.
diff --git a/sources b/sources
index 1b783d4..65b647d 100644
--- a/sources
+++ b/sources
@@ -1 +1 @@
-917c7c5b0f5ff0b42c49edd25f643165 Archive-Extract-0.66.tar.gz
+8316c72e5df9808364157875bd48d887 Archive-Extract-0.68.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-Archive-Extract/f19] 0.68 bump
Summary of changes: 8b7bf42... 0.68 bump (*) (*) 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
Broken dependencies: perl-Math-Clipper
perl-Math-Clipper has broken dependencies in the rawhide tree: On x86_64: perl-Math-Clipper-1.17-3.fc19.x86_64 requires libpolyclipping.so.5()(64bit) On i386: perl-Math-Clipper-1.17-3.fc19.i686 requires libpolyclipping.so.5 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 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
File Digest-MD4-1.8.tar.gz uploaded to lookaside cache by pghmcfc
A file has been added to the lookaside cache for perl-Digest-MD4: b6e612cde0bfc48a580724db42291e15 Digest-MD4-1.8.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
Broken dependencies: perl-Math-Clipper
perl-Math-Clipper has broken dependencies in the F-19 tree: On x86_64: perl-Math-Clipper-1.17-3.fc19.x86_64 requires libpolyclipping.so.5()(64bit) On i386: perl-Math-Clipper-1.17-3.fc19.i686 requires libpolyclipping.so.5 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
Broken dependencies: perl-Bio-ASN1-EntrezGene
perl-Bio-ASN1-EntrezGene has broken dependencies in the F-19 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
[perl-Digest-MD4] Update to 1.8
commit 33d0c86d0577f04ba11ccda719f8b87f2f51dfb0
Author: Paul Howarth p...@city-fan.org
Date: Fri Mar 15 10:46:45 2013 +
Update to 1.8
- New upstream release 1.8
- Fixed example output in doc in MD4.pm
- Removed defunct code that prevented building on 64-bit platform
- BR: perl(Exporter) and perl(File::Spec)
- BR: libdb-devel where available
- Drop %defattr, redundant since rpm 4.4
- No need to remove empty directories from the buildroot
.gitignore |2 +-
perl-Digest-MD4.spec | 25 -
sources |2 +-
3 files changed, 22 insertions(+), 7 deletions(-)
---
diff --git a/.gitignore b/.gitignore
index a1c04eb..c008c68 100644
--- a/.gitignore
+++ b/.gitignore
@@ -1 +1 @@
-Digest-MD4-1.5.tar.gz
+/Digest-MD4-[0-9.]*.tar.gz
diff --git a/perl-Digest-MD4.spec b/perl-Digest-MD4.spec
index d145207..f8f8666 100644
--- a/perl-Digest-MD4.spec
+++ b/perl-Digest-MD4.spec
@@ -1,13 +1,21 @@
Name: perl-Digest-MD4
-Version: 1.5
-Release: 20%{?dist}
+Version: 1.8
+Release: 1%{?dist}
Summary: Perl interface to the MD4 Algorithm
Group: Development/Libraries
License: GPL+ or Artistic
URL: http://search.cpan.org/dist/Digest-MD4/
Source0:
http://search.cpan.org/CPAN/authors/id/M/MI/MIKEM/DigestMD4/Digest-MD4-%{version}.tar.gz
BuildRoot: %{_tmppath}/%{name}-%{version}-%{release}-root-%(id -nu)
-BuildRequires: perl(ExtUtils::MakeMaker), db4-devel, gdbm-devel
+%if 0%{?fedora} 13 || 0%{?rhel} 6
+BuildRequires: libdb-devel
+%else
+BuildRequires: db4-devel
+%endif
+BuildRequires: gdbm-devel
+BuildRequires: perl(Exporter)
+BuildRequires: perl(ExtUtils::MakeMaker)
+BuildRequires: perl(File::Spec)
Requires: perl(:MODULE_COMPAT_%(eval `perl -V:version`; echo $version))
# Don't provide private Perl libs
@@ -31,7 +39,6 @@ rm -rf %{buildroot}
make pure_install DESTDIR=%{buildroot}
find %{buildroot} -type f -name .packlist -exec rm -f {} ';'
find %{buildroot} -type f -name '*.bs' -empty -exec rm -f {} ';'
-find %{buildroot} -depth -type d -exec rmdir {} ';' 2/dev/null
%{_fixperms} %{buildroot}
%check
@@ -41,13 +48,21 @@ make test
rm -rf %{buildroot}
%files
-%defattr(-,root,root,-)
%doc Changes README rfc1320.txt
%{perl_vendorarch}/Digest/
%{perl_vendorarch}/auto/Digest/
%{_mandir}/man3/Digest::MD4.3pm*
%changelog
+* Fri Mar 15 2013 Paul Howarth p...@city-fan.org - 1.8-1
+- Update to 1.8
+ - Fixed example output in doc in MD4.pm
+ - Removed defunct code that prevented building on 64-bit platform
+- BR: perl(Exporter) and perl(File::Spec)
+- BR: libdb-devel where available
+- Drop %%defattr, redundant since rpm 4.4
+- No need to remove empty directories from the buildroot
+
* Thu Feb 14 2013 Fedora Release Engineering rel-...@lists.fedoraproject.org
- 1.5-20
- Rebuilt for https://fedoraproject.org/wiki/Fedora_19_Mass_Rebuild
diff --git a/sources b/sources
index b1efb8f..d7158ac 100644
--- a/sources
+++ b/sources
@@ -1 +1 @@
-594d661c18b46a4aea97931dcaf5ce14 Digest-MD4-1.5.tar.gz
+b6e612cde0bfc48a580724db42291e15 Digest-MD4-1.8.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-Digest-MD4] Created tag perl-Digest-MD4-1.8-1.fc19
The lightweight tag 'perl-Digest-MD4-1.8-1.fc19' was created pointing to: 33d0c86... Update to 1.8 -- 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-Digest-MD4] Created tag perl-Digest-MD4-1.8-1.fc20
The lightweight tag 'perl-Digest-MD4-1.8-1.fc20' was created pointing to: 33d0c86... Update to 1.8 -- 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] Correct dependencies of perl-HTTP-Tiny
commit 31309539843b4b3c41ae7aee6c14faf03432d0e1
Author: Petr Písař ppi...@redhat.com
Date: Fri Mar 15 14:24:27 2013 +0100
Correct dependencies of perl-HTTP-Tiny
perl.spec |7 ++-
1 files changed, 6 insertions(+), 1 deletions(-)
---
diff --git a/perl.spec b/perl.spec
index 4b56274..09e5ad4 100644
--- a/perl.spec
+++ b/perl.spec
@@ -29,7 +29,7 @@
Name: perl
Version:%{perl_version}
# release number must be even higher, because dual-lived modules will be
broken otherwise
-Release:261%{?dist}
+Release:262%{?dist}
Epoch: %{perl_epoch}
Summary:Practical Extraction and Report Language
Group: Development/Languages
@@ -812,8 +812,10 @@ Group: Development/Libraries
License:GPL+ or Artistic
Epoch: 0
Version:0.017
+Requires: perl(bytes)
Requires: perl(Carp)
Requires: perl(IO::Socket)
+Requires: perl(Time::Local)
BuildArch: noarch
%description HTTP-Tiny
@@ -3106,6 +3108,9 @@ sed \
# Old changelog entries are preserved in CVS.
%changelog
+* Fri Mar 15 2013 Petr Pisar ppi...@redhat.com - 4:5.16.3-262
+- Correct dependencies of perl-HTTP-Tiny
+
* Thu Mar 14 2013 Petr Pisar ppi...@redhat.com - 4:5.16.3-261
- 5.16.3 bump (see http://search.cpan.org/dist/perl-5.16.3/pod/perldelta.pod
for release notes)
--
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] Sub-package Time-Local
commit bffc0256e912ec6c926233e7f9a92ebbe124f8c0
Author: Petr Písař ppi...@redhat.com
Date: Fri Mar 15 14:24:43 2013 +0100
Sub-package Time-Local
perl.spec | 28 +++-
1 files changed, 27 insertions(+), 1 deletions(-)
---
diff --git a/perl.spec b/perl.spec
index 09e5ad4..1d906b9 100644
--- a/perl.spec
+++ b/perl.spec
@@ -1405,6 +1405,23 @@ This module provides thread-safe FIFO queues that can be
accessed safely by
any number of threads.
%endif
+%package Time-Local
+Summary:Efficiently compute time from local and GMT time
+Group: Development/Libraries
+License:GPL+ or Artistic
+Epoch: 0
+Version:1.2000
+BuildArch: noarch
+Conflicts: perl 4:5.16.3-262
+
+%description Time-Local
+This module provides functions that are the inverse of built-in perl functions
+localtime() and gmtime(). They accept a date as a six-element array, and
+return the corresponding time(2) value in seconds since the system epoch
+(Midnight, January 1, 1970 GMT on Unix, for example). This value can be
+positive or negative, though POSIX only requires support for positive values,
+so dates before the system's epoch may not work on all operating systems.
+
%package Time-Piece
Summary:Time objects from localtime and gmtime
Group: Development/Libraries
@@ -1570,7 +1587,7 @@ Requires: perl-Pod-Parser, perl-Pod-Perldoc,
perl-Pod-Usage
Requires: perl-podlators, perl-Pod-Simple
Requires: perl-Socket, perl-Term-UI, perl-Test-Harness, perl-Test-Simple
Requires: perl-Text-ParseWords, perl-Text-Soundex, perl-Thread-Queue
-Requires: perl-Time-Piece, perl-Version-Requirements,
+Requires: perl-Time-Local, perl-Time-Piece, perl-Version-Requirements,
Requires: perl-version, perl-threads, perl-threads-shared, perl-parent
%description core
@@ -2397,6 +2414,10 @@ sed \
%exclude %{privlib}/Thread/Queue.pm
%exclude %{_mandir}/man3/Thread::Queue.*
+# Time-Local
+%exclude %{privlib}/Time/Local.pm
+%exclude %{_mandir}/man3/Time::Local.*
+
# Time::Piece
%exclude %{archlib}/Time/Piece.pm
%exclude %{archlib}/Time/Seconds.pm
@@ -3065,6 +3086,10 @@ sed \
%{_mandir}/man3/Thread::Queue.*
%endif
+%files Time-Local
+%{privlib}/Time/Local.pm
+%{_mandir}/man3/Time::Local.*
+
%files Time-Piece
%{archlib}/Time/Piece.pm
%{archlib}/Time/Seconds.pm
@@ -3110,6 +3135,7 @@ sed \
%changelog
* Fri Mar 15 2013 Petr Pisar ppi...@redhat.com - 4:5.16.3-262
- Correct dependencies of perl-HTTP-Tiny
+- Sub-package Time-Local (bug #922054)
* Thu Mar 14 2013 Petr Pisar ppi...@redhat.com - 4:5.16.3-261
- 5.16.3 bump (see http://search.cpan.org/dist/perl-5.16.3/pod/perldelta.pod
--
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] Unify file exclude titles
commit fda872f919597b99b50179080b33e76ee34578ff
Author: Petr Písař ppi...@redhat.com
Date: Fri Mar 15 14:28:46 2013 +0100
Unify file exclude titles
perl.spec | 52 ++--
1 files changed, 26 insertions(+), 26 deletions(-)
---
diff --git a/perl.spec b/perl.spec
index 1d906b9..47aa52b 100644
--- a/perl.spec
+++ b/perl.spec
@@ -2003,14 +2003,14 @@ sed \
%exclude %{archlib}/Compress/Raw/Bzip2.pm
%exclude %{_mandir}/man3/Compress::Raw::Bzip2*
-# Compress::Raw::Zlib
+# Compress-Raw-Zlib
%exclude %{archlib}/Compress/Raw/
%exclude %{archlib}/auto/Compress
%exclude %{archlib}/auto/Compress/Raw/
%exclude %{archlib}/auto/Compress/Raw/Zlib/
%exclude %{_mandir}/man3/Compress::Raw::Zlib*
-# Data::Dumper
+# Data-Dumper
%exclude %dir %{archlib}/auto/Data
%exclude %dir %{archlib}/auto/Data/Dumper
%exclude %{archlib}/auto/Data/Dumper/Dumper.so
@@ -2027,12 +2027,12 @@ sed \
%exclude %{_mandir}/man3/Digest::base.3*
%exclude %{_mandir}/man3/Digest::file.3*
-# Digest::MD5
+# Digest-MD5
%exclude %{archlib}/Digest/MD5.pm
%exclude %{archlib}/auto/Digest/MD5/
%exclude %{_mandir}/man3/Digest::MD5.3*
-# Digest::SHA
+# Digest-SHA
%exclude %{_bindir}/shasum
%exclude %{archlib}/Digest/SHA.pm
%exclude %{archlib}/auto/Digest/SHA/
@@ -2054,16 +2054,16 @@ sed \
%exclude %{privlib}/Encode/encode.h
%exclude %{_mandir}/man1/enc2xs.1*
-# ExtUtils::CBuilder
+# ExtUtils-CBuilder
%exclude %{privlib}/ExtUtils/CBuilder/
%exclude %{privlib}/ExtUtils/CBuilder.pm
%exclude %{_mandir}/man3/ExtUtils::CBuilder*
-# ExtUtils::Embed
+# ExtUtils-Embed
%exclude %{privlib}/ExtUtils/Embed.pm
%exclude %{_mandir}/man3/ExtUtils::Embed*
-# ExtUtils::Install
+# ExtUtils-Install
%exclude %{privlib}/ExtUtils/Install.pm
%exclude %{privlib}/ExtUtils/Installed.pm
%exclude %{privlib}/ExtUtils/Packlist.pm
@@ -2071,12 +2071,12 @@ sed \
%exclude %{_mandir}/man3/ExtUtils::Installed.3*
%exclude %{_mandir}/man3/ExtUtils::Packlist.3*
-# ExtUtils::Manifest
+# ExtUtils-Manifest
%exclude %{privlib}/ExtUtils/Manifest.pm
%exclude %{privlib}/ExtUtils/MANIFEST.SKIP
%exclude %{_mandir}/man3/ExtUtils::Manifest.3*
-# ExtUtils::MakeMaker
+# ExtUtils-MakeMaker
%exclude %{_bindir}/instmodsh
%exclude %{privlib}/ExtUtils/Command/
%exclude %{privlib}/ExtUtils/Liblist/
@@ -2098,7 +2098,7 @@ sed \
%exclude %{_mandir}/man3/ExtUtils::Mksymlists.3*
%exclude %{_mandir}/man3/ExtUtils::testlib.3*
-# ExtUtils::ParseXS
+# ExtUtils-ParseXS
%exclude %dir %{privlib}/ExtUtils/ParseXS/
%exclude %dir %{privlib}/ExtUtils/Typemaps/
%exclude %{privlib}/ExtUtils/ParseXS.pm
@@ -2127,7 +2127,7 @@ sed \
%exclude %{privlib}/File/CheckTree.pm
%exclude %{_mandir}/man3/File::CheckTree.3*
-# File::Fetch
+# File-Fetch
%exclude %{privlib}/File/Fetch.pm
%exclude %{_mandir}/man3/File::Fetch.3*
@@ -2138,15 +2138,15 @@ sed \
%exclude %{_mandir}/man1/perlfilter.*
%exclude %{_mandir}/man3/Filter::Util::*
-# IO::Compress
+# IO-Compress
%exclude %{_bindir}/zipdetails
%exclude %{privlib}/IO/Compress/FAQ.pod
%exclude %{_mandir}/man1/zipdetails.*
%exclude %{_mandir}/man3/IO::Compress::FAQ.*
-# Compress::Zlib
+# Compress-Zlib
%exclude %{privlib}/Compress/Zlib.pm
%exclude %{_mandir}/man3/Compress::Zlib*
-# IO::Compress::Base
+# IO-Compress-Base
%exclude %{privlib}/File/GlobMapper.pm
%exclude %{privlib}/IO/Compress/Base/
%exclude %{privlib}/IO/Compress/Base.pm
@@ -2156,7 +2156,7 @@ sed \
%exclude %{_mandir}/man3/IO::Compress::Base.*
%exclude %{_mandir}/man3/IO::Uncompress::AnyUncompress.*
%exclude %{_mandir}/man3/IO::Uncompress::Base.*
-# IO::Compress::Zlib
+# IO-Compress-Zlib
%exclude %{privlib}/IO/Compress/Adapter/
%exclude %{privlib}/IO/Compress/Deflate.pm
%exclude %{privlib}/IO/Compress/Gzip/
@@ -2185,19 +2185,19 @@ sed \
%exclude %{_mandir}/man3/IO::Uncompress::RawInflate*
%exclude %{_mandir}/man3/IO::Uncompress::Unzip*
-# IO::Zlib
+# IO-Zlib
%exclude %{privlib}/IO/Zlib.pm
%exclude %{_mandir}/man3/IO::Zlib.*
-# HTTP::Tiny
+# HTTP-Tiny
%exclude %{privlib}/HTTP/Tiny.pm
%exclude %{_mandir}/man3/HTTP::Tiny*
-# IPC::Cmd
+# IPC-Cmd
%exclude %{privlib}/IPC/Cmd.pm
%exclude %{_mandir}/man3/IPC::Cmd.3*
-# JSON::PP
+# JSON-PP
%exclude %{_bindir}/json_pp
%exclude %{privlib}/JSON/PP
%exclude %{privlib}/JSON/PP.pm
@@ -2205,7 +2205,7 @@ sed \
%exclude %{_mandir}/man3/JSON::PP.3*
%exclude %{_mandir}/man3/JSON::PP::Boolean.3pm*
-# Locale::Codes
+# Locale-Codes
%exclude %{privlib}/Locale/Codes
%exclude %{privlib}/Locale/Codes.*
%exclude %{privlib}/Locale/Country.*
@@ -2219,11 +2219,11 @@ sed \
%exclude %{_mandir}/man3/Locale::Language.*
%exclude %{_mandir}/man3/Locale::Script.*
-# Locale::Maketext::Simple
+# Locale-Maketext-Simple
%exclude %{privlib}/Locale/Maketext/Simple.pm
%exclude %{_mandir}/man3/Locale::Maketext::Simple.*
-# Log::Message
+# Log-Message
%exclude %{privlib}/Log/Message.pm
%exclude %{privlib}/Log/Message/Config.pm
%exclude
